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ồng cô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ập nhậ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 được cậ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ứa cá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ột lượ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ại cá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ốn quan 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ấn chỉ 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ững thay đổ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ệc là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ốt nhấ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ính chấ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ệm ban đầ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ấu giữ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ựa chọ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.

Đồ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ải thí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ường chỉ 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ủa nhiề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ụm củ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ể mang lạ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ản phẩ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ẩm con của tất cả các sản phẩm do một nhà sản xuất nào đó cung cấp:

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ản ghi 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à hai hoặ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ơi lư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:

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ác bả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ục nà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ủa Parts. 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ên thuộ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 đi lặ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ượng cá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 trong trườ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ủa chú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ày chậ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ũng chậ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).

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ồng truy 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ộc tí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\text{.}(n-1)\text{.}\text{.}\text{.}(n-c+1)=\frac{n!}{(n-c)!}$ lựa chọn. Tổng số các chỉ mục khác nhau với c thuộc tính là: $\sum _{i=1}^c\frac{n!}{(n-1)!}$

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ục khá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ồng cô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 ưu cầ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ìm kiế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ái thườ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 hai thuộ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ình chỉ 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 đề ước lượ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 ra mộ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ác cấ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ấu hì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ôi trình bày hai bước này chi tiết hơn.

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ỗi truy 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 được chọ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ằm trong mệnh đề WHERE của truy vấn có điều kiện hoặc trong mệnh đề GROUP BY hoặc ORDER BY của truy vấn SQL. Một chỉ mục có thể được chấp nhận cho một truy vấn nà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ới việ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ủa hai 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ục này rất tốn kém vì chúng ta sẽ có $n+n\text{.}(n-1)+\text{.}\text{.}\text{.}+n\text{.}(n-1)\text{.}\text{.}\text{.}(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ếm heuristical 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ình chỉ 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.

Đ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ản nhấ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ọng trong 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ồng cô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ác cậ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ào nhữ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:

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ống thươ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ọn chỉ 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âu hơ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 tra lạ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. Đối vớ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ày là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ăng thờ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ật phạ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 trang trà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ương trì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ạy mộ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ồng cô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 đầu hoặ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ội dung 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ại lượ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ọn cá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ớn hơ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ệc thêm một số trường vào quan hệ hiện tại để tăng tốc độ một số truy vấn quan trọ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ỉnh mộ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ác khung 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ều chỉ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 truy vấ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ệc thự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ều chỉ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ơn mong 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à xem xé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ống khô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ột truy vấn có mệnh đề GROUP BY. Tất nhiên, hầu như không có bộ tối ưu nào tì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ệc quan 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ác phươ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ống cho 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ấp cá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ủa DBMS 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â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ùng chú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ó hai lược đồ SDP và CSJDQV. Phân rã này không mất mát thông tin, nhưng nó không bảo toà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ộc hà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ượng cá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 hai quan 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ểu mụ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ệu tă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 hai quan hệ PartInfo có các thuộc tính SDP và quan hệ Contractlnfo có các thuộc tí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:

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ì ba quan hệ CJP, SPQV, và CSJDQ (ngược lại với chỉ CSJDQV) có thể dẫn chúng ta đến việc lựa chọn phân rã đầu tiên. Trong trường hợp này, thiết lập các FDs trở nên cần thiết. Chúng ta có thể không làm điều này, nhưng nếu vậy chúng ta sẽ gặp những vi phạm ràng buộc trên dữ liệu.

Phân rã theo chiều dọc các quan hệ BCNF

Giả sử rằng chúng ta đã quyết định phân rã Contracts thành SDP và CSJDQV. Các lược đồ này đều ở BCNF, và không có lý do gì để tiếp tục phân rã chúng đứng trên quan điểm chuẩn hoá. Tuy nhiên, giả sử rằng các truy vấn sau đây thường xuyên được yêu cầu:

• Tìm các hợp đồng có nhà cung cấp là S.
• Tìm các hợp đồng do phòng D đặt.

Những truy vấn này có lẽ dẫn chúng ta đến việc phân rã CSJDQV thành CS, CD, và CJQV. Phân rã này không mất mát thông tin và hai truy vấn quan trọng này có thể được thực hiện bằng cách kiểm tra các quan hệ nhỏ hơn. Lý do khác để xem xét phân rã này là điều khiển tương tranh các hot spots. Nếu những truy vấn này phổ biến, và các cập nhật phổ biến nhất bao gồm thao tác thay đổi số lượng của các mặt hàng (và giá trị) trong các hợp đồng, phân rã này sẽ cải thiện được khả năng thực thi của hệ thống bằng cách giảm sự cạnh tranh khoá. Bây giờ, các khoá loại trừ được thiết đặt trên bảng CJQV là chủ yếu, và việc đọc trên CS và CD không xung đột với những khoá này.

Bất cứ khi nào chúng ta phân rã một quan hệ, chúng ta phải xem xét các truy vấn bị ảnh hưởng do việc phân rã này gây ra, đặc biệt là khi phân rã chỉ nhằm mục đích cải thiện khả năng thực thi của hệ thống. Ví dụ, nếu một truy vấn quan trọng khác là tìm tổng giá trị của các hợp đồng liên quan đến một nhà cung cấp nào đó, truy vấn này yêu cầu phải kết nối các quan hệ phân rã là CS và CJQV. Trong trường hợp này, chúng ta nên quyết định là không phân rã.

Phân rã theo chiều ngang

Phần trước chúng ta xem xét cách thay thế một quan hệ bằng một tập các quan hệ được phân rã theo chiều dọc. Đôi khi, chúng ta nên phân rã một quan hệ theo chiều ngang, tức là chia một quan hệ thành hai quan hệ có cùng thuộc tính như quan hệ gốc, mỗi quan hệ chứa một tập con các bộ giá trị của quan hệ gốc. Công nghệ này hữu ích khi các tập con này được truy vấn theo những cách rất khác nhau.

Ví dụ, có những luật khác nhau áp dụng cho các hợp đồng lớn, những hợp đồng mà giá trị của nó lớn hơn 10,000. (Có thể những hợp đồng này phải được nhận thông qua đấu giá). Ràng buộc này có thể đưa đến một số truy vấn trên Contracts sử dụng điều kiện value > 10,000. Một cách tiếp cận tình trạng này là xây dựng một chỉ mục B+tree phân cụm trên trường value của Contracts. Một lựa chọn nữa là chúng ta thay thế Contracts bằng hai quan hệ gọi là LargeContracts và SmallContracts, với ý nghĩa như trên.

Nếu chúng ta thay thế Contracts bằng hai quan hệ LargeContracts và SmallContracts, chúng ta có thể tạo mặt nạ cho những thay đổi này bằng cách định nghĩa một khung nhìn gọi là Contracts:

Tuy nhiên, với các truy vấn có thể thực hiện được chỉ cần LargeContracts thì chỉ cần truy cập trực tiếp trên LargeContracts mà không phải trên khung nhìn. Thực hiện các truy vấn này trên khung nhìn Contracts với điều kiện chọn là value > 10,000 sẽ có kết quả tương đương với việc thực hiện nó trên LargeContracts nhưng không hiệu quả bằng.

Một ví dụ khác, nếu Contracts có một trường year (năm) và các truy vấn thường phải đối mặt với các hợp đồng trong một năm nào đó, chúng ta có thể lựa chọn phân vùng Contracts theo năm. Tất nhiên, các truy vấn liên quan đến các hợp đồng của nhiều hơn một năm, chúng ta sẽ phải thực hiện truy vấn liên quan đến năm đó trên từng quan hệ đã được phân rã.

Giảm khoảng thời gian khoá

Làm trễ các yêu cầu khoá: Điều chỉnh các giao dịch bằng cách viết lại một số biến chương trình địa phương và trì hoãn các thay đổi đối với cơ sở dữ liệu cho đến khi kết thúc giao dịch. Điều này làm giảm được thời gian khoá của giao dịch.

Làm các giao dịch trở nên nhanh hơn: Các giao dịch càng hoàn thành sớm thì các khoá của nó càng được giải phóng sớm. Chúng ta đã bàn về một số cách để tăng tốc độ của truy vấn và các lệnh cập nhật (ví dụ, điều chỉnh các chỉ mục, viết lại các truy vấn). Thêm nữa, việc phân vùng cẩn thận các bộ giá trị trong một quan hệ và những chỉ mục liên quan của nó trên một tập hợp các đĩa có thể cải thiện đáng kể truy cập tương tranh. Ví dụ, nếu chúng ta có một quan hệ trên một đĩa và một chỉ mục trên một đĩa khác, việc truy cập tới các chỉ mục có thể được thực hiện mà không ảnh hưởng đến việc truy cập tới các quan hệ, ít nhất là ở mức đọc đĩa.

Thay thế các giao dịch dài bằng các giao dịch ngắn: Đôi khi, quá nhiều công việc được làm trong một giao dịch, và nó phải mất một khoảng thời gian dài để thực hiện và thời gian nắm giữ các khoá cùng dài. Trong trường hợp này, chúng ta nên cân nhắc để thay thế giao dịch này bằng hai hoặc nhiều giao dịch nhỏ hơn: holdable cursors (xem phần 6.1.2) có thể hữu ích để làm điều này. Ưu điểm của việc làm này là các giao dịch nhỏ hơn có thể hoàn thành nhanh hơn và giải phóng khoá sớm hơn. Nhược điểm là một loạt các thao tác không còn được thực hiện một cách nguyên tử, và các ứng dụng phải giải quyết tình trạng này khi một trong số những giao dịch này không hoàn thành được.

Xây dựng một Warehouse: Các giao dịch phức tạp có thể nắm giữ các khoá chia sẻ trong một thời gian dài. Tuy nhiên, thường thì những truy vấn này bao gồm các phân tích thống kê của các khuynh hướng và nó có thể cho phép chạy trên các bản sao của dữ liệu. Điều này dẫn đến sự phổ biến của data warehouses, nó là bản sao của những dữ liệu được sử dụng trong những truy vấn phức tạp (Chương 25). Việc chạy các truy vấn này trên warehouse sẽ làm giảm gánh nặng cho cơ sở dữ liệu hiện tại.

Đề nghị một mức cô lập thấp hơn: Trong nhiều trường hợp, ví dụ khi các truy vấn đưa ra thông tin nhóm hoặc các thống kê, chúng ta có thể sử dụng một mức cô lập thấp hơn như REPEATABLE READ hoặc READ COMMITTED (Phần 16.6). Các mức cô lập thấp hơn có chi phí khoá thấp hơn và những người lập trình ứng dụng phải cân nhắc để có một bản thiết kế tốt.

Giảm Hot Spots

Trễ các thao tác Hot Spots: Chúng ta đã bàn về giá trị của việc trễ các yêu cầu có khóa. Rõ ràng, điều này đặc biệt quan trọng đối với các yêu cầu có chứa các đối tượng được sử dụng thường xuyên.

Tối ưu hoá các mô hình truy cập: Xây dựng các mô hình cho các thao tác cập nhật một quan hệ có thể cũng mang lại hiệu quả. Ví dụ, nếu các bộ giá trị được thêm vào quan hệ Employees theo thứ tự của eid và chúng ta có một chỉ mục B+tree trên eid, mỗi bộ giá trị được thêm sẽ ở trang lá cuối cùng của B+tree. Điều này dẫn đến có các hot spots dọc theo đường từ gốc đến trang lá bên phải nhất. Vì thế, chúng ta nên chọn một chỉ mục băm trên B+tree hoặc chỉ mục một trường khác. Ghi nhớ rằng việc mô hình hoá các truy cập như thế này sẽ dẫn đến khả năng thực thi của các chỉ mục ISAM kém đi, vì trang lá cuối cùng trở thành một hot spot. Đây là một khó khăn cho các chỉ mục băm vì quá trình băm sẽ chọn ngẫu nhiên một bucket mà bản ghi được thêm vào.

Phân chia các thực thi trên Hot spots: Xem xét một giao dịch thêm các bản ghi mới vào một file nào đó (ví dụ, thêm vào một bảng được lưu như một heap file). Thay vì thêm một bản ghi ứng với một giao dịch và thực hiện một khoá trên trang cuối cùng của mỗi bản ghi, chúng ta có thể thay thế các giao dịch này bằng một vài giao dịch khác, nó sẽ viết các bản ghi lên một file địa phương và sau đó định kỳ thực hiện thêm một bó các bản ghi này lên file chính.

Minh hoạ thêm về việc phân vùng, giả sử chúng ta lưu lại số lượng các bản ghi được thêm vào một biến đếm. Thay vì phải cập nhật biến này một lần ứng với mỗi bản ghi được thêm, chúng ta sẽ sử dụng cách tiếp cận trước và chỉ định kỳ cập nhật biến này. Ý tưởng này có thể được sử dụng trong rất nhiều các yêu cầu đếm và nó mang lại hiệu quả cao.

Lựa chọn chỉ mục: Nếu một quan hệ nào đó được cập nhật thường xuyên, các chỉ mục B+tree trên có thể trở thành các nút cổ chai, bởi vì tất cả các truy cập thông qua chỉ mục này đều phải đi qua gốc. Vì thế, gốc và các trang chỉ mục phía dưới có thể trở thành các hot spots. Nếu các DBMS sử dụng các giao thức khoá đặc biệt cho các chỉ mục cây, thì vấn đề này sẽ bớt nghiêm trọng hơn. Rất nhiều hệ thống hiện nay sử dụng công nghệ này.

Tuy nhiên, xem xét này có thể dẫn chúng ta đến việc lựa chọn một chỉ mục ISAM trong một số tình huống. Vì các mức chỉ mục của một chỉ mục ISAM nào đó là tĩnh nên chúng ta không cần thực hiện khoá trên những trang này; chỉ những trang lá là cần phải khoá. Một chỉ mục ISAM có lẽ phù hợp hơn một chỉ mục B+tree, ví dụ, nếu việc cập nhật xảy ra thường xuyên nhưng chúng ta hy vọng sự phân bố của các bản ghi , số lượng (và kích thước) của các bản ghi trong một miền nào đó của giá trị khoá tìm kiếm là xấp xỉ bằng nhau. Trong trường hợp này chỉ mục ISAM sẽ cần chi phí khoá thấp hơn (và giảm được sự cạnh tranh của các khoá), và việc phân bố các bản ghi này sẽ tạo ra không nhiều các trang tràn.

Các chỉ mục băm không tạo ra các nút cổ chai tương tranh, trừ khi việc phân bố dữ liệu được thực hiện rất kém và rất nhiều mục dữ liệu được lưu tập trung trong một vài bucket nào đó. Trong trường hợp này, các cổng vào thư mục của các buckets này có thể trở thành các hot spots.

Điều chỉnh cơ sở dữ liệu

Một vài tháng sau khi khai trương Website B&N, DBDudes được gọi đến và được nói rằng khách hàng thắc mắc rằng các hóa đơn đang trong quá trình chờ thực hiện được xử lý rất chậm. B&N đã rất thành công, bảng Orders và Orderlists đã có số lượng bản ghi rất lớn.

Suy nghĩ thêm về phần thiết kế, DBDudes nhận ra rằng có hai kiểu hóa đơn: một là các hóa đơn đã hoàn thành, đó là những hóa đơn mà tất cả các sách khách hàng đặt đã được giao hết; hai là các hóa đơn chưa hoàn thành, là những hóa đơn mà một số cuốn sách trong hóa đơn đó chưa được giao. Hầu hết khách hàng yêu cầu xem các hóa đơn chưa hoàn thành, những hóa đơn dạng này chỉ chiếm một phần rất nhỏ so với toàn bộ hóa đơn. Vì thế DBDudes quyết định phân vùng theo chiều ngang cả hai bảng Orders và Orderlists theo thuộc tính ordernum. Việc làm này dẫn đến có bốn quan hệ mới: NewOrders, OldOrders, NewOrderlists, và OldOrderlists.

Một hóa đơn và các thành phần của nó luôn đi đôi với nhau – và chúng ta có thể xác định những cặp này, cũ hoặc mới, bằng một kiểm tra đơn giản trên ordernum - và các truy vấn chứa các hóa đơn này có thể được thực hiện chỉ trên các quan hệ liên quan. Bây giờ, một số truy vấn lại thực hiện chậm hơn, như truy vấn lấy ra tất cả các hóa đơn của một khách hàng, vì truy vấn này sẽ yêu cầu chúng ta tìm kiếm trên cả bốn quan hệ trên. Tuy nhiên, các truy vấn dạng này không thường xuyên được yêu cầu và thực thi của nó có thể chấp nhận được.

Các tiêu chuẩn đánh giá DBMS nổi tiếng

Online Transaction Processing Benchmarks: TPC-A và TPC-B tạo nên các định nghĩa chuẩn về các độ đo tps và $/tps. TPC-A đo khả năng thực thi và giá của một mạng máy tính cộng với DBMS, ngược lại TPC-B benchmark xem xét chỉ riêng DBMS. Các tiêu chuẩn này bao gồm một giao dịch đơn giản để cập nhật ba bản ghi từ ba bảng khác nhau, và thêm một bản ghi vào bảng thứ tư. Một số thông tin chi tiết (ví dụ, giao dịch phân tán, phương thức kết nối trong, các thuộc tính của hệ thống) được xác định một cách nghiêm khắc, đảm bảo rằng kết quả trong các hệ thống khác nhau có thể được so sánh đầy đủ. TPC-C benchmark là một tập các công việc phức tạp hơn TPC-A và TPC-B. Nó mô hình hóa một warehouse ghi lại các mặt hàng đã được cung cấp cho từng khách hàng và bao gồm năm kiểu giao dịch. Một giao dịch TPC-C đắt hơn một giao dịch TPC-A hoặc TPC-B, và TPC-C tận dụng được nhiều khả năng của hệ thống, như sử dụng các chỉ mục phụ và loại bỏ các giao dịch không còn sử dụng nữa. Nó có thể thay thế hoàn toàn được TPC-A và TPC-B như là một benchmark xử lý giao dịch chuẩn tắc.

Query Benchmarks: Wisconsin benchmark được sử dụng rộng rãi để đo sự thực thi của các truy vấn đơn giản. Set Query benchmark đo khả năng thực thi của một loạt các truy vấn phức tạp hơn, và AS³AP benchmark đo khả năng thực thi của luồng công việc giữa các giao dịch hỗn hợp, các truy vấn quan hệ và các hàm tiện ích. TPC-D benchmark hỗ trợ một dãy các truy vấn SQL phức tạp được dùng trong các ứng dụng. OLAP Council cũng phát triển một benchmark sử dụng cho các truy vấn hỗ-trợ-ra-quyết-định phức tạp, bao gồm một số truy vấn không thể được biểu diễn dễ dàng bằng SQL. Nó được sử dụng để đo các hệ thống OLAP, các hệ thống này được trình bày trong Chương 25. Sequoia 2000 benchmark được thiết kế để so sánh các DBMS hỗ trợ các hệ thống thông tin địa lý.

Object-Database Benchmarks: Benchmarks 001 và 007 đo khả năng thực thi của các hệ thống cơ sở dữ liệu hướng đối tượng. Bucky benchmark đo khả năng thực thi của các hệ thống cơ sở dữ liệu hướng quan hệ. (Chúng tôi sẽ trình bày về các hệ thống cơ sở dữ liệu hướng đối tượng trong Chương 23).

Sử dụng Tiêu chuẩn

Tiêu chuẩn nên được sử dụng cùng với những hiểu biết tốt về việc chúng được thiết kế để đánh giá cái gì và môi trường ứng dụng sử dụng DBMS này. Khi bạn sử dụng tiêu chuẩn để định hướng việc lựa chọn DBMS cho ứng dụng của mình, bạn nên luôn ghi nhớ những hướng dẫn sau:

Ý nghĩa của một Benchmark nào đó? Một DBMS là một phần mềm phức tạp được sử dụng trong hàng loạt các ứng dụng. Một benchmark nên có một dãy các công việc được lựa chọn cẩn thận để phủ lên một miền ứng dụng cụ thể và kiểm tra các tính năng DBMS quan trọng cho miền ứng dụng đó.

Benchmark phản chiếu luồng công việc của bạn tốt như thế nào? Xem xét luồng công việc của bạn và so sánh nó với benchmark này. Cung cấp nhiều trường hợp thử nghiệm cho benchmark này (tức là, các truy vấn và các yêu cầu cập nhật), những thao tác tương đương với những thao tác quan trọng trong luồng công việc của bạn. Đồng thời cũng xem xét ngữ cảnh mà benchmark này được đánh giá. Ví dụ, thời gian thực hiện của các truy vấn độc lập có lẽ khác với thời gian thực hiện nó trong chế độ đa người dùng: Một hệ thống nào đó có thể có thời gian thực hiện dài hơn vì các thao tác I/O được thực hiện chậm hơn. Trên luồng công việc đa người dùng, nếu được cung cấp các đĩa đủ cho thực hiện I/O song song, thì thời gian thực hiện một yêu cầu nào đó sẽ thấp hơn.

Tạo ra benchmark của chính bạn: Bạn có thể tạo ra benchmark do bạn làm chủ bằng cách thay đổi các benchmark chuẩn một cách tinh tế hoặc thay thế các công việc trong một benchmark chuẩn bằng các công việc tương đương trong luồng công việc của bạn.

Tài liệu tham khảo

[658] là những bàn luận ban đầu về thiết kế cơ sở dữ liệu vật lý. [659] bàn về chuẩn hóa và những quan sát về phi chuẩn hóa có thể cải thiện được khả năng thực thi của một số truy vấn. Các công cụ thiết kế vật lý của IBM được trình bày trong [272]. Công cụ Microsoft Auto Admin thực hiện lựa chọn chỉ mục tự động dựa theo luồng công việc được trình bày trong một số tài liệu [163, 164]. DB2 Advisor được trình bày trong [750]. Các cách tiếp cận khác của thiết kế cơ sở dữ liệu vật lý được trình bày trong [146, 639]. [679] xem xét việc điều chỉnh giao dịch, phần mà chúng ta mới chỉ trình bày một cách tóm tắt.

Những quyển sách sau trình bày chi tiết về thiết kế vật lý: chúng được đề nghị đọc thêm. [779] trình bày về DB2. Shasha & Bonnet cung cấp thông tin chi tiết hơn về điều chỉnh cơ sở dữ liệu [104].

[334] gồm một số bài báo về benchmarking và có một số phần mềm kèm theo. Nó bao gồm các bài báo về AS3AP, Set Query, TPC-A, TPC-B, Wisconsin, và tiêu chuẩn 001 được viết bởi những người phát triển đầu tiên. Bucky benchmark được trình bày trong [132], tiêu chuẩn 007 được trình bày trong [131], và tiêu chuẩn TPC-D được trình bày trong [739]. Tiêu chuẩn Sequoia 2000 được trình bày trong [720].