Thiết kế cơ sở dữ liệu vật lý và những điều chỉnh thiết kế

Giống như tất cả các phần thiết kế cơ sở dữ liệu khác, thiết kế vật lý phải được định hướng bởi yếu tố tự nhiên của dữ liệu và những chức năng gì mà người dùng mong muốn sử dụng. Cụ thể, chúng ta phải hiểu về những luồng công việc điển hình mà cơ sở dữ liệu phải hỗ trợ, luồng công việc bao gồm cả các truy vấn và cập nhật dữ liệu. Người dùng cũng có một số yêu cầu về việc tốc độ thực hiện các truy vấn hoặc việc những cập nhật nào phải được thực thi hoặc có bao nhiêu giao dịch phải được xử lý mỗi giây. Biểu diễn luồng công việc và những yêu cầu thực thi của người dùng là cơ sở để tiến hành thiết kế cơ sở dữ liệu vật lý.

Để tạo ra một thiết kế cơ sở dữ liệu vật lý tốt và điều chỉnh sao cho hệ thống này thực hiện phù hợp với những yêu cầu nảy sinh mới của người dùng, người thiết kế phải hiểu được những công việc của một DBMS, đặc biệt là những công nghệ xử lý truy vấn và chỉ mục mà nó hỗ trợ. Nếu cơ sở dữ liệu này có nhiều người sử dụng đồng thời, hoặc nó là cơ sở dữ liệu phân tán, thì các công việc trở nên phức tạp hơn.

Chúng tôi trình bày những ảnh hưởng của tương tranh đối với việc thiết kế cơ sở dữ liệu trong Phần 10 và cơ sở dữ liệu phân tán trong Chương 22.

Khi xem xét những chỉ mục nào nên được tạo, chúng ta bắt đầu từ danh sách các truy vấn (bao gồm cả các truy vấn là một phần của thao tác cập nhật). Trước hết, chỉ những quan hệ được một vài truy vấn truy cập đến mới được xem là các ứng cử viên để đánh chỉ mục, và việc lựa chọn thuộc tính nào làm chỉ mục tuỳ thuộc vào các điều kiện xuất hiện trong các mệnh đề WHERE. Sự hiện diện của các chỉ mục thích hợp có thể cải thiện đáng kể khả năng thực thi truy vấn, như đã trình bày trong Chương 8 và 12.

Một cách tiếp cận để lựa chọn chỉ mục là xem xét những truy vấn quan trọng nhất và với mỗi truy vấn chúng ta sẽ chỉ định sử dụng các chỉ mục nào trong kế hoạch thực hiện của nó. Sau đó chúng ta cân nhắc xem liệu có thể có được một kế hoạch thực hiện tốt hơn không nếu chúng ta bổ sung thêm một số chỉ mục nữa; nếu có, những chỉ mục bổ sung này sẽ là ứng cử viên trong danh sách chỉ mục của chúng ta. Nói chung, những truy cập phạm vi hưởng lợi từ chỉ mục B+tree, và những truy cập so-sánh-chính-xác hưởng lợi từ chỉ mục băm. Việc phân cụm có lợi cho những truy vấn phạm vi, và nó có lợi cho những truy vấn so-sánh-chính-xác nếu một vài cổng vào dữ liệu chứa cùng giá trị khoá.

Tuy nhiên, trước khi thêm một chỉ mục vào danh sách chúng ta phải xem xét tác động của nó đối với thao tác cập nhật. Như chúng ta đã lưu ý ở phía trên, mặc dù chỉ mục có thể làm tăng tốc độ của thành phần truy vấn trong câu lệnh cập nhật, nhưng tất cả các chỉ mục có liên quan đến thuộc tính đã thay đổi phải được cập nhật theo. Vì thế, chúng ta phải cân nhắc khả năng một số phép toán cập nhật chịu tốc độ chậm để tăng tốc độ của những truy vấn khác.

Rõ ràng, để lựa chọn các chỉ mục tốt cho một luồng công việc nào đó yêu cầu chúng ta phải có những hiểu biết về các công nghệ chỉ mục và những gì bộ tối ưu hoá truy vấn làm. Những hướng dẫn sau về lựa chọn chỉ mục tổng kết những tranh luận của chúng ta:

Có nên chỉ mục (Hướng dẫn 1): Không nên xây dựng một chỉ mục nào đó nếu nó không phục vụ cho một vài truy vấn – bao gồm cả các truy vấn là thành phần của lệnh cập nhật - hưởng lợi từ nó. Bất cứ khi nào có thể, hãy lựa chọn các chỉ mục làm tăng tốc độ của nhiều hơn một truy vấn.

Lựa chọn Khoá tìm kiếm (Hướng dẫn 2): Các thuộc tính có trong một mệnh đề WHERE nào đó là các ứng cử viên được đánh chỉ mục.

• Điều kiện lọc so-sánh-chính-xác khuyên chúng ta xem xét một chỉ mục trên các thuộc tính được lọc, lý tưởng là một chỉ mục băm.
• Điều kiện lọc phạm vi khuyên chúng ta xem xét một chỉ mục B+tree (hoặc ISAM) trên các thuộc tính được lọc. Một chỉ mục B+tree thường tốt hơn một chỉ mục ISAM. Lựa chọn một chỉ mục ISAM nếu quan hệ này thường xuyên được cập nhật, nhưng để đơn giản chúng ta thừa nhận rằng một chỉ mục B+tree luôn được ưu tiên lựa chọn trước chỉ mục ISAM.

Các khoá tìm kiếm là đa-thuộc-tính (Hướng dẫn 3): Các chỉ mục với khoá tìm kiếm là đa-thuộc-tính nên được xem xét trong hai trường hợp sau:

• Mệnh đề WHERE chứa các điều kiện gồm nhiều hơn một thuộc tính của một quan hệ.
• Hệ thống cung cấp các chiến lược đánh giá chỉ-chỉ-số (tức là, việc truy cập các quan hệ có thể được tránh) đối với những truy vấn quan trọng. (Trường hợp này có thể dẫn đến một số thuộc tính nằm trong khoá tìm kiếm mặc dù chúng không xuất hiện trong mệnh đề WHERE.)

Khi khoá tìm kiếm là đa-thuộc-tính, các truy vấn phạm vi phải thận trọng với thứ tự các thuộc tính trong khoá tìm kiếm để tương ứng với các truy vấn.

Cân nhắc khi phân cụm (Hướng dẫn 4): Có nhiều nhất một chỉ mục phân cụm trên một quan hệ, và việc phân cụm ảnh hưởng rất lớn đến quá trình thực thi; vì thế lựa chọn chỉ mục nào được phân cụm là rất quan trọng.

• Các truy vấn phạm vi dường như được hưởng lợi nhiều nhất từ việc phân cụm. Nếu một số truy vấn phạm vi được đưa ra trên một quan hệ nào đó, lấy ra các tập thuộc tính khác nhau, hãy xem xét điều kiện lọc trong các truy vấn và tần suất thực hiện của chúng trong luồng công việc để đi đến quyết định chỉ mục nào được phân cụm.
• Nếu một chỉ mục nào đó được dùng trong một chiến lược đánh giá chỉ-chỉ-số, thì chỉ mục này không cần phân cụm. (Chỉ phân cụm khi chỉ mục này được sử dụng để truy cập các bộ giá trị ở các quan hệ nằm phía dưới).

Chỉ mục băm hay chỉ mục cây (Hướng dẫn 5): Chỉ mục B+tree thường tốt hơn cho các truy vấn miền và truy vấn bằng. Chỉ mục băm là tốt hơn trong những trường hợp sau:

• Chỉ mục được hy vọng sẽ hỗ trợ nối lặp lồng nhau chỉ mục; quan hệ chỉ mục là quan hệ phía trong, và khoá tìm kiếm chứa các cột có tính năng kết nối.
• Luồng công việc có một truy vấn bằng rất quan trọng chứa các thuộc tính khoá tìm kiếm, và không có các truy vấn phạm vi.

Cân đối với giá phải trả để duy trì chỉ mục (Hướng dẫn 6): Khi đưa ra quyết định tạo chỉ mục, chúng ta phải cân nhắc ảnh hưởng của mỗi chỉ mục đối với việc cập nhật trong các luồng công việc.

• Nếu việc duy trì một chỉ mục nào đó làm chậm đi các phép toán cập nhật thường xuyên thì chúng ta phải xem xét để xoá chỉ mục này.
• Tuy nhiên, việc thêm một chỉ mục nào đó có thể làm tăng tốc độ thực hiện của một phép cập nhật. Ví dụ, một chỉ mục trên Emloyee IDs có thể làm tăng tốc độ của việc tăng lương cho một nhân viên nào đó (được xác định bằng ID).

Các ví dụ sau minh hoạ cách lựa chọn chỉ mục trong quá trình thiết kế cơ sở dữ liệu, tiếp tục với những tranh luận trong Chương 8, nơi chúng ta đã tập trung bàn về lựa chọn chỉ mục đối với các truy vấn trên một bảng đơn. Lược đồ được sử dụng trong các ví dụ sau không được biểu diễn một cách chi tiết, chúng chỉ chứa tên các thuộc tính. Các thông tin bổ sung được biểu diễn khi cần thiết.

Hãy cùng chúng tôi bắt đầu với một ví dụ đơn giản:

SELECT E.ename, D.mgr
FROM Employees E, Departments D
WHERE D.dname= ‘Toy’ AND E.dno=D.dno

Các quan hệ được đề cập trong truy vấn này là Employees và Departments, và cả hai điều kiện trong mệnh đề WHERE đều là điều kiện bằng. Những hướng dẫn chúng ta đã nghiên cứu ở trên khuyên chúng ta nên xây dựng một chỉ mục băm trên thuộc tính dname của quan hệ Departments. Nhưng cân nhắc đến điều kiện bằng E.dno=D.dno, chúng ta nên xây dựng một chỉ mục (tất nhiên là chỉ mục băm) trên thuộc tính dno của Departments hoặc Employees (hoặc cả hai)? Thực chất chúng ta muốn truy cập các bộ giá trị trong Departments sử dụng chỉ mục trên dname vì chỉ có một vài bộ giá trị thoả mãn điều kiện D.dname=‘Toy’. Với mỗi bộ giá trị Departments thoả mãn, chúng ta tìm các bộ giá trị tương ứng trong Employees bằng việc sử dụng một chỉ mục trên thuộc tính dno của Employees. Vì thế, chúng ta nên xây dựng một chỉ mục trên trường dno của Employees. (Ghi nhớ rằng chẳng có ích lợi gì khi xây dựng một chỉ mục nữa trên trường dno của Departments vì các bộ giá trị Departments được truy cập sử dụng chỉ mục dname).

Việc lựa chọn chỉ mục được định hướng bởi kế hoạch đánh giá truy vấn mà chúng ta muốn sử dụng. Quá trình lựa chọn kế hoạch đánh giá truy vấn sẽ được thực hiện cùng với lựa chọn thiết kế vật lý vì tối ưu hoá truy vấn thực sự rất hữu ích cho thiết kế vật lý. Chúng tôi chỉ ra một kế hoạch tốt đối với truy vấn này trong Hình 1.

Xem xét một thay đổi của truy vấn này, giả sử rằng mệnh đề WHERE được sửa thành WHERE D.dname = ‘Toy’ AND E.dno=D.dno AND E.age=25. Hãy cùng chúng tôi xem xét một số kế hoạch khác. Một kế hoạch tốt ở đây là truy cập các bộ giá tri trong Departments thoả mãn điều kiện chọn của dname, sau đó truy cập các bộ giá trị tương ứng trong Employees bằng cách sử dụng một chỉ mục trên trường dno; phép chọn trên age sau đó được áp dụng theo kiểu on-the-fly. Tuy nhiên, không như những thay đổi trước của truy vấn này, chúng ta không thực sự cần có một chỉ mục trên trường dno của Employees nếu chúng ta có một chỉ mục nào đó trên trường age. Trong trường hợp này chúng ta có thể truy cập các bộ giá trị của Departments thoả mãn điều kiện chọn trên dname (bằng việc sử dụng chỉ mục trên dname, như phần trước), truy cập các bộ giá trị của Employees thoả mãn điều kiện chọn trên age sử dụng chỉ mục trên age, và kết nối những tập giá trị này lại. Vì các tập giá trị chúng ta nối lại là nhỏ, nên chúng có thể nằm vừa trong bộ nhớ và việc xem xét cách thức kết nối không còn quan trọng nữa. Kế hoạch này dường như không tốt như kế hoạch sử dụng một chỉ mục trên dno, nhưng nó cũng là một lựa chọn hợp lý. Vì thế, nếu chúng ta đã có một chỉ mục trên age (đã được sử dụng trong một truy vấn nào đó trong luồng công việc), thì chúng ta nên sử dụng chỉ mục này.

Một kế hoạch đánh giá truy vấn lý tưởng

Truy vấn tiếp theo của chúng ta có chứa một điều kiện chọn phạm vi:

SELECT E.ename, D.dname
FROM 	Employees E, Departments D
WHERE E.sal BETWEEN 10000 AND 20000 AND E.hobby='Stamps'
AND E.dno=D.dno	

10000 < E.sal AND E.sal < 20000

Người ta khuyến khích sử dụng phép toán BETWEEN để biểu diễn các điều kiện phạm vi vì nó dễ dàng cho cả người dùng và cả bộ tối ưu hoá.

Trở lại với ví dụ truy vấn này, cả hai điều kiện chọn đều ở trên quan hệ Employees. Vì thế, dễ dành nhận ra rằng kế hoạch tốt nhất trong trường hợp này là Employees sẽ đóng vai trò là quan hệ phía ngoài và Departments là quan hệ phía trong giống như trong truy vấn trước, và chúng ta nên xây dựng một chỉ mục băm trên thuộc tính dno của Departments. Nhưng chỉ mục nào trên Employees là tốt nhất? Một chỉ mục B+tree trên thuộc tính sal sẽ phù hợp với phép chọn phạm vi, đặc biệt nếu nó là một chỉ mục được phân cụm. Một chỉ mục băm trên thuộc tính hobby sẽ phù hợp với điều kiện chọn bằng. Nếu một trong những chỉ mục này đang sẵn sàng, thì chúng ta có thể truy cập các bộ giá trị trong Employees bằng cách sử dụng chỉ mục này, truy cập các bộ giá trị tương ứng trong Departments sử dụng chỉ mục trên dno, và thực hiện tất cả các điều kiện chọn còn lại và các phép chiếu theo kiểu on-the-fly. Nếu cả hai chỉ mục này đang sẵn sàng, bộ tối ưu hoá sẽ lựa chọn chỉ mục thích hợp hơn để thực hiện truy vấn, tức là nó sẽ xem xét điều kiện chọn nào (điều kiện chọn phạm vi trên salary hoặc điều kiện chọn bằng trên hobby) có ít bộ giá trị thoả mãn hơn. Nói chung, chỉ mục nào thích hợp hơn tuỳ thuộc vào dữ liệu. Nếu có rất ít người có salary nằm trong phạm vi đã cho và có rất nhiều người có sở thích là stamps thì chỉ mục B+tree là lựa chọn tốt nhất. Ngược lại, chỉ mục băm trên hobby là tốt nhất.

Các chỉ mục phân cụm có thể trở nên đặc biệt quan trọng trong khi truy cập các quan hệ phía trong của một nối lặp lồng nhau chỉ mục nào đó. Để hiểu được mối quan hệ giữa các chỉ mục phân cụm và các liên kết, hãy cùng chúng tôi xem lại ví dụ đầu tiên của chúng ta:

SELECT E.ename, D.mgr
FROM Employees E, Departments D	
WHERE D.dname= ‘Toy’ AND E.dno=D.dno

Chúng ta đã kết luận rằng một kế hoạch tốt để thực hiện truy vấn này là sử dụng một chỉ mục trên dname để truy cập các bộ giá trị trong Departments thoả mãn điều kiện trên dname và tìm những bộ giá trị tương ứng của Employees sử dụng chỉ mục trên dno.

Các chỉ mục này có nên được phân cụm?

Giả sử số lượng các bộ giá trị thoả mãn điều kiện D.dname= ‘Toy’ nhỏ, thì chúng ta nên xây dựng một chỉ mục phân cụm trên dname. Mặc khác, Employees là bảng phía trong của nối lặp lồng nhau chỉ mục và dno không phải là khoá dự tuyển. Trường hợp này rất nên sử dụng chỉ mục phân cụm trên trường dno của Employees. Thực tế vì liên kết này chứa các phép chọn bằng lặp đi lặp lại trên trường dno của quan hệ phía trong, truy vấn kiểu này được khuyến khích là tạo ra một chỉ phân cụm trên trường dno hơn là kiểu truy vấn đơn giản trên trường hobby như trong ví dụ trước. (Tất nhiên, hai yếu tố là dữ liệu nào cần được lấy ra (phép lọc) và tần số của truy vấn cũng phải được đưa vào xem xét.)

Ví dụ tiếp theo cũng tự như ví dụ trước, minh hoạ các chỉ mục phân cụm được sử dụng như thế nào trong các liên kết sắp-xếp-trộn (sort-merge joins):

SELECT E.ename, D.mgr
FROM Employees E, Departments D
WHERE E.hobby='Stamps' AND E.dno=D.dno

Truy vấn này khác với truy vấn trước ở chỗ điều kiện E.hobby = ‘Stamps’ thay thế D.dname ='Toy'. Dựa trên giả thiết rằng chỉ có một vài nhân viên trong phòng ‘Toy’, chúng ta đã lựa chọn các chỉ mục phù hợp với phép nối lặp lồng nhau chỉ mục cùng với Departments là quan hệ phía ngoài. Bây giờ, hãy cùng chúng tôi giả sử rằng có rất nhiều nhân viên có sở thích là stamps. Trong trường hợp này, một phép lặp lồng nhau trên khối hoặc nối sắp-xếp-trộn có lẽ hiệu quả hơn. Nối sắp-xếp-trộn có thể sử dụng các lợi thế của chỉ mục phân cụm B+tree trên thuộc tính dno của Departments để truy cập các bộ giá trị và do đó tránh phải sắp xếp bảng Departments. Lưu ý rằng nếu sử dụng chỉ mục không phân cụm sẽ không hiệu quả - vì tất cả các bộ giá trị sẽ được truy cập, việc thực hiện một thao tác I/O đối với mỗi bộ giá trị dường như phải trả giá quá đắt. Nếu không có chỉ mục trên trường dno của Employees, chúng ta có thể truy cập các bộ giá trị của Employees (có thể sử dụng một chỉ mục trên trường hobby, đặc biệt khi chỉ mục này được phân cụm), áp dụng phép lọc E.hobby='Stamps' theo kiểu on-the-fly, và sắp xếp những bộ giá trị thoả mãn theo trường dno.

Những tranh luận của chúng ta chỉ ra rằng khi chúng ta truy cập các bộ giá trị sử dụng một chỉ mục nào đó, ảnh hưởng của việc phân cụm phụ thuộc vào số lượng các bộ giá trị được truy cập, tức là, số lượng các bộ giá trị thoả mãn các điều kiên chọn thích hợp với chỉ mục đó. Một chỉ mục không phân cụm chỉ tốt bằng một chỉ mục phân cụm khi phép chọn chỉ truy cập đến một bộ giá trị duy nhất (ví dụ, một phép chọn bằng trên một khoá dự tuyển). Khi số lượng các bộ giá trị được truy cập tăng lên, sử dụng chỉ mục không phân cụm phải trả giá đắt hơn vượt xa so với việc quét tuần tự toàn bộ quan hệ. Việc quét tuần tự truy cập toàn bộ các bộ giá trị, nhưng mỗi trang được truy cập chính xác một lần, trong khi đó mỗi trang có thể được truy cập nhiều lần bằng số lượng các bản ghi bên trong nó nếu chúng ta sử dụng một chỉ mục không phân cụm. Nếu blocked I/O được thực hiện (như phổ biến), những ưu điểm của quét tuần tự so với sử dụng chỉ mục không phân cụm tăng dần lên.

Chúng ta minh hoạ mối quan hệ giữa số lượng các bộ giá trị truy cập biểu diễn bằng tỷ lệ so với tổng số bộ giá trị có trong quan hệ, và giá của các phương pháp truy cập khác nhau trong Hình 2. Để đơn giản, chúng ta giả sử rằng truy vấn này là một phép chọn trên chỉ một quan hệ. (Hình này phản ánh giá của việc viết ra kết quả; và đường của quét tuần tự là một mặt phẳng.)

SELECT P.pid, A.componentid 
FROM Parts P, Assembly A		
WHERE P.pid = A.partid AND P.supplierid = ‘Acme’

SELECT P.pid, A.componentid
FROM Parts P, Assembly A		
WHERE P.pid = A.partid AND P.cost=10

Phần này xem xét một số truy vấn mà chúng ta có thể tìm ra được các kế hoạch thực hiện chúng hiệu quả hơn bằng cách tránh truy cập các bộ giá trị trong các quan hệ tham chiếu; kế hoạch này sẽ quét một chỉ mục liên quan nào đó (chỉ mục này dường như nhỏ hơn nhiều). Chỉ mục được sử dụng chỉ trong việc quét chỉ-chỉ-số không phải phân cụm vì các bộ giá trị trong quan hệ chỉ mục này không cần được truy cập.

Truy vấn này đưa ra các người quản lý của các phòng/ban có ít nhất một nhân viên:

SELECT D.mgr
FROM Departments D, Employees E
WHERE D.dno=E.dno

Quan sát thấy rằng không có thuộc tính nào của Employees được giữ lại. Nếu chúng ta có một chỉ mục nào đó trên trường dno của Employees, chúng ta nên thực hiện một nối lặp lồng nhau chỉ mục sử dụng quét chỉ-chỉ-số cho quan hệ phía bên trong. Trong trường hợp này, xây dựng một chỉ mục không phân cụm trên trường dno của Employees sẽ tốt hơn một chỉ mục phân cụm.

Truy vấn tiếp theo thực hiện ý tưởng này ở mức cao hơn:

SELECT D.mgr, E.eid
FROM Departments D, Employees E
WHERE D.dno=E.dno

Nếu chúng ta có một chỉ mục nào đó trên trường dno của Employees, chúng ta có thể sử dụng nó để truy cập các bộ giá trị của Employees trong quá trình kết nối (cùng với Departments là quan hệ phía bên ngoài), nhưng nếu chỉ mục này không được phân cụm thì cách tiếp cận này sẽ không hiệu quả. Mặc khác, giả sử chúng ta có một chỉ mục B+tree trên (dno, eid). Bây giờ tất cả thông tin chúng ta cần về một bộ giá trị nào đó của Employees đều chứa trong cổng vào dữ liệu của bộ giá trị đó trong chỉ mục này. Chúng ta có thể sử dụng chỉ mục này để tìm ra cổng vào dữ liệu đầu tiên có dno đã cho; tất cả các cổng vào dữ liệu có cùng giá trị dno được lưu trữ cùng nhau trong chỉ mục này. (Ghi nhớ rằng một chỉ mục băm trên khoá (dno, eid) không thể được sử dụng để xác định vị trí của một entry có dno nào đó). Vì thế, chúng ta có thể thực hiện được truy vấn này sử dụng nối lặp lồng nhau chỉ mục với Departments là quan hệ phía ngoài và quét chỉ-chỉ mục của quan hệ phía trong.

Số lượng các chỉ mục tiềm năng rất lớn: Với mỗi quan hệ, chúng ta có thể xem xét tất cả các tập con các thuộc tính như là một chỉ mục khoá; chúng ta phải quyết định thứ tự của các thuộc tính trong chỉ mục này; và chúng ta cũng phải quyết định xem chỉ mục này có nên phân cụm hay không phân cụm. Rất nhiều các ứng dụng lớn- việc tạo ra hàng chục ngàn các quan hệ khác nhau và việc lựa chọn thủ công các chỉ mục là việc làm không khả thi.

Sự quan trọng của chỉ mục và những khó khăn trong lựa chọn chỉ mục đã dẫn đến việc phải phát triển các công cụ để hỗ trợ người quản trị cơ sở dữ liệu lựa chọn được chỉ mục thích hợp cho từng luồng công việc. Đầu tiên là công cụ hỗ trợ lựa chọn chỉ mục - index tuning wizards, hay còn gọi là cố vấn chỉ mục - index advisors, là các công cụ tách biệt bên ngoài database engine; chúng đề nghị các chỉ mục nào nên được xây dựng cho từng luồng công việc với các truy vấn SQL khác nhau. Hạn chế chính của những hệ thống này là phải sao chép lại mô hình lượng giá tối ưu hoá truy vấn để đảm bảo rằng bộ tối ưu hoá sẽ chọn các kế hoạch đánh giá truy vấn giống với công cụ thiết kế. Vì bộ tối ưu hoá truy vấn luôn thay đổi trong từng phiên bản của hệ thống cơ sở dữ liệu thương mại, nên rất cần tích hợp công cụ hỗ trợ lựa chọn chỉ mục với bộ tối ưu hoá cơ sở dữ liệu. Sự ra đời gần đây nhất của công cụ này đã được tích hợp với database engine và sử dụng sử dụng bộ tối ưu hoá truy vấn để ước lượng giá của một luồng công việc cùng với tập các chỉ mục của nó, tránh được việc phải sao chép lại như ở trên.

Sau khi thiết kế cơ sở dữ liệu được đưa vào sử dụng, quá trình sử dụng thực tế này cung cấp nhiều thông tin chi tiết đáng giá giúp chúng ta điều chỉnh thiết kế ban đầu sao cho nó trở nên hiệu quả hơn. Rất nhiều giả định ban đầu về các luồng công việc có trong ứng dụng có thể đúng, và một số có thể sai. Những ước lượng ban đầu của chúng ta về kích thước dữ liệu có thể được thay thế bằng các thống kê thực tế từ các danh mục hệ thống. Việc kiểm tra cẩn thận các truy vấn có thể giải quyết được những vấn đề không mong muốn; ví dụ, khi thực hiện các kế hoạch của truy vấn, bộ tối ưu hoá có lẽ không sử dụng một vài chỉ mục như ta mong đợi.

Tiếp tục điều chỉnh cơ sở dữ liệu là việc làm quan trọng để đạt được hiệu quả trong thực thi. Trong phần này, chúng tôi giới thiệu ba kiểu điều chỉnh: điều chỉnh các chỉ mục, điều chỉnh lược đồ khái niệm và điều chỉnh các truy vấn. Những tranh luận của chúng ta về lựa chọn chỉ mục cũng được áp dụng để đưa ra những quyết định điều chỉnh chỉ mục. Điều chỉnh lược đồ khái niệm và truy vấn được trình bày kỹ hơn trong Phần 8 và 9.

SELECT D.mgr
FROM Employees E, Departments D
WHERE D.dname= ‘Toy’ AND E.dno=D.dno