Thiết kế cơ sở dữ liệu vật lý và những điều chỉnh thiết kế. Ths. Phạm Hoàng Nhung

Phần 4 xem xét xem vấn đề phân cụm quan trọng như thế nào một cách cẩnthận; tiếp đến chúng tôi trình bày cách chọn các chỉ mục phân cụm và trả lời câu hỏi cónên lưu trữ các bộ giá trị tr

Thiết kế cơ sở dữ liệu vật lý

Sau khi chúng ta thiết kế lược đồ khái niệm và lược đồ ngoài, tức là, tạo ra một tập cácquan hệ và các khung nhìn cùng với một tập các ràng buộc tham chiếu, chúng ta sẽ tiến

hành thiết kế cơ sở dữ liệu vật lý qua việc thiết kế lược đồ vật lý Vì những yêu cầu của

người dùng thường thay đổi nên phần thiết kế này cũng phải điều chỉnh thường xuyên

Chương này được tổ chức như sau Phần 1 cung cấp tổng quan về thiết kế cơ sở dữ liệuvật lý và các điều chỉnh Phần quan trọng nhất trong thiết kế cơ sở dữ liệu vật lý là lựachọn các chỉ mục Chúng tôi trình bày phần hướng dẫn lựa chọn chỉ mục trong Phần 2.Những hướng dẫn này được minh hoạ thông qua một số ví dụ và phát triển thêm trongPhần 3 Phần 4 xem xét xem vấn đề phân cụm quan trọng như thế nào một cách cẩnthận; tiếp đến chúng tôi trình bày cách chọn các chỉ mục phân cụm và trả lời câu hỏi cónên lưu trữ các bộ giá trị trong các quan hệ khác nhau nằm cạnh nhau hay không (lựachọn này được một số DBMS hỗ trợ) Phần 5 tập trung vào giải thích việc lựa chọn chỉmục tốt có thể thực hiện một số truy vấn mà không cần phải tìm kiếm trong phần dữ liệuthực Phần 6 bàn về các công cụ có thể giúp DBA tự động lựa chọn chỉ mục

Phần 7 nghiên cứu những vấn đề chính của việc điều chỉnh cơ sở dữ liệu Để điều chỉnhcác chỉ mục, chúng ta có lẽ phải điều chỉnh lược đồ khái niệm cũng như tần số sử dụngtruy vấn và việc định nghĩa các khung nhìn Chúng tôi trình bày cách điều chỉnh truyvấn và các định nghĩa khung nhìn trong Phần 9 Chúng tôi trình bày tóm tắt ảnh hưởngcủa truy cập tương tranh trong Phần 10 Phần 11 minh hoạ việc điều chỉnh trên ví dụcửa hàng Internet Chúng tôi tổng kết chương này bằng việc trình bày những tiêu chuẩn

giúp đánh giá DBMS trong Phần 12; các tiêu chuẩn này hỗ trợ đánh giá khả năng thựcthi của DBMS.

Giới thiệu về thiết kế cơ sở dữ liệu vật lý

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 địnhhướ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ườidù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ậpnhậ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ểudiễ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ànhthiết kế cơ sở dữ liệu vật lý

Xác định những nút cổ chai: Tất cả các hệ thống thương mại đều cung cấp các công

cụ phù hợp dùng để điều chỉnh các tham số hệ thống Những công cụ này có thể giúpxác định các nút cổ chai và đề xuất các khía cạnh liên quan đến thiết kế cơ sở dữ liệu

và phần chương trình ứng dụng cần thiết giúp điều chỉnh việc thực thi Ví dụ, chúng ta

có thể yêu cầu DBMS giám sát quá trình thực hiện của cơ sở dữ liệu trong một khoảngthời gian và báo số lượng các cụm được quét, số con trỏ được mở, các yêu cầu khoá,checkpoints, số các buffer được quét, thời gian đợi trung bình của các khoá, và nhiềunhững thống kê khác Trong Oracle, một báo cáo chứa những thông tin này có thể đượcđưa ra bằng cách chạy một script gọi là UTLBSTAT.SQL để khởi động việc giám sát

và một script UTLBSTAT.SQL để dừng việc này Danh mục hệ thống sẽ chứa thôngtin chi tiết về các bảng, phân bố các giá trị trong các chỉ mục khóa Một kế hoạch màDBMS đưa ra nhằm thực hiện một truy vấn nào đó có thể được nhìn thấy trong mộtmàn hình cùng với giá ước lượng đối với mỗi phép toán Tuỳ vào từng nhà cung cấp,những thông số chi tiết có thể khác nhau, nhưng tất cả các sản phẩm DBMS phổ biếntrên thị trường ngày nay đều cung cấp các công cụ nói trên

Để 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ựchiệ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ệutrong Phần 10 và cơ sở dữ liệu phân tán trong Chương 22

Luồng công việc của cơ sở dữ liệu

Chìa khoá để thiết kế vật lý tốt là phải có được một biểu diễn chính xác của các luồngcông việc mong muốn Biểu diễn luồng công việc bao gồm:

1 Danh sách các truy vấn (cùng với tần suất của chúng).

2 Danh cách các cập nhật và tần suất của chúng

3 Những đích cần đạt đến của mỗi kiểu truy vấn và cập nhật

Với mỗi truy vấn trong một luồng công việc, chúng ta phải xác định:

• Các quan hệ nào cần phải truy cập

• Những thuộc tính nào phải giữ lại (trong mệnh đề SELECT)

• Những thuộc tính nào phải lấy hoặc các điều kiện kết nối (trong mệnh đề

WHERE)

Tương tự, với mỗi cập nhật trong luồng công việc, chúng ta phải xác định:

• Lựa chọn những thuộc tính nào và các điều kiện nối (trong mệnh đề WHERE)

• Kiểu cập nhật (INSERT, DELETE, hoặc UPDATE) và các quan hệ được cậpnhật

• Với các lệnh cập nhật, những trường (cột) nào sẽ thay đổi

Ghi nhớ rằng các truy vấn và các cập nhật có thể có các tham số, ví dụ một thao tác ghi

nợ hoặc thanh toán sẽ có tham số là số tài khoản cụ thể của một người nào đó

Việc cập nhật bao giờ cũng chứa thành phần truy vấn để tìm ra các bộ giá trị cần đượccập nhật Thành phần này có thể được thực hiện tốt nếu chúng ta thiết kế vật lý tốt và có

sự hiện diện của các chỉ mục

Mặt khác, cập nhật luôn kéo theo một công việc khác đó là cập nhật các chỉ mục chứacác thuộc tính tính đã bị thay đổi Vì thế, trong khi các truy vấn có thể được hưởng lợi từ

sự hiện diện của chỉ mục thì các chỉ mục lại có thể làm tăng hoặc giảm tốc độ cập nhật.Người thiết kế luôn phải lưu ý đến điều này khi tạo ra các chỉ mục

Các quyết định khi thiết kế vật lý và điều chỉnh

Những quyết định quan trong trong quá trình thiết kế cơ sở dữ liệu vật lý và điều chỉnh

cơ sở dữ liệu bao gồm:

1 Lựa chọn những chỉ mục nào được tạo:

• Những quan hệ nào được chỉ mục và trường nào hoặc kết hợp một số trường đểtạo ra chỉ mục khoá tìm kiếm

• Với mỗi chỉ mục, xác định xem nó nên được phân cụm hay không phân cụm?

2 Điều chỉnh lược đồ khái niệm:

• Lựa chọn lược đồ chuẩn hoá: Chúng ta có nhiều hơn một cách để phân rã mộtlược đồ thành các quan hệ con ở dạng chuẩn mong muốn (BCNF hoặc 3NF).Quyết định chọn lược đồ nào sẽ dựa vào các điều kiện trong quá trình thực thi.

• Phi chuẩn hoá: Để cải thiện tốc độ thực thi các truy vấn, chúng ta sẽ xem xét lạicác lược đồ phân rã đưa ra do việc chuẩn hoá khi thiết kế lược đồ khái niệm

• Phân tách theo chiều dọc: Tuỳ theo tình trạng hiện tại, chúng ta có thể muốnquan hệ được phân rã sâu hơn nữa nhằm cải thiện tốc độ thực hiện các truy vấnchỉ bao gồm một vài thuộc tính

• Khung nhìn: Chúng ta có lẽ muốn thêm một vài khung nhìn để che giấu nhữngthay đổi trong lược đồ khái niệm

3 Điều chỉnh truy vấn và giao dịch: Các truy vấn được thực hiện một cách liên tục vàcác giao dịch có lẽ cần được viết lại để chạy nhanh hơn

Trong cơ sở dữ liệu phân tán và song song chúng ta sẽ bàn đến trong Chương 22, có một

số lựa chọn để xem xét như phân chia một quan hệ ra các site khác nhau hay là lưu trữbản sao của nó ở nhiều site

Sự cần thiết phải điều chỉnh cơ sở dữ liệu

Những thông tin chi tiết về luồng thực thi có lẽ khó có được ngay từ khi bắt đầu thiết kế

Do đó, điều chỉnh một cơ sở dữ liệu sau khi nó đã được thiết kế và phát triển là một việclàm quan trọng- chúng ta phải cải tiến thiết kế ban đầu để đạt được hiệu quả thực thi tốtnhất

Sự khác nhau giữa thiết kế cơ sở dữ liệu và điều chỉnh cơ sở dữ liệu đôi khi mang tínhchất chủ quan Chúng ta có thể coi kết quả của quá trình thiết kế là lược đồ khái niệmban đầu, tập các chỉ mục và các phân cụm sẽ được tạo Bất kể sự thay đổi nào tới lược đồkhái niệm và các lựa chọn chỉ mục và phân cụm trên đều được coi là chỉnh sửa Chúng

ta có thể coi một vài điều chỉnh của lược đồ khái niệm (và các quyết định thiết kế vật lýtạo ra do những điều chỉnh này) là một phần của quá trình thiết kế vật lý Việc đánh giấugiữa thiết kế và hiệu chỉnh là không quan trọng, và khi chúng ta trình bày về những lựachọn chỉ mục và điều chỉnh cơ sở dữ liệu không cần đề cập tới những điều chỉnh này đãthực hiện khi nào

Các chỉ dẫn để lựa chọn chỉ mục

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 truyvấ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ữngquan hệ được một vài truy vấn truy cập đến mới được xem là các ứng cử viên để đánhchỉ 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ấthiệ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ảithiệ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ớimỗ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ơnkhô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ổ sungnà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ậpphạ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 chonhữ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 độngcủ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ácchỉ 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 taphả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ấnlà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ệnhcậ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ácthuộ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ặcISAM) 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ộtchỉ 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+treeluô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ộtquan 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ácquan 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úngkhô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ácthuộ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ọnchỉ 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áctậ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ầnsuất thực hiện của chúng trong luồng công việc để đi đến quyết định chỉ mụcnà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ợpsau:

• 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ậttrong 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ủamộ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ụ cơ bản của việc chọn chỉ mục

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ếptụ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 tamuố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ùngvớ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ànhWHERE D.dname = ‘Toy’ AND E.dno=D.dno AND E.age=25 Hãy cùng chúng tôixem 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ằmvừ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 DWHERE 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.

Chỉ mục hoá và phân cụm

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ữacá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ủachú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ụngnhư 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ùngvớ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ấtnhiề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 nhautrê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ụngchỉ 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ụngmộ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ớichỉ 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épchọ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ôngphâ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ệcqué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ácmộ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ảnghi 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ụckhô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ácnhau 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ọntrê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éttuần tự là một mặt phẳng.)

Ảnh hưởng của việc phân cụm

Đồng-phân-cụm hai quan hệ

Trong phần trình bày về kiến trúc hệ thống cơ sở dữ liệu ở Chương 9, chúng ta đã giảithích về một quan hệ được lưu trữ trong một file như thế nào Mặc dù một file thườngchỉ chứa các bản ghi của một quan hệ, nhưng một vài hệ thống cho phép các bản ghi củanhiều hơn một quan hệ được lưu trong một file Với cách này, người dùng cơ sở dữ liệu

có thể yêu cầu các bản ghi của hai quan hệ có thể được đặt cạnh nhau theo một quy luật

tự nhiên Cách sắp đặt dữ liệu như thế này đôi khi được nói tới như là đồng-phân-cụmcủa hai quan hệ Bây giờ chúng ta bàn về vấn đề khi nào đồng-phân-cụm có thể manglại lợi ích

Ví dụ, xem xét hai quan hệ với lược đồ như sau:

Parts(pid: integer, pname: string, cost: integer, supplierid: integer)

Assembly(partid: integer, componentid: integer, quantity: integer)

Trong lược đồ này, trường componentid của Assembly (Sản phẩm kết hợp) tham chiếu tới pid của một Parts (Sản phẩm) nào đó Vì thế, bảng Assembly biểu diễn mối liên kết

1:N giữa Parts và Subparts (Sản phẩm con) của nó; một sản phẩm có thể có nhiều sảnphẩm con, nhưng mỗi sản phẩm là một sản phẩm con của nhiều nhất một sản phẩm

Trong bảng Parts, pid là khoá Với các sản phẩm kết hợp (những sản phẩm được lắp giáp từ các sản phẩm khác, như nội dung của bảng Assembly chỉ ra), trường cost được

tính từ giá của các sản phẩm con của nó

Giả sử rằng có một truy vấn thường xuyên xảy ra là tìm ra (ngay lập tức) các sản phẩmcon của tất cả các sản phẩm do một nhà sản xuất nào đó cung cấp:

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

Một kế hoạch tốt để thực hiện truy vấn này là áp điều kiện chọn trên bảng Parts và sau đótruy cập các bản ghi phù hợp của Assembly thông qua một chỉ mục nào đó trên trường

partid Chỉ mục này trên partid nên được phân cụm là tốt nhất Chúng tôi khẳng định kế

hoạch này là tốt Tuy nhiên, nếu chúng ta muốn tối ưu hoá chúng thêm nữa, thì chúng

ta có thể đồng-phân-cụm trên hai bảng này Với cách tiếp cận này, chúng ta sẽ lưu các

bản ghi của hai bảng cùng với nhau, với mỗi bản ghi Part(P) sẽ có tất cả các bản ghi của

Assembly(A) thoả mãn P.pid = A.partid theo sau Cách tiếp cận này cải thiện được việc lưu trữ hai quan hệ tách rời nhau và việc có một chỉ mục phân cụm trên partid bởi vì

nó không cần một chỉ mục giúp tìm ra các bản ghi ở Assembly tương ứng với một bảnghi nào đó của Parts Vì thế, với mỗi truy vấn, chúng ta ghi lại một vài (điển hình là haihoặc ba) trang chỉ mục I/Os

Nếu chúng ta quan tâm đến việc tìm ra các sản phẩm con của tất cả các sản phẩm ngay

lập tức (tức là, truy vấn trước không có điều kiện chọn trên supplierid),việc tạo ra một chỉ mục phân cụm trên partid và thực hiện một nối lặp lồng nhau chỉ mục trong đó

Assembly là quan hệ phía trong được coi là một kế hoạch tốt Thậm chí có một chiến

lược tốt hơn nữa là tạo ra một chỉ mục phân cụm trên trường partid của Assembly và trường pid của Parts, sau đó thực hiện một sắp-xếp-trộn, sử dụng các chỉ mục để truy cập

các bộ giá trị theo thứ tự được sắp Chiến lược này có thể so sánh được với việc sử dụngđồng-phân-cụm, cách mà chỉ việc quét trên tập các bản ghi (của Parts và Assembly, nơilưu trữ cùng nhau theo cơ chế xen lẫn).

Lợi ích thực sự của đồng-phân-cụm được minh hoạ trong truy vấn sau:

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

Giả sử rằng có rất nhiều Part có cost=10 Truy vấn này về bản chất sẽ đưa ra một tập cácbản ghi của Parts và các bản ghi tương ứng của Assembly Nếu chúng ta có một chỉ mụcnào đó trên trường cost của Parts, chúng ta có thể truy cập các bộ giá trị thoả mãn củaParts Với mỗi bộ giá trị, chúng ta phải sử dụng chỉ mục này trên Assembly để xác định

vị trí các bản ghi có pid đã biết Nếu chúng ta sử dụng tổ chức đồng-phân-cụm chúng

ta có thể tránh được chỉ mục này trên Assembly (Tất nhiên, vẫn cần một chỉ mục trênthuộc tính cost của Parts)

Như vậy tối ưu hoá đặc biệt quan trọng khi chúng ta muốn duyệt qua một vài mức của

phân cấp sản phẩm-sản phẩm con (part-subpart) Ví dụ, một truy vấn phổ biến là tìm

tổng giá thành của một sản phẩm nào đó, truy vấn này yêu cầu chúng ta thực hiện lặp đilặp lại kết nối giữa Parts và Assembly Thêm nữa, chúng ta có thể không biết số lượngcác mức trong phân cấp, số lượng các kết nối khác nhau và truy vấn này không thểđược biểu diễn trong SQL Truy vấn này có thể được thực hiện bằng cách kết hợp sửdụng ngôn ngữ lập trình Như vậy, đồng-phân-cụm mang lại những lợi ích đặc biệt trongtrường hợp một kết nối nào đó thường xuyên được thực hiện

Tổng kết về đồng-phân-cụm:

• Nó có thể làm tăng tốc độ các kết nối, cụ thể là các kết nối khoá-khoá ngoại

tương ứng với mối liên kết 1:N:

• Việc quét tuần tự một trong hai quan hệ trở nên chậm hơn (Trong ví dụ củachúng ta, vì một số bộ giá trị của Assembly được lưu trữ giữa các bộ giá trịParts kề nhau, nên việc quét tất cả các bộ giá trị của Parts trong trường hợp nàychậm hơn khi nó được lưu trữ tách rời Tương tự, việc quét tuần tự tất cả các bộgiá trị của Assembly cũng chậm hơn)

• Tất cả các thao tác thêm, xoá, và cập nhật làm biến đổi chiều dài bản ghi cũngchậm hơn do phải duy trì việc phân cụm (Chúng ta không bàn về các vần đềthực thi của đồng-phân-cụm ở đây)

Các chỉ mục có thể sử dụng trong kế hoạch chỉ-chỉ-số

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ựchiệ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 WHERED.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ớiDepartments là quan hệ phía bên ngoài), nhưng nếu chỉ mục này không được phân cụmthì 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

Các công cụ hỗ trợ việc lựa chọn chỉ mục

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ủacá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ụcngà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ôngkhả 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ệcphả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ựngcho 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ươngmạ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ớitập các chỉ mục của nó, tránh được việc phải sao chép lại như ở trên

Lựa chọn chỉ mục tự động

Chúng ta gọi tập các chỉ mục của một lược đồ cơ sở dữ liệu là một cấu hình chỉ mục.

Giả sử rằng một luồng truy vấn là một tập các truy vấn trên một lược đồ cơ sở dữ liệu.Cho một lược đồ cơ sở dữ liệu và một luồng công việc, giá của một cấu hình chỉ mục làgiá phải trả để thực thi những truy vấn này Cho một lược đồ cơ sở dữ liệu và một luồngtruy vấn, bây giờ chúng ta có thể định nghĩa vấn đề lựa chọn chỉ mục tự động chính làviệc tìm ra một cấu hình chỉ mục có giá thành thực thi nhỏ nhất

Vì sao lựa chọn chỉ mục tự động là một vấn đề khó? Hãy cùng chúng tôi tính toán sốlượng các chỉ mục khác nhau cùng với c thuộc tính, giả sử rằng bảng này có n thuộctính Với thuộc tính đầu tiên trong chỉ mục này, có n lựa chọn, với thuộc tính thứ hai cón-1 thuộc tính, vì thế với thuộc tính thức ta sẽ cón.(n − 1) (n − c + 1) = (n − c)! n! lựa chọn.Tổng số các chỉ mục khác nhau với c thuộc tính là:∑i = 1 c (n − 1)! n!

Với một bảng có 10 thuộc tính sẽ có 10 chỉ mục khác nhau có 1 thuộc tính, 90 chỉ mụckhác nhau có hai thuộc tính, và 30240 chỉ mục khác nhau có 5 thuộc tính Với các luồngcông việc phức tạp bao gồm hàng trăm bảng, số lượng các cấu hình chỉ mục rõ ràng sẽrất lớn

Hiệu quả của các công cụ lựa chọn chỉ mục tự động có thể được đánh giá bởi hai yếu tố:(1) số lượng các cấu hình chỉ mục dự tuyển được xem xét, và (2) số lượng các bộ tối ưucần gọi đến để ước lượng giá của một cấu hình Ghi nhớ rằng việc giảm không gian tìmkiếm của các chỉ mục dự tuyển tương ứng với việc giới hạn không gian tìm kiếm của bộtối ưu hoá truy vấn với các kế hoạch sâu-trái (deep-left) Trong rất nhiều trường hợp, kếhoạch tốt nhất không phải là kế hoạch sâu-trái, nhưng trong tất cả các kế hoạch sâu-tráithường có một kế hoạch có giá gần bằng kế hoạch tốt nhất

Chúng ta có thể dễ dàng giảm thời gian lựa chọn chỉ mục tự động bằng cách giảm sốlượng các cấu hình chỉ mục dự tuyển, hoặc chỉ xem xét các chỉ mục có một hoặc haithuộc tính.

Lựa chọn chỉ mục tự động làm việc như thế nào?

Lựa chọn chỉ mục tự động tìm ra một tập các chỉ mục là ứng cử viên cho một cấu hìnhchỉ mục có chi phí thấp nhất Chúng tôi trình bày một thuật toán tiêu biểu; những công

cụ thực thi đang tồn tại là biến thể của thuật toán này, nhưng sự thực hiện của chúng cócùng cấu trúc cơ bản

Trước khi trình bày thuật toán lựa chọn chỉ mục, chúng ta sẽ cùng xem xét vấn đề ướclượng giá của một cấu hình chỉ mục nào đó Ghi nhớ rằng sẽ không khả thi nếu tạo ramột tập các chỉ mục cho một cấu hình ứng cử viên và sau đó tối ưu truy vấn dựa vào cáccấu hình này Việc tạo ra dù chỉ một cấu hình ứng cử viên có một vài chỉ mục cũng cóthể mất hàng giờ đối với các cơ sở dữ liệu lớn Vì thế, kiểm tra một số lượng lớn các cấuhình ứng cử viên có khả năng là cách tiếp cận không khả thi

Bây giờ chúng tôi trình bày một thuật toán lựa chọn chỉ mục điển hình Thuật toán này

có hai bước, lựa chọn chỉ mục ứng cử viên và liệt kê cấu hình Trong bước đầu tiên,

chúng ta lựa chọn một tập các chỉ mục ứng cử viên để xem xét trong toàn bộ bước hai,sau đó bước hai sẽ xây dựng các khối của các cấu hình chỉ mục Hãy cùng chúng tôitrình bày hai bước này chi tiết hơn

Cố vấn chỉ mục của DB2 Cố vấn chỉ mục của DB2 là một công cụ giúp đề cử các chỉmục một cách tự động cho một luồng công việc Luồng công việc này được lưu trữ trongmột bảng gọi là ADVISE_WORKLOAD của hệ thống cơ sở dữ liệu Cố vấn chỉ mụccủa DB2 cho phép người dùng chỉ định dung lượng tối đa của khoảng trống đĩa cho cácchỉ mục mới và khoảng thời gian tối đa cho việc tính toán một cấu hình chỉ mục

Cố vấn chỉ mục của DB2 có một chương trình giúp tìm kiếm tập con của các cấu hìnhchỉ mục một cách thông minh Cho một cấu hình chỉ mục ứng cử viên, nó gọi tới bộtối ưu hoá truy vấn ứng với mỗi truy vấn trong bảng ADVISE_WORKLOAD ở chế độRECOMMEND_INDEXES, ở chế độ này bộ tối ưu hoá đề cử một tập các chỉ mục vàlưu chúng trong bảng ADVISE_INDEXES (các chỉ mục khuyên dùng) Trong chế độEVALUATE_INDEXES, bộ tối ưu hoá đánh giá lợi ích của các cấu hình chỉ mục nàyứng với mỗi truy vấn trong bảng ADVISE-WORKLOAD Đầu ra của bước lựa chọn chỉmục là các câu lệnh SQL DDL cho phép tạo ra các chỉ mục đề cử

Chọn chỉ mục tự động của Microsoft SQL Server 2000 Microsoft là hãng đi tiên phongtrong việc tích hợp chọn chỉ mục tự động với bộ tối ưu hoá truy vấn Công cụ này có

ba chế độ cho phép người dùng thoả thuận giữa thời gian phân tích và số lượng các cấuhình chỉ mục ứng cử viên được kiểm tra: nhanh, trung bình và trọn vẹn, trong đó cấu

hình nhanh có thời gian phân tích ít nhất và cấu hình trọn vẹn có số lượng các cấu hìnhnhiều nhất Các tham số khác bao gồm khoảng không tối đa cấp cho các chỉ mục đề cử,

số lượng tối đa các thuộc tính của mỗi chỉ mục, và các bảng có thể sử dụng các chỉ mụcnày Công cụ này cho phép co giãn bảng, người dùng có thể xác định số lượng các bảnghi của bảng sẽ cần trong luồng công việc Điều này cho phép người dùng lập kế hoạchphát triển các bảng trong tương lai

Lựa chọn chỉ mục ứng cử viên

Chúng ta đã nhìn thấy trong phần trước là không thể xem xét tất cả các chỉ mục có khảnăng, do có một số lượng quá lớn các ứng cử viên chỉ mục trong một lược đồ cơ sở dữliệu lớn Một cách làm ở đây là tỉa không gian rất lớn các chỉ mục có khả năng của mỗitruy vấn trong luồng công việc một cách độc lập, sau đó phép hợp của các chỉ mục đượcchọn trong bước đầu tiên này sẽ là đầu vào của bước thứ hai

Với một truy vấn, hãy cùng chúng tôi tìm hiểu về khái niệm của một thuộc tính có khảnăng làm chỉ mục, đó là thuộc tính mà sự xuất hiện của nó trong một chỉ mục có thểlàm thay đổi giá của truy vấn Thuộc tính có khả năng làm chỉ mục là thuộc tính nằmtrong mệnh đề WHERE của truy vấn có điều kiện hoặc trong mệnh đề GROUP BY hoặcORDER BY của truy vấn SQL Một chỉ mục có thể được chấp nhận cho một truy vấnnào đó là một chỉ mục chứa các thuộc tính có khả năng làm chỉ mục trong truy vấn đó

Chúng ta chọn các chỉ mục ứng cử viên cho một truy vấn cụ thể nào đó như thế nào?Một cách tiếp cận là liệt kê tất cả các chỉ mục của k thuộc tính Chúng ta bắt đầu vớiviệc chọn tất cả các thuộc tính đơn đều là chỉ mục ứng cử viên, sau đó là sự kết hợp củahai chỉ mục, và lặp cho đến khi đạt đến kích thước k do người dùng định nghĩa Thủ tụcnày rất tốn kém vì chúng ta sẽ cón + n.(n − 1) + +n.(n − 1) (n − k + 1)chỉ mục ứng cửviên Những tài liệu tham khảo ở cuối chương này trình bày về các thuật toán tìm kiếmheuristical nhanh hơn (nhưng không trọn vẹn bằng)

Liệt kê các cấu hình chỉ mục

Trong bước thứ hai, chúng ta sử dụng các chỉ mục ứng cử viên để liệt kê các cấu hìnhchỉ mục Như ở bước thứ nhất, chúng ta có thể liệt kê toàn bộ tất cả các cấu hình chỉmục có kích thước k Như trình bày ở phía trước, các chiến lược tìm kiếm phức tạp cóthể làm giảm số lượng các cấu hình trong khi vẫn đưa ra được một cấu hình cuối cùng

có chất lượng cao

Tổng quan về điều chỉnh cơ sở dữ liệu

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 cungcấ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íchthướ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 mongmuố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ụngmộ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ựcthi 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

Điều chỉnh chỉ mục

Những lựa chọn chỉ mục ban đầu có thể phải điều chỉnh vì một số lý do Lý do đơn giảnnhất là luồng công việc chứa một số truy vấn và các cập nhật được coi là quan trọngtrong thiết kế ban đầu nhưng trên thực tế nó lại không xuất hiện thường xuyên Luồngcông việc thực tế quan sát được bây giờ cũng có thể chứa một số truy vấn mới và cáccập nhật quan trọng Những lựa chọn chỉ mục ban đầu phải được điều chỉnh lại dựa vàonhững thông tin mới này Một số chỉ mục ban đầu có thể phải xoá đi và thêm vào đómột số chỉ mục mới

Chúng ta cũng khám phá ra rằng bộ tối ưu hoá trong một hệ thống nào đó không tìm rađược các kế hoạch như ta mong muốn Ví dụ, xem xét truy vấn sau, truy vấn này chúng

ta đã bàn luận ở trên:

SELECT D.mgr FROM Employees E, Departments D WHERE

D.dname= ‘Toy’ AND E.dno=D.dno

Một kế hoạch tốt ở đây là sử dụng một chỉ mục trên dname để truy cập các bộ giá trị của Departments có dname ='Toy' và thực hiện quét chỉ-chỉ-số trên chỉ mục của trường dno của Employees Chúng ta nhận thấy rằng bộ tối ưu hoá sẽ tìm ra được một kế hoạch như vậy, nên chúng ta có thể tạo ra một chỉ mục không phân cụm trên trường dno của

Employees

Bây giờ giả sử thực hiện các truy vấn dạng này mất một thời gian rất lâu Chúng ta có thểyêu cầu hệ thống cho xem các kế hoạch mà bộ tối ưu hoá đã chọn (Hầu hết các hệ thốngthương mại cung cấp một lệnh đơn giản để làm điều này) Nếu các kế hoạch không sửdụng quét chỉ-chỉ-số (do những hạn chế của hệ thống gây ra), thì trừ phi những bộ giá trịcủa Employees đang được truy cập, còn không chúng ta phải xem xét lại việc lựa chọnchỉ mục ban đầu Trong trường hợp này, chúng ta phải xoá chỉ mục không phân cụm

trên trường dno của Employees và thay thế nó bằng một chỉ mục được phân cụm.

Một vài hạn chế phổ biến của các bộ tối ưu hoá là nó không thực hiện tốt các phép chọn

có chứa các biểu thức xâu ký tự, số học, và các giá trị rỗng Chúng ta sẽ bàn luận sâuhơn về vấn đề này trong nội dung điều chỉnh truy vấn ở Phần 9 Hơn nữa, việc kiểm tralại các lựa chọn chỉ mục có thể giúp chúng ta tổ chức lại một số chỉ mục trước Ví dụ,một chỉ mục tĩnh, như chỉ mục ISAM có thể sinh ra các chuỗi tràn dài Việc xoá các chỉmục này và xây dựng lại nó- nếu khả thi, cung cấp các truy cập ngắt quãng tới quan hệđược chỉ mục- do đó có thể cải thiện được thời gian truy cập thông qua chỉ mục này Đốivới cấu trúc động như là B+tree, nếu quá trình thực thi không tiến hành trộn các trang đã

bị xoá, không gian bị chiếm có thể tăng lên đáng kể trong một số trường hợp Điều nàylàm kích thước của chỉ mục này (trong các trang) lớn hơn cần thiết, và có thể làm tăngthời gian truy cập Việc xây dựng lại chỉ mục này nên được xem xét Các phép cập nhậtphạm vi tới một chỉ mục phân cụm nào đó có lẽ cùng dẫn đến phải sử dụng các trangtràn, vì thế chúng ta nên cố gắng giảm bậc của phân cụm Khẳng định thêm một lần nữa,việc xây dựng lại chỉ mục là việc nên làm

Cuối cùng, ghi nhớ rằng tối ưu hoá truy vấn được cân nhắc dựa vào các thống kê thực

tế trong các danh mục hệ thống Những thống kê này được cập nhật chỉ khi một chươngtrình tiện ích đặc biệt đang chạy; vì thế phải đảm bảo rằng các tiện ích này được chạymột cách thường xuyên đủ để duy trì những thống kê này một cách hợp lý

Điều chỉnh lược đồ khái niệm

Trong các khoá học về thiết kế cơ sở dữ liệu, chúng ta đã được biết rằng lược đồ quan hệđược xây dựng ban đầu có thể không phù hợp với các mục đích thực thi của các luồngcông việc Vì thế, chúng ta có thể phải thiết kế lại lược đồ khái niệm (và những quyếtđịnh liên quan đến thiết kế vật lý cũng phải kiểm tra lại)

Chúng ta cũng biết rằng việc thiết kế lại là cần thiết trong suốt quá trình thiết kế ban đầuhoặc sau đó, khi mà hệ thống đã đi vào sử dụng Khi một cơ sở dữ liệu đã được thiết kế

và đã có chứa dữ liệu, việc thay đổi lược đồ khái niệm dẫn đến việc phải thay đổi nộidung của các quan hệ có liên quan Bây giờ chúng ta xem xét các vấn đề của thiết kế lạilược đồ đứng trên quan điểm thực thi

Một điểm quan trọng cần hiểu là việc lựa chọn lược đồ khái niệm nên dựa vào việc xem xét các truy vấn và các cập nhật nào có trong luồng công việc của chúng ta, và các vấn

đề liên quan đến dư thừa dữ liệu (chúng ta đã bàn đến trong Chương 19) Có một sốcông việc phải được xem xét trong khi tiến hành điều chỉnh lược đồ khái niệm:

• Chúng ta cân nhắc xem các quan hệ nên ở 3NF thay vì BCNF không

• Nếu có hai cách để phân rã một lược đồ quan hệ về 3NF hoặc BCNF, lựa chọncách nào sẽ phụ thuộc vào các luồng công việc

• Đôi khi chúng ta có lẽ muốn tiếp tục phân rã một quan hệ đã ở BCNF

• Trong những trường hợp khác, chúng ta có lẽ muốn thực hiện phi chuẩn Tức

là, chúng ta thay thế một tập các quan hệ đã được phân rã từ một quan hệ lớnhơn bằng chính quan hệ ban đầu (khi chưa phân rã), mặc dù như vậy có thểphải chấp nhận các vấn đề dư thừa Thêm nữa, chúng ta có lẽ lựa chọn việcthêm một số trường vào quan hệ hiện tại để tăng tốc độ một số truy vấn quantrọng, mặc dù điều này sẽ dẫn đến việc lưu trữ dư thừa thông tin (và cuối cùng

là lược đồ này không ở 3NF cũng không ở BCNF)

• Những trình bày về chuẩn hoá này đã được nói đến như là công nghệ phân rã,tức là phân chia một quan hệ theo chiều dọc Công nghệ khác cũng đã được đềcập là phân rã quan hệ theo chiều ngang, công nghệ này sẽ tạo ra hai quan hệ

có cùng lược đồ Lưu ý rằng ở đây chúng ta không nói về việc phân chia vật lýmột quan hệ nào đó; mà là chúng ta muốn tạo ra hai quan hệ riêng biệt (có thểchứa các ràng buộc và các chỉ mục khác nhau trên mỗi quan hệ)

Thêm nữa, khi chúng ta thiết kế lại lược đồ khái niệm, đặc biệt nếu chúng ta điều chỉnhmột lược đồ cơ sở dữ liệu đang tồn tại, việc xem xét xem chúng ta có nên tạo lại cáckhung nhìn cho người dùng là nên làm Chúng tôi trình bày những lựa chọn của điềuchỉnh lược đồ khái niệm trong Phần 8

Điều chỉnh truy vấn và khung nhìn

Nếu thấy truy vấn đang chạy chậm hơn mong muốn, thì chúng ta nên kiểm tra lại truyvấn một cách cẩn thận để tìm ra nguyên nhân Đôi khi viết lại truy vấn cùng với việcthực hiện một số điều chỉnh chỉ mục có thể giải quyết được vấn đề này Tương tự, điềuchỉnh có thể được thực hiện nếu các truy vấn trên một số khung nhìn chạy chậm hơnmong muốn Chúng tôi không bàn về điều chỉnh khung nhìn một cách tách biệt mà xemxét các truy vấn trong các khung nhìn đó và tìm cách điều chỉnh chúng

Khi điều chỉnh một truy vấn, điều đầu tiên là kiểm tra xem hệ thống có sử dụng các

kế hoạch thực hiện nó như bạn mong muốn không Có thể vì nhiều lý do mà hệ thốngkhông tìm được kế hoạch tốt nhất Một vài trường hợp sau đây không được nhiều bộ tối

ưu hoá quản lý hiệu quả:

• Truy vấn có một điều kiện chọn bao gồm các giá trị rỗng.

• Các điều kiện chọn bao gồm các biểu thức số học, xâu ký tự hoặc các điều kiện

chọn sử dụng phép OR Ví dụ, nếu chúng ta có một điều kiện chọn là E.age = 2*D.age trong mệnh đề WHERE, bộ tối ưu hoá có thể sử dụng một cách đúng đắn chỉ mục trên E.age nhưng sử dụng không đúng chỉ mục trên D.age Thay thế điều kiện này bằng điều kiện E.age/2 = D.age sẽ giải quyết được vấn đề

này

• Không có khả năng nhận ra một kế hoạch phức tạp như quét chỉ-chỉ-số trên mộttruy vấn có mệnh đề GROUP BY Tất nhiên, hầu như không có bộ tối ưu nàotìm kiếm các kế hoạch bên ngoài các kế hoạch đã trình bày trong Chương 12 và

15, như là các cây liên kết sâu-không-trái (nonleft-deep join trees) Vì thế, việcquan trọng là phải hiểu được các bộ tối ưu hoá điển hình sẽ thực hiện những gì.Thêm nữa, tốt hơn nữa là bạn cũng nên tìm hiểu về những ưu điểm và hạn chếcủa hệ thống mà bạn sử dụng.

Nếu bộ tối ưu hoá không đủ thông minh để tìm ra được kế hoạch tốt nhất (sử dụng cácphương thức truy cập và các chiến lược đánh giá do DBMS hỗ trợ), một vài hệ thốngcho phép người dùng hướng dẫn việc chọn kế hoạch bằng việc cung cấp các lời gợi ýcho bộ tối ưu hoá; ví dụ, người dùng có thể yêu cầu sử dụng một chỉ mục cụ thể nào

đó hoặc chọn thứ thự kết nối và phương thức kết nối Tất nhiên, người dùng cung cấpcác hướng dẫn cho bộ tối ưu phải là người có hiểu biết về cả tối ưu hoá và khả năng củaDBMS mà mình sử dụng Chúng ta sẽ bàn thêm về tối ưu hoá truy vấn trong Phần 9

Các lựa chọn trong điều chỉnh lược đồ khái niệm

Bây giờ chúng ta minh hoạ các lựa chọn có thể có trong điều chỉnh lược đồ khái niệmthông qua một vài ví dụ sử dụng lược đồ sau:

Contracts(cid: integer, supplierid: integer, projectid: integer, deptid: integer, partid: integer, qty: integer, value: real)

Departments(did: integer, budget: real, annualreport: varchar)

Parts(pid: integer, cost: integer)

Projects(jid: integer, mgr: char(20))

Suppliers(sid: integer, address: char(50))

Để ngắn gọn, chúng ta chỉ viết tắt một thuộc tính nào đó bằng một ký tự Xem xét lược

đồ của quan hệ Contracts, lược đồ này được gọi tắt bằng CSJDPQV Ý nghĩa của một

bộ giá trị trong quan hệ này là: một hợp đồng (C) cùng với cid là sự thoả thuận của nhà cung cấp S (với sid bằng supplierid) sẽ cung cấp Q sản phẩm của mặt hàng P (với pid bằng partid) cho dự án J (với jid bằng projectid) quản lý bởi phòng D (với deptid bằng did), và giá trị V bằng value.

Có hai ràng buộc toàn vẹn đối với Contracts Một dự án mua một mặt hàng nào đó sửdụng chỉ một hợp đồng; vì thế sẽ không có hai hợp đồng cho cùng một dự án mua cùng

một mặt hàng Ràng buộc này được biểu diễn bằng FD JP → C Tương tự, một phòng

nào đó mua nhiều nhất là một mặt hàng từ một nhà cung cấp Ràng buộc này được biểu

diễn bằng FD SD→P Thêm nữa, tất nhiên là contract ID C là một khoá Ý nghĩa của

những quan hệ khác nên được làm rõ, và chúng ta không trình bày chi tiết ở đây vì chúng

ta chỉ tập trung vào quan hệ Contracts

Cân nhắc lựa chọn dạng chuẩn thấp hơn

Xem xét quan hệ Contracts Có nên phân rã nó thành các quan hệ nhỏ hơn? Hãy cùngchúng tôi xem xem nó đang ở dạng chuẩn nào Các khoá dự tuyển của quan hệ này là C

và JP (C là một khoá, và JP là phụ thuộc hàm xác định C) Chỉ có một phụ thuộc hàm

không-khóa là SD→P, và P là thuộc tính prime vì nó là một phần của khoá dự tuyển JP.

Vì thế, quan hệ này không ở BCNF- vì có một phụ thuộc hàm không-khóa, nhưng nó ở3NF

Bằng việc sử dụng phụ thuộc hàm SD→P để định hướng việc phân rã, chúng ta có hailược đồ SDP và CSJDQV Phân rã này không mất mát thông tin, nhưng nó không bảotoàn phụ thuộc hàm Tuy nhiên, bằng cách thêm một lược đồ quan hệ là CJP, chúng ta

sẽ có được phép phân rã thành BCNF không mất mát thông tin và bảo toàn phụ thuộchàm Sử dụng cách phân rã này là hiệu quả, chúng ta thay thế Contracts bằng ba lược đồquan hệ là CJP, SDP, và CSJDQV

Tuy nhiên, giả sử rằng truy vấn sau được yêu cầu thực hiện thường xuyên: Tìm số lượngcác sản phẩm Q của mặt hàng P trong hợp đồng C Truy vấn này yêu cầu kết nối haiquan hệ đã phân rã là CJP và CSJDQV (hoặc SDP và CSJDQV), ngược lại nó có thểđược trả lời một cách trực tiếp sử dụng quan hệ Contracts Giá phải trả cho truy vấn này

sử dụng lược đồ quan hệ ở 3NF tốt hơn nhiều so với sử dụng các lược đồ ở BCNF

Phi chuẩn hoá

Các lý do chính thúc đẩy lựa chọn dạng chuẩn thấp hơn dẫn chúng ta đến việc tìm hiểumục này: một số dạng phi chuẩn Như ví dụ trên, xem xét quan hệ Contracts- ở 3NF.Bây giờ, giả sử rằng có một truy vấn thường xuyên được yêu cầu là kiểm tra giá trịcủa một hợp đồng xem có thấp hơn số tiền mà Phòng đặt hàng đang có trong ngân quỹ

không Chúng ta có thể quyết định để thêm một trường là ngân sách (bugget) B cho quan

hệ Contracst Vì did là một khóa của Departments, bây giờ chúng ta có một phụ thuộc hàm là D → B trong Contracts, như vậy là Contracts không còn ở 3NF nữa Tuy nhiên,

chúng ta có thể quyết định thiết kế ở dạng này nếu mục đích về hiệu quả thực thi đượcđặt cao hơn Như vậy quyết định này mang tính chủ quan và nó làm cho dư thừa dữ liệutăng lên đáng kể

Lựa chọn của việc phân rã

Xem xét lại quan hệ Contracts Có một số lựa chọn có thể được sử dụng để giải quyết

dư thừa trong quan hệ này:

• Chúng ta có thể cho phép quan hệ Contracts ở dạng chuẩn ba và chấp nhận dưthừa sẽ tốt hơn là đưa quan hệ về BCNF

• Chúng ta có thể quyết định rằng chúng ta không muốn có những dị thường dữliệu sinh ra do dư thừa, vì thế chúng ta phân rã Contracts thành các quan hệ ởBCNF sử dụng một trong những cách sau:

• Thực hiện một phân rã không mất kết nối chia quan hệ Contracts thành haiquan hệ PartInfo có các thuộc tính SDP và quan hệ Contractlnfo có các thuộctính CSJDQV Như đã nói ở trên, phân rã này không bảo toàn phụ thuộc hàm,

và để có được điều này chúng ta sẽ phải thêm vào một quan hệ thứ ba là CJP,mục đích duy nhất của việc thêm quan hệ này là để bảo toàn phụ thuộc hàm

JP→ C.

• Chúng ta có thể chọn cách thay thế quan hệ Contracts bằng hai quan hệ

PartInfo và ContractInfo ngay cả khi việc phân rã này không bảo toàn phụthuộc hàm

Việc thay thế Contracts chỉ bằng PartInfo và ContractInfo không ngăn cản chúng ta thiết

lập được ràng buộc JP → C Chúng ta có thể tạo ra một xác nhận bằng SQL-92 để kiểm

tra ràng buộc này như sau:

CREATE ASSERTION checkDep CHECK ( NOT EXISTS ( SELECT *FROM PartInfo PI, ContractInfo CI WHERE

PI.supplierid=CI.supplierid AND CI.deptid=Cl.deptid GROUP

BY CI.projectid, PI.partid HAVING COUNT (cid) > 1 ) )

Xác nhận này có hiệu quả cao vì nó bao gồm một liên kết đằng sau một sắp xếp Hệthống có thể kiểm tra JP là một khoá chính của quan hệ CJP bằng cách duy trì một chỉmục trên JP Giá để xác nhận ràng buộc này rẻ hơn so với giá duy trì phụ thuộc hàm.Mặt khác, nếu các phép cập nhật thường xuyên xảy ra, giá phải trả cho việc thực hiện nó

có thể chấp nhận được; vì thế, chúng ta có lẽ không nên duy trì bảng CJP (và tất nhiên

là cả chỉ mục trên nó)

Một ví dụ khác minh hoạ các lựa chọn khi phân rã, xem xét lại quan hệ Contracts, và giả

sử chúng ta có một ràng buộc toàn vẹn là SPQ→ V.

Tiếp tục phía trên, chúng ta có một phân rã không mất kết nối của quan hệ Contracts

thành SDP và CSJDQV Chúng ta có thể bắt đầu bằng việc sử dụng phụ thuộc hàm SPQ

→ V để định hướng phân rã, và thay thế Contracts bằng SPQV và CSJDPQ Sau đó chúng ta có thể phân rã CSJDPQ thành SDP và CSJDQ do có phụ thuộc hàm SD → P.

Bây giờ chúng ta có hai lựa chọn phân rã không mất kết nối thành BCNF cho quan hệContracts, không có cách nào trong hai lựa chọn trên bảo toàn phụ thuộc hàm Lựa chọnđầu tiên là thay thế Contracts bằng hai quan hệ SDP và CSJDQV Lựa chọn thứ hai làthay thế bằng SPQV, SDP, và CSJDQ Thêm một quan hệ là CJP sẽ làm cho phân rãthứ hai (không phải là phân rã đầu tiên) bảo toàn phụ thuộc hàm Giá của việc duy trì baquan hệ CJP, SPQV, và CSJDQ (ngược lại với chỉ CSJDQV) có thể dẫn chúng ta đến