Hệ quản trị Cơ sở dữ liệu

Biên tập bởi:Ths. Phạm Hoàng Nhung

Hệ quản trị Cơ sở dữ liệu

Biên tập bởi:Ths. Phạm Hoàng Nhung

Các tác giả:Ths. Phạm Hoàng Nhung

Phiên bản trực tuyến:http://voer.edu.vn/c/9d6bddd9

MỤC LỤC

1. Lời nói đầu2. Tổng quan về các hệ thống cơ sở dữ liệu3. Giới thiệu thiết kế cơ sở dữ liệu4. Mô hình quan hệ5. Đại số quan hệ và các phép toán logic6. Truy vấn, Ràng buộc, Trigger7. Phát triển ứng dụng cơ sở dữ liệu8. Các ứng dụng Internet9. Tổng quan về lưu trữ và chỉ số10. Tổng quan về đánh giá truy vấn11. Tổng quan về quản lý giao dịch12. Tinh chỉnh lược đồ và các dạng chuẩn hoá13. Thiết kế cơ sở dữ liệu vật lý và những điều chỉnh thiết kếTham gia đóng góp

1/470

Lời nói đầuMở đầu

Các hệ thống cơ sở dữ liệu là công cụ không thể thiếu cho việc quản lý thông tin, và khóahọc về lý thuyết và thực hành trên các hệ thống cơ sở dữ liệu là một phần quan trọngcủa chương trình đào tạo ngành khoa học máy tính. Quyển sách này trình bày những nộidung cơ bản của các hệ thống quản lý cơ sở dữ liệu hiện đại, cụ thể là các hệ cơ sở dữliệu quan hệ.

Chúng tôi cố gắng trình bày vấn đề này một cách rõ ràng và đơn giản. Cách tiếp cậnđịnh lượng được sử dụng cùng với nhiều những ví dụ chi tiết. Có rất nhiều bài tập trongmỗi chương, nó giúp tăng cường khả năng của sinh viên để áp dụng những khái niệmvào giải quyết các vấn đề thực tế.

Quyển sách có thể được sử dụng cùng với phần mềm hỗ trợ và các bài tập lập trình tronghai loại khác nhau của khóa học:

1. Tập trung vào ứng dụng: Khóa học này tập trung vào các nội dung cơ bản của cáchệ thống cơ sở dữ liệu, và nhấn mạnh vào việc chúng được sử dụng như thế nào trongcác ứng dụng hướng-dữ-liệu. Hai chương mới về phát triển ứng dụng đã được thêm vàotrong phiên bản thứ ba, và toàn bộ quyển sách được tổ chức lại để hỗ trợ những khóahọc kiểu này. Một ví dụ nghiên cứu và các tài nguyên hỗ trợ trực tuyến (ví dụ, mã lệnhcủa các truy vấn SQL và các ứng dụng Java, cơ sở dữ liệu trực tuyến và các giải pháp)giúp cho quyển sách này trở nên dễ dạy cho những khóa hướng ứng dụng.

2. Tập trung vào hệ thống: Khóa học này giả thiết rằng sinh viên có kỹ năng lập trìnhC và C++ tốt. Trong trường hợp này một phần mềm Minibase phù hợp có thể được sửdụng như một dự án trong đó sinh viên được yêu cầu để thực hiện hàng loạt các vấn đềcủa RDBMS. Một vài mô-đun trong phần mềm (ví dụ, heap files, quản lý vùng đệm,B+trees, các chỉ số băm, các phương pháp nối khác nhau) được trình bày chi tiết trongtài liệu để sinh viên có thể thực hiện chúng, với các giao diện lớp (C++).

Rất nhiều giáo viên dạy khóa học liên quan đến cả hai kiểu chương trình trên. Việc cấutrúc lại trong phiên bản thứ ba cho phép thực hiện một khóa học lai như vậy. Quyển sáchnày có đủ để hỗ trợ những khóa học nâng cao bao gồm hai-khóa-học liên tục.

Tổ chức của phiên bản thứ ba

Quyển sách này được tổ chức thành sáu phần chính và hàng loạt các chủ đề nâng cao đãđược lựa chọn, như trong Hình 0.1. Các chương cơ bản giới thiệu về các hệ thống cơ sở

2/470

dữ liệu, mô hình ER và mô hình quan hệ. Chúng giải thích việc các cơ sở dữ liệu đượctạo ra và sử dụng như thế nào, và trình bày những vấn đề cơ bản của thiết kế cơ sở dữliệu và các truy vấn, bao gồm những vấn đề chuyên sâu về các truy vấn SQL. Trong khigiảng viên có thể bỏ qua một số vấn đề này theo ý của họ (ví dụ, đại số quan hệ, mộtvài phần về mô hình ER hoặc các truy vấn SQL), nhưng vấn đề này liên quan đến tất cảcác sinh viên làm việc trên các hệ thống cơ sở dữ liệu, và chúng tôi đề nghị rằng nó nênđược trình bày chi tiết nhiều nhất có thể.

Mỗi phần trong năm phần chính còn lại có hoặc là ứng dụng hoặc là tập trung vào cáchệ thống cơ sở dữ liệu. Trong ba phần về Các hệ thống, mỗi phần đều có một chươnggiới thiệu, được thiết kế để cung cấp những khái niệm cho chính phần đó, ví dụ, Chương8 là tổng quan về lưu trữ và chỉ số hóa. Các chương tổng quan này có thể được sử dụngđể cung cấp tổng quan về chủ đề này, hoặc như là chương đầu tiên trước khi đi vàonhững nội dung chi tiết hơn. Vì thế, trong một khóa học hướng ứng dụng, Chương 8trình bày về các tổ chức file và chỉ số hóa, trong khi đó, khóa học hướng hệ thống sẽchọn từ Chương 9 đến Chương 11. Phần về thiết kế và tinh chỉnh cơ sở dữ liệu trình bàyvề những vấn đề trong thiết kế và tinh chỉnh thực thi cho những truy vấn cần đảm bảo antoàn. Những chủ đề ứng dụng nên được trình bày tốt nhất là sau khi cung cấp cho sinhviên những kiến thức về kiến trúc của hệ thống cơ sở dữ liệu, và vì thế các chương nàynên được trình bày lần lượt.

(1) Cơ bản Cả hai

(2) Phát triển ứng dụng Tập trung vào ứng dụng

(3) Lưu trữ và chỉ số hóa Tập trung vào hệ thống

(4) Đánh giá truy vấn Tập trung vào hệ thống

(5) Quản lý giao dịch Tập trung vào hệ thống

(6) Thiết kế cơ sở dữ liệu và tinh chỉnh Tập trung vào ứng dụng

(7) Các chủ đề bổ sung Cả hai

Đề nghị cho đề cương khóa học

Quyển sách này có thể được sử dụng trong hai kiểu của khóa học cơ sở dữ liệu nói trên.Khóa học hướng ứng dụng có thể sử dụng các chương Cơ bản, sau đó là các chươngPhát triển ứng dụng, sau đó là các chương Tổng quan về hệ thống, và tổng kết bằng phầnThiết kế và tinh chỉnh cơ sở dữ liệu. Sự phụ thuộc giữa các chương được giữ ở mức thấpnhất, vì thế giảng viên có thể dễ dàng điều chỉnh bài giảng của mình. Phần I về các vấnđề Cơ bản nên được tìm hiểu đầu tiên. Chỉ các chương còn lại trong Phần I tới Phần VIlà có sự phụ thuộc lẫn nhau được chỉ ra theo các mũi tên trong Hình 0.2. Các chươngtrong Phần I nên được nghiên cứu tuần tự. Tuy nhiên, phần tìm hiểu về đại số quan hệ

3/470

và các phép toán logic có thể được để lại để tìm hiểu về các truy vấn SQL trước (mặc dùchúng ta biết rằng vấn đề này là quan trọng và lưu ý rằng nó nên được nghiên cứu trướckhi tìm hiểu về SQL.) .

Khóa học hướng hệ thống sẽ tìm hiểu về các chương Cơ bản và một số phần trong cácchương về Ứng dụng và Hệ thống. Một điểm quan trọng cho các khóa học hướng hệthống là lựa chọn đúng các dự án lập trình (ví dụ, việc sử dụng Minibase) làm cho ngườiđọc mong muốn sớm được nghiên cứu các chủ đề về hệ thống. Sự phụ thuộc giữa cácchương được giới hạn một cách cẩn thận để cho phép các chương Hệ thống được tìmhiểu ngay sau Chương 1 và Chương 3. Các chương Cơ bản còn lại và các chương Ứngdụng có thể được tìm hiểu sau. Quyển sách này cũng có thể được hỗ trợ cho đa-khóa-học. Hiển nhiên, việc lựa chọn bài giảng Tập trung vào Ứng dụng hay Tập trung vào Hệthống dẫn đến việc bỏ đi những nội dung không thực sự cần thiết; những phần trình bàytrong quyển sách này hỗ trợ hỗn hợp cả hai dạng khóa học. Các chủ đề bổ sung dải trênmột miền rộng lớn các vấn đề, và có thể được sử dụng cho các khóa học nâng cao.

Các vấn đề bổ sung

Quyển sách có những hỗ trợ trực tuyến:

4/470

Tổ chức các chương và sự phụ thuộc lẫn nhau

5/470

Các chương trực tuyến: Để tạo không gian cho các vấn đề mới như phát triển ứngdụng, truy cập thông tin, và XML, chúng tôi đưa một số chương lên tài liệu trực tuyến.Sinh viên có thể tải về miễn phí các chương này trên website của quyển sách, và các giảipháp cho các bài tập trong chương này được trình bày trong một quyển kèm theo.

Các slide bài giảng: Các slide bài giảng của tất cả các chương được miễn phí trongđịnh dạng Postscript, và PDF. Giảng viên khóa học cũng có thể có được các slide nàytrong định dạng Microsoft Powerpoint, và có thể sửa chúng để phù hợp với bài giảngcủa mình. Giảng viên cũng có thể truy cập tới tất cả các hình sử dụng trong quyển sáchnày (trong định dạng xfig), và có thể sử dụng chúng để thay đổi các slide.

Lời giải cho các bài tập trong các chương: Quyển sách có nhiều bài tập chuyên sâu.Sinh viên có thể tìm thấy lời giải của các bài tập được đánh số lẻ và các slide bài giảngcủa mỗi chương có trên Website trong các định dạng Postscript và Adobe PDF. Giảngviên có thể có được giải pháp cho tất cả các bài tập.

Phần mềm: Song hành với quyển sách này là hai loại phần mềm. Đầu tiên, chúng ta cóMinibase, một RDBMS nhỏ được sử dụng trong các khóa học hướng-hệ-thống. Cùngvới Minibase là các bài tập ví dụ và lời giải, xem Phụ lục 30. Thứ hai, chúng tôi đưa ramã chương trình của tất cả các bài tập phát triển ứng dụng trên Java và SQL trong quyểnsách này, cùng với những script để tạo ra các cơ sở dữ liệu minh họa, và các script choviệc thiết đặt một số DBMSs thương mại. Sinh viên có thể chỉ truy cập được các lời giảicủa các bài tập lẻ, nhưng giảng viên thì có thể truy cập lời giải của tất cả bài tập.

Tài liệu cho giảng viên: Quyển sách có những tài nguyên trực tuyến trong đó có nhữngdẫn giải cho giảng viên về từng chương. Nó cung cấp tổng quan về mỗi chương vàhướng dẫn giảng viên nên nhấn mạnh hoặc bỏ qua những nội dung nào. Tài liệu nàycũng bàn về các tài nguyên được hỗ trợ trực tuyến của từng chương và hàng loạt nhữngđề xuất cho các bài tập và các dự án. Cuối cùng, nó bao gồm các ví dụ về các bài kiểmtra cho các khóa học sử dụng quyển sách này làm giáo trình.

Thông tin tham khảo

Trang chủ của cuốn sách này có URL là:

http://www.es.wisc.edu/~ dbbook

Nó bao gồm danh sách những thay đổi từ phiên bản 2 sang phiên bản 3, và những lỗivà những hỗ trợ của quyển sách này cũng được cập nhật thường xuyên. Giảng viên nênvào website này định kỳ hoặc đăng ký để nhận được những thông tin này qua thư điệntử.

6/470

Lời cảm ơn

Quyển sách này được phát triển từ các bài giảng của môn học có mã là CS564, một khóahọc về cơ sở dữ liệu ở UW-Madison. David DeWitt đã phát triển khóa học này và mộtdự án Minibase, trong đó sinh viên có viết một số phần trong RDBMS. Những suy nghĩcủa tôi đã hình thành từ khi dạy CS564, và Minirel là nguồn cảm hứng để xây dựngMinibase – nó có nhiều sự pha trộn (ví dụ, nó có một bộ tối ưu hóa truy vấn và một phầnmềm mô phỏng) nhưng cố gắng để giữ lại những tưởng tượng của Minirel. Mike Careyvà tôi cùng nhau thiết kế Minibase rất nhiều. Bài giảng của tôi bị ảnh hưởng rất nhiềutừ các bài giảng của Mike và slides bài giảng của Yannis Loannidis. Joe Hellerstein đãsử dụng phiên bản beta của quyển sách này ở Berkeley và đã cung cấp cho tôi nhữngphản hồi vô giá, hỗ trợ các slides và những chú giải rất hài hước. Việc viết các chươngvề hệ cơ sở dữ liệu hướng đối tượng cùng với Joe có rất nhiều niềm vui. C. Mohan cungcấp những hỗ trợ vô giá, kiên nhẫn trả lời một số lượng lớn các câu hỏi về công nghệthực thi được sử dụng trong các hệ thống thương mại, cụ thể là việc chỉ số hóa, điềukhiển tương tranh, và các thuật toán liên quan đến phục hồi dữ liệu. Moshe Zloof trảlời rất nhiều các câu hỏi về ngữ nghĩa QBE và các hệ thống thương mại dựa trên QBE.Ron Fagin, Krishna Kulkarni, Len Shapiro, Jim Melton, Dennis Shasha, và Dirk VanGucht phản biện quyển sách này và cung cấp những phản hồi rất chi tiết, giúp cải thiệncả nội dung và phần trình bày. Michael Goldweber ở Đại học Beloit, Matthew Hainesở Wyoming, Michael Kifer ở SUNY StonyBrook, Jeff Naughton ở Wisconsin, PraveenSeshadri ở Cornell, và Stan Zdonik ở Brown cũng sử dụng phiên bản beta cho các bàigiảng về cơ sở dữ liệu của họ và cung cấp những phản hồi và những báo cáo chi tiết. Cụthể, Michael Kifer chỉ ra một lỗi trong thuật toán (cũ) về tính tập bao phủ tối thiểu và đềxuất tìm hiểu một số đặc tính SQL trong Chương 2 để cải thiện khả năng module hóa.Tài liệu tham khảo của Gio Wiederhold trình bày dưới dịnh dạng Latex, và tài liệu thamkhảo trực tuyến của Michael Ley trên các cơ sở dữ liệu và lập trình logic đã có đónggóp lớn lao trong khi biên dịch tài liệu tham khảo cho các chương. Shaun Flisakowskivà Uri Shaft đã giúp đỡ tôi liên tục khi đối mặt cùng Latex.

Tôi cũng gửi lời cảm ơn đặc biệt của mình tới rất, rất nhiều sinh viên đã xây dựng nênphần mềm Minibase. Emmanuel Ackaouy, Jim Pruyne, Lee Schumacher, và MichaelLee đã làm việc cùng tôi khi tôi phát triển phiên bản đầu tiên của Minibase (nhiều phầnđã bị bỏ qua, nhưng nó ảnh hưởng rất nhiều tới phiên bản sau). Emmanuel Ackaouy vàBryan So là người đồng hướng dẫn của tôi khi tôi dạy khóa học CS564 sử dụng phiênbản này và họ đã nỗ lực để tinh chỉnh nó. Paul Aoki đã làm việc hết sức mình với mộtphiên bản Minibase và đưa ra nhiều lời nhận xét đáng giá. Sinh viên của lớp CS764(khóa học cơ sở dữ liệu cho sinh viên đã tốt nghiệp) đã phát triển phiên bản hiện tại củaMinibase rất nhiều trong một dự án của lớp dưới sự hướng dẫn của tôi và Mike Carey.Amit Shukla và Michael Lee là những giảng viên đi kèm với tôi khi tôi dạy khóa họcCS564 sử dụng phiên bản này của Minibase và phát triển phần mềm xa hơn.

7/470

Một số sinh viên đã làm việc cùng tôi trên các dự án độc lập trong một thời gian dàiđể phát triển các thành phần khác nhau của Minibase. Nó bao gồm các gói phần mềmmô phỏng phục vụ quản lý bộ đệm và B+trees (Huseyin Bektas, Harry Stavropoulos,và Weiqing Huang); một bộ tối ưu hóa truy vấn và người mô phỏng là Stephen Harris,Michael Lee, và Donko Donjerkovic; một công cụ lược đồ ER dựa trên lược đồOpossum (Eben Haber); và một công cụ dựa trên GUI trong việc chuẩn hóa (AndrewProck và Andy Therber). Ngoài ra, Bill Kimmel đã làm việc để tích hợp và cố định phầnmã nguồn (quản lý bộ đệm, quản lý lưu trữ, các phương pháp truy cập và files, các phéptoán quan hệ, và bộ lập kế hoạch truy vấn) được đưa ra trong dự án của lớp CS764.Ranjani Ramamurty đã mở rộng đáng kể công việc của Bill trong việc làm rõ và tích hợphàng loạt các modun. Luke Blanshard, Uri Shaft, và Shaun Flisakowski đã cùng nhaulàm việc để phát triển những bài kiểm tra thích hợp và những bài tập dựa trên phần mềmMinibase. Krishna Kunchithapadam đã kiểm tra bộ tối ưu hóa và phần đã phát triển củaMinibase GUI.

Rõ ràng, phần mềm Minibase sẽ không tồn tại nếu không có sự góp mặt của rất nhiềungười có tài. Phần mềm này miễn phí cho các người dùng trong lĩnh vực này, tôi hyvọng nhiều giảng viên sẽ có thể dạy khóa học về cơ sở dữ liệu hướng-hệ-thống cùng vớisự kết hợp giữa thực tiễn và kinh nghiệm để hoàn thành các tài liệu cho bài giảng.

Tôi cũng muốn cảm ơn rất nhiều sinh viên đã giúp tôi xây dựng và kiểm tra các đápán của các bài tập và cung cấp những phản hồi hữu ích cho các phiên bản nháp củaquyển sách này. Theo thứ tự là: X. Bao, S. Biao, M. Chakrabarti, C. Chan, W. Chen,N. Cheung, D. Colwell, C. Fritz, V. Ganti, J. Gehrke, G. Glass, V. Gopalakrishnan,M. Higgins, T. Jasmin, M. Krishnaprasad, Y. Lin, C. Liu, M. Lusignan, H. Modi, S.Narayanan, D. Randolph, A. Ranganathan, J. Reminga, A. Therber, M. Thomas, Q.Wang, R. Wang, Z. Wang, và J. Yuan. Arcady Grenader, James Harrington, và MartinReames ở Wisconsin và Nina Tang ở Berkeley đã cung cấp những phản hồi đặc biệt chitiết.

Charlie Fischer, Avi Silberschatz, và Jeff Ullman cho tôi những lời khuyên đáng giátrong khi làm việc với nhà xuất bản. Người biên tập của tôi ở McGraw-Hill, Betsy Jonesvà Eric Munson, đã đọc rất kỹ và chỉ dẫn cho quyển sách này trong những giai đoạn banđầu của nó.

Cuối cùng, quyển sách này là một tên trộm thời gian, và trong nhiều trường hợp, nó gâyra những khó khăn cho gia đình tôi còn nhiều hơn đối với tôi. Con trai của tôi đã nóithẳng thắn như vậy. Từ khi năm tuổi, Ketan đã nói: “Bố, đừng làm việc với quyển sáchngớ ngẩn này. Bố không có bất kỳ thời gian nào dành cho con.” Đứa con hai tuổi, Viveknói: “Bố làm việc với sách? Không không không hãy chơi bóng với con!” Tất cả sự bấtbình đã được vợ của tôi giải quyết, Apu đã giữ không khí vui vẻ cho cả gia đình mặc dùrất nhiều buổi tối và ngày cuối tuần tôi dành cho quyển sách này. (Không kể đến nhữngngày tôi sử dụng bên cạnh những đồng nghiệp trong khoa của tôi).

8/470

Trên tất cả, tôi cảm ơn tình yêu của cha tôi và mẹ tôi, cùng với tình yêu của họ dành chotôi. Anh trai của tôi đã gọi điện để kéo tôi ra khỏi phòng làm việc, nhưng thay vì cảm ơnanh ấy, tôi đã tức giận. Tôi muốn cảm ơn gia đình của tôi đã ủng hộ những gì tôi làm.(Ở đây! Tôi đã tìm ra được lý do để cảm ơn Kartik.)

Lời cảm ơn cho phiên bản thứ hai

Emily Gray và Betsy Jones ở McGraw-Hill đã đọc rất cẩn thân và cung cấp nhữnglời khuyên và sự hỗ trợ khi chúng tôi chuẩn bị thực hiện phiên bản hai. Những ngườiphản biện sau này cung cấp cho chúng tôi nhiều phản hồi có giá trị cả về nội dung vàcách tổ chức: Liming Cai ở Ohio University, Costas Tsatsoulis ở University of Kansas,Kwok-Bun Yue ở University of Houston, Clear Lake, William Grosky ở Wayne StateUniversity, Sang H. Son ở University of Virginia, James M. Slack ở Minnesota StateUniversity, Mankato, Herman Balsters ở University of Twente, Netherlands,Karen C.Davis ở University of Cincinnati, Joachim Hammer ở University of Florida, Fred Petryat Tulane University, Gregory Speegle ở Baylor University, Salih Yurttas ở Texas A&MUniversity, và David Chao ở San Francisco State University.

Một số người thông báo về các lỗi xảy ra trong phiên bản đầu tiên. Cụ thể, chúngtôi gửi lời cảm ơn tới những người sau: Joseph Albert ở Portland State University,Han-yin Chen ở University of Wisconsin, Lois Delcambre ở Oregon Graduate Institute,Maggie Eich ở Southern Methodist LIniversity, Raj Gopalan ở Curtin University ofTechnology, Davood Rafiei ở University of Toronto, Michael Schrefl ở University ofSouth Australia, Alex Thomasian ở University of Connecticut, và Scott Vandenberg ởSiena College.

Chúng tôi đặc biệt cảm ơn những người đã trả lời chi tiết những câu hỏi về cách thứccác hệ thống thương mại hỗ trợ các đặc tính khác nhau trong DBMS: Ở IBM: MikeCarey, Bruce Lindsay, C. Mohan, và James Teng; ở Informix: M. Muralikrishna vàMichael Ubell: ở Microsoft: David Campbell, Goetz Graefe, và Peter Spiro; ở Oracle:Hakan Jacobsson, Jonathan D. Klein, Muralidhar Krishnaprasad, và M. Ziauddin; vàở Sybase, Marc Chanliau, Lucien Dimino, Sangeeta Doraiswamy, Hanuma Kodavalla,Roger MacNicol, và Tirumanjanam Rengarajan.

Lời cảm ơn cho phiên bản thứ ba

Chúng tôi cảm ơn Raghav Kaushik về những đóng góp của anh ấy đối với phần XML,và Alex Thomasian với những đóng góp trong phần điều khiển tương tranh. Chúng tôiđặc biệt cảm ơn Jim Melton đã gửi cho chúng tôi cuốn sách chưa xuất bản của anh ấyvề những phần mở rộng hướng đối tượng trong chuẩn SQL: 1999, và chỉ ra một vài lỗitrong bản nháp phiên bản thứ ba này. Marti Hearst ở Berkeley đã hào phóng cho phépchúng tôi sử dụng một số slide của anh ấy trong phần Truy cập thông tin, Alon Levy và

9/470

Dan Suciu đã cho chúng tôi sử dụng một số slid của họ về XML, Mike Carey giúp đỡsử dụng các dịch vụ Web.

Emily Lupash ở McGraw-Hill đã hỗ trợ và khuyến khích chúng tôi liên tục. Cô ấy làngười phản biện đến từ Ming Wang ở Embry-Riddle Aeronautical University, ChengHsu at RPI, Paul Bergstein ở Univ. of Massachusetts, Archana Sathaye ở SJSU, BharatBhargava ở Purdue, John Fendrich ở Bradley, Ahmet Ugur ở Central Michigan, RichardOsborne ở Univ. of Colorado, Akira Kawaguchi ở CCNY, Mark Last ở Ben Gurion,Vassilis Tsotras ở Univ. of California, và Ronald Eaglin ở Univ. of Central Florida.Chúng tôi gửi lời cảm ơn chân thành tới những người phản biện, họ đã giúp chúng tôicó những cải tiến lớn trong nội dung và thiết kế.

10/470

Tổng quan về các hệ thống cơ sở dữ liệuMột lượng lớn thông tin hữu ích đối với chúng ta tồn tại ở dạng văn bản, và giá trị củadữ liệu chính là tài sản quan trọng. Tuy nhiên, khả năng quản lý một lượng lớn thôngtin, nhanh chóng truy cập đến những thông tin cần thiết còn quan trọng hơn nữa. Điềuđó có nghĩa là có thông tin là chưa đủ, chúng ta còn phải biết cách sử dụng nó sao chothật hiệu quả. Từ thực tế đó dẫn chúng ta đến một suy nghĩ là: cần phải có một hệ thốngquản lý dữ liệu thật mạnh mẽ và hiệu quả. Để quản lý một lượng lớn dữ liệu phức tạp,người sử dụng phải có những công cụ - hỗ trợ tính năng đơn giản trong thao tác nhưnglại hiệu quả trong trích lọc thông tin.

Cơ sở dữ liệu là tập hợp dữ liệu biểu diễn các hoạt động của một hoặc một số tổ chức cóliên quan đến nhau. Ví dụ, cơ sở dữ liệu của một trường đại học có thể chứa thông tinvề:

Hệ quản trị cơ sở dữ liệu, còn gọi là DBMS là phần mềm được thiết kế để lưu trữvà quản lý một lượng lớn dữ liệu. Sử dụng DBMS là hướng tới một cách tiếp cận mới,không phải lưu trữ dữ liệu ở các tệp tin độc lập và viết từng ứng dụng cụ thể để quản lýchúng. Sự hữu ích của cơ sở dữ liệu sẽ được chúng ta đề cập chi tiết trong phần 4.

Note: Lĩnh vực của hệ quản trị cơ sở dữ liệu là một thế giới thu nhỏ của khoa học máytính. Những vấn đề đặt ra và công nghệ sử dụng liên quan đến một chuỗi những ngànhkhoa học như xử lý ngôn ngữ, ngôn ngữ lập trình, biên dịch, hệ điều hành, điều khiểntương tranh, cấu trúc dữ liệu, thuật toán, hệ thống phân tán và song song, giao diện ngườimáy, hệ chuyên gia và trí tuệ nhân tạo, công nghệ thống kê. Chúng ta sẽ không thể đivào tất cả các lĩnh vực nói trên trong cuốn sách này, nhưng nên chắc chắn rằng đây lànhững môn học cần thiết và đầy hứng thú.

Quản lý dữ liệu

Mục đích của cuốn sách này là trình bày chi tiết về hệ quản trị cơ sở dữ liệu, nhấn mạnhvề cách thức tổ chức thông tin trong DBMS, lưu trữ và truy cập dữ liệu hiệu quả, baogồm, cách thiết kế một cơ sở dữ liệu và sử dụng DBMS hiệu quả. Quyết định sử dụngDBMS nào cho một ứng dụng cụ thể phụ thuộc vào khả năng của DBMS, cân nhắc xemnó có hỗ trợ ứng dụng này hiệu quả không. Vì thế, để sử dụng tốt một DBMS nào đó,thì chúng ta cần phải hiểu được DBMS đó làm việc như thế nào.

Có rất nhiều loại của hệ quản trị cơ sở dữ liệu, nhưng cuốn sách này tập trung vào hệthống cơ sở dữ liệu quan hệ (RDBMSs), ngày nay hầu hết các DBMS hỗ trợ hệ thốngnày. Những câu hỏi sau được giải đáp trong cuốn sách này:

11/470

1. Thiết kế cơ sở dữ liệu và phát triển ứng dụng: Cách thức người sử dụng cóthể biểu diễn các hoạt động của thế giới thực (ví dụ, hoạt động của một trườngđại học) bằng những dữ liệu được lưu trữ trong DBMS? Những dữ liệu nàophải được xem xét và tổ chức lưu trữ như thế nào? Như thế nào để phát triểnứng dụng trên DBMS (Chương 2, 3, 6, 7, 19, 20 và 21)

2. Phân tích dữ liệu: Người sử dụng đưa ra yêu cầu với hệ thống như thế nàothông qua các truy vấn trên dữ liệu đang được lưu trữ trong DBMS? (Chương4, và 5)Một chương trực tuyến về Query-by-Example (QBA) cũng có thể phù hợp

3. Điều khiển tương tranh và đảm bảo an toàn: Cách thức DBMS cho phép rấtnhiều người cùng truy cập tới một dữ liệu đồng thời và làm thế nào để bảo vệan toàn dữ liệu thậm chí khi hệ thống có sự cố. (Chương 16, 17 và 18)

4. Hiệu suất: Làm cách nào DBMS có thể lưu trữ được tập dữ liệu lớn và đápứng được yêu cầu về hiệu quả của dữ liệu (Chương 8, 9, 10, 11, 12, 13, và 14)

Những chương cuối trình bày về những chủ để mở rộng như hệ quản trị cơ sở dữ liệuphân tán và song song, kho dữ liệu và những truy vấn phức tạp cho việc hỗ trợ ra quyếtđịnh, khai phá dữ liệu, truy vấn thông tin và cơ sở dữ liệu, XML, cơ sở dữ liệu hướngđối tượng, quản lý dữ liệu không gian và DBMS hướng chức năng.

Trong chương này, chúng ta giới thiệu về những vấn đề liệt kê ở trên. Trong phần 2,chúng ta sẽ bắt đầu tìm hiểu tóm tắt về lịch sử và vai trò của hệ quản trị cơ sở dữ liệutrong những hệ thống thông tin hiện đại. Sau đó, chúng ta chỉ ra lợi ích của việc lưu trữdữ liệu bằng DBMS thay vì lưu trữ bằng hệ thống file trong phần 3, và bàn về nhữnglợi ích của việc sử dụng DBMS để quản lý dữ liệu trong phần 4. Trong phần 5, chúngta sẽ xem xét dữ liệu được lưu trữ như thế nào trong DBMS. Người sử dụng có lẽ nghĩrằng thông tin được lưu trữ dưới dạng các khái niệm mức cao như là các thực thể (đốitượng) trong một tổ chức và các mối liên kết giữa các đối tượng này. Ngược lại, DBMSlưu trữ dữ liệu cụ thể ở dạng các bits. Sự khác nhau giữa suy nghĩ của người sử dụngvới thực tế lưu trữ dữ liệu trong DBMS được giải quyết bằng cầu nối là một số các mứctrừu tượng được DBMS hỗ trợ. Bằng trực giác, người sử dụng có thể biểu diễn dữ liệuở mức cao và sau đó làm rõ ràng những biểu diễn này bằng cách thêm vào một số thôngtin và miêu tả cần thiết.

Trong phần 6, chúng ta đề cập đến việc như thế nào người sử dụng có thể truy cập đếnnhững dữ liệu được lưu trữ trong DBMS và những yêu cầu về công nghệ để làm chocác truy vấn trở nên hiệu quả. Phần 7 cung cấp tổng quan về cách thức DBMS hỗ trợnhững truy cập tương tranh và bảo vệ an toàn dữ liệu ngay cả khi hệ thống gặp sự cố.Sau đó, chúng ta biểu diễn sơ bộ kiến trúc bên trong của DBMS trong phần 8 và một sốđối tượng làm việc trên DBMS trong phần 9.

12/470

Lịch sử phát triển

Từ những ngày đầu tiên có máy tính, lưu trữ và các thao tác dữ liệu đã trở thành nhữngmối quan tâm chính. DBMS đầu tiên đã được Charles Bachman thiết kế vào nhữngnăm 60 và gọi là Lưu trữ dữ liệu tích hợp. Nó được xây dựng dựa trên mô hình mạng.Bachman đã nhận được giải thưởng ACM's Turing (được đánh giá là giải Nobel trongngành khoa học máy tính) vào năm 1973 trong lĩnh vực cơ sở dữ liệu.

Cuối những năm 60, IBM đã phát triển Hệ thống quản lý dữ liệu và được sử dụng đếnngày nay trong nhiều ứng dụng chính. IMS được xây dựng dựa trên mô hình gọi là môhình phân cấp. Hệ thống SABRE phục vụ cho hệ thống đặt vé máy bay được Hàngkhông Mỹ và IBM phối hợp thực hiện và hệ thống này cho phép một số người có thểcùng truy cập vào một dữ liệu thông qua mạng máy tính. Điều thú vị là ngày nay là hệthống SABRE vẫn được sử dụng trong các dịch vụ du lịch dựa trên nền Web như làTravelocity.

Trong năm 1970, Edgar Codd, thuộc phòng nghiên cứu ở IBM's San Jose đã đưa ra mộtmô hình biểu diễn dữ liệu mới gọi là mô hình dữ liệu quan hệ. Phát minh này đã mở ramột thời kỳ phát triển mới cho hệ thống cơ sở dữ liệu, những DBMS xây dựng dựa trênmô hình này phát triển rất mạnh mẽ. Codd đã đạt được giải Turing về nghiên cứu này.Những lợi ích của nghiên cứu này được nhận thức rộng rãi và sử dụng DBMSs cho quảnlý dữ liệu trở thành chuẩn mực.

Trong những năm 80, mô hình quan hệ phát triển mạnh mẽ và hệ thống cơ sở dữ liệutiếp tục được ứng dụng rộng rãi. Ngôn ngữ truy vấn dữ liệu (SQL) dùng cho cơ sở dữliệu quan hệ được dự án IBM's System R phát triển và ngày nay đã trở thành ngôn ngữtruy vấn dữ liệu chuẩn. SQL được chuẩn hóa vào cuối những năm 80 và SQL-92 đượcphát triển bởi American National Standards Institute (ANSI) và International StandardsOrganization (ISO) đã thành ngôn ngữ chuẩn hiện nay. Ngoài ra, người sử dụng có thểviết các giao dịch thực hiện trên cơ sở dữ liệu. James Gray đã đạt được giải thưởngTuring năm 1999 về sự đóng góp của ông trong lĩnh vực quản lý giao dịch trên DBMS.

Cuối những năm 80 và những năm 90, đã có rất nhiều tiến bộ trong nhiều lĩnh vực hệthống cơ sở dữ liệu. Nhiều nghiên cứu đã đem đến sức mạnh cho ngôn ngữ truy vấn vàcác mô hình dữ liệu trở nên phong phú hơn, đã có những hỗ trợ đáng kể cho những phântích dữ liệu phức tạp. Một số những hãng như IBM’s, DB2, Oracle, Informix

Gần đây Informix đã sáp nhập vào IBMUDS đã mở rộng hệ thống của họ để có thể lưu trữ được những dữ liệu phức tạp hơnnhư hình ảnh, dữ liệu dạng văn bản và có thể thực hiện được nhiều loại truy vấn phứctạp hơn. Những hệ thống chuyên dụng đã được tạo ra để có thể làm kho dữ liệu, hợpnhất giữa một số cơ sở dữ liệu khác nhau và tạo ra những phân tích dữ liệu đặc biệt.

13/470

Điều đặc biệt là sự nổi lên của một số gói ứng dụng như Enterprise resource planning(ERP) và Management resource planning (MRP), đã có tác dụng đáng kể trong việcnâng cao khả năng của lớp trên cùng của DBMS - chính là lớp hướng ứng dụng(application-oriented). Những gói ứng dụng được sử dụng rộng rãi đến từ các hãngBaan, Oracle, PeopleSoft, SAP, và Siebel. Những gói này cung cấp một số các chứcnăng như: quản lý các đánh giá, lập kế hoạch, phân tích tài chính…Dữ liệu được lưu trữtrong cơ sở dữ liệu quan hệ và lớp ứng dụng có thể được xây dựng để hỗ trợ từng yêucầu khác nhau của các công ty.

Một lợi ích lớn lao nữa chính là DBMSs đã ra nhập hệ thống Internet. Trong khi thế hệđầu tiên của các Websites chỉ có thể lưu trữ dữ liệu dưới dạng hệ thống file, thì việc sửdụng cơ sở dữ liệu để lưu trữ dữ liệu và sau đó truy cập đến dữ liệu thông qua các trìnhduyệt Web đã trở nên vô cùng phổ biến. Các truy vấn được đưa vào thông qua các trìnhduyệt Web và sau đó kết quả được định dạng và trả về sử dụng ngôn ngữ đánh dấu nhưHTML để dễ dàng hiển thị lên các trình duyệt. Tất cả các nhà phát triển cơ sở dữ liệuthêm các tính năng khác vào hệ quản trị cơ sở dữ liệu để nó có thể ứng dụng hiệu quảtrên Internet.

Hệ quản trị cơ sở dữ liệu tiếp tục thể hiện vai trò của mình khi ngày càng nhiều giaodịch được thực hiện trực tuyến và những truy cập được thực hiện thông qua mạng máytính. Ngày nay, các tiện ích của cơ sở dữ liệu đa phương tiện, thư viện số, các kho dữliệu khoa học, thương mại điện tử … đã làm thay đổi cuộc sống của con người.

So sánh giữa lưu trữ bằng hệ thống file cổ điển với DBMS

Để hiểu được sự cần thiết của DBMS, chúng ta cùng nhau xem xét ví dụ sau: Một côngty có một tập hợp dữ liệu lớn (khoảng 500GB

Một kilobyte (KB) bằng 1024 bytes, một megabyte (MB) bằng 1024 KBs, mộtgigabyte (GB) bằng 1024 MBs, một terabyte (TB) bằng 1024 GBs, và một petabyte(PB) bằng 1024 terabytes.) để lưu thông tin về nhân viên, các phòng, sản phẩm, doanh số bán hàng v.v…Nhữngdữ liệu này có thể được một số nhân viên truy cập vào đồng thời. Những yêu cầu (câuhỏi) về dữ liệu phải được đáp ứng nhanh chóng, những thay đổi trên dữ liệu được thựchiện bằng những người dùng khác nhau phải được cập nhật một cách nhất quán, vàphải có giới hạn truy cập đến các phần dữ liệu khác nhau đối với từng đối tượng ngườidùng khác nhau.

Chúng ta có thể giải quyết các vấn đề về quản lý dữ liệu bằng việc lưu trữ dữ liệu trênhệ thống file riêng rẽ. Tuy nhiên, cách tiếp cận này gặp một số khó khăn, bao gồm:

14/470

• Có lẽ chúng ta không có bộ nhớ trong nào đủ 500GB để lưu trữ tất cả dữ liệu.Vì thế, chúng ta phải lưu trữ dữ liệu này thông qua các thiết bị lưu trữ như đĩa,băng từ và sau đó chuyển từng phần vào bộ nhớ trong để xử lý khi cần thiết.

• Thậm chí, nếu chúng ta có một bộ nhớ trong có dung lượng 500GB trên hệthống máy tính 32-bits, chúng ta cũng không thể tham chiếu trực tiếp đến nhiềuhơn 4GB dữ liệu! Chúng ta phải lập trình một vài phương pháp để có thể địnhvị được tất cả dữ liệu.

• Chúng ta phải viết các chương trình đặc biệt để trả lời từng câu hỏi của ngườisử dụng đối với dữ liệu. Những chương trình này rất phức tạp vì không giantìm kiếm quá lớn.

• Chúng ta phải bảo đảm sự đúng đắn của dữ liệu đối với những thay đổi khôngnhất quán của nhiều người sử dụng đồng thời tác động lên dữ liệu. Nếu nhữngchương trình được viết cho phép truy cập đồng thời thì nó thực sự rất phức tạp.

• Chúng ta phải đảm bảo rằng dữ liệu được lưu trữ phải có tính chất nhất quánnếu như hệ thống gặp trục trặc trong khi đang thực hiện một phiên giao dịch cósự thay đổi dữ liệu.

• Hệ điều hành chỉ cung cấp duy nhất một mật khẩu cho máy tính để đảm bảo antoàn. Điều này không đủ khả năng để cung cấp quyền cho các đối tượng ngườidùng khác nhau để họ chỉ được phép thực hiện trên các vùng dữ liệu nào đó củacơ sở dữ liệu.

DBMS là tập hợp các phần mềm được thiết kế để có thể thực hiện các công việc nói trênmột cách dễ dàng. Bằng việc lưu trữ dữ liệu trên DBMS thay vì việc lưu trữ vào các fileriêng rẽ, chúng ta có thể sử dụng các chức năng của DBMS để quản lý dữ liệu dễ dàng.Với dung lượng dữ liệu khổng lồ và số lượng rất lớn những người sử dụng đồng thời,những tính năng mà DBMS hỗ trợ đã trở nên vô cùng quan trọng và không thể thiếu.

Những lợi ích của DBMS

Sử dụng DBMS để quản lý dữ liệu có rất nhiều lợi ích:

• Độc lập dữ liệu: Những chương trình ứng dụng nên được độc lập tối đa có thểđối với việc biểu diễn và lưu trữ dữ liệu. DBMS có thể cung cấp các khungnhìn trừu tượng trên dữ liệu cách ly với lưu trữ vật lý của dữ liệu.

• Truy cập dữ liệu hiệu quả: Hàng loạt những tính năng của DBMS có thể giúplưu trữ và truy cập cơ sở dữ liệu hiệu quả. Những tính năng này đặc biệt quantrọng nếu dữ liệu được lưu trữ trên các thiết bị lưu trữ ngoài.

• Toàn vẹn và an toàn dữ liệu: Nếu dữ liệu luôn luôn được truy cập thông quaDBMS, thì DBMS có thể thiết đặt các ràng buộc toàn vẹn trên dữ liệu. Ví dụ,trước khi thêm thông tin về lương của một nhân viên, DBMS có thể kiểm tra sốlương đó không vượt quá số tiền hiện có của phòng. Hoặc, DBMS có thể thiếtđặt các quyền truy cập để giới hạn các đối tượng người dùng khác nhau đối vớicác phần bên trong cơ sở dữ liệu.

15/470

• Quản trị dữ liệu: Khi một vài người dùng chia sẻ dữ liệu, người quản trị hệthống có thể đưa ra những đề xuất mang lại hiệu quả đáng kể. Những chuyêngia có kinh nghiệm hiểu rõ dữ liệu đang được quản lý như thế nào và nhữngnhóm người sử dụng nào có thể sử dụng từng phần trong cơ sở dữ liệu, từ đó họcó thể đưa ra được cách thức tổ chức dữ liệu để giảm được tối đa dư thừa vàtruy cập trở nên hiệu quả.

• Truy cập đồng thời và khôi phục dữ liệu: DBMS lập lịch cho việc truy cậpđồng thời đến dữ liệu để người sử dụng có cảm giác rằng chỉ có một ngườiđang sử dụng dữ liệu trong một khoảng thời gian. Thêm vào đó, DBMS bảo vệngười sử dụng tránh những ảnh hưởng khi hệ thống gặp sự cố.

• Giảm thời gian phát triển ứng dụng: DBMS hỗ trợ rất nhiều các tính năngquan trọng được sử dụng trong rất nhiều các ứng dụng truy cập tới dữ liệu đượclưu trữ trong DBMS. Thông qua lược đồ mức cao (high-level interface), nhữngứng dụng được phát triển nhanh chóng và dễ dàng hơn vì rất nhiều những côngviệc đã được DBMS hỗ trợ thay vì bạn phải xây dựng trong chương trình ứngdụng.

Với những lợi ích nêu trên thì có lý do nào để chúng ta không sử dụng DBMS? DBMSlà sự kết hợp của những gói phần mềm phức tạp, được tối ưu cho những kiểu công việccó sự kế thừa, chồng lên nhau, và nó không thích hợp với những ứng dụng quá hẹp. Vídụ những ứng dụng có ít ràng buộc hoặc chỉ có một vài các phép toán phải thực hiện. Lýdo khác để không sử dụng DBMS là với những ứng dụng không cần có ngôn ngữ truyvấn hỗ trợ. Trong trường hợp này, lưu trữ dữ liệu một cách trừu tượng hóa như trongDBMS là không phù hợp và nó không tận dụng được những tính năng của DBMS như:thực hiện truy vấn phức tạp, bảo mật, điều khiển tương tranh, tự động khôi phục khi cósự cố.

Biểu diễn và lưu trữ dữ liệu trong DBMS

Người sử dụng của DBMS chỉ tập trung vào biểu diễn thế giới thực và các ràng buộctrong đó. Ví dụ, có các đối tượng Sinh viên, Khoa, và các Khóa học khi cần mô tả vềtrường đại học, và dữ liệu trong cơ sở dữ liệu về trường đại học này được biểu diễn dướidạng thực thể và các mối quan hệ giữa các thực thể.

Mô hình dữ liệu là tập hợp những cấu trúc biểu diễn dữ liệu ở mức cao, nó đã ẩn điphần chi tiết dữ liệu được lưu trữ ở mức thấp như thế nào. DBMS cho phép người sửdụng được định nghĩa dữ liệu lưu trữ trong các phần của mô hình dữ liệu. Hầu hết cácDBMS hiện nay dựa trên mô hình dữ liệu quan hệ- mô hình được tập trung trình bàytrong cuốn sách này.

Mô hình dữ liệu của DBMS ẩn đi rất nhiều các chi tiết về cách thức lưu trữ bên trongcủa hệ thống để nó trở nên dễ dàng hơn đối với người sử dụng. Mô hình dữ liệu mức

16/470

ngữ nghĩa là mô hình dữ liệu mức cao, trừu tượng, dễ dàng để người sử dụng tiếp cậnvà biểu diễn dữ liệu của ứng dụng.

Note: Ví dụ một thiết kế không tốt: Lược đồ quan hệ của thực thể Students sau đâychứng tỏ một thiết kế không tốt; bạn không nên tạo ra trường age, vì giá trị của trườngnày thay đổi theo thời gian. Tốt hơn, thay vì trường age sẽ là trường DOB (Date ofBirth); bởi vì trường luôn có giá trị cố định và trường age cũng có thể suy ra từ trườngnày. Trong những ví dụ của cuốn sách này, ta vẫn sử dụng trường age để chúng ta dễđọc.

Mô hình dữ liệu mức ngữ nghĩa được sử dụng rộng rãi nhất ngày nay là mô hình quanhệ -thực thể (còn gọi là mô hình ER), cho phép ta biểu diễn thế giới thực dưới dạng cácthực thể và mối liên kết giữa các thực thể đó. Chúng ta sẽ nghiên cứu sâu hơn về môhình này trong chương 2.

Mô hình quan hệ

Trong phần này chúng ta sẽ tìm hiểu tóm tắt về mô hình quan hệ. Cấu trúc để biểu diễndữ liệu trong mô hình này ở dạng quan hệ, có thể hiểu là tập hợp của các bản ghi.

Biểu diễn cấu trúc trong mô hình dữ liệu được gọi là lược đồ. Trong mô hình quan hệ,lược đồ của một quan hệ được xác định bằng tên của lược đồ và tên của các trường - còngọi là các cột hoặc các thuộc tính. Ví dụ, thông tin về sinh viên trong cơ sở dữ liệu củatrường đại học có thể được lưu trữ trong quan hệ, được biểu diễn ở dạng lược đồ nhưsau:

Students(sid: string, name: string, login: string, age:integer, gpa: real)

Lược đồ trên chỉ ra rằng mỗi một bản ghi trong quan hệ Students có năm trường, cùngvới tên của trường và kiểu dữ liệu của trường đó.

Một thể hiện dữ liệu của quan hệ Students được chỉ ra trong Hình 1.

Một thể hiện của quan hệ Students

17/470

Mỗi một dòng trong quan hệ Students là một bản ghi, biểu diễn chi tiết về một sinh viêncụ thể. Biểu diễn này không phải là toàn bộ thông tin về một đối tượng nào đó- ví dụ,thông tin về chiều cao của sinh viên không được chỉ ra vì nó không quan trọng trong cơsở dữ liệu của một trường đại học. Mỗi lược đồ chỉ ra cấu trúc của quan hệ, vì thế nó cóthể được xem như một khuôn dạng để biểu diễn quan hệ.

Chúng ta có thể xác định các ràng buộc toàn vẹn trên thông tin về các sinh viên, đólà những điều kiện mà các bản ghi trong quan hệ phải tuân theo. Ví dụ, chúng ta có thểxác định mỗi sinh viên phải có một sid duy nhất. Quan sát thấy rằng, chúng ta không thểbiểu diễn những ràng buộc này thông qua lược đồ Students. Vì thế, chúng ta phải chỉ racác ràng buộc trên từng trường dữ liệu khi biểu diễn dữ liệu thông qua DBMS. Việc chỉra các ràng buộc về toàn vẹn dữ liệu rất quan trọng trong khi xây dựng mô hình dữ liệu.

Những mô hình dữ liệu khác:

Ngoài mô hình dữ liệu quan hệ (mô hình được sử dụng trong rất nhiều hệ thống (baogồm IBM's DB2, Informix, Oracle, Sybase, Microsoft's Access, FoxBase, Paradox,Tandem, và Teradata), những mô hình dữ liệu quan trọng khác như mô hình phân cấp(ví dụ, mô hình sử dụng trong IBM's IMS DBMS), mô hình mạng (ví dụ, mô hình sửdụng trong IDS và IDMS), mô hình hướng đối tượng (ví dụ, mô hình sử dụng trongObjectstore và Versant), và mô hình quan hệ - hướng đối tượng (ví dụ, mô hình sửdụng trong các sản phẩm của DBMS từ các hãng IBM, Informix, ObjectStore, Oracle,Versant, và một số hãng khác). Mặc dù có một số hệ thống cơ sở dữ liệu vẫn đang sửdụng mô hình dữ liệu mạng và phân cấp, một số hệ thống khác sử dụng mô hình hướngđối tượng và mô hình quan hệ hướng đối tượng, nhưng mô hình phổ biến nhất hiện nayvẫn là mô hình quan hệ.

Trong cuốn sách này, chúng ta tập trung tìm hiểu về mô hình quan hệ bởi vì nó đượcứng dụng rộng rãi. Thực tế, mô hình quan hệ - hướng đối tượng, cũng bắt đầu trở nênphổ biến vì nó kết hợp đặc trưng giữa mô hình quan hệ và mô hình hướng đối tượng,nắm chắc về mô hình quan hệ là thực sự cần thiết để bạn có thể tìm hiểu tiếp về mô hìnhhướng đối tượng. (Chúng ta sẽ bàn đến mô hình hướng đối tượng và mô hình quan hệ -hướng đối tượng ở Chương 23.)

Các mức trừu tượng trong DBMS

Dữ liệu trong DBMS được biểu diễn ở ba mức trừu tượng, minh họa trong hình 5. Bamức trừu tượng này được biểu diễn trong các lược đồ: lược đồ khái niệm, lược đồ vật lývà lược đồ ngoài.

Ngôn ngữ định nghĩa dữ liệu (DDL) được sử dụng để định nghĩa lược đồ ngoài vàlược đồ khái niệm. Chúng ta sẽ bàn tới ngôn ngữ DDL trong chương 3, phần trình bàyvề ngôn ngữ SQL- ngôn ngữ truy vấn dữ liệu được sử dụng rộng rãi hiện nay. Tất cả

18/470

các nhà sản xuất DBMS hiện nay đều hỗ trợ những lệnh SQL để biểu diễn những khíacạnh của lược đồ vật lý, nhưng những lệnh này không nằm trong ngôn ngữ SQL chuẩn.Thông tin về lược đồ khái niệm, lược đồ trong, lược đồ vật lý được lưu trữ trong Danhmục hệ thống (Phần 12.1). Chúng ta sẽ bàn về ba mức trừu tượng trong phần này.

Các mức trừu tượng trong DBMS

Lược đồ khái niệm - Conceptual Schema

Lược đồ khái niệm (còn được gọi là Lược đồ logic) biểu diễn cấu trúc và các ràng buộctrong toàn bộ cơ sở dữ liệu phục vụ cho việc giao tiếp với người dùng. Lược đồ kháiniệm ẩn đi cách thức tổ chức vật lý của dữ liệu, chỉ tập trung vào việc biểu diễn các thựcthể, các kiểu dữ liệu, mối quan hệ giữa các thực thể, các thao tác của người sử dụng vàcác ràng buộc giữa các dữ liệu.

Trong hệ quản trị cơ sở dữ liệu quan hệ, lược đồ khái niệm chỉ ra tất cả các quan hệđược lưu trữ trong cơ sở dữ liệu. Trong cơ sở dữ liệu về trường đại học, các quan hệ cóthể chứa đựng thông tin về các đối tượng như sinh viên, khoa, các khóa học và các mốiquan hệ giữa các đối tượng này. Tất cả các sinh viên được biểu diễn trong các bản ghicủa quan hệ sinh viên và chúng ta dễ dàng nhìn thấy chúng. Chúng ta thường biểu diễnquan hệ thông qua lược đồ khái niệm như sau:

Students(sid: string, name: string, login: string, age:integer, gpa: real) Faculty(fid: string, fname: string,sal: real) Courses(cid: string, cname: string, credits:integer) Rooms(rno: integer, address: string, capacity:integer) Enrolled(sid: string, cid: string, grade: string)Teaches(fid: string, cid: string) Meets_In(cid: string,rno: integer, time: string)

19/470

Lựa chọn các quan hệ, và các trường trong các quan hệ đó không phải dễ dàng và thốngnhất. Quá trình lựa chọn này được gọi là thiết kế cơ sở dữ liệu khái niệm. Chúng ta sẽbàn đến nội dung này trong Chương 2 và 19.

Lược đồ vật lý - Physical Schema

Lược đồ vật lý chỉ ra cách lưu trữ dữ liệu chi tiết. Về cơ bản, lược đồ vật lý chỉ ra cáchthức dữ liệu được lưu trữ trong các thiết bị lưu trữ thứ cấp như đĩa và băng từ.

Chúng ta phải quyết định những cách thức tổ chức tệp tin nào được sử dụng để lưu trữcác quan hệ và tạo ra những cấu trúc dữ liệu bổ trợ gọi là các chỉ số để tăng tốc độ củacác phép toán truy cập dữ liệu. Ví dụ về lược đồ vật lý của cơ sở dữ liệu University nhưsau:

• Lưu trữ tất cả các quan hệ bằng những tệp tin không được sắp xếp của các bảnghi (Một tệp tin trong DBMS là tập hợp những bản ghi hoặc tập hợp các trang,tốt hơn là một xâu của các ký tự như trong hệ điều hành.)

• Tạo các chỉ số trên cột đầu tiên của các quan hệ Students, Faculty, và Courses,cột Sal của Faculty, và cột Capacity của quan hệ Rooms.

Những quyết định về lược đồ vật lý dựa trên những hiểu biết về cách thức dữ liệu đượctruy cập thế nào. Quá trình đi đến một lược đồ vật lý tốt được gọi là thiết kế cơ sở dữliệu vật lý. Chúng ta sẽ bàn đến nội dung này trong Chương 16.

Lược đồ ngoài - External Schema

Lược đồ ngoài cũng là một trong những thành phần trong mô hình dữ liệu của DBMS,cho phép truy cập tới dữ liệu ở các mức khác nhau mà người sử dụng được phép. Mỗicơ sở dữ liệu có chính xác một lược đồ vật lý và một lược đồ khái niệm vì nó chỉ lưu trữmột tập hợp các quan hệ, nhưng nó lại có thể có nhiều lược đồ mức ngoài để thích hợpcho nhiều đối tượng người sử dụng khác nhau. Một lược đồ ngoài có thể có nhiều khungnhìn và các quan hệ có từ lược đồ khái niệm. Một khung nhìn có thể được hiểu là mộtquan hệ, nhưng những bản ghi của khung nhìn không được lưu trữ trong DBMS. Khungnhìn được người sử dụng định nghĩa và kết quả của nó được lấy ra từ các quan hệ trongcơ sở dữ liệu (kết quả của khung nhìn có thể là dữ liệu của một hoặc nhiều quan hệ).Chúng ta sẽ bàn kỹ về khung nhìn trong Chương 3 và 25.

Thiết kế lược đồ ngoài dựa trên những yêu cầu của người dùng cuối. Ví dụ, chúng tamuốn cho sinh viên xem thông tin về các khóa học, gồm có mã số của khóa học, tênkhoa dạy khóa học đó, và số lượng những đăng ký tham gia khóa học, chúng ta sẽ địnhnghĩa một khung nhìn như sau:

20/470

Courseinfo(cid: string, fname: string, enrollment:integer)

Người dùng coi những khung nhìn giống như những quan hệ và yêu cầu xem những bảnghi trong khung nhìn. Mặc dù, những bản ghi trong khung nhìn không được lưu trữ rõràng, chúng chỉ được tính toán khi cần thiết. Chúng ta không chỉ ra Courseinfo tronglược đồ khái niệm vì nó có thể được tính ra từ những quan hệ trong lược đồ khái niệm,và việc lưu trữ nó sẽ làm dư thừa thông tin. Dư thừa thông tin thì sẽ có khả năng sẽdẫn tới dữ liệu không nhất quán. Ví dụ, một bộ dữ liệu có thể được thêm vào quan hệEnrolled, chỉ ra rằng một sinh viên đã tham gia vào một vài khóa học nào đó, trong khigiá trị trường Enrollment của lược đồ Courseinfo không tăng lên tương ứng.

Độc lập dữ liệu

Một lợi ích rất quan trọng được sử dụng trong DBMS là khả năng độc lập dữ liệu. Đólà, những chương trình ứng dụng được cách ly với những thay đổi về cấu trúc và cáchlưu trữ dữ liệu. Độc lập dữ liệu đạt được thông qua việc sử dụng ba mức trừu tượng dữliệu; cụ thể, lược đồ khái niệm và lược đồ ngoài cung cấp lợi ích này.

Những quan hệ trong lược đồ ngoài được sinh ra dựa trên những quan hệ tương ứngtrong lược đồ khái niệm

Trong thực tế, chúng có thể được tính trước và lưu trữ để tăng tốc độ truy vấn trênkhung nhìn, nhưng những khung nhìn này phải được cập nhật ngay khi các quan hệphía dưới được cập nhật.. Nếu dữ liệu bên dưới được tổ chức lại thì lược đồ khái niệm sẽ phải thay đổi, và chỉcác định nghĩa của các quan hệ khung nhìn có thể phải thay đổi tương ứng. Ví dụ, giảsử rằng quan hệ Faculty trong cơ sở dữ liệu University được thay thế bằng hai quan hệsau:

Faculty_public(fid: string, fname: string, office:integer) Faculty_public(fid: string, sal: real)

Bằng trực giác, một vài thông tin bí mật về khoa đã được lưu trong một quan hệ riêngvà trường office đã được thêm vào. Khung nhìn Courseinfo có thể được định nghĩa lạidựa trên hai quan hệ Faculty_public và Faculty_private, những quan hệ cùng nhau chứathông tin về Faculty, vì thế những người sử dụng truy vấn thông tin trong Courseinfo sẽthu được kết quả không thay đổi với trước.

Như vậy, người sử dụng có thể được bảo vệ từ những thay đổi trong cấu trúc logic củadữ liệu, hoặc những thay đổi trong việc lựa chọn những quan hệ nào được lưu trữ. Tínhchất này được gọi là độc lập dữ liệu logic.

21/470

Quay trở lại, lược đồ khái niệm bảo vệ người dùng từ những thay đổi trong lưu trữ vậtlý của dữ liệu. Đặc trưng này được đề cập như là độc lập dữ liệu vật lý. Lược đồ kháiniệm ẩn đi những chi tiết như dữ liệu được lưu trữ thực sự như thế nào trên đĩa, cấu trúctệp tin, các lựa chọn chỉ số. Vì thế, chúng ta có thể thay đổi việc lưu trữ chi tiết của dữliệu mà không cần thay đổi chương trình ứng dụng. (Tất nhiên, việc thực hiện thì vẫn cóthể ảnh hưởng từ những thay đổi này).

Truy vấn trong DBMS

Người sử dụng thường có nhiều những yêu cầu khác nhau về dữ liệu đối với cơ sở dữliệu. Ngược lại với những hệ thống thông tin cũ, hệ cơ sở dữ liệu quan hệ cho phép dễdàng truy cập đến thông tin trong cơ sở dữ liệu, tính năng này khiến cho hệ thống trởnên thân thiện với người sử dụng hơn. Xem xét ví dụ cơ sở dữ liệu về một trường đạihọc trong phần 5.2, sau đây là một số các yêu cầu đối với cơ sở dữ liệu mà người sửdụng thường đặt ra.

1. Tên của sinh viên có mã là 123456?2. Lương trung bình của các giáo viên dạy cho khóa học CS546?3. Bao nhiêu sinh viên đã đăng ký khóa học CS564?4. Tỷ lệ sinh viên tham gia khóa học CS564 có một điểm từ B trở lên?5. Có sinh viên nào có điểm trung bình chung nhỏ hơn 3 tham gia khóa học

CS564?

Những yêu cầu trên cần phải truy xuất thông tin từ DBMS và được gọi là các truy vấn.DBMS cung cấp một ngôn ngữ đặc biệt là ngôn ngữ truy vấn. Tính năng nổi trội củamô hình quan hệ là nó hỗ trợ rất mạnh mẽ ngôn ngữ truy vấn. Phép toán quan hệ làngôn ngữ truy vấn chuẩn dựa trên các phép toán logic, và truy vấn viết bằng ngôn ngữnày rất trực quan và rõ ràng. Đại số quan hệ là ngôn ngữ truy vấn chuẩn khác dựa trêntập hợp các phép toán trên quan hệ.

DBMS rất quan tâm đến việc đánh giá hiệu quả của các truy vấn. Chúng ta sẽ bàn đếntối ưu hóa truy vấn và đánh giá trong chương 12, 14 và 15. Tất nhiên, hiệu quả của việcđánh giá truy vấn nhằm mục đích xác định cách thức lưu trữ vật lý của dữ liệu như thếnào. Việc đánh chỉ số có thể được sử dụng để làm tăng tốc độ của câu lệnh truy vấn.Chúng ta sẽ bàn đến cách lưu trữ dữ liệu và đánh chỉ số trong chương 8, 9, 10 và 11.

DBMS cho phép người sử dụng tạo, sửa, và truy vấn dữ liệu thông qua ngôn ngữ thựcthi dữ liệu (DML). Vì thế, ngôn ngữ truy vấn-cung cấp các câu lệnh thêm, xóa và sửadữ liệu-chỉ là một phần của DML. Chúng ta sẽ bàn đến các tính năng của DML trongchương 5. DML và DDL có thể được nhúng trong các ngôn ngữ lập trình như C hoặcCOBOL.

22/470

Quản lý giao dịch

Xem xét cơ sở dữ liệu lưu trữ thông tin về đặt chỗ vé máy bay. Trong nhiều trường hợp,tại cùng một thời điểm, có nhiều đại lý cùng truy cập tới hệ thống để đặt chỗ trên máybay. Ví dụ, như họ cùng muốn đặt một chỗ nào đó trên cùng một chuyến bay. Lúc đó,hệ thống phải đảm bảo được thứ tự thực hiện các yêu cầu để tránh xung đột.

Một ví dụ khác về nhiều người dùng đồng thời sử dụng hệ thống là cơ sở dữ liệu củangân hàng. Trong khi một chương trình ứng dụng đang tính toán tổng số khoản tiền gửicủa một tài khoản, thì một ứng dụng khác lại đang thực hiện chuyển tiền vào tài khoảnnày. Nếu hai giao dịch này diễn ra đồng thời thì kết quả của hai giao dịch trên khôngđồng nhất. Vì thế, những giao dịch dị thường như thế không được phép xảy ra.

Thêm vào đó, DBMS phải bảo vệ người dùng tránh những ảnh hưởng khi hệ thống xảyra sự cố, đảm bảo rằng tất cả dữ liệu và các trạng thái của ứng dụng phải được khôi phụcnhất quán khi hệ thống khởi động lại. Ví dụ, nếu đại lý bán vé máy bay yêu cầu đượcđặt chỗ và DBMS phản hồi lại là đã chấp nhận thì yêu cầu đó chắc chắn phải được thựchiện dù hệ thống có gặp sự cố. Và, nếu như DBMS chưa phản hồi lại yêu cầu của đạilý bán vé, thì những thay đổi thành phần đã thực hiện trước khi hệ thống gặp sự cố phảiđược khôi phục lại, tức là hệ thống phải khôi phục lại như chưa từng có yêu cầu thựchiện giao dịch đó để đảm bảo tính đúng đắn của dữ liệu.

Giao dịch là bất kỳ một thực hiện nào của người dùng trong DBMS. (Thực hiện cùngmột chương trình nhiều lần sẽ đưa ra nhiều giao dịch). Đây là một đơn vị cơ sở (basicunit) của thay đổi được thực hiện trong DBMS: Những giao dịch chưa hoàn thành (mộtphần của giao dịch) sẽ không được phép, có nghĩa là một giao dịch thành công nếu tất cảcác lệnh trong giao dịch đó được thực hiện thành công và ngược lại, giao dịch sẽ thất bạinếu một trong số những lệnh trong giao dịch đó thất bại. Chúng tôi sẽ trình bày tóm tắtnhư thế nào để đảm bảo được những tính chất này, phần chi tiết sẽ được bàn đến trongnhững chương sau.

Thực hiện đồng thời của các giao dịch

Một công việc quan trọng của DBMS là lập lịch trình cho những truy cập đồng thời tớidữ liệu để người dùng được đảm bảo an toàn, mặc dù thực tế rằng nhiều người khác cóthể đang cùng truy cập tới dữ liệu đó. Sự quan trọng của việc này không thể được xemnhẹ vì cơ sở dữ liệu được chia sẻ cho một số lượng lớn người sử dụng, họ gửi yêu cầutới DBMS một cách độc lập. DBMS cho phép người sử dụng nghĩ về những chươngtrình của họ như thể nó đang được thực hiện độc lập, chương trình này sau chương trìnhkia theo thứ tự được DBMS sắp xếp. Ví dụ, có một chương trình chuyển tiền vào mộttài khoản diễn ra đồng thời với một chương trình ghi nợ của chính tài khoản này, cả haichương trình có thể được DBMS thực hiện, và thứ tự của chúng sẽ phải được đảm bảođể không xảy ra sai sót dữ liệu.

23/470

Giao thức khóa là tập các quy tắc theo sau mỗi giao dịch để đảm bảo rằng trong khimột giao dịch đang thực hiện, những thao tác của một số giao dịch khác có thể được xenvào, nhưng kết quả cuối cùng vẫn phải tương đương với việc các giao dịch này đượcthực hiện theo một thứ tự. Khóa là một cơ chế được sử dụng để điều khiển việc truy cậptới các đối tượng cơ sở dữ liệu. Hai loại của khóa được DBMS hỗ trợ: khóa chia sẻ trênmột đối tượng cho phép hai giao dịch tại cùng một thời điểm, nhưng khóa độc quyềntrên một đối tượng sẽ đảm bảo rằng không có bất kỳ một giao dịch nào khác được nắmkhóa trên đối tượng này.

Giả sử rằng có giao thức khóa: Tất cả các giao dịch bắt đầu bằng việc nắm giữ khóachia sẻ trên mỗi đối tượng dữ liệu nếu nó thực hiện thao tác đọc, và nắm giữa khóa độcquyền khi nó cần sửa dữ liệu và sau đó giải phóng tất cả các khóa khi nó hoàn thành tấtcả các công việc. Xem xét hai giao dịch T1 và T2, T1 muốn sửa một đối tượng dữ liệuvà T2 muốn đọc trên chính đối tượng dữ liệu này. Như vậy, nếu T1 có khóa độc quyềnsẽ được thực hiện trước, T2 không thể được thực hiện cho đến khi T1 giải phóng khóa.Với thứ tự này, tất cả các yêu cầu của T1 sẽ phải được hoàn thành trước khi T2 bắt đầu.Chúng ta sẽ đề cập chi tiết đến khóa trong chương 16 và 17.

Những giao dịch không hoàn thành và sự cố hệ thống

Giao dịch có thể bị ngắt trước khi hoàn thành do xảy ra sự cố. DBMS phải đảm bảo rằngnhững thay đổi đã hoàn thành từ khi bắt đầu giao dịch đến khi bị ngắt phải được loại bỏra khỏi cơ sở dữ liệu. Ví dụ, nếu DBMS đang thực hiện chuyển tiền từ tài khoản A sangtài khoản B, và hệ thống gặp sự cố khi tài khoản A đã bị trừ tiền, tài khoản B chưa kịpcộng tiền. Lúc này, giao dịch bị ngắt phải thực hiện khôi phục lại tình trạng như trướckhi nó thực hiện. Để làm được điều này, DBMS duy trì một lịch sử (log) đối với tất cảcác hoạt động ghi lên cơ sở dữ liệu. Đặc tính chủ yếu của log là tất cả các hoạt động ghiphải được lưu lại trên log (nằm trên đĩa) trước khi nó thực hiện trên cơ sở dữ liệu. Vìnếu không làm như vậy, DBMS sẽ không thể khôi phục lại những thay đổi đã thực hiện.Đặc tính này được gọi là Write-Ahead Log hoặc WAL. Để đảm bảo được đặc tính này,DBMS phải có khả năng cưỡng chế một trang nào đó của bộ nhớ phải ghi lên đĩa.

Log cũng được sử dụng để chắc chắn rằng những thay đổi được thực hiện bằng các giaodịch thành công sẽ không bị mất do hệ thống gặp sự cố, được giải thích rõ hơn trongchương 18. Việc mang đến cho cơ sở dữ liệu trạng thái ổn định sau khi sự cố xảy ra cóthể mất nhiều thời gian, vì DBMS phải chắc chắn rằng những ảnh hưởng của tất cả cácgiao dịch đã thành công phải được lưu trữ lại và tất cả các giao dịch chưa hoàn thànhphải được khôi phục lại trạng thái như trước khi nó bắt đầu. Có thể giảm thời gian khôiphục lại bằng cách xác nhận định kỳ một số thông tin trên đĩa, thao tác thực hiện địnhkỳ này được gọi là checkpoint.

24/470

Các điểm cần lưu ý

Cuối cùng, có ba điểm cần ghi nhớ đối với một DBMS hỗ trợ điều khiển tương tranh vàkhôi phục hệ thống:

1. Giao dịch đọc một đối tượng nào đó của cơ sở dữ liệu theo chế độ khóa chia sẻvà ghi theo chế độ khóa độc quyền. Đặt khóa trên đối tượng giúp giới hạnnhững khả năng của nó với những giao dịch khác, ảnh hưởng đến việc thựchiện.

2. Để duy trì hiệu quả của log, DBMS phải được lựa chọn hiệu quả tập các trangtrong bộ nhớ chính trên đĩa. Hệ điều hành hỗ trợ chức năng này không phải lúcnào cũng đáp ứng được.

3. Checkpoint định kỳ có thể giảm thời gian khôi phục hệ thống khi có sự cố. Tấtnhiên, điều này phải được cân đối để tránh ảnh hưởng của checkpoint quá nhiềulàm giảm tốc độ thực hiện các yêu cầu bình thường.

Kiến trúc của một DBMS

Hình 3 chỉ ra kiến trúc của một DBMS tiêu biểu dựa trên mô hình dữ liệu quan hệ.

DBMS nhận những câu lệnh SQL từ các giao diện người dùng, lập kế hoạch thực hiệntruy vấn, thực hiện những truy vấn này trên cơ sở dữ liệu và trả lại kết quả. (Câu lệnhSQL có thể được nhúng trong các ngôn ngữ lập trình, ví dụ, Java hoặc COBOL. Chúngta bỏ qua những vấn đề này để tập trung vào các chức năng chính của DBMS).

Khi người sử dụng yêu cầu một truy vấn, cú pháp truy vấn được xem xét trong bộ tốiưu hóa truy vấn, bộ tối ưu hóa này sẽ dựa vào những dữ liệu đang được lưu trữ và cáchthức lưu trữ chúng để lên kế hoạch thực hiện truy vấn sao cho hiệu quả. Kế hoạch thựchiện truy vấn là một tập các bước thực hiện được biểu diễn thành các phép toán quan hệdưới dạng hình cây. Chúng ta sẽ bàn tới tối ưu hóa truy vấn trong chương 12 và chương15. Thực hiện của các phép toán khác được trình bày trong chương 12 và 14.

Phần mã chương trình thực thi các phép toán quan hệ được đặt phía trên của lớp filesand access methods. Lớp này bao gồm hàng loạt các phần mềm hỗ trợ khái niệm củatệp tin, trong DBMS là tập hợp các trang hoặc các bản ghi. Lớp này hỗ trợ các file vunđống, còn gọi là file chứa các trang không được sắp thứ tự, và các chỉ số. Thêm vào đó,để nắm được vị trí của các trang trong tệp tin, lớp này lưu trữ những thông tin bên trongmột trang. Vấn đề lưu trữ mức trang và file được đề cập trong Chương 9. Cấu trúc củafile và các chỉ số được đề cập trong Chương 8.

Phần mã chương trình của lớp filesandaccessmethods được đặt phía trên của buffermanager, bộ phận này có nhiệm vụ mang những trang từ đĩa tới bộ nhớ chính khi cần

25/470

thiết để phản hồi các yêu cầu từ người dùng. Buffer management được bàn đến trongChương 9.

Kiến trúc của một DBMS

Lớp thấp nhất của phần mềm DBMS giúp quản lý các vùng trống trên đĩa, nơi lưu trữdữ liệu, là disk space manager. Lớp này được trình bày trong chương 9.

DBMS hỗ trợ truy cập tương tranh và khôi phục sự cố bằng việc lập lịch trình cẩn thậncho những yêu cầu của người dùng và duy trì lịch sử của tất cả các thay đổi trên cơ sởdữ liệu. Các thành phần hỗ trợ điều khiển tương tranh và khôi phục sự cố nằm trongtransaction managercủa DBMS, quản lý giao dịch đảm bảo rằng các giao dịch yêu cầuvà giải phóng các khóa theo các giao thức khóa thích hợp và lập lịch trình thực hiện chocác giao dịch; log manager quản lý các yêu cầu đối với các khóa trên các đối tượng cơ

26/470

sở dữ liệu; và recovery manager duy trì lịch sử và khôi phục hệ thống trở về trạng tháinhất quán sau sự cố. Các lớp disk space manager, buffer manager, và file and accessmethod phải chịu ảnh hưởng của các thành phần này. Chúng ta sẽ bàn chi tiết đến điềukhiển đồng thời và khôi phục sự cố trong Chương 16.

Những người làm việc với cơ sở dữ liệu

Có rất nhiều người tham gia tạo và sử dụng cơ sở dữ liệu. Hiển nhiên, có những nhàsáng chế - người xây dựng phần mềm DBMS, và người dùng cuối – người mong muốnđược lưu trữ và sử dụng dữ liệu trong DBMS. Người xây dựng phầm mềm DBMS làmviệc cho những nhà phát triển hệ thống như IBM hoặc Oracle. Người dùng cuối là nhữngngười đến từ các lĩnh vực khác nhau. Dữ liệu tăng trưởng rất nhanh và phức tạp, và nóđược coi là tài sản của cơ quan, việc lưu trữ nó trong DBMS đang được chấp nhận rộngrãi. Nhiều người dùng cuối đơn giản chỉ sử dụng các ứng dụng được viết bởi nhữngngười lập trình ứng dụng và họ không cần có nhiều hiểu biết về phầm mềm DBMS. Tấtnhiên, những người dùng có trình độ cao hơn yêu cầu có thể tự viết được các lệnh truyvấn của họ.

Ngoài hai đối tượng người dùng là người dùng cuối và người xây dựng các phần mềmDBMS còn có hai đối tượng nữa, đó là: người lập trình ứng dụng và người quản trị cơsở dữ liệu.

Người lập trình ứng dụng cơ sở dữ liệu phát triển những gói phần mềm hỗ trợ ngườidùng cuối truy cập cơ sở dữ liệu, người dùng cuối thường không phải là những chuyêngia về máy tính. Người lập trình ứng dụng sử dụng các ngôn ngữ lập trình và các côngcụ phần mềm do các nhà sáng chế DBMS cung cấp. (Các công cụ như viết báo cáo, bảngtính, thống kê, …). Các chương trình ứng dụng nên truy cập dữ liệu thông qua lược đồngoài. Có thể viết những ứng dụng truy cập dữ liệu ở mức thấp, nhưng những ứng dụngnhư vậy phải có sự dàn xếp với khả năng độc lập dữ liệu.

Một cơ sở dữ liệu cá nhân được duy trì bằng một người làm chủ nó và sử dụng nó. Tuynhiên, những cơ sở dữ liệu của một tổ chức hoặc được sử dụng rộng rãi sẽ đủ quan trọngvà phức tạp để cần có một chuyên gia quản lý nó, người này gọi là người quản trị cơsở dữ liệu (DBA). DBA có rất nhiều nhiệm vụ:

• Thiết kế các lược đồ vật lý và lược đồ khái niệm: DBA phải hiểu những kiểudữ liệu nào có thể được lưu trữ trong DBMS và nó được sử dụng như thế nào.Dựa vào những hiểu biết này, DBA phải thiết kế các lược đồ khái niệm (quyếtđịnh lưu trữ những quan hệ nào) và lược đồ vật lý (các quan hệ này được lưutrữ như thế nào). DBA có lẽ cũng có thể thiết kế những phần khác nhau củalược đồ ngoài bằng cách tạo ra các khung nhìn bổ sung.

• Bảo mật và Xác thực: DBA phải chịu trách nhiệm đảm bảo rằng những truycập dữ liệu không hợp lệ sẽ không được phép. Nói chung, không phải tất cả

27/470

người dùng đều có thể truy cập vào tất cả dữ liệu. Trong DBMS quan hệ, ngườidùng có thể được cấp quyền truy cập tới các quan hệ và các khung nhìn hiệncó. Ví dụ, bạn có thể cho phép sinh viên đăng ký các khóa học và giáo viên dạykhóa học đó, nhưng bạn không nên cho sinh viên xem lương và thứ hạng củacác giáo viên. DBA có thể thực hiện những chính sách này bằng cách chỉ cấpcho sinh viên quyền truy cập tới khung nhìn Courseinfo.

• Sự sẵn sàng của dữ liệu và khôi phục sau sự cố: DBA phải thực hiện cácbước để đảm bảo rằng nếu hệ thống gặp sự cố, người dùng có thể được tiếp tụctruy cập nhiều nhất có thể những dữ liệu không bị hỏng. DBA cũng phải làmviệc để khôi phục dữ liệu về trạng thái nhất quán. DBMS cung cấp phần mềmhỗ trợ những tính năng này, nhưng DBA phải có nhiệm vụ thực thi những thủtục sao lưu dữ liệu định kỳ và duy trì logs của hệ thống để có thể khôi phục dữliệu sau sự cố.

• Tinh chỉnh cơ sở dữ liệu: Yêu cầu của người dùng thay đổi theo thời gian.DBA phải có trách nhiệm sửa đổi cơ sở dữ liệu, cụ thể là các lược đồ vật lý vàlược đồ khái niệm để đảm bảo thực hiện tương xứng với những thay đổi củayêu cầu.

Các câu hỏi ôn tập

Câu trả lời của các câu hỏi có thể được tìm thấy trong các phần sau:

• Lợi ích chính của việc sử dụng DBMS để quản lý dữ liệu trong những ứngdụng có phạm vi sử dụng rộng lớn? (Phần 1, 4)

• Khi nào bạn thực hiện lưu trữ dữ liệu bằng DBMS thay vì sử dụng hệ thống tệptin do hệ điều hành cung cấp? (Phần 3)

• Mô hình dữ liệu là gì? Mô hình dữ liệu quan hệ là gì? Độc lập dữ liệu là gì vàDBMS hỗ trợ nó như thế nào? (Phần 5)

• Giải thích lợi ích của việc sử dụng ngôn ngữ truy vấn thay vì các chương trìnhcủa người dùng để truy cập đến dữ liệu? (Phần 6)

• Giao dịch là gì? Những đảm bảo gì mà DBMS phải làm để thực hiện các giaodịch? (Phần 7)

• Khóa trong DBMS là gì và vì sao khóa được sử dụng? Write-ahead logging làgì và vì sao nó được sử dụng? Checkpointing là gì và vì sao nó được sử dụng?(Phần 8)

• Trình bày các chức năng của người quản trị cơ sở dữ liệu, các lập trình ứngdụng và người sử dụng cuối của cơ sở dữ liệu. Ai là người cần phải biết tất cảvề các thành phần của hệ thống cơ sở dữ liệu? (Phần 9)

Bài tập

Vì sao bạn lựa chọn hệ thống cơ sở dữ liệu thay vì việc lưu trữ dữ liệu đơn giản trong hệthống tệp tin. Khi nào không nên sử dụng hệ thống cơ sở dữ liệu?

28/470

Một cơ sở dữ liệu là một tập hợp dữ liệu hợp nhất, nó thường rất lớn nên phải lưu trữtrong các thiết bị lưu trữ thứ cấp như đĩa hoặc băng từ. Dữ liệu này có thể được lưutrữ như một tập hợp các file, hoặc lưu trữ trong một DBMS. Những lợi ích khi sử dụngDBMS bao gồm:

• Sự độc lập dữ liệu và truy cập hiệu quả. Các chương trình ứng dụng cơ sở dữliệu độc lập với những chi tiết của biểu diễn và lưu trữ dữ liệu. Lược đồ ngoàivà lược đồ khái niệm cung cấp sự độc lập với những quyết định về các lưu trữvật lý và thiết kế logic. Thêm nữa, DBMS cung cấp cách thức lưu trữ và các cơchế truy cập rất hiệu quả, bao gồm việc hỗ trợ các file có kích thước rất hơn,các cấu trúc chỉ mục và tối ưu hóa truy vấn.

• Giảm thời gian phát triển ứng dụng. Vì DBMS cung cấp các chức quan trọngcho các ứng dụng, như điều khiển tương tranh và khôi phục sự cố, các khả năngtruy vấn mức cao, vv…, người lập trình chỉ phải viết những đoạn mã chươngtrình đặc biệt cho từng ứng dụng. Thậm chí điều này cũng được hỗ trợ bởi cáccông cụ phát triển ứng dụng phù hợp do các nhà sáng chế ra DBMS cung cấp.

• Toàn vẹn dữ liệu và bảo mật. Cơ chế khung nhìn và các khả năng xác thựccủa DBMS cung cấp một cơ chế điều khiển truy cập mạnh mẽ. Thêm nữa,những cập nhật gây ra sự không nhất quán của dữ liệu có thể được phát hiện vàtừ chối bởi DBMS nếu người dùng chỉ rõ các ràng buộc toàn vẹn tương ứng.

• Quản trị dữ liệu. Bằng việc cung cấp một bộ khung giúp hỗ trợ một tập hợpdữ liệu lớn và nhiều người sử dụng, DBMS hỗ trợ việc duy trì và các công việcquản trị dữ liệu. Một DBA tốt có thể là bức bình phong ngăn chặn những truycập trái phép, và định kỳ sao lưu dữ liệu vv…

• Điều khiển tương tranh và khôi phục sự cố. DBMS hỗ trợ khai niệm giaodịch. Người dùng có thể viết các giao dịch như thể các chương trình của họđang được chạy độc lập trên cơ sở dữ liệu. DBMS thực thi các thao tác của cácgiao dịch một cách xen kẽ để nâng cao khả năng của hệ thống, nhưng các lịchtrình của chúng lại được đảm bảo rằng các thao tác xung đột không được phépdiễn ra đồng thời. Thêm nữa, DBMS duy trì một log để ghi lại những thay đổiđối với dữ liệu, và nếu hệ thống gặp sự cố, nó có thể khôi phục lại cơ sở dữ liệuđể nó trở về trạng thái nhất quán. Tức là, các thao tác của các giao dịch chưahoàn thành được làm lại để trạng thái cơ sở dữ liệu chỉ tương ứng với các giaodịch đã thành công. Vì thế, nếu mỗi giao dịch thành công khi thực hiện độc lậpđưa cơ sở dữ liệu về trạng thái nhất quán thì trạng thái cơ sở dữ liệu sau khikhôi phục sự cố cũng trở về trạng thái nhất quán.

• Nếu những lợi ích trên không quan trọng với ứng dụng của bạn, thì việc sửdụng một tập các file là giải phát tốt hơn vì việc duy trì và thực hiện trênDBMS phải trả giá thành cao hơn.

Độc lập dữ liệu logic là gì và vì sao nó quan trọng?

Dành cho bạn đọc.

29/470

Giải thích sự khác nhau giữa độc lập dữ liệu logic và độc lập dữ liệu vật lý?

Độc lập dữ liệu logic có nghĩa là người dùng được bảo vệ từ những thay đổi trong cấutrúc logic của dữ liệu, trong khi độc lập dữ liệu vật lý cách ly người dùng với nhữngthay đổi trong lưu trữ vật lý của dữ liệu. Chúng ta xem một ví dụ của độc lập dữ liệulogic trong câu trả lời của Bài 1.2. Xem xét quan hệ Students từ ví dụ này (và bây giờgiả sử rằng nó không được thay thế bằng hai quan hệ nhỏ hơn). Chúng ta có thể lựa chọnđể lưu trữ các bản ghi của quan hệ Students trong một heap file, cùng với một chỉ mụcphân cụm trên trường sname. Ngoài ra, chúng ta có thể lựa chịn để lưu trữ nó cùng vớimột chỉ mục trên trường gpa, hoặc tạo ra các chỉ mục rên cả hai trường này, hoặc lưu trữnó như một file được sắp xếp bằng gpa. Những cách lưu trữ này người dùng không nhìnthấy được, họ chỉ nhìn thấy quan hệ đơn giản là một tập các bản ghi. Điều này chính làsự độc lập dữ liệu vật lý.

Giải thích sự khác nhau giữa lược đồ ngoài, lược đồ trong, lược đồ khái niệm. Nhữnglược đồ khác nhau này liên quan đến khái niệm độc lập dữ liệu logic và độc lập dữ liệuvật lý như thế nào?

Dành cho bạn đọc.

Trách nhiệm của DBA là gì? Nếu giả sử rằng DBA không quan tâm đến các truy vấn,DBA vẫn cần hiểu về tối ưu hóa truy vấn? Vì sao?

DBA có nhiệm vụ sau:

• Thiết kế các lược đồ logic và vật lý, cũng như là những khung nhìn chủ yếu củalược đồ ngoài.

• Bảo mật và xác thực.• Sự sẵn sàng của dữ liệu và khôi phục sau sự cố.• Tinh chỉnh cơ sở dữ liệu: DBAM có nhiệm vụ phát triển cơ sở dữ liệu, cụ thể là

phát triển các lược đồ vật lý và lược đồ ngoài để đảm bảo thực hiện đượcnhững yêu cầu thay đổi theo thời gian của người dùng.

DBA cần hiểu về tối ưu hóa truy vấn ngay cả khi người này không quan tâm đến việcchạy những truy vấn nào vì anh ta có một số nhiệm vụ (thiết kế và điều chỉnh cơ sở dữliệu) liên quan đến tối ưu hóa truy vấn. Nếu DBA không hiểu về những truy vấn đượcsử dụng rộng rãi cần những gì cho thực thi, và DBMS sẽ tối ưu và thực hiện những truyvấn này như thế nào, anh ta sẽ không thể có những quyết định tốt khi thiết kế và điềuchỉnh cơ sở dữ liệu.

Scrooge McNugget muốn lưu trữ thông tin (names, addresses, descriptions) về chi trảcá nhân của ông. Không ngạc nhiên, ông muốn mua một hệ thống cơ sở dữ liệu. Để tiếtkiệm tiền, ông muốn mua một hệ thống với những chức năng cần thiết tối thiểu, và ônglên kế hoạch để sử dụng nó như ứng dụng chỉ chạy trên máy tính cá nhân của ông. Tất

30/470

nhiên, ông không lên kế hoạch để chia sẻ ứng dụng cho bất kỳ ai. Chỉ ra những đặc tínhcủa DBMS mà ông Scrooge cần, trong từng trường hợp, chỉ ra vì sao đặc trưng này cầnhoặc không cần phải mua.

• Khả năng bảo đảm an toàn.• Khả năng điều khiển truy cập đồng thời.• Khả năng khôi phục sau sự cố.• Cơ chế khung nhìn.• Ngôn ngữ truy vấn.

Dành cho bạn đọc.

Những thành phần nào sau đây có vai trò quan trọng tới biểu diễn thông tin về thế giớithực trong cơ sở dữ liệu? Giải thích tóm tắt.

1. Ngôn ngữ định nghĩa dữ liệu.2. Ngôn ngữ thực thi dữ liệu.3. Quản lý bộ đệm.4. Mô hình dữ liệu.

Hãy cùng chúng tôi bàn về những lựa chọn này.

• Ngôn ngữ định nghĩa dữ liệu quan trọng trong biểu diễn thông tin vì nó được sửdụng để biểu diễn các lược đồ logic và lược đồ ngoài.

• Ngôn ngữ thực thi dữ liệu được sử dụng để truy cập và cập nhật dữ liệu; nókhông quan trọng trong biểu diễn dữ liệu. (Tất nhiên, ngôn ngữ thực thi dữ liệuphải hiểu được dữ liệu đang được biểu diễn như thế nào, và phản chiếu điềunày trong các cấu trúc mà nó hỗ trợ).

• Quản lý bộ đệm không thực sự quan trọng trong biểu diễn vì nó mang nhữngtrang trên đĩa vào bộ nhớ chính, độc lập với việc dữ liệu được biểu diễn như thếnào.

• Mô hình dữ liệu là nền tảng để biểu diễn thông tin. Mô hình dữ liệu xác địnhcác chơ chế biểu diễn dữ liệu nào đang được DBMS hỗ trợ. Ngôn ngữ địnhnghĩa dữ liệu chỉ chỉ ta tập các cấu trúc ngôn ngữ dùng để biểu diễn dữ liệu củamột ứng dụng cụ thể.

Trình bày kiến trúc của một DBMS. Nếu hệ điều hành của bạn được nâng cấp để hỗtrợ một số chức năng mới trên các tệp tin của hệ điều hành, những tầng nào của DBMSchúng ta cần viết lại để tận dụng được các ưu điểm của chức năng mới này?

Dành cho bạn đọc

Trả lời các câu hỏi sau:

31/470

1. Giao dịch là gì?2. Vì sao DBMS chen vào các hoạt động của các giao dịch khác nhau, thay vì

thực hiện các giao dịch một cách tuần tự?3. Điều gì mà DBMS phải đảm bảo để thực hiện đồng thời nhiều giao dịch và

nhất quán cơ sở dữ liệu?4. Giải thích về giao thức khóa hai pha nghiêm ngặt.5. Đặc tính WAL là gì, và vì sao nó quan trọng?

Hãy cùng chúng tôi trả lời từng câu hỏi:

• Một giao dịch là một tập các thực thi được gộp lại thành một khối của mộtchương trình ứng dụng.

• Một DBMS thường được chia sẽ cho rất nhiều người dùng. Các giao dịch từnhững người dùng này có thể được thực thi xen kẽ để cải thiện thời gian thựchiện các truy vấn của người dùng. Bằng cách này, người dùng không phải đợinhững giao dịch của người dùng khác hoàn thành rồi mới đến giao dịch củamình được bắt đầu. Không thực hiện xen kẽ, nếu người dùng A thực hiện mộtgiao dịch nào đó mất 10s, và người dùng B bắt đầu thực hiện giao dịch củamình, người dùng B sẽ phải đợi 10s để giao dịch của người dùng A hoàn thành.

• DBMS phải đảm bảo rằng giao dịch được thực thi toàn bộ và độc lập với cácgiao dịch khác. Một tính chất quan trọng của giao dịch trong DBMS là tínhnguyên tử, và tính cô lập. Các giao dịch hoặc là thành công hoặc là thất bạihoàn toàn. Điều này đảm bảo tính nhất quán của cơ sở dữ liệu.

• Khóa hai-pha nghiêm ngặt sử dụng các khóa chia sẻ và khóa độc quyền để bảovệ dữ liệu. Một giao dịch phải nắm giữ tất cả các khóa cần thiết trước khi thựcthi và không giải phóng bất cứ khóa nào trước khi giao dịch kết thúc hoàn toàn.

• Đặc tính WAL ảnh hưởng đến chiến lược logging trong DBMS. WAL là viếttắt của Write- Ahead Log, có nghĩa là mỗi một thao tác viết lên cơ sở dữ liệuđều phải được ghi vào log (trên đĩa) trước khi nó thực sự xảy ra trong cơ sở dữliệu. Điều này bảo vệ được cơ sở dữ liệu nếu có sự cố xảy ra trong quá trìnhgiao dịch đang thực hiện. Bằng việc ghi lại những thay đổi vào trong log trướckhi những thay đổi này thực sự diễn ra, cơ sở dữ liệu biết được phải làm lạinhững thao tác nào để khôi phục sự cố. Ngược lại, nếu việc ghi vào log diễn rasau thì cơ sở dữ liệu sẽ không thể phát hiện được có những thay đổi nào đã xảyra trong quá trình khôi phục sự cố.

Bài tập lớn

Sử dụng trình duyệt Web để tìm kiếm tài liệu dạng HTML về Minibase. Cố gắng để cóđược kiến trúc tổng quan về nó.

Dành cho bạn đọc.

32/470

TÀI LIỆU THAM KHẢO

Quá trình phát triển của DBMS được trình bày trong [289]. Sử dụng các mô hình dữ liệuđể biểu diễn thế giới thực được trình bày trong [423], và [425] chứa nguyên tắc phânloại các mô hình dữ liệu. Ba mức trừu tượng được giới thiệu trong [186, 712]. Mô hìnhdữ liệu mạng được trình bày trong [186], và [775] trình bày một số hệ thống thương mạiđược xây dựng dựa trên mô hình này.

Những tài liệu khác về DBMS bao gồm [204, 245, 305, 339, 475, 574, 689, 747, 762].[204] cung cấp những thảo luận chi tiết về mô hình quan hệ và có những tài liệu thamkhảo đáng chú ý khác. [574] trình bày triển vọng của cách tiếp cận hướng đối tượng vàtham khảo tới một số hệ thống thương mại. [245] và [689] trình bày về các khái niệm hệthống cơ sở dữ liệu, bao gồm những thảo luận về các mô hình dữ liệu mạng và phân cấp.[339] trình bày nhấn mạnh sự kết nối giữa ngôn ngữ truy vấn cơ sở dữ liệu và ngôn ngữlập trình. [762] tập trung vào các mô hình dữ liệu. [747] cung cấp những trình bày chitiết nhất về các bài toán lý thuyết. Những tài liệu tập trung vào các khía cạnh lý thuyếtbao gồm [3, 45, 501].

33/470

Giới thiệu thiết kế cơ sở dữ liệuMô hình ER cho phép chúng ta biểu diễn dữ liệu trong thế giới thực bằng các đối tượngvà mối quan hệ giữa chúng, và nó được sử dụng rộng rãi như là bước đầu tiên trong thiếtkế cơ sở dữ liệu. Trong chương này, chúng tôi giới thiệu mô hình ER và bàn luận tại saochúng được sử dụng rộng rãi.

Chúng tôi bắt đầu phần tổng quan về thiết kế cơ sở dữ liệu trong phần 1 để làm rõ mụctiêu bàn luận của chúng tôi về mô hình ER. Trong sơ đồ lớn của quá trình thiết kế tổngquan, mô hình ER được sử dụng trong giai đoạn gọi là thiết kế cơ sở dữ liệu mức kháiniệm. Sau đó, phần 2, 3 và 4 sẽ giới thiệu về mô hình ER. Phần 5 sẽ bàn đến những vấnđề thiết kế cơ sở dữ liệu trong mô hình ER. Chúng tôi bàn tóm tắt về thiết kế cơ sở dữliệu mức khái niệm cho các ứng dụng lớn trong phần 6. Phần 7 biểu diễn tổng quan vềUML, phương pháp mô hình hóa và thiết kế tổng quát hơn mô hình ER.

Phần 8 giới thiệu một bài toán thực tế sẽ được nghiên cứu như một ví dụ xuyên suốtcuốn sách này. Đây là ví dụ về thiết kế cơ sở dữ liệu cho một cửa hàng Internet. Chúngtôi minh họa hai bước đầu tiên (bao gồm phân tích và thiết kế khái niệm) trong phần 8.Những chương cuối cùng sẽ mở rộng ví dụ này để trình bày những bước còn lại trongquá trình thiết kế.

Chúng ta ghi nhớ rằng có rất nhiều mô hình ER hiện nay đang được sử dụng, vàkhông có chuẩn nào thắng thế. Những trình bày trong chương này là những miêu tả vềmô hình ER phổ biến, bao gồm tập hợp những đặc tính phổ dụng nhất.

Thiết kế cơ sở dữ liệu và lược đồ ER

Quá trình thiết kế cơ sở dữ liệu có thể được chia thành sáu bước. Mô hình ER liên quanchặt chẽ tới ba bước đầu tiên.

1. Phân tích yêu cầu: Bước đầu tiên trong thiết kế ứng dụng cơ sở dữ liệu là phảihiểu được những dữ liệu nào cần lưu trữ trong cơ sở dữ liệu, những ứng dụngnào phải được xây dựng đầu tiên và những thao tác nào được sử dụng. Nói cáchkhác, chúng ta phải chỉ ra những gì người sử dụng muốn đối với cơ sở dữ liệu.Quá trình này chúng ta cần phải bàn luận với nhóm người dùng, nghiên cứuthực trạng và ghi nhận những mong muốn của người sử dụng, phân tích nhữngvăn bản có thể và những ứng dụng đang tồn tại của hệ thống để có thể xây dựngứng dụng thay thế tốt hơn. Một số phương pháp luận đã được đề xuất để tổchức và biểu diễn những thông tin tập hợp được, và một vài công cụ tự động đãđược phát triển để hỗ trợ quá trình này.

34/470

Các công cụ thiết kế cơ sở dữ liệu: Công cụ thiết kế được các nhà phát triểnRDBMS cung cấp. Ví dụ, chi tiết về công cụ thiết kế và phân tích của Sysbaseđược chỉ ra trong liên kết sau:

http://www.sybase.com/products/application tools

Chi tiết về những công cụ của Oracle được chỉ ra trong liên kết sau:

http://www.oracle.com/tools

2. Thiết kế cơ sở dữ liệu mức khái niệm: Những thông tin thu thập được trongbước phân tích yêu cầu được sử dụng để xây dựng phần biểu diễn dữ liệu trongcơ sở dữ liệu ở mức cao dựa vào những ràng buộc chúng ta đã biết về dữ liệu.Bước này được thực hiện sử dụng mô hình ER, hoặc mô hình dữ liệu mức caotương đương, và nó sẽ được bàn tới trong chương này. Mô hình ER là mộttrong một số những mô hình mức cao, còn gọi là mô hình ngữ nghĩa. Mụcđích của bước này là tạo ra cái nhìn đơn giản về dữ liệu để người sử dụng vàngười thiết kế dễ dàng hiểu được. Điều này giúp cho tất cả các đối tượng liênquan dễ dàng hiểu nhau trong quá trình thiết kế, kể cả những người không cóhiểu biết nền tảng về công nghệ thông tin. Ở thời điểm này, người thiết kế phảicó đủ thông tin để có thể xây dựng mô hình dữ liệu dựa vào hệ thống cơ sở dữliệu thương mại (thực tế, đó là mô hình quan hệ).

3. Thiết kế cơ sở dữ liệu logic: Chúng ta phải lựa chọn DBMS để thực hiệnnhững thiết kế cơ sở dữ liệu của chúng ta, và chuyển thiết kế cơ sở dữ liệu kháiniệm vào lược đồ cơ sở dữ liệu tương ứng trong mô hình dữ liệu của DBMS.Chúng tôi sẽ chỉ đề cập đến các DBMS quan hệ, và vì thế, công việc trongbước thiết kế cơ sở dữ liệu logic là chuyển từ lược đồ ER sang lược đồ cơ sở dữliệu quan hệ. Chúng tôi sẽ bàn chi tiết trong chương 3, kết quả thu được cuốicùng là lược đồ khái niệm, đôi khi gọi là lược đồ logic trong mô hình dữ liệuquan hệ.

Phía sau của thiết kế ER

Lược đồ ER chỉ là biểu diễn tương đối của dữ liệu, được xây dựng dựa trên đánh giá chủquan trong quá trình thu thập dữ liệu ở bước phân tích yêu cầu. Nhiều phân tích cẩn thậnhơn được xem xét trong lược đồ logic ở cuối bước 3. Khi chúng ta có lược đồ logic tốt,chúng ta phải xem xét điều kiện thực hiện và thiết kế lược đồ vật lý. Cuối cùng, chúngta phải cụ thể hóa những vấn đề về bảo mật và đảm bảo rằng những người sử dụng cóthể truy cập thấy thông tin mà họ cần. Ba bước thiết kế cơ sở dữ liệu còn lại được trìnhbày tóm tắt trong phần sau:

1. Tinh chỉnh lược đồ: Bước thứ 4 của thiết kế là phân tích tập hợp các quan hệtrong lược đồ cơ sở dữ liệu quan hệ để xác định các vấn đề cần thiết và xem xét

35/470

lại nó. Ngược lại với bước phân tích yêu cầu và thiết kế khái niệm, nơi tậptrung chủ yếu vào các đối tượng, thì bước này chúng ta phải thực hiện việc tinhchỉnh lược đồ bằng những hướng dẫn nặng về lý thuyết hơn. Chúng ta sẽ bànđến các dạng chuẩn của quan hệ và tìm hiểu sâu sắc hơn trong chương 19.

2. Thiết kế cơ sở dữ liệu vật lý: Trong bước này chúng ta phải xem xét khốilượng công việc mà cơ sở dữ liệu của chúng ta phải hỗ trợ và xem xét lại thiếtkế cơ sở dữ liệu để đảm bảo rằng nó thỏa mãn các điều kiện thực thi. Bước nàycó thể bao gồm việc xây dựng các chỉ số trên một số bảng và phân cụm một sốbảng, hoặc có thể bao gồm việc thiết kế lại đáng kể các phần trong lược đồ cơsở dữ liệu đạt được từ các bước thiết kế trước. Chúng tôi sẽ trình bày về thiếtkế cơ sở dữ liệu vật lý và điều chỉnh cơ sở dữ liệu trong chương 20.

3. Thiết kế ứng dụng và bảo mật: Bất kỳ dự án phần mềm nào phát triển trênDBMS cũng phải xem xét những khía cạnh của ứng dụng phía trước, và dựatrên cơ sở dữ liệu đã tồn tại trước đó. Phương pháp thiết kế như UML (phần 7)cố gắng để cụ thể hóa vòng tròn thiết kế và phát triển phần mềm khép kín. Tómlại, chúng ta phải xác định các thực thể (ví dụ: người dùng, nhóm người dùng,phòng/ban) và các quá trình cần thực hiện trong ứng dụng. Chúng ta phải biểudiễn các vai trò của mỗi thực thể trong tất cả các quá trình xử lý. Với mỗi vaitrò (role), chúng ta phải xác định các phần của cơ sở dữ liệu được phép hoặckhông được truy cập, và chúng ta phải đảm bảo rằng chúng chỉ được truy cậpvào các phần cần thiết. DBMS cung cấp một vài cơ chế để hỗ trợ bước này, vàchương 21 sẽ trình bày về vấn đề này.

Trong giai đoạn thực hiện này, chúng ta phải sử dụng ngôn ngữ lập trình để viết chươngtrình cho mỗi phần việc trong ứng dụng (ví dụ: Java), sử dụng DBMS để truy cập dữliệu. Chương 6 và 7 sẽ trình bày phần phát triển ứng dụng.

Tóm lại, việc chia thành 6 bước nên được xem như việc phân lớp quá trình thiết kế. Quátrình này có thể diễn ra tuần tự hoặc vòng tròn, lặp đi lặp lại.

Thực thể, thuộc tính và kiểu thực thể

Thực thể là tập đối tượng trong thế giới thực giúp ta phân biệt với các đối tượng khác.Ví dụ: đồ chơi (của Green Dragonzord), văn phòng, người quản lý của văn phòng, địachỉ nhà của người quản lý của văn phòng. Người ta thường xác định một tập các thực thểtương đương nhau. Tập hợp này được gọi là kiểu thực thể. Ghi nhớ rằng tập các thựcthể không cần được tách rời nhau; tập hợp những nhân viên làm việc trong văn phòngvà tập hợp những nhân viên trong phòng thiết bị có thể đều nằm trong tập hợp các nhânviên của công ty. Chúng ta có thể định nghĩa kiểu thực thể này là Employees chứa toànbộ nhân viên trong cả hai phòng.

Một thực thể được biểu diễn bằng một tập các thuộc tính. Tất cả các thực thể trong cùngmột kiểu phải có cùng tập thuộc tính. Những lựa chọn của chúng ta về tập thuộc tính

36/470

phản ánh mức chi tiết về dữ liệu mà chúng ta mong muốn được biểu diễn trong thực thể.Ví dụ, kiểu thực thể Employees có thể có các thuộc tính: Tên (Name), Số bảo hiểm xãhội (social security number -ssn). Trong trường hợp này, cơ sở dữ liệu lưu trữ thông tinvề tên, số bảo hiểm xã hội của các nhân viên. Tuy nhiên, chúng ta sẽ không lưu trữ đượcđịa chỉ của nhân viên (hoặc giới tính, tuổi).

Với mỗi thuộc tính trong kiểu thực thể, chúng ta phải xác định miền giá trị của nó. Vídụ, miền giá trị của thuộc tính Name trong kiểu thực thể Employees có thể có kiểu dữliệu là xâu ký tự, chiều dài tối đa 20 ký tự.

Để tránh nhầm lẫn, chúng ta giả sử rằng tên các thuộc tính của cùng kiểu thực thểkhông trùng nhau.Một ví dụ khác, nếu trong công ty có sự xếp hạng nhân viên từ 1 đến 10 thì cơ sở dữliệu phải có một thuộc tính để lưu thông tin này, có thể là thuộc tính rating và miền giátrị của nó sẽ là 1 đến 10. Thêm vào đó, với mỗi kiểu thực thể, chúng ta cần lựa chọnthuộc tính khóa cho nó. Khóa là tập tối thiểu các thuộc tính trong kiểu thực thể có khảnăng xác định duy nhất một thực thể (Hay nói cách khác, khóa phải có khả năng phânbiệt được thực thể này với thực thể khác). Có thể có nhiều hơn một khóa dự tuyển;chúng ta sẽ lựa chọn một trong số các khóa dự tuyển để làm khóa chính. Từ bây giờchúng ta sẽ giả sử rằng, mỗi kiểu thực thể chứa ít nhất một tập các thuộc tính để xácđịnh duy nhất một thực thể trong kiểu thực thể đó; gọi là tập thuộc tính khóa. Chúng tasẽ xem xét vấn đề này trong phần 4.3.

Kiểu thực thể Employees có các thuộc tính ssn, name, và rất nhiều các thuộc tính khácđược chỉ ra trong hình 1. Một kiểu thực thể được biểu diễn bằng một hình chữ nhật, mộtthuộc tính được biểu diễn bằng một hình bầu dục. Thuộc tính có gạch chân ở dưới làthuộc tính khóa. Trong hình 1, thuộc tính khóa là ssn.

Liên kết và kiểu liên kết

Liên kết là mối quan hệ giữa hai hoặc nhiều thực thể. Ví dụ, chúng ta có thể có liên kếtAttishoo làm việc trong văn phòng dược. Với nhiều thực thể cùng kiểu, chúng ta có tậpcác liên kết tương đương nhau tạo thành kiểu liên kết. Một kiểu liên kết có thể đượcxem như một tập của n- tupes:

{(e1,...,en) ∣ e1 ∈ E1,...,en ∈ En}

37/470

Tập thực thể Employees

Mỗi n-tupe biểu thị một mối liên kết bao gồm n thực thể từ e1 tới en, trong đó thực thểei thuộc tập thực thể Ei. Trong Hình 2 chúng ta chỉ ra kiểu liên kết Works_In, trong đómỗi liên kết chỉ ra một department mà một nhân viên làm việc.

Kiểu quan hệ Work_In

Một liên kết có thể có các thuộc tính mô tả. Thuộc tính mô tả được sử dụng để ghi lạinhững thông tin về mối liên kết, những thông tin này không nên để ở những thực thểthành phần tham gia trong mối liên kết. Ví dụ, chúng ta muốn ghi lại thời gian bắt đầulàm việc của Attishoo ở văn phòng dược từ tháng 1 năm 1991. Thông tin này được minhhọa trong hình 2 bằng việc thêm vào một thuộc tính since trong mối liên kết Works_In.Trong kiểu liên kết Works_In, ví dụ, mỗi liên kết Works_In phải được xác định duy nhấtbằng việc kết hợp ssn của thực thể Employee với did của thực thể Department. Vì thế,với mỗi cặp employee-department, chúng ta không thể có nhiều hơn một giá trị since.

Một minh họa của một kiểu liên kết là một tập các liên kết. Một minh họa có thể đượcxem như một 'snapshot' của một kiểu liên kết ở một thời điểm nào đó. Một minh họacủa kiểu liên kết Works_In được chỉ ra trong hình 3. Mỗi thực thể Employee được đạidiện bằng thuộc tính ssn của nó, và mỗi thực thể Department được đại diện bằng thuộctính did. Giá trị của thuộc tính since được chỉ ra bên trong mỗi liên kết. Những chúthích 'many-to-many' (nhiều-nhiều) và 'total participation' (lực lượng tham gia toàn bộ)sẽ được trình bày chi tiết trong phần sau, khi chúng tôi bàn về những ràng buộc toànvẹn.

38/470

Một minh họa của kiểu liên kết Works_In

Một ví dụ khác của lược đồ ER, giả sử rằng mỗi Department có một vài vị trí khác nhauvà chúng ta muốn ghi lại vị trí văn phòng của từng nhân viên làm việc. Mối liên kết nàylà mối liên kết bậc 3 vì chúng ta phải ghi lại mối liên quan giữa Employee, Departmentvà Location. Kiểu liên kết Works_In được biến thể thành kiểu liên kết Work_In2, lượcđồ ER chỉ ra trong Hình 4.

Các kiểu thực thể tham gia trong một kiểu liên kết không nhất thiết phải là hai kiểuthực thể khác nhau; đôi khi tồn tại kiểu liên kết giữa hai thực thể cùng kiểu. Ví dụ, xemxét mối liên kết Reports_To được chỉ ra trong hình 5. Vì những nhân viên có thể báocáo tới những nhân viên khác, nên tất cả các liên kết trong Reports_To ở dạng (emp1,emp2), nơi mà cả hai thực thể emp1 và emp2 đều là thực thể của Employees. Tuy nhiên,chúng đóng vai trò khác nhau: emp1 báo cáo tới người quản lý là emp2, điều này phảnánh vai trò của người quản lý (supervisor) và nhân viên dưới quyền (subordinate), hình5. Nếu một kiểu thực thể có nhiều hơn một vai trò, thì vai trò này được thể hiện trongthuộc tính định danh. Ví dụ, mối liên kết Reports_To có những thuộc tính liên quan tớissn của người quản lý và ssn của nhân viên cấp dưới và tên của các thuộc tính này làsupervisor_ssn và subordinate_ssn.

Kiểu liên kết bậc 3

39/470

Kiểu liên kết Reports_To

Những đặc trưng khác của mô hình ER

Chúng ta xem xét một số các thành phần khác của mô hình ER để có thể biểu diễn đượccác đặc điểm đặc biệt của dữ liệu. Khả năng biểu diễn tốt của mô hình ER là lý do chínhkhiến nó được sử dụng rộng rãi.

Ràng buộc khóa

Xem xét mối liên kết Works_In trong hình 2. Một nhân viên có thể làm việc trong nhiềuphòng, và một phòng có thể có nhiều nhân viên làm việc. Nhân viên 231-31-5368 đanglàm việc cho phòng 51 từ 3/3/93 và phòng 56 từ 2/2/92. Phòng 51 có 2 nhân viên.

Bây giờ, chúng ta xem xét một kiểu liên kết khác gọi là Manages (quản lý) giữa hai kiểuthực thể Employees và Departments với nguyên tắc quản lý là mỗi một phòng có nhiềunhất một người quản lý và một nhân viên có thể quản lý nhiều hơn một phòng. Sự giớihạn mỗi phòng có nhiều nhất một người quản lý là một ví dụ về ràng buộc khóa, và nóngụ ý rằng mỗi thực thể Department xuất hiện ít nhất một mối liên kết Manages trongbất kỳ minh họa nào của Manages. Giới hạn này được chỉ ra trong lược đồ ER của hình6 thông qua mũi tên từ Departments tới Manages. Theo hình vẽ, gốc mũi tên đặt ở thựcthể Departments, có nghĩa là có duy nhất một liên kết giữa thực thể Departments vớiManages.

Ràng buộc khóa trên Manages

40/470

Minh họa của kiểu liên kết Manages

Kiểu liên kết như Manages đôi khi được gọi là kiểu liên kết một-nhiều (one-to-many),để chỉ ra rằng một Employee có thể kết hợp với nhiều Departments (tùy thuộc vàokhả năng của người quản lý), ngược lại, mỗi Department chỉ có thể kết hợp với mộtEmployees như là người quản lý của nó. Ngược lại, kiểu liên kết Works_In, mỗiEmployee được phép làm việc cho một số Departments và một Department có thể cónhiều Employees làm việc, được gọi là kiểu liên kết nhiều-nhiều.

Nếu ta thêm một giới hạn với mối liên kết Manages là: mỗi nhân viên có thể quảnlý nhiều nhất một phòng, thì trong hình 6 mô hình sẽ phải thêm vào mỗi mũi tên từEmployees tới Manages . Kiểu liên kết này trở thành kiểu liên kết 1-1.

Ràng buộc khóa trên kiểu liên kết bậc 3

Chúng ta có thể mở rộng quy định này với những kiểu liên kết bậc 3, gồm ba kiểu thựcthể trở lên: Nếu kiểu thực thể E có ràng buộc khóa trên kiểu liên kết R, mỗi thực thểtrong minh họa của E xuất hiện trong ít nhất một liên kết của R. Để xác định ràng buộckhóa trên kiểu thực thể E trong kiểu liên kết R, chúng ta vẽ một mũi tên từ E đến R.

Trong hình 8 chúng ta chỉ ra kiểu liên kết bậc 3 với những ràng buộc khóa. Mỗi nhânviên làm việc trong nhiều nhất một phòng và chỉ ở một địa điểm duy nhất. Hình 9 minhhọa kiểu liên kết Works_In3. Ghi nhớ rằng mỗi một Department có thể liên kết với mộtsố Employees và Locations, và mỗi Location có thể liên kết với một vài Departmentsvà Employees; tuy nhiên, mỗi Employee chỉ liên kết với duy nhất một Department vàLocation.

41/470

Mối liên kết bậc 3 cùng với ràng buộc khóa

Các ràng buộc về lực lượng tham gia liên kết

Ràng buộc khóa trên Manages cho chúng ta biết rằng một Department có nhiều nhấtmột người quản lý. Một câu hỏi tự nhiên là có phải tất cả các Department đều phải cómột người quản lý không. Chúng ta cứ giả sử rằng tất cả các Department đều yêu cầucó một người quản lý thì sự tham gia của kiểu thực thể Departments trong kiểu liên kếtManages được gọi là toàn bộ (total). Sự tham gia không toàn bộ được gọi là bộ phận(partial). Ví dụ, sự tham gia của kiểu thực thể Employees trong kiểu liên kết Manages làtham gia bộ phận, vì không phải Employees nào cũng làm quản lý của Department.

Một minh họa của Works_In3

Xem xét kiểu liên kết Works_In, điều mong muốn tự nhiên là mỗi Employee làm việctrong ít nhất một Department và mỗi Department có ít nhất một Employee. Điều đó cónghĩa rằng lực lượng của cả hai kiểu thực thể Employees và Departments tham gia trongkiểu liên kết Works_In là toàn bộ. Lược đồ ER trong Hình 10 chỉ ra cả hai kiểu liên kếtManages và Works_In và những ràng buộc của nó. Nếu sự tham gia của kiểu thực thể

42/470

trong kiểu liên kết là toàn bộ, cả hai đường nối đều là đường đậm; không lệ thuộc vàobiểu diễn của đường mũi tên như đối với ràng buộc khóa. Minh họa của Works_In vàManages được chỉ ra trong hình 3 và 7 đều thỏa mãn những ràng buộc trong Hình 10.

Thực thể yếu

Ở phần trên, chúng ta đã giả sử rằng tất cả các thực thể đều có một tập thuộc tính đóngvai trò là khóa. Giả sử này không phải luôn đúng. Ví dụ, giả sử rằng một nhân viên muốnmua bảo hiểm cho những người phụ thuộc vào họ. Chúng ta mong muốn ghi lại nhữngthông tin liên quan đến bảo hiểm, bao gồm những ai là người phụ thuộc vào nhân viênđó. Thông tin này chỉ liên quan đến một nhân viên cụ thể. Nếu nhân viên đó hoàn thànhbảo hiểm, thì chúng ta cũng muốn những thông tin về những người liên quan cũng bịxóa khỏi cơ sở dữ liệu. Trong trường hợp này, chúng ta xác định người phụ thuộc dựavào tên của họ, vì chúng ta suy nghĩ rằng những người phụ thuộc vào một nhân viên nàođó sẽ không có tên trùng nhau. Vì thế, những thuộc tính của kiểu thực thể Dependents(Người phụ thuộc) có thể gồm pname và age. Thuộc tính pname không xác định mộtngười phụ thuộc duy nhất trong kiểu thực thể Dependents vì có thể có hai người phụthuộc vào hai nhân viên khác nhau có tên trùng nhau.

Manages và Works_In

Dependents là một ví dụ về kiểu thực thể yếu.Một thực thể yếu có thể được xác địnhduy nhất chỉ khi khóa chính của nó được tạo ra bằng sự kết hợp một vài thuộc tính củanó với thuộc tính khóa chính của kiểu thực thể chủ.

Một số giới hạn cần biết:

43/470

• Kiểu thực thể chủ và kiểu thực thể yếu phải tham gia trong kiểu liên kết một-nhiều (một thực thể chủ được tham gia cùng với một hoặc nhiều thực thể yếu,nhưng mỗi thực thể yếu chỉ có một thực thể làm chủ nó). Kiểu liên kết nàyđược gọi là kiểu liên kết định danh (identifying relationship set) của kiểu thựcthể yếu.

• Kiểu thực thể yếu phải có lực lượng tham gia toàn bộ vào trong kiểu liên kếtđịnh danh.

Ví dụ, một thực thể Dependents có thể được xác định duy nhất chỉ khi chúng ta kết hợpthuộc tính pname với thuộc tính khóa của kiểu thực thể Employees. Tập thuộc tính xácđịnh của kiểu thực thể yếu được gọi là khóa thành phần (partial key). Trong ví dụ củachúng ta, thuộc tính pname là khóa thành phần của Dependents.

Kiểu thực thể yếu Dependents và liên kết của nó với Employees được chỉ ra trong hình11. Sự tham gia toàn bộ của Dependents trong Policy

Policy có thể được hiểu là Mối quan hệ (cha, mẹ, con cái…) giữa nhân viên và nhữngngười phụ thuộc vào họ. Thuộc tính cost của liên kết Policy trong Hình 11 dùng để lưulại khoản tiền được khấu trừ tương ứng với từng mối quan hệ (trong tính thuế thunhập).được chỉ ra bằng đường nối đậm giữa chúng. Mũi tên từ Dependents tới Policy chỉ rarằng chính xác một thực thể Dependents xuất hiện trong ít nhất một mối liên kếtPolicy. Để chỉ ra Dependents là thực thể yếu và Policy là kiểu liên kết định danh,chúng tôi vẽ cả hai với đường nét đậm. Để chỉ ra pname là khóa thành phần củaDependents, chúng ta gạch đường nét đứt dưới thuộc tính đó.

Kiểu thực thể yếu

Hệ thống phân cấp

Đôi khi, trong tự nhiên chúng ta cần phân lớp các thực thể trong một kiểu thực thể vàocác lớp con. Ví dụ, chúng ta muốn nói về kiểu thực thể Hourly_Emps (nhân viên làmviệc theo giờ) và kiểu thực thể Contract_Emps (nhân viên hợp đồng) để phân biệt vềhình thức thanh toán lương cho hai kiểu nhân viên này. Chúng ta có lẽ có các thuộc tínhhours_worked và hourly_wage để xác định cho thực thể Hourly_Emps và thuộc tínhcontractid cho thực thể Contract_Emps.

44/470

Chúng ta muốn tất cả các thực thể này đều thuộc về kiểu thực thể Employees, và chúngphải có tất cả các thuộc tính của Employees. Vì thế, những thuộc tính được xác địnhtrong thực thể Hourly_Emps là những thuộc tính của kiểu thực thể Employees cộng vớiHourly Emps. Chúng ta nói rằng những thuộc tính của kiểu thực thể Hourly_Emps đượckế thừa từ các thuộc tính của Employees, và Hourly_Emps ISA Employees. Hình 12minh họa hệ thống phân cấp này.

Kiểu thực thể Employees có lẽ được phân cấp sử dụng các điều kiện khác nhau. Ví dụ,chúng ta có thể có một tập các nhân viên như Senior_Emps. Chúng ta có thể sửa Hình12 để phản ánh những thay đổi bằng việc thêm vào một nút ISA thứ 2 như nút con củaEmployees và Senior Emps là con của nút này. Mỗi kiểu thực thể có thể được xa hơn,tạo ra một hệ cây ISA đa cấp.

Hệ thống phân cấp được biểu diễn bằng một trong hai cách:

• Employees được chia vào trong các lớp con. Chuyên biệt hoá là quá trình xácđịnh các tập con của một kiểu thực thể lớp cha (superclass)- kiểu thực thể cómột số các đặc tính phân biệt giữa thực thể này với thực thể khác. Thôngthường, kiểu thực thể lớp cha được định nghĩa trước, tiếp theo định nghĩa cáckiểu thực thể con, sau đó xác định các thuộc tính của các kiểu thực thể lớp convà kiểu liên kết của nó với kiểu thực thể lớp cha.

• Hourly_Emps và Contract_Emps được tổng quát hoá thành Employees. Mộtví dụ khác, hai kiểu thực thể Motorboats và Cars có thể được tổng quát thànhkiểu thực thể Motor Vehicles. Tổng quát hoá thực hiện việc xác định một sốđặc tính chung của tập các thực thể con và tạo ra thực thể mới xử lý các đặctính chung này. Thông thường, những kiểu thực thể lớp con được định nghĩatrước, lớp cha được định nghĩa sau, sau đó các kiểu liên kết được xác định.

Chúng ta có thể xác định hai kiểu của ràng buộc phản chiếu trong mô hình ISA, tênlà ràng buộc Overlap và Covering. Ràng buộc Overlapxác định có hay không hai lớpcon được phép nằm trong cùng một thực thể. Ví dụ, Attishoo có thể thuộc cả về thựcthể Hourly_Emps và Contract_Emps không? Bằng trực giác là không. Anh ấy có thểthuộc cả về thực thể Hourly_Emps và Contract_Emps không? Bằng trực giác là có.Chúng ta biểu diễn điều này bằng việc viết 'Contract_Emps OVERLAPS Senior Emps'.Nếu không có ghi chú này, chúng ta mặc định rằng kiểu thực thể không có ràng buộcOverlap.

45/470

Hệ thống phân cấp

Ràng buộc covering xác định có hoặc không một lớp cha chứa tất cả các thực thểtrong các lớp con. Ví dụ, tất cả các thực thể Empolyees thuộc về một lớp cha của nó?Bằng trực giác là không. Tất cả các thực thể Motor_Vehicles phải thuộc về thực thểMotorboats hoặc thực thể Cars? Bằng trực giác là có; đặc tính đặc trưng của những hệthống tổng quát hóa là tất cả những mô tả của lớp cha là mô tả của lớp con. Chúngta biểu diễn bằng việc viết 'Motorboats AND Cars COVER Motor_Vehicles.' Trongtrường hợp không có chú thích này, chúng ta mặc định rằng kiểu thực thể không có ràngbuộc covering; chúng ta có thể có những Motor Verhicles không phải là Motorboats,cũng không là Cars.

Có hai lý do chính cho việc xác định lớp con (bằng chuyên biệt hóa hoặc tổng quát hóa):

1. Chúng ta muốn thêm những thuộc tính biểu diễn vào các thực thể trong lớpcon. Ví dụ, thuộc tính hourly wages không cần thiết cho thực thểContract_Emps, vì lương của đối tượng này được xác định thông qua hợp đồngcá nhân.

2. Chúng ta muốn chỉ ra tập các thực thể tham gia trong một vài liên kết. Ví dụ,chúng ta có thể muốn xác định kiểu liên kết Manages giữa Senior_Emps vàDepartments để đảm bảo rằng chỉ có có những Senior Employees (nhân viêncao cấp) mới có thể là người quản lý.

46/470

Khối kết hợp

Như chúng ta đã định nghĩa ở trên, một kiểu liên kết sẽ được tạo thành giữa hai kiểu thựcthể. Nhưng đôi khi, chúng ta phải mô hình hóa một liên kết giữa tập hợp các thực thểvà các kiểu liên kết (relationships). Giả sử rằng chúng ta có kiểu thực thể là Projects vàmỗi một Project được tài trợ bằng một hoặc nhiều Departments. Kiểu quan hệ Sponsors(Tài trợ) biểu diễn thông tin này. Một Department tài trợ một Project, Department nàycó thể cử nhân viên để quản lý (monitor) việc tài trợ. Như thế, Monitors nên là kiểu liênkết giữa Sponsors (tốt hơn là Projects hoặc Departments) với Employees.

Tuy nhiên, như chúng ta đã định nghĩa thì kiểu liên kết được tạo thành giữa hai hoặcnhiều kiểu thực thể. Vì thế, để định nghĩa kiểu liên kết như là Monitors, chúng tôi giớithiệu một khả năng mới của mô hình ER, gọi là Khối kết hợp. Khối kết hợp cho phépchúng ta minh họa một kiểu liên kết (chỉ ra bằng hộp nét đứt) kết nối với một kiểu liênkết khác. Minh họa trong Hình 13, hộp nét đứt xung quanh Sponsors (và các kiểu thựcthể thành phần) sử dụng để biểu diễn Khối kết hợp. Điều này cho phép chúng ta xemSponsors như một kiểu thực thể tham gia trong kiểu liên kết Monitors.

Khi nào chúng ta nên sử dụng Khối kết hợp? Như ta đã phân tích, chúng ta sử dụng nókhi chúng ta cần biểu diễn một mối liên kết giữa các mối liên kết. Nhưng với những kiếnthức chúng ta đã học, chúng ta không thể biểu diễn được điều này nếu không sử dụngKhối kết hợp. Tuy nhiên, các bạn có thể đặt ra câu hỏi, tại sao trong ví dụ trên, chúng takhông biến Sponsors thành kiểu liên kết bậc ba?

Bởi vì, ở đây là hai kiểu liên kết bậc hai khác nhau, Sponsors và Monitors, mỗi kiểuliên kết có thuộc tính riêng của nó. Theo như minh họa, mối liên kết Monitors có mộtthuộc tính là Until để ghi lại ngày mà một nhân viên được cử là quản lý sự tài trợ. Sosánh thuộc tính này với thuộc tính Since của Sponsors, là ngày bắt đầu mà Departmenttài trợ cho Project. Sử dụng Khối kết hợp hay sử dụng kiểu liên kết bậc ba được cânnhắc bằng việc xem xét các ràng buộc tham chiếu của dữ liệu, giải thích trong 5.4.

47/470

Khối kết hợp

Thiết kế cơ sở dữ liệu mức khái niệm bằng mô hình ER

Quá trình xây dựng lược đồ ER phải thực hiện một số lựa chọn sau:

• Một khái niệm nào đó nên được mô hình hóa như một thực thể hay là mộtthuộc tính?

• Một khái niệm nào đó nên được mô hình hóa như một thực thể hay là một liênkết?

• Có những kiểu liên kết nào và các kiểu thực thể tham gia trong kiểu quan hệđó? Chúng ta nên sử dụng kiểu liên kết bậc hai hay bậc ba?

• Có nên sử dụng khối kết hợp hay không?

Chúng ta sẽ bàn những vấn đề này trong phần tiếp theo.

Thực thể hay thuộc tính

Trong khi xác định các thuộc tính của kiểu thực thể, nên tìm hiểu rõ ràng một đặc trưngdữ liệu nào đó nên là một thuộc tính hay là một kiểu thực thể. Ví dụ, chúng ta đề cậpđến việc thêm thông tin về địa chỉ vào kiểu thực thể Employees. Lựa chọn đầu tiên làta thêm một thuộc tính address. Lựa chọn này là thích hợp nếu chúng ta chỉ cần ghi lạimột địa chỉ ứng với một nhân viên, và coi rằng toàn bộ địa chỉ là một xâu ký tự. Lựachọn thứ hai là tạo ra một kiểu thực thể có tên Address, để ghi lại địa chỉ của nhân viênchúng ta sử dụng một liên kết giữa Employees và Address (ví dụ là Has_address). Lựachọn này phức tạp hơn nhưng là cần thiết trong hai trường hợp:

48/470

• Chúng ta phải ghi lại nhiều hơn một địa chỉ ứng với một nhân viên.• Chúng ta muốn ghi lại cấu trúc của địa chỉ trong lược đồ ER. Ví dụ, chúng ta

muốn chia địa chỉ rõ ràng thành: city (thành phố), nước (Country), và Zip_code(mã bưu chính), và thông tin về đường phố. Với cách thể hiện Address như làmột kiểu thực thể và các thuộc tính của nó, chúng ta có thể truy vấn thông tinvề tất cả các địa chỉ của một nhân viên nào đó.

Một ví dụ khác về mô hình hóa một khái niệm bằng một kiểu thực thể thay vì một thuộctính được đề cập trong kiểu liên kết (gọi là Works_In2) trong Hình 14.

Kiểu liên kết Works_In2

Kiểu liên kết Works_In2 khác với kiểu liên kết Works_In trong Hình 2 chỉ là thuộc tínhsince được thay bằng hai thuộc tính from và to. Trong trường hợp này, hai thuộc tínhtrên sẽ ghi lại toàn bộ quá trình một nhân viên làm việc cho một phòng nào đó. Bây giờ,chúng ta giả sử rằng một nhân viên có thể làm việc cho một phòng ở nhiều quãng thờigian khác nhau.

Khả năng này được biểu diễn trong lược đồ ER. Vấn đề ở đây là chúng ta muốn ghi lạimột số giá trị để biểu diễn thuộc tính của mỗi thể hiện của liên kết Works_In2. (Trườnghợp này tương tự với việc muốn ghi lại một vài địa chỉ ứng với một nhân viên). Chúngta có thể thực hiện điều này bằng việc sử dụng một kiểu thực thể là Duration, với cácthuộc tính là from và to, như trong Hình 15.

49/470

Kiểu liên kết Works_In4

Trong một số phiên bản của mô hình ER, một thuộc tính nào đó có thể mang nhiềuhơn một giá trị (còn gọi là thuộc tính đa trị). Với phiên bản này, chúng ta có thể xemDuration như là một thuộc tính đa trị của Work_In thay vì nó phải là một kiểu thực thểkết nối với kiểu liên kết Works_In như trên. Cách làm này có lẽ trực quan hơn là ta môhình hóa Duration như một kiểu thực thể. Tuy nhiên, khi đặt những giá trị của thuộc tínhnày vào mô hình quan hệ - mô hình không hỗ trợ thuộc tính có nhiều giá trị, thì cuốicùng lược đồ quan hệ của mô hình quan hệ cũng tương tự như là chúng ta xem Durationnhư một kiểu thực thể.

Thực thể hay liên kết

Xem xét một kiểu liên kết là Manages trong Hình 6. Giả sử rằng mỗi một người quản lýcủa Department được cung cấp một khoản tài chính (dbugget), như chỉ ra trong Hình 16(kiểu liên kết Manages được đổi tên thành Manages2).

Ở đó có nhiều nhất một Employee quản lý một Department, nhưng một Employee lại cóthể quản lý nhiều Departments, chúng ta lưu lại ngày bắt đầu làm quản lý và khoản tàichính của mỗi cặp người quản lý- phòng (manager-department). Cách tiếp cận này là tựnhiên nếu chúng ta giả sử rằng một người quản lý chỉ nhận một khoản tài chính ứng vớiphòng người ấy quản lý.

Nhưng điều gì sẽ xảy ra nếu chúng ta coi dbudget là tổng số tiền quản lý của một ngườiđối với tất cả các Department mà người đó quản lý? Trong trường hợp này, mỗi liên kếtManages2 ứng với một nhân viên làm quản lý sẽ có cùng giá trị trong trường dbudget,dẫn tới lưu trữ dư thừa cùng một thông tin. Vấn đề khác gặp phải nếu thiết kế như thếnày đó là nó dẫn tới sự sai lạc; nó chỉ ra một Budget (khoản tài chính) kết nối với mộtliên kết, trong khi khoản tài chính này liên quan thực sự đến một người quản lý.

Chúng ta có thể giải quyết vấn đề này bằng việc giới thiệu một kiểu thực thể mới gọi làManagers (có thể đặt sau Emloyees trong hệ thống ISA, để chỉ ra người quản lý cũng

50/470

là một nhân viên). Thuộc tính since và dbudget biểu diễn một thực thể Manager như dựđịnh. Tuy nhiên, trong khi tất cả người quản lý chỉ có một giá trị dbudget, nhưng lại cóthể có nhiều giá trị của ngày bắt đầu làm quản lý (since) ứng với mỗi Department. Trongtrường hợp này, dbudget là thuộc tính của Managers, nhưng since lại là thuộc tính củakiểu liên kết giữa Managers với Departments.

Thực thể hay liên kết

Biểu diễn tự nhiên thiếu chính xác của mô hình ER có thể dẫn đến khó khăn trong việcnhận ra những thực thể cơ bản, và chúng ta có thể sử dụng các thuộc tính gắn vào kiểuliên kết thay vì sử dụng những kiểu thực thể. Tóm lại, những lỗi trên sẽ dẫn đến lưu trữdư thừa cùng một thông tin và từ đó nảy sinh nhiều vấn đề. Chúng ta sẽ bàn đến dư thừathông tin và những vấn đề liên quan trong chương 19, và trình bày một công nghệ gọi làChuẩn hóa (Nomalization) để loại trừ dư thừa trong các bảng chứa dữ liệu.

Liên kết bậc hai hay bậc ba

Xem xét sơ đồ ER trong Hình 17. Nó mô hình hóa trường hợp một Employee có thể cómột vài Policies và mỗi Policy có thể thuộc về một số Employees, và mỗi Dependent cóthể có một số Policies.

Giả sử rằng, chúng ta có một số yêu cầu sau:

• Bất kỳ một Policy nào cũng không thể được hai hoặc nhiều hơn Employeescùng sở hữu.

• Policy nào cũng phải có Employees nào đó làm chủ.• Dependents là kiểu thực thể yếu, và mỗi một thực thể Dependent được xác định

duy nhất bằng thuộc tính pname kết hợp với thuộc tính policyid của thực thểPolicy.

Yêu cầu đầu tiên đề nghị rằng chúng ta phải thiết đặt một ràng buộc khóa lên trênPolicies trong liên kết với Covers, nhưng ràng buộc này không yêu cầu rằng một Policycó thể ảnh hưởng chỉ tới một Dependent. Yêu cầu thứ hai đề nghị chúng ta thiết đặt ràngbuộc tham gia toàn bộ lên Policies. Giải pháp này có thể chấp nhận nếu mỗi Policy ảnhhưởng tới ít nhất một Dependent. Yêu cầu thứ ba bắt buộc chúng ta sử dụng đến kiểuliên kết định danh.

51/470

Nếu bỏ qua yêu cầu thứ ba ở trên, cách tốt nhất để mô hình hóa trường hợp này là sửdụng hai kiểu liên kết bậc hai, chỉ ra trong Hình 18.

Ví dụ này có hai kiểu liên kết bao gồm liên quan đến Policies, và chúng ta cố gắng sửdụng một kiểu liên kết bậc ba (Hình 17) là không phù hợp. Tuy nhiên, có những trườnghợp ở đó một mối liên kết vốn đã liên quan đến nhiều hơn hai thực thể. Chúng ta đã nhìnthấy ví dụ trong Hình 4 và 15.

Policies được xem như một kiểu thực thể

Như là một ví dụ điển hình của mối liên kết bậc ba, kiểu thực thể Parts (Sản phẩm),Suppliers (Nhà cung cấp), và Departments (Phòng) và kiểu liên kết Contracts (Hợpđồng) cùng với thuộc tính biểu diễn qty gắn với Contracts. Một hợp đồng xác định rằngmột Nhà cung cấp sẽ cung cấp (một số lượng) Sản phẩm cho Phòng. Liên kết này khôngthể biểu diễn bằng một tập các liên kết bậc hai (không sử dụng Khối kết hợp). Với kiểuliên kết bậc hai, chúng ta có thể chỉ ra rằng một Nhà cung cấp 'có thể cung cấp' đích xácmột số Sản phẩm nào đó; một Phòng 'cần được cung cấp' đích xác một số Sản phẩm nàođó; một Phòng 'giao dịch trực tiếp' với đích xác một Nhà cung cấp nào đó. Tuy nhiên,không kết hợp những kiểu liên kết bậc hai này để biểu diễn một hợp đồng, vì ít nhất hailý do:

• Chúng ta không thể biểu diễn được mối liên kết đồng thời giữa ba kiểu thực thểnày. Thực tế rằng, một nhà cung cấp (S) có thể cung cấp sản phẩm (P), mộtPhòng cần một số sản phẩm (P), và Phòng (D) sẽ mua từ nhà cung cấp (S)những sản phẩm mà S cung cấp.

• Chúng ta không thể biểu diễn thuộc tính Qty một cách rõ ràng.

52/470

Khối kết hợp hay Kiểu liên kết bậc ba

Như chúng ta đã ghi chú trong Phần 4.5, lựa chọn giữa sử dụng Khối liên kết hay là kiểuliên kết bậc ba được xác định chủ yếu dựa vào tình trạng của liên kết giữa một kiểu liênkết với một kiểu thực thể. Lựa chọn này có thể cũng được định hướng bằng các ràngbuộc tham chiếu chúng ta đang muốn biểu diễn. Ví dụ, xem xét lược đồ ER chỉ ra trongHình 13. Theo lược đồ này, một Project có thể được tài trợ bằng bất kỳ Departments nào,một Department có thể tài trợ cho một hoặc nhiều Projects, và mỗi tài trợ (sponsorship)được một hoặc nhiều Employees điều hành. Nếu chúng ta không cần ghi lại thuộc tínhuntil của Monitors, thì chúng ta có thể sử dụng kiểu liên kết bậc ba như Sponsors2 trongHình 19.

Xem lại kiểu thực thể Policies

Xem xét ràng buộc: mỗi tài trợ của một Department cho một Project được điều hànhbằng nhiều nhất một nhân viên. Chúng ta thấy, chúng ta không thể biểu diễn được ràngbuộc này nếu chỉ sử dụng kiểu liên kết Sponsor2. Trong khi đó, ràng buộc này lại có thểdễ dàng biểu diễn bằng việc vẽ một mũi tên từ Khối liên kết Sponsors tới kiểu liên kếtMonitors như hình 13. Vì thế, khả năng biểu diễn các ràng buộc là một lý do nữa để sửdụng Khối kết hợp hay là kiểu liên kết bậc ba.

53/470

Sử dụng liên kết bậc ba thay vì Khối kết hợp

Thiết kế khái niệm cho các hệ thống lớn

Chúng ta đã tập trung trình bày những cấu trúc có thể trong mô hình ER để biểu diễn cáckhái niệm của ứng dụng và các mối liên kết giữa các khái niệm đó. Quá trình thiết kế cơsở dữ liệu mức khái niệm bao gồm nhiều công đoạn, không đơn thuần là việc sử dụnglược đồ ER để biểu diễn các phần nhỏ của ứng dụng. Trong các hệ thống lớn, có nhiềungười cùng tham gia thiết kế và viết chương trình ứng dụng. Sử dụng mô hình dữ liệumức cao (mức ngữ nghĩa) như lược đồ ER cho thiết kế khái niệm giúp cho những ngườithiết kế và những người sử dụng sau này có thể dễ dàng hiểu nhau và hiểu dữ liệu.

Khía cạnh quan trọng của quá trình thiết kế là phương pháp luận sử dụng Thiết kế vòngtròn để đảm bảo rằng người thiết kế tiếp nhận được tất cả các yêu cầu cần thiết của ngườisử dụng. Cách tiếp cận thông thường là những yêu cầu của các nhóm người sử dụngđược xem xét, bất kỳ những yêu cầu đối lập nhau được tìm hiểu và một tập hợp các yêucầu duy nhất được đưa ra ở cuối của quá trình phân tích yêu cầu. Đưa ra được một tậphợp các yêu cầu duy nhất này là một công việc khó, nhưng nó cho phép quá trình thiếtkế khái niệm và xây dựng lược đồ logic có thể bao quát được tất cả dữ liệu và ứng dụngtrong hệ thống.

Một cách tiếp cận khác là xây dựng các lược đồ khái niệm riêng rẽ cho từng nhóm ngườidùng và sau đó tích hợp những lược đồ con này lại. Để tích hợp nhiều lược đồ con,chúng ta phải xây dựng mối quan hệ tương quan giữa các thực thể, kiểu liên kết và cácthuộc tính và chúng ta phải giải quyết hàng loạt các vấn đề xung đột (ví dụ, xung đột vềtên, miền dữ liệu không tương ứng, khác nhau giữa các đơn vị đo sử dụng). Công việcnày là khó cho người đứng đầu. Trong một số trường hợp, việc tích hợp là không thể

54/470

tránh khỏi, ví dụ, khi một tổ chức được hợp nhất vào một tổ chức khác, những cơ sở dữliệu đang tồn tại phải được tích hợp.

UML

Có rất nhiều cách tiếp cận để thiết kế hệ thống phần mềm end-to-end, bao gồm tất cả cácbước từ xác định yêu cầu đến bước cuối cùng để hoàn thành ứng dụng, bao gồm luồngtiến trình, giao diện người dùng, và rất nhiều khía cạnh của hệ thống phần mềm để cóđược cơ sở dữ liệu tốt. Trong phần này, chúng ta trình bày tóm tắt về cách tiếp cận đangtrở nên phổ biến, gọi là cách tiếp cận UML.

UML, giống như mô hình ER, có một đặc trưng đáng chú ý là cấu trúc của nó có thể vẽnhư những lược đồ. Nó chứa đựng một phổ rộng hơn của quá trình thiết kế phần mềmhơn là mô hình ER.

• Mô hình hóa nghiệp vụ (Bussiness Modeling): Đích của quá trình này là biểudiễn các quy tắc nghiệp vụ trong quá trình phát triển ứng dụng phần mềm.

• Mô hình hóa hệ thống (System Modeling): Những hiểu biết về quá trìnhnghiệp vụ được sử dụng để xác định các yêu cầu cho phần ứng dụng. Một phầncủa tập hợp yêu cầu là yêu cầu của cơ sở dữ liệu.

• Mô hình hóa cơ sở dữ liệu khái niệm (Conceptual Database Modeling): Bướcnày giúp tạo ra lược đồ ER cho cơ sở dữ liệu. Với mục đích này, UML cungcấp nhiều cấu trúc song song với các cấu trúc của mô hình ER.

• Mô hình hóa cơ sở dữ liệu vật lý (Physical Database Modeling): UML cũngcung cấp cách biểu diễn bằng hình tượng cho quá trình thiết kế cơ sở dữ liệuvật lý, như tạo ra các không gian bảng và các chỉ số (Chúng ta sẽ bàn về thiếtkế cơ sở dữ liệu vật lý trong những chương sau, nhưng sẽ không đề cập đến cấutrúc UML).

Có rất nhiều loại của lược đồ trong UML. Lược đồ Use case (Trường hợp sử dụng) biểudiễn các hành động hệ thống thực hiện để phản hồi các yêu cầu của người dùng, vànhững người tham gia trong những hành động này. Những lược đồ này cũng xác địnhchức năng mở rộng mà người dùng mong muốn hệ thống hỗ trợ.

Lược đồ Activity (Hoạt động) chỉ ra một luồng các hoạt động trong quá trình nghiệpvụ. Lược đồ Statechart biểu diễn các hoạt động bên trong giữa các đối tượng hệ thống.Những lược đồ sử dụng trong mô hình nghiệp vụ và mô hình hệ thống sẽ biểu diễnnhững chức năng bên trong thực hiện như thế nào, bao gồm những quy tắc nghiệp vụ vàcác tiến trình của hệ thống.

Lược đồ Class (Lớp) tương tự như lược đồ ER, mặc dù chúng chủ yếu đề cập để môhình hóa các thực thể ứng dụng (các thành phần quan trọng của chương trình) và mốiquan hệ logic giữa các thực thể đó.

55/470

Cả kiểu thực thể và kiểu liên kết có thể được biểu diễn như các lớp trong UML, cùng vớicác ràng buộc khóa, kiểu thực thể yếu, và hệ thống phân cấp. Khái niệm liên kết được sửdụng khác một chút trong UML, và những liên kết trong UML đều là bậc hai. Điều nàyđôi khi dẫn đến nhầm lẫn nếu kiểu liên kết trong lược đồ ER có ba hoặc nhiều hơn cáckiểu thực thể được biểu diễn trực tiếp trong UML. Nhầm lẫn này không xuất hiện nếuchúng ta hiểu rằng tất cả các kiểu liên kết (theo cách hiểu trong mô hình ER) được biểudiễn như là các lớp trong UML; liên kết UML bậc hai chỉ tập trung biểu diễn những liênkết giữa các kiểu thực thể và các kiểu liên kết trong lược đồ ER.

Kiểu liên kết cùng với các ràng buộc khóa thường được các lược đồ UML bỏ qua vàkiểu liên kết được chỉ ra bằng các liên kết trực tiếp giữa các kiểu thực thể. Ví dụ, xemxét Hình 6, biểu diễn UML của lược đồ ER này sẽ có một lớp cho Employees, một lớpcho Departments và kiểu liên kết Manages được chỉ ra bằng liên kết giữa hai lớp này.Liên kết này có thể được gắn nhãn với tên và các thông tin khác để chỉ ra rằng mộtPhòng có thể có duy nhất một người quản lý.

Như chúng ta sẽ nhìn thấy trong chương 3, các lược đồ ER được chuyển vào mô hìnhquan hệ bằng cách ánh xạ mỗi kiểu thực thể vào một bảng và mỗi kiểu liên kết vào mộtbảng. Xa hơn nữa, chúng ta sẽ xem phần 3.5.3, bảng tương ứng với kiểu liên kết một-nhiều được bỏ qua và thêm vào một số thông tin về kiểu liên kết này vào một bảng liênquan trong liên kết. Vì thế, lược đồ Lớp liên quan chặt chẽ đến các bảng được tạo rabằng việc ánh xạ lược đồ ER.

Thực vậy, tất cả các lớp trong lược đồ lớp UML được ánh xạ vào một bảng trong lược đồcơ sở dữ liệu UML liên quan. Lược đồ database (Cơ sở dữ liệu) của UML chỉ ra các lớpđược biểu diễn như thế nào trong cơ sở dữ liệu và những chi tiết về cấu trúc của cơ sở dữliệu như là các ràng buộc tham chiếu và các chỉ số. Liên kết (UML's 'relationships') giữacác lớp UML dẫn đến hàng loạt các ràng buộc tham chiếu giữa các bảng liên quan. Rấtnhiều chi tiết trong mô hình quan hệ (ví dụ: khung nhìn (Views), khóa ngoại (foreignkeys), những trường cho phép rỗng (null-allowed fields)) và những lựa chọn khi thiết kếvật lý (ví dụ, các trường được chọn làm chỉ số) có thể được mô hình hoá trong lược đồcơ sở dữ liệu UML.

Các thành phần của lược đồ UML mô tả những khía cạnh lưu trữ của cơ sở dữ liệu, nhưnhững khônggian bảng (tablespaces) và phân vùng cơ sở dữ liệu (database partitions),cũng như là các giao diện để ứng dụng truy cập cơ sở dữ liệu. Cuối cùng, lược đồDeployment (triển khai) chỉ ra những khía cạnh phần cứng của hệ thống.

Mục đích của chúng tôi trong quyển sách này là tập trung vào lưu trữ dữ liệu trong cơ sởdữ liệu và các vấn đề thiết kế liên quan. Cuối cùng, chúng ta thảo luận một cách nhìn vềcác bước phải thực hiện khi thiết kế và phát triển phần mềm. Thêm vào đó, những thảoluận về UML, những trình bày trong phần này được sử dụng để giải quyết các vấn đềgặp phải khi thiết kế hệ thống lớn. Chúng tôi hy vọng rằng điều này sẽ giúp người đọc

56/470

hứng thú trong những phần trình bày về thiết kế phần mềm và những bàn luận về nhữngvấn đề khác để hoàn thành thiết kế tổng quan.

Trường hợp nghiên cứu: Cửa hàng Internet

Chúng tôi giới thiệu một minh hoạ, trường hợp nghiên cứu này sẽ được làm ví dụ trongtoàn bộ cuốn sách. Công ty DBDudes, là một hãng tư vấn cơ sở dữ liệu nổi tiếng, đãđược mời đến để giúp đỡ công ty B&N để thiết kế và thực thi cơ sở dữ liệu của công tynày. B&N là một kho sách lớn, đặc biệt là các sách về đua ngựa, và họ quyết định đưanhững quyển sách này lên mạng. Công ty DBDudes đầu tiên xác định rằng B&N sẵnsàng trả kinh phí cho họ, sau đó lập lịch cho bữa ăn trưa - B&N phải thanh toán, tiếp đếnlà thực hiện phân tích các yêu cầu.

Phân tích các yêu cầu

Người chủ của B&N, không giống rất nhiều người cần cơ sở dữ liệu, có suy nghĩ rấtrộng về những điều anh ấy muốn và viết trong một bản yêu cầu ngắn gọn:

"Tôi muốn những khách hàng của tôi có thể xem được danh mục các quyển sách và đặtmua chúng trên Internet. Hiện nay, tôi nhận những đơn đặt hàng bằng điện thoại. Tôi cócác khách hàng là các tập thể, họ gọi điện cho tôi và cung cấp số ISBN của quyển sáchvà số lượng; họ thường thanh toán bằng thẻ tín dụng. Sau đó, tôi chuẩn bị những quyểnsách họ đặt. Nếu tôi không có đủ số lượng sách trong kho, tôi đề nghị nhà xuất bản bổsung và hoãn trả hàng cho khách cho tới khi tôi có đủ số lượng; Tôi muốn chuyển cáchoá đơn của cùng một khách hàng một lần. Danh mục bao gồm tất cả các quyển sáchmà tôi bán. Với mỗi quyển sách, danh mục có chứa thông tin về: số ISBN, tiêu đề, tácgiả, giá bìa, giá bán, năm xuất bản. Hầu hết khách hàng của tôi là những khách quen, tôimuốn ghi lại thông tin về tên, địa chỉ của họ. Những khách mới phải gọi trước cho tôivà đăng ký một tài khoản trước khi họ muốn sử dụng website của tôi.

Trên website mới, khách hàng được xác định bằng một định danh duy nhất. Sau đó, họcó thể duyệt danh mục sách và đặt mua chúng trực tuyến."

Hãng tư vấn DBDudes nhanh chóng thu thập yêu cầu và trở lại văn phòng để phân tíchnhững thông tin này.

Thiết kế khái niệm

Trong bước thiết kế khái niệm, DBDudes xây dựng biểu diễn mức cao của dữ liệu bằngnhững thuật ngữ của mô hình ER. Thiết kế đầu tiên này được chỉ ra trong Hình 20.Những quyển sách và khách hàng được mô hình hoá như là các thực thể và liên kết vớinhau thông qua kiểu liên kết Orders (Đặt hàng). Với mỗi đơn đặt hàng, những thuộc tínhsau được lưu trữ: Quantity (Số lượng), Order date (Ngày đặt hàng), và Ship Date (Ngày

57/470

chuyển hàng); nếu Ship Date bằng giá trị rỗng (Null), có nghĩa là cho đến nay, đơn đặthàng này vẫn chưa được chuyển.

Lược đồ ER của thiết kế ban đầu

Đến thời điểm này, DBDudes tiến hành xem xét lại các thiết kế bên trong và có một sốcâu hỏi đặt ra. Để bảo đảm được các ý kiến, chúng ta sẽ coi thiết kế của người đứng đầunhóm thiết kế như là Dule 1 và người kiểm tra lại như là Dule 2.

Dule 2: Điều gì xảy ra nếu một khách hành đặt hai hoá đơn cho cùng một quyển sáchtrong cùng một ngày?

Dule 1: Hoá đơn đầu tiên được tiếp nhận bằng cách tạo ra một liên kết Orders mới vàhoá đơn thứ hai được tiếp nhận bằng cách cập nhật giá trị cho thuộc tính Quatity trongliên kết này.

Dule 2: Điều gì xảy ra nếu một khách hàng đặt hai hoá đơn cho hai quyển sách khácnhau trong một ngày?

Dule 1: Không vấn đề. Mỗi trường hợp của liên kết Orders thiết lập một mối liên kếtgiữa khách hàng và một quyển sách khác (sẽ có hai liên kết Orders sinh ra trong trườnghợp này- mỗi quyển sách khác nhau ứng với một liên kết khác nhau).

Dule 2: Ah, điều gì xảy ra nếu một khách hàng đặt hai hoá đơn cho cùng một quyểnsách trong hai ngày khác nhau?

Dule 1: Chúng ta có thể sử dụng thuộc tính Order Date của liên kết Orders để phân biệthai hoá đơn.

Dule 2: Oh. Không được. Hai thuộc tính khoá của hai kiểu thực thể Customers và Booksđược kết hợp thành tập thuộc tính khoá của kiểu liên kết Orders. Vì thế, với thiết kế này

58/470

không cho phép một khách hàng đặt nhiều hoá đơn cho cùng một quyển sách, cho dù làcác ngày khác nhau.

Dule 1: Ah, bạn đúng. B&N có lẽ không quan tâm đến, chúng tôi sẽ xem lại.

DBDudes quyết định thực hiện giai đoạn thiết kế tiếp theo, thiết kế cơ sở dữ liệu logic;chúng ta sẽ tiếp tục trong phần 3.8.

Câu hỏi tổng kết

Câu trả lời của các câu hỏi tổng kết có thể được tìm thấy trong các phần sau:

• Các bước chính trong thiết kế cơ sở dữ liệu. Mục đích của từng bước là gì?Bước nào chủ yếu sử dụng mô hình ER? (Phần 1)

• Định nghĩa các thuật ngữ: thực thể, kiểu thực thể, thuộc tính, khóa. (Phần 2)• Định nghĩa các thuật ngữ: liên kết, kiểu liên kết, thuộc tính mô tả. (Phần 3)• Định nghĩa các loại ràng buộc và ví dụ của từng loại: ràng buộc khóa, ràng

buộc tham gia. Thực thể yếu là gì? Hệ thống phân cấp là gì? Khối kết hợp làgì? Cung cấp một ví dụ ứng với mỗi khái niệm này. (Phần 4)

• Những hướng dẫn nào bạn sẽ sử dụng cho các lựa chọn khi thiết kế lược đồER: Sử dụng thuộc tính hay kiểu thực thể, kiểu thực thể hay kiểu liên kết, kiểuliên kết bậc hai, bậc ba, hay khối kết hợp. (Phần 5)

• Vì sao việc thiết kế cơ sở dữ liệu cho các hệ thống lớn lại rất khó? (Phần 6)• UML là gì? Làm thế nào để thiết kế cơ sở dữ liệu được đặt thích hợp vào thiết

kế tổng thể của hệ thống phần mềm dữ liệu tập trung (data-intensive softwaresystem)? UML liên quan tới lược đồ ER như thế nào? (Phần 7)

Bài tập

Giải thích tóm tắt các thuật ngữ sau: thuộc tính, miền xác định, thực thể, liên kết, kiểuthực thể, kiểu liên kết, liên kết một-nhiều, liên kết nhiều-nhiều, ràng buộc tham gia, ràngbuộc Overlap, ràng buộc Covering, kiểu thực thể yếu, khối kết hợp.

Giải thích các khái niệm:

• Thuộc tính – là tính chất hoặc biểu diễn của một thực thể. Một thực thểEmployee có thể có các thuộc tính biểu diễn tên, lương… của nhân viên.

• Miều giá trị – là tập các giá trị có thể có của một thuộc tính.• Thực thể – một đối tượng trong thế giới thực được phân biệt với các đối tượng

khác.• Liên kết – là mối liên quan giữa hai hay nhiều thực thể.• Kiểu thực thể – là tập các thực thể tương đương nhau, ví dụ các nhân viên trong

cùng công ty.

59/470

• Kiểu liên kết – là tập các liên kết tương đương nhau.• Liên kết một-nhiều – ràng buộc khóa chỉ ra rằng một thực thể có thể có liên kết

với nhiều thực thể khác. Một ví dụ về liên kết một-nhiều là: một nhân viên chỉlàm việc cho một phòng, và một phòng có nhiều nhân viên làm việc.

• Liên kết nhiều-nhiều – ràng buộc khóa chỉ ra rằng nhiều thực thể có thể liên kếtvới nhiều thực thể khác. Ví dụ về liên kết nhiều-nhiều là nhân viên và sở thíchcủa họ: một nhân viên có thể có nhiều sở thích và một sở thích có thể đượcnhiều nhân viên thích.

• Ràng buộc tham gia – một ràng buộc tham gia chỉ ra số lượng các thực thểtham gia vào trong một liên kết. Ví dụ, tất cả các thực thể phòng có một thựcthể quản lý. Các ràng buộc tham dự có thể là toàn bộ hoặc bộ phận. Ràng buộctham gia toàn bộ nói rằng tất cả các phòng có một quản lý. Ràng buộc tham giabộ phận nói rằng không phải tất cả các nhân viên đều là quản lý.

• Ràng buộc Overlap – trong phân cấp ISA, một ràng buộc overlap chỉ ra rằng cóhay không hai lớp con được phép nằm trong cùng một thực thể.

• Ràng buộc Covering – trong phân cấp ISA, ràng buộc covering chỉ ra rằng cóhay không một lớp cha chứa tất cả các thực thể trong lớp con. Ví dụ, kiểu thựcthể Employees có hai lớp con là HourlyEmployee và SalaryEmployee, khôngtồn tại một thực thể Employee nào không thuộc một trong hai lớp con trên.

• Kiểu thực thể yếu – một thực thể không thể được xác định nếu không chỉ rathuộc tính đóng vai trò là khóa chính của thực thể chủ của nó. Ví dụ: thực thểngười phụ thuộc- phụ thuộc vào thực thể nhân viên.

Khối kết hợp – đặc tính của mô hình ER cho phép một kiểu liên kết được tham gia vàomột kiểu liên kết khác. Điều này chỉ ra trong lược đồ ER bằng cách vẽ một hình chữnhật gạch nét đứt bao quanh khối kết hợp

Cơ sở dữ liệu của một trường đại học có chứa thông tin về các giáo sư (định danh bằngsố bảo hiểm xã hội, ssn) và các khóa học (định danh bằng courseid). Các giáo sư dạycác khóa học; được liên kết với nhau bằng kiểu liên kết Teaches. Với mỗi trường hợp,vẽ lược đồ ER để biểu diễn (giả sử rằng không có những ràng buộc khác).

1. Nhiều giáo sư có thể dạy cùng một khóa học trong một vài học kỳ, và chúngphải được ghi lại.

2. Nhiều giáo sư có thể dạy cùng một khóa học trong một vài học kỳ, và chỉ cókhóa học gần đây nhất phải ghi lại. (Giả sử điều kiện này áp dụng cho tất cả cácyêu cầu tiếp theo.)

3. Tất cả các giáo sư phải dạy một vài khóa học.4. Tất cả giáo sư chỉ dạy duy nhất một khóa học (không nhiều hơn, không ít hơn).5. Tất cả giáo sư chỉ dạy duy nhất một khóa học (không nhiều hơn, không ít hơn),

và tất cả khóa học phải được vài giáo sư dạy.6. Bây giờ giả sử rằng, các khóa học có thể được một nhóm giáo sư cùng tham gia

dạy, nhưng không có giáo sư nào trong nhóm có thể dạy toàn bộ khoá học. Để

60/470

mô hình hoá trường hợp này, bạn có thể bổ sung thêm kiểu liên kết và kiểuthực thể nếu cần thiết.

Trả lời: Dành cho độc giả.

Xem xét các thông tin sau về cơ sở dữ liệu của một trường đại học:

• Giáo sư có có các thông tin sau: số bảo hiểm xã hội, tên, tuổi, chức danh và mộtlĩnh vực nghiên cứu đặc biệt.

• Dự án có mã số dự án, tên người bảo trợ, ngày bắt đầu, ngày kết thúc và ngânsách dự thảo.

• Sinh viên sau đại học có thông tin về số bảo hiểm xã hội, tên, tuổi, và chươngtrình học (thạc sỹ hay nghiên cứu sinh).

• Mỗi dự án được một giáo sư quản lý (đứng đầu dự án).• Mỗi dự án được một hoặc nhiều giáo sư tham gia làm việc (cộng tác viên).• Một giáo sư có thể quản lý hoặc cộng tác trong nhiều dự án.• Mỗi một dự án được một hoặc nhiều sinh viên sau đại học làm việc (những

người hỗ trợ nghiên cứu của dự án).• Khi những sinh viên sau đại học làm việc cho một dự án, giáo sư phải quản lý

công việc họ làm trong dự án đó. Sinh viên sau đại học có thể làm việc chonhiều dự án, ứng với mỗi một dự án họ có một giáo sư quản lý riêng.

• Các bộ môn có thông tin về mã số, tên, trụ sở chính.• Các bộ môn có một giáo sư đứng đầu điều hành.• Các giáo sư có thể làm việc trong một hoặc nhiều bộ môn và ứng với mỗi bộ

môn lưu lại phần trăm thời gian họ làm việc ở đó.• Sinh viên sau đại học chỉ thuộc về một bộ môn quản lý, nơi họ đang theo học.• Mỗi sinh viên sau đại học có nhiều sinh viên lớp trên hỗ trợ (cố vấn), khuyên

họ nên theo học những môn học nào.

Thiết kế và vẽ lược đồ ER để biểu diễn các thông tin này. Chỉ sử dụng thành phần cơbản của mô hình ER, đó là thực thể, kiểu liên kết và thuộc tính. Chỉ ra ràng buộc khóavà các ràng buộc tham gia.

Câu trả lời nằm trong Hình 21

61/470

Lược đồ ER

Một công ty cần lưu trữ thông tin về nhân viên (định danh bằng số bảo hiểm xã hội, vàcó các thuộc tính khác là lương và số điện thoại); Phòng (định danh bằng mã số phòng,và có một số thuộc tính khác là tên phòng và ngân quỹ); và con của các nhân viên (cócác thuộc tính tên và tuổi). Các nhân viên có thể làm việc trong nhiều phòng; mỗi phòngđược một nhân viên quản lý; mỗi đứa con phải được định danh duy nhất ứng với mộtcha/mẹ (giả sử rằng chỉ có một người, hoặc cha hoặc mẹ làm việc cho công ty). Khinhân viên chuyển đi, chúng ta sẽ không quan tâm đến những thông tin về những đứa concủa họ.

Vẽ lược đồ ER để biểu diễn các thông tin này.

Trả lời: Dành cho độc giả.

Notown Records (hãng băng đĩa) quyết định lưu trữ thông tin về những nhạc sỹ thựchiện các album tại đây. Công ty có lựa chọn thông minh là thuê bạn là một người thiếtkế cơ sở dữ liệu (với mức phí tư vấn thông thường là 2500$/ngày).

• Mỗi nhạc sỹ ghi băng ở Notown có lưu thông tin về số bảo hiểm xã hội, địa chỉ,số điện thoại. Những nhạc sỹ nghèo thường có chung nhau một địa chỉ vàkhông có địa chỉ nào có nhiều hơn một số điện thoại.

62/470

• Mỗi nhạc cụ được sử dụng trong các bài hát ghi ở Notown có tên (ví dụ, ghi ta,nhạc cụ điện tử, sáo) và nốt nhạc (ví dụ, C, B-flat, E-flat).

• Mỗi album được ghi ở Notown có thông tin về tên, ngày xuất bản, định dạng(ví dụ, CD hoặc MC), và mã số định danh album.

• Mỗi bài hát ghi ở Notown có tiêu đề và tác giả.• Mỗi nhạc sỹ có thể chơi một số nhạc cụ, và một nhạc cụ có thể được nhiều nhạc

sỹ chơi.• Mỗi album có một số bài hát, nhưng không có bài hát nào xuất hiện trong nhiều

hơn một album.• Một bài hát có thể được thực hiện bằng nhiều nhạc sỹ, và một nhạc sỹ có thể

thực hiện một số bài hát.• Mỗi album có chính xác một nhạc sỹ là người sản xuất. Một nhạc sỹ có thể là

người sản xuất của nhiều album.

Thiết kế lược đồ khái niệm cho công ty Notown và vẽ lược đồ ER. Những thông tin biểudiễn cơ sở dữ liệu của Notown phía trên phải được mô hình hóa. Xác định tất cả cácràng buộc khóa và ràng buộc thành phần. Chỉ ra các ràng buộc mà bạn không thể biểudiễn trong lược đồ ER và giải thích tóm tắt vì sao bạn không thể biểu diễn chúng.

Trả lời:Câu trả lời nằm trong Hình sau

63/470

Bộ môn khoa học máy tính thường xuyên nghe phi công phàn nàn với nhà chức tráchcủa sân bay thành phố Dane về sự tổ chức nghèo nàn ở sân bay. Vì thế, những nhà chứctrách đã quyết định sử dụng DBMS để tổ chức tất cả các thông tin liên quan ở sân bay vàbạn đã được thuê để thiết kế cơ sở dữ liệu. Công việc đầu tiên của bạn là tổ chức thôngtin về tất cả các máy bay được sử dụng ở sân bay. Các thông tin liên quan bao gồm:

• Tất cả các máy bay có mã số đăng ký, và mỗi máy bay thuộc một loại nhấtđịnh.

• Sân bay có một số loại máy bay, mỗi loại được định danh bằng mã số loại (vídụ, DC-10) và có thông tin về trọng tải và khả năng chở khách hàng.

• Có một số các kỹ sư làm việc ở sân bay. Bạn cần lưu lại tên, số bảo hiểm xãhội, địa chỉ, số điện thoại, lương của từng người.

64/470

• Mỗi kỹ sư là một chuyên gia trên một hoặc nhiều loại máy bay, và ý kiếnchuyên môn của anh/cô ấy có ý nghĩa quyết định. Thông tin về những kỹ sưnày cần được ghi lại.

• Những nhân viên kiểm soát phải có kiểm tra y tế định kỳ. Với mỗi nhân viênkiểm soát, bạn phải ghi lại ngày kiểm tra y tế gần đây nhất.

• Mỗi nhân viên sân bay (bao gồm cả kỹ sư) phải thuộc về một tổ chức nào đó.Bạn phải lưu lại mã số của mỗi nhân viên trong tổ chức. Bạn có thể giả sử rằngmỗi nhân viên có mã số bảo hiểm xã hội khác nhau.

• Mỗi sân bay có một số kiểm tra được thực hiện để đảm bảo rằng tất cả các máybay vẫn hoạt động tốt. Mỗi kiểm tra có mã số FAA (Federal AviationAdministration), tên, và điểm cao nhất có thể.

• FAA yêu cầu sân bay giữ lại lịch sử của mỗi lần kiểm tra đối với từng máy bay.Với mỗi lần kiểm tra, thông tin cần lưu lại là: ngày kiểm tra, số lượng giờ màkỹ sư đã dùng để kiểm tra và điểm mà máy bay đó nhận được.

1. Vẽ lược đồ ER cho cơ sở dữ liệu về sân bay, chỉ ra tất cả các thuộc tính củakiểu thực thể và kiểu quan hệ, xác định khoá và các ràng buộc tham gia chomỗi kiểu quan hệ. Xác định những ràng buộc overlap và covering nếu có.

2. Những kiểm tra FAA thông thường trên máy bay phải được thực hiện bằng kỹsư- chuyên gia về loại máy bay đó. Ràng buộc này được biểu diễn như thế nàotrong lược đồ ER? Nếu không thể biểu diễn ràng buộc này, giải thích tóm tắt tạisao.

Trả lời: Dành cho độc giả.

Thiết kế cơ sở dữ liệu cho một công ty kinh doanh dược phẩm. Tham khảo những thôngtin sau:

• Bệnh nhân được xác định bằng SSN và lưu lại tên, địa chỉ, tuổi của bệnh nhân.• Bác sỹ được xác định bằng SSN. Mỗi bác sỹ lưu lại tên, chuyên môn, số năm

kinh nghiệm.• Mỗi công ty dược được xác định bằng tên và có số điện thoại. Với mỗi loại

thuốc, tên và công thức phải được ghi lại. Mỗi loại thuốc được bán bởi mộtcông ty dược và tên của loại thuốc của một công ty phải khác nhau. Nếu mộtcông ty dược bị xoá, bạn không cần lưu lại thông tin về các loại thuốc của côngty đó nữa.

• Mỗi cửa hàng thuốc có tên, địa chỉ và số điện thoại.• Mỗi bệnh nhân có một bác sỹ điều trị chính. Tất cả các bác sỹ đều có ít nhất

một bệnh nhân.• Mỗi cửa hàng bán một vài loại thuốc và có giá cho mỗi loại. Mỗi loại thuốc có

thể được bán ở một vài cửa hàng thuốc và giá bán có thể khác nhau.• Bác sỹ kê đơn thuốc cho các các bệnh nhân. Bác sỹ có thể kê đơn một hoặc

nhiều loại thuốc cho các bệnh nhân khác nhau, và một bệnh nhân có thể nhậncác đơn thuốc từ một vài bác sỹ. Mỗi đơn thuốc có ngày và số lượng của từng

65/470

loại thuốc. Bạn có thể giả sử rằng một bác sỹ kê cùng một loại thuốc cho cùngmột bệnh nhân nhiều hơn một lần, trong trường hợp này bạn chỉ cần lưu lại lầnkê đơn cuối cùng.

• Công ty kinh doanh dược phẩm có hợp đồng dài hạn với các cửa hàng. Mộtcông ty có thể hợp đồng với nhiều cửa hàng, và một cửa hàng có thể hợp đồngvới nhiều công ty. Với mỗi hợp đồng, bạn cần lưu lại ngày bắt đầu, ngày cuốicùng và văn bản của hợp đồng.

• Các cửa hàng cử một người quản lý cho mỗi hợp đồng. Mỗi hợp đồng phảiluôn có người quản lý, người quản lý có thể thay đổi trong suốt thời gian duy trìhợp đồng.

1. Xây dựng lược đồ ER biểu diễn những thông tin trên.2. Thay đổi thiết kế của bạn như thế nào để mỗi loại thuốc phải được bán bằng

một giá ở tất cả các cửa hàng.3. Thay đổi thiết kế như thế nào nếu thay đổi yêu cầu như sau: Nếu một bác sỹ kê

đơn cùng một loại thuốc cho cùng một bệnh nhân nhiều lần, những lần này đềucần ghi lại.

Trả lời

1. Nếu thuốc được bán một giá cố định chúng ta có thể thêm thuộc tính price vàokiểu thực thể Drug và bỏ price ở kiểu liên kết Sell.

2. Thông tin ngày tháng (date) có thể không còn được mô hình hóa như một thuộctính của Prescription. Chúng ta phải tạo ra một thực thể mới gọi là Prescriptiondate và xem Prescription là một kiểu liên kết 4-đường, tức là được bổ sungthêm một đường tới kiểu thực thể này.

66/470

Lược đồ ER

Bạn muốn xây dựng một cơ sở dữ liệu, ArtBase, để lưu lại thông tin về những tác phẩmnghệ thuật trong những triển lãm. Triển lãm chứa thông tin về các nghệ sỹ, bao gồm tên(xác định duy nhất), ngày sinh, tuổi và phong cách nghệ thuật của họ. Với mỗi tác phẩm,bạn cần lưu lại thông tin về: nghệ sỹ, năm hoàn thành, tên tác phẩm (xác định duy nhất),loại nghệ thuật (tranh vẽ, tranh đá, tượng, ảnh…), và giá. Các tác phẩm cũng được phânloại thành các nhóm, ví dụ, chân dung, cuộc sống hàng ngày, trường phái Picasso, tácphẩm của thế kỷ 19; mỗi tác phẩm cũng có thể thuộc về nhiều nhóm. Mỗi nhóm xácđịnh bằng tên của nhóm. Cuối cùng, triển lãm cần lưu lại thông tin về các khách hàng.Với mỗi khách hàng, triển lãm lưu lại thông tin về tên, địa chỉ, tổng số tiền họ đã sửdụng trong một triển lãm (rất quan trọng), và những nghệ sỹ và loại tác phẩm họ thích.

Vẽ lược đồ ER cho cơ sở dữ liệu này.

Trả lời: Dành cho độc giả.

Trả lời những câu hỏi sau:

67/470

• Giải thích tóm tắt những thuật ngữ sau: UML, lược đồ trường hợp sử dụng,lược đồ lớp, lược đồ cơ sở dữ liệu, lược đồ thành phần, và lược đồ phát triển.

• Giải thích mối quan hệ giữa lược đồ ER và UML.

Trả lời: Chưa thực hiện

TÀI LIỆU THAM KHẢO

Một số quyển sách cung cấp những hướng dẫn tốt để thiết kế khái niệm; bao gồm [63](nó cũng chứa tổng quan về các công cụ thiết kế cơ sở dữ liệu thương mại) và [730].

Mô hình ER đã được Chen đề xuất [172], và những mở rộng đã được đề xuất trong mộtsố bài báo. Tổng quát hóa và khối kết hợp được giới thiệu trong [693]. [390, 589] trìnhbày tốt về mô hình cơ sở dữ liệu ngữ nghĩa.

[731] trình bày về cách thức thiết kế bằng cách phát triển lược đồ ER và sau đó ánh xạnó sang mô hình quan hệ. Markowitz đề cập đến ràng buộc tham chiếu trong mô hìnhER để ánh xạ quan hệ và bàn về những hỗ trợ do một số hệ thống thương mại cung cấptrong [513, 514].

Mô hình ER được trình bày trong hàng loath các bài báo, như [698].

Trang chủ của OMG (www.omg.org) trình bày về UML và các chuẩn mô hình liên quan.Một số lượng lớn sách trình bày về UML; ví dụ [105, 278, 640] và có một hội thảo hàngnăm liên quan đến những lợi ích của UML đó là hội thảo quốc tế về UML.

Khung nhìn được trình bày trong một số bài báo, bao gồm [97, 139, 184, 244, 535, 551,550, 685, 697, 748].

68/470

Mô hình quan hệCodd đã đề xuất mô hình dữ liệu quan hệ năm 1970. Trong thời gian đó, hầu hết hệthống cơ sở dữ liệu đều dựa trên hai mô hình dữ liệu cũ (mô hình phân cấp và mô hìnhmạng); mô hình quan hệ thực sự là một cuộc cách mạng trong lĩnh vực cơ sở dữ liệu vànó nhanh chóng thay chỗ cho các mô hình trước. Các hệ quản trị cơ sở dữ liệu nguyênmẫu đã được phát triển đầu tiên trong những dự án của IBM và UC-Berkeley vào giữanhững năm 70, và một vài nhà sản xuất đã đưa ra những sản phẩm của cơ sở dữ liệuquan hệ một thời gian ngắn sau đó. Ngày nay, mô hình quan hệ là mô hình dữ liệu phổbiến nhất và được sử dụng trong các sản phẩm DBMS, bao gồm IBM's DB2, Informix,Oracle, Sybase, Microsoft's Access và SQLServer, FoxBase, và Paradox. Hệ quản trị cơsở dữ liệu quan hệ có mặt khắp nơi trên thị trường và được coi là ngành công nghiệpnhiều tỷ đô la.

SQL: là ngôn ngữ truy vấn dữ liệu (Structured Query Language) được IBM phát triến.SQL đã trở thành ngôn ngữ được sử dụng rộng rãi nhất để tạo, thực thi và truy vấn dữliệu trong các DBMS. Cho đến nay, rất nhiều nhà sản xuất đã đưa ra các sản phẩm khácnhau của SQL, vì thế cần có một chuẩn được định nghĩa là 'SQL chính thức'. Sự tồn tạicủa chuẩn này cho phép người sử dụng đánh giá phiên bản SQL đang sử dụng. Nó cũngcho phép người sử dụng phân biệt các đặc trưng riêng biệt của SQL so với phiên bảnchuẩn; những ứng dụng hỗ trợ các đặc trưng riêng biệt này thường ít gặp.

Phiên bản SQL chuẩn đầu tiên được phát triển vào năm 1986 bởi American NationalStandards Institute (ANSI), và được gọi là SQL-86. Phiên bản tiếp theo ra đời năm1989 được gọi là SQL-89, bản chính thức ra đời năm 1992 và được gọi là SQL-92.International Standards Organization (ISO) đã kết hợp với ANSI để phát triển SQL-92.Hầu hết các DBMS thương mại hỗ trợ SQL-92.

Mô hình quan hệ là mô hình đơn giản và dễ sử dụng; cơ sở dữ liệu là tập hợp của mộthoặc nhiều quan hệ, mỗi quan hệ là một bảng gồm các dòng và các cột. Bảng này có thểgiúp người sử dụng bình thường hiểu được nội dung của cơ sở dữ liệu, và cho phép sửdụng nó đơn giản bằng cách sử dụng ngôn ngữ truy vấn dữ liệu bậc cao. Những ưu điểmchính của mô hình quan hệ so với mô hình dữ liệu cũ là dữ liệu trong đó được biểu diễnđơn giản và những truy vấn phức tạp dễ dàng thực hiện.

Trong khi chúng ta tập trung vào những khái niệm dưới đây, chúng tôi cũng giới thiệuvề ngôn ngữ định nghĩa dữ liệu (Data Definition Language-DDL) của SQL-92, ngônngữ chuẩn để tạo, thực thi và truy vấn dữ liệu trong các hệ quản trị cơ sở dữ liệu quanhệ. Điều này cho phép chúng ta có lý do để bàn tới những khái niệm khác trong các hệthống cơ sở dữ liệu.

69/470

Chúng ta sẽ bàn tới khái niệm quan hệ trong Phần 1 và làm thế nào để tạo ra một quan hệsử dụng ngôn ngữ SQL. Một thành phần quan trọng của mô hình dữ liệu là một tập cáccấu trúc trong những trường hợp xác định để đảm bảo sự đúng đắn của dữ liệu. Nhữngđiều kiện đó gọi là các ràng buộc toàn vẹn. Chúng ta biểu diễn ràng buộc toàn vẹn trongmô hình quan hệ trong Phần 2, sau đó sẽ bàn tới phần SQL hỗ trợ ràng buộc toàn vẹnnhư thế nào. Chúng tôi cũng sẽ trình bày cách DBMS thiết đặt ràng buộc tham chiếutrong Phần 3.

Trong phần 4, chúng ta sẽ quay lại với cách thức truy vấn dữ liệu trong cơ sở dữ liệu,ngôn ngữ truy vấn, và giới thiệu những đặc trưng truy vấn của SQL, phần này sẽ đượcbàn tới sâu hơn trong một chương phía sau.

Sau đó, chúng tôi sẽ trình bày các bước để chuyển từ lược đồ ER sang lược đồ cơ sở dữliệu quan hệ trong phần 5. Cuối cùng, chúng tôi giới thiệu về khung nhìn, bảng sử dụngtruy vấn trong Phần 6. Khung nhìn có thể được sử dụng để định nghĩa lược đồ ngoài củacơ sở dữ liệu và vì thế nó hỗ trợ độc lập dữ liệu logic trong mô hình quan hệ. Phần 7 sẽbàn tới các lệnh SQL để xóa, sửa bảng và khung nhìn.

Cuối cùng Phần 8 sẽ mở rộng thiết kế của ví dụ Cửa hàng Internet, bằng việc chỉ ra cáchánh xạ từ lược đồ ER sang mô hình quan hệ, và sử dụng các khung nhìn có thể hỗ trợthiết kế này.

Giới thiệu mô hình quan hệ

Cấu trúc chính để biểu diễn dữ liệu trong mô hình quan hệ là các quan hệ. Một quan hệchứa lược đồ quan hệ và minh họa quan hệ. Một trường hợp quan hệ là một bảng, vàlược đồ quan hệ biểu diễn những tên cột trong bảng. Chúng ta đầu tiên biểu diễn lược đồquan hệ, sau đó đến minh họa quan hệ. Lược đồ chỉ ra tên quan hệ, tên của các trường(hoặc cột, hoặc thuộc tính), và miền giá trị của mỗi trường. Miền được tham chiếu tớilược đồ quan hệ bằng tên miền và tập những giá trị mà trường đó có thể nhận.

Chúng ta sử dụng ví dụ của thông tin về sinh viên trong cơ sở dữ liệu trường đại học ởchương 1 làm minh họa cho phần lược đồ quan hệ:

Students(sid: string, name: string, login: string, age:integer, gpa: real)

Trong ví dụ trên, trường sid có miền trị là string. Tập các giá trị có thể có của miền nàylà tất cả các ký tự.

Bây giờ, chúng ta quay lại với minh họa quan hệ. Minh họa của quan hệ là tập các bộgiá trị, hay còn gọi là các bản ghi, và mỗi bộ giá trị có cùng số lượng các trường nhưlược đồ quan hệ. Minh họa quan hệ có thể được nghĩ như một bảng, trong đó có các

70/470

dòng, và tất cả các dòng có cùng số lượng các trường. (Thuật ngữ minh họa quan hệthường được sử dụng để chỉ một quan hệ).

Minh họa S1 của quan hệ Students

Một minh họa của quan hệ Students được chỉ ra trong Hình 1. Minh họa S1 chứa 6 bộgiá trị và 5 trường. Ghi nhớ rằng, không có hai dòng có cùng định danh. Điều này làmột yêu cầu của mô hình quan hệ, mỗi quan hệ phải có một tập các thuộc tính đóng vaitrò định danh, giúp ta phân biệt được bộ giá trị này với bộ giá trị khác. Thứ tự các dòngtrong bảng không quan trọng.

Trong Hình 2 chỉ ra một minh họa khác của quan hệ. Nếu như các trường được đặt tên,như trong định nghĩa lược đồ và các hình mô tả các minh họa quan hệ, thứ thự của cáctrường không phải là vấn đề. Tuy nhiên, nên đặt các trường theo thứ tự xác định và thamchiếu đến các trường theo thứ tự của nó. Do đó, sid là trường 1 của Students, login làtrường 3 của Students, vv…Nếu làm theo cách này thì thứ tự các trường lại trở nên quantrọng. Ví dụ, trong SQL, tên của các trường được sử dụng trong các câu lệnh truy vấndữ liệu và thứ tự các trường cũng được quan tâm khi chúng ta thêm một bộ dữ liệu mới.

Một biểu diễn khác của minh họa quan hệ Students

71/470

Lược đồ quan hệ chỉ ra miền giá trị của mỗi trường (cột) trong minh họa quan hệ. Nhữngràng buộc miền trong lược đồ xác định điều kiện mà mỗi minh họa của quan hệ cầnphải thỏa mãn: Giá trị xuất hiện trong mỗi cột phải nằm trong miền xác định của cột đó.Vì thế, miền của mỗi trường cần chỉ ra kiểu dữ liệu của trường đó và những giới hạn giátrị mà trường đó có thể nhận.

Để hiểu rõ ràng, chúng ta xem xét lược đồ quan hệ R(f1: D1,…fn : Dn), và mỗi fi , 1 ≤i ≤ n, và Domi là tập giá trị nằm trong miền. Một minh họa của R thỏa mãn ràng buộcmiền trong lược đồ là tập hợp các bộ giá trị gồm n trường:

{<f1: d1, …, fn: dn> | d1∈ Dom1, …, dn∈ Domn}

Phần nằm trong dấu <…> chỉ ra những trường của bộ giá trị. Sử dụng ký hiệu này, bộgiá trị Students đầu tiên chỉ ra trong Hình 1 được viết như sau:

<sid: 50000, name: Dave, login: dave@cs, age: 19, gpa:3.3>

Ký hiệu {…} chỉ ra tập các bộ giá trị. Những biểu diễn ở bên phải ký hiệu | trong côngthức chỉ ra miền giá trị của các trường tương ứng ghi ở bên trái. Vì thế, minh họa của Rđược định nghĩa như là tập các bộ giá trị. Những trường của mỗi bộ giá trị phải tươngứng với những trường trong lược đồ quan hệ.

Ràng buộc miền là khái niệm rất cơ bản trong mô hình quan hệ vì thế từ nay chúng ta sẽchỉ xem xét những minh họa quan hệ thỏa mãn các miền giá trị của nó. Do đó, minh họaquan hệ nghĩa là những minh họa thỏa mãn miền giá trị trong lược đồ quan hệ.

Bậc của quan hệ là số lượng các trường trong quan hệ. Lực lượng là số lượng các bộ giátrị trong qaun hệ. Trong Hình 1, bậc của quan hệ (số các cột) là 5, và lực lượng trongminh hoạ này là 6.

Cơ sở dữ liệu quan hệ là tập hợp các quan hệ có tên khác nhau. Lược đồ cơ sở dữ liệuquan hệ là tập hợp các lược đồ quan hệ trong cơ sở dữ liệu. Ví dụ, trong Chương 1,chúng ta bàn tới cơ sở dữ liệu của một trường đại học với các quan hệ Students, Faculty,Courses, Rooms, Enrolled, Teaches, và Meets_In. Minh hoạ của cơ sở dữ liệu quan hệlà tập hợp các minh hoạ của các quan hệ, tất nhiên mỗi minh họa của một quan hệ phảithoả mãn miền giá trị của lược đồ đó.

Tạo và sửa quan hệ sử dụng SQL-92

Ngôn ngữ SQL-92 chuẩn sử dụng từ bảng thay thế cho từ quan hệ. Tập những lệnh SQLhỗ trợ việc tạo, xoá, và sửa bảng gọi là Ngôn ngữ định nghĩa dữ liệu.

72/470

Lệnh CREATE TABE được sử dụng để định nghĩa bảng mới. Để tạo ra bảng Students,chúng ta có thể sử dụng câu lệnh sau:

CREATE TABLE Students ( sid CHAR(20), name CHAR(30), loginCHAR(20), age INTEGER, gpa REAL )

Các bộ giá trị được thêm vào bằng cách sử dụng câu lệnh INSERT. Chúng ta có thểthêm vào bảng một bộ giá trị như sau:

INSERT INTO Students(sid, name, login, age, gpa)VALUES(53688, 'Smith', 'smith@ee', 18, 3.2)

Chúng ta thường bỏ qua việc liệt kê tên các cột trong mệnh đề INTO nếu giá trị đượcthêm vào đã theo đúng thứ tự trong định nghĩa lược đồ quan hệ.

Chúng ta có thể xoá các bộ giá trị sử dụng lệnh DELETE. Chúng ta có thể xoá bộ tất cảcác bộ giá trị có name là Smith bằng lệnh sau:

DELETE FROM Students S WHERE S.name = 'Smith'

Chúng ta có thể sửa giá trị trong một dòng đang tồn tại bằng lệnh UPDATE. Ví dụ,chúng ta tăng tuổi (age) và giảm điểm trung bình (gpa) của sinh viên có sid bằng 53688sử dụng câu lệnh sau:

UPDATE Students S SET S.age = S.age + 1, S.gpa = S.gpa - 1WHERE S.sid = 53688

Mệnh đề WHERE được sử dụng để xác định những dòng nào cần sửa. Mệnh đề SETđược dùng để xác định dòng đó được sửa như thế nào. Bên phải dấu '=' là giá trị mới củacột được sửa. Để minh hoạ cho câu lệnh này, chúng ta xem xét ví dụ sau:

UPDATE Students S SET S.gpa = S.gpa - 0.1 WHERE S.gpa >=3.3

Nếu câu lệnh này được áp dụng cho minh hoạ dữ liệu S1 của quan hệ Students trongHình 1, chúng ta sẽ nhận được kết quả như trong Hình 3.

73/470

Minh hoạ quan hệ S1 của Students sau khi Update

Các ràng buộc toàn vẹn trên quan hệ

Cơ sở dữ liệu chỉ có ích khi có thông tin đúng được lưu trữ trong nó, và DBMS vì thếphải tránh được các dữ liệu không đúng. Ràng buộc toàn vẹn là những yêu cầu thiết đặttrên các lược đồ quan hệ, và giới hạn những dữ liệu nào có thể được lưu trữ trong lượcđồ đó. Nếu một minh họa dữ liệu thỏa mãn tất cả các ràng buộc toàn vẹn trên lược đồ cơsở dữ liệu đó thì minh họa đó gọi là minh họa hợp lệ. DBMS hỗ trợ thiết đặt các ràngbuộc tham chiếu, chỉ cho phép những minh họa dữ liệu hợp lệ được lưu trữ trong cơ sởdữ liệu.

Ràng buộc tham chiếu được xác định và thiết đặt ở nhiều thời điểm khác nhau:

1. Khi người quản trị và người sử dụng cuối định nghĩa lược đồ cơ sở dữ liệu,anh/cô ấy xác định có những ràng buộc tham chiếu nào có trong cơ sở dữ liệu.

2. Khi một ứng dụng cơ sở dữ liệu thực thi, người quản trị kiểm tra những viphạm dữ liệu và không cho phép những thay đổi vi phạm ràng buộc thamchiếu. Trong một số trường hợp, DBMS có thể thêm vào một số các thay đổitới dữ liệu để đảm bảo các minh họa dữ liệu thỏa mãn các ràng buộc thamchiếu. Trong những trường hợp khác, không được phép tạo ra những minh họadữ liệu vi phạm bất kỳ ràng buộc tham chiếu nào.

Rất nhiều loại ràng buộc tham chiếu có thể được xác định trong mô hình quan hệ. Chúngta đã nhìn thấy một ví dụ về ràng buộc tham chiếu trong các ràng buộc miền giá trị(Phần 1). Tóm lại, nhiều loại khác nhau của ràng buộc có thể được xác định dễ dàng; vídụ, không có hai sinh viên có cùng giá trị sid. Trong phần này, chúng ta bàn tới nhữngràng buộc tham chiếu, khác với ràng buộc miền giá trị, phần mà người quản trị hoặcngười dùng cuối có thể xác định trong mô hình quan hệ

Các ràng buộc khóa

Xem xét quan hệ Students và ràng buộc về hai sinh viên không có cùng sid. Ràng buộcnày là một ví dụ về ràng buộc khóa. Ràng buộc khóa được phát biểu rằng: một tập connhỏ nhất các trường của quan hệ giúp xác định một bộ giá trị là duy nhất. Tập các trườnggiúp xác định duy nhất một bộ giá trị được gọi là khóa dự tuyển trong quan hệ; chúng

74/470

ta thường gọi đơn giản là khóa. Trong trường hợp của quan hệ Students, trường sid làkhóa dự tuyển.

Hãy cùng tìm hiểu sâu hơn định nghĩa trên về khóa dự tuyển. Định nghĩa có hai phần:

1. Hai bộ giá trị khác nhau trong minh họa dữ liệu hợp lệ (minh họa thỏa mãn tấtcả các ràng buộc tham chiếu, bao gồm cả ràng buộc khóa) không thể có giá trịtrùng nhau trong các trường đóng vai trò là khóa.

2. Không có một tập con của các trường trong khóa có thể xác định duy nhất môtbộ giá trị (Khóa là một tập tối giản).

Phần đầu tiên của định nghĩa có nghĩa là trong bất kỳ một minh họa dữ liệu hợp lệ, cácgiá trị của các trường khóa phải xác định một bộ giá trị là duy nhất trong minh họa quanhệ. Khi xác định ràng buộc khóa, người quản trị hoặc người dùng phải đảm bảo rằngràng buộc này sẽ không ngăn cản họ lưu trữ những bộ dữ liệu 'hợp lệ'. (Lời nhắc tươngtự được áp dụng để xác định chuẩn xác những loại ràng buộc tham chiếu).'Hợp lệ' ở đâyphụ thuộc vào trạng thái tự nhiên của dữ liệu phải lưu trữ. Ví dụ, một số sinh viên cóthể có tên trùng nhau, nếu trường tên được xác định là khóa, DBMS sẽ không cho phépnhập hai sinh viên có cùng tên vào quan hệ Students, như vậy là không phù hợp vớitrạng thái tự nhiên của dữ liệu.

Phần thứ hai của định nghĩa có nghĩa là, ví dụ, tập các trường {sid, name} không phảilà khóa của quan hệ Students, vì tập này chứa thuộc tính sid có khả năng làm khóa. Tập{sid, name} là một ví dụ về siêu khóa, tập của những trường chứa khóa.

Hãy nhìn lại minh họa của quan hệ Students trong Hình 1. Quan sát hai dòng khác nhauluôn có giá trị sid khác nhau; sid là khóa và xác định duy nhất một bộ giá trị. Tuy nhiên,điều này không cần thiết đối với các trường không phải là khóa. Ví dụ, quan hệ có thểchứa hai dòng có trường name là Smith, vì name không phải là khóa.

Ghi nhớ rằng tất cả quan hệ phải đảm bảo có khóa. Vì một quan hệ là một tập các bộ giátrị, một tập hợp của tất cả các trường sẽ luôn luôn là siêu khóa. Một vài tập con của cáctrường có thể hình thành nên khóa, nhưng nếu không, tập tất cả các trường sẽ là khóa.

Quan hệ có thể có một vài khóa dự tuyển. Ví dụ, hai trường login và age của quan hệStudents có thể xác định duy nhất một sinh viên. Vì thế tập {login, age} cũng có thể làmkhóa. Nếu giả sử rằng, chỉ có trường login làm khóa, thì hai dòng trong cùng một minhhọa có thể có cùng giá trị login. Tuy nhiên, khóa phải xác định được bộ giá trị duy nhấttrong tất cả các minh họa hợp lệ của quan hệ. Nếu xác định {login, age} là khóa, thìngười dùng không được phép nhập hai sinh viên có cùng cả login và cả age trùng nhau.

Trong tất cả các khóa dự tuyển, người thiết kế cơ sở dữ liệu chọn ra một khóa chính.Thực tế, khi biết khóa chính, ta có thể tham chiếu tới tất cả các trường liên quan đếnkhóa chính đó. Ví dụ, chúng ta có thể tham chiếu tới một bộ giá trị trong quan hệ

75/470

Students nếu ta biết giá trị sid của nó. Trên nguyên tắc, chúng ta có thể sử dụng bất kỳkhóa nào, không chỉ là khóa chính để tham chiếu tới một bộ giá trị. Tuy nhiên, sử dụngkhóa chính là thích hợp hơn bởi vì nó là cái mà DBMS hy vọng- đây là ý nghĩa của việcchỉ định một khóa dự tuyển nào đó là khóa chính và tối giản nó. Ví dụ, DBMS có thểtạo ra chỉ số trên những trường khóa chính để tìm kiếm theo khóa, truy cập đến một bộgiá trị sử dụng khóa chính của nó sẽ hiệu quả cao hơn. Ý nghĩa của việc tham chiếu tớimột bộ giá trị được nghiên cứu sâu hơn trong phần sau.

Xác định ràng buộc khóa bằng SQL-92

Trong SQL chúng ta có thể khai báo một tập con các cột của bảng đóng vai trò là khóabằng sử dụng ràng buộc UNIQUE. Trong đó, nhiều nhất một khóa dự tuyển có thể đượckhai báo là khóa chính, sử dụng ràng buộc PRIMARY KEY. (SQL không yêu cầu nhữngràng buộc này phải được khai báo khi định nghĩa bảng).

Cùng xem xét ví dụ sau đây về định nghĩa bảng và xác định ràng buộc:

CREATE TABLE Students ( sid CHAR(20), name CHAR(30), loginCHAR(20), age INTEGER, gpa REAL, UNIQUE (name, age),CONSTRAINT StudentsKey PRIMARY KEY (sid) )

Định nghĩa này chỉ ra sid là khóa chính và kết hợp giữa name và age cũng có thể làmkhóa. Định nghĩa của khóa chính cũng minh họa cách làm thế nào chúng ta có thể đặttên cho ràng buộc, tên ràng buộc được đặt phía sau từ khóa CONSTRAINT tên ràngbuộc. Nếu ràng buộc bị vi phạm, tên ràng buộc sẽ trả về để dễ dàng xác định lỗi.

Ràng buộc khóa ngoại

Một số thông tin lưu trữ trong một quan hệ có thể được liên kết tới những thông tin đượclưu trữ trong một quan hệ khác. Nếu một trong những quan hệ bị sửa, những quan hệkhác phải được kiểm tra lại và có thể sửa theo để đảm bảo sự nhất quán dữ liệu. Nhữngràng buộc tham chiếu thông thường bao gồm hai quan hệ và được gọi là ràng buộc khoángoại.

Giả sử rằng bổ sung vào quan hệ Students, ta có thêm một quan hệ thứ hai:

Enrolled(sid: string, cid: string, grade: string)

Để đảm bảo rằng chỉ có những sinh viên thực sự mới có thể đăng ký vào những khóahọc, bất kỳ giá trị nào xuất hiện trong trường sid của minh họa quan hệ Enrolled cũngphải xuất hiện trong trường sid trong một bộ giá trị nào đó của quan hệ Students. Trườngsid của Enrolled được gọi là khóa ngoại và tham chiếu tới quan hệ Students. Khóangoại trong quan hệ tham chiếu (trong ví dụ của chúng ta là Enrolled) phải phù hợp với

76/470

khóa chính trong quan hệ được tham chiếu (Students), ví dụ, nó phải có cùng số lượngcác cột và kiểu dữ liệu tương thích, mặc dù tên các cột có thể khác nhau.

Ràng buộc này được minh họa trong Hình 4. Như chúng ta thấy, có một số sinh viênkhông được tham chiếu từ Enrolled (ví dụ, sinh viên có sid=50000). Tuy nhiên, tất cảcác giá trị sid xuất hiện trong bảng Enrolled đều phải xuất hiện trong cột khóa chính củadòng nào đó trong bảng Students.

Ràng buộc tham chiếu

Nếu chúng ta cố gắng thêm một bộ giá trị {55555, Art104, A} vào E1, ràng buộc thamchiếu bị vi phạm bởi vì không có bộ giá trị nào của S1 có id= 55555; hệ thống cơ sởdữ liệu nên từ chối việc thêm trên. Tương tự, chúng ta xóa bộ giá trị {53666, Jones,jones@cs, 18, 3.4} từ S, chúng ta vi phạm ràng buộc khóa ngoại bởi vì bộ giá trị {53666,History105, B} trong E1 chứa sid bằng 53666, là sid của bộ giá trị trong Students bị xóa.DBMS không nên cho phép xóa hoặc nếu xóa bộ giá trị này trong Enrolled thì cũng xóaluôn nó trong Students. Chúng ta sẽ bàn đến ràng khóa khóa ngoại và ảnh hưởng của nótới việc cập nhật dữ liệu trong Phần 3.3.

Cuối cùng, chúng ta ghi nhớ rằng khóa ngoại có thể tham chiếu trong cùng một quanhệ. Ví dụ, chúng ta có thể thêm vào quan hệ Students một cột mới gọi là Partner (ngườicộng tác) và khai báo cột này là khóa ngoại tham chiếu tới chính quan hệ Students. Thựctế, tất cả các sinh viên đều có thể có người cộng tác, và người này cũng chính là sinhviên, tức là trường Partner chứa giá trị sid của các cộng sự. Người đọc có thể đặt ra câuhỏi: "Điều gì xảy ra nếu một sinh viên không có bất kỳ người cộng sự nào?". Tình trạngnày được quản lý trong SQL bằng việc sử dụng giá trị đặc biệt gọi là giá trị Null (Rỗng).Việc sử dụng Null trong một trường của một bộ giá trị chỉ ra rằng trường đó không cógiá trị hoặc có nhưng chúng ta không biết (ví dụ, chúng ta không biết người cộng sự củasinh viên đó, hoặc người đó không có cộng sự nào). Sự xuất hiện của null trong trườngkhóa ngoại không vi phạm ràng buộc khóa. Tuy nhiên, những giá trị null không đượcphép xuất hiện trong trường khóa chính (bởi vì trường khóa chính được sử dụng để xácđịnh một bộ giá trị là duy nhất). Chúng ta sẽ bàn thêm về giá trị null trong Chương 5.

77/470

Xác định ràng buộc khóa ngoại bằng SQL-92.

Chúng ta xem xét định nghĩa Enrolled (sid: string, cid: string, grade: string):

CREATE TABLE Enrolled ( sid CHAR(20), cid CHAR(20), gradeCHAR(10), PRIMARY KEY (sid, cid), FOREIGN KEY (sid)REFERENCES Students )

Ràng buộc khóa ngoại chỉ ra rằng tất cả các giá trị sid trong Enrolled phải xuất hiệntrong Students, vì sid trong Enrolled là khóa ngoại đang tham chiếu tới Students.

Nhân đây cũng đề cập thêm, ràng buộc khóa chính trên chỉ ra một sinh viên có chính xácmột kết quả (Grade) trong một khóa học đã tham gia. Nếu chúng ta muốn ghi lạ nhiềuhơn một kết quả của một sinh viên trong một khóa học, chúng ta phải thay đổi ràng buộckhóa chính trên.

Những ràng buộc phổ biến

Ràng buộc miền, khóa chính và khóa ngoại được coi là những khái niệm cơ bản của môhình dữ liệu quan hệ và được đặc biệt quan tâm trong hầu hết các hệ thống quản trị cơsở dữ liệu thương mại. Tuy nhiên, trong một số trường hợp, chúng ta cần xác định thêmcác ràng buộc khác.

Ví dụ, chúng ta có thể yêu cầu tuổi của sinh viên phải nằm trong một dải giá trị nhấtđịnh; điều này được cũng được coi là ràng buộc tham chiếu, DBMS sẽ không chấp nhậnthêm hoặc cập nhật những giá trị vi phạm ràng buộc này. Điều này rất hữu ích trong việctránh những dữ liệu sai nhập vào cơ sở dữ liệu. Nếu chúng ta xác định rằng, tất cả sinhviên phải có tuổi ít nhất là 16, minh họa quan hệ Students chỉ ra trong Hình 1 trở nênkhông hợp lệ vì có hai sinh viên có tuổi dưới 16. Nếu chúng ta không cho phép thêm haibộ giá trị này, chúng ta sẽ có minh họa dữ liệu hợp lệ như trong Hình 5.

Minh họa S2 của quan hệ Students

Ràng buộc tham chiếu chỉ ra tất cả sinh viên không có tuổi dưới 16 có thể được xem nhưlà mở rộng của ràng buộc miền giá trị, ngoài việc định nghĩa kiểu dữ liệu cho trườngage là integer, chúng ta còn cần định nghĩa thêm miền giá trị mà nó có thể nhận. Tómlại, tất cả các ràng buộc, miền, khóa, khóa ngoại đều có thể được xác định. Ví dụ, chúng

78/470

ta có thể yêu cầu tất cả các sinh viên có tuổi lớn hơn 18 thì kết quả học tập (grade) phảilớn hơn 3.

Các hệ thống cơ sở dữ liệu quan hệ hỗ trợ các ràng buộc phổ biến theo dạng của cácràng buộc và xác nhận bảng. Ràng buộc bảng được hỗ trợ trên từng bảng và được kiểmtra bất cứ khi nào bảng được sửa. Ngược lại, xác nhận bảng có thể bao gồm nhiều bảngvà được kiểm tra bất cứ khi nào một bảng trong đó được sửa. Cả hai loại ràng buộc vàxác nhận bảng đều có thể sử dụng câu lệnh SQL để chỉ ra giới hạn mong muốn đối vớidữ liệu.

Hiệu quả của các ràng buộc tham chiếu

Như chúng ta quan sát ở trên, các ràng buộc tham chiếu được xác định khi tạo các quanhệ và nó phát huy tác dụng khi quan hệ có sự thay đổi. Tác động của các ràng buộcmiền, PRIMARY KEY, và UNIQUE rất dễ hiểu: nếu câu lệnh thêm, xóa hoặc cập nhậtlàm vi phạm sự đúng đắn của dữ liệu thì câu lệnh đó bị từ chối thực hiện. Khả năng viphạm được kiểm tra ở cuối mỗi thực hiện câu lệnh, tuy vậy việc trì hoãn kiểm tra có thểlui lại ở cuối giao dịch, chúng ta sẽ xem xét vấn đề này ở Chương 18.

Xem xét minh họa S1 của quan hệ Students ở Hình 1. Việc thêm dữ liệu sau đây vi phạmràng buộc khóa chính bởi vì đã có một bộ giá trị có sid là 53688 và DBMS sẽ từ chốithực hiện câu lệnh này.

INSERT INTO Students(sid, name, login, age, gpa)VALUES(53688,'Mike','mike@ee',17, 3.4)

Câu lệnh INSERT sau đây vi phạm ràng buộc vì khóa chính không thể chứa giá trị Null:

INSERT INTO Students(sid, name, login, age, gpa)VALUES(null,'Mike','mike@ee',17, 3.4)

Tất nhiên, cũng gặp phải vấn đề tương tự khi chúng ta cố gắng thêm một bộ giá trị màgiá trị trong trường đó không nằm trong miền giá trị của nó, ví dụ, khi chúng ta vi phạmràng buộc miền giá trị. Xóa dữ liệu không phải là nguyên nhân vi phạm ràng buộc miền,khóa chính, ràng buộc xác định duy nhất. Tuy nhiên, việc cập nhật có thể dẫn tới viphạm, ví dụ:

UPDATE Students S SET S.sid = 50000 WHERE S.sid = 53688

Câu lệnh cập nhật này vi phạm ràng buộc khóa chính bởi vì đã tồn tại bộ giá trị có sid là50000.

79/470

Ảnh hưởng của ràng buộc khóa ngoại phức tạp hơn bởi vì đôi khi SQL cố gắng điềuchỉnh những thao tác vi phạm ràng buộc khóa ngoại thay vì từ chối ngay những vi phạmnhư những ràng buộc khác. Chúng ta sẽ bàn tới các bước thi hành ràng buộc thamchiếu trong DBMS trong ví dụ của hai bảng Enrolled và Students, với ràng buộc khóangoại là Enrolled.sid được tham chiếu tới khóa chính của bảng Students.

Để thêm vào minh họa S1 của Students, xem xét minh họa của Enrolled trong Hình 4.Việc xóa các bộ giá trị trong Enrolled không làm vi phạm ràng buộc tham chiếu, nhưngviệc thêm dữ liệu thì có thể dẫn tới vi phạm. Câu lệnh INSERT sau đây là hợp lệ vìkhông có sinh viên nào có sid là 51111:

INSERT INTO Enrolled(cid, grade, sid) VALUES ('Hindi101','B', 51111)

Trong ví dụ khác, việc thêm bộ giá trị vào Students không vi phạm ràng buộc thamchiếu, nhưng việc xóa lại có thể vi phạm. Thêm nữa, cập nhật dữ liệu trên Enrolled hoặcStudents làm thay đổi sid có thể dẫn tới vi phạm ràng buộc tham chiếu.

SQL-92 cung cấp một vài cách để nắm bắt vi phạm ràng buộc tham chiếu. Chúng ta phảixem xét ba câu hỏi cơ bản sau:

1. Điều gì chúng ta nên làm nếu một dòng được thêm vào Enrolled, với giá trị của cộtsid không xuất hiện trong bất kỳ dòng nào của bảng Students.

Trường hợp này câu lệnh INSERT sẽ bị từ chối thực hiện.

2. Điều gì nên làm nếu xóa một dòng trong bảng Students?

Có những lựa chọn sau:

• Xóa tất cả các dòng của Enrolled tham chiếu tới dòng đã bị xóa của bảngStudents.

• Không cho phép xóa dòng của bảng Students nếu hiện tại đang có các dòng củabảng Enrolled tham chiếu tới.

• Đặt cho các sid của bảng Enrolled tham chiếu tới dòng bị xóa trong Studentsmột giá trị mặc định.

• Đặt cho các sid của bảng Enrolled tham chiếu tới dòng bị xóa trong Studentsmột giá trị Null. Trong ví dụ của chúng ta, lựa chọn này không được vì sid làmột phần trong khóa chính của bảng Enrolled và vì thế nó không thể nhận giátrị Null. Do đó, chúng ta giới hạn ba lựa chọn đầu tiên cho ví dụ này, mặc dùvậy lựa chọn thứ tư hoàn toàn có thể thực hiện trong các trường hợp khác.

3. Điều gì nên làm nếu giá trị khóa chính của bảng Students được cập nhật?

80/470

Các lựa chọn ở đây tương tự như trường hợp trên.

SQL-92 cho phép chúng ta chọn trong bốn cách làm trên khi thực hiện DELETE hoặcUPDATE. Ví dụ, chúng ta có thể chỉ ra rằng khi một dòng trong Students bị xóa, tấtcả các dòng trong Enrolled tham chiếu đến nó cũng sẽ bị xóa, khi cột sid của một dòngtrong Students được thay đổi, các dòng tham chiếu tới nó trong bảng Enrolled cũng thayđổi tương ứng.

CREATE TABLE Enrolled ( sid CHAR(20), cid CHAR(20), gradeCHAR(10), PRIMARY KEY (sid, cid), FOREIGN KEY (sid)REFERENCES Students ON DELETE CASCADE ON UPDATE NO ACTION)

Những lựa chọn này được xác định như một phần của khai báo khóa ngoại. Lựa chọnmặc định là NO ACTION, có nghĩa là hành động (DELETE hoặc UPDATE) bị từchối. Vì thế, mệnh đề NO UPDATE trong ví dụ của chúng ta có thể bỏ qua. Từ khóaCASCADE xác định rằng nếu một dòng của Students bị xóa, tất cả các dòng củaEnrolled tham chiếu tới nó cũng sẽ bị xóa theo. Nếu như mệnh đề UPDATE xác địnhlà CASCADE, và cột sid của một dòng trong Students được cập nhật, sự cập nhật nàycũng được áp dụng cho tất cả các dòng trong Enrolled tham chiếu tới nó.

Nếu một dòng trong Students bị xóa, chúng ta có thể chuyển sự đăng ký (enrollment)tới một sinh viên mặc định bằng cách sử dụng ON DELETE SET DEFAULT. Sinh viênmặc định này được chỉ ra trong khi định nghĩa trường sid của quan hệ Enrolled; ví dụ,sid CHAR(20) DEFAULT ‘53666’. Mặc dù việc xác định giá trị mặc định này thích hợptrong một số trường hợp (ví dụ, xác định mặc định một nhà cung cấp các sản phẩm),việc gán đăng ký học cho một sinh viên mặc định như trong trường hợp này là khôngphù hợp. Giải pháp đúng cho ví dụ này là xóa tất cả các bộ giá trị trong Enrolled củamột sinh viên nếu ta xóa sinh viên đó trong Students (sử dụng CASCADE), hoặc từ chốiviệc cập nhật.

SQL cũng cho phép sử dụng Null như giá trị mặc định bằng việc chỉ ra ON DELETESET NULL.

Giao dịch và ràng buộc

Như chúng ta nhìn thấy trong chương 1, một chương trình chạy trên cơ sở dữ liệu đượcgọi là giao dịch, và nó có thể bao gồm một hoặc nhiều câu lệnh (queries, inserts, updates,etc.) truy cập tới cơ sở dữ liệu. Nếu (việc thực hiện của) câu lệnh trong giao dịch viphạm một ràng buộc tham chiếu, giao dịch nên chỉ ra cách làm thế nào cho đúng hoặctất cả các giao dịch nên được kiểm tra trước khi giao dịch hoàn thành?

81/470

Mặc định, ràng buộc được kiểm tra ở cuối mỗi câu lệnh SQL, điều này có thể dẫn tới viphạm, và nếu có vi phạm, câu lệnh nên được từ chối thực hiện. Đôi khi, cách thực hiệnnày quá phức tạp. Xem xét những biến đổi sau của quan hệ Students và Courses, tất cảcác sinh viên được yêu cầu có một khoá học về nghi thức (honors), và tất cả các khoáhọc được yêu cầu phải có người tốt nghiệp, người đó là sinh viên.

CREATE TABLE Students ( sid CHAR(20), name CHAR(30), loginCHAR(20), age INTEGER, honors CHAR(10) NOT NULL, gpa REAL,PRIMARY KEY (sid), FOREIGN KEY(honors) REFERENCESCourses(cid)) CREATE TABLE Courses ( cid CHAR(20), cnameCHAR(10), credits INTEGER, grader CHAR(20) NOT NULL,PRIMARY KEY (cid), FOREIGN KEY(grader) REFERENCESStudents(sid))

Bất cứ khi nào một bộ giá trị của bảng Students được thêm vào, việc kiểm tra được thựchiện để đảm bảo khoá học nghi thức trong bảng Students đã có mặt trong bảng Courses,và bất kỳ bộ giá trị nào được thêm vào bảng Courses, những sinh viên đã tốt nghiệptrong bảng này cũng đã phải xuất hiện trong bảng Students. Tuy nhiên, chúng ta sẽ phảithêm sinh viên trong quan hệ Students trước hay là khoá học trong quan hệ Coursestrước? Một quan hệ được thêm vào không thể thiếu quan hệ kia. Cách duy nhất để hoànthành việc thêm dữ liệu này là việc tham chiếu tới ràng buộc phải thực hiện ở cuối câulệnh INSERT.

SQL cho phép điều này bằng cách sử dụng phương thức DEFERRED hoặcIMMEDIATE:

SET CONSTRAINT ConstraintFoo DEFERRED

Ràng buộc theo phương thức này được kiểm tra ở thời điểm hoàn thành câu lệnh. Trongví dụ của chúng ta, ràng buộc khoá ngoại trên cả Students và Courses đều được khai báotheo phương thức DEFERRED. Chúng ta có thể thêm một khoá học vào bảng Studentsmặc dù khoá học đó chưa tồn tại trong bảng Courses và ngược lại.

Truy vấn dữ liệu quan hệ

Truy vấn cơ sở dữ liệu quan hệ (gọi tắt là truy vấn) là những câu hỏi về dữ liệu, vàcâu trả lời nằm trong một quan hệ mới. Ví dụ, chúng ta muốn tìm tất cả các sinh viên cótuổi nhỏ hơn 18 hoặc tất cả các sinh viên đăng ký học lớp Reggae203. Ngôn ngữ truyvấn là ngôn ngữ dùng để viết các truy vấn.

SQL là ngôn ngữ truy vấn phổ biến nhất trong các DBMS. Bây giờ, chúng tôi sẽ viếtmột số ví dụ của câu lệnh SQL để chỉ ra rằng truy vấn trên các quan hệ dễ dàng đến mứcnào. Xem xét minh họa của quan hệ Students chỉ ra trong Hình 1. Chúng ta có thể truy

82/470

vấn các dòng trong bảng Students để đưa ra danh sách những sinh viên có tuổi nhỏ hơn18, sử dụng câu lệnh sau:

SELECT * FROM Students S WHERE S.age < 18

Ký hiệu * có nghĩa là chúng ta sẽ đưa ra tất cả các trường của các bộ giá trị kết quả. Đểhiểu được truy vấn này, hãy nghĩ S như là một biến nắm giữ giá trị của từng bộ giá trịtrong Students, bộ này nối tiếp bộ kia. Điều kiện S.age<18 trong mệnh để Where chỉ rarằng chúng ta chỉ muốn lựa chọn những bộ giá trị có giá trị của age nhỏ hơn 18. Kết quảcủa truy vấn nằm trong Hình 6.

Những sinh viên có age < 18 trong minh họa S1

Điều kiện S.age <18 là một so sánh toán học của age với một giá trị integer, điều nàythực hiện được vì miền của trường age cũng là integer. Thêm vào đó, điều kiện như làS.age=S.sid không thực hiện được vì không thể so sánh một giá trị có kiểu integer vớimột giá trị có kiểu string, và SQL sẽ cho đây là lỗi và không có bộ giá trị nào được trảvề.

Thêm nữa, để lựa chọn tập con các bộ giá trị, truy vấn có thể trích chọn ra một tập concác trường. Chúng ta có thể đưa ra Name và Login của các sinh viên có tuổi nhỏ hơn 18bằng truy vấn sau:

SELECT S.name, S.login FROM Students S WHERE S.age < 18

Hình 7 chỉ ra kết quả của truy vấn này, nó bỏ đi các trường không được chỉ ra trongtruy vấn. Ghi nhớ rằng thứ tự thực hiện các phép toán cũng là vấn đề- nếu chúng ta bỏđi những trường không mong muốn trước, chúng ta không thể kiểm tra được điều kiệnS.age<18.

Chúng ta có thể kết hợp thông tin trong hai quan hệ Students và Enrolled. Nếu chúngta muốn có tên của sinh viên và cid của khoá học mà sinh viên học có kết quả học tập(grade) là 'A', chúng ta có thể thực hiện câu lệnh sau:

SELECT S.name, E.cid FROM Students S, Enrolled E WHERES.sid = E.sid AND E.grade = 'A'

83/470

Names và Logins của các sinh viên dưới 18 tuổi

Truy vấn này có thể được hiểu như sau: Nếu có một bộ giá trị S của Students và mộtbộ giá trị E của Enrolled thoả mãn S.id= E.id (S biểu diễn sinh viên tham gia khoá họcE) và E.grade='A', thì in ra tên sinh viên và mã khoá học mà sinh viên đó tham dự. Khixem xét minh hoạ của Students và Enrolled trong Hình 4, truy vấn này trả về kết quả làmột bộ giá trị {Smith, Topology112}.

Chúng ta sẽ nghiên cứu sâu hơn về truy vấn, và SQL trong những chương sau.

Thiết kế cơ sở dữ liệu logic: ER chuyển sang quan hệ

Mô hình quan hệ là thiết kế đầu tiên, thiết kế cơ sở dữ liệu mức cao. Lược đồ ER biểudiễn cơ sở dữ liệu, đó là một chuẩn áp dụng để sinh ra lược đồ cơ sở dữ liệu quan hệgần xấp xỉ với thiết kế ER. (Việc chuyển đổi gần như là việc thêm vào những điều màchúng ta không thể thể hiện tường minh trong thiết kế ER bằng cách sử dụng SQL-92).Bây giờ chúng ta biểu diễn cách thức như thế nào để chuyển lược đồ ER thành một tậpcác bảng cùng với các ràng buộc hỗ trợ, tức là lược đồ cơ sở dữ liệu quan hệ.

Các kiểu thực thể chuyển thành các bảng

Một kiểu thực thể được ánh xạ thành một quan hệ: Mỗi thuộc tính của kiểu thực thể trởthành thuộc tính của bảng. Ghi nhớ rằng chúng ta biết về miền của từng thuộc tính vàkhóa chính của mỗi kiểu thực thể.

Xem xét kiểu thực thể Employees với các thuộc tính ssn, name và lot chỉ ra trong Hình8. Một minh họa có thể của kiểu thực thể Employees, chứa ba thực thể được chỉ ra trongHình 9:

Kiểu thực thể Employees

Câu lệnh SQL sau thể hiện những thông tin trên, bao gồm các ràng buộc miền và khóa:

84/470

CREATE TABLE Employees ( ssn CHAR(11), name CHAR(30), lotINTEGER, PRIMARY KEY (ssn) )

Một minh hoạ của kiểu thực thể Employees

Các kiểu liên kết (không có ràng buộc) thành các Bảng.

Kiểu liên kết, tương tự như kiểu thực thể, được ánh xạ thành một quan hệ trong mô hìnhquan hệ. Chúng ta bắt đầu bằng việc xem xét kiểu liên kết không có khóa và các ràngbuộc tham dự, và chúng ta bàn cách làm như thế nào để nắm bắt được những ràng buộcnày trong những phần tiếp theo. Để biểu diễn một liên kết, chúng ta phải xác định từngthành phần thực thể tham dự và cung cấp những thông tin để biểu diễn những thuộc tínhcủa liên kết. Vì thế, những thuộc tính của quan hệ này bao gồm:

• Các khóa chính của các thực thể tham gia trong liên kết, đóng vai trò như lànhững trường khóa ngoại.

• Những thuộc tính biểu diễn của kiểu liên kết.

Tập các thuộc tính là thuộc tính không biểu diễn sẽ là siêu khóa của quan hệ. Nếu ở đókhông có những ràng buộc khóa (xem Phần 2.4.1), tập những thuộc tính này là khóa dựtuyển.

Xem xét kiểu liên kết Works_In2 trong Hình 10. Mỗi Department có nhiều văn phòngđặt ở nhiều vị trí khác nhau và chúng ta muốn lưu lại vị trí văn phòng làm việc của từngnhân viên.

Kiểu liên kết bậc ba

Tất cả thông tin có thể về bảng Works_In2 được SQL định nghĩa như sau:

85/470

CREATE TABLE Works In2 ( ssn CHAR(11), did INTEGER,address CHAR(20), since DATE, PRIMARY KEY (ssn, did,address), FOREIGN KEY (ssn) REFERENCES Employees, FOREIGNKEY (address) REFERENCES Locations, FOREIGN KEY (did)REFERENCES Departments )

Ghi nhớ rằng các trường address, did, và ssn không thể mang giá trị Null. Bởi vì nhữngtrường này là một phần của khóa chính trong quan hệ Works_In2, và ràng buộc NOTNULL là đúng đối với các trường đó. Ràng buộc này đảm bảo rằng những trường nàyxác định duy nhất một department, một employee, và một location trong mỗi bộ giá trịcủa Works_In. Chúng ta cũng có thể xác định rằng một hành động mong muốn nào đókhi một bộ giá trị tham chiếu tới các quan hệ Employees, Departments hoặc Locationsbị xoá. Trong chương này chúng ta giả sử rằng hành động mong muốn đó là hành độngmặc định trừ trường hợp mô hình ER có yêu cầu một hành động khác.

Kiểu liên kết Reports_To

Cuối cùng, chúng ta xem xét liên kết Reports_To chỉ ra trong Hình 11. Vai trò của chúthích supervisor và subordinate được sử dụng để tạo ra tên các trường có ý nghĩa trongcâu lệnh CREATE để tạo ra bảng Reports_To:

CREATE TABLE Reports To ( supervisor_ssn CHAR(11),subordinate_ssn CHAR(11), PRIMARY KEY (supervisor_ssn,subordinate_ssn), FOREIGN KEY (supervisor_ssn) REFERENCESEmployees(ssn), FOREIGN KEY (subordinate_ssn) REFERENCESEmployees(ssn))

Quan sát thấy rằng, chúng ta cần một tên tường minh cho trường tham chiếu củaEmployees bởi vì tên trường phải khác với tên của trường tham chiếu tới nó.

86/470

Chuyển một kiểu liên kết có ràng buộc khoá

Xem xét kiểu liên kết Manages trong Hình 12.

Bảng tương ứng với kiểu liên kết Manages có các thuộc tính ssn, did, since. Tuy nhiên,vì mỗi Department có nhiều nhất một người quản lý nên không thể có hai bộ giá trị cócùng giá trị did (khác với giá trị ssn). Kết quả của quan sát này là, riêng thuộc tính didcó thể làm khoá của quan hệ Manages, thay vì phải chọn một tập thuộc tính ?did, ssn?(vìđây không phải là tập tối thiểu). Quan hệ Manages có thể được định nghĩa bằng SQLnhư sau:

Ràng buộc khoá trên ManagesCREATE TABLE Manages ( ssn CHAR(11), did INTEGER, sinceDATE, PRIMARY KEY (did), FOREIGN KEY (ssn) REFERENCESEmployees, FOREIGN KEY (did) REFERENCES Departments )

Cách tiếp cận thứ hai gọi là 'gộp chung', tránh tạo ra một bảng cho một kiểu liên kết.Cách làm này sẽ chuyển tất cả các thông tin trong kiểu liên kết vào một trong nhữngkiểu quan hệ tham gia trong liên kết. Trong ví dụ Manages, vì mỗi Departments có nhiềunhất một người quản lý, chúng ta có thể thêm những trường khoá của Employees vàthuộc tính since vào kiểu quan hệ Departments.

Cách tiếp cận này tránh được việc tạo ra một quan hệ Manages, và những truy vấn yêucầu đưa ra người quản lý của Departments sẽ không cần phải kết hợp thông tin trong haiquan hệ. Nhược điểm của cách tiếp cận này là sẽ có những khoảng trống dư thừa nếucó những Departments không có người quản lý. Trong trường hợp này, những chỗ trốngsẽ được điền giá trị là Null. Cách áp dụng thứ nhất (sử dụng một bảng Manages riêng)tránh được sự dư thừa này, nhưng một số những truy vấn quan trọng yêu cầu chúng taphải kết hợp thông tin từ hai bảng sẽ làm chậm việc thực hiện câu lệnh.

Câu lệnh SQL sau định nghĩa quan hệ DEPT_Mgr thể hiện thông tin trong cảDepartments và Manages, minh hoạ cách tiếp cận thứ hai:

CREATE TABLE Dept_Mgr ( did INTEGER, dname CHAR(20),budget REAL, ssn CHAR(11), since DATE, PRIMARY KEY (did),FOREIGN KEY (ssn) REFERENCES Employees )

87/470

Ghi nhớ rằng ssn có thể có giá trị Null.

Cách tiếp cận này có thể áp dụng với những kiểu liên kết liên quan đến nhiều hơn haikiểu thực thể.

Chúng ta sẽ bàn thêm về lợi ích của hai cách tiếp cận này sau khi xem xét cách chuyểnmột kiểu liên kết có những ràng buộc tham dự (participation constraints) thành bảng.

Chuyển kiểu liên kết có những ràng buộc tham dự

Xem xét lược đồ trong Hình 13 có hai kiểu liên kết Manages và Works_In.

Manages và Works_In

Tất cả các Departments được yêu cầu có người quản lý, tức là có ràng buộc tham dự, vànhiều nhất là một người quản lý, tức là có ràng buộc khoá. Câu lệnh SQL sau đây phảnánh cách tiếp cận thứ 2 bàn đến trong Phần 3.5.3 và sử dụng ràng buộc khoá:

CREATE TABLE Dept_Mgr ( did INTEGER, dname CHAR(20),budget REAL, ssn CHAR(11) NOT NULL, since DATE, PRIMARYKEY (did), FOREIGN KEY (ssn) REFERENCES Employees ONDELETE NO ACTION )

Nó cũng minh họa ràng buộc tham dự, rằng tất cả các Departments phải có người quảnlý. Vì ssn không thể mang giá trị Null, mỗi bộ giá trị Dept_Mgr xác định một bộ giá trịcủa Employees (người làm quản lý). Xác nhận NO ACTION là mặc định và không cầnphải chỉ ra tường minh như trên, để đảm bảo rằng mỗi bộ giá trị của Employees khôngthể bị xóa trong khi nó đang được Dept_Mgr tham chiếu tới. Nếu chúng ta muốn xóamột bộ giá trị nào đó trong Employees, đầu tiên chúng ta cần thay đổi người quản lý này

88/470

sang người quản lý mới trong Dept_Mgr. (Chúng ta cũng có thể xác định CASCADEthay cho NO ACTION, nhưng nếu muốn xóa thông tin về một Employees, thì nhữngthông tin về Departments liên quan lại xóa theo thì sẽ không hợp lý.)

Ràng buộc tất cả các Departments phải có người quản lý không thể được chỉ ra nếu sửdụng cách tiếp cận thứ nhất trong Phần 3.5.3. (Nhìn vào định nghĩa của Manages và nghĩvề điều gì sẽ xảy ra nếu chúng ta không thêm vào các ràng buộc NOT NULL cho cáctrường ssn và did. Gợi ý: Ràng buộc sẽ ngăn cản sự thiếu vắng người quản lý, nhưngkhông đảm bảo rằng người quản lý này là người đầu tiên được đề cử làm người quản lýmỗi Departments!). Trường hợp này gây ra nhiều tranh luận trong việc ủng hộ cách tiếpcận thứ hai cho liên kết một-nhiều như Manages, đặc biệt là khi kiểu thực thể có ràngbuộc khóa và cũng có ràng buộc tham gia toàn bộ.

Không may là có rất nhiều ràng buộc tham dự mà chúng ta không thể biểu diễn sử dụngSQL-92. Ràng buộc và xác nhận bảng có thể được chỉ ra bằng cách sử dụng khả năngmạnh hơn của SQL (bàn tới trong Phần 5.11) và nó rất có ý nghĩa, và nó cũng rất có ýnghĩa để kiểm tra và thiết đặt ràng buộc. Ví dụ, chúng ta không thể thiết đặt các ràngbuộc tham dự trên quan hệ Works_In mà không sử dụng những ràng buộc phổ biến.Để giải thích vì sao, chúng ta thu được quan hệ Works_In bằng cách chuyển lược đồER sang các quan hệ. Nó chứa các trường ssn và did, là các khóa ngoại tham chiếu tớiEmployees và Departments. Để đảm bảo sự tham gia toàn bộ của Departments trongWorks_In, chúng ta phải đảm bảo rằng tất cả giá trị did trong Departments phải xuấthiện trong một bộ giá trị nào đó của Works_In. Chúng ta có thể cố gắng để đảm bảođiều kiện này bằng việc khai báo rằng did trong Departments là khóa ngoại tham chiếutới Works_In, nhưng đây không phải là ràng buộc khóa ngoại hợp lệ vì did không phảilà khóa dự tuyển của Works_In.

Để đảm bảo sự tham gia toàn bộ của Departments trong Works_In sử dụng SQL-92,chúng ta cần một xác nhận (assertion). Chúng ta phải đảm bảo rằng tất cả giá trị didtrong Departments phải xuất hiện trong một bộ giá trị của Works_In; thêm vào đó, bộgiá trị của Works_In phải không có giá trị NULL trong các trường mà các khóa ngoạiđang tham chiếu tới (trong ví dụ này là trường ssn). Chúng ta có thể đảm bảo thêm ràngbuộc này bằng việc đưa ra một yêu cầu mạnh hơn rằng ssn trong Works_In không thểchứa giá trị Null. (Đảm bảo rằng sự tham dự của Employees trong Works_In là toàn bộ).

Một ràng buộc khác cần sử dụng xác nhận để biểu diễn trong SQL là ràng buộc yêucầu mỗi thực thể Employees (trong liên kết với Manages) phải quản lý ít nhất mộtDepartment.

Trên thực tế, kiểu liên kết Manages làm ví dụ cho hầu hết các ràng buộc tham dự sửdụng các ràng buộc khóa và khóa ngoại. Manages là kiểu liên kết nhị phân, trong đó cóchính xác một kiểu thực thể (Departments) có ràng buộc khóa, và ràng buộc tham giatoàn bộ được biểu diễn trong kiểu thực thể này.

89/470

Chúng ta cũng có thể thể hiện những ràng buộc tham dự bằng sử dụng ràng buộc khóavà khóa ngoại trong một trường hợp đặc biệt khác: một kiểu liên kết mà tất cả các kiểuthực thể tham gia đều có ràng buộc khóa và ràng buộc tham gia toàn bộ. Cách chuyểntốt nhất trong trường hợp này là ánh xạ từng kiểu thực thể cũng như kiểu liên kết vàomột bảng.

Chuyển kiểu thực thể yếu

Kiểu thực thể yếu luôn luôn là một phần trong liên kết bậc hai một-nhiều và có ràngbuộc khóa và ràng buộc tham dự. Cách chuyển thứ hai được giới thiệu trong Phần 3.5.3là một ý tưởng giải quyết trường hợp này, nhưng chúng ta phải nhớ rằng thực thể yếuchỉ có một khóa bộ phận. Và khi thực thể chủ bị xóa, chúng ta muốn tất cả các thực thểyếu liên quan đến thực thể chủ này phải được xóa theo.

Xem xét thực thể yếu Dependents trong Hình 14, với khóa bộ phận là pname. Thựcthể Dependents có thể được xác định duy nhất khi chúng ta kết hợp giữa khóa chínhcủa thực thể chủ Employees và khóa bộ phận pname của Dependents, và thực thểDependents phải bị xóa nếu thực thể chủ Employees bị xóa.

Kiểu thực thể yếu Dependents

Chúng ta có thể thể hiện mong muốn trên bằng cách sử dụng câu lệnh định nghĩa quanhệ Dep_Policy:

CREATE TABLE Dep_Policy ( pname CHAR(20), age INTEGER,cost REAL, ssn CHAR(11), PRIMARY KEY (pname, ssn), FOREIGNKEY (ssn) REFERENCES Employees ON DELETE CASCADE )

Quan sát thấy rằng khóa chính là {pname, ssn}, vì Dependents là thực thể yếu. Ràngbuộc này sẽ thay đổi tùy vào cách chuyển đổi đã được bàn trong Phần 3.5.3. Chúng taphải đảm bảo rằng tất cả thực thể Dependents được liên kết với một thực thể Employees(thực thể chủ), giống như ràng buộc tham gia toàn bộ trên Dependents, có nghĩa là ssnkhông thể mang giá trị Null. Điều này được đảm bảo vì ssn là một phần của khóa chính.Lựa chọn CASCADE đảm bảo rằng thông tin về những người phụ thuộc (Dependents)liên quan đến một nhân viên sẽ bị xóa khi nhân viên đó bị xóa.

90/470

Chuyển hệ thống phân cấp

Chúng tôi sẽ trình bày hai cách tiếp cận để chuyển đổi một phân cấp ISA, áp dụng nhữngcách này cho lược đồ ER chỉ ra trong Hình 15.

Hệ thống phân cấp1. Chúng ta có thể ánh xạ mỗi kiểu thực thể Employees, Hourly_Emps, và

Contract_Emps tới một quan hệ. Quan hệ Employees được tạo trong Phần 2.2.Chúng ta sẽ bàn Hourly_Emps ở đây; Contract_Emps sẽ tương tự. Quan hệHourly_Emps bao gồm thuộc tính lương theo giờ và số giờ làm việc củaHourly_Emps. Nó cũng chứa thuộc tính khóa của lớp trên (trong trường hợpnày là ssn), thuộc tính này được sử dụng như khóa chính của Hourly_Emps,đồng thời là khóa ngoại tham chiếu tới lớp cha (Employees). Với mỗi thực thểHourly_Emps, giá trị của thuộc tính name và nhiều thuộc tính khác nữa đượclưu trữ trong dòng tương ứng của lớp cha (Employees). Ghi nhớ rằng nếu mộtbộ giá trị trong lớp cha bị xóa, những bộ giá trị tương ứng trong lớp con phảiđược xóa theo.

2. Cách hai, chúng ta có thể chỉ tạo ra hai quan hệ, tương ứng với Hourly_Empsvà Contract_Emps. Quan hệ Hourly_Emps bao gồm tất cả các thuộc củaHourly_Emps và các thuộc tính của Employees (ssn, name, lot, hourly_wages,hours_worked).

Cách tiếp cận đầu tiên là phổ biến và luôn luôn thực hiện được. Các truy vấn muốn kiểmtra tất cả các nhân viên mà không quan tâm đến những thuộc tính riêng biệt của lớpcon được thực hiện dễ dàng sử dụng quan hệ Employees. Tuy nhiên, những truy vấn chỉmuốn biết về những thông tin của nhân viên làm việc theo giờ thì chúng ta phải kết hợpquan hệ Hourly_Emps với quan hệ Employees để có được name và lot.

Cách áp dụng thứ hai không dùng được nếu chúng ta có những nhân viên không làm việctheo giờ (Hourly_Emps), cũng không làm việc theo hợp đồng (Contract_Emps). Tương

91/470

tự, nếu một nhân viên vừa làm việc theo giờ, vừa là nhân viên làm việc theo hợp đồngthì giá trị Name và Lot được lưu trữ hai lần. Việc lưu trữ nhiều lần có thể dẫn tới nhữngdị thường dữ liệu. Một truy vấn cần xem toàn bộ các nhân viên thì phải thực hiện trênhai quan hệ. Tuy nhiên, truy vấn cần kiểm tra chỉ những nhân viên làm việc theo giờ cóthể thực hiện chỉ trên một quan hệ. Việc lựa chọn cách áp dụng nào phải phụ thuộc vàoý nghĩa của dữ liệu và sự thường xuyên hay không của các truy cập trên các quan hệ.

Chuyển lược đồ ER có khối kết hợp

Xem xét lược đồ ER chỉ ra trong Hình 16.

Kiểu thực thể Employees, Projects, và Departments và kiểu liên kết Sponsors được ánhxạ như cách làm trong các phần trước. Với kiểu liên kết Monitors, chúng ta tạo ra mộtquan hệ có các thuộc tính sau: thuộc tính khóa của Employees (ssn), các thuộc tính khóacủa Sponsor (did, pid), và thuộc tính biểu diễn của Monitors (until). Việc chuyển này vềcơ bản giống như cách ánh xạ chuẩn cho mỗi kiểu liên kết, biểu diễn trong Phần 3.5.2.

Có một trường hợp đặc biệt trong cách chuyển đổi này là chúng ta có thể tinh giảm bằngcách xóa quan hệ Sponsors. Xem xét quan hệ Sponsors. Nó có các thuộc tính pid, did,và since và thường thì chúng ta cần đến nó (thêm vào Monitors) vì hai lý do:

1. Chúng ta phải ghi lại các thuộc tính biểu diễn (trong ví dụ của chúng ta là thuộctính since) của liên kết Sponsors.

2. Không phải tất cả các bảo trợ (giữa Departments và Projects) đều cần có ngườiđiều hành (monitor), và vì thế một số cặp {pid, did} trong quan hệ Sponsors cóthể không xuất hiện trong quan hệ Monitors.

Tuy nhiên, nếu Sponsors không có các thuộc tính biểu diễn và có ràng buộc tham giatoàn bộ trong Monitor (tức là sự bảo trợ nào giữa Departments và Projects đều phải cóngười điều hành), thì ta nhận thấy tất cả các minh họa có thể của quan hệ Sponsors đềucó thể nhận được từ các cột {pid, did} của Monitors; vì thế Sponsors có thể xóa được.

92/470

Khối kết hợp

ER tới Quan hệ: Một ví dụ khác

Xem xét lược đồ ER trong Hình 17.

Policy Revisited

Chúng ta có thể sử dụng các ràng buộc khóa để kết hợp thông tin Purchaser cùng vớiPolicies và thông tin Beneficiary cùng với Dependents, và chuyển nó vào mô hình quanhệ như sau:

CREATE TABLE Policies ( policyid INTEGER, cost REAL, ssnCHAR(11) NOT NULL, PRIMARY KEY (policyid), FOREIGN KEY(ssn) REFERENCES Employees ON DELETE CASCADE ) CREATE

93/470

TABLE Dependents ( pname CHAR(20), age INTEGER, policyidINTEGER, PRIMARY KEY (pname, policyid), FOREIGN KEY(policyid) REFERENCES Policies ON DELETE CASCADE )

Ghi nhớ rằng việc xóa một nhân viên sẽ dẫn tới xóa tất cả các chính sách (policies) liênquan đến nhân viên đó và tất cả các người phụ thuộc hưởng chính sách này. Thêm vàođó, mỗi người phụ thuộc được yêu cầu có một chính sách bảo vệ- bởi vì policyid là mộtphần trong khóa chính của Dependents, ở đó có một ràng buộc NOT NULL. Mô hìnhhày phản ánh chính xác các ràng buộc tham dự trong lược đồ ER và những hành độngđược dự định khi thực thể Employees bị xóa.

Nói chung, đó có thể là một chuỗi các liên kết của các kiểu thực thể yếu.Ví dụ, chúngta đã giả sử rằng policyid giúp xác định duy nhất một policy. Giả sử rằng policyid chỉphân biệt được các policies của một nhân viên; tức là, policyid chỉ là khóa thành phầnvà Policies chỉ nên được mô hình hóa như là một kiểu thực thể yếu. Giả định mới nàyvề policyid không phải là nguyên nhân lớn dẫn tới những bàn luận phía trước. Thực tế,chỉ có thay đổi là khóa chính của Policies bây giờ là {policyid, ssn} và định nghĩa củaDependents phải thay đổi- trường được gọi là ssn được thêm vào và trở thành một phầncủa khóa chính của Dependents và khóa ngoại tham chiếu tới Policies:

CREATE TABLE Dependents (pname CHAR(20), ssn CHAR(11), ageINTEGER, policyid INTEGER NOT NULL, PRIMARY KEY (pname,policyid, ssn), FOREIGN KEY (policyid, ssn) REFERENCESPolicies ON DELETE CASCADE)

Giới thiệu khung nhìn

Khung nhìn là một bảng bao gồm các dòng không được lưu trữ rõ ràng trong cơ sở dữliệu nhưng được đưa ra khi cần thiết thông qua định nghĩakhung nhìn. Xem xét quanhệ Students và Enrolled. Giả sử rằng chúng ta thường cần tìm name, sid và cid của cácsinh viên có điểm tốt nghiệp loại B. Chúng ta có thể định nghĩa một khung nhìn để phụcvụ mục đích này. Sử dụng SQL-92:

CREATE VIEW B-Students (name, sid, course) AS SELECTS.sname, S.sid, E.cid FROM Students S, Enrolled E WHERES.sid = E.sid AND E.grade = 'B'

Khung nhìn này có thể được sử dụng như là các bảng cơ sở, hoặc bảng được lưu trữtường minh. Như minh họa của Enrolled và Students được chỉ ra trong Hình 4, B-Students chứa các bộ giá trị như trong Hình 18. Về mặt lý thuyết, bất cứ khi nào B-Students cũng được sử dụng trong truy vấn, trước tiên, định nghĩa khung nhìn được dùngđể nhận được các minh họa dữ liệu như B-Students, sau đó, khung nhìn được sử dụng

94/470

như một quan hệ để các truy vấn có thể tham chiếu tới. (Chúng ta sẽ bàn tới truy vấn vàkhung nhìn được đánh giá như thế nào trong Chương 23.)

Minh họa của khung nhìn B-Students

Khung nhìn, Độc lập dữ liệu, Đảm bảo an toàn

Xem xét các mức trừu tượng mà chúng ta đã bàn đến trong Phân 1.5.2. Lược đồ vật lýcủa cơ sở dữ liệu quan hệ biểu diễn các quan hệ trong lược đồ khái niệm được lưu trữnhư thế nào, dưới dạng các tổ chức file và chỉ số. Lược đồ khái niệm là tập các lược đồcủa quan hệ trong cơ sở dữ liệu. Trong khi một số quan hệ trong lược đồ khái niệm cóthể được nhìn thấy từ các ứng dụng, ví dụ một phần của lược đồ ngoài của cơ sở dữ liệu,các quan hệ bổ sung trong lược đồ ngoài có thể được định nghĩa thông qua khung nhìn.Khung nhìn vì thế cung cấp sự hỗ trợ cho độc lập dữ liệu vật lý trong mô hình quan hệ.Vì thế, nó có thể được sử dụng để định nghĩa các quan hệ trong lược đồ ngoài.

Khung nhìn cũng có giá trị trong việc đảm bảo sự an toàn dữ liệu: Chúng ta có thể địnhnghĩa các khung nhìn cho một nhóm người sủ dụng, để đảm bảo rằng họ chỉ được truycập tới các thông tin mà họ được phép. Ví dụ, chúng ta có thể định nghĩa khung nhìncho phép sinh viên nhìn thấy tên và tuổi của các sinh viên khác, nhưng không cho phépnhìn thấy điểm, và cho phép tất cả sinh viên truy cập tới khung nhìn này để không làmảnh hưởng tới bảng Students.

Cập nhật trên khung nhìn

Mục đích của các khung nhìn là làm cho người dùng có thể nhìn thấy dữ liệu. Ngườidùng không nên lo lắng về sự khác biệt giữa khung nhìn và bảng cơ sở. Khung nhìn đượcsử dụng như các bảng trong khi định nghĩa truy vấn. Tuy nhiên, một điều bình thườnglà bạn muốn cập nhật dữ liệu thông qua khung nhìn. Trong trường hợp này, không maythay, có sự khác biệt giữa khung nhìn và bảng cơ sở.

Chuẩn SQL-92 cho phép cập nhật trên khung nhìn đối với các khung nhìn mà trong phầnđịnh nghĩa chỉ có các bảng cơ sở cùng với các phép chọn và phép chiếu, không có cácphép toán nhóm. Những khung nhìn này được gọi là các khung nhìn có khả năng cậpnhật. Một phép cập nhật trên khung nhìn loại này có thể được thực hiện bằng việc cậpnhật các cơ sở một cách rõ ràng. Xem sét khung nhìn sau:

CREAT VIEW GoodStudents (sid, gpa) AS SELECT S.sid, S.gpaFROM Students S WHERE S.gpa > 30

95/470

Chúng ta thực hiện lệnh để sửa giá trị của thuộc tính gpa của một dòng trong quan hệGoodStudents bằng việc sửa dòng tương ứng trong Students. Chúng ta có thể xóa mộtdòng GoodStudents bằng việc xóa các dòng tương ứng trong bảng Students. (Tóm lại,nếu khung nhìn không bao gồm khóa của bảng phía dưới, một vài dòng trong bảng cóthể liên quan tới một dòng trong khung nhìn. Đây là một trường hợp, ví dụ, nếu sử dụngS.sname thay vì S.sid trong định nghĩa của GoodStudents. Một lệnh ảnh hưởng đến cácdòng trong khung nhìn sẽ ảnh hưởng tới tất cả các dòng liên quan trong bảng phía dưới).

Chúng ta có thể thêm một vài dòng và GoodStudents bằng việc thêm một dòng vàoStudents, sử dụng giá trị Null trong các cột của Students, những cột mà không xuất hiệntrong GoodStudents (ví dụ: sname, login). Ghi nhớ rằng các cột đóng vai trò khóa chínhkhông được phép thêm giá trị Null. Vì thế, nếu chúng ta cố gắng thêm các dòng thôngqua khung nhìn, nhưng khung nhìn này không chứa khóa chính của bảng phía dưới thìyêu cầu thêm này sẽ bị từ chối. Ví dụ, nếu GoodStudents chứa sname mà không có sid,chúng ta không thể thêm các dòng vào bảng Student thông qua việc thêm vào khungnhìn GoodStudents.

Nhận xét quan trọng là, INSERT hoặc UPDATE có thể thay đổi các bảng cơ sở phíadưới mặc dù dòng này không xuất hiện trong khung nhìn! Ví dụ, nếu chúng ta cốgắng thêm một dòng {51234, 2.8} vào trong khung nhìn, dòng này có thể được thêmvào các bảng Students phía dưới, nhưng mà nó sẽ không xuất hiện trong khung nhìnGoodStudents vì nó không thỏa mãn điều kiện của khung nhìn là gpa>3.0. SQL-92 mặcđịnh là sẽ cho phép thêm vào, nhưng chúng ta có thể không cho phép thêm vào bộ giátrị không thỏa mãn này bằng cách sử dụng mệnh đề WITH CHECK OPTION trong khiđịnh nghĩa khung nhìn.

Chúng tôi nhắc nhở người đọc rằng khi khung nhìn được định nghĩa dựa trên các khungnhìn khác, những ảnh hưởng lẫn nhau giữa các định nghĩa khung nhìn này đối với việccập nhật và mệnh đề CHECK OPTION có thể trở nên phức tạp; chúng ta sẽ không đichi tiết phần này.

Những khung nhìn có khả năng cập nhật trong SQL:1999 Chuẩn SQL mới đã mở rộngnhững loại định nghĩa khung nhìn có khả năng cập nhật. Đối lập với SQL-92, địnhnghĩa khung nhìn chứa nhiều hơn một bảng trong mệnh đề FROM có thể được cập nhật.Chúng ta có thể cập nhật một trường của khung nhìn nếu trường là trường duy nhất nằmtrong những bảng phía dưới, và khoá chính của bảng đó nằm trong những trường củakhung nhìn.

SQL:1999 phân biệt giữa các khung nhìn chứa các dòng có thể sửa được (các khung nhìncó khả năng cập nhật) và các khung nhìn có thể thêm dòng mới (các khung nhìn có khảnăng thêm mới): Trong định nghĩa các khung nhìn chứa cấu trúc UNION, INTERSECTvà EXCEPT (đã bàn tới trong Chương 5) không thể được thêm dòng mới, mặc dù chúngcó thể được cập nhật. Khả năng cập nhật đảm bảo rằng những bộ giá trị được cập nhật

96/470

trong khung nhìn có thể được lần vết từ chính xác một bộ giá trị của các bảng đã sử dụngtrong định nghĩa khung nhìn.

Cần phải giới hạn việc cập nhật qua khung nhìn

Trong khi SQL-92 hạn chế khả năng cập nhật trên khung nhìn nghiêm ngặt hơn cầnthiết, có một vài vấn đề cơ bản đối với việc cập nhật dữ liệu thông qua khung nhìn, vàcó những lý do đúng để giới hạn một số loại của khung nhìn mới có khả năng cập nhật.Xem xét quan hệ Students và một quan hệ mới gọi là Clubs:

Clubs(cname: string, jyear: date, mname: string)

Một bộ giá trị trong Clubs chỉ ra rằng sinh viên có tên mname đã là thành viên của câulạc bộ cname từ năm jyear. Giả sử rằng chúng ta thường muốn tìm names và logins củanhững sinh viên có gpa lớn hơn 3 thuộc vào ít nhất một câu lạc bộ, cùng với tên câu lạcbộ và ngày vào câu lạc bộ. Chúng ta định nghĩa khung nhìn này như sau:

CREATE VIEW ActiveStudents (name, login, club, since) ASSELECT S.sname, S.login, C.cname, C.jyear FROM Students S,Clubs C WHERE S.sname = C.mname AND S.gpa > 3

Bây giờ giả sử rằng chúng ta muốn xoá dòng {Smith, smith@ee, Hiking, 1997} từ Ac-tiveStudents. Chúng ta làm điều này như thế nào? Các dòng trong ActiveStudents khôngđược lưu trữ tường minh nhưng được đưa ra khi cần thiết từ hai bảng Students và Clubssử dụng định nghĩa khung nhìn. Vì thế chúng ta phải thay đổi Students hoặc Clubs(hoặc cả hai). Công việc này được thực hiện bằng một trong hai cách: hoặc xoá dòng{53688, Smith, smith@ee, 18, 3.2} từ bảng Students hoặc xoá dòng {Hiking, 1997,Smith} từ Clubs. Nhưng không có giải pháp nào ở trên là thoả đáng. Việc xoá dòng trongbảng Students sẽ dẫn tới việc xoá dòng {Smith, smith@ee, Rowing, 1998} trong khungnhìn ActiveStudents. Việc xoá dòng trong Clubs cũng sẽ dẫn tới việc xoá dòng {Smith,smith@math, Hiking, 1997} trong khung nhìn ActiveStudents. Cả hai ảnh hưởng nàyđều không được chấp nhận. Thực tế, chỉ có một giải pháp có thể là không cho phép cậpnhật trên khung nhìn.

Nhiều khung nhìn có thể có nhiều hơn một bảng cơ sở, theo nguyên tắc phải được cậpnhật một cách an toàn. Khung nhìn B-Students chúng ta giới thiệu ở đầu của phần nàylà một ví dụ về khung nhìn như thế. Xem xét minh hoạ của B-Students chỉ ra trongHình 18 (cùng với minh hoạ của Students và Enrolled trong Hình 4). Để thêm một bộgiá trị, giả sử {Dave, 50000, Reggae203} vào B-Students, chúng ta đơn giản có thểthêm một bộ giá trị {Reggae203, B, 50000} vào Enrolled vì đã có một bộ giá trị có sidlà 50000 trong Students. Mặt khác, để thêm {John, 55000, Reggae203}, chúng ta phảithêm {Reggae203, B, 55000} vào Enrolled và cũng thêm {55000, John, null, null, null}vào Students. Lược đồ khung nhìn chứa những trường khoá chính của cả hai bảng phía

97/470

dưới, nếu không thì chúng ta sẽ không thể thêm vào trong khung nhìn này. Để xoá mộtbộ giá trị từ khung nhìn B-Students, chúng ta có thể xoá những bộ giá trị liên quan trongEnrolled.

Mặc dù ví dụ này chỉ ra rằng SQL-92 hạn chế khả năng cập nhật của khung nhìn làkhông cần thiết, nhưng nó vẫn chỉ ra được sự phức tạp trong kiểm soát việc cập nhậtthông qua khung nhìn trong những trường hợp chung khác. Vì những lý do thực tế này,SQL-92 đã lựa chọn chỉ cho phép cập nhật lên những loại khung nhìn nhất định.

Xoá/Sửa bảng và khung nhìn

Nếu chúng ta quyết định không cần đến một bảng cơ sở và chúng ta muốn xoá nó (tứclà, xoá tất cả các dòng trong bảng và thông tin định nghĩa bảng), chúng ta có thể sửdụng câu lệnh DROP TABLE. Ví dụ, DROP TABLE Students RESTRICT sẽ xoá bảngStudents trừ khi có một vài khung nhìn và ràng buộc tham chiếu tới Students; nếu đangcó sự tham chiếu này thì lệnh sẽ hỏng. Nếu từ khoá RESTRICT được thay bằng từCASCADE, Students sẽ bị xoá và bất kỳ tham chiếu của khung nhìn hoặc ràng buộctham chiếu cũng bị xoá theo; một trong những từ khoá này phải luôn luôn được xácđịnh. Khung nhìn có thể được xoá sử dụng lệnh DROP VIEW, thay vì DROP TABLE.

ALTER TABLE là lệnh sửa cấu trúc của một bảng đang tồn tại. Để thêm một cột có tênlà maiden-name vào bảng Students, chúng ta sẽ sử dụng lệnh sau đây:

ALTER TABLE Students ADD COLUMN maiden-name CHAR(10)

Định nghĩa Students được sửa để thêm vào cột này, và tất cả các dòng đang tồn tại đượcthêm giá trị Null vào cột này. ALTER TABLE có thể được sử dụng để xoá hoặc thêmcác cột, hoặc xoá các ràng buộc tham chiếu trên một bảng; chúng ta sẽ không bàn tớinhững phần này vì nó tương tự như xoá bảng hoặc khung nhìn.

Trường hợp nghiên cứu: Cửa hàng Internet

Bước thiết kế tiếp theo trong ví dụ này (tiếp tục từ Phần 2.8) là thiết kế cơ sở dữ liệulogic. Sử dụng cách tiếp cận chuẩn đã bàn trong Chương 3, DBDudes ánh xạ lược đồER trong Hình 2.20 tới mô hình quan hệ sẽ nhận được những bảng sau:

CREATE TABLE Books( isbn CHAR(10), title CHAR(80), authorCHAR(80), qty_in_stock INTEGER, price REAL, year_publishedINTEGER, PRIMARY KEY (isbn)) CREATE TABLE Orders( isbnCHAR(10), cid INTEGER, cardnum CHAR(16), qty INTEGER,order_date DATE, ship_date DATE, PRIMARY KEY (isbn, cid),FOREIGN KEY (isbn) REFERENCES Books, FOREIGN KEY(cid)

98/470

REFERENCES Customers) CREATE TABLE Customers( cid INTEGER,cname CHAR(80), address CHAR(200), PRIMARY KEY (cid))

Bảng Orders chứa trường Order_date và khoá của bảng chỉ là hai trường isbn và ciid.Bởi vì, một khách hàng không thể đặt cùng một cuốn sách trong những ngày khác nhau,sự giới hạn đó đã không được dự kiến. Vì sao không thêm thuộc tính Order_date vàokhoá của bảng Orders?

CREATE TABLE Orders( isbn CHAR(10), … PRIMARY KEY (isbn,cid), …)

Người kiểm tra, Dude2, sẽ không thích giải pháp này, cái mà anh ấy gọi là 'hack'. Anhấy nói rằng không có một lược đồ ER tự nhiên nào thể hiện được thiết kế này. Dude1không đồng ý với ý kiến này, và có ý kiến rằng, nên đến B&N để trình bày bản thiết kếtrước và sẽ nhận được phản hồi từ phía họ; tất cả mọi người đồng ý với đề nghị này vàhọ cùng quay trở lại B&N.

Người quản lý của B&N bây giờ lại đưa thêm những yêu cầu mà anh ấy chưa đề cậpđến trong lần gặp trước: "Những khách hàng nên được cho phép đặt một số các cuốnsách trong một hóa đơn duy nhất. Ví dụ, nếu khách hàng muốn đặt ba bản của cuốn 'TheEnglish Teacher' và hai bản của cuốn 'The Character of Physical Law', khách hàng nênđược phép đặt cả hai trong một hóa đơn duy nhất."

Trưởng nhóm thiết kế, Dude1, điều này ảnh hưởng như thế nào đến nguyên tắc giaohàng của cửa hàng. B&N có giao tất cả các sách trong hóa đơn cùng nhau không? Ngườiquản lý B&N giải thích nguyên tắc giao hàng của họ: "Ngay khi chúng tôi có đủ các bảncủa một cuốn sách trong hóa đơn, chúng tôi sẽ giao nó, mặc dù có những quyển sáchkhác chưa có đủ. Vì thế, có thể xảy ra, ba bản 'The English Teacher' được giao ngàyhôm nay, nhưng 'The Character of Physical Law' lại được giao vào ngày mai, vì thực sựlà hôm nay chúng tôi không còn đủ cuốn này trong kho. Thêm nữa, khách hàng của tôicó thể đặt nhiều hóa đơn trong một ngày, và họ muốn được xác nhận những hóa đơn màhọ đã đặt."

Nhóm DBDudes suy nghĩ về những yêu cầu trên và xác nhận lại: Đầu tiên, một hóa đơncó thể bao gồm nhiều cuốn sách. Thứ hai, khách hàng phải được phân biệt hai hóa đơnđược đặt trong một ngày. Để đáp ứng hai yêu cầu này, họ giới thiệu một thuộc tính mớithêm vào bảng Orders gọi là ordernum (số hóa đơn), thuộc tính này giúp xác định duynhất một hóa đơn và do đó khách hàng có thể đặt nó. Tuy nhiên, vì nhiều cuốn sách cóthể được đặt trong cùng một hóa đơn, nên cả hai thuộc tính ordernum và isbn đều cầnthiết để xác định qty (số lượng) và ship_date (ngày giao).

Thuộc tính Ordernum được gán giá trị là các số tự động tăng. Nếu có một vài hóa đơnđược đặt cùng bởi một khách hàng trong một ngày thì những hóa đơn này có số khác

99/470

nhau và hoàn toàn có thể phân biệt được nó. Câu lệnh SQL DDL để tạo bảng Ordersmới như sau:

CREATE TABLE Orders( ordernum INTEGER, isbn CHAR(10), cidINTEGER, cardnum CHAR(16), qty INTEGER, order_date DATE,ship_date DATE, PRIMARY KEY (ordernum, isbn), FOREIGN KEY(isbn) REFERENCES Books, FOREIGN KEY(cid) REFERENCESCustomers)

Người quản lý của B&N thực sự hài lòng với thiết kế bảng Orders như thế này, nhưnglại đưa ra thêm yêu cầu khác (DBDudes không bất ngờ về điều này, vì các khách hàngthường đưa ra những yêu cầu mới bổ sung những yêu cầu lần trước). Người quản lýmuốn tất cả các nhân viên của cửa hàng có thể xem chi tiết từng hóa đơn đặt hàng để họcó thể trả lời những yêu cầu của khách hàng, người quản lý muốn thông tin về thẻ tíndụng của khách hàng (credit card) được hiển thị để dễ dàng theo dõi. Để giải quyết yêucầu này, DBDudes đã tạo ra khung nhìn như sau:

CREATE VIEW OrderInfo (isbn, cid, qty, order_date,ship_date) AS SELECT O.cid, O.qty, O.order_date,O.ship_date FROM Orders O

Để lên kế hoạch cho phép nhân viên nào được nhìn thấy bảng này, người thiết kế phảigiới hạn các quyền truy cập cho các loại nhân viên khác nhau. Chúng ta sẽ xem xét phầnnày kỹ hơn trong Phần 21.7.

Câu hỏi ôn tập

Trả lời các câu hỏi ôn tập sau, câu trả lời có thể tìm trong phần được liệt kê bên cạnh:

• Quan hệ là gì? Phân biệt sự khác nhau giữa lược đồ quan hệ và minh họa quanhệ. Định nghĩa thuật ngữ bậc của quan hệ. Ràng buộc miền là gì? (Phần 1)

• Cấu trúc nào của SQL cho phép định nghĩa một quan hệ? Cấu trúc nào chophép sửa một minh họa quan hệ? (Phần 1.1)

• Ràng buộc tham chiếu là gì? Định nghĩa thuật ngữ ràng buộc khóa chính vàràng buộc khóa ngoại. Những ràng buộc này được biểu diễn như thế nào trongSQL? Những loại ràng buộc nào bạn có thể biểu diễn trong SQL? (Phần 2)

• DBMS làm gì khi những ràng buộc bị vi phạm? Người lập trình có thể điềukhiển thời gian kiểm tra sự vi phạm ràng buộc trong giao dịch như thế nào?(Phần 3)

• Truy vấn cơ sở dữ liệu quan hệ là gì? (Phần 4)• Chúng ta chuyển lược đồ ER vào các câu lệnh SQL như thế nào để tạo ra các

bảng. Một kiểu thực thể được ánh xạ thành một quan hệ như thế nào? Một kiểuliên kết được ánh xạ vào quan hệ như thế nào? Ràng buộc trong mô hình ER,

100/470

kiểu thực thể yếu, hệ thống phân cấp, khối kết hợp được sử dụng như thế nào?(Phần 5)

• Khung nhìn là gì? Khung nhìn hỗ trợ sự độc lập dữ liệu logic như thế nào?Khung nhìn được sử dụng cho bảo mật như thế nào? Truy vấn thực hiện trênkhung nhìn như thế nào? Vì sao SQL chỉ cho phép một số loại khung nhìn đượcphép cập nhật? (Phần 6)

• Cấu trúc nào của SQL được dùng để sửa cấu trúc bảng, xóa bảng và khungnhìn? Điều gì xảy ra khi ta xóa khung nhìn? (Phần 7)

Bài tập

Định nghĩa các thuật ngữ sau: Lược đồ quan hệ, lược đồ cơ sở dữ liệu quan hệ, miền giátrị, minh họa quan hệ, lực lượng quan hệ, và bậc quan hệ.

Trả lời:Lược đồ quan hệ được dùng để biểu diễn cấu trúc của quan hệ hay còn gọi làbảng. Nó bao gồm một tập các tên cột, kiểu dữ liệu ứng với mỗi cột, và tên của toàn bộbảng. Ví dụ, một lược đồ quan hệ có tên là Students có thể được biểu diễn như sau:

Students(sid: string, name: string, login: string, age:integer, gpa: real)

Quan hệ này có năm trường hay còn gọi là năm cột, cùng với tên và kiểu dữ liệu đượcchỉ ra như trên.

Lược đồ cơ sở dữ liệu quan hệ là tập những lược đồ quan hệ, biểu diễn một hoặc nhiềuquan hệ.

Miền giá trị đồng nghĩa với kiểu dữ liệu. Các thuộc tính có thể được xem như các cộttrong một bảng. Vì thế, miền thuộc tính tham chiếu tới kiểu dữ liệu của cột này.

Minh họa quan hệ là một tập các bộ giá trị (được biết đến như là các dòng hoặc các bảnghi) và mỗi dòng này đều thỏa mãn lược đồ quan hệ.

Lực lượng quan hệ là số lượng các bộ giá trị trong quan hệ.

Bậc quan hệ là số lượng các trường có trong quan hệ.

Có bao nhiêu bộ giá trị phân biệt trong một minh họa quan hệ với lực lượng 22?

Trả lời: Dành cho độc giả

Mô hình quan hệ, như nhìn thấy bằng cách viết truy vấn SQL, cung cấp sự độc lập dữliệu vật lý hay độc lập dữ liệu logic? Giải thích?

101/470

Trả lời: Người dùng của SQL không có ý niệm về cách dữ liệu được biểu diễn vật lýnhư thế nào trong máy. Anh/cô ấy truy vấn quan hệ hoàn toàn dựa vào mức trừu tượngcủa quan hệ. Vì thế, độc lập dữ liệu được đảm bảo. Vì người dùng có thể định nghĩakhung nhìn, độc lập dữ liệu logic có thể cũng đạt được bằng cách sử dụng các định nghĩakhung nhìn để che đi những thay đổi trong lược đồ khái niệm.

Sự khác nhau giữa khóa dự tuyển và khóa chính trong một quan hệ là gì? Siêu khóa làgì?

Trả lời: Dành cho độc giả

Xem xét minh họa quan hệ Students trong Hình 1.

1. Giả sử minh họa này là hợp lệ, đưa ra một hoặc một tập thuộc tính khóa không-dự-tuyển.

2. Giả sử minh họa này là hợp lệ, đưa ra một hoặc một tập thuộc tính là khóa dựtuyển.

Trả lời: Những ví dụ về khóa không-dự-tuyển bao gồm: {name}, {age}. Bạn không thểxác định khóa của một quan hệ mà chỉ dựa vào một minh họa của nó. Thực tế, minh họanày là ‘hợp lệ’ vô hình. Khóa dự tuyển được định nghĩa ở đây là khóa, không phải là cólẽ là khóa. Minh họa này chỉ là một ‘snapshot’ có thể của quan hệ. Ở những thời điểmkhác, quan hệ này có lẽ có một minh họa (hoặc snapshot) chứa những bộ giá trị khácnhau hoàn toàn, và chúng ta không thể dự đoán được những minh họa này chỉ dựa vàomột minh họa mà đề bài cung cấp.

Ràng buộc khóa ngoại là gì? Vì sao ràng buộc này lại quan trọng? Ràng buộc tham chiếulà gì?

Trả lời: Dành cho độc giả

Xem xét quan hệ Students, Faculty, Courses, Rooms, Enrolled, Teaches, và Meets_Inđã định nghĩa trong Phần 1.5.2.

1. Liệt kê tất cả các ràng buộc khóa ngoại giữa các quan hệ này.2. Cung cấp một ví dụ của ràng buộc bao gồm một hoặc nhiều quan hệ mà không

phải là ràng buộc khóa chính hay khóa ngoại.

Trả lời: Ở đây không có lý do gì để có một ràng buộc khóa ngoại (FKC) trên các quanhệ Students, Faculty, Courses, hoặc Rooms. Hầu hết chúng đều là các quan hệ cơ sở vàphải đứng độc lập. Phải quan tâm đặc biệt đến việc nhập dữ liệu vào trong những quanhệ cơ sở này.

102/470

Trong quan hệ Enrolled, sid và cid cả hai nên có FKC trên chúng. (Những sinh viên hiệntại phải được đăng ký những khóa học hiện tại). Cũng như vậy, vì các giáo viên phải dạynhững khóa học hiện tại, cả fid và cid trong quan hệ Teacher nên có FKCs. Cuối cùng,Meets _In nên đặt FKDs lên cả hai trường cid và rno.

Bạn cũng có thể thiết đặt một vài ràng buộc lên trên cơ sở dữ liệu này: chiều dàu củasid, cid, và fidcó thể được chuẩn hóa; giới hạn có thể được đặt trên kích thước của cácsố nhập vào các trường vv…

Trả lời tóm tắt các câu hỏi sau đây. Câu trả lời dựa trên lược đồ quan hệ như sau:

Emp(eid: integer, ename: string, age: integer, salary: real)

Works(eid: integer, did: integer, pct_ time: integer)

Dept(did: integer, dname: string, budget: real, managerid: integer)

1. Cung cấp ví dụ về ràng buộc khóa ngoại trong quan hệ Dept. Những lựa chọnnào cho thực thi ràng buộc này khi người dùng cố gắng xóa bộ giá trị của Dept?

2. Viết câu lệnh SQL yêu cầu tạo các quan hệ trên, bao gồm cả những ràng buộckhóa chính, khóa ngoại phù hợp.

3. Định nghĩa quan hệ Dept trong SQL để tất cả Departments được đảm bảo cómột người quản lý.

4. Viết câu lệnh SQL để thêm 'John Doe' như là một nhân viên với eid = 101, age= 32 và salary = 15,000.

5. Viết câu lệnh SQL để tăng lương tất cả các nhân viên lên 10%.6. Viết câu lệnh SQL để xóa Departments là 'Toy'. Cung cấp ràng buộc tham

chiếu bạn lựa chọn cho lược đồ này, giải thích điều gì xảy ra khi câu lệnh nàythực hiện.

Trả lời: Dành cho độc giả

Xem xét truy vấn SQL dựa trên kết quả được chỉ ra trong Hình 6.

1. Sửa truy vấn này để chỉ có cột Login xuất hiện trong kết quả.2. Nếu mệnh đề Where S.gpa>=2 được thêm vào truy vấn, kết quả của câu lệnh

này sẽ là gì?

Trả lời:

1. Chỉ có trường login trong kết quả:

SELECT S.login FROM Students S WHERE S.age < 18

103/470

2. Bộ giá trị về Madayan sẽ không hiển thị.

Giải thích vì sao thêm các ràng buộc NOT NULL vào định nghĩa SQL của quan hệManages (Trong Phần 3.5.3) sẽ không thiết đặt được ràng buộc mỗi Departments phảicó một người quản lý. Điều gì đạt được khi yêu cầu trường ssn của Manages là NotNull?

Trả lời: Dành cho độc giả

Giả sử rằng có liên kết bậc ba R giữa ba kiểu thực thể A, B và C, trong đó A có ràngbuộc khóa và ràng buộc toàn bộ và B có ràng buộc khóa; A có các thuộc tính a1 và a2,trong đó a1 là khóa; B và C tương tự. R không có các thuộc tính biểu diễn. Viết câu lệnhSQL để tạo các bảng tương ứng với những thông tin trên với những ràng buộc có thể.Nếu không thể thể hiện một vài ràng buộc, giải thích vì sao.

Trả lời: Các câu lệnh SQL sau tạo ra các quan hệ tương ứng:

CREATE TABLE A ( a1 CHAR(10), a2 CHAR(10), b1 CHAR(10), c1CHAR(10), PRIMARY KEY (a1), UNIQUE (b1), FOREIGN KEY (b1)REFERENCES B, FOREIGN KEY (c1) REFERENCES C ) CREATE TABLEB ( b1 CHAR(10), b2 CHAR(10), PRIMARY KEY (b1) ) CREATETABLE C ( b1 CHAR(10), c2 CHAR(10), PRIMARY KEY (c1) )

Câu lệnh SQL đầu tiên gán liên kết R vào bảng A và vì thế đảm bảo ràng buộc tham dự.

Xem xét kịch bản của Bài 2.2, nơi bạn thiết kế lược đồ ER cho cơ sở dữ liệu University.Viết câu lệnh để tạo ra các quan hệ tương ứng và thể hiện nhiều ràng buộc nhất có thể.Nếu bạn không thể hiện được một vài ràng buộc, giải thích vì sao.

Trả lời: Dành cho độc giả

Xem xét cơ sở dữ liệu University trong Bài 2.3 và lược đồ ER bạn thiết kế. Viết câu lệnhđể tạo ra các quan hệ tương ứng và thể hiện nhiều ràng buộc nhất có thể. Nếu bạn khôngthể hiện được một vài ràng buộc, giải thích vì sao.

Trả lời: Những câu lệnh SQL sau tạo ra các quan hệ tương ứng.

1. CREATE TABLE Professors( prof_ssn CHAR(10), nameCHAR(64), age INTEGER, rank INTEGER, speciality CHAR(64),PRIMARY KEY (prof_ssn)) 2. CREATE TABLE Depts( dnoINTEGER, dname CHAR(64), office CHAR(10), PRIMARY KEY(dno)) 3. CREATE TABLE Runs( dno INTEGER, Prof_ssnCHAR(10), PRIMARY KEY (dno, prof_ssn), FOREIGN KEY

104/470

(prof_ssn) REFERENCES Professors, FOREIGN KEY (dno)REFERENCES Depts ) 4. CREATE TABLE Work_Dept( dno INTEGER,Prof_ssn CHAR(10), pc_time INTEGER, PRIMARY KEY (dno,prof_ ssn), FOREIGN KEY (prof_ssn) REFERENCES Professors,FOREIGN KEY (dno) REFERENCES Depts )

Quan sát thấy rằng chúng ta có thể cần những ràng buộc kiểm tra hoặc các xác nhậntrong SQL để thiết đặt các một nguyên tắc là các Professors làm việc ở ít nhất mộtDepartment.

5. CREATE TABLE Project ( pid INTEGER, sponsor CHAR(32),start_date DATE, end_date DATE, budget FLOAT, PRIMARY KEY(pid) ) 6. CREATE TABLE Graduates ( grad_ssn CHAR(10), ageINTEGER, name CHAR(64), deg_prog CHAR(32), major INTEGER,PRIMARY KEY (grad_ssn), FOREIGN KEY (major) REFERENCESDepts)

Ghi nhớ rằng bảng Major không cần thiết vì mỗi Graduate chỉ có một major và vì thế nócó thể là một thuộc tính trong bảng Graduates.

7. CREATE TABLE Advisor ( senior_ssn CHAR(10), Grad_ssnCHAR(10), PRIMARY KEY (senior_ssn, grad_ssn), FOREIGN KEY(senior_ssn) REFERENCES Graduates (grad_ssn), FOREIGN KEY(grad_ssn) REFERENCES Graduates ) 8. CREATE TABLE Manages( pid INTEGER, Prof_ssn CHAR(10), PRIMARY KEY (pid,prof_ssn), FOREIGN KEY (prof_ssn) REFERENCES Professors,FOREIGN KEY (pid) REFERENCES Projects ) 9. CREATE TABLEWork_In ( pid INTEGER, Prof_ssn CHAR(10), PRIMARY KEY(pid, prof_ssn), FOREIGN KEY (prof_ssn) REFERENCESProfessors, FOREIGN KEY (pid) REFERENCES Projects )

Quan sát thấy rằng chúng ta không thể thiết đặt được ràng buộc tham dự cho Projectstrong bảng Work_In vì trong SQL thiếu những ràng buộc kiểm tra hoặc các xác nhận.

10. CREATE TABLE Supervises ( prof_ssn CHAR(10), Grad_ssnCHAR(10), pid INTEGER, PRIMARY KEY (prof_ssn, grad_ssn,pid), FOREIGN KEY (prof_ssn) REFERENCES Professors,FOREIGN KEY (grad_ssn) REFERENCES Graduates, FOREIGN KEY(pid) REFERENCES Projects )

105/470

Ghi nhớ rằng chúng ta không cần một bảng tường minh cho quan hệ Worrk_Proj vìtất cả những lần một Graduate làm việc cho một Project, anh/cô ấy đều phải có mộtSupervisor.

Xem xét kịch bản của Bài 2.4, nơi bạn thiết kế lược đồ ER cho cơ sở dữ liệu Company.Viết câu lệnh để tạo ra các quan hệ tương ứng và thể hiện nhiều ràng buộc nhất có thể.Nếu bạn không thể hiện được một vài ràng buộc, giải thích vì sao.

Trả lời: Dành cho độc giả

Xem xét cơ sở dữ liệu Notown của Bài 2.5. Bạn đã quyết định để Notown sử dụng hệquản trị cơ sở dữ liệu để lưu trữ dữ liệu của công ty. Chỉ ra các câu lệnh SQL để tạora các quan hệ tương ứng với các kiểu thực thể và kiểu quan hệ trong thiết kế của bạn.Chỉ ra những ràng buộc nào trong lược đồ ER mà bạn không thể thể hiện được bằng câulệnh SQL và giải thích tóm tắt vì sao bạn không thể biểu diễn chúng.

Trả lời: Những lệnh SQL sau tạo ra các quan hệ tương ứng.

1. CREATE TABLE Musicians( ssn CHAR(10), name CHAR(30),PRIMARY KEY (ssn)) 2. CREATE TABLE Instruments( instrIdCHAR(10), dname CHAR(30), key CHAR(5), PRIMARY KEY(instrId)) 3. CREATE TABLE Plays( ssn CHAR(10), instrIdINTEGER, PRIMARY KEY (ssn, instrId), FOREIGN KEY (ssn)REFERENCES Musicians, FOREIGN KEY (instrId) REFERENCESInstruments ) 4. CREATE TABLE Songs_Appears ( songIdINTEGER, author CHAR(30), title CHAR(30), albumIdentifierINTEGER NOT NULL, PRIMARY KEY (songId), FOREIGN KEY(albumIdentifier) References Album Producer) 5. CREATETABLE Telephone_Home ( phone CHAR(11), address CHAR(30),PRIMARY KEY (phone), FOREIGN KEY (address) REFERENCESPlace) 6. CREATE TABLE Lives ( ssn CHAR(10), phoneCHAR(11), address CHAR(30), PRIMARY KEY (ssn, address),FOREIGN KEY (phone, address) References Telephone_Home,FOREIGN KEY (ssn) REFERENCES Musicians ) 7. CREATE TABLEPlace ( address CHAR(30) ) 8. CREATE TABLE Perform (songId INTEGER, ssn CHAR(10), PRIMARY KEY (ssn, songId),FOREIGN KEY (songId) REFERENCES Songs, FOREIGN KEY (ssn)REFERENCES Musicians ) 9. CREATE TABLE Album Producer (albumIdentifier INTEGER, ssn CHAR(10), copyrightDate DATE,speed INTEGER, title CHAR(30), PRIMARY KEY(albumIdentifier), FOREIGN KEY (ssn) REFERENCES Musicians)

106/470

Chuyển lược đồ ER của bạn trong Bài 2.6 vào lược đồ quan hệ và chỉ ra các câu lệnhSQL cần thiết để tạo ra các quan hệ, chỉ sử dụng các ràng buộc khóa và ràng buộc Null.Nếu việc chuyển của bạn không thể minh họa được một vài ràng buộc trong lược đồ ER,giải thích vì sao.

Trong Bài 2.6, bạn cũng sửa lược đồ ER để nó bao gồm ràng buộc rằng, những kiểm tratrên một máy bay phải được thực hiện bằng kỹ sư, người là chuyên gia về loại máy baynày. Bạn có thể sửa các câu lệnh SQL đã dùng để định nghĩa các quan hệ (là kết quả củaviệc ánh xạ lược đồ ER) để thực hiện ràng buộc này.

Trả lời: Dành cho độc giả

Xem xét lược đồ ER bạn đã thiết kế cho Prescriptions-R-X trong Bài 2.7. Sử dụng SQL,định nghĩa các quan hệ tương ứng với các kiểu thực thể và kiểu liên kết trong thiết kếcủa bạn.

Trả lời: Những câu lệnh tạo ra các bảng tương ứng của kiểu thực thể Doctor, Pharmacy,và Pharm_co rất dễ thực hiện, độc giả tự viết. Những bảng khác có thể được tạo nhưsau:

1. CREATE TABLE Pri_Phy_Patient ( ssn CHAR(11), nameCHAR(20), age INTEGER, address CHAR(20), phy_ssn CHAR(11),PRIMARY KEY (ssn), FOREIGN KEY (phy_ssn) REFERENCESDoctor) 2. CREATE TABLE Prescription ( ssn CHAR(11),Phy_ssn CHAR(11), date CHAR(11), quantity INTEGER,trade_name CHAR(20), pharm_id CHAR(11), PRIMARY KEY (ssn,phy_ssn), FOREIGN KEY (ssn) REFERENCES Patient, FOREIGNKEY (phy_ssn) REFERENCES Doctor, FOREIGN KEY (trade_name,pharm_id) References Make_Drug) 3. CREATE TABLE Make_Drug(trade_name CHAR(20), Pharm_id CHAR(11), PRIMARY KEY(trade_name, pharm_id), FOREIGN KEY (trade_name)REFERENCES Drug, FOREIGN KEY (pharm_id) REFERENCESPharm_co) 4. CREATE TABLE Sell ( price INTEGER, nameCHAR(10), trade_name CHAR(10), PRIMARY KEY (name,trade_name), FOREIGN KEY (name) REFERENCES Pharmacy,FOREIGN KEY (trade_name) REFERENCES Drug) 5. CREATE TABLEContract ( name CHAR(20), Pharm_id CHAR(11), Start_dateCHAR(11), End_date CHAR(11), text CHAR(10000), supervisorCHAR(20), PRIMARY KEY (name, pharm_id), FOREIGN KEY (name)REFERENCES Pharmacy, FOREIGN KEY (pharm_id) REFERENCESPharm_co)

107/470

Viết câu lệnh SQL để tạo ra các quan hệ tương ứng với lược đồ ER bạn đã thiết kế trongBài 2.8. Nếu việc chuyển của bạn không thể minh họa được một vài ràng buộc tronglược đồ ER, giải thích vì sao.

Trả lời: Dành cho độc giả

Trả lời tóm tắt các câu hỏi sau đây dựa vào lược đồ cho bên dưới:

Emp(eid: integer, ename: string, age: integer, salary: real)

Works(eid: integer, did: integer, pct_ time: integer)

Dept(did: integer, dname: string, budget: real, managerid: integer)

1. Giả sử bạn có khung nhìn SeniorEmp được định nghĩa như sau:CREATE VIEW SeniorEmp(sname, sage, salary) AS SELECTE.ename, E.age, E.salary FROM Emp E WHERE E.age>50

Giải thích ví sao hệ thống sẽ không thực hiện truy vấn sau:

SELECT S.sname FROM SeniorEmp S WHERE S.salary>100,0001. Cung cấp ví dụ một khung nhìn trên Emp có thể được tự động cập nhật khi cập

nhật Emp.2. Cung cấp ví dụ một khung nhìn trên Emp không có khả năng cập nhật tự động

và giải thích vì sao lại không có khả năng này.

Trả lời: Trả lời mỗi câu hỏi như sau:

1. Hệ thống sẽ làm như sau:

SELECT S.name FROM (SELECT E.ename AS name, E.age,E.salary FROM Emp E WHERE E.age > 50 ) AS S WHERE S.salary> 100000

2. Khung nhìn sau trên Emp có thể được cập nhật một cách tự động bằng việc cập nhậtEmp:

CREATE VIEW SeniorEmp (eid, name, age, salary) AS SELECTE.eid, E.ename, E.age, E.salary FROM Emp E WHERE E.age >50

3. Khung nhìn sau không thể được cập nhật một cách tự động vì nó không rõ ràng bảnghi nào của Emp sẽ được cập nhật khi có một lệnh cập nhật nào đó.

108/470

CREATE VIEW AvgSalaryByAge (age, avgSalary) AS SELECTE.eid, AVG (E.salary) FROM Emp E GROUP BY E.age

Xem xét lược đồ sau:

Suppliers(sid: integer, sname: string, address: string)

Parts(pid: integer, pname: string, color: string)

Catalog(sid: integer, pid: integer, cost: real)

Quan hệ Catalog liệt kê danh sách các giá trả cho các sản phẩm của các nhà cung cấp.Trả lời các câu hỏi sau:

• Cung cấp một ví dụ của một khung nhìn có khả năng cập nhật trên một quanhệ.

Trả lời: Dành cho độc giả

Bài tập lớn

Bài 21 Tạo ra các quan hệ Students, Faculty, Courses, Rooms, Enrolled, Teaches, vàMeets_In trong Minibase.

Bài 22 Thêm những bộ giá trị trong Hình 1 and 4 vào trong quan hệ Students vàEnrolled. Tạo ra những minh họa có thể của các quan hệ khác.

Bài 23 Những ràng buộc tham chiếu nàp được thiết đặt bởi Minibase?

Bài 24 Chạy những truy vấn SQL trình bày trong chương này.

TÀI LIỆU THAM KHẢO

Mô hình quan hệ đã được đề xuất trong một bài báo của Codd [187]. Childs [176] vàKuhns [454] đã tiên đoán trước về sự phát triển này. Gallaire and Minker's book [296]chứa một vài bài báo về cơ sở dữ liệu quan hệ. Một hệ thống dựa trên mô hình quan hệlưu trữ toàn bộ dữ liệu trong một quan hệ được gọi là universal relation, được trình bàytrong [746]. Những mở rộng của mô hình quan hệ cùng với những giá trị null được mộtsố tác giả bàn đến, ví dụ [329, 396, 622, 754, 790].

Những dự án tiên phong bao gồm System R [40, 150] của IBM San Jose ResearchLaboratory (bây giờ là IBM Almaden Research Center), Ingres [717] ở trường đại họcCalifornia ở Berkeley, RTV [737] của IBM UK Scientific Center ở Peterlee, và QBE[801] ở IBM T.J.Watson Research Center.

109/470

Một phần lý thuyết đầy đủ và chắc chắn về lĩnh vực cơ sở dữ liệu quan hệ. Các tài liệu vềnhững lý thuyết này của Atzeni và DeAntonellis [45]; Maier [501]; và Abiteboul, Hull,và Vianu [3]. [415] là những nội dung thực sự có giá trị.

Những ràng buộc toàn vẹn trong cơ sở dữ liệu quan hệ đã được trình bày rất nhiều. [190]giải quyết những mở rộng ngữ nghĩa của mô hình quan hệ, và toàn vẹn, cụ thể là toànvẹn tham chiếu. [360] trình bày về các ràng buộc toàn vẹn ngữ nghĩa. [230] có các bàibáo giải quyết một loạt các ảnh hưởng của ràng buộc toàn vẹn, bao gồm những bàn luậnchi tiết về ràng buộc toàn vẹn. Một loạt tài liệu liên quan đến ràng buộc toàn vẹn thamchiếu. [51] so sánh giá của ràng buộc toàn vẹn tham chiếu thông qua thời gian biên dịch,thời gian chạy. [145] trình bày về ngôn ngữ dựa trên SQL để xác định các ràng buộctoàn vẹn và các điều kiện định danh. [713] trình bày về các công nghệ để kiểm tra ràngbuộc toàn vẹn. [180] trình bày về các ràng buộc toàn vẹn thời-gian-thực. Những bài báokhác trình bày về các toàn vẹn kiểm tra trong cơ sở dữ liệu bao gồm [82, 122, 138, 517].[681] xem xét cách tiếp cận của việc kiểm tra sự đúng đắn của các chương trình truy cậpcơ sở dữ liệu thay vì các kiểm tra run-time. Một vài bài báo được viết sớm hơn tronghướng nghiên cứu này là [296] và [295].

Trong phần tham khảo về SQL, nhìn vào phần nội dung tham khảo ở Chương 5. Quyểnsách này không trình bày về các sản phẩm dựa trên mô hình quan hệ, nhưng có rất nhiềusách hay trình bày về các hệ thống thương mại chính; ví dụ, Chamberlin’s DB2 [149],Date and McGoveran's book on Sybase [206], và Koch and Loney's book on Oracle[443].

Một vài bài báo xem xét vấn đề chuyển những cập nhật trên các khung nhìn thành cáccập nhật trên các bảng cơ sở [59, 208, 422, 468, 778]. [292] là tài liệu tốt về về chủ đềnày. Xem phần tài liệu tham khảo ở Chương 25 để hiểu thêm về truy vấn khung nhìn vàduy trì khung nhìn.

[731] trình bày về phương pháp thiết kế dựa vào lược đồ ER và sau đó ánh xạ thành môhình quan hệ . Markowitz nghiên cứu về ràng buộc tham chiếu trong ngữ cảnh lược đồER ánh xạ sang mô hình quan hệ và những thảo luận xung quanh cách thực thi trong cáchệ thống thương mại [513, 514].

110/470

Đại số quan hệ và các phép toán logicMở đầu

Chúng ta bắt đầu bằng việc làm rõ một vài điểm quan trọng trong các truy vấn quan hệ.Đầu vào và đầu ra của truy vấn đều là các quan hệ. Kết quả của truy vấn phụ thuộc vàocác minh hoạ dữ liệu của mỗi quan hệ đầu vào. Trong phần 3.4, chúng ta sử dụng têncác trường để tham chiếu tới các trường bởi vì chú thích này làm cho các truy vấn dễđọc hơn. Cách lựa chọn khác là ta dùng thứ tự các trường để tham chiếu tới quan hệ thayvì việc sử dụng tên trường.

Trong định nghĩa đại số và các phép toán logic quan hệ, lựa chọn tham chiếu tới cáctrường bằng vị trí thông dụng hơn bằng tên của trường: Các truy vấn thường dựa trênnhững tính toán của các kết quả trung gian, và nếu chúng ta sử dụng tên các trường đểtham chiếu tới các trường, định nghĩa cấu trúc truy vấn phải xác định trên tên các trườngcủa các kết quả trung gian này. Điều này có thể làm dài dòng và vì thế chúng ta lựa chọncách tham chiếu thứ hai. Tuy nhiên, cách tham chiếu thứ nhất làm cho truy vấn dễ đọchơn.

Từ những cân nhắc trên, chúng ta sử dụng cách tham chiếu theo vị trí để định nghĩa đạisố quan hệ và các phép toán logic quan hệ. Chúng ta cũng giới thiệu một quy tắc đơngiản là cho phép các quan hệ trung gian được 'thừa hưởng' tên các trường.

Chúng ta biểu diễn một số ví dụ truy vấn sử dụng những lược đồ sau:

Sailors(sid: integer, sname: string, rating: integer, age:real) Boats(bid: integer, bname: string, color: string)Reserves(sid: integer, bid: integer, day: date)

Những trường khoá được gạch chân, và miền xác định của mỗi trường được liệt kê sautên trường. Trong ví dụ trên, sid là khoá của Sailors, bid là trường khoá của Boats, vàtất cả các trường cùng nhau làm khóa của Reservers. Những trường trong minh hoạ củamột trong các quan hệ trên sẽ được tham chiếu bằng tên, hoặc vị trí dựa trên thứ tự củachúng được liệt kê.

Trong một vài ví dụ minh hoạ các toán tử đại số quan hệ, chúng ta sẽ sử dụng minh hoạdữ liệu S1 và S2 (của Sailors) và R1(của Reservers) trong Hình 1, 2, và 3.

111/470

Minh họa S1 của Sailors

Minh họa S2 của Sailors

Minh họa R1 của Reservers

Đại số quan hệ

Đại số quan hệ là một trong hai dạng ngôn ngữ truy vấn hỗ trợ trong mô hình quan hệ.Những truy vấn trong đại số được soạn thảo sử dụng tập các toán tử. Một đặc tính cơbản là tất cả các toán tử trong đại số quan hệ nhật một hoặc hai minh hoạ quan hệ như làtham biến và trả lại kết quả là một minh hoạ quan hệ. Đặc tính này làm nó dễ soạn thảocác toán tử để xây dựng các truy vấn phức tạp - biểu thức đại số quan hệ được địnhnghĩa đệ quy trong một quan hệ, một toán tử đại số đơn được áp dụng cho một biểu thứcđơn, một toán tử đại số nhị phân được áp dụng cho hai biểu thức. Chúng ta biểu diễnnhững toán tử cơ bản của đại số quan hệ (chọn, chiếu, hợp, nhân chéo, trừ), cũng nhưmột số các toán tử khác có thể được định nghĩa dựa trên các toán tử cơ bản trên.

Mỗi truy vấn quan hệ biểu diễn một thủ tục theo từng bước để tính toán ra kết quả mongđợi, dựa trên thứ tự các toán tử được áp dụng trong truy vấn. Biểu diễn tự nhiên của đạisố quan hệ cho phép chúng ta nghĩ một biểu thức đại số như một cách thức thực hiện,hay một kế hoạch để đánh giá truy vấn, và hệ thống quan hệ trên thực tế sử dụng nhữngbiểu thức đại số để biểu diễn những kế hoạch đánh giá truy vấn.

• Phép chọn và phép chiếu

Đại số quan hệ bao gồm các toán tử để lựa chọn các dòng trong quan hệ (σ) và các cột(π). Những toán tử này cho phép chúng ta thực thi dữ liệu trên các quan hệ đơn. Xemxét minh họa của quan hệ Sailors (S2) chỉ ra trong Hình 2. Chúng ta có thể truy cập đếncác dòng ứng với các thủy thủ lão luyện bằng cách sử dụng phép toán σ. Biểu diễn

112/470

σ rating>8(S2)

kết quả chỉ ra trong Hình 4. Chỉ số dưới rating>8 chỉ ra điều kiện lựa chọn để lọc ra cácbộ giá trị.

rating>8(S2)

π sname,rating(S2)

Toán tử chọn σ chỉ ra những bộ giá trị còn lại thông qua điều kiện chọn. Nói chung, điềukiện chọn là một tổ hợp logic (ví dụ, biểu thức sử dụng các kết nối logic ∧, và ∨) củacác thành phần, có dạng thuộc tínhophằng số hoặc thuộc tính 1 opthuộc tính 2, trong đóop là một trong số những toán tử so sánh <, <=, =, ≠, >=, hoặc >. Tham chiếu tới mộtthuộc tính có thể bằng vị trí (theo dạng .i hoặc i) hoặc theo tên (theo dạng .name hoặcname). Lược đồ kết quả của phép chọn là lược đồ của minh họa quan hệ đầu vào.

Phép chiếu (π) cho phép trích ra một số các cột từ một quan hệ; ví dụ, chúng ta có thểđưa ra sname và rating của tất cả các thủy thủ sử dụng toán tử π. Biểu diễn

πsname,rating(S2)

cho kết quả trong Hình 5. Chỉ số dưới sname, rating chỉ ra những trường cần đưa ra.Lược đồ kết quả của phép chiếu được xác định bằng những trường được đưa ra trongphép chiếu. Giả sử rằng chúng ta chỉ muốn đưa ra age của các thủy thủ. Biểu diễn

πage(S2)

cho kết quả trong Hình 6. Một điểm quan trọng cần ghi nhớ là, mặc dù ba thủy thủ cótuổi bằng 35, nhưng chỉ có một bộ giá trị có age=35 xuất hiện trong kết quả của phépchiếu, vì những bộ giá trị trùng nhau đã bị loại đi.

Vì kết quả của một biểu thức đại số quan hệ luôn là một quan hệ, chúng ta có thể thayquan hệ bằng một biểu thức. Ví dụ, chúng ta có thể đưa ra name và rating của các thủythủ lão luyện bằng việc kết hợp hai truy vấn phía trên. Biểu diễn

113/470

πsname,rating(σ rating>8(S2))

cho kết quả trong Hình 7. Kết quả này nhận được bằng việc áp dụng phép chọn trên S2(để có quan hệ trong Hình 4) và sau đó áp dụng phép chiếu.

πage(S2)

πsname,rating(σ rating>8(S2))• Các phép toán tập hợp

Những phép toán trên tập hợp sau đây được hỗ trợ trong đại số quan hệ: phép hợp, phépgiao, phép trừ (?), phép nhân chéo (×).

Phép hợp: R U S trả về một minh họa quan hệ chứa tất cả các bộ giá trị có trong minhhọa quan hệ R hoặc trong minh họa quan hệ S (hoặc cả hai). R và S phải là khả hợp, vàlược đồ kết quả được định nghĩa giống hệt của R.

Hai quan hệ được gọi là khả hợp nếu nó thỏa mãn các điều kiện sau đây:

• Chúng có cùng số lượng các trường, và• Những trường tương ứng, theo thứ tự từ trái sang phải, có cùng miền xác định.

Ghi nhớ rằng tên các trường không được sử dụng trong định nghĩa khả hợp. Cho thuậntiện, chúng ta sẽ giả sử rằng các trường của R U S thừa kế tên các trường từ R, nếu cáctrường của R có tên. (Giả định này là ngầm định trong định nghĩa lược đồ của R U S)

Phép giao: R giao S trả về một minh họa quan hệ chứa tất cả các bộ giá trị xuất hiệntrong cả hai quan hệ R và S. Quan hệ R và S phải là khả hợp, và lược đồ kết quả đượcđịnh nghĩa giống hệt với lược đồ của R.

Phép trừ: R ? S trả về một minh họa quan hệ chứa tất cả các bộ giá trị xuất hiện trongR nhưng không xuất hiện trong S. Quan hệ R và S phải là khả hợp, và lược đồ kết quảđược định nghĩa giống hệt với lược đồ của R.

Phép nhân chéo: R × S trả về một minh họa quan hệ mà trong lược đồ chứa tất cả cáctrường của R (theo thứ tự xuất hiện của chúng trong R) và theo sau là tất cả các trườngcủa S (theo tứ tự xuất hiện của chúng trong S). Kết quả của R × S chứa một bộ giá trị

114/470

<r,s> (sự móc nối của r và s) cho mỗi cặp của các bộ giá trị r ∈ R, s ∈ S. Phép nhânchéo đôi khi được gọi là phép Tích đề các.

Chúng ta sử dụng thỏa thuận rằng các tên của các trường trong R × S được thừa kế từtên của các trường tương ứng trong R và S. Có thể trong R và S có những trường có têntrùng nhau; tình trạng này tạo ra sự tranh chấp tên. Những trường tương ứng trong R ×S sẽ không có tên và chúng được tham chiếu chỉ thông qua vị trí của trường.

Trong những định nghĩa trước, ghi nhớ rằng mỗi toán tử có thể được áp dụng tới cácminh họa quan hệ được tính toán từ các biểu thức đại số quan hệ.

Bây giờ chúng ta sẽ minh họa các định nghĩa này thông qua một vài ví dụ. Phép hợp củaS1 và S2 chỉ ra kết quả trong Hình 8. Những trường được liệt kê theo thứ tự; tên của cáctrường được kế thừa từ S1. S2 có cùng tên các trường, tất nhiên, vì nó cũng là một minhhọa của quan hệ Sailors. Nói chung, tên của các trường trong S2 có thể khác, vì chúng tachỉ yêu cầu sự tương đương về miền giá trị (tên trường có thể khác nhau). Ghi nhớ rằngkết quả là một tập các bộ giá trị. Bộ giá trị xuất hiện trong cả S1 và S2 chỉ xuất hiện mộtlần trong S1 U S2.

S1 U R1 không phải là phép toán đúng vì hai quan hệ này không khả hợp. Phép giao củaS1 và S2 chỉ ra trong Hình 9, và phép trừ chỉ ra trong Hình 10.

S1 U S2

Kết quả của phép nhân chéo S1 × R1 được chỉ ra trong Hình 11. Bởi vì R1 và S1 cùngcó trường có tên là sid, do thỏa thuận của chúng ta về tên các trường, hai trường tươngứng trong S1 × R1 không được đặt tên, và tham chiếu tới chúng chỉ thông qua vị tríxuất hiện trong Hình 11. Các trường của S1 × R1 có cùng miền với các trường tươngứng trong R1 và S1. Trong Hình 11, sid được liệt kê trong ngoặc để nhấn mạnh rằng nókhông được thừa kế tên trường, chỉ miền tương ứng là được thừa kế.

S1 giao S2

115/470

S1 ? S2

S1 × S2• Đổi tên

Chúng ta đã cẩn thận để chọn các thỏa thuận đặt tên cho trường, kết quả của một biểuthức đại số quan hệ thừa kế các tên từ các minh họa quan hệ. Tuy nhiên, xung đột tên cóthể xảy ra trong một vài trường hợp; ví dụ S1 × S2. Vì thế, sẽ thuận lợi hơn nếu có thểđược đặt tên rõ ràng cho các trường trong các biểu thức đại số quan hệ.

Chúng ta giới thiệu một toán tử đổi tên ρ cho mục đích này. Biểu diễn ρ(R( F̄), E) lấymột biểu thức đại số quan hệ bất kỳ E và trả về một minh họa của quan hệ (mới) gọi làR. R chứa những bộ giá trị như trong E, và có cùng lược đồ với E, nhưng một số trườngđã được đổi tên. Tên các trường trong quan hệ R cũng giống như trong E, trừ nhữngtrường được đổi tên nằm trong danh sách đổi tênF̄, liệt kê theo dạng tên cũ!tên mới hoặcvị trí!tên mới. Với những ρ được định nghĩa tốt, tham chiếu tới các trường (theo dạngtrên) không mập mờ, và không có hai trường trong kết quả có cùng tên. Đôi khi chúngta muốn chỉ đổi tên các trường hoặc tên các quan hệ; chúng ta sẽ coi cả R và F̄là khôngbắt buộc trong sử dụng của ρ. (Tất nhiên, nó sẽ vô nghĩa nếu bỏ cả hai).

Ví dụ, biểu diễn ρ(C(1 → sid1, 5 → sid2), S1 × S2) trả về một quan hệ chứa những bộgiá trị trong Hình 11 và có lược đồ sau: C(sid1: integer, sname: string, rating: integer,age: real, sid2: integer, bid: integer, day: dates).

Có thể có một số toán tử bổ sung trong đại số, nhưng tất cả chúng có thể được định nghĩadưới dạng các toán tử ở phần sau. (Thực tế, toán tử đổi tên chỉ dùng để tạo sự thuận lợivề cú pháp,và thậm chí toán tử giao là dư thừa; R giao S có thể được định nghĩa bằngR ? (R ? S). Chúng ta xem xét những toán tử bổ sung này, và định nghĩa của chúng dựatrên các toán tử cơ bản trong những phần sau.

• Kết nối

116/470

Phép toán kết nối là một trong những phép toán hữu dụng nhất trong đại số quan hệvà nó là cách thông thường nhất để kết nối thông tin từ hai hoặc nhiều quan hệ. Mặcdù một kết nối có thể được định nghĩa như một phép nhân chéo, tiếp sau là phép chọnvà phép chiếu. Trong thực tế, kết nối xuất hiện thường xuyên hơn phép nhân chéo đơngiản. Thêm nữa, kết quả của phép nhân chéo lớn hơn nhiều so với phép nối. Vì lý donày, phép nối đã nhận được rất nhiều sự chú ý, và có một loạt các biến thể của phép nối.

Điều kiện nối

Phiên bản chung nhất của phép nối chấp nhận a điều kiện nối c và cặp của minh họaquan hệ được xem như đối số, và kết quả trả về là một minh họa quan hệ. Dạng của điềukiện nối giống như điều kiện chọn. Phép nối được định nghĩa như sau:

Vì thế, phép được định nghĩa như một phép nhân chéo, theo sau là phép chọn. Ghinhớ rằng điều kiện c có thể tham chiếu tới các thuộc tính của cả R và S. Sự tham chiếutới một thuộc tính của quan hệ, giả sử R, có thể bằng vị trí (theo dạng R.i) hoặc bằng tên(theo dạng R.name).

Như ví dụ, kết quả của S1 S1.sid<R1.sidR1 được chỉ ra trong Hình 12. Vì sid xuất hiệntrong cả S1 và R1, những trường tương ứng trong kết quả của phép nhân chéo S1 × R1(và do đó cũng trong kết quả của S1 S1.sid<R1.sidR1) sẽ không được đặt tên. Miền xácđịnh được thừa kế từ những trường tương ứng của S1 và R1.

S1 S1.sid<R1.sidR1

Nối bằng

Trường hợp thường gặp của phép nối R S là khi điều kiện nối chứa chỉ các đẳng thức(liên quan tới ∧) theo dạng R.name1 =S.name2, đó là đẳng thức giữa hai trường trongR và S. Trong trường hợp này, rõ ràng có một số sự dư thừa trong những thuộc tính cònlại của kết quả. Nếu điều kiện nối chỉ chứa các đẳng thức, phép nối được tinh lọc bằngviệc thêm các phép chiếu để S.name2 bị xóa bỏ. Phép nối với sự tinh lọc này được gọilà phép nối bằng.

Lược đồ kết quả của phép nối bằng chứa những trường của R (với tên và miền xác địnhtương đương trong R), theo sau là các trường của S mà các trường này không xuất hiệntrong điều kiện nối. Nếu tập các trường trong quan hệ kết quả có hai trường được thừakế từ R và S có cùng tên, chúng sẽ không được đặt tên trong quan hệ kết quả.

117/470

Chúng ta minh họa kết quả S1 R.sid=S.sid R1 trong Hình 13. Ghi nhớ rằng chỉ có mộttrường sid xuất hiện trong kết quả.

S1 R.sid=S.sid R1

Nối tự nhiên

Trường hợp đặc biệt khác của phép nối R S là nối bằng trong đó các đẳng thức đượcxác định trên tất cả các trường có cùng tên trong R và S. Trong trường hợp này, để đơngiản chúng ta có thể lờ đi điều kiện nối; mặc định điều kiện nối là tập các đẳng thức trêntất cả các trường chung. Chúng ta có thể gọi trường hợp đặc biệt này là nối tự nhiên, vànó được đảm bảo sẽ không có hai trường có cùng tên. Biểu diễn nối bằng S1 R.sid=S.sidR1 là một trường hợp của nối tự nhiên và có thể được ghi đơn giản là S1 R1, vì chỉcó trường chung là sid. Nếu hai quan hệ không có các thuộc tính chung, S1 R1 đơngiản chỉ là phép nhân chéo.

• Phép chia

Phép chia hữu ích để biểu diễn một số kiểu truy vấn, ví dụ: "Tìm tên của các thủy thủ đãphục vụ trên tất cả chuyến tàu". Việc hiểu được làm thế nào để sử dụng các toán tử cơbản của đại số quan hệ cho định nghĩa phép chia là một bài tập hữu ích. Tuy nhiên, phépchia không quan trọng như là các phép toán khác- nó không cần thường xuyên, và cáchệ thống cơ sở dữ liệu không cố gắng để khai thác ngữ nghĩa của phép chia bằng cáchthực hiện nó như là một toán tử riêng biệt (ví dụ, nó được thực hiện cùng với phép nối).

Chúng ta sẽ bàn tới phép chia thông qua một ví dụ. Xem xét hai minh họa quan hệ Avà B trong đó A có chính xác hai trường x và y, và B chỉ có một trường y, có miền nhưtrong A. Chúng ta định nghĩa phép chia A/B như sau: Với mỗi giá trị x trong (cột đầutiên của) A, giả sử tập của giá trị y xuất hiện trong (trường thứ hai của) các bộ giá trị củaA cùng với giá trị của x. Nếu tập giá trị này chứa (tất cả giá trị y trong) B, giá trị x là kếtquả của A/B.

Sự tương đương với phép chia số nguyên có lẽ giúp chúng ta hiểu được phép chia. Vớihai số nguyên A và B, A/B tạo ra số nguyên lớn nhất Q, với Q*B ≤ A. Với các minh họaquan hệ A và B, A/B là minh họa quan hệ lớn nhất để Q × B ⊆ A.

Phép chia minh họa trong Hình 14. A là một quan hệ liệt kê các sản phẩm (Parts) đượccung cấp bởi các nhà cung cấp (Suppliers), và B là quan hệ liệt kê tất cả các sản phẩm

118/470

(Parts). Kết quả của A/Bi là tất cả các nhà cung cấp, người mà cung cấp tất cả các sảnphẩm được liệt kê trong Bi.

Biểu diễn A/B dựa trên những toán tử đại số quan hệ là một bài tập thú vị, và người đọcnên cố gắng để làm trước khi đọc tiếp. Ý tưởng cơ bản là để tính ra được tất cả giá trịx trong A không bị loại ra (disqualified). Giá trị x bị loại ra nếu khi gán giá trị y cho B,chúng ta có một bộ giá trị <x,y> không nằm trong A. Chúng ta có thể tính được các bộgiá trị bị loại sử dụng biểu diễn đại số sau:

π x((π(A) × B) ? A)

Vì thế, chúng ta có thể định nghĩa A/B như sau:

πx(A) ? π x((π(A) × B) ? A)

Ví dụ minh họa phép chia

Để hiểu được phép chia trong dạng tổng quát, chúng ta phải xem xét trường hợp khi cảx và y được thay thế bằng một tập các thuộc tính. Sự tổng quát không quá khó hiểu vànó là một bài tập cho người đọc. Chúng ta sẽ bàn tới những ví dụ khác minh họa phépchia trong phần sau (Truy vấn Q9 và Q10)

• Những ví dụ khác của Truy vấn đại số quan hệ

Bây giờ chúng tôi trình bày một số ví dụ để minh họa việc viết các truy vấn trong đạisố quan hệ. Chúng ta sử dụng các lược đồ Sailors, Reserves và Boats cho những ví dụtrong phần này. Chúng ta sẽ sử dụng những dấu ngoặc đơn cần thiết để những biểu thứcđại số được rõ ràng. Ghi nhớ rằng tất cả các truy vấn ví dụ trong chương này được đánhsố thứ tự. Những mã số này được sử dụng trong cả chương này và chương về truy vấnSQL (Chương 5). Sự đánh số thứ tự làm cho ta dễ dàng xác định truy vấn khi đọc lại

119/470

trong ngữ cảnh của các phép toán quan hệ và trong SQL và cũng để so sánh các cáchkhác nhau để viết một truy vấn. (Tất cả tham chiếu tới một truy vấn có thể được tìm thấytrong phần chỉ số chủ đề của cuốn sách)

Trong chương này (và chương 5), chúng ta sẽ biểu diễn truy vấn sử dụng minh họa dữliệu S3 của Sailors, R2 của Reserves và B1 của Boats, chỉ ra trong Hình 15, 16 và 17.

(Q1) Tìm tên của các thủy thủ đã đặt chỗ trên chuyến tàu 103.

Truy vấn này có thể được viết như sau:

πsname((σbid=103Reserves) Sailors)

Minh họa S3 của Sailors

Minh họa R2 của Reserves

120/470

Minh họa B1 của Boats

Đầu tiên, chúng ta lấy ra bộ giá trị trong Reserves thỏa mãn bid =103 và sau đó kết nốitự nhiên bộ giá trị này với Sailors. Biểu thức này có thể được đánh giá trên minh hoạ củaReserves và Sailors. Kết quả dựa trên minh hoạ R2 và S3, kết quả là một quan hệ chỉ cómột trường, gọi là sname, và ba bộ giá trị <Dustini>, <Horatioi> và <Lubberi>.(Quansát thấy rằng có hai thuỷ thủ có cùng tên Horatio, và chỉ có một trong số họ đã phục vụtrên chuyến 103).

Chúng ta có thể chia truy vấn này thành các phần nhỏ sử dụng toán tử đổi tên:

ρ(Temp1, σ bid=103 Reserves)

ρ(Temp2, Temp1 Sailors)

πsname(Temp2)

Ghi nhớ rằng bởi vì chúng ta chỉ sử dụng ρ để cung cấp tên cho quan hệ trung gian, đổitên không bắt buộc và có thể bỏ qua. Temp1 chỉ ra một quan hệ trung gian để xác địnhcác Reservations của chuyến 103. Temp2 là một quan hệ trung gian khác, và nó chỉ racác thuỷ thuỷ đã làm một Reservation trên tập Temp1. Minh hoạ của các quan hệ khiđánh giá truy vấn này trên các minh hoạ R2 và S3 được chỉ ra trong Hình 18 và 19. Cuốicùng, chúng ta trích ra cột sname từ Temp2.

Minh hoạ của Temp1

Minh hoạ của Temp2

121/470

Phiên bản của truy vấn sử dụng ρ cơ bản giống như truy vấn nguyên bản; sủ dụng ρ nhưkiểu cú pháp. Tuy nhiên, có một số cách khác nhau để viết truy vấn trong đại số quanhệ. Đây là một cách viết khác:

πsname(σbid=103(Reserves Sailors))

Trong phiên bản này, đầu tiên chúng ta thực hiện phép nối tự nhiên của Reserves vàSailors, sau đó áp dụng phép chọn và phép chiếu.

Ví dụ đưa ra cách nhìn sơ qua về vai trò của đại số trong quan hệ DBMS. Các truy vấnđược viết bởi người sử dụng bằng ngôn ngữ như là SQL. DBMS thực hiện biên dịchmột truy vấn thành đại số quan hệ, và sau đó tìm những cách biểu diễn đại số khác để cóthể thực hiện truy vấn hiệu quả hơn. Nếu truy vấn của người sử dụng đầu tiên được biểudiễn như sau:

πsname(σbid=103(Reserves Sailors))

một bộ tối ưu hoá truy vấn tốt sẽ tìm ra một cách biểu diễn khác như sau

πsname((σbid=103Reserves) Sailors)

Thêm nữa, bộ tối ưu hoá sẽ nhận ra rằng cách biểu diễn thứ hai hiệu quả hơn cách biểudiễn thứ nhất vì kích thước của những quan hệ trung gian nhỏ hơn vì đã sử dụng phépchọn trước.

πsname((σcolor='red'Boats) Reserves Sailors)

Truy vấn này bao gồm một loạt các phép nối đôi. Đầu tiên, chúng ta chọn được nhữngbộ giá trị trên Boats có màu 'red'. Sau đó chúng ta liên kết tập giá trị này với Reserves(kết nối tự nhiên, cùng đẳng thức được xác định trên cột sid) để truy cập đến tên của cácthuỷ thủ đã đặt chỗ trên tàu có màu 'red'. Cuối cùng, chúng ta thực hiện phép chiếu đểlấy ra tên (name) các thuỷ thủ. Khi thực hiện trên minh hoạ B1, R2 và S3, kết quả củatruy vấn trên lấy được ba tên: Dustin, Horatio, và Lubber.

Biểu diễn tương đương là:

πsname(πsid((πbid σcolor='red'Boats) Reserves) Sailors)

Người đọc được yêu cầu viết lại những truy vấn này sử dụng ρ để làm những quan hệtrung gian rõ ràng và để so sánh các lược đồ của các quan hệ trung gian. Cách viết thứhai đưa ra những quan hệ trung gian với ít trường hơn (và vì thế kết quả của các minhhoạ quan hệ trung gian có ít bộ giá trị hơn). Tối ưu hoá truy vấn quan hệ sẽ cố gắng đạtđến cách biểu diễn thứ hai nếu đầu tiên nó được cung cấp như cách biểu diễn thứ nhất.

122/470

(Q3) Tìm màu của các tàu được Lubber phục vụ.

πcolor((σsname='Lubber ' Sailors) Reserves Boats)

Truy vấn này rất giống truy vấn chúng ta đã sử dụng để đưa ra các thuỷ thủ đã phục vụtrên tàu màu 'red'. Trên minh hoạ quan hệ B1, R2 và S3, truy vấn này sẽ trả về các màulà 'green' và 'red'.

(Q4) Tìm tên của các thuỷ thủ đã phục vụ trên ít nhất một tàu.

π sname(Sailors Reserves)

Kết nối của Sailors và Reserves tạo ra các quan hệ trung gian trong đó các bộ giá trịchứa một bộ giá trị của Sailors 'kết nối với' một bộ giá trị Reserves. Một bộ giá trị củaSailors xuất hiện trong (một vài bộ giá trị của) quan hệ trung gian chỉ khi có ít nhất mộtbộ giá trị Reserves có cùng giá trị sid. Khi đánh giá dựa trên minh hoạ B1, R2 và S3, kếtquả chứa ba bộ giá trị <Dustinini>, <Horatio>, và <Lubber>. Ngay cả khi có hai thuỷthủ có cùng tên <Horatio> đã từng phục vụ trên một tàu, kết quả cũng chỉ chứa duy nhấtmột bộ giá trị <Horatio>, bởi vì kết quả là một quan hệ nên không có bất kỳ sự trùngnhau nào.

Ở thời điểm này, ta đã thấy được sự thường xuyên xuất hiện của phép kết nối tự nhiêntrong các ví dụ của chúng ta. Sự thường xuyên này không chỉ là ngẫu nhiên trên nhữngví dụ truy vấn này, mà kết nối tự nhiên là phép toán được sử dụng rất rộng rãi. Đặc biệt,kết nối tự nhiên được sử dụng thường xuyên khi kết nối hai quan hệ dựa trên trường khoángoại. Trong truy vấn Q4, nối bằng giữa quan hệ Sailors và Reserves dựa trên trườngsid, trong đó sid là khoá ngoại của Reserves tham chiếu tới trường sid của Sailors.

(Q5) Tìm tên của các thuỷ thủ đã phục vụ trên tàu màu 'red' hoặc màu 'green'

ρ(Tempboats, (σcolor='red'Boats) U (σcolor='green'Boats))

πsname(Tempboats Reserves Sailors)

Chúng ta xác định tập tất cả các tàu hoặc có màu 'red', hoặc có màu 'green' (Tempboatschứa những tàu có bid là 102, 103 và 104 trong các minh hoạ quan hệ B1, R2 và S3).Sau đó chúng nối với quan hệ Reserves để xác định sid của những thuỷ thủ đã phục vụtrên một trong những tàu đó; điều này cung cấp cho chúng ta sids 22, 31, 64 và 74 ứngvới những minh hoạ quan hệ nói trên. Cuối cùng, chúng ta nối (một quan hệ trung gianchứa tập các sid này) với Sailors để tìm ra tên của các thuỷ thủ tương ứng với các sidnày. Kết quả nhận được là các tên Dustin, Horatio, và Lubber ứng với các minh hoạquan hệ B1, R2 và S3.

Một định nghĩa tương đương khác như sau:

123/470

ρ(Tempboats, (σcolor= 'red' ∨ color='green'Boats))

πsname(Tempboats Reserves Sailors)

Bây giờ hãy cùng chúng tôi xem xét một truy vấn rất giống truy vấn này:

(Q6) Tìm tên các thuỷ thủ đã phục vụ trên tàu màu 'red' và tàu màu 'green'. Cố gắngđể làm truy vấn này đơn giản bằng việc thay thế hợp bằng giao trong định nghĩa củaTempboats:

ρ (Tempboats2, (σ color='red'Boats) giao (σ color='green'Boats))

π sname(Tempboats2 Reserves Sailors)

Tuy nhiên, giải pháp này là không đúng - nó đã thay vì cố gắng đưa ra những thuỷ thủđã phục vụ trên tàu có cả màu 'red' và 'green'. (Vì bid là khoá của Boats, một tàu chỉ cóthể có một màu; truy vấn này sẽ luôn trả kết quả là một quan hệ rỗng.) Cách thực hiệnđúng là tìm ra những thuỷ thuỷ đã phục vụ trên tàu có màu 'red', sau đó là những thuỷthủ đã phục vụ trên tàu có màu 'green', và sau đó thực hiện phép giao hai tập kết quảnày.

ρ (Tempred, π sid((σ color= 'red' Boats) Reserves))

ρ (Tempgreen, π sid((σ color='green'Boats) Reserves))

π sname((Tempred giao Tempgreen) Sailors)

Hai quan hệ tạm (Temp…) này đưa ra sid của các thuỷ thủ, và xác định tập giao để chỉra những người đã phục vụ trên cả tàu màu 'red' và tàu màu 'green'. Trên minh hoạ B1,R2 và S3, các sid của thuỷ thủ đã phục vụ trên tàu màu 'red' là 22, 31 và 64. Sid của cácthuỷ thủ đã phục vụ trên tàu màu 'green' là 22, 31 và 74. Vì thế, thuỷ thủ có sid là 22và 31 là những người đã phục vụ trên cả tàu màu 'red' và tàu màu 'green'; tên của họ làDustin và Lubber.

Công thức thực hiện truy vấn Q6 có thể được sửa dễ dàng để đưa ra được những thuỷthủ phục vụ trên tàu màu 'red' hoặc tàu màu 'green' (truy vấn Q5); chỉ cần thay thế phépgiao bằng hợp.

ρ (Tempred, π sid((σ color= 'red' Boats) Reserves))

ρ (Tempgreen, π sid((σ color='green'Boats) Reserves))

π sname((Tempred U Tempgreen) Sailors)

124/470

Đối với các công thức trên của Q6 và Q5, việc sid là khoá của Sailors rất quan trọng.Xem xét một cách thử để trả lời truy vấn Q6 sau:

ρ (Tempred, π sname((σ color= 'red' Boats) Reserves Sailors))

ρ (Tempgreen, π sname((σ color='green'Boats) Reserves Sailors))

Tempred U Tempgreen

Công thức trên là không đúng vì một lý do tinh vi hơn. Hai thuỷ thủ khác nhau có cùngtên, trong ví dụ minh hoạ quan hệ là Horatio, có thể phục vụ trên tàu màu 'red' và tàumàu 'green'. Trong trường hợp này, tên Horatio sẽ (không đúng) có trong kết quả mặcdù không có một ai có tên Horatio đã phục vụ trên tàu màu 'red' và 'green'. Nguyên nhâncủa lỗi này là sname được sử dụng để xác định thuỷ thủ (trong khu thực hiện phép giao)trong phiên bản này của truy vấn, nhưng sname không phải là khoá.

(Q7) Tìm tên các thuỷ thủ đã phục vụ trên ít nhất hai tàu.

ρ(Reservations, π sid,sname,bid(Sailors Reserves))

ρ(Reservationpairs(1 → sid1, 2 → sname1, 3 → bid1, 4 → sid2, 5 → sname2, 6 →bid2), Reservations × Reservations)

π sname1 σ (sid1=sid2)^(bid1 ≠bid2)Reservationpairs

Đầu tiên, chúng ta đưa ra những bộ giá trị theo dạng <sid, sname,bid>, nơi các thuỷ thủ(sid) đã phục vụ cho tàu (bid); tập các bộ giá trị này nằm trong một quan hệ tạm thời làReservations. Tiếp theo, chúng ta tìm tất cả các cặp của các bộ giá trị trong Reservationsbiểu diễn một thuỷ thủ phục vụ trên hai tàu khác nhau. Đây là ý tưởng chính: Để chỉ ramột thuỷ thủ đã phục vụ trên hai tàu, chúng ta phải tìm hai bộ giá trị Reservations màcùng một thuỷ thủ nhưng ứng với hai tàu phân biệt. Trên minh hoạ B1, R2 và S3, nhữngthuỷ thủ có sid 22, 31 và 64 thoả mãn. Cuối cùng, chúng ta thực hiện phép chiếu lấy ratên các thuỷ thủ này, đó là Dustin, Horatio, và Lubber.

Ghi nhớ rằng chúng ta sử dụng sid trong Reservations vì đó là trường khoá của Sailors,và chúng ta cần nó để kiểm tra hai bộ giá trị trong Reservations có liên quan đến cùngmột thuỷ thủ không. Nhớ lại trong ví dụ trước, chúng ta không thể sử dụng sname thayvì sid trong trường hợp này.

(Q8) Tìm ra những sid của Sailors có tuổi (age) lớn hơn 20 và không phục vụ trên tàumàu 'red'.

π sid(σ age>20Sailors) − π sid((σ color='red'Boats) Reserves Sailors)

125/470

Truy vấn này minh hoạ việc sử dụng toán tử trừ. Một lần nữa, chúng ta sử dụng mộtthực tế rằng sid là khoá của quan hệ Sailors. Đầu tiên, chúng ta tìm ra những thuỷ thủcó age trên 20 (trên minh hoạ B1, R2 và S3, sid thoả mãn là 22, 29, 31, 32, 58, 64, 74,85, và 95), sau đó loại bỏ những người đã phục vụ trên tàu màu 'red' (sid 22, 31 và 64),kết quả là những sid còn lại (29, 32, 58, 74, và 95). Nếu chúng ta muốn đưa ra tên cácthuỷ thủ này, đầu tiên chúng ta phải tìm được các sid (như trên), sau đó nối với Sailorsvà thực hiện phép chiếu để lấy được sname.

(Q9) Tìm ra tên các thuỷ thủ đã phục vụ trên tất cả các tàu. Việc sử dụng từ 'tất cả' (hoặc'mọi') là dấu hiệu tốt để lựa chọn phép chia:

ρ(Tempsids, (π sid,bidReserves)/(π bidBoats))

π sname(Tempsids Sailors)

Quan hệ trung gian Tempsids được định nghĩa sử dụng phép chia, và đưa ra tập các sidcủa thuỷ thủ phục vụ trên tất cả các tàu (trên minh hoạ B1, R2 và S3, chỉ có sid 22 thoảmãn). Ghi nhớ chúng ta định nghĩa hai quan hệ như thế nào để phép chia (/) có thể đượcáp dụng- quan hệ đầu tiên có lược đồ (sid, bid) và quan hệ thứ hai có lược đồ (bid). Phépchia sau đó trả lại tất cả sid mà có một bộ giá trị <sid, bid> trong quan hệ đầu tiên ứngvới mỗi bid trong quan hệ thứ hai. Kết nối Tempsids với Sailors là cần thiết để lấy đượctên của các sid tương ứng, với sid là 22 thì tên là Dustin.

(Q10) Tìm tên của các thuỷ thủ phục vụ trên tất cả các tàu có tên là Interlake.

ρ(Tempsids, (π sid,bidReserves)/(πbid(σ bname='Interlake'Boats)))

π sname(Tempsids Sailors)

Chỉ khác với truy vấn trước là bây giờ chúng ta áp dụng một phép chọn trên Boats, đểđảm bảo rằng chúng ta đưa ra chỉ những bid có tên là Interlake trong định nghĩa đối sốthứ hai của toán tử chia. Trên minh hoạ B1, R2 và S3, Tempsids có hai sid là 22 và 64,và tên thuỷ thủ tương ứng là Dustin và Horatio.

Phép toán logic quan hệ

Phép toán logic quan hệ là một phần khác với đại số quan hệ. Đối lập với đại số, lànhững thủ tục, phép toán logic là phi thủ tục, cho phép chúng ta biểu diễn tập kết quảkhông cần tường minh về cách chúng được tính toán thế nào. Phép toán logic quan hệcó ảnh hưởng lớn đến thiết kế ngôn ngữ truy vấn thương mại như SQL và đặc biệt làTruy vấn-bằng-ví dụ (Query-by-Example (QBE)).

126/470

Một dạng của phép toán logic mà chúng ta sẽ biểu diễn chi tiết được gọi là các Phép toánlogic quan hệ trên bộ (tuple relational calculus - TRC). Các biến trong TRC nắm giữcác bộ giá trị như là các biến. Một dạng khác, gọi là Phép toán logic trên miền (domainrelational calculus - DRC), các biến nhận giá trị là các miền giá trị của các trường trên.TRC có nhiều ảnh hưởng tới SQL, trong khi DRC có ảnh hưởng mạnh mẽ tới QBE.Chúng ta sẽ bàn tới DRC trong phần 3.2.

• Phép toán logic trên bộ

Một biến bộ là một biến nắm giữ các bộ giá trị của một lược đồ quan hệ cụ thể. Đó là,tất cả giá trị gán cho một biến bộ có cùng số lượng và kiểu của trường. Một truy vấnTRC có dạng {T | p(T)}, trong đó T là một biến bộ và p(T) là một công thức biểu diễnT; chúng ta sẽ định nghĩa các công thức và các truy vấn một cách nghiêm ngặt. Kết quảcủa truy vấn này là một tập gồm tất cả các bộ giá trị t mà với T=t thì p(T) đúng. Chúngta xem xét ví dụ truy vấn sau:

(Q11) Tìm tất cả các thuỷ thủ có Rating>7

{S | S ∈ Sailors ∧ S.rating >7}

Khi truy vấn được thực hiện trên minh hoạ của quan hệ Sailors, biến bộ S được áp dụnglần lượt với mỗi bộ giá trị để kiểm tra điều kiện S.rating>7. Kết quả của truy vấn chứanhững bộ giá trị của S thoả mãn điều kiện này. Trên minh hoạ S3 của Sailors, kết quảchứa những bộ giá trị mà sid là 31, 32, 58, 71 và 74.

Cú pháp của truy vấn TRC

Bây giờ chúng ta định nghĩa những khái niệm này một cách chính thức, bắt đầu bằngkhái niệm của công thức. Giả sử Rel là tên một quan hệ, R và S là những biến bộ, a làmột thuộc tính của R, và b là một thuộc tính của S. Giả sử op biểu diễn một toán tử trongtập {<, >. =, ≤, ≥, ≠}. Một công thức nguyên thuỷ là một trong những công thức sau:

• R ∈ Rel• R.a op S.b• R.a op Hằng_số, hoặc Hằng_số op R.a

Một công thức được định nghĩa đệ quy như một trong những dạng sau, trong đó p và qlà một công thức, và p(R) là một công thức trong đó có R xuất hiện:

• bất kỳ công thức nguyên tử nào• p, p ∧q, p ∨q, hoặc p ⇒q• ∃ R(p(R)), trong đó R một tuple variable• ∀ R(p(R)), trong đó R một tuple variable

127/470

Trong hai mệnh đề cuối cùng ở trên, lượng tử ∃ và ∀ được gọi là 'kết buộc' với biến R.Biến được gọi là 'tự do' nếu trong công thức hoặc công thức con (công thức nằm trongmột công thức lớn) không chứa một sự kiện nào chứa các lượng tử 'kết buộc' tới biếnđó.

Chúng ta quan sát thấy rằng, tất cả các biến trong công thức TRC đều xuất hiện trongmột công thức con nào đó- những công thức nguyên tử, và tất cả các lược đồ quan hệ chỉra một miền ứng với mỗi trường; quan sát này đảm bảo rằng mỗi biến trong công thứcTRC có kiểu dữ liệu được định nghĩa tốt theo tư duy của ngôn ngữ lập trình. Quả thật,một công thức nguyên tử R ∈ Rel đem đến R một kiểu (type) của các bộ giá trị trongRel, và những so sánh như R.a op S.b và R.a op Hằng_số đem lại những giới hạn trêntrường R.a. Nếu một biến R không xuất hiện trong một công thức nguyên tử theo dạngR ∈ Rel (tức là, nó xuất hiện chỉ trong các công thức nguyên tử là các so sánh), chúng tasẽ sinh ra một thoả thuận ngầm rằng kiểu của R là một bộ giá trị của những trường baogồm tất cả (và chỉ) những trường của R xuất hiện trong công thức.

Chúng ta sẽ không định nghĩa các kiểu của biến một cách chính thức, nhưng kiểu củamột biến nên rõ ràng trong hầu hết các trường hợp, và điểm quan trọng phải ghi nhớ lànhững so sánh thực hiện trên những kiểu dữ liệu khác nhau luôn bị lỗi. (Trong nhữngbàn luận của phép toán logic quan hệ, giả định đơn giản thường được làm là có mộtmiền duy nhất của các hằng số và miền liên quan đến mỗi trường của mỗi quan hệ.)

Truy vấn TRC được định nghĩa theo dạng {T | p(T)}, trong đó T là biến 'tự do' trongcông thức p.

Ngữ nghĩa của các truy vấn TRC

Ý nghĩa của TRC là gì? Hay chính xác hơn, cái gì là tập các bộ giá trị kết quả của mộttruy vấn TRC? Câu trả lời tới truy vấn TRC {T | p(T)}, như chúng ta đã nói tới phía trên,là tập của tất cả các bộ giá trị t trong công thức p(T) mà với T=t thì p(T) đúng.

Một truy vấn được đánh giá trên một minh hoạ được cơ sở dữ liệu cung cấp. Mỗi biến'tự do' trong công thức F được gán một giá trị của bộ, F đúng nếu thỏa mãn một trongnhững điều kiện sau:

• F là một công thức nguyên tử R ∈ Rel, và R được gán bằng một bộ giá trị trongminh họa của quan hệ Rel.

• F là một so sánh R.a op S.b, R.a op Hằng_số, hoặc Hằng_số op R.a, và nhữngbộ giá trị gán cho R và S có giá trị trường R.a và R.b làm cho công thức đúng.

• F có dạng p, trong đó p không đúng; hoặc có dạng p ∧ q, trong đó cả p và qđúng; hoặc có dạng p ∨ q trong đó p hoặc q đúng; hoặc có dạng p ⇒ q trong đóq đúng hoặc p đúng.

128/470

• F có dạng ∃R(p(R)), trong đó có một hoặc một số phép gán của các bộ giá trịcho các biến trong p(R), kể cả biến R, làm cho công thức p(R) đúng.

• F có dạng ∀R(p(R)), trong đó có một số phép gán của các bộ giá trị cho cácbiến trong p(R) làm cho công thức p(R) đúng với bất kỳ bộ giá trị nào được gáncho R.

Những ví dụ của truy vấn TRC

Bây giờ chúng ta minh hoạ phép toán logic quan hệ thông qua một số ví dụ, sử dụngminh hoạ B1 của Boats, R2 của Reserves và S3 của Sailors chỉ ra trong Hình 15, 16 và17. Chúng ta sử dụng các dấu ngoặc khi cần thiết để làm công thức của chúng ta rõ rànghơn. Thường thì một công thức p(R) bao gồm một điều kiện R ∈ Rel. Chúng ta sẽ sửdụng ký hiệu ∃ R ∈ Rel(p(R)) cho ∃R(R ∈ Rel ∧ p(R)). Tương tự, chúng ta sử dụngghi chú ∀R ∈ Rel(p(R)) cho ∀R(R ∈ Rel ⇒ p(R)).

(Q12) Tìm tên và tuổi của các thuỷ thủ có Rating>7.

{P | ∃ S ∈ Sailors(S.rating > 7 ∧ P.name = S.sname ∧ P.age = S.age)}

Truy vấn này minh hoạ: P được xem là một biến bộ với chính xác hai trường là namevà age. Kết quả của truy vấn này là một quan hệ gồm hai trường, name và age. Côngthức nguyên tử P.name=S.name và P.age=S.age cung cấp giá trị cho các trường của bộgiá trị kết quả P. Trên minh hoạ B1, R2 và S3, kết quả là tập bộ giá trị <Lubber, 55.5>,<Andy, 25.5>, <Rusty, 35.0>, <Zorba, 16.0>, và <Horatio, 35.0>.

(Q13) Tìm tên thủy thủ (name), mã thuyền (bid), và ngày phục vụ (date) của mỗi sựphục vụ.

{ P | ∃ R ∈ Reserves ∃ S ∈ Sailors

(R.sid = S.sid ∧ P.bid = R.bid ∧ P.day = R.day ∧ P.sname = S.sname)}

Với mỗi bộ giá trị của Reserves, chúng ta tìm một bộ giá trị trong Sailors có cùng sid.Với mỗi cặp của các bộ giá trị như thế, chúng ta xây dựng một bộ giá trị kết quả P vớicác trường sname, bid và day bằng cách sao chép các trường tương ứng từ hai bộ giá trịnày. Truy vấn này minh hoạ cách chúng ta có thể kết hợp những giá trị từ những quanhệ khác nhau trong mỗi bộ giá trị kết quả. Kết quả của truy vấn này thực hiện trên minhhoạ quan hệ B1, R2 và S3 chỉ ra trong Hình 20.

129/470

Kết quả của truy vấn Q13

(Q1) Tìm tên những thuỷ thủ đã phục vụ trên tàu 103

{P | ∃ S ∈ Sailors ∃R ∈ Reserves(R.sid=S.sid ∧ R.bid=103 ∧ P.sname=S.sname)}

Truy vấn này có thể được đọc như sau: Tìm ra tất cả các bộ giá trị Sailors, cái mà có tồntại một bộ trong Reserves, có cùng giá trị trong trường sid, và với bid=103. Đó là, vớimỗi bộ giá trị sailor, chúng ta tìm một bộ giá trị trong Reserves chỉ ra rằng sailor này đãphục vụ trên tàu 103. Bộ giá trị kết quả P chỉ chứa một trường là sname.

(Q2) Tìm tên những thuỷ thủ đã phục vụ trên tàu có màu 'red'

{P | ∃ S ∈ Sailors ∃R ∈ Reserves(R.sid = S.sid ∧ P.sname = S.sname

∧ ∃ B ∈ Boats(B.bid = R.bid ∧ B.color = 'red'))}

Truy vấn này có thể được đọc như sau: Tìm tất cả các bộ giá trị Sailors, cái mà có tồntại các bộ giá trị R trong Reserves và B trong Boats để S.sid=R.sid, R.bid=B.bid vàB.color='red'. Cách viết khác phù hợp với cách đọc trên là:

{ P | ∃S ∈ Sailors ∃R ∈ Reserves ∃B ∈ Boats

(R.sid = S.sid ∧ B.bid = R.bid ∧ B.color ='red' ∧ P.sname = S.sname)}

(Q7) Tìm ra tên các thuỷ thủ đã phục vụ trên ít nhất hai tàu.

{P | ∃S ∈ Sailors ∃R1 ∈ Reserves ∃R2 ∈ Reserves

(S.sid = R1.sid ∧ R1.sid = R2.sid ∧ R1.bid ≠ R2.bid ∧ P.sname = S.sname)}

130/470

So sánh truy vấn này trong phiên bản sử dụng đại số quan hệ và thấy chúng đơn giảnhơn nhiều khi sử dụng các phép toán logic. Một phần, sự khác nhau này là do sự cồngkềnh trong việc đổi tên các trường trong phiên bản đại số quan hệ, nhưng phiên bảnphép toán logic thì thực sự đơn giản hơn.

(Q9) Tìm tên các cầu thủ đã phục vụ trên tất cả các chuyến tàu.

{P | ∃ S ∈ Sailors ∀B ∈ Boats

(∃R ∈ Reserves(S.sid=R.sid ∧ R.bid=B.bid ∧ P.sname=S.sname))}

Truy vấn này được biểu diễn sử dụng phép chia trong đại số quan hệ. Hãy xem nó đượcbiểu diễn dễ dàng như thế nào trong phép toán logic. Biểu diễn truy vấn theo phép toánlogic trực tiếp phản chiếu cách chúng ta biểu diễn một truy vấn bằng tiếng Anh: "Tìmnhững thủy thủ S để với tất cả các tàu B có một bộ giá trị Reserves chỉ ra rằng thủy thủS đã phục vụ trên tàu B."

(Q14) Tìm tất cả các thủy thủ đã phục vụ trên tất cả tàu có màu 'red'.

{S | S ∈ Sailors ∧ ∀B ∈ Boats

(B.color ='red') ⇒ (∃R ∈ Reserves(S.sid = R.sid ∧ R.bid = B.bid)))}

Truy vấn này có thể được đọc như sau: Với mỗi ứng viên (thủy thủ), nếu một tàu cómàu 'red', thủy thủ phải phục vụ trên tàu này. Đó là, với mỗi ứng viên thủy thủ, một tàumàu 'red' phải chỉ ra thủy thủ này phục vụ trên nó. Quan sát thấy rằng, vì chúng ta có thểtrả về kết quả là một thực thể thủy thủ thay vì chỉ trả về tên của họ, nên chúng ta tránhđưa vào biến tự do mới (ví dụ, biến P trong ví dụ trước) để nắm giữ giá trị kết quả. Trênminh họa B1, R2 và S3, kết quả chứa các bộ giá trị Sailors có sid là 22 và 31.

Chúng ta có thể viết truy vấn này không cần sử dụng phép kéo theo, bằng cách thay p ⇒q bằng công thức logic tương đương ?p ∨ q:

{S | S ∈ Sailors ∧ ∀B ∈ Boats

(B.color ≠ 'red' ∨ (∃R ∈ Reserves(S.sid = R.sid ∧ R.bid = B.bid)))}

Truy vấn này nên được đọc như sau: Tìm những thủy thủ S ứng với mọi tàu B, hoặc tàukhông có màu 'red' hoặc một bộ giá trị Reserves nào đó chỉ ra rằng thủy thủ S đã phụcvụ tàu B."

• Phép toán logic trên miền

131/470

Biến miền là biến nhận giá trị là miền của một số thuộc tính (ví dụ, biến có thể đượcgán giá trị Integer nếu nó xuất hiện trong một thuộc tính mà miền của nó là tập các sốInteger). Truy vấn DRC có dạng {<x1, x2, …, xn> | p(<x1, x2, …, xn>)}, trong đó mỗixi hoặc là biến miền hoặc là hằng số và p(<x1, x2, …, xn>) là một công thức DRC, nơimà chỉ có những công thức nguyên tố. Kết quả của truy vấn này là tập các bộ giá trị <x1,x2, …, xn> làm cho P đúng.

Công thức DRC được định nghĩa theo cách tương tự như cách định nghĩa của công thứcTRC. Sự khác nhau chính là các biến trong trường hợp này là các biến miền. Giả sử oplà các phép toán trên tập hợp {<, >, =, ≤, ≥ ≠} và giả sử X, Y là các biến miền. Một côngthức nguyên tử trong DRC có một trong những dạng sau:

• <x1, x2, …, xn> ∈ Rel, trong đó Rel là một quan hệ có n thuộc tính, mỗi xi (1 ≤i ≤ n) là một biến hoặc một hằng số.

• X op Y

Một công thức được định nghĩa đệ quy theo một trong các dạng sau, trong đó p và q làcông thức, và p(X) là một công thức có biến X xuất hiện trong đó:

• Bất kỳ công thức nguyên tử nào• p, p ∧q, p ∨q, hoặc p ⇒ q• ∃X(p(X)), trong đó X là một biến miền• ∃X(p(X)), trong đó X là một biến miền

Người đọc xem lại để so sánh định nghĩa này với định nghĩa công thức TRC và nhậnthấy sự liên quan giữa hai định nghĩa này. Chúng ta sẽ định nghĩa ngữ nghĩa của côngthức DRC chính thức, đây là một bài tập cho người đọc.

Ví dụ của truy vấn DRC

Chúng ta sẽ minh họa DRC thông qua một số ví dụ. Người đọc xem lại để so sánh vớiphiên bản định nghĩa theo TRC.

(Q11) Tìm tất cả thủy thủ có rating>7.

{<I, N, T, A> | <I, N, T, A> ∈ Sailors ∧ T > 7}

Điều kiện <I, N, T, A> ∈ Sailors đảm bảo rằng các biến miền I, N , T và A được giớihạn là các trường của cùng một bộ. So sánh với truy vấn TRC, chúng ta có thể dùng T>7thay vì S.rating>7, nhưng chúng ta phải chỉ ra bộ <I, N, T, A> trong kết quả, không chỉlà S.

(Q1) Tìm ra tên các thủy thủ đã phục vụ trên tàu 103.

132/470

{<N> | ∃I, T, A(<I, N, T, A> ∈ Sailors

∧ ∃Ir, Br, D(<Ir, Br, D> ∈ Reserves ∧ Ir = I ∧ Br = 103))}

Chú ý rằng chỉ có trường sname được giữ lại trong kết quả và chỉ có N là biến tự do.Chúng ta sử dụng biểu diễn ∃Ir, Br, D (…) như cách viết nhanh của ∃Ir(∃Br(∃D(…))).Rất thường xuyên, tất cả các biến định lượng xuất hiện trong một quan hệ đơn, như trongví dụ này. Và thậm chí co lại là ∃Ir, Br, D ∈ Reserves. Chúng ta sẽ sử dụng cách này từnay về sau, và truy vấn trên được viết như sau:

{<N> | ∃I, T, A(<I, N, T, A> ∈ Sailors

∧ ∃<Ir, Br, D> ∈ Reserves(Ir = I ∧ Br = 103))}

Truy vấn này cũng có thể được viết như sau, lưu ý sự lặp lại của biến I và cách sử dụnghằng số 103:

{<N> | ∃I, T, A(<I, N, T, A> ∈ Sailors ∧ ∃D(<I, 103, D> ∈ Reserves))}

(Q2) Tìm tên các thủy thủ đã phục vụ trên tàu có màu 'red'

{<N> | ∃I, T, A(<I, N, T, A> ∈ Sailors

∧ ∃<I, Br, D> ∈ Reserves ∧ ∃<Br, BN, 'red'> ∈ Boats)}

(Q7) Tìm tên các thủy thủ đã phục vụ trên ít nhất hai tàu.

{<N> | ∃I, T, A(<I, N, T, A> ∈ Sailors ∧

∃Br1, Br2, D1,D2(<I,Br1,D1>∈ Reserves ∧ <I,Br2,D2> ∈ Reserves ∧ Br1≠Br2))}

Ghi nhớ biến I được sử dụng lặp lại để đảm bảo rằng cùng một thủy thủ đã phục vụ trênhai tàu.

(Q9) Tìm tên các thủy thủ đã phục vụ trên tất cả các tàu.

{<N> | ∃I, T, A(<I, N, T, A> ∈ Sailors ∧

∀B, BN, C(-,(<B, BN, C> ∈ Boats) ∨

(∃<Ir, Br, D> ∈ Reserves(I = Ir ∧ Br = B))))}

Truy vấn này có thể được đọc như sau: Tìm tất cả giá trị của N mà có một vài bộ <I, N,T, A> trong Sailors thỏa mãn điều kiện sau: với mỗi <B, BN, C>, hoặc ở đây không có

133/470

một bộ nào trong Boats hoặc không có một số bộ <B, BN, C> trong Reserves để chứngminh rằng Sailors I đã phục vụ tàu B." Lượng tử ∀ cho phép các biến miền B, BN, và Ccó thể nhận tất cả các giá trị trong các miền thuộc tính tương ứng của chúng, và đoạn '-,(<B, BN, C> ∈ Boats) ∨' là cần thiết để hạn chế chú ý đến giá trị xuất hiện trong bộ giátrị của Boats. Đoạn này thường dùng trong công thức DRC, và có thể được thay bằng∀<B, BN, C> ∈ Boats. Điều này tương đương với cách viết đối với lượng tử ∃ đã giớithiệu. Với cách này, truy vấn được viết như sau:

{<N> | ∃I, T, A(<I, N, T, A> ∈ Sailors ∧ ∀<B, BN, C> ∈ Boats

(∃<Ir, Br, D> ∈ Reserves(I = Ir ∧ Br = B)))}

(Q14) Tìm những thủy thủ đã phục vụ trên tất cả tàu có màu 'red'.

{<I, N, T, A> | <I, N, T, A> ∈ Sailors ∧ ∀<B, BN, C> ∈ Boats

(C =red) ⇒ ∃<Ir, Br, D> ∈ Reserves(I = Ir ∧ Br = B))}

Ở đây, chúng ta tìm ra tất cả các thủy thủ mà với tất cả tàu màu 'red' có một bộ trongReserves chỉ ra thủy thủ này đã làm việc trên đó.

Khả năng của đại số và các phép toán logic trên quan hệ

Chúng tôi đã trình bày hai loại của ngôn ngữ truy vấn của mô hình quan hệ. Khả năngcủa chúng như thế nào? Có phải tất cả các truy vấn biểu diễn trong đại số quan hệ có thểđược biểu diễn trong phép toán logic quan hệ? Câu trả lời là có. Trước khi chúng ta trảlời câu hỏi này, chúng ta xem xét một vấn đề chính cùng với phép toán logic.

Xem xét truy vấn {S |(S ∈ Sailors)}. Cú pháp của truy vấn này là đúng. Tuy nhiên, nóyêu cầu tất cả các bộ giá trị S mà S không phải là Sailors. Tập các bộ giá trị S như vậy làvô hạn. Ví dụ này là một minh hoạ của truy vấn không an toàn. Chúng ta cần phải hạnchế những phép toán logic quan hệ để không cho phép những truy vấn không an toàn.

Bây giờ chúng ta phác hoạ như thế nào các truy vấn phép toán logic được hạn chế để trởnên an toàn. Xem xét một tập I các minh hoạ quan hệ, với một minh hoạ trên một quanhệ xuất hiện trong truy vấn Q. Giả sử Dom(Q, I) là tập của tất cả các hằng số xuất hiệntrong minh hoạ quan hệ I hoặc trong công thức của truy vấn Q. Vì chúng ta chỉ cho phépnhững minh hoạ I hữu hạn, Dom(Q, I) cũng là hữu hạn.

Với mỗi công thức logic quan hệ Q được xem là an toàn, chúng ta muốn đảm bảo rằngvới bất kỳ I nào được cung cấp, tập kết quả của truy vấn Q chứa chỉ những giá trị thuộcDom(Q,I). Trong khi hạn chế này được yêu cầu, nó vẫn là chưa đủ. Chúng ta khôngchỉ muốn tập kết quả được đưa ra dựa trên các hằng số trong Dom(Q,I)! Hy vọng này

134/470

dẫn tới việc sử dụng các lượng tử phổ dụng ∃ và ∀: Với một công thức TRC có dạng∃R(p(R)), chúng ta muốn tìm tất cả các giá trị của biến R làm cho công thức đúng bằngviệc chỉ kiểm tra những bộ giá trị chứa các hằng số trong Dom(Q,I). Tương tự, với mộtcông thức TRC có dạng ∀R(p(R)), chúng ta muốn tìm một giá trị nào đó của biến Rlàm cho công thức sai bằng cách chỉ kiểm tra những bộ giá trị chứa các hằng số trongDom(Q, I).

Vì thế, chúng ta định nghĩa công thức Q là công thức TRC an toàn như sau:

1. Với bất kỳ giá trị I nào được cung cấp, tập kết quả của truy vấn Q chỉ chứanhững giá trị trong Dom(Q, I).

2. Với mỗi công thức con có dạng ∃R(p(R)) trong Q, nếu một bộ r (gán tới biếnR) làm cho công thức đúng, thì r chứa chỉ những hằng số trong Dom(Q, I).

3. Với mỗi công thức con có dạng ∀R(p(R)) trong Q, nếu một bộ r (gán tới biếnR) chứa hằng số nào đó không ở trong Dom(Q, I), thì r phải làm cho công thứcđúng.

Ghi nhớ rằng định nghĩa này không 'có tính xây dựng', nó không nói cho chúng ta cáchlàm thế nào để kiểm tra một truy vấn là an toàn.

Truy vấn Q= ?S ??(S ∈ Sailors)? là không an toàn theo định nghĩa này. Dom(Q,I) làtập tất cả các giá trị xuất hiện trong (một minh hoạ I của) Sailors. Xem xét minh hoạ S1trong Hình 4.1. Kết quả của truy vấn này rõ ràng bao gồm những giá trị không xuất hiệntrong Dom(Q, S1).

Quay trở lại câu hỏi trên, chúng ta có thể chỉ ra rằng tất cả truy vấn có thể được biểu diễnsử dụng phép toán logic an toàn, truy vấn cũng có thể được biểu diễn trong đại số quanhệ. Sức mạnh của đại số quan hệ thường được sử dụng như thước đo sức mạnh của ngônngữ truy vấn cơ sở dữ liệu quan hệ. Nếu một ngôn ngữ truy vấn có thể biểu diễn đượctất cả các truy vấn trong đại số quan hệ, nó được gọi là relationally complete. Ngônngữ truy vấn thực hành được hy vọng là relationally complete; thêm nữa, ngôn ngữ truyvấn thương mại điển hình hỗ trợ các đặc trưng cho phép chúng ta biểu diễn cả các truyvấn mà không biểu diễn được trong đại số quan hệ.

Câu hỏi tổng kết

Trả lời các câu hỏi tổng kết sau, tham khảo tới nội dung của phần kèm theo.

• Cái gì là đầu vào của một truy vấn quan hệ? Cái gì là kết quả của một truy vấn?(Phần 4.1)

• Các hệ cơ sở dữ liệu sử dụng một vài dạng của đại số quan hệ để trình bàynhững kế hoạch đánh giá truy vấn. Giải thích vì sao đại số là thích hợp cho mụcđích này? (Phần 2)

135/470

• Trình bày phép chọn. Điều kiện của các bảng đầu vào và đầu ra của phép toánnày? (Đó là, nếu đầu vào có k bộ giá trị, thì đầu ra là gì?). Trình bày phépchiếu. Điều kiện của các bảng đầu vào và đầu ra của phép toán này? (Phần 2.1)

• Trình bày các phép toán tập hợp của đại số quan hệ, bao gồm phép hợp (?),phép giao (?), phép trừ (?), và phép nhân (×). Với mỗi phép toán, điều kiện củacác bảng đầu vào và đầu ra của phép toán này là gì? (Phần 2.2)

• Giải thích phép đổi tên được sử dụng như thế nào? Nó có bắt buộc không? Nếuphép toán này không được phép, có truy vấn nào không thể được biểu diễnbằng đại số không? (Phần 2.3)

• Định nghĩa tất cả các dạng của phép nối. Vì sao phép nối được đặc biệt quantâm. Có phải chúng ta không thể biểu diễn tất cả các phép nối dựa trên phépnhân chéo, phép chọn và phép chiếu? (Phần 2.4)

• Định nghĩa phép chia dựa trên các phép toán đại số quan hệ cơ bản. Trình bàymột truy vấn đặc trưng cho phép chia. Không như phép nối, phép chia khôngđược biểu diễn riêng trong hệ cơ sở dữ liệu. Giải thích vì sao? (Phần 2.5)

• Phép toán logic quan hệ được gọi là ngôn ngữ phi thủ tục, đối lập với đại sốquan hệ là ngôn ngữ thủ tục. Giải thích sự khác nhau. (Phần 3)

• Một truy vấn dựa trên phép toán logic quan hệ 'biểu diễn' các bộ kết quả nhưthế nào? Trình bày về cách sử dụng của các lượng tử tồn tại và phổ dụng, biếnkết buộc và biến tự do. (Phần 3.1)

• Sự khác nhau giữa TRC và DRC là gì? (Phần 3.2)• Truy vấn dựa trên phép toán logic không an toàn là gì? Vì sao phải hạn chế

những truy vấn này? (Phần 4)• Đại số quan hệ và phép toán logic quan hệ được cho là có khả năng tương

đương. Giải thích nhận xét này và nó liên quan tới 'relationally complete' nhưthế nào.(Phần 4)

Bài tập

Giải thích từng trường hợp phép toán đại số quan hệ được sử dụng.

Trả lời: Tất cả các phép toán trong đại số quan hệ chấp nhận các minh họa quan hệ làcác đối số và kết quả của nó luôn là một minh họa quan hệ. Vì thế đối số của một phéptóan có thể là kết quả của một phép toán khác. Điều này quan trọng bởi vì nó làm choviệc viết các truy vấn phức tạp trở nên dễ dàng hơn bằng cách viết nó dưới dạng cácphép toán đại số quan hệ.

Cho hai quan hệ R1 và R2, trong đó R1 chứa N1 bộ giá trị, R2 chứa N2 bộ giá trị, vàN2>N1>0, đưa ra kích thước (các bộ giá trị) nhỏ nhất và lớn nhất có thể của quan hệ kếtquả trong từng công thức sau:

(1) R1 ? R2, (2) R1 ? R2, (3) R1? R2, (4) R1 × R2, (5) σa=5(R1), (6) πa(R1), và

136/470

(7) R1/R2

Trả lời: Dành cho độc giả.

Xem xét lược đồ sau:

Suppliers(sid: integer, sname: string, address: string)Parts(pid: integer, pname: string, color: string)Catalog(sid: integer, pid: integer, cost: real)

Những trường khoá được gạch chân, và miền của mỗi trường được liệt kê sau tên trường.Vì thế sid là khoá của Suppliers, pid là khoá của Parts, sid và pid cùng làm khoá củaCatalog. Quan hệ Catalog liệt kê giá thay đổi của các sản phẩm (parts) của các nhà cungcấp (Suppliers). Viết các truy vấn sau trong đại số quan hệ, trong TRC và DRC:

1. Tìm tên của các nhà cung cấp cung cấp một số sản phẩm màu đỏ.2. Tìm mã của các nhà cung cấp cung cấp một số sản phẩm màu đỏ hoặc màu

xanh.3. Tìm mã của các nhà cung cấp cung cấp một số sản phẩm màu đỏ hoặc ở địa chỉ

221 Packer Ave.4. Tìm mã của các nhà cung cấp cung cấp một số sản phẩm màu đỏ và một số sản

phẩm màu xanh.5. Tìm mã của các nhà cung cấp cung cấp tất cả các sản phẩm.6. Tìm mã của các nhà cung cấp cung cấp tất cả các sản phẩm màu đỏ.7. Tìm mã của các nhà cung cấp đã cung cấp tất cả các sản phẩm màu đỏ hoặc sản

phẩm màu xanh.8. Tìm mã của các nhà cung cấp đã cung cấp tất cả các sản phẩm màu đỏ hoặc

cung cấp tất cả các sản phẩm màu xanh.9. Tìm cặp mã của nhà cung cấp cùng cung cấp một sản phẩm mà giá thành của

nhà cấp thứ nhất lớn hơn giá thành của nhà cung cấp thứ hai.10. Tìm mã của các sản phẩm có ít nhất hai nhà cung cấp.11. Tìm mã của sản phẩm đắt nhất được nhà cung cấp có tên 'Yosemite Sham' cung

cấp.12. Tìm mã các sản phẩm được tất cả các nhà cung cấp đưa ra giá ít hơn 200$.

(Nếu có một nhà cung cấp hoặc là không cung cấp hoặc là phải trả nhiều hơn200$ cho sản phẩm đó thì sản phẩm đó sẽ không được đưa ra).

Trả lời: Trong những câu trả lời sau, RA là viết tắt của Relational Algebra, TRC viếttắt của Tuple Relational Calculus và DRC là của Domain Relational Calculus.

137/470

138/470

139/470

140/470

141/470

142/470

143/470

144/470

145/470

Xem xét lược đồ quan hệ Supplier-Parts-Catalog trong câu hỏi trước, truy vấn theo sauđề cập đến yêu cầu gì?

Trả lời: Dành cho độc giả.

Xem xét các quan hệ sau mô tả thông tin các chuyến bay:

Flights(flno: integer, from: string, to: string, distance:integer, departs: time, arrives: time) Aircraft(aid:integer,aname: string, cruisingrange: integer)Certified(eid: integer, aid: integer) Employees(eid:integer, ename: string, salary: integer)

Các quan hệ Employees mô tả các phi công và các loại nhân viên khác; tất cả các phicông được chứng nhận trên một số loại máy bay(aircraft) (nếu không có, cô/anh ấykhông được coi là phi công), và chỉ những phi công được chứng nhận mới được phépbay.

146/470

Viết những truy vấn sau trong đại số quan hệ, TRC và DRC. Lưu ý rằng có một số truyvấn không thể được biểu diễn trong đại số quan hệ (vì thế, cũng không biểu diễn đượcbằng TRC và DRC)! Với những truy vấn này, giải thích vì sao chúng không thể đượcbiểu diễn. (Nhìn vào những bài tập ở cuối chương 5 để có thêm những truy vấn trên lượcđồ này.)

1. Tìm mã của những phi công được chứng nhận trên loại máy Boeing.2. Tìm tên của những phi công được chứng nhận trên loại máy Boeing.3. Tìm mã của tất cả loại máy bay có thể được sử dụng trên những chuyến bay

'non-stop' từ Bonn tới Madras.4. Xác định tất cả các chuyến bay có thể được điều khiển bằng tất cả các phi công

có lương hơn $100,000.5. Tìm tên những phi công có thể điều khiển một số hành trình lớn hơn 3000

miles những không có chứng nhận trên loại máy bay Boeing.6. Tìm mã của những nhân viên có mức lương cao nhất.7. Tìm mã của những nhân viên có mức lương cao thứ hai.8. Tìm mã của những phi công đã được chứng nhận trên nhiều loại máy bay nhất.9. Tìm mã của những phi công đã được chứng nhận trên chính xác ba loại máy

bay.10. Tìm tổng số lương phải thanh toán cho nhân viên.11. Có hành trình nào từ Madison tới Timbuktu không? Mỗi chuyến trong hành

trình được yêu cầu khởi hành từ thành phố là đích của chuyến bay trước;chuyến bay đầu tiên phải rời từ Madison, chuyến bay cuối cùng phải tới đượcTimbuktu, và không giới hạn các các chuyến bay trung gian.

Trả lời: Trong những câu trả lời sau, RA là viết tắt của Relational Algebra, TRC viếttắt của Tuple Relational Calculus và DRC là của Domain Relational Calculus.

147/470

148/470

149/470

150/470

151/470

6.

• RA

Cách tiếp cận ở đây là: đầu tiên, tìm tất cả các nhân viên không phải là người có lươngcao nhất. Lấy danh sách gốc trừ đi danh sách này sẽ nhận được kết quả cần tìm.

1. RA

Cách tiếp cận ở đây tương tự với những lời giải ở bài tập trước. Đầu tiên, tìm tất cả nhânviên không có lương cao nhất. Loại bỏ những người này từ danh sách nhân viên banđầu và những nhân viên còn lại là những người được trả lương cao nhất. Loại bỏ nhữngngười có lương cao nhất từ danh sách ban đầu. Những người còn lại là những người cólương cao thứ hai trở xuống. Sau đó tìm những người có lương cao nhất trong danh sáchmới này. Kết quả sẽ nhận được danh sách những người có lương cao thứ hai.

152/470

8. Điều này không thể biểu diễn được trong đại số quan hệ (hoặc phép toán logic) vì nókhông có phép toán đếm, và truy vấn này yêu cầu khả năng đếm một số phụ thuộc vàodữ liệu. Tuy nhiên, truy vấn này có thể được biểu diễn bằng SQL như sau:

153/470

9. Các tiếp cận của truy vấn này là: đầu tiên, tìm những nhân viên được chứng nhận ítnhất ba loại máy bay (chúng xuất hiện ít nhất ba lần trong quan hệ Certified). Sau đó,tìm những nhân viên được chứng nhận ít nhất bốn loại máy bay. Sau đó trừ kết quả thứnhất cho kết quả thứ hai ta sẽ nhận được kết quả cần tìm.

154/470

155/470

1. Điều này không thể biểu diễn được bằng đại số quan hệ (hoặc phép toán logic)vì không có phép toán nào tính tổng các giá trị. Tuy nhiên, truy vấn này có thểđược biểu diễn bằng SQL như sau:

1. Điều này không biểu diễn được bằng đại số quan hệ hoặc phép toán logic hoặcSQL. Vấn đề ở đây là không có một giới hạn nào trên số lượng các chuyến baytrung gian. Tất cả các phương pháp truy vấn có thể có lời giải nếu có mộtchuyến bay trực tiếp từ Madison tới Timbuktu và nếu có thứ tự của hai chuyếnbay bắt đầu ở Madison và kết thúc ở Timbuktu. Thậm chí, có thể tìm được thứtự của n chuyến bay bắt đầu từ Madison và kết thúc ở Timbuktu miễn là chobiết số lượng các chuyến bay trung gian. Tuy nhiên, trong truy vấn này, cậntrên không phải là một số cố định mà là một số có khả năng thay đổi (tùy vàotập các bộ giá trị trong quan hệ Flights).

Tóm lại, nếu chúng ta có một số cận trên cố định (giả sử k), chúng ta có thể biết đượctruy vấn SQL và đại số. Nếu cận trên thay đổi thì chúng ta không thể viết được truy vấnnày vì k không được biết khi viết truy vấn.

Relational completeness là gì? Nếu một ngôn ngữ truy vấn relationally complete, bạncó thể viết bất kỳ truy vấn nào bằng ngôn ngữ này?

Trả lời: Dành cho độc giả.

156/470

Truy vấn không an toàn là gì? Cung cấp một ví dụ và giải thích vì sao cần phải khôngcho phép những truy vấn như vậy.

Trả lời:Truy vấn không an toàn là một truy vấn trong các phép toán logic mà kết quảcủa nó không được xác định. Ví dụ như truy vấn:

Truy vấn này trả về tất cả những điều không phải là Sailors. Rõ ràng, câu trả lời ở đâykhông được xác định nên nó là truy vấn không an toàn. Không cho phép các truy vấnkhông an toàn vì chúng ta muốn có thể trả về cho người dùng kết quả của câu truy vấnsau một khoảng thời gian giới hạn nào đó.

Tài liệu tham khảo

Đại số quan hệ đã được Codd đề xuất trong [187], và anh ấy đã chỉ ra sự tương đươnggiữa đại số quan hệ và TRRC trong [189]. Ở thời điểm sớm hơn, Kuhns [454] đã xemxét đến việc sử dụng logic để viết truy vấn.

LaCroix & Pirotte trình bày về DRC trong [459]. Klug tổng quát hóa đại số quan hệvà các phép toán logic bao gồm các hàm nhóm trong [439]. Những mở rộng của đại sốvà phép toán logic để thực hiện các hàm nhóm được bàn đến trong [578]. Merrett đãđề xuất về đại số quan hệ mở rộng dựa trên những lượng tử tồn tại và phổ dụng [530].Lượng tử phổ dụng được trình bày nhiều trong [52].

157/470

Truy vấn, Ràng buộc, TriggerSQL (Structured Query Language) là ngôn ngữ truy vấn cấu trúc được sử dụng rộngrãi trong cơ sở dữ liệu quan hệ. Đầu tiên, nó được IBM đề xuất trong dự án SEQUEL-XRM và System-R(1974-1977). Dường như ngay lập tức, những nhà sản xuất khác đãgiới thiệu sản phẩm DBMS của mình dựa trên SQL, và bây giờ nó đã được chuẩn hoáchính thức. SQL tiếp tục phát triển đáp ứng những thay đổi trong lĩnh vực cơ sở dữ liệu.Chuẩn ANSI/ISO hiện tại của SQL được gọi là SQL-1999. Trong khi không phải tất cảsản phẩm DBMS đều hỗ trợ SQL-1999 đầy đủ, những nhà sản xuất vẫn đang tiếp tụclàm việc để đạt đến điều này và hiện nay hầu hết các sản phẩm DBMS đều hỗ trợ nhữngđặc trưng cơ bản của SQL-1999.

Làm thích hợp các chuẩn của SQL: SQL:1999 có tập hợp các tính năng gọi là CoreSQL mà các nhà sản xuất phải thực hiện để thích hợp với chuẩn SQL-1999. Những đặctrưng còn lại được tổ chức trong các gói hỗ trợ.

Ví dụ, các gói được tổ chức như sau (các chương liên quan nằm trong dấu ngoặcđơn): kiểu ngày tháng nâng cao (enhanced date and time), quản lý ràng buộc nâng cao(enhanced integrity management) và các cơ sở dữ liệu hoạt động (active databases)(chương này), các giao diện ngôn ngữ phía ngoài (external language interfaces)(Chương 6), Xử lý các phân tích trực tuyến (OLAP) (Chương 25) và các đặc tính hướngđối tượng (object features) (Chương 23). Chuẩn SQL/MM thực hiện SQL-1999 bằngviệc định nghĩa các gói bổ sung hỗ trợ Khai phá dữ liệu (data mining) (Chương 26), dữliệu không gian (spatial data) (Chương 28) và văn bản (text documents) (Chương 27),hỗ trợ dữ liệu XML và các truy vấn tương lai.

Tổng quan

Ngôn ngữ SQL có một số khía cạnh:

• Ngôn ngữ thực hiện dữ liệu - The Data Manipulation Language (DML): Làtập hợp các lệnh của SQL cho phép người dùng đưa ra các truy vấn, thêm, sửavà xóa các dòng dữ liệu trong bảng. Những truy vấn sẽ được tập trung trình bàytrong chương này. Chúng ta đã khám phá DML để thêm, sửa, xóa dữ liệu trongChương 3.

• Ngôn ngữ định nghĩa dữ liệu - The Data Defination Language (DDL): Làtập hợp các câu lệnh của SQL hỗ trợ để tạo, xóa và sửa định nghĩa các bảng vàcác khung nhìn. Các ràng buộc tham chiếu có thể định nghĩa trên bảng, hoặc cóthể định nghĩa sau khi bảng được tạo ra. Chúng ta đã khám phá các đặc trưngDDL trong chương 3. Mặc dù chuẩn SQL không đề cập tới các chỉ số, nhưng

158/470

các thực hiện của DBMS thương mại cũng cung cấp lệnh để tạo và xóa các chỉsố.

• Trigger và Các ràng buộc toàn vẹn nâng cao (Triggers and AdvancedIntegrity Constraints): Chuẩn SQL:1999 mới có những hỗ trợ cho thực hiệntriggers, đó là tập những thao tác được DBMS thực hiện khi có bất kỳ sự thayđổi nào trong cơ sở dữ liệu. Chúng ta sẽ khám phá trigger và các ràng buộctrong chương này.

• SQL nhúng và động (Embedded và dynamic SQL):Các đặc trưng củaEmbedded SQL cho phép mã lệnh SQL được gọi từ một ngôn ngữ lập trình nhưC và COBOL. Các đặc trưng của Dynamic SQL cho phép một truy vấn đượcxây dựng và thực hiện run-time.

• Truy vấn cơ sở dữ liệu từ xa và các thực hiện Client-Server (Client-ServerExecution and Remote Database Access): Những lệnh này điều khiển cáchthức các chương trình ứng dụng trên Client kết nối với cơ sở dữ liệu trênServer, hoặc truy cập dữ liệu trong cơ sở dữ liệu trên mạng. Chúng ta sẽ khámphá những lệnh này trong Chương 7.

• Quản lý giao dịch (Transaction Management): Một loạt các lệnh cho phépngười dùng điều khiển các giao dịch.

• Bảo mật (Security): SQL cung cấp cơ chế để điều khiển các truy cập củangười dùng tới các đối tượng dữ liệu như các bảng và các khung nhìn.

• Các đặc trưng nâng cao (Advanced features): Chuẩn SQL:1999 bao gồm cáctính năng hướng đối tượng (Chương 23), các truy vấn lồng nhau (Chương 24),truy vấn hỗ trợ quyết định (Chương 25), khai phá dữ liệu (Chương 26), dữ liệukhông gian (Chương 28) và quản lý dữ liệu XML và văn bản (Chương 27).

• Tổ chức chương

Các phần của chương được tổ chức như sau. Phần 2 trình bày về các truy vấn SQL cơbản và Phần 3 giới thiệu các phép toán tập hợp. Phần 4 trình bày về các truy vấn lồngnhau. Phần 5.5 khám phá các phép toán nhóm. Chúng ta bàn tới các giá trị null trongPhần 6. Phần 7 xem xét các lệnh SQL được nhúng trong ngôn ngữ lập trình và trongPhần 8 bàn tới các bộ giá trị trong quan hệ được truy cập như thế nào bằng con trỏ. Phần9 trình bày như thế nào truy vấn được xây dựng sử dụng dynamic SQL, và trong Phần10 bàn về hai chuẩn kết nối tới DBMS là ODBC và JDBC. Phần 11 bàn về các ràngbuộc toàn vẹn phức tạp được thực hiện trong SQL DDL, phần tiếp theo của những phầnđã trình bày trong Chương 3; những ràng buộc mới cho phép chúng ta tận dụng đầy đủkhả năng của ngôn ngữ truy vấn SQL.

Cuối cùng, Phần 12 và 13 trình bày về khái niệm cơ sở dữ liệu hoạt động. Một cơ sở dữliệu hoạt động có một tập các triggers do các DBA định nghĩa. DBMS điều khiển cáccơ sở dữ liệu, phát hiện tình trạng hiện tại của cơ sở dữ liệu và gọi đến các trigger.

Các ví dụ:

159/470

Chúng ta sẽ xem xét một số ví dụ truy vấn sử dụng các bảng được định nghĩa sau:

Sailors(sid: integer, sname: string, rating: integer, age: real)

Boats(bid: integer, bname: string, color: string)

Reserves(sid: integer, bid: integer, day: date)

Chúng ta sẽ cung cấp cho mỗi truy vấn một mã duy nhất, và sử dụng tiếp các truy vấntrong Chương 4. Truy vấn mới đầu tiên của chương này có mã số Q15. Truy vấn từ Q1đến Q14 được định nghĩa trong Chương 4. Chúng ta sử dụng minh họa quan hệ S3 củaSailors, R2 của Reserves, và B1 của Boats giới thiệu trong Chương 4, hình 1, 2 và 3 đểlàm dữ liệu ví dụ cho các truy vấn.

Tất cả các bảng và truy vấn trong chương này có thể được tìm thấy trong Website:

http://www.cs.wisc.edu/~dbbook

Những vấn đề được chỉ ra bao gồm cách thức thực hiện câu lệnh SQL trong Oracle, IBMDB2, Microsoft SQL Server, và MySQL, và các scripts để tạo các bảng và các truy vấnví dụ.

Dạng đơn giản của truy vấn SQL

Phần này trình bày cú pháp của truy vấn SQL đơn giản và giải thích ý nghĩa của nóthông qua chiếnlược thực hiện truy vấn ở mức khái niệm. Chiến lược thực hiện truy vấnở mức khái niệm là cách để thực hiện truy vấn theo chiều hướng dễ hiểu, không tậptrung vào hiệu năng. DBMS sẽ thực hiện truy vấn có thể theo một cách khác hiệu quảhơn cách người dùng định nghĩa.

Dạng đơn giản của truy vấn SQL như sau:

Tất cả các truy vấn phải có mệnh đề SELECT, chỉ ra những cột nào được đưa ra trongkết quả, và mệnh đề FROM xác định bảng chứa những cột liên quan trong câu lệnh.Mệnh đề WHERE xác định điều kiện chọn.

Chúng ta đã biết rằng một truy vấn liên quan tới các biểu thức trong đại số quan hệ, baogồm phép chọn, phép chiếu, phép nhân chéo. Quan hệ chặt chẽ giữa đại số quan hệ vàSQL là nền tảng để tối ưu hóa truy vấn trong DBMS quan hệ, chúng ta sẽ xem trongChương 12 và 15. Kế hoạch thực hiện truy vấn SQL được biểu diễn sử dụng hàng loạtcác biểu thức đại số quan hệ (Phần 15.1).

160/470

Minh họa S3 của Sailors

Minh họa R2 của Reserves

(Q15) Đưa ra tên và tuổi của tất cả các thủy thủ.

SELECT DISTINCT S.sname, S.age FROM Sailors S

Minh họa B1 của Boats

Hình 3 Minh họa B1 của Boats

Kết quả của truy vấn này trong trường hợp có và không có từ khóa DISTINCT dựa trênminh họa của Sailors chỉ ra trong Hình 4 và 5. Chỉ có sự khác nhau trong hai kết quảnày là sự xuất hiện hay không xuất hiện của bộ giá trị có tên là Horatio và tuổi là 35.

161/470

Truy vấn tiếp theo có sử dụng đến phép chọn trong đại số quan hệ.

Kết quả của Q15

Kết quả của Q15 bỏ DISTINCTSELECT S.sid, S.sname, S.rating, S.age FROM Sailors AS SWHERE S.rating > 7

Như hai ví dụ minh họa ở trên, mệnh đề SELECT được sử dụng để thực hiện phép chiếu,trong khi phép chọn trong đại số quan hệ được biểu diễn sau mệnh đề WHERE! Chúngta sẽ đề cập chi tiết đến các cú pháp của truy vấn SQL đơn giản:

• Cụm from-list sau mệnh đề FROM là danh sách tên các bảng. Tên bảng có thểđược thay bằng một biến miền, biến miền hữu ích khi cùng một tên bảng xuấthiện nhiều hơn một lần trong from-list.

• Cụm select-list là danh sách tên các cột của bảng trong from-list. Các tên cột cóthể có tiền tố là các biến miền.

• Qualification trong mệnh đề WHERE là một tổ hợp logic (tức là, biểu thức sửdụng kết nối logic AND, OR, NOT) của các điều kiện theo dạngBiểu_thứcopBiểu_thức, trong đó op là một trong những toán tử logic ?>, <, >=,<=, =?. Một biểu thức là tên cột, hằng số, hoặc một biểu thức (toán học hoặcxâu ký tự).

162/470

• Từ khóa DISTINCT là từ khóa lựa chọn. Nó chỉ ra rằng bảng kết quả của truyvấn có nên chứa bộ giá trị trùng nhau không. Mặc định, những bộ giá trị trùngnhau không được phép loại bỏ.

Mặc dù, những quy tắc phía trên biểu diễn cú pháp của truy vấn SQL cơ bản, nhưngchúng không nói cho chúng ta biết ý nghĩa của một truy vấn. Kết quả của một truy vấnlà một quan hệ bao gồm một tập các dòng! - những nội dung này có thể được hiểu bằngviệc xem xét chiến lược thực hiện truy vấn ở mức khái niệm sau:

1. Tìm kết quả của phép nhân chéo trên các bảng trong from-list.2. Xoá các dòng trong kết quả của phép nhân chéo không thoả mãn các điều kiện

trong qualification.3. Xoá tất cả các cột không xuất hiện trong select-list.4. Nếu có từ khoá DISTINCT, kết quả của truy vấn sẽ bỏ đi những dòng trùng

nhau.

Chiến lược thực hiện truy vấn ở mức khái niệm nói trên làm chúng ta nhìn thấy rõ ràngnhững dòng nào cần được xuất hiện trong kết quả. Tuy nhiên, nó dường như là khôngthực sự hiệu quả (tốc độ thực hiện truy vấn chậm). Chúng ta sẽ xem xét chi tiết về cáchthực hiện một truy vấn như thế nào trong Chương 12 và 13; bây giờ, mục đích của chúngta chỉ đơn giản là giải thích ý nghĩa của truy vấn. Chúng ta sử dụng truy vấn sau để minhhoạ chiến lược thực hiện truy vấn ở mức khái niệm:

(Q1) Tìm tên các thuỷ thủ đã phục vụ trên tàu mã số 103.

Câu lệnh SQL như sau:

SELECT S.sname FROM Sailors S, Reserves R WHERE S.sid =R.sid AND R.bid=103

Bước đầu tiên là xây dựng phép nhân chéo S4 × R3, kết quả chỉ ra trong Hình 8.

Bước thứ hai là áp dụng điều kiện S.sid=R.sid AND R.bid=103 (Ghi nhớ rằng phép sosánh đầu tiên là yêu cầu của phép nối). Bước này loại bỏ tất cả trừ dòng cuối cùng trongminh hoạ chỉ ra trong Hình 5.8. Bước thứ 3 là loại bỏ những cột không cần thiết, chỉsname xuất hiện trong mệnh đề SELECT là cần được giữ lại. Bước này đưa chúng tađến kết quả trong Hình 9, bảng chỉ có một cột và một dòng.

Minh hoạ R3 của Reserves

163/470

Hình 6. Minh hoạ R3 của Reserves

Minh hoạ S4 của Sailors

S4 × R3

Kết quả của truy vấn Q1 trên R3 v S4

Bây giờ, chúng tôi trình bày một số ví dụ truy vấn, rất nhiều trong số này đã được trìnhbày trong phần đại số quan hệ và các phép toán logic (Chương 4). Ví dụ đầu tiên minhhoạ cách sử dụng các biến miền là biến không bắt buộc. Truy vấn Q1 bàn đến trongphần trước có thể được viết như sau:

SELECT sname FROM Sailors S, Reserves R WHERE S.sid =R.sid AND bid=103 SELECT sname FROM Sailors, Reserves WHERESailors.sid = Reserves.sid AND bid=103

(Q16) Tìm các sid của thuỷ thủ đã phục vụ trên tàu màu 'red'.

SELECT R.sid FROM Boats B, Reserves R WHERE B.bid = R.bidAND B.color = 'red'

(Q2) Tìm tên các thuỷ thủ đã phục vụ trên tàu màu 'red'.

FROM Sailors S, Reserves R, Boats B WHERE S.sid = R.sidAND R.bid = B.bid AND B.color = 'red'

Truy vấn này chứa phép nối giữa ba bảng, tiếp đến là điều kiện chọn màu của tàu. Kếtnối với Sailors cho phép chúng ta tìm tên các thuỷ thủ.

164/470

(Q3) Tìm màu của các tàu đã được Lubber phục vụ.

SELECT B.color FROM Sailors S, Reserves R, Boats B WHERES.sid = R.sid AND R.bid = B.bid AND S.sname = 'Lubber'

(Q4) Tìm tên các thuỷ thủ đã phục vụ trên ít nhất một tàu.

SELECT S.sname FROM Sailors S, Reserves R WHERE S.sid =R.sid

SQL hỗ trợ một phiên bản chung của select-list, trong đó không chỉ có danh sách cáccột. Mỗi mục trong select-list có thể có dạng biểu-thức AS tên-cột, trong đó biểu-thứclà một biểu thức toán hoặc một xâu ký tự của các cột (tiền tố có thể là một biến miền)và các hằng số. Nó có thể chứa hàm nhóm như sum và count, phần này chúng ta sẽ bàntrong Phần 5. Chuẩn SQL cũng hỗ trợ các biểu thức dạng ngày và tháng, phần này chúngta sẽ không bàn ở đây. Mặc dù không phải là một thành phần của chuẩn SQL, rất nhiềucác hệ thống thực thi cũng hỗ trợ sử dụng các hàm hỗ trợ như sqrt, sin và mod.

Biểu thức thông thường trong SQL: Phản ảnh tầm quan trọng của dữ liệu dạng ký tự,SQL: 1999 bao gồm một toán tử mạnh LIKE, còn gọi là SIMILAR. Toán tử này hỗ trợmạnh mẽ việc tìm kiếm ký tự. Những biểu thức thông thường cũng được hệ điều hànhUnix hỗ trợ phục vụ cho tìm kiếm xâu ký tự, mặc dù cú pháp có khác nhau một chút.

Đại số quan hệ và SQL: Tập các phép toán trong SQL có thể thực thi trong đại số quanhệ.

(Q17) Tăng rating lên 1 cho những người đã phục vụ trên hai tàu khác nhau trong mộtngày.

SELECT S.sname, S.rating+1 AS rating FROM Sailors S,Reserves R1, Reserves R2 WHERE S.sid = R1.sid AND S.sid =R2.sid AND R1.day = R2.day AND R1.bid <> R2.bid SELECTS1.sname AS name1, S2.sname AS name2 FROM Sailors S1,Sailors S2 WHERE 2*S1.rating = S2.rating-1

Thêm vào đó, SQL cung cấp khả năng so sánh mẫu thông qua toán tử LIKE, cùng vớiviệc sử dụng ký hiệu % (thay thế cho số không hoặc nhiều ký tự bất kỳ) và _ (thay thếcho chính xác một ký tự bất kỳ). Vì thế '_AB%' là một mẫu phù hợp với tất cả các xâucó chứa ít nhất 3 ký tự, trong đó ký tự thứ 2 và thứ 3 là A và B tương ứng. Ghi nhớ rằng,không như những toán tử so sánh khác, ký tự trống cũng quan trọng trong toán tử LIKE.Vì thế, 'Jept' ='Jept ' là đúng, trong khi 'Jept' LIKE 'Jept' là sai. Một ví dụ sử dụng LIKEtrong truy vấn như sau:

165/470

(Q18) Tìm tuổi các thuỷ thủ có tên bắt đầu và kết thúc bằng ký tự B và có ít nhất 3 kýtự.

SELECT S.age FROM Sailors S WHERE S.sname LIKE 'B_%B'

Hợp, giao và trừ

SQL cung cấp 3 cấu trúc thực hiện trên tập hợp, phần mở rộng của các dạng truy vấn cơbản phía trước. Vì kết quả của một truy vấn là tập hợp các dòng nên việc xem xét đếncác phép toán như hợp (UNION), giao (INTERSECT), trừ (EXCEPT) là rất tự nhiên.SQL hỗ trợ ba phép toán này thông qua từ khoá UNION, INTERSECT, and EXCEPT.SQL cũng cung cấp các phép toán tập hợp khác: IN (để kiểm tra một phần tử nào đócó ở trong tập hợp hay không), op ANY, op ALL (để so sánh một giá trị cùng với cácphần tử trong một tập hợp nào đó, sử dụng phép so sánh op), và EXIST (để kiểm tra mộttập hợp có rỗng hay không), Chúng ta khám phá các toán tử UNION, INTERSECT, vàEXCEPT trong phần này, và các toán tử khác trong Phần 4.

Xem xét truy vấn sau đây:

(Q5) Tìm tên các thuỷ thủ đã phục vụ trên tàu màu đỏ hoặc màu xanh.

SELECT S.sname FROM Sailors S, Reserves R, Boats B WHERES.sid = R.sid AND R.bid = B.bid AND (B.color = 'red' ORB.color = 'green')

(Q6) Tìm tên các thuỷ thủ đã phục vụ trên cả hai tàu màu đỏ và màu xanh.

Nếu chúng ta chỉ thay thế OR bằng AND, chúng ta sẽ nhận được tên các thuỷ thủ đãphục vụ trên một tàu có hai màu đỏ và xanh. Một ràng buộc tham chiếu chỉ ra rằng bidlà khoá của Boats chứng tỏ rằng cùng một tàu không thể có hai màu, vì thế sự thay đổiAND cho OR trong truy vấn trước sẽ trả lại kết quả là một tập rỗng. Câu lệnh đúng củaQ6 sử dụng toán tử AND như sau:

SELECT S.sname FROM Sailors S, Reserves R1, Boats B1,Reserves R2, Boats B2 WHERE S.sid = R1.sid AND R1.bid =B1.bid AND S.sid = R2.sid AND R2.bid = B2.bid ANDB1.color='red' AND B2.color = 'green'

Truy vấn trước rất khó để hiểu (và cũng không hiệu quả cho việc thực hiện). Giải pháptốt cho hai truy vấn này là sử dụng UNION và INTERSECT.

Truy vấn Q5 có thể viết lại như sau:

166/470

SELECT S.sname FROM Sailors S, Reserves R, Boats B WHERES.sid = R.sid AND R.bid = B.bid AND B.color = 'red' UNIONSELECT S2.sname FROM Sailors S2, Boats B2, Reserves R2WHERE S2.sid = R2.sid AND R2.bid = B2.bid AND B2.color ='green' SELECT S.sname FROM Sailors S, Reserves R, Boats BWHERE S.sid = R.sid AND R.bid = B.bid AND B.color = 'red'INTERSECT SELECT S2.sname FROM Sailors S2, Boats B2,Reserves R2 WHERE S2.sid = R2.sid AND R2.bid = B2.bid ANDB2.color = 'green'

Như chúng ta đã quan sát trong chương 4, vấn đề này tồn tại bởi vì sname không xácđịnh được một thuỷ thủ nào đó, vì sname không phải là khoá của Sailor. Nếu chúng tachọn sid thay cho sname, chúng ta sẽ đưa ra được tập các thuỷ thủ đã phục vụ trên cảhai tàu màu đỏ và màu xanh. (Để đưa ra được tên các thuỷ thủ như yêu cầu của truy vấn,chúng ta sẽ phải sử dụng đến truy vấn lồng nhau, chúng ta sẽ bàn đến ví dụ này trongPhần 5.4.4)

Truy vấn tiếp theo minh hoạ phép toán tập hợp trong SQL là:

(Q19) Tìm sid của các thuỷ thủ đã phục vụ trên tàu màu đỏ, nhưng không phục vụ trêntàu màu xanh.

SELECT S.sid FROM Sailors S, Reserves R, Boats B WHERES.sid = R.sid AND R.bid = B.bid AND B.color = 'red' EXCEPTSELECT S2.sid FROM Sailors S2, Reserves R2, Boats B2 WHERES2.sid = R2.sid AND R2.bid = B2.bid AND B2.color ='green'

Ngoài ra, vì quan hệ Reserves chứa trường sid nên chúng ta không cần tìm trong quanhệ Sailors, và chúng ta có thể sử dụng một truy vấn đơn giản hơn.

SELECT R.sid FROM Boats B, Reserves R WHERE R.bid = B.bidAND B.color = 'red' EXCEPT SELECT R2.sid FROM Boats B2,Reserves R2 WHERE R2.bid = B2.bid AND B2.color = 'green'

(Q20) Tìm tất cả các sid của thuỷ thủ có rating là 10 hoặc đã phục vụ trên tàu 104.

SELECT S.sid FROM Sailors S WHERE S.rating = 10 UNIONSELECT R.sid FROM Reserves R WHERE R.bid = 104

167/470

Truy vấn lồng nhau

Một trong các tính năng mạnh mẽ nhất của SQL là truy vấn lồng nhau. Một truy vấnlồng nhau là một truy vấn có một hay nhiều truy vấn khác bên trong nó, truy vấn bêntrong được gọi là truy vấn con. Khi viết một truy vấn, đôi khi chúng ta cần biểu diễnmột điều kiện, điều kiện đó liên quan đến kết quả của một truy vấn khác. Truy vấn conthông thường xuất hiện trong mệnh đề WHERE. Truy vấn con đôi khi cũng xuất hiệntrong mệnh đề FROM hoặc HAVING (chúng tôi sẽ trình bày trong Phần 5)

Phần này chỉ bàn tới những truy vấn con xuất hiện trong mệnh đề WHERE. Cách làmtruy vấn con trong các mệnh đề khác cũng tương tự. Những ví dụ về truy vấn con xuấthiện trong mệnh đề FROM sẽ được trình bày trong Phần 5.5.1.

Đại số quan hệ và SQL: Sự lồng nhau của các truy vấn là một tính năng không thể biểudiễn được trong đại số quan hệ, nhưng các truy vấn con có thể được chuyển vào đại số,chúng ta sẽ nhìn thấy trong Chương 15. Sự lồng nhau trong SQL được các phép toánlogic trên quan hệ hỗ trợ nhiều hơn là được đại số quan hệ hỗ trợ. Trong mối liên quanvới một số tính năng khác của SQL, như các toán tử hỗ trợ tập hợp và nhóm, lồng nhaulà một cấu trúc thường xuyên được sử dụng.

Giới thiệu về các truy vấn lồng nhau

Để ví dụ, chúng ta cùng nhau viết lại truy vấn sau sử dụng truy vấn lồng nhau:

(Q1) Tìm tên các thuỷ thủ đã phục vụ trên tàu 103.

SELECT S.sname FROM Sailors S WHERE S.sid IN ( SELECTR.sid FROM Reserves R WHERE R.bid = 103 )

Truy vấn con tìm ra một tập các sid của thuỷ thủ đã phục vu trên tàu 103 (đó là 22, 31,và 74 trong minh hoạ R2 và S3), và truy vấn bên trên đưa ra tên các thuỷ thủ có sid nằmtrong tập đó. Toán tử IN cho phép chúng ta kiểm tra một giá trị có nằm trong một tậpcác phần tử; một truy vấn SQL được sử dụng để để đưa ra tập các bộ giá trị thoả mãnđiều kiện kiểm tra. Ghi nhớ rằng, nếu muốn đưa ra tập các thuỷ thủ không phục vụ trêntàu 103 thì rất đơn giản chỉ cần thay IN bằng NOT IN.

Cách tốt nhất để hiểu truy vấn lồng nhau là chỉ nghĩ đến nó trong ngữ cảnh đánh giátruy vấn ở mức khái niệm. Trong ví dụ của chúng ta, chiến lược thực hiện ở đây là: đầutiên kiểm tra các dòng trong Sailors, sau đó ứng với từng dòng này, thực hiện truy vấncon trên quan hệ Reserves. Nói chung, chiến lược đánh giá khái niệm chúng ta đã sửdụng để biểu diễn việc định nghĩa một truy vấn có thể được mở rộng để biểu diễn truyvấn lồng nhau như sau: Xây dựng phép nhân chéo giữa các bảng trong mệnh đề FROM.Với mỗi dòng trong phép nhân chéo, khi kiểm tra điều kiện trong mệnh đề WHERE,

168/470

tính toán (lại) truy vấn con. Tất nhiên, truy vấn con bản thân nó có thể chứa những truyvấn con khác, trong trường hợp này chúng ta tiếp tục áp dụng ý tưởng này.

Để biểu diễn truy vấn lồng nhau nhiều mức, chúng ta viết lại truy vấn Q2 như sau:

(Q2) Tìm tên các thuỷ thủ đã phục vụ trên tàu màu đỏ.

SELECT S.sname FROM Sailors S WHERE S.sid IN (SELECT R.sidFROM Reserves R WHERE R.bid IN (SELECT B.bid FROM Boats BWHERE B.color = 'red' )

Truy vấn trong cùng tìm ra tập các bid của tàu màu đỏ (102 và 104 trong minh hoạ B1).Truy vấn con phía trên tìm ra tập các thuỷ thủ đã phục vụ trên một trong những tàu này.Trong minh hoạ B1, R2 và S3, tập sid là 22, 31 và 64. Truy vấn trên cùng tìm ra têncác thuỷ thủ có sid nằm trong tập sid trên. Trong các minh hoạ này, kết quả có Dustin,Lubber, và Horatio.

Để tìm tên các thuỷ thủ không phục vụ trên tàu màu đỏ, chúng ta chỉ thay thế IN bằngNOT IN.

(Q21) Tìm tên các thuỷ thủ chưa từng phục vụ trên tàu nào có màu đỏ.

SELECT S.sname FROM Sailors S WHERE S.sid NOT IN ( SELECTR.sid FROM Reserves R WHERE R.bid IN (SELECT B.bid FROMBoats B WHERE B.color = 'red' )

Truy vấn này đưa ra tên các thuỷ thủ có sid không nằm trong tập 22, 31 và 64.

Ngược lại với truy vấn Q21, chúng ta có thể sửa truy vấn trước (phiên bản lồng nhaucủa Q2) bằng việc thay thế IN bằng NOT IN trong truy vấn con bên trong. Việc sửa nàysẽ đưa ra tên các thuỷ thủ đã phục vụ trên tàu không phải màu đỏ. Hãy cùng chúng tôixem xét cụ thể. Trong truy vấn con, chúng ta kiểm tra R.bid không phải là 102 và 104(bid của những tàu màu đỏ). Truy vấn bên ngoài tìm ra những bộ giá trị trong Reservescó bid không phải là 102 và 104. Trên minh hoạ B1, R2 và S3, truy vấn ngoài trả lại kếtquả là tập sid 22, 31, 64 và 74. Cuối cùng, chúng ta tìm ra tên các thuỷ thủ có sid nằmtrong tập này.

Chúng ta có thể sửa truy vấn lồng nhau Q2 bằng việc thay thế cả hai từ khoá IN bằngNOT IN. Việc thay thế này sẽ giúp tìm ra tên các thuỷ thủ chưa từng phục vụ trên tàukhông phải màu đỏ, tức là, họ chỉ phục vụ trên những tàu có màu đỏ. Trên minh hoạ B1,R2 và S3, truy vấn bên ngoài đưa ra tập các sid của thuỷ thủ không phải là 22, 31, 64và 74. Tập này là 29, 32, 58, 71, 85, và 95. Chúng ta sau đó sẽ tìm ra tên tương ứng củatừng thuỷ thủ.

169/470

Truy vấn lồng nhau liên kết

Trong các truy vấn lồng nhau chúng ta đã xem xét phía trước, truy vấn bên trong thựchiện độc lập với truy vấn bên ngoài. Thông thường, truy vấn bên trong có thể phụ thuộcvào bản ghi đang xét ở truy vấn bên ngoài (xét về khía cạnh kế hoạch thực hiện truyvấn). Hãy cùng chúng tôi viết lại truy vấn sau:

(Q1) Tìm tên các thuỷ thủ đã phục vụ trên tàu 103

SELECT S.sname FROM Sailors S WHERE EXISTS ( SELECT * FROMReserves R WHERE R.bid = 103 AND R.sid = S.sid )

Toán tử EXISTS là toán tử so sánh trên tập hợp, giống như IN. Nó cho phép chúng takiểm tra một giá trị nào đó có tồn tại trong một tập hợp không. Vì thế, với mỗi thuỷ thủtrên dòng S, chúng ta kiểm tra giá trị này trên tập các dòng của Reserves (R) xem córỗng không. Nếu không rỗng, tức là thuỷ thủ S đã phục vụ trên tàu 103 và chúng ta sẽđưa ra tên của họ. Truy vấn con rõ ràng phụ thuộc vào dòng đang xét S và phải xem xéttrên từng dòng của Sailors. Sự xuất hiện của S trong truy vấn con (có dạng S.sid) đượcgọi là liên kết, và truy vấn như thế này gọi là những truy vấn liên kết.

Trong ví dụ phía trước, bằng việc sử dụng NOT EXIST thay cho EXIST, chúng ta cóthể đưa ra tên các thuỷ thủ chưa từng phục vụ trên tàu màu đỏ. Liên quan chặt chẽ đếnEXISTS là xác nhận UNIQUE. Khi chúng ta áp dụng UNIQUE trong truy vấn con, nósẽ trả lại True nếu không có dòng nào xuất hiện hai lần trong kết quả của truy vấn con,có nghĩa là, ở đó không có sự trùng nhau; trong trường hợp đặc biệt, nó trả lại True nếukết quả truy vấn con rỗng (Và đây cũng là trường hợp của NOT UNIQUE)

Các toán tử so sánh trên tập hợp

Chúng ta đã xem xét một số toán tử trên tập hợp là EXISTS, IN và UNIQUE và trườnghợp phủ định tương ứng. SQL cũng hỗ trợ op ANY và op ALL, trong đó op là mộttrong những phép so sánh ?>, <=, =, <, >=? (SOME cũng có thể sử dụng, nhưng nó cùngnghĩa với ANY)

(Q22) Tìm những thuỷ thủ có rating lớn hơn của bất kỳ thuỷ thủ nào có tên là Horatio.

SELECT S.sid FROM Sailors S WHERE S.rating > ANY ( SELECTS2.rating FROM Sailors S2 WHERE S2.sname = 'Horatio' )

Nếu chúng ta có một vài thuỷ thủ có tên là Horatio, truy vấn này tìm ra tất cả các thuỷthủ có rating cao hơn một thủy thủ nào đó có tên Horatio. Trên minh hoạ S3, kết quảtruy vấn này là các sid 31, 32, 58, 71, và 74. Nếu ở đó không có thuỷ thủ nào có tên làHoratio thì sao? Trong trường hợp này so sánh S.rating> ANY … được định nghĩa để trả

170/470

về giá trị False, và truy vấn trên trả về tập kết quả là rỗng. Để hiểu những so sánh cóchứa ANY, chúng ta cần phải biết rằng những so sánh được thực hiện so sánh lặp đi lặplại. Trong ví dụ trên, S.rating được so sánh thành công với một số giá trị rating trongkết quả của truy vấn con. Truy vấn con phải trả lại dòng mà kết quả so sánh là True. Sosánh trả về giá trị True nếu một trong số so sánh trên từng dòng trả lại giá trị True.

(Q23) Tìm các thuỷ thủ có rating lớn hơn của tất cả các thuỷ thủ có tên là Horatio.

Chúng ta có thể đạt được yêu cầu trên bằng việc sửa truy vấn Q22 một chút, chỉ cầnthay thế ANY bằng ALL trong mệnh đề WHERE của truy vấn ngoài. Trong minh hoạS3, chúng ta sẽ có sids là 58 và 71. Nếu ở đó không có thuỷ thủ nào có tên là Horatio, sosánh S.rating>ALL… sẽ trả về giá trị True. Sau đó, truy vấn sẽ đưa ra tên của tất cả cácthuỷ thủ. Một lần nữa, chúng ta lại cần phải biết rằng việc thực hiện so sánh được lặp đilặp lại. So sánh phải trả về giá trị True nếu tất cả các so sánh trên từng dòng trả lại giátrị True.

Một minh hoạ khác sử dụng ALL, xem xét truy vấn sau:

(Q24) Tìm tất cả các thuỷ thủ có rating cao nhất.

SELECT S.sid FROM Sailors S WHERE S.rating >= ALL ( SELECTS2.rating FROM Sailors S2 )

Truy vấn con đưa ra tập rating của tất cả các thuỷ thủ. Điều kiện WHERE chỉ được thoảmãn S.rating lớn hơn hoặc bằng tất cả các giá trị rating trong truy vấn con, tức là, khinó là giá trị rating lớn nhất. Trong minh họa S3, điều kiện thoả mãn với rating bằng 10,và các sid có rating này là 58 và 71.

Ghi nhớ rằng IN và NOT IN lần lượt tương đương với =ANY và <>ALL.

Một số ví dụ khác về truy vấn lồng nhau

Chúng ta cùng nhau xem lại một số truy vấn phía trên sử dụng toán tử INTERSECT.

(Q6) Tìm tên các thuỷ thủ đã phục vụ trên tàu màu 'red' và tàu màu 'green'

SELECT S.sname FROM Sailors S, Reserves R, Boats B WHERES.sid = R.sid AND R.bid = B.bid AND B.color = 'red' ANDS.sid IN ( SELECT S2.sid FROM Sailors S2, Boats B2,Reserves R2 WHERE S2.sid = R2.sid AND R2.bid = B2.bid ANDB2.color = 'green' )

171/470

Truy vấn này có thể được hiểu như sau: Tìm tất cả thuỷ thủ đã phục vụ trên tàu màu đỏvà thêm nữa, các sid này có trong tập các sid của thuỷ thủ đã phục vụ trên tàu màu xanh.Minh hoạ này chỉ ra cách thức một truy vấn sử dụng INTERSECT có thể được viết lạisử dụng IN, nó sẽ rất hữu ích nếu hệ thống của bạn không hỗ trợ toán tử INTERSECT.Những truy vấn sử dụng EXCEPT có thể viết lại tương đương sử dụng NOT IN. Để tìmnhững sid của thuỷ thủ đã phục vụ trên tàu màu đỏ nhưng chưa phục vụ trên tàu màuxanh, chúng ta chỉ cần thay thế từ khoá IN trong truy vấn trước bằng từ khoá NOT IN.

Viết lại truy vấn (Q6) sử dụng INTERSECT là phức tạp hơn vì chúng ta phải sử dụngcác sid để xác định các thuỷ thủ và phải trả về tên của họ:

SELECT S3.sname FROM Sailors S3 WHERE S3.sid IN (( SELECTR.sid FROM Boats B, Reserves R WHERE R.bid = B.bid ANDB.color = `red' ) INTERSECT (SELECT R2.sid FROM Boats B2,Reserves R2 WHERE R2.bid = B2.bid AND B2.color = 'green'))

Ví dụ tiếp theo của chúng ta minh hoạ cách biểu diễn SQL của phép chia trong đại sốquan hệ.

(Q9) Tìm ra tên các thuỷ thủ đã phục vụ trên tất cả các tàu.

SELECT S.sname FROM Sailors S WHERE NOT EXISTS (( SELECTB.bid FROM Boats B ) EXCEPT (SELECT R.bid FROM Reserves RWHERE R.sid = S.sid ))

Ghi nhớ rằng truy vấn này là liên kết- với mỗi thuỷ thủ S, chúng ta kiểm tra để thấy rằngtập các tàu mà S đã phục vụ là một tập chứa tất cả các tàu. Cách khác để thực hiện truyvấn này mà không sử dụng EXCEPT như sau:

SELECT S.sname FROM Sailors S WHERE NOT EXISTS ( SELECTB.bid FROM Boats B WHERE NOT EXISTS ( SELECT R.bid FROMReserves R WHERE R.bid = B.bid AND R.sid = S.sid ))

Trong đó, mỗi thủy thủ chúng ta kiểm tra thì không có một tàu nào mà thuỷ thủ này chưaphục vụ.

SQL: 1999 Các hàm nhóm: Tập hợp các hàm nhóm được mở rộng rất nhiều trongchuẩn mới, bao gồm một số hàm thống kê như độ lệch chuẩn, hiệp phương sai. Tuynhiên, các hàm nhóm mới được đóng gói trong SQL/OLAP không phải được tất cả cácnhà sản xuất hỗ trợ.

172/470

Hàm nhóm

Khi truy vấn dữ liệu, chúng ta thường muốn thực hiện một số tính toán hoặc tổng kếttrên những dữ liệu đó. Như chúng ta đã biết trong chương trước, SQL cho phép thựchiện các biểu thức toán học. Chúng ta sẽ xem xét khả năng tính toán trên các nhóm dữliệu thông qua các hàm như MIN và SUM. Những đặc tính này là một trong những phầnmở rộng của đại số quan hệ. SQL hỗ trợ năm hàm nhóm, có thể áp dụng trên bất kỳ cộtnào, giả sử A, của một quan hệ:

1. COUNT([DISTINCT] A): Số các giá trị (khác nhau) tại cột A

2. SUM([DISTINCT] A): Tổng số của tất cả các giá trị (khác nhau) tại cột A.

3. AVG([DISTINCT] A): Giá trị trung bình của tất cả các giá trị (khác nhau) tại cột A.

4. MAX(A): Giá trị lớn nhất trên cột A

5. MIN(A): Giá trị lớn nhất trên cột A

Ghi nhớ rằng sẽ không có ý nghĩa nếu chỉ ra từ khoá DISTINCT đằng sau MIN hoặcMAX.

(Q25) Tìm tuổi trung bình của tất cả thuỷ thủ.

SELECT AVG (S.age) FROM Sailors S

Trong minh hoạ S3, tuổi trung bình là 37.4. Tất nhiên, mệnh đề WHERE có thể được sửdụng để giới hạn bớt các thuỷ thủ tham gia vào hàm nhóm.

(Q26) Tìm tuổi trung bình của các thuỷ thủ có rating bằng 10

SELECT AVG (S.age) FROM Sailors S WHERE S.rating = 10

Chỉ có hai thuỷ thủ thoả mãn điều kiện này, tuổi trung bình của họ là 25.5. MIN hoặcMAX có thể được sử dụng thay thế cho AVG trong truy vấn trên để tìm ra tuổi ít nhấtvà tuổi nhiều nhất của thuỷ thủ.

Tuy nhiên, tìm cả tên và tuổi của thuỷ thủ lớn tuổi nhất thì phức tạp hơn, như minh hoạtrong truy vấn tiếp theo.

(Q27) Tìm tên và tuổi của thuỷ thủ lớn tuổi nhất. Xem xét truy vấn sau và cố gắng đưara kết quả của truy vấn này.

SELECT S.sname, MAX (S.age) FROM Sailors S

173/470

Mục đích của truy vấn này là trả lại chỉ tuổi lớn nhất và tên của người thuỷ thủ tươngứng. Tuy nhiên, truy vấn này không hợp lệ trong SQL - nếu mệnh đề SELECT sử dụngmột hàm nhóm, thì nó phải sử dụng chỉ những hàm nhóm trừ khi truy vấn đó có chứamệnh đề GROUP BY! (Cụ thể của hạn chế này sẽ được bàn đến trong mệnh đề GROUPBY ở Phần 5.5.1). Vì thế, chúng ta không thể sử dụng Max(S.age) cùng với S.nametrong mệnh đề SELECT. Chúng ta phải sử dụng đến truy vấn con để thực hiện yêu cầutrong Q27.

SELECT S.sname, S.age FROM Sailors S WHERE S.age = (SELECT MAX (S2.age) FROM Sailors S2 )

Quan sát thấy rằng, chúng ta sử dụng kết quả của hàm nhóm trong truy vấn con như mộtđối số của phép so sánh. Nói đúng ra, chúng ta so sánh giá trị tuổi của tất cả các thuỷ thủvới kết quả của truy vấn con. Tuy nhiên, vì sử dụng hàm nhóm, truy vấn con đảm bảosẽ trả về giá trị duy nhất trong một trường duy nhất, và SQL chuyển quan hệ thành mộtgiá trị để có thể so sánh được. Sau đây là một truy vấn cho kết quả tương đương trongchuẩn SQL, tuy nhiên không nhiều hệ thống hỗ trợ kiểu truy vấn này.

SELECT S.sname, S.age FROM Sailors S WHERE (SELECT MAX(S2.age) FROM Sailors S2 ) = S.age

Chúng ta có thể đếm số thuỷ thủ sử dụng mệnh đề COUNT. Ví dụ này minh hoạ việc sửdụng COUNT, nó hữu ích khi chúng ta muốn đếm xem có tất cả bao nhiêu thuỷ thủ.

(Q28) Đếm xem có tổng số bao nhiêu thuỷ thủ

SELECT COUNT (*) FROM Sailors S

Chúng ta có thể nghĩ ký tự * như cách viết ngắn để thay thế tất cả các cột. Ngược lại vớitruy vấn này, truy vấn sau đây chỉ ra số các thuỷ thủ có tên khác nhau. (Ghi nhớ rằngsname không phải là khoá)

(Q29) Đếm số các thuỷ thủ có tên khác nhau

SELECT COUNT ( DISTINCT S.sname ) FROM Sailors S

Trong minh hoạ S3, kết quả của truy vấn Q28 là 10, trong khi kết quả của Q29 là 9 vì cóhai thuỷ thủ có tên trùng nhau là Horatio. Nếu bỏ từ khóa DISTINCT, kết quả của Q29là 10 vì tên Horatio được đếm hai lần. Vì thế, nếu không có DISTINCT thì Q29 và Q28tương đương nhau. Tuy nhiên, sử dụng COUNT(*) là lựa chọn tốt khi có thể.

Hàm nhóm thường được sử dụng kết hợp với cấu trúc ANY và ALL. Ví dụ, xem xéttruy vấn sau:

174/470

(Q30) Tìm tên các thủy thủ người lớn tuổi hơn người già nhất có rating bằng 10.

SELECT S.sname FROM Sailors S WHERE S.age > ( SELECT MAX (S2.age ) FROM Sailors S2 WHERE S2.rating = 10 )

Trong minh họa S3, thủy thủ già nhất có rating bằng 10 là sid=58, tuổi là 35. Tên cácthủy thủ lớn tuổi hơn người này là Bob, Dustin, Horatio, và Lubber. Nếu sử dụng ALL,truy vấn này có thể được viết như sau:

SELECT S.sname FROM Sailors S WHERE S.age > ALL ( SELECTS2.age FROM Sailors S2 WHERE S2.rating = 10 )

Nếu thay ANY bằng ALL thì truy vấn sẽ đưa ra tên những người lớn tuổi hơn một ngườinào đó có rating=10. Việc này sẽ tương đương với việc thay MAX bằng MIN trong truyvấn trên.

Đại số quan hệ và SQL: Hàm nhóm là những hàm không thể biểu diễn được trong đạisố quan hệ. Tương tự, cấu trúc nhóm trong SQL không thể biểu diễn được trong đại số.

Mệnh đề GROUP BY và HAVING

Phần trước, chúng ta đã áp dụng toán tử nhóm tới tất cả các dòng trong quan hệ. Thườngthì chúng ta muốn áp dụng các toán tử nhóm tới một số các dòng trong quan hệ. Ví dụ,xem xét truy vấn sau:

(Q31) Tìm tuổi của các thủy thủ trẻ nhất ứng với từng mức rating.

Nếu chúng ta biết rằng rating là các số nguyên nằm trong khoảng từ 1 đến 10, chúng tasẽ viết 10 truy vấn theo dạng:

SELECT MIN (S.age) FROM Sailors S WHERE S.rating = i

trong đó i=1,2, …, 10. Viết 10 truy vấn như thế thì rất nhàm chán và mệt mỏi. Quantrọng hơn, trên thực tế chúng ta có lẽ không biết có bao nhiêu mức rating tồn tại.

Để viết truy vấn kiểu này, chúng ta cần mở rộng các chức năng cơ bản của dạng câu lệnhSQL cơ bản, như mệnh đề GROUP BY. Trên thực tế, sự mở rộng này cũng bao gồm cảmệnh đề HAVING, là mệnh đề có thể lựa chọn để thêm vào điều kiện của nhóm (ví dụ,chúng ta có thể chỉ đưa ra những mức rating>6). Dạng chung của truy vấn SQL có mởrộng như sau:

175/470

SELECT [ DISTINCT ] select-list FROM from-list WHEREqualification GROUP BY grouping-list HAVING group-qualification

Sử dụng mệnh đề GROUP BY, chúng ta có thể viết Q31 như sau:

SELECT S.rating, MIN (S.age) FROM Sailors S GROUP BYS.rating

Hãy cùng chúng tôi xem xét một số điểm quan trọng liên quan đến các mệnh đề mớinày:

• Cụm Select-list trong mệnh đề SELECT chứa (1) danh sách tên các cột và (2)danh sách các hàm nhóm có dạng aggop (colum-name) AS new-name. Lựachọn AS new-name cung cấp cho cột này một tên mới trong kết quả của truyvấn. Bất kỳ toán tử nhóm nào cũng có thể được sử dụng trong aggop. Tất cảcác cột xuất hiện trong (1) cũng phải xuất hiện trong grouping-list. Lý do làmỗi dòng trong kết quả tương ứng với một nhóm. Nếu một cột xuất hiện trongdanh sách (1), nhưng không xuất hiện trong group-list, thì kết quả của truy vấnsẽ không rõ ràng.

• Các biểu thức xuất hiện trong group-qualification của mệnh đề HAVING phảicó một giá trị duy nhất ứng với mỗi nhóm. Mệnh đề HAVING xác định nhữngdòng kết quả nào của nhóm sẽ được đưa ra. Vì thế, cột xuất hiện trong group-qualification phải là đối số của một hàm nhóm, hoặc nó cũng phải xuất hiệntrong grouping-list.

• Nếu mệnh đề GROUP BY bị bỏ đi, toàn bộ bảng được đề cập đến như là mộtnhóm. Chúng ta sẽ giải thích về mặt ngữ nghĩa của điều này thông qua ví dụ.Xem xét truy vấn:

(Q32) Tìm tuổi của thủy thủ trẻ nhất (ít nhất 18 tuổi) ứng với mỗi mức rating có ít nhấthai thủy thủ.

SELECT S.rating, MIN (S.age) AS minage FROM Sailors SWHERE S.age >= 18 GROUP BY S.rating HAVING COUNT (*) > 1

Chúng ta sẽ đánh giá truy vấn này trong minh họa S3 của Sailors trong Hình 10. Mởrộng chiến lược thực hiện truy vấn ở mức khái niệm đã trình bày trong Phần 2, truy vấnnày thực hiện như sau: Bước đầu tiên là thực hiện phép nhân chéo trên các bảng trongfrom-list. Vì chỉ có một quan hệ trong from-list trong Q23 nên kết quả của phép nhânchéo này chính là quan hệ trong Hình 10.

176/470

Minh họa S3 của Sailors

Bước thứ hai là thực hiện điều kiện trong mệnh đề WHERE, S.age>=18. Bước nàyloại đi dòng <71, Zorba, 10, 16.0>. Bước ba loại đi những cột không mong muốn. Chỉnhững cột được đề cập trong mệnh đề SELECT, mệnh đề GROUP BY, hoặc mệnh đềHAVING là cần thiết, có nghĩa là chúng ta có thể bỏ đi sid và sname trong ví dụ củachúng ta. Kết quả chỉ ra trong Hình 11. Quan sát thấy rằng có hai dòng khác nhau vớirating=3 và age=25, SQL không loại đi những bộ giá trị trùng nhau trừ khi chúng đượcyêu cầu bằng việc sử dụng từ khóa DISTINCT!

Bước thứ 4 là sắp xếp bảng tùy theo mệnh đề GROUP BY để xác định các nhóm. Kếtquả của bước này chỉ ra trong Hình 12.

Kết quả sau Bước 3

177/470

Kết quả sau Bước 4

Bước thứ 5 là áp dụng group-qualification trong mệnh đề HAVING, đó là điều kiệnCOUNT(*)>1. Bước này loại đi những nhóm có rating bằng 1, 9 và 10. Quan sát thấyrằng thứ tự xem xét điều kiện trong mệnh đề WHERE và HAVING rất có ý nghĩa: Nếumệnh đề WHERE không được xem xét đầu tiên, nhóm có rating=10 sẽ có mặt trong kếtquả (mặc dù có một dòng không thỏa mãn điều kiện age>=18). Bước thứ 6 là đưa ramột dòng kết quả ứng một nhóm còn lại. Dòng kết quả ứng với một nhóm chứa tập concủa các cột trong nhóm, cộng với một hoặc nhiều cột trong hàm nhóm. Trong ví dụ củachúng ta, mỗi dòng kết quả có cột rating và minage, cột đã được tính toán bằng cách ápdụng hàm MIN cho cột age. Kết quả của bước này chỉ ra trong Hình 13.

Kết quả cuối cùng của truy vấn

SQL:1999 đã giới thiệu hai hàm tập hợp mới, EVERY và ANY. Để minh họa cho nhữnghàm này, chúng ta có thể thay thế mệnh đề HAVING trong ví dụ của chúng ta bằng

HAVING COUNT(*)>1 AND EVERY(S.age<=60)

Bước thứ 5 của quá trình thực hiện bị thay đổi do những thay đổi trong mệnh đềHAVING. Xem xét kết quả trong bước 4, chỉ ra trong Hình 12. Từ khóa EVERY yêu cầutất cả các dòng trong nhóm phải thỏa mãn điều kiện trong group-qualification. Nhómcó rating=3 không thỏa mãn điều kiện và bị xóa, kết quả chỉ ra trong Hình 14.

Có thể thay thế truy vấn trên bằng truy vấn theo sau, điều kiện của age được đặt lênmệnh đề WHERE thay vì để ở HAVING:

178/470

SELECT S.rating, MIN (S.age) AS minage FROM Sailors SWHERE S.age >= 18 AND S.age<=60 GROUP BY S.rating HAVINGCOUNT (*) > 1

Bây giờ, kết quả sau bước 3 của quá trình thực hiện không chứa dòng có age=63.5. Tuynhiên, nhóm có rating=3 thỏa mãn điều kiện COUNT(*)>1, vì nó vẫn có hai dòng, vàthỏa mãn điều kiện trong group-qualification được kiểm tra trong bước 5. Kết quả cuốicùng của truy vấn này chỉ ra trong Hình 15.

Kết quả sau Bước 3

Kết quả sau Bước 4

Các ví dụ khác của truy vấn sử dụng hàm nhóm

(Q33) Với mỗi tàu màu đỏ, tìm số lượng các phục vụ (reservation) cho từng tàu.

SELECT B.bid, COUNT (*) AS sailorcount FROM Boats B,Reserves R WHERE R.bid = B.bid AND B.color = 'red' GROUPBY B.bid

Trên minh họa B1 và R2, kết quả của truy vấn này chứa hai bộ giá trị ?102, 3? và ?104,2?.

Quan sát thấy rằng cách viết của truy vấn phía sau đây sẽ không hợp lệ:

SELECT B.bid, COUNT (*) AS sailorcount FROM Boats B,Reserves R WHERE R.bid = B.bid GROUP BY B.bid HAVINGB.color = 'red'

Cho dù là group-qualificationB.color='red' là giá trị duy nhất trên mỗi nhóm, vì thuộctính được nhóm bid là khóa của Boats (vì thế xác định được duy nhất màu tương ứng),thì SQL cũng không cho phép truy vấn này. Chỉ những cột xuất hiện trong mệnh đềGROUP BY thì mới được phép xuất hiện trong mệnh đề HAVING, trừ khi nó xuất hiệnnhư là đối số của một hàm nhóm trong mệnh đề HAVING.

179/470

(Q34) Tìm tuổi trung bình của các thủy thủ ứng với mỗi mức rating có ít nhất hai thủythủ.

SELECT S.rating, AVG (S.age) AS avgage FROM Sailors SGROUP BY S.rating HAVING COUNT (*) > 1

Sau khi xác định các nhóm dựa trên rating, chúng ta giữ lại chỉ những những nhóm cóít nhất hai thủy thủ. Kết quả của truy vấn áp dụng trên minh họa S3 được chỉ ra trongHình 16.

Kết quả Q34

Kết quả Q35

Kết quả Q36

Thêm vào một truy vấn con bên trong mệnh đề HAVING của Q34 (cách viết như vớimệnh đề WHERE). Ghi nhớ rằng chúng ta có thể sử dụng S.rating bên trong truy vấncon của mệnh đề HAVING vì nó có một giá trị duy nhất cho nhóm hiện tại của các thủythủ.

SELECT S.rating, AVG ( S.age ) AS avgage FROM Sailors SGROUP BY S.rating HAVING 1 < ( SELECT COUNT (*) FROMSailors S2 WHERE S.rating = S2.rating )

(Q35) Tìm tuổi trung bình của các thủy thủ (ít nhất 18 tuổi) ứng với mỗi mức rating cóít nhất hai thủy thủ.

180/470

SELECT S.rating, AVG ( S.age ) AS avgage FROM Sailors SWHERE S. age >= 18 GROUP BY S.rating HAVING 1 < ( SELECTCOUNT (*) FROM Sailors S2 WHERE S.rating = S2.rating )

Sự khác nhau đối với Q34, chúng ta loại đi những bộ giá trị có age<=18 và nhóm nhữngbộ giá trị còn lại theo rating. Với mỗi nhóm, truy vấn con bên trong mệnh đề HAVINGđưa ra số lượng các bộ giá trị của Sailors (không áp dụng điều kiện lựa chọn age<=18)có giá trị rating bằng với nhóm hiện tại đang xét. Nếu một nhóm có ít hơn hai thủy thủ,nó sẽ bị loại đi. Với mỗi nhóm còn lại, chúng ta đưa ra tuổi trung bình. Kết quả của truyvấn này áp dụng trên minh họa S3 chỉ ra trong Hình 15. Ghi nhớ rằng kết quả này tươngđương với kết quả của truy vấn Q34, chỉ có sự khác nhau ở nhóm có rating = 10, chúngta bỏ đi thủy thủ có age=16 trong khi tính tuổi trung bình.

(Q36) Tìm tuổi trung bình của các thủy thủ (ít nhất 18 tuổi), với mỗi mức rating chỉ ratrong kết quả phải có ít nhất hai thủy thủ.

SELECT S.rating, AVG ( S.age ) AS avgage FROM Sailors SWHERE S. age >18 GROUP BY S.rating HAVING 1 < ( SELECTCOUNT (*) FROM Sailors S2 WHERE S.rating = S2.rating ANDS2.age >= 18 )

Biểu diễn trên của truy vấn đã có sự thay đổi với Q35. Kết quả của truy vấn Q36 trênminh họa S3 chỉ ra trong Hình 16. Nó khác với kết quả của Q35 là không có bộ giá trịrating =10, vì chỉ có một bộ giá trị có rating=10 và age>=18.

Truy vấn Q36 thực sự tương tự với Q32, biểu diễn đơn giản như sau:

SELECT S.rating, AVG ( S.age ) AS avgage FROM Sailors SWHERE S. age > 18 GROUP BY S.rating HAVING COUNT (*) > 1

Phát biểu của truy vấn Q36 chỉ ra thực tế rằng mệnh đề điều kiện trong mệnh đềWHERE được áp dụng trước điều kiện nhóm, vì thế, chỉ những thủy thủ có age>18được đưa vào nhóm. Chúng ta sẽ xem xét cách khác để viết truy vấn này:

SELECT Temp.rating, Temp.avgage FROM ( SELECT S.rating,AVG ( S.age ) AS avgage, COUNT (*) AS ratingcount FROMSailors S WHERE S. age > 18 GROUP BY S.rating ) AS TempWHERE Temp.ratingcount > 1

Sự thay đổi này mang đến một số điểm đáng chú ý. Đầu tiên, mệnh đề FROM có thểchứa truy vấn con, theo chuẩn SQL. Thứ 2, mệnh đề HAVING không phải lúc nào cũngcần. Bất kỳ mệnh đề HAVING nào cũng có thể được viết lại mà không có nó, nhưngrất nhiều truy vấn sẽ đơn giản hơn nếu chúng ta sử dụng HAVING. Cuối cùng, khi một

181/470

truy vấn con xuất hiện trong mệnh đề FROM, sử dụng từ khóa AS để cung cấp cho nómột tên mới khi cần thiết (vì nếu không thì chúng ta không thể biểu diễn được điều kiệnTemp.ratingcount> 1 trong trường hợp này).

(Q37) Tìm những rating mà tuổi trung bình của thủy thủ bằng tuổi trung bình nhỏ nhấttrên tất cả các mức rating.

Chúng ta sử dụng truy vấn này để minh họa rằng các hàm nhóm không thể được lồngnhau. Một cách viết như sau có thể được xem xét:

SELECT S.rating FROM Sailors S WHERE AVG (S.age) = (SELECT MIN (AVG (S2.age)) FROM Sailors S2 GROUP BYS2.rating )

Suy nghĩ một chút cũng thấy rằng truy vấn này không thể thực hiện được cho dù tagiả sử biểu thức MIN(AVG(S2.age)) không hợp lệ được thực hiện. Trong truy vấn con,Sailors được chia vào các nhóm theo rating, và tuổi trung bình được tính trên mỗi nhóm.Với mỗi nhóm, áp dụng MIN trên các giá trị trung bình này sẽ trả lại cùng một giá trị!

Cách viết đúng của truy vấn trên như sau. Là cần thiết để đưa ra một bảng phụ lưu tuổitrung bình trên ứng với mỗi mức rating, sau đó tìm ra rating mà tuổi trung bình là nhỏnhất.

SELECT Temp.rating, Temp.avgage FROM ( SELECT S.rating,AVG (S.age) AS avgage, FROM Sailors S GROUP BY S.rating)AS Temp WHERE Temp.avgage =(SELECT MIN (Temp.avgage) FROMTemp )

Kết quả của truy vấn này trên minh họa S3 là ?10, 25.5?.

Xem như là bài tập, người đọc nên xem xét xem truy vấn sau ra kết quả tương đươngkhông, nếu không thì vì sao không:

SELECT Temp.rating, MIN ( Temp.avgage ) FROM ( SELECTS.rating, AVG (S.age) AS avgage, FROM Sailors S GROUP BYS.rating ) AS Temp GROUP BY Temp.rating

Các giá trị NULL

Ở trên, chúng ta đã giả sử rằng giá trị các cột trong từng dòng đã được biết. Nhưng thựctế, ta sẽ gặp rất nhiều trường hợp mà giá trị này không có. Ví dụ, khi một thủy thủ, nhưDan, tham gia một câu lạc bộ du thuyền, anh ấy có lẽ không cần đăng ký rating củamình.Vì định nghĩa của bảng có cột rating, nên giá trị rating của Dan không biết phải

182/470

thêm gì vào đó. Điều cần làm ở đây là thêm vào đó một giá trị đặc biệt được gọi là giátrị chưa biết. Giả sử định nghĩa bảng Sailors được thêm vào một cột là maiden-name.Tuy nhiên, chỉ có những phụ nữ đã lập gia đình mới có họ của chồng (maiden-name).Với những phụ nữ độc thân và những người đàn ông, giá trị maiden-name sẽ không có.Một lần nữa, chúng ta phải thêm giá trị nào vào cột này cho Dan?

SQL cung cấp một giá trị cột đặc biệt gọi là null cho những trường hợp này. Sử dụngđịnh nghĩa bảng Sailors, chúng ta sẽ nhập vào dòng ?98; Dan; null; 39? để biểu diễnDan, sự hiện diện của giá trị null làm nảy sinh nhiều vấn đề phức tạp, và chúng ta xemxét tác động của giá trị null đối với SQL trong phần này.

Các so sánh sử dụng giá trị Null

Xem xét một so sánh là rating=8. Nếu áp dụng so sánh này cho dòng của Dan, kết quảso sánh sẽ True hay False? Vì rating của Dan không biết, nó là nguyên nhân để có thểnói rằng phép so sánh này có kết quả là unknown. Trên thực tế, so sánh rating>8 vàrating<8 sẽ thực hiện tốt. Nếu chúng ta so sánh hai giá trị null sử dụng >, <, = và nhiềuhơn nữa, kết quả luôn luôn là unknown. Ví dụ, nếu chúng ta có null trong hai dòng phânbiệt của quan hệ Sailor, bất kỳ so sánh nào cũng trả lại kết quả unknown.

SQL cũng cung cấp một phép so sánh đặc biệt IS NULL để kiểm tra giá trị của cột cónull hay không; ví dụ, chúng ta có thể viết rating IS NULL, sẽ trả lại kết quả true trêndòng biểu diễn Dan. Chúng ta cũng có thể viết rating IS NOT NULL, sẽ trả lại kết quảfalse trên dòng biểu diễn Dan.

Các kết nối logic AND, OR, NOT

Bây giờ chúng ta tìm hiểu cách biểu diễn rating = 8 OR age < 40 và rating = 8 ANDage < 40 có nghĩa là gì? Xem xét bản ghi Dan một lần nữa, vì age < 40, biểu thức đầutiên trả lại giá trị True vì chúng ta không cần quan tâm đến rating, nhưng biểu thức thứhai thì sao? Chúng ta chỉ có thể nói là unknown.

Nhưng ví dụ này đưa ra một điểm quan trọng- đó là chúng ta có các giá trị null, chúngta phải định nghĩa các toán tử logic AND, OR, NOT mà kết quả trả về có ba giá trị true,false, và unknown. Chúng ta mở rộng cách hiểu bình thường của AND, OR, NOT đểcó thể bao được những trường hợp khi mà các đối số là unknown như trên. Biểu diễnNOT unknown được định nghĩa như unknown. OR của hai đối số cho kết quả là true nếumột trong hai đối số là true, và unknown nếu một trong các đối số là false và các trườnghợp khác là unknown. (Nếu cả hai đối số là false, thì tất nhiên, kết quả sẽ là false). ANDcủa hai đối số cho kết quả là false nếu một trong hai đối số là false, và unknown nếu mộttrong hai đối số là unknown và những trường hợp khác là true hoặc unknown. (Nếu cảhai đối số là true, kết quả là true).

183/470

Ảnh hưởng đến cấu trúc của SQL

Biểu thức logic xuất hiện trong rất nhiều câu lệnh SQL, và ảnh hưởng của giá trị nullphải được nhận ra. Ví dụ, điều kiện trong mệnh đề WHERE loại đi những dòng (trongphép nhân chéo của các bảng mà tên có ở mệnh đề FROM) mà kết quả kiểm tra điềukiện không trả về giá trị true. Vì thế, nếu có sự hiện diện của giá trị null, bất kỳ dòng nàocho kết quả là false hoặc unknown đều bị loại bỏ. Loại bỏ các dòng có giá trị unknowncó ảnh hưởng rất tinh tế và ý nghĩa trên các truy vấn, đặc biệt đối với các truy vấn concó mệnh đề EXISTS hoặc UNIQUE.

Vấn đề khác khi xuất hiện giá trị null là khi cần xác định hai dòng trong một minh hoạquan hệ có trùng nhau hay không. SQL định nghĩa rằng hai dòng là trùng nhau nếu cáccột tương đương có giá trị bằng nhau, hoặc cả hai đều chứa giá trị null. Đối lập với địnhnghĩa này là thực tế rằng nếu chúng ta so sánh hai giá trị null sử dụng =, kết quả sẽ làunknown! Trong ngữ cảnh của các dòng trùng nhau, so sánh này hoàn toàn được trả lạikết quả true, đó là một điều dị thường.

Như chúng ta mong đợi, các phép toán +, ? , *, và / tất cả trả lại giá tri null nếu mộttrong các đối số là null. Tuy nhiên, nulls có thể gây ra một số điều không mong đợi khithực hiện các phép toán trên tập hợp. COUNT(*) coi giá trị null giống như những giá trịkhác, vì thế, giá trị này vẫn được đếm. Tất cả các toán tử nhóm khác (COUNT, SUM,AVG, MIN, MAX và những biến dạng của khi kết hợp với DISTINCT) hoàn toàn bỏđi những giá trị null- vì thế SUM không được hiểu chỉ là phép cộng trên tất cả các giátrị; bước chuẩn bị ở đây là bỏ đi tất cả các giá trị null phải được đề cập tới. Như là mộttrường hợp đặc biệt, nếu một trong các toán tử này- không phải là COUNT- được ápdụng với chỉ những giá trị null, thì kết quả sẽ trả lại giá trị null.

Phép nối ngoài (Outer joins)

Một số những biến thể của phép nối dựa trên các giá trị null, gọi là phép nối ngoài, đượcSQL hỗ trợ. Xem xét việc nối hai bảng, giả sử Sailors c Reserves. Các bộ giá trị củaSailors không so sánh được với một dòng nào đó trong Reserves theo điều kiện nối sẽkhông xuất hiện trong kết quả. Trong phép nối ngoài thì không phải như vậy.

Trên thực tế, có một vài dạng của phép nối ngoài. LEFT OUTER JOIN trả về tất cả cácdòng có ở quan hệ Sailors, mặc dù các dòng ở Reserves không thỏa mãn phép so sánh.RIGHT OUTER JOIN trả về tất cả các dòng có ở quan hệ Reserves, mặc dù các dòngở quan hệ Sailors không thỏa mãn phép so sánh. FULL OUTER JOIN trả về tất cả cácdòng từ quan hệ Sailors và Reserves mặc dù không thỏa mãn điều kiện so sánh. (Tấtnhiên, những dòng mà thoả mãn điều kiện so sánh luôn luôn xuất hiện trong kết quả, gọilà INNER JOINS, chúng ta đã trình bày trong chương 4).

184/470

SQL cho phép xác định các kiểu nối trong mệnh đề FROM. Ví dụ, truy vấn sau đưa radanh sách ?sid, bid? tương ứng với các thuỷ thủ và các tàu mà họ đã phục vụ:

SELECT Sailors.sid, Reserves.bid FROM Sailors NATURAL LEFTOUTER JOIN Reserves R

Từ khoá NATURAL chỉ ra rằng điều kiện nối là phép nối bằng trên tất cả các thuộc tínhchung (trong ví dụ này là sid), và mệnh đề WHERE không cần thiết (trừ khi chúng tamuốn thêm vào một điều kiện khác). Trên minh hoạ Sailors và Reserves trong Hình 6,truy vấn này đưa ra kết quả trong Hình 17.

Left Outer Join của Sailor1 và Reserves1

Không cho phép các giá trị Null

Chúng ta có thể không cho phép các giá trị null bằng cách chỉ ra NOT NULL khi địnhnghĩa trường, ví dụ, sname CHAR(20) NOT NULL. Thêm nữa, các trường được địnhnghĩa là khoá chính cũng không cho phép các giá trị null. Vì thế, ràng buộc NOT NULLkhông cần phải liệt kê trong các trường là khoá chính.

Khám phá của chúng ta về giá trị null đã hoàn thành. Người đọc nên tìm hiểu thêm trongnhiều cuốn sách về SQL để có thể hiểu chi tiết hơn.

Các ràng buộc phức tạp trong SQL

Trong phần này chúng tôi sẽ trình bày về một số ràng buộc phức tạp, phần này đượcSQL hỗ trợ rất tốt. Các đặc trưng được bàn trong phần này bổ sung cho những ràng buộctham chiếu của SQL đã trình bày ở Chương 3.

Các ràng buộc trên bảng đơn

Chúng ta có thể xác định những ràng buộc trên bảng đơn sử dụng các ràng buộc bảng,có dạng CHECK conditional-expression. Ví dụ, để đảm bảo rằng rating phải ở dạng sốnguyên trong khoảng từ 1 đến 10, chúng ra có thể sử dụng:

CREATE TABLE Sailors (sid INTEGER, sname CHAR(10), ratingINTEGER, age REAL, PRIMARY KEY (sid), CHECK ( rating >= 1AND rating <= 10 ))

185/470

Để thiết đặt ràng buộc rằng, những tàu Interlake không được phục vụ, chúng ta có thểsử dụng:

CREATE TABLE Reserves (sid INTEGER, bid INTEGER, day DATE,FOREIGN KEY (sid) REFERENCES Sailors FOREIGN KEY (bid)REFERENCES Boats CONSTRAINT noInterlakeRes CHECK ('Interlake' <> (SELECT B.bname FROM Boats B WHERE B.bid =Reserves.bid )))

Khi một dòng được thêm vào Reserves hoặc sửa một dòng nào đó đang tồn tại,conditional expression trong ràng buộc CHECK được kiểm tra. Nếu kết quả trả về làfalse, lệnh bị từ chối thực hiện.

Các ràng buộc miền và các kiểu dữ liệu khác

Người dùng có thể định nghĩa miền mới sử dụng câu lệnh CREATE DOMAIN, và ràngbuộc CHECK.

CREATE DOMAIN ratingval INTEGER DEFAULT 0 CHECK ( VALUE >=1 AND VALUE <= 10 )

INTEGER là kiểu dữ liệu cơ bản của miền ratingval, và tất cả giá trị của ratingval phảithuộc kiểu này. Các giá trị trong ratingval được tiếp tục giới hạn sử dụng ràng buộcCHECK; trong định nghĩa ràng buộc này, chúng ta sử dụng từ khóa VALUE để thamchiếu tới giá trị trong miền. Bằng việc sử dụng tiện ích này, chúng ta có thể ràng buộccác giá trị trong miền này sử dụng sức mạnh của các truy vấn SQL. Khi một miền đượcđịnh nghĩa, tên của miền có thể được sử dụng để giới hạn giá trị của các cột trong mộtbảng; chúng ta có thể sử dụng một dòng trong khai báo lược đồ, ví dụ:

rating ratingval

Lựa chọn từ khóa DEFAULT được sử dụng để hỗ trợ giá trị mặc định. Nếu miềnratingval được sử dụng trong một cột của quan hệ, và không có giá trị nào được nhậpcho cột này khi thêm một bộ giá trị mới, giá trị mặc định 0 sẽ được sử dụng. (Nếu mộtgiá trị mặc định được xác định cho một cột trong phần định nghĩa bảng, nó sẽ ưu tiêngiá trị mặc định của miền giá trị). Đặc trưng này có thể được sử dụng để giảm thiểu lỗitrên dữ liệu nhập vào.

SQL hỗ trợ khái niệm giới hạn miền trong một khía cạnh quan trọng. Ví dụ, chúng tacó thể định nghĩa hai miền là Sailorid và Boatclass, mỗi miền sử dụng kiểu dữ liệu cơbản là INTEGER. Mục đích là để thiết đặt một so sánh của giá trị Sailorid và Boatclassđể nó luôn luôn bị lỗi (vì chúng được tạo ra từ các miền khác nhau); tuy nhiên, vì cả hai

186/470

đều có cùng kiểu dữ liệu cơ bản, INTEGER, nên so sánh sẽ thành công trong SQL. Vấnđề này được làm rõ thông qua việc giới thiệu kiểu dữ liệu khác trong SQL:1999.

CREATE TYPE ratingtype AS INTEGER

Câu lệnh này định nghĩa một kiểu dữ liệu mới gọi là ratingtype, với INTEGER là kiểugốc. Giá trị trong kiểu ratingtype có thể so sánh được với nhau, nhưng nó không thể sosánh được với giá trị của các kiểu khác. Đặc biệt, các giá trị của kiểu ratingtype đượcxem như một kiểu riêng khác với kiểu gốc-INTEGER, chúng không thể so sánh hoặckết hợp được với INTEGER (ví dụ, cộng một giá trị kiểu Integer với một giá trị kiểuratingtype). Nếu chúng ta muốn định nghĩa các phép toán trên kiểu mới, ví dụ, hàmAverage, chúng ta phải tự làm điều này một cách tường minh. Chúng ta sẽ bàn đến cáchđịnh nghĩa các hàm trong Phần 23.4.1.

Các xác nhận (assertions): Các ràng buộc trên nhiều bảng

Các ràng buộc bảng liên quan đến một bảng đơn, mặc dù biểu thức điều kiện trong mệnhđề CHECK có thể tham chiếu sang các bảng khác. Các ràng buộc được yêu cầu hoạtđộng chỉ khi các bảng liên quan không rỗng. Vì thế, khi một ràng buộc có sự tham giacủa một hoặc nhiều bảng, cơ chế ràng buộc bảng đôi khi làm cản trở và không thựcsự được mong muốn. Để khống chế những tình trạng này, SQL hỗ trợ để tạo ra cácassertions, là những ràng buộc không liên quan đến bất kỳ bảng cụ thể nào.

Như một ví dụ, giả sử rằng chúng ta hy vọng để thiết đặt ràng buộc là: số lượng của tàucộng với số lượng của thủy thủ nên ít hơn 100. Chúng ta sẽ cố gắng tạo ràng buộc bảngsau:

CREATE TABLE Sailors (sid INTEGER, sname CHAR(10), ratingINTEGER, age REAL, PRIMARY KEY (sid), CHECK ( rating >= 1AND rating <= 10) CHECK ( ( SELECT COUNT (S.sid) FROMSailors S ) + ( SELECT COUNT (B.bid) FROM Boats B ) < 100))

Giải pháp này có hai hạn chế. Nó liên quan đến Sailors, mặc dù nó bao gồm cả Boatstrong định nghĩa. Quan trọng hơn, nếu một bảng Sailors rỗng, ràng buộc này được địnhnghĩa để luôn luôn hoạt động thậm chí cả khi chúng ta có nhiều hơn 100 dòng trênBoats! Chúng ta có thể mở rộng ràng buộc này để thêm vào một kiểm tra đảm bảoSailors không rỗng, nhưng cách tiếp cận này gây nhiều cản trở. Giải pháp tốt nhất là tạora một assertion, như sau:

CREATE ASSERTION smallClub CHECK (( SELECT COUNT (S.sid)FROM Sailors S ) + ( SELECT COUNT (B.bid) FROM Boats B) <100 )

187/470

TRIGGERS và các cơ sở dữ liệu hoạt động

Trigger là một loại thủ tục đặc biệt được thực thi một cách tự động khi có một sự kiệnthay đổi dữ liệu xảy ra như Update, Insert hay Delete. Trigger được dùng để đảm bảoràng buộc dữ liệu, tính nhất quán, hoặc thực hiện các quy tắc dữ liệu phức tạp.

Trigger là đối tượng đặc biệt được tạo trên một bảng và là một phần của cơ sở dữ liệu.Trigger có thể truy vấn tới các bảng khác và có thể bao gồm các câu lệnh SQL phức tạp.Chúng ta có thể tạo trigger cho mỗi hành động trên bảng hoặc có thể kết hợp 2 hoặc 3hành động trong một trigger.

Trigger được DBA xây dựng. Một cơ sở dữ liệu có một tập hợp các trigger được gọi làcơ sở dữ liệu hoạt động. Một trigger gồm 3 phần:

• Sự kiện: Những thay đổi ảnh hưởng tới cơ sở dữ liệu khi trigger hoạt động.• Điều kiện: Một truy vấn hoặc một kiểm tra được thực hiện khi trigger hoạt

động.• Hoạt động: Một thủ tục được thực hiện khi trigger hoạt động và các điều kiện

của nó là đúng.

Một trigger có thể được nghĩ như là một 'daemon' điều khiển một cơ sở dữ liệu, và thựchiện khi cơ sở dữ liệu có sự thay đổi ứng với sự kiện đã xác định.

Một điều kiện của một trigger có thể trả về giá trị True/False (ví dụ, tất cả các nhân viêncó lương ít hơn $100,000) hoặc một truy vấn. Một truy vấn hiểu là true nếu tập kết quảkhông rỗng, và false nếu truy vấn không có kết quả trả về. Nếu phần điều kiện có giá trịtrue, những hành động của trigger được thực hiện.

Một hoạt động có thể kiểm tra kết quả của truy vấn trong một phần điều kiện của trigger,tham chiếu tới các giá trị cũ và mới của những bộ giá trị thay đổi sau khi thực hiệntrigger, thực hiện các truy vấn mới và làm những thay đổi đối với cơ sở dữ liệu. Thực tế,một action có thể thực hiện một chuỗi các câu lệnh định nghĩa dữ liệu (ví dụ, tạo bảngmới, thay đổi quyền của người dùng) và các lệnh hướng-giao dịch (ví dụ, commit), hoặcgọi các thủ tục khác.

Những ví dụ của Trigger trong SQL

Một ví dụ chỉ ra trong Hình 5.20, cú pháp viết trên Oracle 7 để định nghĩa các triggers,minh họa những khái niệm cơ bản của trigger nói trên. (Cú pháp của SQL:1999 chonhững trigger này tương tự như trong Oracle; chúng ta sẽ xem một ví dụ sử dụng cúpháp ngắn gọn của SQL:1999). Một trigger sử dụng init_count để khởi động một biếnđếm trước khi thực hiện câu lệnh INSERT để thêm một bộ giá trị vào quan hệ Students.Trigger dùng biến tự động tăng incr_count để đếm khi có một bộ giá trị được thêm vàothỏa mãn điều kiện age <18.

188/470

CREATE TRIGGER init_count BEFORE INSERT ON Students /* Sựkiện */ DECLARE count INTEGER; BEGIN /* Hành động */ count:= 0; END CREATE TRIGGER incr_count AFTER INSERT ONStudents /* Sự kiện */ WHEN (new.age < 18) /* Điều kiện;'new' là bộ giá trị mới được thêm vào */ FOR EACH ROWBEGIN /* Hành động; một thủ tục nào đó trong Oracle's PL/SQL syntax */ count := count + 1; END

Hình 20. Ví dụ minh hoạ Trigger

Một trong những trigger minh hoạ trong Hình 5.20 thực hiện trước khi câu lệnh thực thi,và minh hoạ khác thực hiện sau. Một trigger có thể cũng được lập lịch thực hiện thay thếcho một câu lệnh, hoặc trong cơ chế hoãn, ở cuối giao dịch ngăn lại một câu lệnh, hoặctrong cơ chế không đồng bộ, nó thực hiện như một phần của một giao dịch riêng biệt.

Trong Hình 20 minh hoạ một điểm khác về thực thi trigger: Người dùng phải xác địnhmột trigger được thực hiện một lần mỗi khi sửa bản ghi hoặc một lần mỗi khi câu lệnhthực thi. Nếu một hoạt động phụ thuộc vào sự thay đổi của các bản ghi riêng lẻ, ví dụ,chúng ta phải kiểm tra trường age khi có một bản ghi Students được thêm vào để quyếtđịnh tăng biến đếm, sự kiện của trigger nên được định nghĩa xảy ra mỗi khi bản ghiđược sửa; mệnh đề FOR EACH ROW được sử dụng để làm điều này. Kiểu trigger nàyđược gọi là row-level trigger. Mặt khác, trigger init_count được thực hiện một lần vớimỗi câu lệnh INSERT, không quan tâm đến số lượng các bản ghi được thêm vào, bởi vìchúng không có mệnh đề FOR EACH ROW. Trigger như thế này được gọi là statement-level trigger.

Trong Hình 20, từ khoá new tham chiếu tới một bộ giá trị mới được thêm vào. Nếu bộgiá trị đang tồn tại được sửa, từ khoá old và new có thể được sử dụng để tham chiếu tớicác giá trị trước và sau khi có sự thay đổi. Bản SQL: 1999 phác thảo cũng cho phép hànhđộng của trigger tham chiếu đến một tập các bản ghi đã thay đổi, không chỉ là thay đổicủa một bản ghi. Ví dụ, thật hữu ích nếu có thể tham chiếu tới một tập các bản ghi mớithêm vào quan hệ Students, những bản ghi được thêm chỉ bằng một câu lệnh INSERT;chúng ta có thể đếm được số bản ghi mới có age<18 thông qua việc sử dụng truy vấntrên tập này. Như trigger được chỉ ra trong Hình 5.21, là trigger bổ sung cho các triggertrong Hình 5.20.

Định nghĩa trong hình 20 sử dụng cú pháp của SQL:1999, để minh hoạ sự tương đồngvà sự khác nhau về cú pháp được sử dụng trong DBMS. Từ khoá NEW TABLE có thểđược chúng ta sử dụng để cung cấp một tên mới cho tập các bộ giá trị mới được thêm.Mệnh đề FOR EACH STATEMENT chỉ ra trigger này là statement-level trigger và cóthể bỏ qua vì nó là mệnh đề mặc định. Định nghĩa này không có mệnh đề WHEN; nếucó mệnh đề này, nó sẽ có mệnh đề FOR EACH STATEMENT theo sau-mệnh đề viếttrước khi xác định các hành động.

189/470

Mỗi trigger được thực hiện một lần với mỗi câu lệnh SQL thêm các bộ giá trị vào bảngStudents, và việc thêm từng bộ giá trị duy nhất vào bảng được thống kê lại. Hai trườngđầu tiên của bộ giá trị chứa các hằng số (chỉ ra bảng được thay đổi là Students và loạithay đổi là Insert), và trường thứ ba là số lượng các bộ giá trị được thêm vào có age<18.(Trigger trong Hình 5.20 chỉ thực hiện việc đếm; trigger bổ sung được yêu cầu để thêmbộ giá trị phù hợp vào bảng thống kê).

CREATE TRIGGER set_count AFTER INSERT ON Students /* Event*/ REFERENCING NEW TABLE AS InsertedTuples FOR EACHSTATEMENT INSERT /* Action */ INTOStatisticsTable(ModifiedTable, ModificationType, Count)SELECT 'Students', 'Insert', COUNT * FROM InsertedTuples IWHERE I.age < 18

Hình 20. Set-Oriented Trigger

Thiết kế cơ sở dữ liệu hoạt động

Trigger được coi là cơ chế mạnh mẽ để đối mặt với những thay đổi trên cơ sở dữ liệu,nhưng chúng phải được sử dụng hợp lý. Ảnh hưởng của tập hợp các trigger có thể rấtphức tạp, và bảo trì các cơ sở dữ liệu hoạt động trở nên rất khó khăn. Thường thì, sửdụng sáng suốt những ràng buộc tham chiếu có thể thay thế được trigger.

Vì sao trigger khó hiểu

Trong một hệ thống cơ sở dữ liệu hoạt động, khi DBMS thực hiện một câu lệnh sửa đổidữ liệu trong cơ sở dữ liệu, nó kiểm tra một số trigger được kích hoạt khi câu lệnh nàythực hiện. DBMS thực hiện các trigger bằng việc xem xét các điều kiện của nó và sauđó thực hiện chúng (nếu kết quả kiểm tra điều kiện là True).

Nếu một câu lệnh làm kích hoạt nhiều hơn một trigger, DBMS sẽ lần lượt thực hiệnchúng theo thứ tự ưu tiên. Một điểm quan trọng là trong quá trình thực hiện trigger cóthể làm kích hoạt những trigger khác. Đặc biệt, khi một trigger thực hiện có thể kíchhoạt chính bản thân nó, những trigger như thế gọi là các trigger đệ quy. Phản ứng dâytruyền, và thứ tự không thể đoán trước được khi DBMS xử lý các trigger được kích hoạtlàm cho những ảnh hưởng của tập các trigger trở nên khó hiểu.

Khác nhau giữa các ràng buộc và Triggers

Mục đích của trigger là đảm bảo sự nhất quán của cơ sở dữ liệu, và với mục đích này,chúng ta nên xem xét đến việc sử dụng các ràng buộc tham chiếu (ví dụ, ràng buộc khoángoại). Ràng buộc không tự động kích hoạt như trigger nên các ràng buộc dễ để hiểu vàcũng cung cấp cho DBMS nhiều cơ hội để tối ưu hoá việc thực hiện. Ràng buộc cũng

190/470

tránh cho dữ liệu trở nên thiếu nhất quán với bất kỳ loại câu lệnh nào, ngược lại triggerchỉ kích hoạt ứng với một loại câu lệnh xác định (ví dụ, câu lệnh Insert hoặc Delete).Một lần nữa, ta thấy giới hạn này làm cho ràng buộc dễ hiểu hơn.

Mặt khác, trigger cho phép chúng ta thực hiện các ràng buộc cơ sở dữ liệu bằng nhiềucách phức tạp, như những ví dụ minh sau đây:

• Giả sử rằng chúng ta có một bảng Orders có các trường itemid, quantity,customerid, và unitprice. Khi một khách hàng đặt một hoá đơn, giá trị batrường đầu tiên được điền vào bằng người dùng (ví dụ là người bán hàng). Giátrị trường thứ tư có thể được lấy từ một bảng có tên là Items, nhưng nó cần thiếtphải có mặt trong bảng Orders để có được một bản ghi hoàn thiện về sự kiệnđặt hàng. Trong trường hợp giá của một Item sau đó thay đổi, chúng ta có thểđịnh nghĩa một trigger để tìm giá trị này và đưa nó vào trường thứ tư khi cómột bản ghi mới được thêm. Thêm nữa, việc giảm số lượng các trường màngười bán hàng phải nhập vào sẽ làm giảm nguy cơ dẫn đến không nhất quándữ liệu, vì người bán hàng có thể nhập sai giá làm cho nó khác với giá lưutrong cơ sở dữ liệu.

• Tiếp tục với ví dụ trên, chúng ta có lẽ muốn thực hiện một số hoạt động kháckhi một hoá đơn được nhận. Ví dụ, nếu chúng ta thanh toán qua tài khoản thìchúng ta muốn kiểm tra xem tổng số tiền cần phải trả có nhỏ hơn giới hạnthanh toán của thẻ không. Chúng ta có thể sử dụng trigger để kiểm tra; thực tế,chúng ta thậm chí có thể sử dụng ràng buộc CHECK. Tuy nhiên, sử dụngtrigger cho phép chúng ta thực hiện nhiều ràng buộc phức tạp hơn. Trongtrường hợp này, chúng ta có thể cho phép thanh toán số tiền vượt quá 10% khảnăng của thẻ nếu khách hàng có quan hệ với công ty ít nhất một năm, và thêmkhách hàng vào một bảng của các ứng cử viên cần được tăng thêm giới hạn thẻ.

Những khả năng khác của Triggers

Rất nhiều khả năng tiềm ẩn của Trigger dựa trên các ràng buộc dữ liệu. Trigger có thểđược sử dụng để đáp ứng các yêu cầu không thường xuyên. Ví dụ, chúng ta có thể muốnkiểm tra những khách hàng đã mua hàng và thanh toán đầy đủ trong một tháng trước đâyđể khuyến mại giảm giá, nếu như thế, người bán hàng phải thông báo với khách hàng vàyêu cầu cung cấp thông tin (các hoá đơn mua hàng). Chúng ta có thể thực hiện điều nàybằng việc sử dụng một trigger để kiểm tra các hoá đơn thanh toán gần đây.

Các trigger có thể sinh ra một 'lịch sử' ghi lại các sự kiện để hỗ trợ các kiểm tra bảo đảman toàn. Ví dụ, mỗi lần khách hàng đặt một hoá đơn, chúng ta tạo ra một bản ghi có Mãkhách hàng và giới hạn thanh toán của thẻ, và thêm bản ghi này vào bảng Lịch sử kháchhàng. Sau đó, phân tích bảng này để đưa ra đề nghị những khách hàng nào nên đượctăng giới hạn thanh toán của thẻ (ví dụ, khách hàng không bao giờ thanh toán hoá đơnsai hạn và có ít nhất ba lần số tiền cần thanh toán vượt quá giới hạn của thẻ).

191/470

Trong ví dụ minh hoạ ở 8, chúng ta có thể sử dụng các trigger để tập hợp các thốngkê trên bảng được truy cập và thay đổi. Một vài hệ thống cơ sở dữ liệu thậm chí sửdụng trigger bên trong như một phần cơ bản để quản lý các mô hình của quan hệ (Phần22.11.1). Danh sách các khả năng của triggers không thể liệt kê thấu đáo, ví dụ, cáctrigger cũng thường được đề cập đến khi cần quản lý luồng công việc và thiết đặt cácquy tắc quản lý.

Câu hỏi ôn tập

Câu trả lời của các câu hỏi tổng kết sau có thể được tìm thấy trong phần tương ứng:

• Các thành phần của SQL cơ bản? (Phần 2)• Biến miền trong SQL là gì? Làm thế nào để bạn có thể đặt tên cho các cột của

bảng kết quả truy vấn? Những hỗ trợ của SQL để so sánh các xâu ký tự? (Phần2)

• Các phép toán SQL cung cấp trên tập (nhiều tập) các bộ giá trị, và chúng đượcsử dụng như thế nào khi viết truy vấn. (Phần 3)

• Truy vấn lồng nhau là gì? Truy vấn lồng nhau liên kết là gì? Sử dụng các toántử IN, EXISTS, UNIQUE, ANY, và ALL được sử dụng như thế nào trong cáctruy vấn lồng nhau? Vì sao chúng hữu dụng? Minh hoạ câu trả lời của bạn bằngviệc viết phép toán chia trong SQL. (Phần 4)

• Những hàm nhóm nào được SQL hỗ trợ? (Phần 2)• Nhóm là gì? Giải thích đặc trưng này và thảo luận về cách thực hiện trong

mệnh đề HAVING và WHERE. Đề cập những giới hạn mà các trường xuấthiện trong mệnh đề GROUP BY phải tuân theo. (Phần 5)

• Giá trị Null là gì? Chúng có được hỗ trợ trong mô hình quan hệ (trình bày trongChương 3)? Chúng ảnh hưởng đến truy vấn thế nào? Trường là khoá chính củabảng có được phép chứa giá trị Null hay không? (Phần 6)

• Các loại ràng buộc SQL nào có thể được xác định bằng việc sử dụng ngôn ngữtruy vấn? Có thể biểu diễn các ràng buộc khoá chính sử dụng một trong các loạiràng buộc mới này. Nếu có thì tại sao SQL lại cung cấp cho ràng buộc khoáchính một cú pháp riêng. (Phần 7)

• Trigger là gì và ba phần của nó là gì? Sự khác nhau giữa các row-level triggersvà statement-level triggers là gì? (Phần 8)

• Vì sao trigger khó hiểu? Giải thích sự khác nhau giữa trigger và ràng buộc vàkhi nào sử dụng trigger thay vì ràng buộc và ngược lại. Trigger được sử dụngcho những mục đích nào? (Phần 9)

Bài tập

Những vấn đề liên quan đến tất cả bài tập trong chương này có thể tìm thấy trên trangWeb: http://www.cs.wisc.edu/~dbbook

192/470

Trang Web này chứa thông tin về các scripts để tạo bảng cho các ví dụ chạy trên các hệquản trị cơ sở dữ liệu Oracle, IBM DB2, Microsoft SQL Server và MySQL.

Xem xét các lược đồ quan hệ sau: Student(snum: integer, sname: string, major: string,level: string, age: integer) Class(name: string, meets_ at: time, room: string, fid:integer)Enrolled(snum: integer, cname: string)Faculty(fid: integer, fname: string,deptid: integer)Ý nghĩa của các quan hệ này rất dễ hiểu, Enrolled (Đăng ký) có một bảnghi ứng với mỗi cặp Student-Class (Sinh viên-Lớp) khi sinh viên đăng ký học trong mộtlớp. Viết các truy vấn sau bằng SQL. Những bộ giá trị trùng nhau không được xuất hiệntrong kết quả của truy vấn.

• Tìm tên của tất cả các sinh viên có (Level=JR) đã đăng ký lớp học do giáo viênI.Teach dạy.

• Tìm tuổi của sinh viên lớn tuổi nhất hoặc có Major là History hoặc đã đăng kýtrong lớp học do I.Teach dạy.

• Tìm tên của tất cả các lớp hoặc có meet_at ở phòng R128 hoặc có trên nămsinh viên tham gia.

• Tìm tên của tất cả các sinh viên đã đăng ký tham gia trong hai lớp có giờ họctrùng nhau.

• Đưa ra các level và tuổi trung bình của các sinh viên ở level này.• Đưa ra các level và tuổi trung bình của các sinh viên ở level này, trừ level là

JR.• Tìm tên của các sinh viên đã đăng ký nhiều lớp học nhất.• Tìm tên của sinh viên chưa đăng ký lớp học nào.• Với mỗi giá trị tuổi (age) xuất hiện trong bảng Students, tìm giá trị xuất hiện

level xuất hiện thường xuyên nhất. Ví dụ, nếu ứng với tuổi 18, có nhiều sinhviên ở level là FR hơn là ở mức SR, JR, hoặc SO, thì một cặp kết quả sẽ là (18,FR).

Trả lời: Câu trả lời của từng câu hỏi như sau:

1. SELECT DISTINCT S.Sname FROM Student S, Class C,Enrolled E, Faculty F WHERE S.snum = E.snum AND E.cname =C.name AND C.fid = F.fid AND F.fname = ‘I.Teach’ ANDS.level = ‘JR’ 2. SELECT MAX(S.age) FROM Student S WHERE(S.major = ‘History’) OR S.snum IN ( SELECT E.snum FROMClass C, Enrolled E, Faculty F WHERE E.cname = C.name ANDC.fid = F.fid AND F.fname = ‘I.Teach’ ) 3. SELECT C.nameFROM Class C WHERE C.room = ‘R128’ OR C.name IN (SELECTE.cname FROM Enrolled E GROUP BY E.cname HAVING COUNT (*)>= 5) 4. SELECT DISTINCT S.sname FROM Student S WHERES.snum IN (SELECT E1.snum FROM Enrolled E1, Enrolled E2,Class C1,Class C2 WHERE E1.snum = E2.snum AND E1.cname<>

193/470

E2.cname AND E1.cname = C1.name AND E2.cname = C2.name ANDC1.meets_at=C2.meets_at) 5. SELECT DISTINCT F.fname FROMFaculty F WHERE NOT EXISTS (( SELECT * FROM Class C )EXCEPT (SELECT C1.room FROM Class C1 WHERE C1.fid = F.fid)) 6. SELECT DISTINCT F.fname FROM Faculty F WHERE 5 > (SELECT COUNT (E.snum) FROM Class C, Enrolled E WHEREC.name = E.cname AND C.fid = F.fid) 7. SELECT S.level,AVG(S.age) FROM Student S GROUP BY S.level 8. SELECTS.level, AVG(S.age) FROM Student S WHERE S.level <> ‘JR’GROUP BY S.level 9. SELECT F.fname, COUNT(*) ASCourseCount FROM Faculty F, Class C WHERE F.fid = C.fidGROUP BY F.fid, F.fname HAVING EVERY ( C.room = ‘R128’ )10. SELECT DISTINCT S.sname FROM Student S WHERE S.snum IN(SELECT E.snum FROM Enrolled E GROUP BY E.snum HAVINGCOUNT (*) >= ALL (SELECT COUNT (*) FROM Enrolled E2 GROUPBY E2.snum )) 11. SELECT DISTINCT S.sname FROM Student SWHERE S.snum NOT IN (SELECT E.snum FROM Enrolled E ) 12.SELECT S.age, S.level FROM Student S GROUP BY S.age,S.level, HAVING S.level IN ( SELECT S1.level FROM StudentS1 WHERE S1.age = S.age GROUP BY S1.level, S1.age HAVINGCOUNT (*) >= ALL( SELECT COUNT (*) FROM Student S2 WHEREs1.age = S2.age GROUP BY S2.level, S2.age))

Xem xét các lược đồ quan hệ sau:

Suppliers(sid: integer, sname: string, address: string)

Parts(pid: integer, pname: string, color: string)

Catalog(sid: integer, pid: integer, cost: real)

Quan hệ Danh mục (Catalog) liệt kê danh sách các giá các sản phẩm (Parts) của các nhàcung cấp (Suppliers). Viết các truy vấn sau bằng SQL:

• Tìm các pname của các sản phẩm có một vài nhà cung cấp.• Tìm các sname của các nhà cung cấp cung cấp tất cả các sản phẩm.• Tìm các sname của các nhà cung cấp đã cung cấp tất cả các sản phẩm màu đỏ.• Tìm các pname của các sản phẩm được cung cấp chỉ bởi Acme Widget

Suppliers.• Tìm các sid của các nhà cung cấp giao sản phẩm với giá đắt hơn giá trung bình

của tất cả các nhà cung cấp cung cấp sản phẩm đó.

194/470

• Với mỗi sản phẩm, tìm sname của các nhà cung cấp bán sản phẩm này với giáđắt nhất.

• Tìm các sid của nhà cung cấp chỉ cung cấp các sản phẩm màu đỏ.• Tìm các sid của các nhà cung cấp cung cấp một sản phẩm màu đỏ và một sản

phẩm màu xanh.• Tìm sid của các nhà cung cấp cung cấp một sản phẩm màu đỏ hoặc một sản

phẩm màu xanh.• Với tất cả các nhà cung cấp chỉ cung cấp các sản phẩm màu xanh, in ra tên của

các nhà cung cấp và tổng số sản phẩm mà nhà cung cấp này cung cấp.• Với tất cả các nhà cung cấp cung cấp một sản phẩm màu đỏ và một sản phẩm

màu xanh, in ra tên và giá sản phẩm đắt nhất mà nhà cung cấp đó cung cấp.

Trả lời: Dành cho độc giả

Các quan hệ sau đây lưu lại thông tin về các chuyến bay của hãng hàng không:

Flights(flno: integer, from: string, to: string, distance: integer,

departs: time, arrives: time, price: integer)

Aircraft(aid: integer, aname: string, cruisingrange: integer)

Certified(eid: integer, aid: integer)

Employees(eid: integer, ename: string, salary: integer)

Các quan hệ Employees mô tả các phi công và các loại nhân viên khác; tất cả các phicông được chứng nhận trên một số loại máy bay (aircraft) (nếu không có, cô/anh ấykhông được coi là phi công), và chỉ những phi công được chứng nhận mới được phépbay. (Những truy vấn này sử dụng cùng một lược đồ đã được liệt kê ở Chương 4)

• Tìm tên của những loại máy bay mà tất cả các phi công điều hành chúng đều cóthu nhập trên 80,000.

• Với mỗi phi công có chứng nhận bay trên nhiều hơn ba loại máy bay, tìm eidvà cruisingrange lớn nhất của loại máy bay mà phi công đó có chứng nhận.

• Tìm tên của các phi công có lương ít hơn giá rẻ nhất của đường bay từ LosAngeles tới Honolulu.

• Với tất cả các loại máy bay có cruisingrange trên 1000 dặm (miles), tìm têncủa loại máy bay và lương trung bình của tất cả các phi công được chứng nhậntrên loại máy bay này.

• Tìm tên của các phi công được chứng nhận trên một vài loại máy Boeing.• Tìm các aid của tất cả các hãng bay có thể được sử dụng trên đường bay từ Los

Angeles tới Chicago.

195/470

• Xác định các chuyến bay có thể được điều khiển bằng tất cả các phi công cóthu nhập trên $100,000.

• In ra ename của các phi công có thể điều khiển các loại máy bay cócruisingrange lớn hơn 3000 dặm, nhưng không được chứng nhận trên loại máybay boeing.

• Hành khách muốn đi du lịch từ Madison tới New York mà không chuyển máybay hơn hai lần. Liệt kê các lựa chọn thời gian khởi hành từ Madison nếu hànhkhách muốn tới New York lúc 6 p.m.

• Tính toán sự khác nhau giữa lương trung bình của một phi công và lương trungbình của tất cả các nhân viên (gồm cả phi công).

• In ra tên và lương của tất cả các nhân viên không phải là phi công, người mà cólương hơn lương trung bình của các phi công.

• In ra tên của các nhân viên có chứng nhận chỉ trên các loại máy bay cócruisingrange lớn hơn 1000 dặm.

• In ra tên của các nhân viên có chứng nhận chỉ trên các loại máy bay cócruisingrange lớn hơn 1000 dặm, nhưng trên ít nhất hai loại máy bay như vậy.

• In ra tên của các nhân viên có chứng nhận chỉ trên các loại máy bay cócruisingrange lớn hơn 1000 dặm và người đó được chứng nhận trên một vàiloại máy bay Boeing.

Câu trả lời của từng câu hỏi như sau:

1. SELECT DISTINCT A.aname FROM Aircraft A WHERE A.Aid IN(SELECT C.aid FROM Certified C, Employees E WHERE C.eid =E.eid AND NOT EXISTS ( SELECT * FROM Employees E1 WHEREE1.eid = E.eid AND E1.salary<80000)) 2. SELECT C.eid, MAX(A.cruisingrange) FROM Certified C, Aircraft A WHERE C.aid= A.aid GROUP BY C.eid HAVING COUNT (*) > 3 3. SELECTDISTINCT E.ename FROM Employees E WHERE E.salary < (SELECT MIN (F.price) FROM Flights F WHERE F.from = ‘LosAngeles’ AND F.to = ‘Honolulu’ ) 4. Quan sát rằng aid làkhoá của Aircraft, nhưng đề bài yêu cầu aname; chúng tađối mặt với sự phức tạp này bằng cách sử dụng một quan hệTemp trung gian. SELECT Temp.name, Temp.AvgSalary FROM (SELECT A.aid, A.aname AS name, AVG (E.salary) AS AvgSalaryFROM Aircraft A, Certified C, Employees E WHERE A.aid =C.aid AND C.eid = E.eid AND A.cruisingrange > 1000 GROUPBY A.aid, A.aname ) AS Temp 5. SELECT DISTINCT E.enameFROM Employees E, Certified C, Aircraft A WHERE E.eid =C.eid AND C.aid = A.aid AND A.aname LIKE ‘Boeing%’ 6.SELECT A.aid FROM Aircraft A WHERE A.cruisingrange > (SELECT MIN (F.distance) FROM Flights F WHERE F.from = ‘Los

196/470

Angeles’ AND F.to =‘Chicago’) 7. SELECT DISTINCT F.from,F.to FROM Flights F WHERE NOT EXISTS ( SELECT * FROMEmployees E WHERE E.salary > 100000 AND NOT EXISTS (SELECT* FROM Aircraft A, Certified C WHERE A.cruisingrange >F.distance AND E.eid = C.eid AND A.aid = C.aid) ) 8.SELECT DISTINCT E.ename FROM Employees E WHERE E.eid IN (( SELECT C.eid FROM Certified C WHERE EXISTS ( SELECTA.aid FROM Aircraft A WHERE A.aid = C.aid ANDA.cruisingrange > 3000 ) AND NOT EXISTS ( SELECT A1.aidFROM Aircraft A1 WHERE A1.aid = C.aid AND A1.aname LIKE‘Boeing%’ )) 9.SELECT F.departs FROM Flights F WHEREF.flno IN (( SELECT F0.flno FROM Flights F0 WHERE F0.from= ‘Madison’ AND F0.to = ‘New York’ AND F0.arrives<‘18:00’) UNION ( SELECT F0.flno FROM Flights F0, Flights F1 WHEREF0.from = ‘Madison’ AND F0.to <> ‘New York’ AND F0.to =F1.from AND F1.to = ‘New York’ AND F1.departs > F0.arrivesAND F1.arrives < ‘18:00’ ) UNION ( SELECT F0.flno FROMFlights F0, Flights F1, Flights F2 WHERE F0.from =‘Madison’ AND F0.to = F1.from AND F1.to = F2.from ANDF2.to = ‘New York’ AND F0.to <> ‘New York’ AND F1.to <>‘New York’ AND F1.departs > F0.arrives AND F2.departs >F1.arrives AND F2.arrives < ‘18:00’ )) 10. SELECTTemp1.avg- Temp2.avg FROM (SELECT AVG (E.salary) AS avgFROM Employees E WHERE E.eid IN (SELECT DISTINCT C.eidFROM Certified C )) AS Temp1, (SELECT AVG (E1.salary) ASavg FROM Employees E1 ) AS Temp2 11. SELECT E.ename,E.salary FROM Employees E WHERE E.eid NOT IN ( SELECTDISTINCT C.eid FROM Certified C ) AND E.salary > ( SELECTAVG (E1.salary) FROM Employees E1 WHERE E1.eid IN ( SELECTDISTINCT C1.eid FROM Certified C1 ) ) 12.SELECT E.enameFROM Employees E, Certified C, Aircraft A WHERE C.aid =A.aid AND E.eid = C.eid GROUP BY E.eid, E.ename HAVINGEVERY (A.cruisingrange > 1000) 13. SELECT E.ename FROM3Employees E, Certified C, Aircraft A WHERE C.aid = A.aidAND E.eid = C.eid GROUP BY E.eid, E.ename HAVING EVERY(A.cruisingrange > 1000) AND COUNT (*) > 1 14. SELECTE.ename FROM Employees E, Certified C, Aircraft A WHEREC.aid = A.aid AND E.eid = C.eid GROUP BY E.eid, E.enameHAVING EVERY (A.cruisingrange > 1000) AND ANY (A.aname =’Boeing’)

197/470

Xem xét các lược đồ quan hệ sau. Một nhân viên có thể làm việc cho nhiều phòng;trường pct_ time của quan hệ Works chỉ ra tỷ lệ thời gian mà nhân viên đó làm việc chocác phòng khác nhau.

Emp(eid: integer, ename: string, age: integer, salary: real)

Works(eid: integer, did: integer, pct_time: integer)

Dept(did: integer, budget: real, managerid: integer)

Viết các truy vấn sau sử dụng SQL:

• In ra tên và tuổi của từng nhân viên làm việc cho cả hai phòng Hardware vàSoftware.

• Với mỗi phòng có nhiều hơn 20 nhân viên yêu cầu làm việc toàn bộ thời gian,in ra did và số lượng nhân viên làm việc cho phòng đó.

• In ra tên của mỗi nhân viên có lương vượt quá budget (quỹ) của tất cả cácphòng mà người đó làm việc.

• Tìm managerids của các người quản lý chỉ quản lý những phòng có budgetslớn hơn $1,000,000.

• Tìm ename của những người quản lý quản lý một phòng có budget lớn nhất.• Nếu một người quản lý nào đó quản lý nhiều hơn một phòng, người đó điều

khiển tổng số tất cả các budget của các phòng này. Tìm managerids của nhữngngười quản lý điều khiển nhiều hơn $5,000,000.

• Tìm managerids của các nhà quản lý điều khiển lượng budgets lớn nhất.• Tìm ename của những người quản lý chỉ quản lý những phòng có budgets lớn

hơn $1,000,000, nhưng có ít nhất một phòng có budgets nhỏ hơn $5,000,000.

Trả lời: Dành cho độc giả

Xem xét minh hoạ của quan hệ Sailors

• Viết các truy vấn SQL để đưa ra rating trung bình (sử dụng AVG); tổng sốrating (sử dụng SUM), và số lượng các rating (sử dụng COUNT).

• Nếu bạn chia tổng số trên (sum) cho số lượng (count), kết quả có tương tự nhưtính trung bình không? Câu trả lời của bạn thay đổi như thế nào nếu ta áp dụngnhững tính toán trên trường age thay vì trường rating.

• Xem xét truy vấn sau: Tìm tên các thuỷ thủ có rating cao hơn tất cả các thuỷthủ có age<21. Hai truy vấn SQL sau cố gắng để thực hiện yêu cầu này. Chúngcó cùng một kết quả không? Nếu không, giải thích vì sao?

SELECT S.sname FROM Sailors S WHERE NOT EXISTS(SELECT *FROM Sailors S2 WHERE S2.age < 21AND S.rating <= S2.rating

198/470

) SELECT * FROM Sailors S WHERE S.rating > ANY(SELECTS2.rating FROM Sailors S2 WHERE S2.age < 21 )

• Xem xét minh hoạ Sailor. Cùng chúng tôi định nghĩa minh hoạ S1 của Sailorsđể chứa hai bộ giá trị đầu tiên, minh hoạ S2 để nó chứa hai bộ giá trị cuối cùngvà S là minh hoạ trên.

1. Chỉ ra kết quả thực hiện phép left outer join của S với chính bản thân nó, vớiđiều kiện nối là sid=sid.

2. Chỉ ra kết quả thực hiện phép right outer join của S với chính bản thân nó, vớiđiều kiện nối là sid=sid.

3. Chỉ ra kết quả thực hiện phép full outer join của S với chính bản thân nó, vớiđiều kiện nối là sid=sid.

4. Chỉ ra kết quả thực hiện phép left outer join của S1 với S2, với điều kiện nối làsid=sid.

5. Chỉ ra kết quả thực hiện phép right outer join của S1 với S2, với điều kiện nốilà sid=sid.

6. Chỉ ra kết quả thực hiện phép full outer join của S1 với S2, với điều kiện nối làsid=sid.

Trả lời: Dành cho độc giả

Trả lời những câu hỏi sau:

• Giải thích cụm từ impedance mismatch trong ngữ cảnh nhúng các lệnh SQLtrong ngôn ngữ lập trình trên máy trạm như C.

• Bằng cách nào giá trị của biến trong ngôn ngữ lập trình có thể được gán cholệnh SQL nhúng trong đó.

• Giải thích cách sử dụng câu lệnh WHENEVER trong nắm bắt lỗi và trường hợpngoại lệ.

• Giải thích sự cần thiết của con trỏ.• Cung cấp ví dụ của một trường hợp cần thiết phải sử dụng câu lệnh SQL

nhúng, vì nhiều khi chỉ sử dụng câu lệnh SQL không đủ và cần thiết phải sửdụng ngôn ngữ lập trình.

• Viết một chương trình C cùng với các câu lệnh SQL nhúng để cụ thể ví dụ củabạn trong những câu trả lời trước.

• Viết một chương trình C cùng với các câu lệnh SQL nhúng để tìm độ lệchchuẩn của tuổi các cầu thủ.

• Giải thích những cụm từ sau liên quan tới con trỏ: updatability, sensitivity, vàscrol-lability

• Định nghĩa một con trỏ trên quan hệ Sailors có khả năng cập nhật (updatable),cuộn (scrollable), và trả về kết quả được sắp xếp theo age.

• Cung cấp một ví dụ về trường hợp cần thiết sử dụng dynamic SQL, đó là, thậmchí SQL nhúng không hiệu quả.

199/470

Trả lời: Dành cho độc giả

Xem xét lược đồ quan hệ sau và trả lời tóm tắt các câu hỏi:

Emp(eid: integer, ename: string, age: integer, salary: real)

Works(eid: integer, did: integer, pct_time: integer)

Dept(did: integer, budget: real, managerid: integer)

• Định nghĩa ràng buộc bảng trên Emp để đảm bảo tất cả các nhân viên có lươngít nhất $10,000.

• Định nghĩa ràng buộc bảng trên Dept để đảm bảo rằng tất cả người quản lý cóage>30.

• Định nghĩa một xác nhận (assertion ) trên Dept để đảm bảo tất cả các ngườiquản lý đều có age>30. So sánh xác nhận này với ràng buộc tương đương trênbảng. Giải thích cái nào tốt hơn.

• Viết các câu lệnh SQL để xoá tất cả các thông tin về các nhân viên có lươngvượt quá lương của người quản lý. Đảm bảo rằng tất cả các ràng buộc liên quanphải thoả mãn sau những cập nhật của bạn.

Trả lời: Dành cho độc giả

Xem xét các lược đồ quan hệ sau:

Student(snum: integer, sname: string, major: string, level: string, age: integer)

Class(name: string, meets_ at: time, room: string, fid: integer)

Enrolled(snum: integer, cname: string)

Faculty(fid: integer, fname: string, deptid: integer)

Ý nghĩa của những lược đồ quan hệ này rất dễ hiểu; ví dụ; Enrolled có một bản ghi ứngvới mỗi cặp Student-Class khi có một sinh viên đăng ký vào một lớp học.

1. Viết các câu lệnh SQL để tạo các lược đồ quan hệ trên, bao gồm cả những yêucầu ràng buộc khoá chính và khoá ngoại.

2. Trình bày từng ràng buộc tham chiếu sau trong SQL nếu nó không là các ràngbuộc khoá chính và khoá ngoại. Nếu ràng buộc không biểu diễn được bằngSQL, hãy trả lời tại sao.

1. Tất cả các lớp có ít nhất 5 sinh viên và nhiều nhất 30 sinh viên đăng ký.2. Có ít nhất một lớp học trong một phòng.3. Tất cả các giáo viên phải dạy ít nhất hai khoá học.

200/470

4. Chỉ những giáo viên trong bộ môn (Department) có deptid=33 dạynhiều hơn ba khoá học.

5. Tất cả sinh viên phải đăng ký khoá học có tên là Math 101.6. Lớp được lập lịch sớm nhất (tức là, lớp có giá trị meet_at nhỏ nhất)

không nên cùng phòng với lớp được lập lịch muộn nhất.7. Hai lớp không được học cùng một phòng tại một thời điểm.8. Bộ môn có nhiều giáo viên nhất phải có số giáo viên gấp đôi bộ môn có

ít giáo viên nhất.9. Không có bộ môn nào có nhiều hơn 10 giáo viên.

10. Một sinh viên không được thêm nhiều hơn hai khoá học một lúc.11. Số lượng các chuyên ngành (majors) CS phải nhiều hơn chuyên ngành

Math.12. Số lượng các khoá học khác nhau được sinh viên chuyên ngành CS

đăng ký nhiều hơn số lượng các khoá học khác nhau được sinh viênchuyên ngành Math đăng ký.

13. Tổng số các đăng ký trong các khoá học được dạy bằng giáo viên trongbộ môn có Depid=33 nhiều hơn số lượng của các sinh viên chuyênngành Math.

14. Phải có ít nhất một sinh viên chuyên ngành CS nếu như bảng Studentscó sinh viên.

15. Các giáo viên của các bộ môn khác nhau không thể dạy trong cùng mộtphòng.

Trả lời: Dành cho độc giả

Thảo luận về ưu điểm và nhược điểm của cơ chế Trigger. Sự khác nhau giữa ràng buộctham chiếu và trigger.

Trả lời: Dành cho độc giả

Xem xét các lược đồ quan hệ sau. Một nhân viên có thể làm việc cho nhiều phòng;trường pct_ time của quan hệ Works chỉ ra tỷ lệ thời gian mà nhân viên đó làm việc chocác phòng khác nhau.

Emp(eid: integer, ename: string, age: integer, salary: real)

Works(eid: integer, did: integer, pct_time: integer)

Dept(did: integer, budget: real, managerid: integer)

Viết các ràng buộc tham chiếu (miền, khoá, khoá ngoại, hoặc các ràng buộc kiểm tra;hoặc các xác nhận- assertions) hoặc các triggers để đảm bảo từng yêu cầu sau, các yêucầu là độc lập.

201/470

• Nhân viên phải có mức lương nhỏ nhất là $1000.• Tất cả các nhà quản lý phải là nhân viên.• Tổng số tỷ lệ phần trăm thời gian của mỗi nhân viên trong các phòng khác nhau

phải dưới 100%.• Người quản lý phải có lương cao hơn bất kỳ nhân viên nào mà mình quản lý.• Bất cứ khi nào một nhân viên được tăng lương, lương người quản lý cũng phải

tăng ít nhất là bằng với mức này.• Bất cứ khi nào một nhân viên được tăng lương, lương người quản lý cũng phải

tăng ít nhất là bằng với mức này. Thêm nữa, bất cứ khi nào một nhân viên đượctăng lương, qũy (budget) của phòng cũng phải tăng để lớn hơn tổng số lươngcủa tất cả các nhân viên.

Trả lời dành cho độc giả

Bài tập lớn

Xác định tập con các truy vấn SQL được Minibase hỗ trợ.

Trà lời: Dành cho độc giả

Tài liệu tham khảo

Phiên bản gốc của SQL đã được phát triển như một ngôn ngữ truy vấn trong dự án IBM'sSystem R, và sự phát triển ban đầu này được định hướng trong [107, 151]. Từ đó SQLđã được phát triển rộng rãi trong ngôn ngữ truy vấn quan hệ, và bây giờ nó đã trở thànhmột chuẩn quốc tế.

Một nghiên cứu toàn diện rất nên đọc về SQL-92 được Melton & Simon trình bày trong[524], và những tính năng chính của SQL: 1999 được trình bày trong [525]. Chúng tôihướng người đọc tới hai quyển sách nghiên cứu về SQL. Một bản tóm lược về SQL:1999 chuẩn được trình bày trong [237]. Những phân tích sâu sắc về SQL được trình bàytrong [202]. Mặc dù có một vài vấn đề đã được SQL-92 giải quyết trong những phiênbản sau. Phần ngữ nghĩa của một số lượng lớn các câu lệnh truy vấn SQL được trình bàytrong [560]. SQL: 1999 là chuẩn của tổ chức quốc tế ISO và ANSI. Melton là tác giảcủa ANSI và ISO SQL: 1999, tài liệu ANSI/ISO/IEC 9075 -:1999. Những tài liệu ISOliên quan là ISO/IEC 9075-: 1999. Một sự kế thừa, được đưa ra vào 2003, xây dựng trênSQL: 1999 là SQL: 2003. Bản nháp của SQL: 2003 có thể tìm được theo địa chỉ sau:

ftp://sqlstandards.org/SC32/

[774] chứa một tập các tài liệu trình bày về lĩnh vực cơ sở dữ liệu hoạt động. [794] chứanhững giới thiệu sâu sắc về các luật tích cực (active rules), tìm hiểu về ngữ nghĩa, cácứng dụng và các vấn đề thiết kế.

202/470

[251] trình bày về những mở rộng SQL để phục vụ kiểm tra ràng buộc tích hợp thôngqua các triggers. [123] cũng bàn về một cơ chế thủ tục, gọi là alerter, để quản lý cơ sởdữ liệu.

[185] là một văn bản gần đây đề cập đến vấn đề triggers có thể được tích hợp vào SQLmở rộng. Những kiểu cơ sở dữ liệu hoạt động có ảnh hưởng lớn bao gồm Ariel [366],HiPAC [516], ODE [18], Postgres [722], RDL [690], và Sentinel [36]. [147] so sánhkiến trúc của các hệ thống cơ sở dữ liệu hoạt động. [32] xem xét các điều kiện bên trongcủa tập các quy tắc tích cực, sự độc lập của thứ tự đánh giá. Những ngữ nghĩa của cơsở dữ liệu được nghiên cứu trong [285] và [792]. Việc thiết kế và quản lý các hệ thốngquy tắc tích cực được trình bày trong [60, 225]. [142] trình bày về quản lý các quy tắcsử dụng Chimera, một mô hình dữ liệu và ngôn ngữ của các hệ thống cơ sở dữ liệu hoạtđộng.

203/470

Phát triển ứng dụng cơ sở dữ liệuTrong chương 5, chúng ta đã nghiên cứu về các cấu trúc khác nhau của truy vấn SQL.Hệ quản trị cơ sở dữ liệu quan hệ thường có hỗ trợ ngôn ngữ SQL thông qua giao diệntương tác, và người dùng có thể nhập trực tiếp các câu lệnh SQL để thực hiện truy vấndữ liệu. Với những yêu cầu đơn giản có thể thực hiện ngay bằng một câu lệnh SQL thìphương pháp này là tốt. Tuy nhiên trên thực tế ta thường gặp những yêu cầu phức tạphơn vì thế ta có thể phải sử dụng ngôn ngữ lập trình mà SQL cung cấp. Ví dụ, chúngta có thể muốn tích hợp một ứng dụng cơ sở dữ liệu với giao diện đồ hoạ của người sửdụng, hoặc chúng ta muốn tích hợp với các chương trình ứng dụng khác đang tồn tại.

Các ứng dụng dựa trên hệ quản trị cơ sở dữ liệu để quản lý dữ liệu chạy như những tiếntrình riêng rẽ, những tiến trình này kết nối với hệ quản trị cơ sở dữ liệu để tương tácvới nó. Ngay khi một kết nối được thành lập, các câu lệnh SQL có thể được sử dụng đểthêm, xoá, và sửa dữ liệu. Các truy vấn SQL có thể được sử dụng để truy vấn những dữliệu mong muốn, nhưng chúng ta cần phải làm một cầu nối giữa các ngôn ngữ lập trìnhnhư C, Java với dữ liệu truy vấn được từ cơ sở dữ liệu: Kết quả của một truy vấn cơ sởdữ liệu là một tập hợp hoặc là các bản ghi, nhưng Java không hỗ trợ kiểu dữ liệu này.Thiếu sót này được giải quyết thông qua các cấu trúc của SQL, cho phép các ứng dụngthao tác trên một tập hợp các bản ghi tại cùng một thời điểm.

Chúng tôi giới thiệu Embedded SQL, Dynamic SQL và con trỏ trong Phần 1. EmbeddedSQL cho phép chúng ta truy cập dữ liệu sử dụng các truy vấn SQL trong phần mã củachương trình (Phần 1.1); cùng với Dynamic SQL, chúng ta có thể tạo ra các truy vấnrun-time (Phần 1.3). Con trỏ được sử dụng như cầu nối giữa giá trị của kết quả truy vấnvà ngôn ngữ lập trình (Phần 1.2). Java là ngôn ngữ lập trình được sử dụng rất thôngdụng để phát triển các ứng dụng Internet, truy cập tới DBMS từ Java được xem là mộtchủ đề quan trọng. Phần 2 sẽ tìm hiểu về JDBC, một công cụ cho phép chúng ta thựchiện các truy vấn SQL từ ngôn ngữ lập trình Java và sử dụng những kết quả trong ngônngữ lập trình Java. JDBC cung cấp nhiều lợi ích hơn là Embedded SQL hay DynamicSQL, và hỗ trợ khả năng kết nối với một vài DBMS mà không cần biên dịch lại mã củachương trình. Phần 4 tìm hiểu về SQLJ, nó tương tự như những truy vấn SQL, nhưngnó dễ dàng để lập trình trong Java cùng với JDBC.

Thường thì việc viết chương trình ứng dụng trên máy chủ cơ sở dữ liệu mang lại nhiềulợi ích hơn là chỉ truy vấn dữ liệu và thực hiện các ứng dụng trong một tiến trình riêng rẽnào đó. Phần 5 tìm hiểu về stored procedures, là phần chương trình có thể được lưu trữvà thực hiện trên máy chủ cơ sở dữ liệu. Chúng ta kết luận chương bằng việc xem xétví dụ ứng dụng B&N trong Phần 6. Trong khi viết các ứng dụng cơ sở dữ liệu, chúng taphải luôn ghi nhớ rằng các chương trình ứng dụng đang được chạy đồng thời. Khái niệmvề giao dịch, giới thiệu trong Chương 1 đã nêu lên những ảnh hưởng của một chương

204/470

trình ứng dụng đối với cơ sở dữ liệu. Một ứng dụng có thể được phép lựa chọn nhữngđặc tính của giao dịch thông qua các câu lệnh SQL, để điều khiển những mức độ ảnhhưởng của nó tới những ứng dụng khác đang chạy đồng thời. Chúng ta sẽ đề cập đếnkhái niệm giao dịch nhiều lần trong chương này. Phần trình bày về các tính chất củagiao dịch và những hỗ trợ của SQL với nó được đề cập đầy đủ trong Chương 16. Nhữngví dụ xuất hiện trong chương này có thể được tìm thấy tại địa chỉ:

http://www.cs.wise.edu/~ dbbook

Truy cập tới cơ sở dữ liệu từ các ứng dụng

Trong phần này, chúng ta tìm hiểu về cách thực hiện các câu lệnh SQL trong ngôn ngữlập trình như C hoặc Java. Việc sử dụng các câu lệnh SQL trong các ngôn ngữ lập trìnhnày được gọi là Embedded SQL. Những chi tiết của Embedded SQL cũng phụ thuộcvào ngôn ngữ lập trình, cú pháp của chúng có một chút thay đổi trong từng ngôn ngữ.Trước tiên chúng ta tìm hiểu phần cơ bản nhất của Embedded SQL trong Phần 1.1. Sauđó chúng ta tìm hiểu về con trỏ trong Phần 1.2. Chúng ta sẽ bàn và Dynamic SQL trongPhần 1.3.

Embedded SQL

Các câu lệnh SQL được nhúng trong ngôn ngữ lập trình rất dễ hiểu. Các câu lệnh SQL(ví dụ, không có phần khai báo biến) có thể được sử dụng bất cứ ở đâu mà chương trìnhyêu cầu. Các câu lệnh SQL phải được đánh dấu rõ ràng để bộ tiền xử lý có thể giải quyếtchúng trước khi biên dịch chương trình trong ngôn ngữ lập trình. Bất kỳ một biến nàocủa chương trình được sử dụng như một tham số trong câu lệnh SQL cũng phải đượckhai báo trong SQL. Trong một số trường hợp, một số biến đặc biệt của ngôn ngữ lậptrình phải được khai báo trong SQL.

Tuy nhiên, ở đây có hai sự rắc rối gặp phải. Đầu tiên, các kiểu dữ liệu được SQL chấpnhận có thể không được ngôn ngữ lập trình chấp nhận và ngược lại. Khó khăn này đượcgiải quyết bằng việc chuyển đổi về các kiểu dữ liệu phù hợp trước khi đưa giá trị vàocâu lệnh SQL. Rắc rối thứ hai là giá trị trả về của câu lệnh SQL thường là một tập hợpcác bản ghi, và khó khăn này được giải quyết khi sử dụng con trỏ. (Xem phần 1.2. Cáclệnh thực hiện với các bảng- là tập hợp các bản ghi).

Trong phần trình bày về Embedded SQL, chúng ta giả sử rằng ngôn ngữ lập trình là C.Sở dĩ phải chỉ rõ như vậy vì có sự khác nhau trong cú pháp câu lệnh SQL trong từngngôn ngữ lập trình.

Khai báo biến và một số ngoại lệ

205/470

Các câu lệnh SQL có thể tham chiếu tới các biến mà ngôn ngữ lập trình đã định nghĩa.Vì thế, những biến của ngôn ngữ lập trình được quy định là phải có tiền tố (:) trongcác câu lệnh SQL và được khai báo giữa các câu lệnh EXEC SQL BEGIN DECLARESECTION và EXEC SQL END DECLARE SECTION. Những khai báo này tương tựnhư chúng ta nhìn thấy trong ngôn ngữ C và cũng như C, các biến được ngăn cách bởidấu chấm phẩy. Ví dụ, chúng ta có thể khai báo các biến c_sname, c_sid, c_rating, vàc_age (trong đó tiền tố c được sử dụng để nhấn mạnh đây là những biến của ngôn ngữlập trình) như sau:

EXEC SQL BEGIN DECLARE SECTION char c_sname[20]; longc_sid; short c_rating; f loat c_age; EXEC SQL END DECLARESECTION

Câu hỏi đầu tiên xuất hiện là các kiểu dữ liệu của SQL có phù hợp với các kiểu dữ liệucủa C, vì chúng ta vừa khai báo một tập hợp các biến trong ngôn ngữ C và sẽ sử dụng nótrong câu lệnh SQL. Chuẩn SQL-92 định nghĩa các kiểu dữ liệu của mình tương thíchvới phần lớn ngôn ngữ lập trình đang tồn tại. Trong ví dụ của chúng ta, c_snamecó kiểudữ liệu là CHARACTER(20) trong câu lệnh SQL, c_sid có kiểu dữ liệu là INTEGER,c_rating là SMALLINT và c_age là REAL.

Chúng ta cũng cần có một vài cách để SQL thông báo khi có lỗi xảy trong quá trìnhthực hiện nó. Chuẩn SQL-92 cung cấp hai biến để báo lỗi là SQLCODE và SQLSTATE.SQLCODE là bội số của hai và được định nghĩa để trả về một số giá trị âm khi mà có lỗixảy ra. SQLSTATE được giới thiệu lần đầu tiên trong SQL-92, hỗ trợ các giá trị đượcđịnh nghĩa trước ứng với lỗi cụ thể xảy ra. Một trong hai biến này phải được khai báo.Trong C, kiểu dữ liệu phù hợp của SQLCODE là long và SQLSTATE là char[6]. Trongchương này chúng ta giả sử rằng SQLSTATE đã được khai báo.

Các câu lệnh Embedded SQL

Tất cả các câu lệnh SQL nhúng trong ngôn ngữ lập trình phải được khai báo rõ ràng, chitiết thế nào phụ thuộc vào từng ngôn ngữ lập trình; trong C, câu lệnh SQL phải có tiềntố là EXEC SQL. Một câu lệnh SQL có thể xuất hiện ở bất kỳ vị trí nào trong chươngtrình.

Ví dụ, câu lệnh Embedded SQL sau được sử dụng để thêm vào một dòng, giá trị của cáccột là giá trị tương ứng của các biến.

EXEC SQL INSERT INTO Sailors VALUES {:c_sname, :c_sid,:c_rating, :c_age);

206/470

Biến SQLSTATE nên được kiểm tra sau mỗi câu lệnh Embedded SQL để nhận đượcthông báo lỗi của câu lệnh (nếu có). SQL cung cấp lệnh WHENEVER để làm đơn giảncông việc nhàm chán này.

EXEC SQL WHENEVER [SQLERROR|NOT FOUND][CONTINUE|GOTO stmt]

Con trỏ

Khó khăn nhất khi sử dụng các câu lệnh Embedded SQL trong các ngôn ngữ lập trìnhnhư C là sự không tương đồng xảy ra khi SQL thường thực hiện những phép toán trêntập hợp các bản ghi, trong khi đó ngôn ngữ lập trình như C không dễ dàng hỗ trợ kiểudữ liệu này. Giải pháp được đề ra là phải cung cấp một cơ chế cho phép chúng ta truycập tới nhiều dòng (bản ghi) dữ liệu trong quan hệ tại cùng một thời điểm.

Cơ chế này được gọi là con trỏ. Chúng ta có thể khai báo một con trỏ trên bất kỳ quanhệ nào hoặc trên bất kỳ một truy vấn SQL nào (bởi vì kết quả của một truy vấn cũng làtập hợp các dòng). Một khi con trỏ được khai báo, chúng ta có thể mở (open) nó; truycập (fetch) tới dòng kế tiếp; di chuyển con trỏ (tới dòng tiếp theo, tới dòng sau dòng thứn, tới dòng đầu tiên, tới dòng cuối cùng, etc., bằng việc xác định thêm một số biến cholệnh FETCH); hoặc đóng con trỏ. Như vậy, một con trỏ sẽ cho phép chúng ta truy cậptới bất kỳ dòng nào trong bảng và đọc dữ liệu tại đó.

Định nghĩa và sử dụng con trỏ

Trong các ngôn ngữ lập trình, con trỏ giúp chúng ta thao tác với các dòng dữ liệu đượclấy ra từ câu lệnh Embedded SQL.

• Chúng ta thường cần phải mở con trỏ nếu câu lệnh Embedded SQL là câu lệnhSELECT. Tuy nhiên, chúng ta có thể tránh mở nó nếu kết quả của câu lệnhSELECT chỉ là một dòng.

• Các câu lệnh INSERT, DELETE, và UPDATE thường không yêu cầu con trỏ,mặc dù một vài biến thể của DELETE và UPDATE có thể yêu cầu con trỏ.

Như trong ví dụ, chúng ta có thể tìm được tên và tuổi của một thuỷ thủ mà chỉ cần gánmột giá trị cho một biến c_sid trong ngôn ngữ lập trình, như sau:

EXEC SQL SELECT S.sname, S.age INTO :c_sname, :c_age FROMSailors S WHERE S.sid = :c_sid;

Mệnh đề INTO cho phép chúng ta gán trị những cột của kết qủa câu lệnh SELECT(trong trường hợp kết quả này chỉ có duy nhất một dòng) cho hai biến c_name và c_age.Vì thế, chúng ta không cần phải sử dụng con trỏ trong trường hợp này. Nhưng điều gì sẽ

207/470

xảy ra với truy vấn sau, yêu cầu đưa ra tên và tuổi của tất cả các thuỷ thủ có rating lớnhơn giá trị của biến c_minrating?

SELECT S.sname, S.age FROM Sailors S WHERE S.rating >:c_minrating;

Kết quả của truy vấn này là một tập hợp các dòng dữ liệu, không phải chỉ là một dòngnhư truy vấn trước. Nếu như chúng ta vẫn thực hiện như trên thì chúng ta sẽ thấy mệnhđề INTO không thực hiện được vì hai biến :c_sname, :c_age không thể cùng lúc lưu trữnhiều giá trị. Giải pháp ở đây là chúng ta phải sử dụng một con trỏ:

DECLARE sinfo CURSOR FOR SELECT S.sname, S.age FROMSailors S WHERE S.rating > :c_minrating;

Đoạn mã này có thể thực hiện trong chương trình C, và khi chạy chương trình, một contrỏ sinfo được định nghĩa. Sau đó, chúng ta có thể mở con trỏ này:

OPEN sinfo;

Khi con trỏ được mở, nó trỏ tới dòng đầu tiên của kết quả truy vấn. Chúng ta có thể sửdụng lệnh FETCH để gán giá trị dòng đầu tiên này vào các biến của chương trình:

FETCH sinfo INTO :c_sname, :c_age;

Khi câu lệnh này thực hiện xong, con trỏ sẽ trỏ tới dòng kế tiếp và các giá trị của các cộtđược gán vào những biến tương ứng của chương trình. Bằng việc thực hiện lặp câu lệnhFETCH (giả sử, sử dụng vòng lặp While trong ngôn ngữ C), chúng ta có thể đọc tất cảcác dòng trong kết quả truy vấn, từng dòng một.

Khi chúng ta làm việc xong với một con trỏ nào đó, chúng ta có thể đóng nó lại:

CLOSE sinfo;

Chúng ta cũng có thể mở lại nó khi chúng ta cần, và giá trị của :cminratingtrong truyvấn SQL sẽ vẫn là giá trị của biến c_minrating ở thời điểm trước.

Các thuộc tính của con trỏ

Cấu trúc chung của một con trỏ là:

DECLARE cursorname [INSENSITIVE] [SCROLL] CURSOR [ WITHHOLD] FOR some query [ORDER BY order-item-list ] [| FORUPDATE ]

208/470

Một con trỏ nào đó có thể được khai báo là chỉ đọc (FOR READ ONLY) hoặc nó cóthể là một con trỏ áp dụng trên một quan hệ hoặc một khung nhìn có khả năng cập nhật(FOR UPDATE). Nếu con trỏ có khả năng cập nhật, những biến thể của lệnh UPDATEvà DELETE sẽ cho phép chúng ta cập nhật hoặc xoá dòng dữ liệu mà con trỏ đang trỏtới. Ví dụ, nếu .sinfo là một con trỏ có khả năng cập nhật và đang được mở, chúng ta cóthể thực hiện câu lệnh sau:

UPDATE Sailors S SET S.rating = S.rating - 1 WHERE CURRENTof sinfo;

Câu lệnh Embedded SQL này sẽ thay đổi giá trị rating của dòng mà con trỏ sinfo đangtrỏ tới, tương tự, chúng ta có thể xoá dòng này bằng lệnh:

DELETE Sailors S WHERE CURRENT of sinfo;

Mặc định, con trỏ sẽ ở chế độ có thể cập nhật được, trừ những con trỏ scrollable hoặcinsensitive (xem phần sau), trong những trường hợp này mặc định con trỏ ở chế độ chỉđọc (read only).

Nếu từ khoá SCROLL được chỉ ra, con trỏ sẽ là con trỏ có khả năng cuộn, có nghĩa làlệnh FETCH có thể được sử dụng để xác định con trỏ này một cách linh hoạt hơn; trongkhi đó lệnh FETCH cơ bản chỉ cho phép con trỏ truy cập đến dòng tiếp theo.

Nếu từ khoá INSENSITIVE được chỉ ra, con trỏ được đối xử giống như nó đang đượcduyệt trên một bản sao của một tập các dòng kết quả. Mặt khác, các giao dịch đang thựcthi có thể sửa những dòng dữ liệu này. Ví dụ, trong khi chúng ta đang đọc dữ liệu sửdụng con trỏ sinfo, đồng thời có thể có một giao dịch khác sửa giá trị rating trong quanhệ Sailor bằng lệnh:

UPDATE Sailors S SET S.rating = S.rating – 1

Xem xét một dòng Sailor trong hai trường hợp: (1) nó chưa được đọc (fetch), và (2) giátrị rating ban đầu sẽ gặp một điều kiện nào đó trong mệnh đề WHERE của một truy vấncó con trỏ sinfo, nhưng giá trị rating mới thì không. Khi chúng ta fetch một dòng nàođó của Sailor, nếu INSENTITIVE được xác định, cách thực hiện giống như là tất cả cáccâu trả lời đã được tính toán và lưu trữ khi con trỏ sinfo đã được mở; vì thế, lệnh updatekhông ảnh hưởng tới những dòng đã fetch bằng con trỏ sinfo nếu nó được thực hiện saukhi sinfo được mở. Nếu không có từ khoá INSENTITIVE, việc thực hiện sẽ phụ thuộcvào tình trạng này.

Một con trỏ là Holdable cursor khi nó sử dụng mệnh đề WITH HOLD, và nó khôngđược đóng lại khi một giao dịch đã hoàn thành. Mục đích của con trỏ loại này xuất pháttừ một thực tế rằng có những giao dịch dài- giao dịch cần truy cập (có thể thay đổi giá

209/470

trị) một số lượng lớn các dòng trong một bảng. Nếu vì một lý do nào đó giao dịch này bịhuỷ bỏ, hệ thống có thể phải làm lại rất nhiều công việc khi giao dịch đó được khởi độnglại. Ngay cả khi giao dịch đó không bị huỷ, những khoá của nó được nắm giữ trong mộtthời gian dài và vì thế khả năng xử lý đồng thời của hệ thống sẽ giảm. Một lựa chọn ởđây là nên chia nhỏ giao dịch này thành những giao dịch nhỏ hơn, nhưng việc ghi nhớvị trí trong bảng giữa những giao dịch (và những chi tiết khác) rất phức tạp và dễ gặplỗi. Việc cho phép một chương trình ứng dụng có thể kết thúc một giao dịch mà nó đãtạo ra, trong khi duy trì việc điều khiển trên bảng tích cực (ví dụ là con trỏ) sẽ giải quyếtvấn đề này: Một ứng dụng có thể kết thúc giao dịch của nó và khởi tạo một giao dịchmới và bằng cách lưu lại những thay đổi nó đã làm tới mức đó.

Cuối cùng, các lệnh FETCH truy vấn các dòng theo thứ tự nào? Thông thường thứ tựnày không được xác định, nhưng mệnh đề ORDER BY có thể được sử dụng nếu muốnviệc truy cập sẽ theo thứ tự. Ghi nhớ rằng những cột được đề cập trong mệnh đề ORDERBY không thể được cập nhật qua con trỏ dạng này.

Order-item-list là một danh sách của order-items; một order-item là tên của một cột,theo sau có thể là một trong hai từ khoá ASC hoặc DESC. Tất cả các cột được đềcập trong mệnh đề ORDER BY cũng phải xuất hiện trong select-list của truy vấn này.Những từ khoá ASC hoặc DESC phải theo sau cột cần sắp xếp- thứ tự tăng dần (ASC)hoặc giảm dần (DESC), chế độ mặc định là ASC. Mệnh đề này phải được đứng ở vị trícuối cùng trong truy vấn.

Xem xét truy vấn được bàn trong Phần 5.5.1, và kết quả được chỉ tra trong Hình 5.13.Giả sử rằng một con trỏ được mở trên truy vấn này, cùng với mệnh đề:

ORDER BY minage ASC, rating DESC

Kết quả của truy vấn này đầu tiên được sắp xếp tăng dần theo minage, và nếu có vàidòng có cùng giá trị minage, những dòng này sẽ được sắp xếp giảm dần theo rating. Contrỏ này sẽ fetch tới các dòng theo thứ tự được chỉ ra trong Hình 6.1.

Thứ tự của các bộ giá trị được fetch

Dynamic SQL

Giả sử một ứng dụng cần truy cập dữ liệu từ một DBMS nào đó. Khi đó, ứng dụng nhậnnhững lệnh từ người dùng, dựa trên yêu cầu của người dùng để tự sinh ra những câulệnh SQL phù hợp để truy cập dữ liệu cần thiết. Trong những trường hợp này, chúng ta

210/470

có thể không dự đoán được những câu lệnh SQL nào cần để thực hiện, mặc dù có mộtsố thuật toán chỉ ra cách mà ứng dụng có thể xây dựng những câu lệnh SQL cần thiếtkhi có một yêu cầu người dùng đưa vào.

SQL cung cấp một vài tiện ích để đối mặt với tình trạng này; nó được biết đến như làDynamic SQL. Chúng tôi cung cấp hai câu lệnh chính, PREPARE và EXECUTE thôngqua một ví dụ đơn giản:

char c_sqlstring[] = {"DELETE FROM Sailors WHERErating>5"}; EXEC SQL PREPARE readytogo FROM :c_sqlstring;EXEC SQL EXECUTE readytogo;

Câu lệnh đầu tiên khai báo một biến C là c_sqlstring và khởi tạo giá trị của nó, giá trị đólà một câu lệnh SQL. Câu lệnh thứ hai nhằm phân tích cú pháp và biên dịch xâu ký tựnày thành một câu lệnh SQL, và gán nó vào biến readytogo. (Vì readytogo là một biếnSQL, chỉ giống như là tên của một con trỏ, nên nó không cần phải được định vị bằngdấu ‘:’ ở đằng trước). Câu lệnh thứ ba sẽ thực hiện câu lệnh SQL này.

Có nhiều trường hợp yêu cầu được sử dụng Dynamic SQL. Tuy nhiên, ghi nhớ rằng việcchuẩn bị của một câu lệnh Dynamic SQL diễn ra ngay tại thời điểm chạy chương trình(run-time). Những lệnh Embedded SQL có thể được chuẩn bị ở thời điểm biên dịch vàsau đó thực hiện như chúng ta thường mong muốn. Vì thế, bạn nên hạn chế sử dụngDynamic SQL, chỉ sử dụng nó khi nào thực sự cần thiết. Có rất nhiều vấn đề liên quanđến Dynamic SQL, nhưng ở đây chúng ta không bàn nhiều về nó.

Giới thiệu về JDBC

ODBC và JDBC là viết tắt của Open DataBase Connectivity và Java DataBaseConnectivity. Cả ODBC và JDBC đều khai thác những khả năng của cơ sở dữ liệu theomột cách thức đã được chuẩn hoá thông qua Application Programming Interface (API).Khác với Embedded SQL, ODBC và JDBC cho phép một thực hiện có thể truy xuất tớicác DBMS khác nhau mà không cần biên dịch lại. Thêm nữa, sử dụng DBMS và JDBC,một ứng dụng nào đó có thể truy xuất không chỉ một DBMS mà nhiều DBMS khác nhauđồng thời.

ODBC và JDBC có được khả năng linh động ở mức thực thi bằng việc bổ sung thêmmột lớp gián tiếp. Tất cả các thao tác trực tiếp với một DBMS xác định nào đó đượcthực hiện thông qua một DBMS-driver. Một driver là một chương trình phần mềm xửlý các yêu cầu của ODBC hoặc JDBC. Những driver phù hợp được đăng ký với DriverManager.

Một điểm thú vị cần ghi nhớ là một driver nào đó không nhất thiết phải tương tác vớimột DBMS hiểu ngôn ngữ SQL. Driver có khả năng chuyển đổi những câu lệnh SQL từ

211/470

chương trình ứng dụng thành những câu lệnh tương đương mà DBMS hiểu được. Vì thế,trong phần còn lại của mục này, chúng tôi coi một hệ thống con lưu trữ dữ liệu tươngứng với một driver nào đó như là một nguồn dữ liệu (data source).

Một ứng dụng nào tương tác cùng với nguồn dữ liệu thông qua ODBC hoặc JDBC sẽlựa chọn một nguồn dữ liệu, tự động tải driver tương ứng và thành lập một kết nối vớinguồn dữ liệu đó. Số lượng các kết nối được mở là không giới hạn, và một ứng dụngnào đó có thể mở một vài kết nối tới các nguồn dữ liệu khác nhau. Mỗi một kết nối cócác giao dịch của nó; ở đây, một kết nối chỉ có thể nhìn thấy những thay đổi của một kếtkhác khi nó đã hoàn thành. Trong khi một kết nối nào đó đang mở, giao dịch được thựchiện bằng việc gửi đi câu lệnh SQL, lấy kết quả, xử lý lỗi và cuối cùng là hoàn thành(commit) hay là quay trở lại trạng thái ban đầu (roll back) của cơ sở dữ liệu trước thờiđiểm thực hiện giao dịch này. Sau đó, ứng dụng sẽ ngắt kết nối với nguồn dữ liệu đểngừng việc tương tác.

Trong phần còn lại của chương này, chúng ta sẽ tập trung tìm hiểu về JDBC.

JDBC Drivers: Nguồn cập nhật nhất của JDBC drivers là Sun JDBC Driver ở trang:

http://industry.java.sun.com/products/jdbc/drivers

JDBC drivers có thể dùng được cho tất cả các hệ thống cơ sở dữ liệu.

Kiến trúc

Kiến trúc của JDBC có bốn thành phần chính: ứng dụng, bộ quản lý driver, một vàinguồn dữ liệu riêng của cácdriver, và các nguồn dữ liệu tương ứng.

Một ứng dụng khởi tạo và ngắt một kết nối với một nguồn dữ liệu nào đó. Nó thiết đặtnhững ranh giới giao dịch, gửi đi những câu lệnh SQL, và truy vấn tới những kết quả-tất cả thông qua một giao diện được định nghĩa tốt như JDBC API. Mục đích chính củabộ quản lý driver là tải các drivers của JDBC và đưa các hàm JDBC gọi từ ứng dụngtới một driver phù hợp. Bộ quản lý drivers cũng quản lý sự khởi động của JDBC và cácthông tin mà ứng dụng gọi và có thể ghi lại tất cả các hàm được gọi. Thêm nữa, bộ quảnlý drivers thực hiện một số việc kiểm tra lỗi ban đầu. Một driver thành lập một kết nốivới nguồn dữ liệu. Sau đó gửi các yêu cầu và trả lại kết quả của yêu cầu, driver nàychuyển đổi dữ liệu, những định dạng lỗi, và những mã lỗi từ dạng nào đó của nguồn dữliệu vào JDBC chuẩn. Nguồn dữ liệu này xử lý các lệnh từ driver và trả về kết quả.

Phụ thuộc vào vị trí tương quan của nguồn dữ liệu và ứng dụng, có một vài kịch bản kếtnối được lập. Các drivers trong JDBC được chia làm bốn loại phụ thuộc vào mối quanhệ giữa ứng dụng và nguồn dữ liệu.

212/470

Loại I: Bridges: Loại này sẽ chuyển đổi các hàm của JDBC vào các hàm của API khôngnative với DBMS. Ví dụ JDBC-ODBC bridge; một ứng dụng nào đó có thể sử dụngJDBC để truy cập một nguồn dữ liệu của ODBC. Ứng dụng này tải chỉ một driver, mộtbridge. Bridges có ưu điểm là dễ đặt một ứng dụng lên trên phần cài đặt đang tồn tại,không cần cài đặt thêm các drivers mới. Nhưng việc sử dụng bridge gặp một số nhượcđiểm. Sự tăng lên của số lượng các lớp giữa nguồn dữ liệu và ứng dụng làm ảnh hưởngđến quá trình thực hiện. Thêm nữa, người dùng bị hạn chế những chức năng mà ODBCdriver hỗ trợ.

Loại II:Trực tiếp chuyển tới Native API thông qua Non-Java Driver: Kiểu này củadriver sẽ thực hiện chuyển các hàm JDBC trực tiếp vào API của một nguồn dữ liệu xácđịnh. Driver này thường được viết sử dụng ngôn ngữ C kết hợp với Java; nó tự liên kếtvà xác định nguồn dữ liệu. Kiến trúc này thực hiện hiệu quả hơn đáng kể so với JDBC-ODBC bridge. Một bất lợi ở đây là driver của cơ sở dữ liệu cần được cài đặt trên mỗimáy chạy ứng dụng.

Loại III: Network Bridges: Gửi các câu lệnh trên Network tới một máy chủ trung giangiao tiếp được với data source. Chỉ cần JDBC driver nhỏ trên mỗi máy trạm, vì nó chỉcó nhiệm vụ gửi những câu lệnh SQL tới máy chủ trung gian. Máy chủ trung gian sauđó có thể sử dụng Loại II JDBC driver để kết nối với nguồn dữ liệu.

Loại IV:Trực tiếp chuyển tới Native API thông qua Java Driver: Thay vì gọi DBMSAPI trực tiếp, driver kết nối với DBMS thông qua Java sockets. Trong trường hợp này,driver phía máy trạm được viết bằng Java, nhưng nó là DBMS xác định. Giải pháp nàykhông yêu cầu một lớp trung gian và từ đó tất cả việc thực hiện do Java đảm nhiệm, quátrình thực hiện thường là tốt.

Các lớp và giao diện JDBC

JDBC là một tập hợp các lớp và các giao diện có thể truy cập đến cơ sở dữ liệu từ cácchương trình viết bằng ngôn ngữ lập trình Java. Nó bao gồm các phương pháp kết nốitới nguồn dữ liệu từ xa, các câu lệnh SQL đang thực thi, tập kết quả của các câu lệnhSQL đang được kiểm tra, quản lý các giao dịch. Các lớp và các giao diện là một phầncủa gói Java.sql. Vì thế, tất cả các đoạn mã nguồn trong phần còn lại của mục này nêncó câu lệnh import java.sql.* ở đầu chương trình, chúng ta sẽ bỏ qua câu lệnh này trongphần còn lại của mục này. JDBC 2.0 cũng bao gồm gói javax.sql, gói không bắt buộccủa JDBC. Khi gói javax.sql được thêm vào, khả năng bể kết nối và giao diện Rowset sẽđược bổ sung. Chúng ta sẽ bàn đến bể kết nối trong Phần 6.3.2, và giao diện ResultSettrong Phần 6.3.4.

Bây giờ, chúng ta minh họa các bước phải làm để gửi đi một truy vấn tới một nguồn dữliệu và truy cập tới các kết quả trả về.

213/470

Quản lý JDBC Driver

Trong JDBC, các driver của nguồn dữ liệu được lớp Drivermanager quản lý, nó chứa tấtcả các driver đã được tải lên. Lớp Drivermanager bao gồm các cách thức registerDriver,deregisterDriver, và getDrivers để có thể linh động bổ sung hoặc xoá các driver. Bướcđầu tiên khi kết nối với nguồn dữ liệu là tải JDBC driver tương ứng. Bước này đượchoàn thành bằng việc sử dụng cơ chế của Java hỗ trợ việc tải các lớp lên một cách linhđộng.

Ví dụ sau cho phép tải một JDBC driver:

Class.forName(''oracle/jdbc.driver.OracleDriver'');

Có hai cách khác nhau để đăng ký một driver. Chúng ta có thể thêm một driver sử dụngcâu lệnh -Djdbc.drivers=oracle/jdbc.driver ở một dòng lệnh khi chúng ta bắt đầu chươngtrình Java.

Sau khi đăng ký driver, chúng ta có thể kết nối tới nguồn dữ liệu.

Các kết nối

Một phiên làm việc cùng với một nguồn dữ liệu nào đó được bắt đầu thông qua việc tạomột đối tượng Connection. Một kết nối nào đó xác nhận một phiên làm việc cùng vớimột nguồn dữ liệu; nhiều kết nối trong cùng một chương trình Java có thể tham chiếu tớicác nguồn dữ liệu khác nhau hoặc cùng một nguồn dữ liệu. Các kết nối được xác địnhthông qua một JDBC URL, một URL sử dụng giao thức jdbc. Vì thế một URL có dạng:

jdbc:<subprotocol>:<otherParameters>

Các kết nối JDBC: Hãy nhớ đóng các kết nối tới nguồn dữ liệu và trả lại những kếtnối có khả năng chia sẻ cho bể kết nối. Các hệ thống cơ sở dữ liệu chỉ cho phép một sốlượng hạn chế những tài nguyên có thể cho các kết nối, và các kết nối “mồ côi” có thểchỉ được phát hiện khi time-out— và trong khi hệ thống cơ sở dữ liệu đang đợi một kếtnối time-out, các nguồn tài nguyên mà những kết nối “mồ côi” sử dụng sẽ bị lãng phí.

Đoạn mã chương trình ví dụ thành lập một kết nối tới một cơ sở dữ liệu Oracle với giảthiết là xâu userid và password được thiết lập giá trị rỗng.

String url = "jdbc:oracle:www.bookstore.com:3083"Connection connection; try{ Connection connection =DriverManager.getConnection(url,userId,password); }catch(SQLException excpt) {

214/470

System.out.println(excpt.getMessage()); return; }Thành lậpmột kết nối với JDBC

Trong JDBC, các kết nối có thể có các thuộc tính khác nhau. Ví dụ, một kết nối cóthể định rõ đặc tính “granularity” (nguyên tử) của giao dịch. Nếu tính chất tự độnghoàn thành được thiết đặt cho một kết nối, thì mỗi một câu lệnh SQL được coi nhưlà một giao dịch chứa chính bản thân câu lệnh SQL đó. Nếu tính chất tự động hoànthành này tắt, thì một loạt các câu lệnh được soạn thảo cho một giao dịch có thể đượchoàn tất sử dụng phương thức commit() của lớp Connection, hoặc huỷ bỏ nếu sử dụngphương thức rollback(). Một lớp Connection có các phương thức để thiết đặt chế độ tựđộng hoàn thành (Connection. setAutoCommit) và để gọi lại chế độ tự động hoàn thành(getAutoCommit). Những phương thức sau là một phần của giao diện Connection chophép thiết lập và lấy các thuộc tính khác nhau:

• public int getTransactionIsolation() throws SQLException và

public void setTransactionIsolation(int l) throws SQLException.

Hai hàm này sẽ lấy và thiết đặt mức cô lập hiện tại cho các giao dịch trong kết nối hiệntại. Có tất cả năm mức cô lập (chi tiết sẽ trình bày trong Phần 16.6) có thể được sử dụng,và đối số l có thể được thiết đặt như sau:

• TRANSACTION_NONE• TRANSACTION_READ_UNCOMMITTED• TRANSACTION_READ_COMMITTED• TRANSACTION_REPEATABLE_READ• TRANSACTION_SERIALIZABLE• public boolean getReadOnly() throws SQLException và

public void setReadOnly(boolean readOnly) throws SQLException.

Hai hàm này cho phép người dùng chỉ định những giao dịch được thực hiện thông quakết nối này là chỉ đọc.

• public boolean isClosed() throws SQLException.

Kiểm tra kết nối hiện tại đã được đóng chưa.

• setAutoCommit and get AutoCommit.

Chúng ta đã bàn đến hai hàm này.

Việc thành lập một kết nối tới một nguồn dữ liệu là một phép toán đắt giá vì nó baogồm nhiều bước, như là thành lập một kết nối mạng tới nguồn dữ liệu, xác thực quyền,

215/470

và phân chia các tài nguyên ví dụ như bộ nhớ. Trong trường hợp một ứng dụng nàođó lập nhiều kết nối khác nhau từ các phần khác nhau (như một Web server), các kếtnối thường được “dùng chung” (pool) để tránh hiện tượng overhead. Một bể kết nối(connection pool) là một tập hợp các kết nối đã được kết nối với một nguồn dữ liệu nàođó. Bất cứ khi nào một kết nối được yêu cầu, một trong số các kết nối trong bể được sửdụng thay vì việc phải tạo ra một kết nối mới tới nguồn dữ liệu đó. Bể kết nối có thểđược quản lý thủ công trong quá trình lập trình chương trình ứng dụng, hoặc có thể sửdụng gói javax.sql, gói này cung cấp các tính năng của bể kết nối và cho phép chúng tathiết đặt lại các tham số khác nhau, như là dung lượng của bể, tỷ lệ co giãn kích thướcbể. Hầu hết các ứng dụng (Phần 7.7.2) sử dụng gói javax.sql.

Thực thi các câu lệnh SQL

Bây giờ chúng ta sẽ bàn đến cách thức tạo và thực hiện các câu lệnh SQL sử dụng JDBC.Trong các đoạn mã lệnh ví dụ của phần này, chúng ta giả sử rằng chúng ta có một đốitượng Connection có tên là con. JDBC hỗ trợ ba cách khác nhau để thực thi các câulệnh:Statement, PreparedStatement, và CallableStatement. Lớp Statement là lớp cơ sởcủa hai lớp còn lại. Nó cho phép chúng ta truy vấn tới nguồn dữ liệu. Chúng ta sẽ tìmhiểu về lớp PreparedStatement ở đây và lớp CallableStatement trong Phần 6.5 khi chúngta tìm hiểu về Stored procedures. Lớp PreparedStatement sinh ra một cách linh động cáccâu lệnh SQL đã được biên dịch-những câu lệnh có thể đã được sử dụng một vài lần;những câu lệnh SQL này có thể có các tham biến, nhưng cấu trúc của chúng được cốđịnh khi một đối tượng PreparedStatement được tạo. Xem xét một ví dụ sử dụng đốitượng PreparedStatement chỉ ra trong Hình 6.3. Một truy vấn SQL được xác định là mộtxâu truy vấn, nhưng sử dụng dấu “?” cho các giá trị của các biến, những giá trị sẽ đượcthiết lập sau khi sử dụng phương thức setString, setFloat, và setInt. Ký hiệu thay thế“?” có thể được sử dụng bất kỳ đâu trong các câu lệnh SQL, nơi mà chúng ta muốn sẽđược thay thế bằng một giá trị. Ví dụ, ký hiệu thay thế có thể xuất hiện trong mệnh đềWHERE (ví dụ, ‘WHERE author=?’), hoặc trong các câu lệnh UPDATE và INSERT.Phương thức setString là một cách để thiết đặt giá trị cho một biến; những phương thứctương tự có thể thiết đặt cho các kiểu dữ liệu như int, float, và date. Chúng ta nên sửdụng clearParameters() trước khi thiết lập các biến giá trị để xoá đi bất kỳ một giá trị cũnào.

//initial quantity is always zero String sql = “INSERTINTO Books VALUES(?, ?, ?, ?, 0, ?)”; PreparedStatementpstmt = con.prepareStatement(sql); //now instantiate theparameters with values //assume that isbn, title, etc. areJava variables that //contain the values to be insertedpstmt.clearParameters(); pstint.setString(l,isbn);pstmt.setString(2,title): pstmt.setString(3,author);pstmt.setFloat(5,price); pstmt.setlnt(6,year); int numRows

216/470

= pstmt.executeUpdate();Câu lệnh SQL Update sử dụng mộtđối tượng PreparedStatement

Có những cách khác nhau để gửi một truy vấn tới nguồn dữ liệu. Ví dụ, chúng ta đãsử dụng lệnh executeUpdate, nó được sử dụng nếu chúng ta biết rằng câu lệnh SQLđó không trả về bất kỳ bản ghi nào (các lệnh SQL: UPDATE, INSERT, ALTER, vàDELETE). Phương thức executeUpdate trả về một số nguyên chỉ ra số dòng đã đượcsửa bằng lệnh SQL; trả về giá trị 0 nếu câu lệnh thực hiện thành công mà không sửa bấtkỳ dòng nào. Phương thức executeQuery được sử dụng nếu câu lệnh SQL trả về dữ liệu,ví dụ như một truy vấn SELECT thông thường nào đó. JDBC có cơ chế con trỏ có dạnglà một đối tượng ResultSet, phần này chúng ta sẽ bàn đến sau. Phương thức thực hiệnnày phổ biến hơn việc sử dụng executeQuery và executeUpdate; phần cuối chương nàycung cấp nhiều thông tin hơn về con trỏ.

ResultSets

Như đã trình bày trong những phần trước, một câu lệnh executeQuery trả về một đốitượng ResultSet, nó tương tự như một con trỏ. Những con trỏ ResultSet trong JDBC 2.0rất hiệu quả, chúng cho phép đi lên, đi xuống, cuộn tròn để thực hiện các thao tác vớibản ghi.

Trong dạng cơ bản nhất, đối tượng ResultSet cho phép chúng ta đọc một dòng của kếtquả truy vấn ở một thời điểm. Ban đầu, đối tượng ResultSet được định vị ở trước dòngđầu tiên, và chúng ta phải truy vấn đề dòng đầu tiên sử dụng phương thức next(). Phươngthức next trả về giá trị false nếu không còn dòng nào trong kết quả truy vấn, và true nếungược lại. Đoạn mã lệnh minh hoạ cách sử dụng cơ bản của đối tượng ResultSet.

ResultSet rs=stmt.executeQuery(sqlQuery); //rs is now acursor //first call to rs.next() moves to the first record//rs.next() moves to the next row String sqlQuery;ResultSet rs = stmt.executeQuery(sqlQuery) while(rs.next()) { //process the data }Sử dụng một đối tượngResultSet

Trong khi next() cho phép chúng ta truy vấn đến dòng tiếp theo trong kết quả truy vấn,chúng ta cũng có thể di chuyển đến các dòng dữ liệu theo các cách khác:

• previous() trở về một dòng trước đó• absolute(int num) di chuyển đến dòng xác định có vị trí là num.• relative(int num) đi lên hoặc đi xuống (nếu num là số âm) so với vị trí hiện tại,

relative(-1) có cùng tác dụng như là previous().• first() di chuyển đến dòng đầu tiên, và last() di chuyển đến dòng cuối cùng.

217/470

So sánh các kiểu dữ liệu của Java và SQL

Xem xét sự tương tác giữa một ứng dụng với một nguồn dữ liệu, những vấn đề chúng tabắt gặp trong môi trường Embedded SQL (ví dụ, trao đổi thông tin giữa một ứng dụngvà nguồn dữ liệu thông qua các biến chia sẻ) tăng lên. Để giải quyết những vấn đề này,JDBC cung cấp các loại dữ liệu đặc biệt và xác định mối quan hệ giữa chúng để làmchúng tương ứng với các kiểu dữ liệu SQL. Hình 2 chỉ ra các phương thức truy cập trongmột đối tượng ResultSet cho các kiểu dữ liệu SQL chung nhất. Với những phương pháptruy cập này, chúng ta có thể truy cập tới những giá trị dòng hiện tại của kết quả truyvấn. Có hai dạng của mỗi phương thức truy cập: một là truy cập đến giá trị thông quachỉ số cột, bắt đầu là 1, và hai là truy cập thông qua tên của cột. Ví dụ sau chỉ ra cáchtruy cập tới các trường của dòng ResultSet hiện tại sử dụng các phương thức truy cập.

Đọc những kiểu dữ liệu SQL từ một đối tượng ResultSet

ResultSet rs=stmt.executeQuery(sqlQuery); String sqlQuery;ResultSet rs = stint.executeQuery(sqlQuery) while(rs.next()){ isbn = rs.getString(1): title =rs.getString(“TITLE”); //process isbn and title }

Cảnh báo lỗi

Tương tự như biến SQLSTATE, hầu hết các phương thức trong java.sql có thể sử dụngSQLException để nhắc nhở nếu một lỗi nào đó xảy ra. Lời nhắc đó nằm trong SQLState,đó là một xâu ký tự nào biểu diễn lỗi này (ví dụ, một câu chứa một mã lỗi SQL). Đểthêm vào phương thức getMessage() được thừa kế từ Throwable, SQLException có haiphương thức nữa để cung cấp thêm thông tin, và một phương thức để lấy những lời nhắcbổ sung:

218/470

• public String getSQLState() trả về SQLState xác định dựa trên SQL:1999, nhưđã trình bày trong Phần 6.1.1.

• public int getErrorCode() trả về một mã lỗi.• public SQLException getNextException() trả về lời nhắc nhở tiếp theo trong

một chuỗi những lời nhắc liên quan đến đối tượng SQLException hiện tại.

Một SQLWarning là một lớp con của SQLException. Những cảnh báo này không khắtkhe như những thông báo lỗi. Các đối tượng Connection, Statement, và ResultSet đềucó chung một phương thức getWarning() để truy cập tới những lời nhắc SQL. Chúng tacó thể xoá những lời cảnh báo thông qua clearWarnings(). Những đối tượng Statementtự động xoá đi những cảnh báo khi nó thực hiện sang câu lệnh tiếp theo; Các đối tượngResultSet xóa những lời cảnh báo ngay khi một bộ dữ liệu mới được truy cập. Hình 6.6là một ví dụ mã lệnh giúp ta thu được các SQLWarnings.

try { stmt = con.createStatement(); warning =con.getWarnings(); while( warning != null) { //handlesQLWarnings //code to process warning warning =warning.getNextWarning(); //get next warning } con.clearWarnings(); stmt.executeUpdate(queryString); warning =stmt.getWarnings(); while( warning!= null) {//handleSQLWarnings //code to process warning warning =warning.getNextWarning(); //get next warning } } // endtry catch ( SQLException SQLe) { // code to handleexception } // end catchXử lý JDBC Warnings và Exceptions

Kiểm tra cơ sở dữ liệu hệ thống

Chúng ta có thể sử dụng đối tượng DatabaseMetaData để lấy những thông tin về hệthống cơ sở dữ liệu. Ví du, đoạn mã sau chỉ ra cách lấy ra tên và driver version củaJDBC driver:

DatabaseMetaData md = con.getMetaData();Systein.out.println("Driver Information:");System.out.println("Name:" + md.getDriverName() + ";version:" + md.getDriverVersion());

Đối tượng DatabaseMetaData có nhiều phương thức (trong JDBC 2.0, có chính xác là134); chúng ta liệt kê một số phương thức ở đây:

• public ResultSet getCatalogs() throws SQLException. Hàm này trả về mộtResultSet có thể được sử dụng lặp đi lặp lại trên tất cả các quan hệ. Các hàmgetIndexInfo() và getTables() làm việc tương tự.

219/470

• public int getMaxConnectionsO throws SQLException. Hàm này trả về sốlượng lớn nhất các kết nối có thể.

Chúng ta sẽ tổng kết những nội dung đã bàn về JDBC thông qua một đoạn mã lệnh trongHình 6.7, nó sẽ kiểm tra tất cả các database metadata.

DatabaseMetaData dmd = con.getMetaData(); ResultSettablesRS = dmd.getTables(null,null,null,null); stringtableName; while(tablesRS.next()) { tableName =tablesRS.getString("TABLE_NAME"); //print out theattributes of this table System.out.println("Theattributes of table " + tableName + " are:"); ResultSetcolumnsRS=dmd.getColuins(null,null,tableName,null): while(columnsRS.next()) {System.out.print(columnsRS.getString("COLUMN_NAME")+ “ ”); } //print out the primary keys of this tableSystem.out.println("The keys of table "+tableName + "are:"); ResultSet keysRS =dmd.getPrimaryKeys(null,null,tableName); while(keysRS.next()) {System.out.print(keysRS.getString("COLUMN_NAME") + " "); }}Đưa ra những thông tin về một nguồn dữ liệu

SQLJ

SQLJ (viết tắt của 'SQL-Java') đã được SQLJ Group phát triển, một nhóm nhà cung cấpcơ sở dữ liệu và Sun. SQLJ đã được phát triển để tạo ra thêm một cách tạo ra các truyvấn trong JDBC một cách linh hoạt. Vì thế nó có liên quan mật thiết với EmbeddedSQL. Không như JDBC, có những truy vấn SQL bán-tĩnh cho phép trình biên dịch thựchiện những kiểm tra cú pháp SQL, những kiểm tra đánh giá sự tương thích giữa các biếntrên máy trạm với các thuộc tính SQL tương ứng và sự nhất quán của các truy vấn cùngvới lược đồ cơ sở dữ liệu – các bảng, các thuộc tính, các khung nhìn, và các thủ tục- tấtcả được kiểm tra cùng lúc khi biên dịch. Ví dụ, cả SQLJ và Embedded SQL, các biến ởtrong ngôn ngữ lập trình luôn được gán tĩnh cho các tham số tương ứng, ngược lại trongJDBC, chúng ta cần phân tách các câu lệnh để gán mỗi biến cho một tham số và truycập kết quả. Ví dụ, câu lệnh SQLJ sau đây sẽ gán các biến trong ngôn ngữ lập trình làtitle, price, và author cho các giá trị trả về của con trỏ books.

#sql books = { SELECT title, price INTO :title, :priceFROM Books WHERE author = :author };

220/470

Trong JDBC, chúng ta có thể quyết định một cách linh động những biến nào của ngônngữ lập trình sẽ nắm giữ kết quả truy vấn. Trong ví dụ sau đây, chúng ta đọc title củamột quyển sách vào trong biến ftitle nếu quyển sách đó được viết bằng Feynman, và vàobiến otitle trong những trường hợp khác:

//assume we have a ResultSet cursor rs author =rs.getString(3); if (author=="Feynman") { ftitle =rs.getString(2); } else { otitic = rs.getString(2); }

Khi biết các ứng dụng SQLJ, chúng ta chỉ viết mã lệnh Java thông thường và các câulệnh Embedded SQL. Các ứng dụng SQLJ được tiền xử lý thông qua một chương trìnhdịch. Nếu chương trình sửa đổi, nó có thể được biên dịch lại bằng bất kỳ trình biên dịchJava nào. Thông thường, thư viện SQLJ Java gọi tới một JDBC driver, nơi nắm giữnhững kết nối tới hệ thống cơ sở dữ liệu.

Có một sự khác nhau tồn tại giữa Embedded SQL và SQLJ và JDBC. Vì những nhà pháttriển cung cấp các phiên bản khác nhau về SQL, chúng ta có thể viết các truy vấn SQLtheo chuẩn SQL-92 hoặc SQL:1999. Tuy nhiên, khi sử dụng Embedded SQL, yêu cầuphải sử dụng các cấu trúc SQL xác định của từng nhà cung cấp- các cấu trúc này dựatrên chuẩn SQL-92 và SQL:1999. SQLJ và JDBC có thể linh động hơn để tương thíchvới các hệ thống cơ sở dữ liệu khác nhau.

Trong phần còn lại, chúng tôi sẽ cung cấp giới thiệu ngắn gọn về SQLJ.

Viết mã lệnh SQLJ

Chúng ta sẽ tìm hiểu SQLJ thông qua các ví dụ. Hãy cùng chúng tôi bắt đầu bằng mộtđoạn mã lệnh SQLJ, nó đưa ra những bản ghi từ bảng Books sau khi so sánh với một tácgiả (author) nào đó được cung cấp.

String title; Float price; String author; #sql iteratorBooks (String title, Float price); Books books; //theapplication sets the author //execute the query and openthe cursor #sql books = { SELECT title, price INTO :title,:price FROM Books WHERE author = :author }; //retrieveresults while (books.next()) {System.out.println(books.title() + ", " + books.price());} books.close();

Đoạn mã viết bằng JDBC sẽ như sau (giả sử chúng ta cũng đã khai báo price, name, vàauthor):

221/470

PreparedStatement stmt = connection.prepareStatement("SELECT title, price FROM Books WHERE author = ?"); //setthe parameter in the query and execute itstmt.setString(l, author); ResultSet rs =stmt.executeQuery(); //retrieve the results while(rs.next()) { System.out.println(rs.getString(l) + ", " +rs.getFloat(2)); }

So sánh hai đoạn mã lệnh viết bằng JDBC và SQLJ, chúng ta nhận thấy rằng mã lệnhcủa SQLJ dễ hiểu hơn JDBC. Vì thế, SQLJ giảm thời gian viết chương trình và bảo trìcho các nhà phát triển phần mềm.

Chúng ta hãy cùng nhau xem xét các thành phần trong đoạn mã SQLJ một cách chi tiếthơn. Tất cả các câu lệnh SQLJ có một tiền tố #sql. Trong SQLJ, chúng ta truy cập tớicác kết quả của truy vấn SQL bằng các đối tượng iterator, là các con trỏ cơ bản. Mộtiterator là một minh hoạ của một lớp iterator. Sử dụng một iterator trong SQLJ phải điqua năm bước:

• Khai báo Iterator Class: Đoạn mã trước sử dụng câu lệnh:#sql iterator Books (String title, Float price);

Câu lệnh này tạo ra một Java class mới.

• Tạo một đối tượng Iterator Object từ Iterator Class: Chúng ta tạo mộtiterator của chúng ta thông qua câu lệnh Books books;.

• Khởi tạo một Iterator sử dụng một câu lệnh SQL: Trong ví dụ của chúng tasử dụng câu lệnh #sql books = ....

• Lặp, đọc các dòng từ một đối tượng Iterator: Bước này tương tự như việcđọc các dòng trong một đối tượng ResultSet của JDBC.

• Đóng đối tượng Iterator.

Có hai kiểu của lớp Iterator: named iterators và positional iterators. Với namediterators, chúng ta chỉ rõ cả kiểu biến và tên của mỗi cột trong một iterator. Điều nàycho phép chúng ta truy cập tới các cột riêng lẻ bằng tên như trong ví dụ trước, chúngta có thể truy cập tới cột title trong bảng Books sử dụng biểu thức books.title(). Vớipositional iterators, chúng ta chỉ cần chỉ rõ kiểu biến của mỗi cột trong một iterator.Để truy cập tới các cột riêng lẻ, chúng ta sử dụng cấu trúc FETCH . . . INTO, tương tựnhư trong Embedded SQL. Cả hai kiểu iterator trên cho cùng một kết qủa, sử dụng cáchnào tuỳ thuộc vào người lập trình.

Hãy cùng xem ví dụ của chúng tôi. Chúng tôi tạo một positional iterator thông qua câulệnh sau:

222/470

#sql iterator Books (String, Float); Sau đó chúng ta truycấp đến từng dòng như sau: while (true) { #sql { FETCH:books INTO :title, :price, }; if (books.endFetch()) {break; } // process the book }

Store procedures

Một điều quan trọng chúng ta cần phải biết là một số phần của chương trình ứng dụngnên được thực thi trực tiếp trong hệ thống cơ sở dữ liệu. Lợi ích của việc này là giảmđược sự trao đổi một lượng lớn dữ liệu giữa máy chủ chứa cơ sở dữ liệu và máy trạm,thêm nữa nó cũng tận dụng được năng lực mạnh mẽ của các máy chủ.

Khi các câu lệnh SQL được phát ra từ một ứng dụng ở xa, các bản ghi trong kết quảcủa truy vấn cần được chuyển từ máy chủ tới các máy trạm. Nếu chúng ta sử dụng mộtcon trỏ để truy cập tới kết quả của câu lệnh SQL, hệ quản trị cơ sở dữ liệu có nhữngtính năng như các khoá và bộ nhớ phải thực hiện nhiệm vụ của nó trong khi ứng dụngđó đang xử lý các bản ghi mà con trỏ đó truy cập. Ngược lại, một stored procedure làmột chương trình có thể được thực thi và hoàn thành trong không gian làm việc của máychủ. Những kết quả có thể được đóng gói và trả về cho ứng dụng, hoặc ứng dụng này cóthể được thực hiện trực tiếp trên máy chủ, không cần trao đổi kết quả liên tục với máytrạm.

Stored procedures cũng có nhiều lợi ích đối với người lập trình phần mềm. Khi mộtstored procedure được đăng ký tại một máy chủ, những người sử dụng khác có thể tái sửdụng stored procedure này. Thêm nữa, những người lập trình ứng dụng không cần phảibiết lược đồ cơ sở dữ liệu nếu chúng ta tóm lược được tất cả các truy cập tới cơ sở dữliệu trong các stored procedures.

Tạo một stored procedure đơn giản

Hãy cùng nhau theo dõi một ví dụ về stored procedure viết bằng SQL. Chúng tanhìn thấy rằng các stored procedure phải được đặt tên; stored procedure này có tên là‘ShowNumberOfOrders’. Mặt khác, nó chỉ chứa một câu lệnh SQL đã được biên dịchvà lưu trữ trên máy chủ.

CREATE PROCEDURE ShowNumberOfOrders SELECT C.cid, C.cname,COUNT(*) FROM Customers C, Orders O WHERE C.cid = O.cidGROUP BY C.cid, C.cnameMột Stored Procedures trong SQL

Stored procedures cũng có thể chứa biến. Những biến này phải có kiểu dữ liệu giốngkiểu dữ liệu của SQL, và là một trong ba dạng sau: IN, OUT, hoặc INOUT. Các biếndạng IN là các tham số được lưu trong stored procedure. Các biến dạng OUT đượcstored procedure đó trả về. Các biến INOUT kết hợp những tính chất của biến dạng IN

223/470

và OUT. Stored procedures kiểm tra chặt chẽ khi có sự so sánh giữa các kiểu dữ liệu:Nếu một biến có kiểu là INTEGER, nó sẽ không thể được gọi bằng một tham số có kiểuVARCHAR. Hãy cùng chúng tôi xem ví dụ về một stored procedure có các tham số.Stored procedure này trong Hình 6.9 có hai tham số: book_isbn và addedQty.

CREATE PROCEDURE AddInventory ( IN book_isbn CHAR(10), INaddedQty INTEGER) UPDATE Books SET qty_in_stock =qty_in_stock + addedQty WHERE book_isbn = isbnMột StoredProcedure có tham số

Stored procedures không phải được viết bằng SQL; chúng có thể được viết bằng ngônngữ lập trình. Như stored procedures là một hàm Java được thực hiện linh động trênmáy chủ ngay khi có một yêu cầu từ một máy trạm nào đó.

CREATE PROCEDURE RankCustomers(IN number INTEGER) LANGUAGEJava EXTERNAL NAME 'file:///c:/storedProcedures/rank.jar'Một Stored Procedure trong Java

Việc gọi Stored Procedures

Stored procedures có thể được gọi trong SQL cùng với câu lệnh CALL:

CALL storedProcedureName(argumentl, argument2, . . . ,argumentN)

Trong Embedded SQL, các tham số của một stored procedure thường là các biến trongngôn ngữ lập trình. Ví dụ. stored procedure AddInventory sẽ được gọi như sau:

EXEC SQL BEGIN DECLARE SECTION char isbn[10]; long qty;EXEC SQL END DECLARE SECTION //set isbn and qty to somevalues EXEC SQL CALL AddInventory(:isbn,:qty);

Việc gọi các Stored Procedures từ JDBC

Chúng ta có thể gọi các stored procedure từ JDBC sử dụng một lớp làCallableStatement. CallableStatement là một lớp con của lớp PreparedStatement vàcung cấp những tính năng tương tự. Một stored procedure có thể chứa nhiều câu lệnhSQL. Chúng ta minh hoạ trường hợp khi kết quả của một stored procedure là mộtResultSet đơn.

CallableStatement cstmt= con.prepareCall(" {callShowNumberOfOrders}"); ResultSet rs = cstmt.executeQuery()while (rs.next()) …

224/470

Việc gọi các Stored Procedures từ SQLJ

Thủ tục “ShowNumberOfOrders” được gọi như sau khi sử dụng SQLJ:

//create the cursor class z#sql Iterator CustomerInfo(intcid, String cname, int count); //create the cursorCustomerInfo customerinfo; //call the stored procedure#sql customerinfo = {CALL ShowNumberOfOrders} while(customerinfo.next()) {ra>System.out.println(custoinerinfo.cid()+"," +customerinfo.count ()); }

SQL/PSM

Tất cả các hệ thống cơ sở dữ liệu đều cung cấp các cách thức để người dùng dễ dàng viếtcác stored procedures một cách đơn giản. Trong phần này, chúng tôi sẽ giới thiệu tómtắt về chuẩn SQL/PSM, nó là một đại diện của hầu hết các ngôn ngữ của các nhà cungcấp khác nhau. Trong PSM, chúng ta định nghĩa các modun, là tập hợp của các storedprocedures, các quan hệ tạm thời, và các khai báo khác.

Trong SQL/PSM, chúng ta định nghĩa một stored procedure như sau:

CREATE PROCEDURE name(parameterl,..., parameterN) localvariable declarations procedure code;

Chúng ta có thể khai báo một hàm (function) đơn giản như sau:

CREATE FUNCTION name (parameterl,..., parameterN) RETURNSsqlDataType local variable declarations function code;

Mỗi một biến nằm trong một trong số ba dạng (IN, OUT, hoặc INOUT) như đã trình bàytrong phần trước, tên biến, và kiểu dữ liệu SQL của biến đó. Chúng ta có thể nhìn thấycác thủ tục SQL/PSM trong phần 6.5.1. Trong trường hợp này, một biến địa phươngkhai báo là rỗng, và đoạn mã lệnh của thủ tục này chứa một truy vấn SQL.

Chúng ta bắt đầu bằng một ví dụ của hàm SQL/PSM minh hoạ cấu trúc chính của SQL/PSM. Hàm này có đầu vào là một khách hàng được xác định bằng cid của cô ấy và mộtnăm (year) nào đó. Hàm này trả về thứ hạng rating của khách hàng đó, thứ hạng nàyđược định nghĩa như sau: Những khách hàng đã mua nhiều hơn 10 quyển sách trongnăm đó được xếp hạng hai (two); khách hàng mua từ 5 đến 10 quyển được xếp hạng làmột (one); những trường hợp khác được xếp hạng là không (zero). Đoạn mã lệnh đưa raxếp hạng của một khách hàng trong một năm nào đó là:

225/470

CREATE PROCEDURE RateCustomer (IN custid INTEGER, IN yearINTEGER) RETURNS INTEGER DECLARE rating INTEGER; DECLAREnumOrders INTEGER; SET numOrders = (SELECT COUNT(*) FROMOrders O WHERE O.cid = custid); IF (numOrders>10) THENrating=2; ELSEIF (numOrders>5) THEN rating=l; ELSErating=0; END IF; RETURN rating;

Thông qua ví dụ này chúng ta hãy cùng tìm hiểu ngắn gọn về một số cấu trúc của SQL/PSM:

• Chúng ta có thể khai báo các biến địa phương sử dụng lệnh DECLARE. Trongví dụ của chúng ta, chúng ta khai báo hai biến địa phương là rating, vànumOrders.

• Các PSM/SQL trả về giá trị thông qua câu lệnh RETURN. Trong ví dụ củachúng ta, chúng ta trả về một giá trị của biến địa phương là rating.

• Chúng ta có thể gán những giá trị cho các biến cùng với câu lệnh SET. Trong vídụ của chúng ta, chúng ta gán giá trị trả về của một truy vấn cho biếnnumOrders.

• SQL/PSM có sử dụng cấu trúc rẽ nhánh và lặp. Cấu trúc rẽ nhánh có dạng nhưsau:

IF (condition) THEN statements; ELSEIF statements; …ELSEIF statements; ELSE statements; END IF

Cấu trúc lặp có dạng như sau:

LOOP Statements; END LOOP• Các truy vấn có thể được sử dụng như là một phần của các biểu thức trong cấu

trúc rẽ nhánh: các truy vấn trả về một giá trị đơn có thể được gán cho biếngiống như ví dụ trên.

• Chúng ta có thể sử dụng các câu lệnh của con trỏ như trong Embedded SQL(OPEN, FETCH, CLOSE), nhưng chúng ta không cần cấu trúc EXEC SQL, vàcác biến không phải có tiền tố là dấu “:”.

Trên đây chỉ là tổng quan rất ngắn gọn về SQL/PSM, các tham chiếu liệt kê ở cuốichương sẽ cung cấp nhiều thông tin hơn.

Trường hợp nghiên cứu: Cửa hàng Internet

DBDudes đã hoàn thành việc thiết kế cơ sở dữ liệu logic trong Phần 3.8, và bây giờ xemxét các truy vấn mà chúng phải hỗ trợ. Họ hy vọng ứng dụng của họ sẽ được viết bằngJava, vì thế họ xem xét JDBC và SQLJ.

Xem lại lược đồ cơ sở dữ liệu của DBDudes:

226/470

Books(isbn: CHAR(10), title:CHAR(8), author:CHAR(80),

qty_in_stock:INTEGER, price: REAL, year_published: INTEGER)

Customers(cid: INTEGER, cname: CHAR(80), address: CHAR(200))

Orders (ordernum: INTEGER, isbn: CHAR (10), cid: INTEGER,

cardnum: CHAR(16), qty:INTEGER,order_date:DATE,ship_date: DATE)

Bây giờ, DBDudes xem xét các kiểu của yêu cầu truy vấn và cập nhật. Đầu tiên, họ tạora một danh sách các công việc phải thực hiện trong ứng dụng.

Những công việc này được các khách hàng thực hiện, bao gồm:

• Các khách hàng tìm sách thông qua tên tác giả (author name), tiều đề (title),hoặc mã ISBN.

• Các khách hàng đăng ký với website này. Những khách hàng đã đăng ký có thểmuốn thay đổi thông tin của họ. DBDudes tin rằng họ phải thêm thông tin vàobảng Customers để lưu giữ login và password của mỗi khách hàng, chúng takhông bàn đến khía cạnh này thêm nữa.

• Các khách hàng kiểm tra giỏ hàng của mình lần cuối cùng trước khi thanh toán.• Các khách hàng có thể thêm hoặc bỏ bớt sách đã lựa chọn ra khỏi giỏ hàng.• Các khách hàng kiểm tra trạng thái của các hoá đơn đang tồn tại và xem xét

những hoá đơn cũ.

Những công việc hành chính được các nhân viên của B&N thực hiện bao gồm:

• Nhân viên tìm kiếm thông tin liên lạc của khách hàng.• Nhân viên thêm các quyển sách mới vào kho.• Nhân viên hoàn tất những hoá đơn, và cần phải cập nhật ngày giao hàng của

từng quyển sách.• Nhân viên phân tích dữ liệu để tìm ra những khách hàng tiềm năng và những

khách hàng yêu thích để gửi cho họ những chiến dịch bán hàng đặc biệt.

Tiếp đến, DBDudes xem xét các kiểu truy vấn để có thể đáp ứng được những yêu cầunày. Để hỗ trợ tìm kiếm sách theo tên, tác giả, tiêu đề, hoặc mã ISBN, DBDudes quyếtđịnh viết một thủ tục như sau:

CREATE PROCEDURE SearchByISBN (IN bookIsbn CHAR(10))SELECT B.title, B.author, B.qty_in_stock, B.price,B.year_published FROM Books B WHERE B.isbn = bookIsb

227/470

Việc đặt một hoá đơn nào đó bao gồm việc thêm một hoặc nhiều bản ghi vào trong bảngOrders. Vì DBDudes không lựa chọn Java để viết chương trình, họ giả sử rằng nhữngquyển sách riêng lẻ trong một hoá đơn được lưu ở lớp ứng dụng trong một mảng củaJava. Để hoàn thành hoá đơn, họ viết một đoạn mã JDBC để thêm những thành phầncủa mảng vào trong bảng Orders. Giả sử rằng đoạn mã có một số biến Java đã được khaibáo trước.

String sql = "INSERT INTO Orders VALUES(?, ?, ?, ?, ?,?)"; PreparedStatement pstmt = con.prepareStatement(sql);con.setAutoCommit(false); try { // orderList is a vectorof Order objects // ordernum is the current order number// cid is the ID of the customer, cardnum is the creditcard number for (int i=0; i<orderList.length(); i++) //now instantiate the parameters with values OrdercurrentOrder = orderList [i]; pstmt.clearParameters();pstmt.setInt(l, ordernum): pstmt.setString(2,Order.getIsbn()); pstmt.setInt(3, cid); pstmt.setString(4,creditCardNum); pstmt.setInt(5. Order.getQtyO);pstmt.setDate(6, null); pstmt.executeUpdate(); }con.commit (); catch(SQLException e){ con.rollback();System.out.println(e.getMessage()); } Thêm một hoá đơn đãhoàn thành vào cơ sở dữ liệu

DBDudes viết đoạn mã lệnh JDBC khác và các stored procedures khác cho tất cả cáccông việc còn lại. Họ sử dụng đoạn mã tương tự với một số chương trình mà chúng tađã thấy trong chương này.

• Việc thành lập một kết nối tới một cơ sở dữ liệu được minh hoạ trong Hình 6.2.• Việc thêm sách mới vào kho, Hình 6.3.• Việc xử lý những kết quả từ các truy vấn SQL, Hình 6.4.• Với mỗi khách hàng, chỉ ra bao nhiêu hoá đơn cô, anh ấy đã đặt. Chúng tôi chỉ

ra một ví dụ về stored procedure đơn giản trong Hình 6.8.• Việc tăng số lượng bản sách của một quyển sách, Hình 6.9.• Xếp hạng khách hàng theo số lượng sách họ đã mua, Hình 6.10.

DBDudes cũng đã xử lý những trường hợp đặc biệt và những cảnh báo, Hình 6.6.

DBDudes cũng đã quyết định viết một trigger. Bất cứ khi nào một hoá đơn mớiđược thêm vào bảng Orders, nó được thêm cùng với trường ship_date được thiết đặtthành null. Trigger này xử lý mỗi dòng trong hoá đơn và gọi đến stored procedure là‘UpdateShipDate’. Stored procedure này (đoạn mã lệnh không được chỉ ra ở đây) cậpnhật trường ship_date cho mỗi hoá đơn mới thành ‘tomorrow’, trong trường hợp trường

228/470

qty_in_stock của quyển sách tương ứng trong bảng Books lớn hơn zero. Ngược lại,stored procedure này thiết đặt trường ship_date lên hai tuần.

CREATE TRIGGER update_ShipDate AFTER INSERT ON Orders /*Event */ FOR EACH ROW BEGIN CALL UpdateShipDate(new); END/* Action */Trigger to Update the Shipping Date of NewOrders

Câu hỏi ôn tập

Những câu trả lời của các câu hỏi sau có thể tìm thấy trong mục kèm theo.

• Vì sao không dễ dàng để kết hợp các truy vấn SQL với một ngôn ngữ lập trìnhnào đó? (Phần 1.1)

• Chúng ta khai báo các biến trong Embedded SQL thế nào? (Phần 1.1)• Chúng ta sử dụng các câu lệnh SQL trong ngôn ngữ lập trình như thế nào? Như

thế nào để kiểm tra lỗi khi thực thi các câu lệnh này? (Phần 1.1)• Các tính chất của con trỏ? (Phần 1.2)• Dynamic SQL là gì và nó khác với Embedded SQL như thế nào? (Phần 1.3)• JDBC là gì và những ưu điểm của nó? (Phần 2)• Những thành phần của kiến trúc JDBC? (Phần 2.1)• Làm thế nào để tải các JDBC drivers trong một chương trình viết bằng Java?

(Phần 3.1)• Chúng ta quản lý các kết nối tới nguồn dữ liệu như thế nào? Những tính chất

của các kết nối? (Phần 3.2)• Những khả năng mà JDBC cung cấp để thực hiện các câu lệnh SQL DML và

DDL? (Phần 3.3)• Chúng ta quản lý các exceptions và warnings trong JDBC như thế nào? (Phần

3.5)• Những tính năng mà lớpDatabaseMetaData là gì? (Phần 3.6)• SQLJ là gì và nó khác với JDBC thế nào? (Phần 4)• Vì sao stored procedures quan trọng? Khai báo stored procedures như thế nào

và gọi thế nào trong chương trình ứng dụng? (Phần 5)

Bài tập

Trả lời tóm tắt các câu hỏi sau.

1. Giải thích các khái niệm sau: Cursor, Embedded SQL, JDBC, SQLJ, storedprocedure.

2. Sự khác nhau giữa JDBC và SQLJ? Vì sao cả hai cùng tồn tại?

229/470

3. Giải thích khái niệm stored procedure, và cung cấp một ví dụ để giải thích vì saochúng hữu dụng?

Trả lời: Câu trả lời với mỗi câu hỏi như sau:

1. Một con trỏ có thể truy cập một dòng nào đó của quan hệ và đọc nội dung của nó.Embedded SQL được coi là các câu lệnh SQL trong ngôn ngữ lập trình trên máy trạm.JDBC viết tắt của Java DataBase Connectivity, là giao diện cho phép một chương trìnhJava kết nối dễ dàng với bất kỳ hệ thống cơ sở dữ liệu nào. SQLJ là công cụ cho phépSQL được nhúng trực tiếp vào một chương trình Java nào đó. Một stored procedurelà chương trình chạy trên máy chủ cơ sở dữ liệu và có thể được gọi bằng một câu lệnhSQL.

2. SQLJ cung cấp các câu lệnh nhúng SQL. Những câu lệnh này là tĩnh và vì thế đượctiền xử lý và tiền biên dịch. Với từng trường hợp, việc kiểm tra cú pháp và kiểm tra lượcđồ được làm tại thời điểm biên dịch. JDBC cho phép các truy vấn động-những truy vấnđược kiểm tra ở thời gian chạy. SQLJ dễ sử dụng hơn JDBS và thường là lựa chọn tốthơn cho các truy vấn tĩnh. Với các truy vấn động, JDBC vẫn phải được sử dụng.

3. Stored procedures là các chương trình chạy trên máy chủ cơ sở dữ liệu và có thểđược gọi bằng một câu lệnh SQL. Chúng hữu dụng trong một số trường hợp nơi mà việcxử lý nên được làm bên phía máy chủ tốt hơn là bên phía máy trạm. Cũng như vậy, vìnhững thủ tục được tập trung ở phía mãy chủ, nên việc viết chương trình và bảo trì rấtđơn giản. Các Stored procedures có thể cũng được sử dụng để giảm kết nối mạng; kếtquả của một stored procedure nào đó có thể được phân tích và lưu giữ trên máy chủ cơsở dữ liệu.

Giải thích cách các bước sau được thực hiện trong JDBC:

1. Kết nối tới một nguồn dữ liệu.

2. Khởi động, hoàn thành, và huỷ bỏ các giao dịch.

3. Gọi một stored procedure.

Các bước này được thực hiện trong SQLJ thế nào?

Trả lời: Dành cho độc giả

So sánh việc quản lý các exception và warning trong embedded SQL, dynamic SQL,JDBC, và SQLJ.

Trả lời: Câu trả lời với mỗi câu hỏi như sau:

230/470

Embedded SQL: Biến SQLSTATE được sử dụng để kiểm tra các lỗi sau khi từng câulệnh Embedded SQL được thực hiện. Nếu một lỗi nào đó xảy ra, bộ điều khiển sẽ đưa ramột thông báo lỗi. Điều này được làm trong suốt quá trình tiền biên dịch của mỗi truyvấn tĩnh.

Dynamic SQL: Với dynamic SQL, câu lệnh SQL có thể thay đổi ở thời gian chạy và vìthế việc quản lý lỗi cũng phải xảy ra ở thời điểm này.

JDBC: Trong JDBC, người lập trình có thể sử dụng cú pháp try ... catchđể quản lý cácngoại lệ của kiểu SQLException. Lớp SQLWarningđược sử dụng cho những vấn đề khắtkhe như là các lỗi chương trình. Chúng không nắm bắt được bằng câu lệnh try ... catchvà phải được kiểm tra độc lập bằng cách gọi hàm getWarnings().

SQLJ: SQLJ sử dụng các cơ chế như JDBC để nắm bắt lỗi (errors) và lời nhắc(warnings).

Trả lời những câu hỏi sau.

1. Vì sao chúng ta cần tiền biên dịch Embedded SQL và SQLJ? Vì sao lại khôngcần nó trong JDBC?

2. SQLJ và Embedded SQL sử dụng các biến trong ngôn ngữ lập trình để gán chocác tham số trong các truy vấn SQL, trong khi JDBC sử dụng những ký tự đạidiện ‘?’. Giải thích sự khác nhau này, và vì sao lại cần như vậy?

Trả lời: Dành cho độc giả

Một trang Web động đưa ra những trang HTML lấy thông tin từ cơ sở dữ liệu. Bất cứkhi nào một trang được yêu cầu, nó linh động tập hợp dữ liệu từ những dữ liệu tĩnh vànhững dữ liệu trong cơ sở dữ liệu. Việc kết nối tới một cơ sở dữ liệu thường tốn nhiềuthời gian, vì cần phải định vị những tài nguyên, và cần phải xác định quyền truy cập củanhững người dùng. Vì thế, connection pooling- thiết lập một bể của các kết nối đang tồntại và sau đó sử dụng lại chúng cho những yêu cầu khác nhau nhằm cải thiện hiệu năngthực hiện của hệ thống. Vì thế, các máy chủ có thể lưu giữ thông tin của các kết nối,chúng ta có thể tạo ra một bể kết nối, và định vị nguồn tài nguyên khi có một yêu cầumới.

Viết một lớp bể kết nối cung cấp các phương thức sau:

• Tạo ra một bể (pool) với một số lượng xác định các kết nối tới một hệ thống cơsở dữ liệu.

• Nhận được một kết nối mở từ bể.• Huỷ bỏ một kết nối trong bể.• Huỷ bỏ bể và đóng tất cả các kết nối.

231/470

Trả lời: Câu trả lời cho bài tập này được hỗ trợ trực tiếp cho các giáo viên. Cách thứcđể truy cập đến các tài nguyên của giáo viên được nêu trong trang chủ của cuốn sáchnày:

http://www.cs.wisc.edu/~dbbook.

Bài tập lớn

Trong những bài tập sau, bạn sẽ tạo ra những ứng dụng có liên quan đến cơ sở dữ liệu.Trong chương này, bạn sẽ tạo ra các phần khác nhau của một ứng dụng có truy cập tớicơ sở dữ liệu. Trong chương tiếp theo, bạn sẽ lập trình thêm những chức năng khác củaứng dụng. Chi tiết thông tin về những bài tập và những tài liệu khác có thể tìm thấy tạiđịa chỉ:

http://www.cs.wisc.edu/ dbbook

Bài 6.6 Nhớ lại thiết kế cơ sở dữ liệu bạn đã làm trong Bài 2.5 và 3.15. Bây giờ bạn sẽbắt đầu việc thiết kế website cho Notown. Những tính năng sau nên được hỗ trợ:

• Người dùng có thể tìm kiếm các đĩa nhạc thông qua tên nhạc sỹ, tiêu đề củaalbum, và tên của bài hát.

• Người dùng có thể đăng ký làm thành viên của website này, và những ngườidùng đã đăng ký có thể đăng nhập được. Khi người dùng đã đăng nhập, họkhông nên phải đăng nhập lại trừ khi họ không hoạt động trong một thời giandài.

• Người dùng đã đăng nhập vào website có thể thêm những mặt hàng vào giỏhàng của họ.

• Người dùng có thể thanh toán giỏ hàng họ đã mua.

Notown muốn sử dụng JDBC để truy cập cơ sở dữ liệu. Viết chương trình bằng để thựchiện truy cập và thao tác dữ liệu cần. Bạn sẽ tích hợp đoạn chương trình này với chươngtrình ứng dụng và trình bày trong chương kế tiếp. Nếu Notown đã được lựa chọn SQLJthay vì JDBC, chương trình của bạn sẽ thay đổi như thế nào?

Bài 6.7 Nhớ lại lược đồ cơ sở dữ liệu của Prescriptions-R-X mà bạn tạo ra ở Bài 2.7.Prescriptions-R-X yêu cầu bạn thiết kế trang web mới cho họ. Website này có hai lớpngười dùng khác nhau: bác sĩ và bệnh nhân. Bác sĩ sẽ có thể nhập những đơn thuốc mớicho bệnh nhân của mình và sửa đổi những đơn thuốc đang tồn tại. Bệnh nhân có thểtrình báo mình là bệnh nhân của bác sĩ nào; họ có thể kiểm tra trạng thái những đơnthuốc một cách trực tuyến, và có thể đặt mua những đơn thuốc đó để các nhà cung cấpcó thể mang đến tận nhà của họ. Làm theo các bước tương tự như Bài 6.6 để viết chươngtrình bằng JDBC thực hiện truy cập và thao tác trên những dữ liệu cần thiết. Bạn sẽ tíchhợp đoạn chương trình này với ứng dụng và trình bày trong chương kế tiếp.

232/470

Bài 6.8 Nhớ lại lược đồ cơ sở dữ liệu bạn đã làm trong bài 5.1. Trường đại học này đãquyết định chuyển việc đăng ký học tới một hệ thống trực tuyến. Website này có hai lớpngười dùng khác nhau: khoa và sinh viên. Khoa sẽ có thể tạo mới và xóa các khóa họchiện có, và sinh viên sẽ có thể đăng ký vào các khóa học này.

Làm theo các bước tương tự như Bài 6.6 để viết chương trình bằng JDBC thực hiện truycập và thao tác trên những dữ liệu cần thiết. Bạn sẽ tích hợp đoạn chương trình này vớiứng dụng và trình bày trong chương kế tiếp.

Bài 6.9 Nhớ lại lược đồ cơ sở dữ liệu Đặt vé máy bay bạn đã làm trong bài 5.3. Hệ thốngnày có hai lớp người dùng khác nhau: nhân viên hãng hàng không và khách hàng. Nhânviên có thể lập lịch cho những chuyến bay mới và có thể huỷ bỏ các chuyến bay. Kháchhàng có thể đặt vé máy bay trên các chuyến bay đang tồn tại.

Làm theo các bước tương tự như Bài 6.6 để viết chương trình bằng JDBC thực hiện truycập và thao tác trên những dữ liệu cần thiết. Bạn sẽ tích hợp đoạn chương trình này vớiứng dụng và trình bày trong chương kế tiếp.

Tài liệu tham khảo

Thông tin về ODBC có thể được tìm thấy trên trang web của Microsoft(www.microsoft.com/data/ODBC), và các thông tin về JDBC có thể được tìm thấy trêntrang web của Java (Java.sun.com/products/jdbc). Hiện tồn tại nhiều sách về ODBC, vídụ, Sanders' ODBC Developer's Guide [652] và Microsoft ODBC SDK [533]. Nhữngquyển sách về JDBC của Hamilton et al. [359], Reese [621], và White et al. [773].

233/470

Các ứng dụng InternetGiới Thiệu

Sự gia tăng của các mạng máy tính, bao gồm cả Internet và ‘intranets’ đã giúp cho ngườidùng có thể truy cập tới một số lượng lớn các nguồn dữ liệu. Điều này đã làm tăng truycập tới cơ sở dữ liệu cũng như phát triển những ứng dụng thực tế có tầm ảnh hưởng lớn;dữ liệu và các dịch vụ được cung cấp trực tiếp cho các khách hàng. Ví dụ những ứngdụng thương mại điện tử như mua sách trực tiếp trên website Amazon.com, tham giađấu giá trực tuyến tại website eBay, và trao đổi thông tin về sản phẩm giữa các công ty.Sự ra đời các chuẩn như XML nhằm biểu diễn nội dung của các tài liệu đã thúc đẩy sựphát triển của thương mại điện tử và các ứng dụng trực tuyến khác.

Trong khi các thế hệ đầu tiên của Internet là tập hợp của những file HTML, thì ngày nayhầu hết các Website đều lưu trữ một phần lớn (nếu không phải tất cả) các dữ liệu trongcác hệ thống cơ sở dữ liệu. Họ dựa vào DBMSs để cung cấp một cách nhanh chóng vàđáng tin cậy những yêu cầu của người dùng trên Internet. Điều này đặc biệt đúng đốivới những website thương mại điện tử và những ứng dụng thương mại.

Trong chương này, chúng tôi trình bày tổng quan về những khái niệm chủ yếu để pháttriển ứng dụng Internet. Chúng tôi bắt đầu với câu hỏi Internet làm việc như thế nàotrong Phần 2. Chúng tôi giới thiệu HTML và XML, hai định dạng dữ liệu được sử dụngđể biểu diễn dữ liệu trên Internet, trong Phần 3 và 4. Trong Phần 5, chúng tôi giới thiệuvề kiến trúc ba lớp, một cách để tổ chức các ứng dụng Internet vào các lớp khác nhautheo chức năng của nó. Trong Phần 6 và 7, chúng tôi mô tả các lớp và trình bày chitiết lớp giữa; DBMSs là lớp thứ ba. Chúng tôi kết luận chương này bằng việc thảo luậntrường hợp nghiên cứu B & N trong Phần 8.

Những ví dụ xuất hiện trong chương này có thể tìm thấy trên website:

http://www.cs.wise.edu/~ dbbook

Những khái niệm về INTERNET

Internet đã nổi lên như một kết nối tổng hợp giữa các hệ thống phần mềm phân tán. Đểhiểu được nó làm việc như thế nào, chúng ta bắt đầu bằng việc tìm hiểu hai vấn đề cơbản: Các trang trên Internet được định vị thế nào, và các chương trình trên một trang kếtnối với các trang khác như thế nào. Đầu tiên, chúng ta giới thiệu về Uniform ResourceIdentifiers (URI), một sơ đồ tên của các nguồn tài nguyên trên Internet trong Phần 2.1.Sau đó, chúng tôi nói về giao thức phổ dụng nhất cho phép truy cập đến các nguồn tàinguyên trên Web đó là HyperText Transfer Protocol (HTTP) trong Phần 2.2.

234/470

Uniform Resource Identifiers

Uniform Resource Identifiers (URIs) là những xâu ký tự giúp định danh duy nhất chonhững nguồn tài nguyên trên Internet. Một nguồn tài nguyên là bất kỳ loại thông tinnào có thể được xác định bởi một URI, ví dụ các trang web, hình ảnh, những file có thểtải về, các dịch vụ có thể được điều khiển từ xa, hộp thư, vv… Loại tài nguyên phổ biếnnhất là các tập tin tĩnh (tài liệu HTML), nhưng cũng có thể là các tệp tin HTML độngđược xuất ra từ cơ sở dữ liệu, hay là một bộ phim, hoặc dữ liệu đầu ra của một chươngtrình, vv…

Một URI có ba phần:

• (Tên của) giao thức được sử dụng để truy cập nguồn tài nguyên.• Các máy vi tính lưu trữ các nguồn tài nguyên.• Tên đường dẫn đến nguồn tài nguyên chính trên máy tính.

Xem xét một ví dụ URI: http://www.bookstore.com/index.html.

URI này có thể được giải thích như sau. Sử dụng giao thức HTTP (giải thích trong phầnkế tiếp), để lấy tài liệu index.html nằm trên máy tính www.bookstore.com. Một ví dụkhác, đoạn HTML sau đây chỉ ra một URI là một địa chỉ email:

<a href="mailto:webmaster@bookstore.com">Email thewebmaster.</a>

The Hypertext Transfer Protocol (HTTP)

Một giao thức là một bộ tiêu chuẩn định nghĩa cấu trúc của các thông điệp giao tiếpgiữa hai bên kết nối để chúng có thể hiểu được nhau. The Hypertext Transfer Protocol(HTTP) là giao thức phổ biến nhất được sử dụng trên Internet. Đó là giao thức máytrạm-máy chủ (client-server), trong đó máy trạm (thường là một trình duyệt Web) gửimột yêu cầu tới một máy chủ HTTP, máy chủ này sẽ trả lại kết quả cho máy trạm. Khimột người dùng yêu cầu một trang web (ví dụ, nhấp chuột vào một siêu liên kết), trìnhduyệt gửi HTTP request messagestới máy chủ. Các máy chủ nhận được các yêu cầu vàtrả lời bằng HTTP response messages bao gồm các đối tượng. Điều quan trọng có thểnhận ra là HTTP được sử dụng để truyền tải tất cả các loại tài nguyên, không chỉ các tậptin, nhưng hầu hết các nguồn tài nguyên trên Internet ngày nay là các tệp tin tĩnh hoặccác scrip xuất ra từ máy chủ.

Một biến thể của giao thức HTTP gọi là giao thức Secure Sockets Layer (SSL) sử dụngmã hóa an toàn để trao đổi thông tin giữa máy trạm và máy chủ. Chúng ta hoãn thảoluận về SSL tới Phần 21.5.2 và trình bày những giao thức HTTP cơ bản trong chươngnày.

235/470

Ví dụ, xem xét những gì sẽ xảy ra nếu một người dùng nhấn vào liên kết sau:http://www.bookstore.com/index.html. Đầu tiên, chúng tôi giải thích cấu trúc của mộtHTTP request message và sau đó là cấu trúc của một HTTP response message.

HTTP Requests

Máy trạm (Web brower) thành lập một kết nối tới webserver và gửi một HTTP requestmessage. Ví dụ sau đây chỉ ra một ví dụ về HTTP request message.

GET index.html HTTP/1.1 User-agent: Mozilla/4.0 Accept:text/html, image/gif, image/jpeg

HTTP Responses

Máy chủ sẽ trả về cho máy trạm một HTTP response message. Nó truy cập trangindex.html, sử dụng nó để thu thập những HTTP response message, và gửi nhữngmessage này tới máy trạm. Một ví dụ của HTTP response:

HTTP/1.1 200 OK Date: Mon, 04 Mar 2002 12:00:00 GMTContent-Length: 1024 Content-Type: text/html Last-Modified: Mon, 22 Jun 1998 09:23:24 GMT <HEAD> <HTML><HEAD> </HEAD> <BODY> <Hl>Barns and Nobble InternetBookstore</Hl> Our inventory: <H3>Science</H3> <B>TheCharacter of Physical Law</B> …

• 200 OK: Yêu cầu thành công và đối tượng nằm trong phần thân của responsemessage.

• 400 Bad Request: Mã lỗi chỉ ra rằng yêu cầu không được máy chủ hoàn thành.• 404 Not Found: Đối tượng yêu cầu không tồn tại trên máy chủ.• 505 HTTP Version Not Supported: Phiên bản của giao thức HTTP mà máy

trạm sử dụng không được máy chủ hỗ trợ (Nhớ lại rằng phiên bản của giao thứcnày được nằm trong yêu cầu của máy trạm).

Máy trạm (trình duyệt Web) nhận được response message, đưa ra các tệp tin HTML,phân tích, và hiển thị nó. Trong khi làm điều này, nó có thể tìm thấy thêm những URIstrong các file, và sau đó nó sử dụng giao thức HTTP để lấy những tài nguyên này, mỗimột tài nguyên thiết lập một kết nối mới.

Một vấn đề quan trọng là giao thức HTTP là một giao thức ‘không lưu trạng thái’(stateless protocol). Tất cả các thông báo - từ máy trạm tới HTTP server và ngược lạilà ‘self-contained’, và kết nối thành lập (cùng với một thông báo yêu cầu) được duy trìcho đến khi response message được gửi. Các giao thức cung cấp không có cơ chế để tựđộng 'nhớ' những tương tác trước đó giữa máy trạm và máy chủ.

236/470

Tính chất không lưu trạng thái của giao thức HTTP có ảnh hưởng lớn đến việc các ứngdụng Internet được viết như thế nào. Xem xét một người dùng tương tác với ứng dụngBookstore của chúng ta. Giả định rằng Bookstore cho phép người sử dụng đăng nhậpvào website và sau đó thực hiện một số thao tác, chẳng hạn như đặt một số quyển sáchhoặc thay đổi địa chỉ của họ, mà không cần đăng nhập lại (cho đến khi hết hạn hoặcngười sử dụng đăng xuất). Làm thế nào để chúng ta theo dõi được một người dùng đãđăng nhập hay chưa? Vì HTTP có tính chất ‘không lưu trạng thái’, nên chúng ta khôngthể chuyển sang một trạng thái khác (ví dụ là trạng thái 'đã đăng nhập'). Thay vào đó,với mọi yêu cầu mà người dùng gửi tới máy chủ, chúng ta phải mã hoá mọi thông tintrạng thái nào ứng dụng yêu cầu, ví dụ như tình trạng đăng nhập của người dùng. Thêmnữa, chương trình ứng dụng phía máy chủ phải duy trì thông tin trạng thái này và đápứng khi có yêu cầu. Vấn đề này được trình bày trong Phần 5.

Ghi nhớ rằng sự ‘không lưu trạng thái’ của HTTP được thiết kế dựa trên yêu cầu làmthế nào để cân bằng được giữa sự dễ dàng thực hiện của giao thức HTTP và sự dễ dàngthực hiện của các nhà phát triển ứng dụng. Những người thiết kế ra HTTP lựa chọn cáchthức là giữ cho bản thân giao thức này đơn giản, và nhường lại những chức năng yêucầu đến các đối tượng cho các lớp ứng dụng nằm trên giao thức HTTP.

Văn bản HTML

Trong phần này và phần tiếp theo, chúng tôi tập trung giới thiệu về HTML và XML.Trong Phần 6, chúng tôi đề cập đến cách thức các ứng dụng sử dụng HTML và XMLđể tạo ra các form tiếp nhận những yêu cầu của người dùng, kết nối tới một máy chủHTML, và chuyển những kết quả do lớp quản lý dữ liệu tạo ra vào một trong nhữngđịnh dạng này.

HTML là một ngôn ngữ đơn giản được sử dụng để biểu diễn dữ liệu. Các lệnh trongngôn ngữ này được gọi là thẻ, nó thường có thẻ bắt đầu và thẻ kết thúc có dạng<TAG> và </TAG>. Ví dụ, xem xét đoạn HTML trong Hình 1. Nó mô tả một trangWeb chỉ ra danh sách các quyển sách. Văn bản này nằm gọn trong thẻ <HTML> và</HTML>, chứng tỏ nó là một văn bản HTML. Phần còn lại của văn bản - nằm trong thẻ<BODY> và </BODY> chứa thông tin về ba quyển sách. Dữ liệu về mỗi quyển đượcbiểu diễn như là một danh sách không được sắp xếp (UL) trong đó toàn bộ các thực thểđược đánh dấu bằng thẻ <LI>. HTML định nghĩa một tập các thẻ đúng như là ý nghĩacủa nó. Ví dụ, HTML định nghĩa thẻ <TITLE> với mục đích ghi tiêu đề của văn bản.Một ví dụ khác, thẻ <UL> biểu diễn một danh sách không được sắp xếp. Audio, video,thậm chí là các chương trình Java (được viết trong Java, một ngôn ngữ bậc cao) có thểnằm trong các văn bản HTML. Khi một người dùng truy cập một văn bản sử dụng mộttrình duyệt phù hợp, những hình ảnh trong văn bản được hiển thị, các file audio và videođược bật, và những chương trình nhúng được thực hiện trên máy của người dùng. Sự dễdàng tạo ra những văn bản HTML và dễ dàng truy cập sử dụng trình duyệt Internet làđộng lực cho sự phát triển mạnh mẽ của các trang Web.

237/470

Danh sách các quyển sách trong HTML

Văn bản XML

Trong phần này, chúng tôi giới thiệu XML như là một định dạng văn bàn, và xem xétcách thức các ứng dụng có thể sử dụng XML. Việc quản lý các văn bản XML trong mộtDBMS đặt ra những thách thức mới; chúng ta sẽ bàn đến khía cạnh này của XML trongChương 27.

Trong khi HTML có thể được sử dụng để đánh dấu các văn bản tuỳ vào mục đích hiểnthị, nó không phù hợp để biểu diễn các cấu trúc của một nội dung dùng chung cho nhiềuứng dụng. Ví dụ, chúng ta có thể gửi một văn bản HTML chỉ ra trong Hình 1 tới một

238/470

ứng dụng khác để hiển thị nó, như ứng dụng thứ hai có thể không phân biệt được phầntên đầu (first name) và phần cuối (last name) của các tác giả. (Ứng dụng này có thể cốgắng lấy những thông tin bằng cách tìm những đoạn văn bản nằm bên trong các thẻ,nhưng điều này làm hỏng mục đích sử dụng thẻ để biểu diễn cấu trúc của văn bản). Vìthế, HTML không thích hợp với những văn bản phức tạp.

Extensible Markup Language (XML) là một ngôn ngữ đánh dấu được phát triển đểkhắc phục những tồn tại của ngôn ngữ HTML. Ngược lại với một tập các thẻ cố địnhđược xác định trong ngôn ngữ HTML, XML cho phép người sử dụng định nghĩa mớimột tập các thẻ có thể được sử dụng để cấu trúc bất kỳ loại dữ liệu hay văn bản nàongười dùng mong muốn truyền tải. XML có khả năng làm cho các hệ thống cơ sở dữliệu tích hợp chặt chẽ với những ứng dụng Web hơn bao giờ hết.

XML được xây dựng dựa trên hai công nghệ, SGML và HTML. Standard GeneralizedMarkup Language (SGML) là siêu ngôn ngữ cho phép định nghĩa dữ liệu và trao đổivăn bản như HTML. Chuẩn SGML được công bố vào năm 1998, và rất nhiều tổ chứcquản lý nhiều những văn bản phức tạp đã sử dụng nó. Tuy nhiên, SGML phức tạp vàyêu cầu các chương trình tinh vi mới khai thác được những khả năng của nó. XML đãđược phát triển để có được những tính năng mạnh mẽ của SGML nhưng vẫn khá đơngiản. XML, giống như SGML, cho phép định nghĩa mới những ngôn ngữ đánh dấu vănbản.

Mục đích thiết kế của XML: XML đã được phát triển từ đầu những năm 1996. Mục đíchcủa XML bao gồm:

1. XML nên tương thích với SGML.

2. Dễ dàng viết các chương trình xử lý những văn bản XML.

3. Thiết kế của XML nên có khuôn mẫu và xúc tích.

Giới thiệu XML

Chúng ta sử dụng tài liệu XML trên Hình 2 làm ví dụ.

• Các nguyên tử (element): Các nguyên tử, hay còn gọi là các thẻ, là nhữngkhối chính trong một văn bản XML. Bắt đầu của nội dung một nguyên tử ELMlà được đánh dấu bằng <ELM>, nó được gọi là thẻ bắt đầu, và kết thúc bằngthẻ </ELM>, gọi là thẻ kết thúc. Trong văn bản ví dụ của chúng ta, nguyên tửBOOKLIST đóng tất cả thông tin trong văn bản này.

Thẻ BOOK phân chia dữ liệu thành từng quyển sách đơn. Những thẻ XML phải đượclồng nhau hợp lý. Những thẻ bắt đầu xuất hiện bên trong nội dung của các thẻ khác phảicó thẻ kết thúc tương ứng. Ví dụ, xem xét đoạn XML sau:

239/470

<BOOK> <AUTHOR> <FIRSTNAME>Richard</FIRSTNAME><LASTNAME>Feyninan</LASTNAME> </AUTHOR> </BOOK>

Thẻ AUTHOR nằm trọn vẹn bên trong thẻ BOOK, và cả hai thẻ LASTNAME vàFIRSTNAME nằm trọn vẹn bên trong thẻ AUTHOR.

• Các thuộc tính: Mỗi thẻ có thể có những thuộc tính biểu diễn để cung cấpthêm thông tin. Các giá trị của thuộc tính được thiết đặt ở bên trong thẻ. Chúngta có thể thiết đặt giá trị cho thuộc tính att thông qua biểu thức sau: <ELM att=“value”>. Tất cả các giá trị thuộc tính phải được đặt bên trong dấu ngoặc.Trong Hình 2, nguyên tử BOOK có hai thuộc tính. Thuộc tính GENRE(loại)xác định thể loại của cuốn sách (là sách khoa học hay sách viễn tưởng) và thuộctính FORMAT chỉ quyển sách được đóng có bìa cứng hay bìa mềm.

• Tham chiếu thực thể: Các tham chiếu thực thể là đường tắt tới các phần khácnhau của văn bản hoặc nội dung của các tệp khác, và chúng ta gọi cách sử dụngmột thực thể nào đó trong XML là một tham chiếu thực thể. Bất cứ khi nàomột tham chiếu thực thể xuất hiện trong một văn bản, nó sẽ được thay thế bằngnội dung của nó. Các tham chiếu thực thể được bắt đầu bằng dấu ‘&’ và kếtthúc bằng dấu ‘;’. Năm thực thể được định nghĩa trước trong XML sẽ thay thếcho những ký tự đặc biệt trong XML. Ví dụ, ký tự < dùng để đánh dấu vị trí bắtđầu của một lệnh XML phải được biểu diễn bằng thực thể lt. Bốn ký tự khác là&, >, ”, và ’ được biểu diễn thông qua các thực thể amp, gt, quot và apos. Vídụ, ký hiệu ‘1<5’ phải được mã hoá trong XML như sau: &apos; l &lt; 5&apos;. Chúng ta cũng có thể sử dụng các thực thể để thêm các ký tự Unicodevào trong văn bản. Unicode là một chuẩn để biểu diễn dữ liệu, tương tự nhưASCII.

• Chú thích: Chúng ta có thể thêm chú thích tại vị trí bất kỳ trong văn bản XML.Chú thích bắt đầu bằng <!- và kết thúc bằng ->. Chú thích có thể chứa nhữngký tự bất kỳ, trừ xâu ký tự --.

• Những khai báo kiểu văn bản (Document Type Declarations-DTDs): TrongXML, chúng ta có thể định nghĩa ngôn ngữ đánh dấu của chúng ta. Một DTD làmột tập các quy tắc cho phép chúng ta xác định tập các thẻ, thuộc tính và cácthực thể. Vì thế, một DTD sẽ chỉ rõ những thẻ nào được phép, thứ tự xuất hiệncủa chúng, và chúng có thể được lồng nhau như thế nào. Chúng ta bàn chi tiếtvề DTDs trong phần tiếp theo.

Chúng ta gọi một văn bản XML là định-dạng-tốt nếu nó tuân theo những hướng dẫnsau:

• Văn bản bắt đầu bằng một khai báo XML. Một ví dụ của khai báo XML ở dòngđầu tiên của văn bản chỉ ra trong Hình 2.

• Một thẻ gốc chứa tất cả các thẻ khác. Trong ví dụ của chúng ta, thẻ gốc là thẻBOOKLIST.

240/470

• Tất cả các thẻ phải được lồng nhau. Yêu cầu này có nghĩa là các thẻ bắt đầu vàkết thúc phải xuất hiện cùng nhau.

Thông tin về cuốn sách trong XML

XML DTDs

Một DTD là một tập các quy tắc cho phép chúng ta tự xác định tập các thẻ, thuộc tính,và các thực thể. Một DTD chỉ ra những thẻ nào chúng ta có thể sử dụng và các ràngbuộc trên những thẻ này, ví dụ, các thẻ có thể được lồng nhau như thế nào và các thẻ cóthể xuất hiện ở đâu trong văn bản. Trong phần còn lại của mục này chúng ta sẽ sử dụngví dụ DTD trong Hình 3 để minh hoạ cách thức cấu trúc một các DTD.

241/470

Bookstore XML DTD

Một DTD được đặt trong <!DOCTYPE name [DTDdeclaration] >, trong đó name là têncủa của thẻ ngoài cùng, và DTDdeclaration là các quy tắc của DTD đó. DTD này bắtđầu bằng thẻ ngoài cùng - thẻ gốc- trong ví dụ của chúng ta là thẻ BOOKLIST. Xem xétluật tiếp theo:

<!ELEMENT BOOKLIST (BOOK)*>

Luật này nói với chúng ta rằng thẻ BOOKLIST chứa 0 hoặc nhiều thẻ BOOK. Ký hiệu* đằng sau BOOK xác định có bao nhiêu thẻ BOOK có thể xuất hiện ở bên trong thẻBOOKLIST. Dấu * quy định có 0 hoặc nhiều sự kiện, ký hiệu + quy định có 1 hoặcnhiều sự kiện, và ký hiệu ? quy định 0 hoặc 1 sự kiện. Ví dụ, nếu chúng ta muốn đảmbảo rằng một BOOKLIST có ít nhất một cuốn sách, chúng ta có thể thay đổi quy tắc nàynhư sau:

<!ELEMENT BOOKLIST (BOOK)+>

Hãy cùng chúng tôi xem xét luật tiếp theo:

<!ELEMENT BOOK (AUTHOR,TITLE,PUBLISHED?)>

Luật này chỉ ra rằng một thẻ BOOK sẽ chứa một thẻ AUTHOR, một thẻ TITLE, và mộtthẻ lựa chọn PUBLISHED (có thể có hoặc không). Lưu ý việc sử dụng dấu ? để chỉ rarằng thông tin là không bắt buộc, có 0 hoặc một sự kiện của thẻ này.

Hãy cùng chúng tôi xem xét luật tiếp theo:

<! ELEMENT LASTNAME (#PCDATA)>

242/470

Từ trước đến giờ chúng ta đã chỉ đề cập đến những thẻ chứa những thẻ khác. Quy tắcnày chỉ ra rằng LASTNAME là một thẻ không có chứa thẻ khác bên trong, nhưng nóchứa tập ký tự. Các thẻ chỉ chứa những thẻ khác được nói là có nội dung thẻ, ngược lạinhững thẻ chứa #PCDATA được nói là có nội dung trộn. Thường thì một khai báo thẻcó cấu trúc như sau:

<! ELEMENT (contentType)>

Năm kiểu nội dung cho phép là:

• Những thẻ khác.• Ký hiệu #PCDATA.• Ký hiệu EMPTY, chứng tỏ rằng thẻ này không có nội dung. Các thẻ không có

nội dung không yêu cầu có thẻ đóng.• Ký hiệu ANY, chứng tỏ rằng bất cứ nội dung nào đều được phép. Điều này nên

tránh vì nó sẽ không thể làm những kiểm tra với cấu trúc văn bản ở bên trongthẻ này.

• Một biểu thức thông thường được xây dựng từ bốn lựa chọn tiền tố. Nó có thểnhư sau:

• expl, exp2, exp3: Một danh sách các biểu thức thông thường.• exp*: Một biểu thức có thể lựa chọn (0 hoặc nhiều sự kiện).• exp?: Một biểu thức có thể lựa chọn (0 hoặc một sự kiện).• exp+: Một biểu thức bắt buộc (1 hoặc nhiều sự kiện).• expl | exp2: expl hoặc exp2

Các thuộc tính của thẻ được khai báo bên ngoài thẻ. Ví dụ, xem xét cách khai báo thuộctính trong hình 3:

<!ATTLIST BOOK GENRE (Science|Fiction) #REQUIRED>>

Đoạn XML DTD này khai báo thuộc tính GENRE là thuộc tính của thẻ BOOK. Thuộctính này có hai giá trị: Science và Fiction. Mỗi một thẻ BOOK phải được biểu diễn trongthẻ bắt đầu của nó bằng một thuộc tính GENRE vì thuộc tính này được yêu cầu do đãxác định #REQUIRED. Hãy cùng chúng tôi xem cấu trúc thông thường của một khaibáo thuộc tính DTD:

<!ATTLIST elementName (attName attType default)+>

Từ khoá ATTLIST đánh dấu việc khai báo thuộc tính. Xâu elementName là tên của thẻcó thuộc tính được định nghĩa theo sau. Phần đằng sau là khai báo của một hoặc nhiềuthuộc tính. Mỗi thuộc tính có một tên (attName), và kiểu (attType). XML định nghĩamột số kiểu cho mỗi thuộc tính. Chúng ta chỉ bàn đến các kiểu xâu ký tự và các kiểu dữliệu đếm được ở đây. Một thuộc tính kiểu xâu ký tự có thể mang giá trị của bất kỳ xâu

243/470

ký tự nào. Chúng ta có thể khai báo một thuộc tính với kiểu dữ liệu là CDATA. Ví dụ,chúng ta khai báo thuộc tính kiểu xâu ký tự của thẻ BOOK như sau:

<! ATTLIST BOOK edition CDATA "1">

Nếu một thuộc tính có kiểu dữ liệu đếm được, chúng ta liệt kê tất cả các giá trị của nócó thể nhận trong phần khai báo thuộc tính đó. Trong ví dụ của chúng ta, thuộc tínhGENRE là kiểu đếm được; nó có thể nhận hai giá trị là ‘Science’ và ‘Fiction’.

Thành phần cuối cùng của khai báo thuộc tính là giá trị mặc định của nó. DTD trongHình 3 chỉ ra hai xác định mặc định khác nhau: #REQUIRED và xâu ‘Paperback’. Xácđịnh mặc định #REQUIRED chỉ ra rằng thuộc tính này được yêu cầu và bất cứ khi nàothẻ liên quan đến nó xuất hiện trong XML thì giá trị của thuộc tính cũng phải được xácđịnh. Phần mặc định là xâu ký tự ‘Paperback’ chứng tỏ rằng thuộc tính này không yêucầu bắt buộc phải có; khi thẻ xuất hiện không có giá trị của thuộc tính này thì nó sẽmang giá trị mặc định là ‘Paperback’. Ví dụ, chúng ta có thể xác định giá trị mặc địnhcủa thuộc tính GENRE là ‘Science’ như sau:

<!ATTLIST BOOK GENRE (Science|Fiction) "Science">

Trong ví dụ về Bookstore của chúng ta, tài liệu XML có một tham chiếu tới DTD đượcchỉ ra trong Hình 4.

Thông tin về sách biểu diễn trong XMLLược đồ XML: Cơ chế DTD có một số hạn chế, mặc dù nó vẫn được sử dụng rộng rãi.Ví dụ, các thẻ và các thuộc tính không thể được gán các kiểu một cách mềm dẻo, vàcác thẻ luôn phải theo thứ tự, dù là ứng dụng không yêu cầu điều này. Lược đồ XMLtrong đề nghị mới của W3C cung cấp nhiều cách thức hiệu quả để biểu diễn cấu trúcvăn bản hơn là trong DTDs; cho phép thừa kế dữ liệu dễ dàng hơn. Một khía cạnh thúvị là nó hỗ trợ các ràng buộc khoá ngoại và ràng buộc duy nhất.

Domain-Specific DTDs

Gần đây, DTDs đã được phát triển cho một số lĩnh vực đặc biệt- phủ lên một vùng rộnglớn của thương mại, kỹ thuật, tài chính, công nghệ và khoa học...- và rất nhiều nhữngđiều thú vị về XML đã được bắt nguồn từ một niềm tin rằng có nhiều hơn và nhiều hơn

244/470

nữa những DTDs chuẩn sẽ được phát triển. DTDs đã được chuẩn hoá sẽ cho phép traođổi dữ liệu giữa những nguồn dữ liệu không đồng nhất.

Ngay cả trong môi trường nơi mà tất cả các dữ liệu XML là hợp lệ, nó cũng không thểtích hợp một số tài liệu XML một cách minh bạch bằng cách đối sánh các thẻ trong cácDTDs khác nhau. Nếu cả hai văn bản sử dụng một chuẩn DTD thì chúng ta sẽ tránhđược vấn đề này. Sự phát triển của các chuẩn DTDs bị ảnh hưởng bởi các yếu tố xã hộinhiều hơn là khó khăn trong việc nghiên cứu, vì các đối tượng tham gia trong lĩnh vựcnày cần phải có ‘tiếng nói chung’ - sự hợp tác với nhau.

Ví dụ, Ngôn ngữ đánh dấu toán học (Mathematical markup language-MathML) đãđược phát triển để mã hoá những ký hiệu toán học trên Web. Có hai loại thẻ MathML.Các thẻ trình diễn biểu diễn cấu trúc của một văn bản; ví dụ thẻ mrow xác định mộtxâu ký tự sẽ được trình bày theo chiều ngang, thẻ msup xác định ký tự cơ sở và số mũcủa nó. Các thẻ nội dung biểu diễn các khái niệm toán học. Ví dụ thẻ plus sẽ xác địnhmột phép tính cộng.

MathML cho phép chúng ta mã hoá các đối tượng toán học bằng cả hai loại vì yêu cầucủa người sử dụng với các đối tượng có thể khác nhau. Các thẻ nội dung mã hoá chínhxác các đối tượng mà không có sự nhập nhằng, và có thể được sử dụng trong các ứngdụng như các hệ thống tính toán số học.

Ví dụ, xem xét công thức đơn giản sau:

x2-4x-32=0

Sử dụng các thẻ trình diễn, công thức được biểu diễn như sau:

<mrow> <mrow> <msup><mi>x</mi><mn>2</mn></msup> <mo>-</mo><mrow><mn>4</mn> <mo>&invisibletimes;</mo> <mi>x</mi></mrow> <mo>-</mo><mn>32</mn> </mrow><mo>=</mo><mn>0</mn></mrow> Sử dụng các thẻ nội dung, công thức được biểu diễnnhư sau: <reln><eq/> <apply> <minus/> <apply> <power/><ci>x</ci> <cn>2</cn> </apply> <apply> <times/> <cn>4</cn><ci>x</ci> </apply> <cn>32</cn> </apply> <cn>0</cn></reln>

Nhớ rằng sẽ có sự bổ sung sức mạnh khi chúng ta sử dụng MathML thay vì mã hoá côngthức bằng HTML. Cách thường dùng khi biểu diễn các đối tượng toán học trong HTMLlà phải sử dụng đến các ảnh của các công thức, ví dụ:

<IMG SRC="images/equation.gif" ALT=" x**2 - 4x - 32 = 10 ">

245/470

Công thức này được mã hoá bên trong thẻ IMG cùng với việc thêm phần định dạng hiểnthị bằng việc sử dụng thẻ ALT. Sử dụng việc mã hoá này cho một đối tượng toán họcdẫn đến những vấn đề sau. Đầu tiên, ảnh phải được điều chỉnh kích cỡ để phù hợp vớikiểu chữ hiện tại, nếu không thì ảnh sẽ quá nhỏ hoặc quá lớn. Thứ hai, trên các hệ thốngcó các màu nền khác nhau, ảnh sẽ không phù hợp với các màu nền tương ứng, dẫn đếnkhó khăn trong hiển thị và in ấn,

Kiến trúc ba-lớp của ứng dụng

Trong phần này, chúng ta bàn đế kiến trúc của các ứng dụng trên Internet chuyên sâu vềdữ liệu. Các ứng dụng này có thể được hiểu dưới dạng ba thành phần chức năng khácnhau: quản lý dữ liệu, chương trình ứng dụng và trình diễn. Thành phần quản lý dữ liệuthường sử dụng một DBMS để lưu trữ dữ liệu, như hai thành phần còn lại là chươngtrình ứng dụng và trình diễn giải quyết nhiều vấn đề hơn là chỉ những chức năng màDBMS cung cấp.

Chúng ta bắt đầu bằng việc giới thiệu ngắn gọn về lịch sử của các kiến trúc ứng dụngchuyên sâu cơ sở dữ liệu, và giới thiệu các kiến trúc một-lớp và kiến trúc máy trạm-máychủ (client-server) trong Phần 7.5.1. Chúng ta giải thích kiến trúc ba-lớp chi tiết trongPhần 7.5.2, và những ưu điểm của nó trong Phần 7.5.3.

Kiến trúc một lớp và máy trạm-máy chủ

Kiến trúc một-lớp

246/470

Kiến trúc hai-lớp: Máy trạm yếu

Kiến trúc hai-lớp còn được gọi là kiến trúc máy trạm-máy chủ, gồm một máy trạmvà một máy chủ, được giao tiếp với nhau thông qua một giao thức được định-nghĩa-tốt.Sự phân công chức năng thực hiện giữa hai máy tính này có thể được điều chỉnh thayđổi. Trong kiến trúc máy trạm-máy chủ truyền thống, các máy trạm chỉ làm nhiệm vụ làmột giao diện đồ hoạ của người sử dụng, và máy chủ thực hiện cả hai chức năng quảnlý dữ liệu và tính toán logic; vì thế các máy trạm thường được gọi là máy-trạm-yếu, vàkiến trúc này được minh hoạ trong Hình 6.

Một sự phân chia khác là máy trạm thực hiện cả hai chức năng: giao diện người dùngvà tính toán logic, hoặc các máy trạm thực hiện chức năng là giao diện người dùng vàmột phần của tính toán logic, phần còn lại thực hiện ở phía máy chủ; máy trạm trongtrường hợp này thường được gọi là máy-trạm-mạnh, và kiến trúc này được minh hoạtrong Hình 7.

Kiến trúc hai-lớp: Máy trạm mạnh

Mười năm trước đây, các công cụ phục vụ mô hình máy trạm-máy chủ đã được pháttriển như Microsoft Visual Basic và Sybase Powerbuilder. Những công cụ này cho phépphát triển nhanh chóng các phần mềm chạy trên kiến trúc máy trạm-máy chủ, góp phầnvào sự thành công của mô hình này.

Mô hình máy-trạm-mạnh có một số nhược điểm so với mô hình máy-trạm-yếu. Đầu tiên,nó không có một vùng tập trung để cập nhật và bảo trì các tính toán logic khi cần thiết,vì mã nguồn ứng dụng chạy trên nhiều máy trạm khác nhau. Thứ hai, có một lượng lớncác ‘kiểm tra đúng đắn’ giữa máy trạm và máy chủ. Ví dụ, DBMS của một ngân hàngphải kiểm tra việc thực thi ứng dụng ở máy ATM để đảm bảo cơ sở dữ liệu có sự nhấtquán.(Một cách để giải quyết vấn đề này là sử dụng stored procedures. Chúng ta sẽ bànđến stored procedures chi tiết trong Phần 5).

247/470

Nhược điểm thứ ba của kiến trúc máy-trạm-mạnh là nó không thể đồng thời phục vụđược quá nhiều yêu cầu của người dùng đồng thời, cụ thể là không nhiều hơn vài trămmáy trạm. Ứng dụng ở phía máy trạm gửi các truy vấn SQL tới máy chủ và máy chủtrả về kết quả cho máy trạm. Một lượng lớn kết quả truy vấn phải được trao đổi giữamáy trạm và máy chủ. (stored procedures sẽ giúp làm giảm lượng dữ liệu phải trao đổinày). Thứ tư, các hệ thống máy-trạm-mạnh không đáp ứng được khi các ứng dụng cầntruy cập đến nhiều hệ thống cơ sở dữ liệu. Giả sử, có x hệ thống cơ sở dữ liệu khác nhauđược truy cập bởi y máy trạm, thì sẽ có x*y kết nối khác nhau được mở, rõ ràng đâykhông là giải pháp tốt.

Kiến trúc ba-lớp chuẩn

Kiến trúc ba-lớp

Kiến trúc hai-lớp-máy-trạm-yếu đã có sự phân chia trong việc trình bày dữ liệu từ cácphần khác nhau của ứng dụng. Kiến trúc ba-lớp đã tiến thêm một bước, nó đã tách rờiphần logic ứng dụng với phần quản lý dữ liệu.

Các công nghệ cho ba-lớp

248/470

Lớp giữa: Logic ứng dụng thực hiện ở đây. Chương trình nguồn của nó thường đượcviết bằng C ++ hoặc Java.

Lớp quản lý dữ liệu: Các ứng dụng Web chuyên sâu về dữ liệu bao gồm các DBMS, lànội dung của cuốn sách này.

Hình 8 chỉ ra một kiến trúc ba-lớp cơ bản. Các công nghệ khác nhau đã được phát triểnnhằm phân bố ba lớp của ứng dụng để có thể phù hợp với nhiều nền tảng phần cứngkhác nhau. Hình 9 chỉ ra những công nghệ liên quan đến từng lớp.

Tổng quan về lớp trình diễn

Ở lớp trình diễn, chúng ta cần cung cấp các form để người dùng có thể đưa vào các yêucầu, và hiển thị thông báo phản hồi mà lớp giữa đưa ra. HTML đã trình bày trong Phần3 là ngôn ngữ biểu diễn dữ liệu chính. Một điều quan trọng là lớp này được mã hoá đểdễ dàng tương thích với các thiết bị hiển thị và các định dạng khác nhau: ví dụ các máytính bàn thông thường khác với các thiết bị cầm tay, khác với điện thoại di động. Sựtương thích này có thể đạt được ở lớp giữa bằng cách đưa ra những trang khác nhau chonhững kiểu máy tính khác nhau, hoặc ở máy trạm thông qua các style sheets xác địnhcách thức dữ liệu được trình bày. Ở trường hợp cuối cùng, lớp giữa có nhiệm vụ đưa radữ liệu phù hợp đáp ứng yêu cầu của người dùng, trong khi đó lớp trình diễn quyết địnhcách thức hiển thị những thông tin này.

Chúng ta tìn hiển các công nghệ của lớp trình diễn, bao gồm các style sheets trong Phần6.

Tổng quan về lớp giữa

Lớp giữa thực thi phần mã nguồn của chương trình ứng dụng. Nó điều khiển những dữliệu nào cần phải đưa vào trước khi một hành động nào đó được thực hiện, xác địnhthứ tự các hành động được thực hiện, điều khiển việc truy cập tới lớp cơ sở dữ liệu, vàthường linh động thu thập các trang HTML phù hợp từ kết quả truy vấn cơ sở dữ liệu.

Mã nguồn của lớp giữa có khả năng hỗ trợ tất cả các role khác nhau của ứng dụng. Vídụ, trong một cửa hàng Internet, chúng ta muốn khách hàng có thể xem được danh mụchàng và thực hiện việc đặt hàng, người quản trị có thể kiểm tra hàng hoá trong kho, vàcó thể phân tích dữ liệu để trả lời được truy vấn về lịch sử của việc đặt hàng. Một rolecó thể yêu cầu nhiều công việc phức tạp.

Ví dụ, xem xét một khách hàng muốn mua một sản phẩm. Trước khi việc bán được thựchiện, khách hàng này phải đi qua một loạt các bước: Cô ấy phải thêm các sản phàm vàogiỏ hàng, cung cấp địa chỉ giao hàng và mã số thẻ thanh toán (trừ khi cô ấy có một tàikhoản trên trang Web này), và phải xác nhận lại hoá đơn bán hàng sau khi đã được cộngthêm giá vận chuyển và thuế sản phẩm. Việc điều khiển thứ tự thực hiện các bước và

249/470

ghi nhớ những bước nào đã được thực hiện sẽ được làm ở lớp giữa. Việc đưa ra dữ liệuđáp ứng các bước trên cần đến thao tác truy cập cơ sở dữ liệu, nhưng không phải lúc nàocũng như vậy (ví dụ, một giỏ hàng không được lưu trữ trong cơ sở dữ liệu cho đến khiviệc bán được hoàn tất).

Chúng ta nghiên cứu chi tiết về lớp giữa trong Phần 7.

Những ưu điểm của kiến trúc ba-lớp

Kiến trúc ba-lớp có những ưu điểm sau:

• Những hệ thống không đồng nhất: Các ứng dụng có thể tận dụng sức mạnhcủa các phần mềm và nền tảng hệ thống của các lớp khác nhau. Chương trìnhtại các lớp khác nhau dễ được sửa đổi hoặc thay thế mà không ảnh hưởng tớicác lớp khác.

• Các máy trạm yếu: Các máy trạm chỉ cần có năng lực tính toán vừa phải phụcvụ cho lớp trình diễn. Các máy trạm chỉ cần là các trình duyệt Web.

• Truy cập dữ liệu: Trong nhiều ứng dụng, dữ liệu phải được truy cập từ nhiềunguồn khác nhau. Điều này có thể được thực hiện dễ dàng ở lớp giữa, nơichúng ta có thể quản lý tập trung các kết nối tới tất cả các hệ thống cơ sở dữliệu liên quan.

• Phục vụ nhiều máy trạm: Tất cả các truy cập của các máy trạm tới hệ thốngđều thông qua lớp giữa. Lớp giữa có thể chia sẻ các kết nối tới cơ sở dữ liệucho các máy trạm, và nếu lớp giữa trở thành ‘cổ chai’, chúng ta có thể dàn xếpcho một số máy chỉ thực hiện chức năng của lớp giữa; các máy trạm có thể kếttới tới bất kỳ máy chủ nào nếu phần thiết kế logic được thực hiện hợp lý. Điềunày được minh hoạ trong Hình 10, trong đó chỉ ra cách thức lớp giữa truy cậptới nhiều nguồn dữ liệu khác nhau. Tất nhiên, chúng ta sẽ nhờ DBMS cho mỗitruy cập nguồn dữ liệu (và ở đây có thể bao gồm thêm phần xử lý song song vàsao lưu dữ liệu, chúng ta sẽ bàn tới trong Chương 22).

• Những lợi ích trong phát triển phần mềm: Bằng việc chia ứng dụng thànhcác phần như biểu diễn địa chỉ, truy cập dữ liệu, và thực hiện logic của chươngtrình, chúng ta đạt được nhiều điểm lợi. Phần thực hiện logic của chương trìnhđược tập trung giải quyết, và vì thế nó dễ dàng được bảo trì, thay đổi và gỡ lỗi.Sự ảnh hưởng lẫn nhau giữa các lớp được định nghĩa tốt thông qua chuẩn APIs.Vì thế, mỗi lớp ứng dụng có thể được xây dựng từ các thành phần được pháttriển, gỡ lỗi, và kiểm tra độc lập .

250/470

Lớp giữa và khả năng truy cập tới nhiều nguồn dữ liệu

Lớp trình diễn

Trong phần này, chúng ta trình bày các công nghệ phía máy trạm trong kiến trúc ba-lớp.Chúng ta bàn về các form HTML trong Phần 6.1. Trong Phần 6.2, chúng ta giới thiệuvề JavaScrip. Chúng ta tổng kết những công nghệ phía máy trạm bằng việc trình bàyvề Style sheets trong Phần 6.3. Style sheets là ngôn ngữ cho phép chúng ta biểu diễncùng một trang Web với các định dạng khác nhau cho các máy trạm; ví dụ, định dạngdữ liệu cho các trình duyệt Web khác với cho điện thoại di động, hoặc trình duyệt Webcủa Netscape khác với của Microsofts Internet Explorer.

Các Form HTML

Form HTMLs là một cách thường dùng để giao tiếp dữ liệu giữa lớp máy trạm và lớpgiữa. Định dạng chung của một form như sau:

<FORM ACTION="page.jsp" METHOD="GET" NAME="LoginForm"> ...</FORM>

Một văn bản HTML có thể chứa nhiều hơn một form. Bên trong một Form HTML cóthể có bất kỳ một thẻ HTML nào, ngoại trừ một FORM khác. Thẻ FORM có ba thuộctính quan trọng sau:

• ACTION: Xác định URI của trang mà nội dung của form sẽ gửi tới trang này;nếu thuộc tính ACTION không xuất hiện, thì URI của trang hiện tại được sửdụng. Trong ví dụ trên, đầu vào của form sẽ được gửi tới trang có tên làpage.jsp. (Chúng ta sẽ giải thích các phương pháp đọc dữ liệu form tại lớp giữatrong Phần 7.)

• METHOD: Phương thức HTTP/1.0 được sử dụng để gửi đi các dữ liệu đầuvào (được nhập trong form) tới Webserver. Có hai lựa chọn, GET và POST;chúng ta sẽ trình bày phần này ở mục sau.

251/470

• NAME: Thuộc tính này chứa tên của form. Mặc dù không cần thiết, nhưngchúng ta nên đặt tên cho form. Trong phần 6.2, chúng ta sẽ bàn tới cách viếtcác chương trình phía-máy-trạm bằng JavaScript trong đó có việc tham chiếutới các form thông qua tên và thực hiện các kiểm tra trên những trường củaform.

Bên trong Form HTMLs, các thẻ INPUT, SELECT, và TEXTAREA được sử dụng đểxác định các thành phần đầu vào: một form có thể có nhiều thành phần của mỗi loại.Thành phần đầu vào đơn giản nhất là một trường INPUT.

Một ví dụ về thẻ INPUT như sau:

<INPUT TYPE="text" NAME="title">

Thẻ INPUT có một số thuộc tính. Ba thuộc tính quan trọng nhất là TYPE, NAME vàVALUE. Thuộc tính TYPE xác định kiểu của trường đầu vào. Nếu thuộc tính TYPEcó giá trị là text, thì trường này nhận giá trị là text. Nếu thuộc tính TYPE có giá trị làpassword, thì trường đầu vào là một trường text mà những ký tự nhập vào dù là gì thìcũng chỉ hiển thị ra màn hình là những ký tự *. Nếu thuộc tính TYPE là kiểu reset, nólà một nút đơn giản có khả năng thiết lập lại tất cả các trường đầu vào của form thànhgiá trị mặc định của chúng. Nếu thuộc tính TYPE có giá trị là submit thì nó là một nútcó khả năng gửi các giá trị của các trường đầu vào khác nhau trong form tới máy chủ.Nhớ rằng reset và submit sẽ ảnh hưởng tới toàn bộ form. Trong ví dụ trước, chúng taxác định title là NAME của trường input.

Thuộc tính NAME của thẻ INPUT xác định tên cho trường này và được sử dụng để nhậnra giá trị của trường đầu vào khi nó được gửi tới máy chủ. NAME phải được thiết đặtcho các thẻ INPUT của tất cả các loại ngoại trừ submit và reset.

Thuộc tính VALUE của thẻ input có thể được sử dụng cho các trường text hoặcpassword để xác định nội dung mặc định của trường này. Với các nút submit hoặc Formtrong Hình 11 chỉ ra hai trường text, một là trường input text thông thường và một làtrường password. Nó cũng chứa hai nút, một nút reset có nhãn là ‘'Reset

Values’ và một nút có nhãn là ‘Log on’. Ghi nhớ rằng có hai trường input được đặt tên,ngược lại hai nút reset và submit không có thuộc tính NAME.

252/470

Form HTML với hai trường text và hai nút

Form HTMLs có các cách khác nhau để nhận giá trị đầu vào, như các thẻ TEXTAREAvà SELECT đã nhắc đến ở trên; chúng ta không bàn sâu đến chúng ở đây.

Gửi các tham số tới các script phía máy chủ

Như đã đề cập trong phần mở đầu của mục 6.1, có hai cách khác nhau để gửi dữ liệutrong Form HTML tới Webserver. Nếu sử dụng phương thức GET thì những nội dungcủa form này được tập hợp vào một truy vấn URI (sẽ trình bày sau) và gửi tới máy chủ.Nếu sử dụng phương thức POST, thì nội dung của form này được mã hoá như trongphương thức GET, nhưng nội dung này được gửi trong một khối dữ liệu độc lập thayvì gắn trực tiếp chúng vào một URI. Vì thế trong phương thức GET nội dung của formngười dùng có thể nhìn thấy như một URI có cấu trúc, ngược lại đối với phương thứcPOST, nội dung của form được gửi bên trong một thông điệp HTTP và người dùngkhông được nhìn thấy chúng.

Việc sử dụng phương thức GET cung cấp cho người dùng cơ hội để đánh dấu một trangnào đó cùng với URI có cấu trúc và vì thế có thể ‘nhảy’ trực tiếp tới những phần sau củanó; điều này là không thể khi sử dụng phương thức POST. Lựa chọn GET hay POSTnên được xác định bằng ứng dụng.

Hãy cùng chúng tôi xem đoạn mã của URI khi phương thức GET được sử dụng. Đoạnmã URI có dạng sau:

action?name1=valuel&name2=value2&name3=value3

Action là một URI đã xác định trong thuộc tính ACTION của thẻ FORM, hoặc URI vănbản hiện tại nếu thuộc tính ACTION không được chỉ ra. Các cặp name=value là giá trịđầu vào mà người dùng đã nhập trong các trường INPUT của form. Với những trườngINPUT mà người dùng không nhập dữ liệu cho nó, phần tên vẫn được biểu diễn kèmvới giá trị rỗng (name=). Cụ thể, xem xét form nhập vào password ở cuối phần trước.Giả sử rằng người dùng nhập giá trị ‘John Doe’ vào trường username, và ‘secret’ vàopassword. Thì request URI là:

page.jsp?username=John+Doe&password=secret

Dữ liệu đầu vào được nhập qua form có thể chứa những ký tự ASCII thông thường, vídụ những ký tự trống, nhưng URIs phải là một xâu liên tục không chứa ký tự trống. Vìthế, các ký tự đặc biệt như ký tự trống, ‘=’, và những ký tự không có khả năng in ra phảiđược mã hoá một cách đặc biệt. Để tạo ra một URI có các trường được mã hoá, chúngta thực hiện các bước sau:

253/470

1. Chuyển đổi tất cả các ký tự đặc biệt trong phần name và giá trị là ‘%xyz’, trongđó ‘xyz’ là giá trị mã ASCII của ký tự theo hệ 16. Những ký tự đặc biệt baogồm =, &, %, +, và những ký tự không thể in được. Ghi nhớ rằng chúng ta cóthể mã hoá tất cả các ký tự theo giá trị ASCII của chúng.

2. Chuyển đổi tất cả các ký tự trống thành ký tự ‘+’.3. Gán phần tên và giá trị tương ứng bằng cách sử dụng dấu ‘=’ và sau đó dán các

cặp tên-giá trị cùng với dấu ‘&’ để tạo ra một request URI của form:action?namel=valuel&name2=value2&name3=value3

Lưu ý thứ tự xử lý các thành phần đầu vào của Form HTML ở lớp giữa, chúng ta cầnthuộc tính ACTION của thẻ FORM để gán nó tới trang, script, hoặc chương trình phầnmềm sẽ xử lý những giá trị của những trường mà người dùng nhập vào form. Chúng tasẽ bàn về các cách chương trình nhận giá trị của form trong Phần 7.1 và 7.3.

JavaScript

JavaScript là một ngôn ngữ kịch bản ở lớp máy trạm nơi mà chúng ta có thể thêmcác chương trình chạy trực tiếp trên máy trạm (ví dụ, ở máy chạy trình duyệt Web).JavaScrip thường được sử dụng cho những tính toán ở máy trạm:

• Dò tìm trình duyệt: JavaScrip có thể được sử dụng để dò tìm các loại trìnhduyệt và tải về những trang Web cụ thể.

• Xác nhận tính hợp lệ của form: JavaScrip được sử dụng để thực hiện nhữngkiểm tra tính nhất quán đơn giản trên những trường của form. Ví dụ, mộtchương trình JavaScrip có thể kiểm tra một trường trong form cho phép nhậpđịa chỉ email xem có ký tự @ trong đó không, hoặc tất cả các trường của formđều yêu cầu người sử dụng nhập dữ liệu vào.

• Điều khiển trình duyệt: Bao gồm những trang đang được mở, ví dụ một trangWeb quảng cáo chứa nhiều trang Web bên trong nó, điều này có thể được lậptrình bằng JavaScrip.

JavaScrip được nhúng vào văn bản HTML bằng một thẻ đặc biệt, thẻ SCRIPT. ThẻSCRIPT có thuộc tính LANGUAGE, chỉ định ngôn ngữ mà script được viết. VớiJavaScrip, chúng ta phải thiết đặt thuộc tính ngôn ngữ của nó. Một thuộc tính khác củathẻ SCRIPT là SRC, nó dùng để chỉ định một file ở bên ngoài được nhúng vào văn bảnHTML. Thường thì file mã nguồn của JavaScrip có đuôi là ‘.js’. Đoạn mã lệnh sau đâychỉ ra có một file JavaScrip được nhúng trong một văn bản HTML:

<SCRIPT LANGUAGE=" JavaScript" SRC="validateForm.js"></SCRIPT>

Thẻ SCRIPT có thể được đặt bên trong chú thích của HTML để đoạn mã chương trìnhJavaScrip không hiển thị nguyên văn trên các trình duyệt Web. Sau đây là một đoạn ví

254/470

dụ JavaScrip khác giúp tạo ra hộp thoại pop-up cùng với một lời chào. Chúng ta đặtđoạn mã lệnh JavaScrip bên trong chú thích HTML vì những lý do vừa đề cập.

<SCRIPT LANGUAGE="JavaScript" > <!-- alert("Welcome to ourbookstore"); //--> </SCRIPT>

JavaScrip cung cấp hai cách để tạo chú thích: chú thích cho một dòng sử dụng ký hiệu‘//’ ở đầu dòng đó, và chú thích cho nhiều dòng sử dụng ‘/*’ để bắt đầu và ‘*/’ để kếtthúc.

Biến trong JavaScrip có thể mang giá trị số, logic (true hoặc false), xâu ký tự, và mộtsố kiểu dữ liệu khác. Các biến dùng chung (global) được khai báo cùng với từ khoá var,và chúng có thể được sử dụng ở bất kỳ đâu bên trong văn bản HTML. Những biến địaphương (local) dùng cho các hàng JavaScrip không cần được khai báo. Các biến khôngcó kiểu cố định nhưng hoàn toàn có thể mang kiểu của dữ liệu được gán cho nó.

JavaScrip thường sử dụng những phép gán (=, +=, vv…), các phép toán số học (+, -,*, /, %), các phép so sánh (==, !=, >=, vv…), và những phép toán logic (&& cho phépAND, || cho phép OR, và ! cho phép NOT). Xâu ký tự có thể được nối dài sử dụng phép‘+’ xâu. Kiểu dữ liệu của đối tượng xác định phép toán nào được sử dụng; ví dụ 1+1 là2, vì chúng là phép cộng hai số, ngược lại “1”+ “1” là “11” vì chúng là phép nối xâuký tự. Một số câu lệnh thường gặp trong JavaScrip là: các phép gán, các câu lệnh điềukiện (if (điều kiện) {các câu lệnh;} else {các câu lệnh;}), và các câu lệnh lặp (for-loop,do-while, và while-loop).

JavaScrip cho phép chúng ta tạo ra các hàng sử dụng từ khoá function:

function f (arg1 , arg2) {các câu lệnh;}.

Chúng ta có thể gọi các hàm từ chương trình JavaScrip, và các hàm có thể trả về giá trịsử dụng từ khoá return.

Chúng ta tổng kết phần giới thiệu về JavaScrip này với một ví dụ về hàm JavaScrip đểkiểm tra trường login và password của một form HTML là không rỗng. Hình 12 chỉ rahàm JavaScrip này và form HTML. Đoạn mã này là một hàm testLoginEmpty() dùng đểkiểm tra xem có trường nào trong form LoginForm bị rỗng không. Hàm testLoginEmptyđược kiểm tra trong một form event handler. Một event handler là một hàm được gọinếu một sự kiện nào đó xảy ra trên một đối tượng trong Website. Even handler chúngta sử dụng ở đây là onSubmit, nó được gọi nếu nút submit được nhấn (hoặc nếu ngườidùng nhấn trở lại vào một trường text trong form). Nếu event handler trả về giá trị true,thì nội dung của form được gửi (submit) tới máy chủ, ngược lại nội dung này sẽ khôngđược gửi tới máy chủ. JavaScrip có nhiều chức năng hơn là những kiến thức cơ bản

255/470

được giới thiệu trong phần này; những điều thú vị về JavaScrip bạn có thể tìm hiểu thêmtrong những phần tham khảo được giới thiệu ở cuối chương.

Kiểm tra form bằng JavaScript

Style Sheets

Các máy trạm khác nhau có chế độ hiển thị khác nhau, vì lẽ đó chúng ta cần nhiều cáchkhác nhau để hiển thị cùng một thông tin. Ví dụ, trong một trường hợp đơn giản nhất,chúng ta cần sử dụng kích thước và màu chữ khác nhau để đảm bảo sự tương phản caotrên màn hình đen- trắng. Ví dụ phức tạp hơn, chúng ta có thể cần sắp xếp lại các đốitượng trên một trang để thích hợp với các loại màn hình nhỏ như các màn hình thiết bịcầm tay. Một ví dụ khác, chúng ta có thể đánh dấu một số thông tin quan trọng trên trong

256/470

trang. Style Sheets là một cách để cùng một nội dung văn bản sẽ được hiển thị trên cácđịnh dạng khác sao cho phù hợp.

Một Style Sheets chứa các cấu trúc hướng dẫn một trình duyệt Web (hoặc bất kỳ cái gìmà máy trạm sử dụng để hiển thị một trang Web) cách chuyển đổi dữ liệu của một vănbản để hiển thị sao cho thích hợp với các màn hình máy trạm khác nhau.

Một ví dụ về Style sheet

Có hai ngôn ngữ Style Sheets: XSL và CSS. CSS được tạo cho HTML với mục đíchphân chia những đặc tính hiển thị của các thẻ định dạng khác nhau vào bản thân các thẻđó. XSL là phần mở rộng của CSS để phục vụ riêng cho các văn bản XSL; bên cạnhđó cho phép chúng ta định nghĩa mức độ các đối tượng được định dạng, XLS chứa mộtngôn ngữ chuyển đổi cho phép chúng ta sắp xếp lại các đối tượng. Những file đích củaCSS là những file HTML, trong khi đó những file đích của XSL là những file XML.

Cascading Style Sheets

Cascading Style Sheet (CSS) được sử dụng để định nghĩa cách thức hiển thị các thẻHTML. (Trong Phần 13, chúng ta đã giới thiệu một ngôn ngữ Style Sheets được thiết kếcho các văn bản XML). Thông thường, các Style được lưu trữ trong Style Sheets- là nơichứa các định nghĩa của style. Rất nhiều văn bản HTML khác nhau, như tất cả các vănbản trong một website, có thể tham chiếu tới cùng CSS. Vì thế, chúng ta có thể thay đổiđịnh dạng của một website bằng việc thay đổi một file duy nhất. Đây là một cách thayđổi việc bố trí của rất nhiều trang Web tại cùng một thời điểm rất tiện lợi, trong đó bướcđầu tiên sẽ là hướng tới việc phân tách nội dung với việc trình bày.

Một ví dụ Style Sheet được chỉ ra trong Hình13. Nó được nhúng trong một file HTMLbằng dòng lệnh sau:

<LINK REL="style sheet" TYPE="text/ess" HREF="books.css"/>

Mỗi dòng trong một CSS sheet chứa ba phần; thành phần được lựa chọn (selector), thuộctính (property), và giá trị (value). Chúng được sắp xếp theo cách sau:

Selector{property: value}

257/470

Slector là định dạng của một thẻ chúng ta đang định nghĩa. Property chỉ ra thuộc tínhcủa thẻ mà ta đang muốn thiết đặt giá trị trong Style Sheet. Ví dụ, xem xét dòng đầu tiêncủa một ví dụ Style Sheet được chỉ ra trong Hình 13.

BODY {BACKGROUND-COLOR: yellow}

Dòng này có cùng tác dụng khi thay đổi mã HTML như sau:

<BODY BACKGROUND-COLOR= "yellow" >.

Giá trị nên đặt trong dấu ngoặc khi chúng có nhiều hơn một từ. Một Selector có thể cónhiều hơn một thuộc tính và chúng được phân tách nhau bằng dấu phẩy như được chỉ ratrong dòng cuối cùng của ví dụ Hình 13.

P {MARGIN-LEFT: 50px; COLOR: red}

CSS có các ký hiệu mở rộng; phần tham khảo ở cuối chương chỉ ra những cuốn sách vàcác tài liệu trực tuyến về CSSs.

XSL

XLS là một ngôn ngữ của các Style Sheets dùng cho các mục đích đặc biệt. Một XLSstyle Sheet là một file biểu diễn cách thức hiển thị một văn bản XML nào đó. XSL chiasẻ những tính năng của CSS và tương thích với nó (mặc dù nó sử dụng những ký hiệuđặc biệt.)

Khả năng của XLS là rất lớn, vượt xa so với những tính năng của CSS. XSL chứa ngônngữ chuyển đổi XSL (XSL Transformation language), còn gọi là XSLT, một ngônngữ cho phép chúng ta biến đổi một file đầu vào là một văn bản XML thành một vănbản XML có cấu trúc khác. Ví dụ, với XLST chúng ta có thể thay đổi thứ tự các thẻchúng ta đang hiển thị (ví dụ, sắp xếp chúng), xử lý các thẻ, ngăn chặn các thẻ trong mộtvùng và biểu diễn chúng ở một vùng khác, và thêm những đoạn văn bản cần thiết khitrình bày.

XSL cũng chứa một XML Path Language (XPath), ngôn ngữ này cho phép chúng tatham chiếu tới các phần khác nhau của một văn bản XML. Chúng ta sẽ bàn về Xpathtrong Phần 27. XSL cũng chứa XSL Formatting Object, một cách định dạng đầu ra củamột XSLT nào đó.

Lớp giữa

Trong phần này chúng ta bàn đến các công nghệ được sử dụng cho lớp giữa. Thế hệđầu tiên của các ứng dụng lớp giữa là các chương trình độc lập được viết bằng các ngôn

258/470

ngữ như C, C++, và Perl. Nhưng những người lập trình nhanh chóng nhận thức đượcrằng việc tương tác với một ứng dụng độc lập thật sự rất tốn kém; nó bao gồm việc khởiđộng ứng dụng bất cứ khi nào nó được yêu cầu và những quá trình trao đổi thông tingiữa webserver và ứng dụng. Do đó, cách làm này không đáp ứng được khi có một sốlượng lớn người sử dụng đồng thời. Từ đó dẫn đến sự phát triển của các máy chủ ứngdụng (application server), nó cung cấp môi trường run-time cho một số công nghệ cóthể được sử dụng để lập trình những thành phần ứng dụng trong lớp giữa. Hầu hết cácwebsite lớn hiện này sử dụng máy chủ ứng dụng để chạy các chương trình ứng dụng củalớp giữa.

Chúng ta bắt đầu phần 7.1 để tìm hiểu về Hệ giao tiếp cổng vào chung (CommonGateway Interface), một giao thức được sử dụng để chuyển những tham số từ các formHTML vào các chương trình ứng dụng chạy ở lớp giữa. Chúng ta giới thiệu về máy chủứng dụng trong phần 7.2. Sau đó, chúng ta trình bày về các công nghệ được sử dụng đểviết ứng dụng ở lớp giữa: Java servlets (Phần7.3) và Java Server Pages (Phần 7.4). Chứcnăng quan trọng khác là duy trì trạng thái của các thành phần trong lớp giữa vì các thànhphần máy trạm đi qua một loạt các bước để hoàn thành một giao dịch (ví dụ, quá trìnhthanh toán một giỏ hàng hoặc quá trình đặt vé máy bay). Trong Phần 7.5 chúng ta bànđến Cookies, một trong những phương pháp tiếp cận để duy trì trạng thái.

CGI: The Common Gateway Interface

CGI kết nối các form HTML với các chương trình ứng dụng. Nó là một giao thức địnhnghĩa cách thức các tham số từ các form chuyển tới các chương trình ứng dụng ở phíamáy chủ. Chúng ta không đi vào chi tiết của giao thức CGI cụ thể vì các thư viện sẽ chophép các chương trình ứng dụng lấy các tham số từ form HTML; chúng ta xem xét mộtví dụ trong một chương trình CGI. Chương trình kết nối với webserver thông qua CGIthường được gọi là CGI scripts, vì rất nhiều các chương trình ứng dụng như vậy đượcviết bằng ngôn ngữ script như Perl.

Ví dụ trong Hình 14 là một ví dụ của một chương trình tương tác với một Form HTMLthông qua CGI. Webpage này chứa một form mà người sử dụng có thể điền tên tác giả.Nếu người dùng nhấn và nút “Send it”, script ‘findBooks’ chỉ ra trong Hình 14 đượcthực hiện như một quá trình độc lập. Giao thức CGI định nghĩa cách thức kết nối giữaform và script. Hình 15 minh hoạ những quá trình tạo ra khi sử dụng giao thức CGI.

Hình 16 chỉ ra một ví dụ CGI script được viết bằng ngôn ngữ Perl. Chúng ta bỏ qua việckiểm tra lỗi để làm đơn giản chương trình. Perl là một ngôn ngữ lập trình thường đượcsử dụng để viết các CGI script và nhiều thư viện Perl, gọi là các modules cung cấp giaodiện mức cao cho các giao thức CGI. Chúng ta sử dụng một trong những thư viện này,gọi là thư viện DBI trong ví dụ của chúng ta. Module CGI này là tập hợp những hàmtiện ích hỗ trợ việc tạo các CGI scripts. Trong phần 1 của script ví dụ, chúng ta trích ramột tham số của một form HTML, tham số này được gửi từ một máy trạm:

259/470

$authorName = $datain - > param('authorName');

Ghi nhớ rằng biến có tên authorName đã được sử dụng trong form của Hình 14 để đặttên cho trường đầu vào đầu tiên. Để tiện lợi, giao thức CGI trừu tượng hoá việc thựcthi thực sự cách thức một Webpage được trả về cho Web browser; Webpage đơn giảnchỉ chứa đầu ra của chương trình của chúng ta, và chúng ta bắt đầu việc tập hợp trangHTML đầu ra trong Phần 2. Mọi thứ script viết trong các câu-lệnh-print là một phần củaWebpage động được trả về cho brower. Chúng ta kết thúc trong Phần 3 bằng việc thêmvào các thẻ đóng cho trang kết quả.

Ví dụ Webpage mà các đầu vào của form được gửi tới CGI Script

Các máy chủ ứng dụng

Ứng dụng có thể được thực thi bằng việc gọi đến các chương trình phía máy chủ sử dụnggiao thức CGI. Tuy nhiên, khi có một yêu cầu từ một Webpage nào đó, hệ thống đềuphải tạo ra một tiến trình mới, giải pháp này không khả thi khi số lượng yêu cầu tại mộtthời điểm lớn. Vấn đề này dẫn đến sự phát triển của các máy chủ ứng dụng. Một máychủ ứng dụng duy trì một bể (pool) các tiến trình và sử dụng nó để thực thi các yêu cầu.Vì thế, nó tránh được chi phí khởi động tiến trình mới cho mỗi yêu cầu.

Cấu trúc tiến trình với CGI Scripts

260/470

Một Perl Script đơn giản

Các máy chủ ứng dụng đã phát triển các gói ở lớp giữa phức tạp, cung cấp nhiều hàm đểloại bỏ các tiến trình overhead. Chúng tạo thuận lợi cho việc truy cập đồng thời tới nhiềunguồn dữ liệu khác nhau (ví dụ, bằng việc cung cấp JDBC drivers), và cung cấp các dịchvụ quản lý phiên làm việc (session management). Thường thì, các tiến trình có mộtsố bước. Người sử dụng hy vọng hệ thống xử lý giao dịch của mình giống như chỉ cómột giao dịch tại một thời điểm. Một số phiên làm việc được nhận diện bằng cookies,URI extensions, và các trường ẩn ở trong các Form HTML có thể được sử dụng để nhậndiện một phiên làm việc. Các máy chủ ứng dụng cung cấp các chức năng để nhận ra mộtphiên làm việc nào đó khởi động và kết thúc và giữ lại dấu vết của các phiên làm việccủa từng người sử dụng. Chúng cũng giúp đảm bảo có được các truy cập cơ sở dữ liệubằng việc hỗ trợ một cơ chế user-id phổ biến. (Chi tiết hơn về bảo mật sẽ được trình bàytrong Chương 21).

261/470

Cấu trúc tiến trình trong kiến trúc Application Server

Servlets

Java servlets là những đoạn chương trình Java có thể chạy ở lớp giữa, Webservers hoặcmáy chủ ứng dụng. Có những quy ước đặc biệt xác định cách thức đọc dữ liệu đầu vàovà cách thức viết dữ liệu đầu ra bằng servlets. Servlets là platform độc lập, vì thế chúngđã trở nên rất phổ dụng đối với những nhà phát triển Web.

Vì servlets là những chương trình Java nên chúng rất linh hoạt. Ví dụ, servlets có thểxây dựng được Webpages, truy cập cơ sở dữ liệu, và duy trì trạng thái. Servlets có thểtruy cập tới tất cả Java APIs, bao gồm JDBC. Tất cả servlets phải thực thi giao diệnServlet. Trong hầu hết các trường hợp, servlets có thể thực hiện các lớp HttpServlet củacác server kết nối với các máy trạm thông qua HTTP. Lớp HttpServlet cung cấp cácphương thức như doGet và doPost để nhận các tham số từ các form HTML, và nó trả kếtquả cho các máy trạm thông qua HTTP. Các Servlets kết nối thông qua các giao thứckhác (như ftp) cần phải thêm lớp GenericServlet.

Servlets là những lớp Java được biên dịch bằng Servlet container. Servlet containerquản lý thời gian sống (life-span) của các servlets độc lập bằng việc tạo và hủy chúng.Mặc dù servlets có thể trả lời bất kỳ loại yêu cầu nào, nhưng chúng hầu như chỉ được sửdụng để mở rộng các ứng dụng trên Webservers. Với những ứng dụng này, có một thưviện rất hữu ích của các lớp servlet HTTP-riêng biệt.

Servlets thường quản lý các yêu cầu từ các form HTML và duy trì trạng thái giữa cácmáy chủ và máy trạm. Chúng ta bàn về cách thức duy trì trạng thái này trong Phần7.5. Một mẫu (templete) của một cấu trúc servlet chung được minh hoạ trong Hình 18.Servlets đơn giản này chỉ đưa ra hai chữ “Hello World”, nhưng nó chỉ ra cấu trúc chungcủa của một servlets đầy đủ-chính thức. Đối tượng yêu cầu (request object) được sửdụng để đọc dữ liệu từ form HTML. Đối tượng phản hồi (response object) được sử dụngđể xác định mã trạng thái phản hồi HTTP và các tiêu đề (header) của phản hồi HTTP.Đối tượng đầu ra này được sử dụng để soạn thảo nội dung trả về cho các máy trạm.

262/470

Nhớ rằng HTTP trả về một dòng trạng thái, một tiêu đề, một dòng trống và sau đó là đếnnội dung. Trong ví dụ này servlets của chúng ta chỉ trả về đoạn text đơn giản. Chúngta có thể mở rộng servlets này bằng việc thiết lập kiểu nội dung cho HTML, việc thêmHTML như sau:

Một cấu trúc servlet chung

Điều gì xảy ra trong suốt quá trình tồn tại của một servlet? Một vài phương thức đượcgọi ở các giai đoạn khác nhau trong quá trình phát triển của một servlet. Khi một trangyêu cầu là một servlet, webserver gửi yêu cầu này tới servlet container. Tại thời điểmtạo servlet, servlet container gọi tới phương thức init(), và trước khi kết thúc servlet này,servlet container gọi tới phương thức destroy() của servlet này.

Khi một servlet container gọi một servlet, nó bắt đầu bằng phương thức service(), sauđó phương thức này tự động gọi đến các phương thức sau dựa trên phương pháp chuyểngiao HTTP: service() gọi doGet() ứng với một HTTP GET request, và nó gọi doPost()ứng với một HTTP POST request. Việc phát đi tự động này cho phép một servlet thựchiện các công việc khác nhau trên một yêu cầu dữ liệu tuỳ vào phương pháp chuyểngiao HTTP. Thường thì, chúng ta không ghi đè lên phương thức service() trừ khi chúngta muốn lập trình cho một servlet xử lý cả HTTP POST request và HTTP GET requestgiống hệt nhau.

Chúng ta tổng kết những nội dung đã trình bày về servlets bằng một ví dụ trong Hình19, ví dụ này minh hoạ cách thức gửi các tham số từ một Form HTML tới một servlet.

263/470

Lấy ra User Name và Password từ một Form

JavaServer Pages

Trong những phần trước, chúng ta đã xem xét cách sử dụng các chương trình Java ởlớp giữa để mã hoá ứng dụng và kiết xuất ra những Webpage một cách linh động. Nếuchúng ta cần xuất ra các trang HTML, chúng ta lập trình nó là một đối tượng đầu ra. Vìthế, chúng ta có thể nghĩ về servlets như là một chương trình Java, cùng với việc nhúngHTML cho đầu ra.

264/470

JavaServer pages (JSPs) trao đổi các vai trò của đầu ra và ứng dụng. JavaServer pagesđược viết trong HTML cùng với servlet- như các đoạn mã lệnh được nhúng trong cácthẻ HTML đặc biệt. Vì thế, khi so sánh với servlets, JavaServer pages thích hợp hơn đểxây dựng các giao diện chỉ có một số đoạn chương trình bên trong, ngược lại servletsthích hợp hơn đối với các chương trình ứng dụng phức tạp.

Trong khi có một sự khác nhau lớn đối với những người lập trình, lớp giữa xử lýJavaServer pages theo một cách rất đơn giản: Chúng thường xuyên được biên dịch thànhmột servlet, sau đó được một servlet container quản lý tương tự như các servlets khác.

Đoạn chương trình trong Hình 20 chỉ ra một ví dụ JSP đơn giản. Trong phần giữa củađoạn mã HTML này, chúng ta truy cập tới thông tin từ một form.

Đọc các biến trong form bằng JSP

Duy trì trạng thái

Như những gì chúng ta đã thảo luận ở các phần trước, hệ thống cần phải duy trì trạngthái của người dùng khi họ đi qua các trang khác nhau. Ví dụ, xem xét việc một ngườidùng muốn thanh toán một số mặt hàng ở Website ‘Barnes and Nobble’. Đầu tiên, ngườidùng này phải thêm các sản phẩm muốn mua vào giỏ hàng trong khi đó cô ấy có thểduyệt qua các trang khác nhau.

265/470

Chúng ta gọi một tương tác với một Webserver là không lưu trạng thái nếu không cóthông tin nào được duy trì từ một yêu cầu này đến một yêu cầu tiếp theo. Chúng ta gọimột tương tác với một Webserver là stateful, hoặc chúng ta có thể gọi là state đượcduy trì, nếu có một phần bộ nhớ được sử dụng để lưu trữ thông tin giữa các yêu cầu tớimáy chủ, và những hành động khác nhau được đưa ra tuỳ thuộc vào nội dung được lưutrữ là gì. Giao thức HTTP là không lưu trạng thái.

Trong ví dụ Barnes và Nobble của chúng ta, chúng ta cần duy trì thông tin về giỏ hàngcủa người dùng. Vì trạng thái này không được duy trì ở giao thức HTTP nên nó phảiđược duy trì ở máy chủ hoặc ở máy trạm. Vì người thiết kế đã xây dựng giao thức HTTPlà không lưu trạng thái, hãy cùng chúng tôi ôn lại những ưu và nhược điểm của quyếtđịnh này. Đầu tiên, một giao thức không lưu trạng thái dễ dàng cho lập trình và sử dụng,và nó có nhiều tác dụng với các ứng dụng chỉ yêu cầu tải các thông tin tĩnh. Thêm nữa,không bộ nhớ ngoài nào cần được sử dụng để duy trì trạng thái, vì thế giao thức nàyrất hiệu quả. Mặt khác, thiếu các cơ chế bổ sung ở lớp trình diễn và lớp giữa, chúng takhông thể ghi lại các yêu cầu ở phía trước, và chúng ta không thể lưu lại được các giỏhàng và các đăng nhập người dùng.

Vì chúng ta không thể duy trì trạng thái bằng giao thức HTTP, vậy thì chúng ta sẽ duytrì nó ở đâu? Có hai cách lựa chọn. Chúng ta có thể thực hiện việc duy trì trạng thái nàyở lớp giữa, bằng việc sắp xếp thông tin trong bộ nhớ chính cục bộ của ứng dụng, hoặcthậm chí ở hệ thống cơ sở dữ liệu. Ngoài ra, chúng ta có thể duy trì trạng thái ở máytrạm bằng việc lưu trữ dữ liệu trong form này thông qua một cookie. Chúng ta sẽ bànđến hai cách duy trì trạng thái này trong hai phần tiếp theo.

Duy trì trạng thái ở lớp giữa

Ở lớp giữa, có một vài nơi ở lớp giữa cho phép ta duy trì trạng thái. Trước hết, chúng tacó thể lưu lại trạng thái này ở lớp đáy, trong máy chủ cơ sở dữ liệu. Trạng thái này giúpphục hồi hệ thống khi có sự cố, nhưng một truy cập cơ sở dữ liệu được yêu cầu để truyvấn và cập nhật trạng thái, một nút cổ chai dễ dàng hình thành. Mặt khác, ta có lưu trạngthái ở bộ nhớ chính của lớp giữa. Nhược điểm là những thông tin này là những thông tinhay thay đổi vì thế tốn rất nhiều bộ nhớ. Chúng ta cũng có thể lưu trữ trạng thái ở cácfile cục bộ của lớp giữa, một sự thoả hiệp giữa hai cách tiếp cận trên.

Một cách làm ở đây duy trì trạng thái ở lớp giữa hoặc lớp cơ sở dữ liệu chỉ cho nhữngdữ liệu cần được duy trì trên nhiều phiên làm việc khác nhau. Ví dụ dữ liệu này là nhữnghoá đơn của khách hàng trong quá khứ, một chuỗi những thao tác kích chuột cần phảighi lại khi người dùng đi qua các website này, hoặc những lựa chọn cố định khác màngười dùng làm, như quyết định về cách bố trí trang theo sở thích của mình. Như nhữngví dụ minh hoạ này, thông tin trạng thái thường tập trung xung quanh những người dùngtương tác với website.

266/470

Duy trì trạng thái ở lớp trình diễn: Cookies

Một khả năng khác là chúng ta duy trì trạng thái tại lớp trình diễn và gửi nó tới lớp giữacùng với HTTP request. Chúng ta thao tác chủ yếu với giao thức HTTP bằng việc gửinhững thông tin bổ sung vào mỗi request. Những thông tin này được gọi là một cookie.

Một cookie là một tập các cặp {name, value} có thể được quản lý ở lớp trình diễn và lớpgiữa. Cookies dễ dàng sử dụng trong Java servlets và JavaServer pages và cung cấp mộtcách đơn giản để làm việc với dữ liệu không quan trọng duy trì ở các máy trạm. Chúngduy trì một số phiên làm việc của máy trạm bởi vì chúng tồn tại trong các catch của trìnhduyệt ngay cả khi các trình duyệt đã đóng.

Một nhược điểm của cookies là chúng thường được coi như những ‘kẻ xâm lấn’, vì thếrất nhiều người dùng vô hiệu hoá cookies trên trình duyệt của họ; trình duyệt cho phépngười dùng ngăn chặn cookies lưu trên máy tính. Một nhược điểm khác là dữ liệu trênmột cookie có dung lượng tối đa là 4KB, nhưng với hầu hết ứng dụng đây không phảilà một giới hạn tồi. Chúng ta có thể sử dụng các cookies để lưu trữ các thông tin như:giỏ hàng của người dùng, thông tin đăng nhập và những lựa chọn không ‘kiên định’khác được sinh ra trong phiên làm việc hiện tại. Tiếp theo, chúng ta sẽ bàn đến cách cáccookies có thể được điều khiển bằng servlets ở lớp giữa.

The Servlet Cookie API

Một cookie được lưu trữ trong một file text nhỏ ở máy trạm và nó chứa các cặp (name,vale), trong đó cả name và value đều là xâu ký tự. Chúng ta tạo ra một cookie mới bằnglớp Java Cookie trong chương trình ứng dụng ở lớp giữa:

Cookie cookie = new Cookie("username","guest");cookie..setDomain( "www.bookstore.com");cookie.setSecure(false); // no SSL requiredcookie.setMaxAge(60*60*24*7*31); // one month lifetimeresponse.addCookie(cookie);

Hãy cùng chúng tôi nhìn vào đoạn chương trình này. Đầu tiên, chúng ta tạo ra một đốitượng cookie xác định bằng cặp {name, value}. Tiếp đến chúng ta thiết đặt các thuộctính của cookie này; sau đây một số thuộc tính chung nhất:

• setDomain và getDomain: Domain này xác định Website sẽ nhận cookie. Giátrị mặc định của thuộc tính này chính là domain đã tạo ra cookie.

• setSecure và getSecure: Nếu cờ (flag) bằng true, thì cookie này được gửi chỉkhi chúng ta đang sử dụng một phiên bản Sercure của giao thức HTTP, ví dụ làSSL.

267/470

• setMaxAge và getMaxAge: Thuộc tính MaxAge xác định thời gian sống củacookie tính theo đơn vị giây. Nếu giá trị MaxAge nhỏ hơn hoặc bằng 0, cookienày được xoá ngay khi đóng trình duyệt.

• setName và get Name: Chúng ta không sử dụng những hàm này trong đoạnchương trình của chúng ta, chúng cho phép chúng ta đặt tên cho cookie.

• setValue và getValue: Những hàm này cho phép chúng ta thiết đặt và đọc giátrị của cookie.

Cookie được thêm vào request object trong Java servlets để được gửi tới máy trạm. Khimột cookie được nhận từ một site (ví dụ www.bookstore.com), trình duyệt Web trênmáy trạm này gán nó vào tất cả các HTTP request nó gửi tới site này cho đến khi cookiekết thúc.

Chúng ta có thể truy cập tới nội dung của một cookie trong lớp giữa thông qua phươngthức getCookies() của đối tượng request, nó sẽ trả về một mảng các đối tượng cookies.Đoạn chương trình sau đây đọc mảng này và tìm cookie có tên là ‘username’.

Cookie[] cookies = request.getCookies(); String theUser;for(int i=0; i < cookies.length; i++) { Cookie cookie =cookies [i]; if (cookie.getName().equals("username"))theUser = cookie.getValue(); }

Một kiểm tra đơn giản có thể được sử dụng để kiểm tra một người dùng nào đó đã tắtcookies: Gửi một cookie tới người dùng này, sau đó kiểm tra xem đối tượng requestđược trả về vẫn chứa cookie này hay không. Ghi nhớ rằng một cookie không bao giờnên chứa password chưa được mã hoá hoặc những thông tin bí mật khác mà chưa mãhoá, vì người dùng có thể dễ dàng kiểm tra, sửa, và xoá bất kỳ cookie nào tại bất cứ thờiđiểm nào. Ứng dụng cần phải có những kiểm tra sự nhất quán để đảm bảo rằng dữ liệutrong cookie là đúng.

Trường hợp nghiên cứu: Cửa hàng sách trên Internet

Bây giờ DBDudes hướng tới việc thực hiện của lớp ứng dụng và xem xét bổ sung kếtnối DBMS tới World Wide Web.

DBDudes bắt đầu với việc xem xét quản lý các phiên làm việc (section). Ví dụ, ngườidùng muốn đăng nhập tới site, duyệt danh mục và lựa chọn những cuốn sách muốn muamà không muốn phải nhập lại mã số định danh của họ. Công việc của section là phảiquản lý các quá trình lựa chọn sách, thêm chúng vào giỏ, và có thể cả việc loại bỏ mộtsố quyển sách ra khỏi giỏ, kiểm tra và thanh toán sách.

Sau đó DBDudes xem xét xem Webpages hiển thị sách nên là tĩnh hay động. Nếu có mộtWebpage tĩnh cho mỗi quyển, thì trong cơ sở dữ liệu chúng ta cần thêm một trường vào

268/470

quan hệ Books để chỉ ra vị trí của file chứa quyển sách đó. Thậm chí cần có một thiếtkế giao diện đặc biệt cho mỗi quyển sách. Đây là một giải pháp tốn rất nhiều công sức.DBDudes thuyết phục B&N để xây dựng một Webpage cho tất cả các quyển sách theomột mẫu chung và thông tin về một quyển sách nào đó được lấy ra từ quan hệ Books.Vì thế, DBDudes không sử dụng các trang HTML tĩnh như ví dụ trong Hình 1 để hiểnthị thông tin.

DBDudes cân nhắc việc sử dụng XML để định dạng dữ liệu giữa máy chủ cơ sở dữ liệuvà lớp giữa, hoặc giữa lớp giữa và lớp máy trạm. Việc trình diễn dữ liệu trong XML củalớp giữa được minh hoạ trong Hình 2 và 3 cho phép dễ dàng tích hợp những nguồn dữliệu khác trong tương lai, nhưng B&N nhận thấy rằng ứng dụng không cần đến sự tíchhợp này, vì thế họ quyết định không sử dụng XML.

DBDudes thiết kế chương trình như sau. Họ nghĩ rằng sẽ có các Webpage khác nhaunhư sau:

• Index.jsp: Trang chủ của B&N. Đây là trang chính của cửa hàng. Trang này cócác trường tìm kiếm dạng text và các nút cho phép người dùng tìm kiếm sáchtheo tên tác giả, mã ISBN, hoặc tiêu đề. Ở đây cũng có đường liên kết tới tranghiển thị giỏ hàng –cart.jsp.

• Login.jsp: Cho phép những người dùng đã đăng ký được đăng nhập vào hệthống. Ở đây DBDudes sử dụng form HTML tương tự như trong Hình 11. Ởlớp giữa, họ sử dụng đoạn mã lệnh tương tự như trong Hình 19 và JavaServerpages như trong Hình 20.

• Search.jsp: Liệt kê tất cả các quyển sách trong cơ sở dữ liệu thoả mãn điềukiện tìm kiếm của người dùng. Người dùng có thể thêm những quyển vừa tìmthấy vào giỏ hàng; mỗi quyển có một nút để chuyển nó tới giỏ hàng (Nếuquyển này đã tồn tại trong giỏ, thì số lượng mua sẽ tăng lên một). Ở đây cũngcó một trường cho phép nhập số lượng quyển sách muốn mua đó. Trangsearch.jsp cũng chứa một nút trực tiếp liên kết tới trang cart.jsp.

• Cart.jsp: Liệt kê tất cả các quyển sách đang có trong giỏ hàng. Danh sách nàynên bao gồm tất cả các quyển sách trong giỏ hàng cùng với những thông tin vềtên sách, giá, và một hộp thoại dạng text cho phép người dùng nhập vào sốlượng muốn mua của mỗi quyển, và một nút để xoá bỏ sách ra khỏi giỏ ứng vớimỗi quyển. Trang này còn có ba nút khác: một nút để tiếp tục quá trình muahàng (nút này giúp người dùng trở về index.jsp), nút thứ hai để cập nhật giỏhàng sau khi đã sửa lại thông tin về số lượng sách trong hộp thoại text, và nútthứ ba để đi tới hoá đơn, trực tiếp đưa người dùng tới trang confirm.jsp.

• Confirm.jsp: Đưa ra một hoá đơn hoàn chỉnh và cho phép người dùng nhập vàothông tin của họ và mã khách hàng (custormer ID). Có hai nút ở trang này: mộtnút để huỷ bỏ hoá đơn và nút thứ hai là để chấp nhận (submit) hoá đơn cuốicùng. Nút huỷ bỏ sẽ huỷ đi hoá đơn và đưa người dùng về trang chủ. Nút

269/470

submit sẽ cập nhật cơ sở dữ liệu cùng với hoá đơn mới, làm rỗng giỏ hàng vàgiúp người dùng quay về trang chủ.

DBDudes cũng đề nghị sử dụng JavaScrip ở lớp giữa để kiểm tra dữ liệu đầu vào trướckhi nó được gửi tới lớp giữa. Ví dụ, trong trang login.jsp, DBDudes muốn viết đoạnchương trình JavaScrip tương tự như trong Hình 12.

Điều này dẫn DBDudes đến quyết định cuối cùng: cách kết nối các ứng dụng vớiDBMS. Họ xem xét hai cách chính trình bày trong Phần 7: CGI script hay là sử dụngmột máy chủ ứng dụng. Nếu họ sử dụng CGI scripts, họ sẽ phải viết chương trình quảnlý giao dịch- đây là một công việc không dễ. Nếu họ sử dụng một máy chủ ứng dụng, họcó thể sử dụng tất cả các chức năng mà máy chủ này cung cấp. Vì thế, họ đề nghị B&Nthực hiện việc xử lý phía máy chủ sử dụng một máy chủ ứng dụng.

B&N chấp nhận việc quyết định sử dụng một máy chủ ứng dụng, nhưng quyết địnhrằng không có đoạn mã chương trình nào được áp dụng cho máy chủ ứng dụng vì B&Nkhông muốn bị phụ thuộc vào một nhà cung cấp. DBDudes đồng ý xây dựng các phầnsau:

• DBDudes thiết kế các trang mức đỉnh- những trang cho phép người dùng đi tớiWebsite cũng như một loạt những form tìm kiếm và trình bày kết quả.

• Giả sử rằng DBDudes lựa chọn một máy chủ ứng dụng dựa vào Java, họ phảibiết Java servlets để xử lý các yêu cầu đưa ra từ form. Có khả năng họ sử dụnglại những JavaBean đang tồn tại. Họ có thể sử dụng JDBC như là một giao diệncơ sở dữ liệu; những ví dụ của chương trình JDBC có thể tìm thấy trong Phần6.2. Thay vì lập trình servlets, họ có thể dùng JavaServer pages và chú thíchcác trang bằng các thẻ đánh dấu JSP đặc biệt.

• DBDudes lựa chọn một máy chủ ứng dụng sử dụng các thẻ đánh dấu riêng củahọ, vì thế họ phải thương lượng lại với B&N, nhưng B&N không cho phép họsử dụng những thẻ như thế trong chương trình.

Bây giờ, chúng ta giả sử rằng DBDudes và B&N đã chấp nhận sử dụng CGI scripts,DBDudes sẽ phải thực hiện các công việc sau:

• Tạo các trang HTML mức đỉnh cho phép người dùng truy cập đến trang Webvà hàng loạt các form cho phép người dùng tìm kiếm sách thông qua ISBN, têntác giả, tiêu đề. Một trang ví dụ chứa form tìm kiếm được chỉ ra trong Hình 1.Khi thêm các form nhập dữ liệu đầu vào, DBDudes phải phát triển thêm cácgiao diện thích hợp để hiển thị kết quả.

• Phát triển ứng dụng để theo dõi một phiên làm việc của người dùng. Nhữngthông tin liên quan phải được lưu trữ ở phía máy chủ hoặc ở trình duyệt củangười dùng thông qua cookies.

270/470

• Viết các scripts xử lý những yêu cầu của người dùng. Ví dụ, một khách hàng cóthể sử dụng một form gọi là ‘Search books by title’ (Tìm sách theo tiêu đề) đểnhập tiêu đề và tìm kiếm sách theo tiêu đề. Giao diện CGI kết nối với mộtscript xử lý yêu cầu này. Ví dụ trong Hình 16 là minh hoạ của script kiểu nàyviết bằng Perl sử dụng thư viện DBI để truy cập dữ liệu.

Những bàn luận trên của chúng ta chỉ mới đề cập đến các giao diện phục vụ khách hàng.DBDudes cũng cần phải thêm vào ứng dụng những giao diện cho phép nhân viên cóthể cập nhật dữ liệu và người quản lý của B&N có thể truy vấn cơ sở dữ liệu để đưa ranhững báo cáo tổng hợp về tình tình kinh doanh.

Toàn bộ những file về trường hợp nghiên cứu này có thể được tìm thấy trên Webpagecủa quyển sách này.

Câu hỏi ôn tập

Trả lời những câu hỏi ôn tập sau, câu trả lời có thể tìm thấy ở phần được liệt kê bêncạnh:

• URIs và URLs là gì? (Phần 2.1)• Giao thức HTTP làm việc như thế nào? Giao thức không lưu trạng thái là gì?

(Phần 2.2)• Giải thích những khái niệm chính của HTML. Vì sao nó chỉ được sử dụng để

biểu diễn dữ liệu và mà không được sử dụng để trao đổi dữ liệu? (Phần 3)• HTML có những thiếu sót gì, và XML giải quyết chúng như thế nào? (Phần 4)• Những thành phần chính của một văn bản XML là gì? (Phần 4.1)• Vì sao chúng ta có XML DTDs? Thế nào là một văn bản XML được định dạng

tốt? Một văn bản XML đúng là gì? Cho một ví dụ về một văn bản XML đúngnhưng không được định dạng tốt, và ngược lại. (Phần 4.2)

• Vai trò của domain-specific DTDs? (Phần 4.3)• Kiến trúc ba lớp là gì? Những ưu điểm của nó so với kiến trúc một lớp và hai

lớp? Trình bày một cách tổng quát các tính năng chính của mỗi thành phầntrong kiến trúc ba lớp. (Phần 5)

• Giải thích cách thức kiến trúc ba lớp giải quyết các vấn đề sau của các ứngdụng Internet: tính không đồng nhất, máy trạm yếu (thin clients), tích hợp dữliệu, phát triển phần mềm. (Phần 5.3)

• Viết một Form HTML . Mô tả tất cả các thành phần của một Form HTML .(Phần 6.1)

• Đâu là sự khác nhau giữa phương thức HTML POST và HTML GET? (Phần11)

• JavaScrip sử dụng cho việc gì? Viết một hàm JavaScrip kiểm tra một thànhphần của Form HTML có chứa một địa chỉ email đúng cú pháp. (Phần 6.2)

271/470

• Style Sheets giải quyết vấn đề gì? Những ưu điểm khi sử dụng Style Sheets?(Phần 6.3)

• Cascading Style Sheets là gì? Giải thích các thành phần của Cascading StyleSheets. XSL là gì và nó khác với CSS ở điểm nào? (Phần 6.3 và 13)

• CGI là gì và nó giải quyết những vấn đề gì? (Phần 7.1)• Các máy chủ ứng dụng (application servers) là gì, nó khác với các Webservers

như thế nào? (Phần 7.2)• Servlets là gì? Cách thức servlets xử lý dữ liệu từ các form HTML? Giải thích

những gì xảy ra trong suốt thời gian sống của một servlets. (Phần 7.3)• Điều gì là sự khác nhau giữa servlets và JSP? Khi nào chúng ta nên sử dụng

servlets và khi nào chúng ta nên sử dụng JSP? (Phần 7.4)• Vì sao chúng ta cần duy trì trạng thái ở lớp giữa? Cookies là gì? Trình duyệt

quản lý cookies như thế nào? Chúng ta có thể truy cập dữ liệu trong cookies từservlets như thế nào? (Phần 7.5)

BÀI TẬP

Trả lời tóm tắt những câu hỏi sau:

1. Giải thích các khái niệm và trình bày chúng được sử dụng để làm gì: HTML,URL, XML, Java, JSP, XSL, XSLT, servlet, cookie, HTTP, CSS, DTD.

2. CGI là gì? Vì sao CGI được giới thiệu? Những nhược điểm của một kiến trúcsử dụng CGI scripts?

3. Sự khác nhau giữa một Webserver và một máy chủ ứng dụng? Các chức năngmà máy chủ ứng dụng điển hình cung cấp?

4. Một văn bản XML được định dạng tốt (well-formed) khi nào? Một văn bảnXML đúng khi nào?

Câu trả lời với mỗi câu hỏi như sau:

1. HTTP (HyperText Transfer Protocol) là một giao thức kết nối được sử dụng đểkết nối các máy trạm với các máy chủ trên Internet. URL (Universal ResourceLocator) là một xâu ký tự xác định một địa chỉ internet duy nhất. HTML(HyperText Markup Language) là một ngôn ngữ đơn giản sử dụng các thẻ đặcbiệt để viết văn bản trên Internet. CSS (Cascading Style Sheets) được sử dụngđể định nghĩa cách thức hiển thị các văn bản HTML. XML (Extensible MarkupLanguage) cho phép người dùng định nghĩa các thẻ đánh dấu của bản thân họtrong một văn bản nào đó. XSL (Extensible Style Language) có thể được sửdụng để biểu diễn cách thức hiển thị một văn bản XML. XSLT (XMLTransformation Language) là một ngôn ngữ cho phép biến đổi một đầu vàoXML thành một cấu trúc XML khác. DTD (Document Type Declaration) biểudiễn cách thức sử dụng các thẻ mới trong văn bản XML. Java là một ngôn ngữlập trình. Servlets là các phần nhỏ của Java chạy trên lớp giữa hoặc lớp máy

272/470

chủ và được sử dụng cho bất kỳ chức năng nào mà Java cung cấp. JSP(JavaServer Pages) là các trang HTML có các đoạn mã servlet được nhúng vào.Cookies là một cách đơn giản để lưu các dữ liệu tại máy trạm.

2. CGI (Common Gateway Interface) xác định cách thức máy chủ web kết nối vớicác chương trình khác bên phía máy chủ. Các chương trình CGI được sử dụngđể chuyển dữ liệu trong form HTML tới các chương trình khác bên phía máychủ. Mỗi một trang yêu cầu sẽ tạo ra một quá trình mới trên máy chủ.

3. Web server quản lý các trao đổi với các web browser bên phía máy trạm. Cácmáy chủ ứng dụng được sử dụng để duy trì một bể các tiến trình. Thôngthường, chúng ở lớp trung gian giữa web server và các nguồn dữ liệu như cáchệ cơ sở dữ liệu. Các máy chủ ứng dụng bỏ qua các vấn đề như việc chồng tạo-tiến-trình và có thể cũng được cung cấp các tính năng khác như trừu tượng hóanhững nguồn dữ liệu không đồng nhất và duy trì thông tin trạng thái của cácphiên làm việc.

4. Một văn bản XML là đúng nếu nó có DTD hỗ trợ và văn bản này tuân thủnhững quy tắc của DTD. Văn bản XML có định dạng tốt nếu nó tuân thủ nhữnghướng dẫn sau: (1) nó bắt đầu bằng khai báo XML, (2) nó chứa một phần tửgốc chứa tất cả các phần tử khác và (3) tất cả các phần tử được đặt lồng nhau.

Trả lời tóm tắt những câu hỏi sau về giao thức HTTP:

1. Một giao thức kết nối là gì?2. Cấu trúc của một HTTP request message? Cấu trúc của một HTTP reponse

message? Vì sao các HTTP message phải có một trường version (phiên bản)?3. Giao thức không lưu trạng thái là gì? Vì sao HTTP được thiết kế là không lưu

trạng thái?4. Chỉ ra HTTP request message đưa ra khi bạn yêu cầu tới trang chủ của cuốn

sách này (http://www.cs.wisc.edu/~dbbook). Chỉ ra HTTP response messagemà máy chủ đưa ra.

Dành cho độc giả

Trong bài tập này, bạn được yêu cầu để viết các chức năng của một giỏ hàng; bạn sẽ sửdụng nó trong các bài tập theo sau. Viết một loạt các trang JSP hiển thị một giỏ hànggồm các sản phẩm và cho phép người dùng thêm, xoá, thay đổi số lượng của từng sảnphẩm. Để làm điều này, sử dụng một cookie lưu trữ các thông tin sau:

• UserID của người dùng sở hữu giỏ hàng.• Số các sản phẩm có trong giỏ hàng.• ProductID và số lượng của mỗi sản phẩm.

• Khi thực thi cookies, nhớ thiết đặt thuộc tính Expires để cookie này có thể chắc chắnthuộc về một phiên làm việc hoặc không. Thử nghiệm cookies sử dụng .jsp và chắcchắn rằng bạn biết cách để truy cập, thiết đặt giá trị, và xoá một cookie.

273/470

• Bạn cần tạo ra năm trang .JSP như sau:• Index Page (index. jsp): Đây là điểm truy cập chính. Nó có một liên kết trực tiếp tới

trang Products để người dùng có thể bắt đầu mua hàng.• Products Page (products.jsp): Liệt kê toàn bộ các sản phẩm có trong cơ sở dữ liệu

cùng với các thông tin biểu diễn và giá của chúng. Đây là trang chính mà người dùngsẽ hoàn thiện giỏ hàng. Mỗi sản phẩm liệt kê nên có một nút next để thêm nó vào giỏhàng. (Nếu sản phẩm đó đã ở trong giỏ hàng thì số lượng sản phẩm này sẽ tăng lên mộtkhi kích vào nút next này). Tổng số các sản phẩm đang ở trong giỏ hàng cũng nên đượcđếm. Trang này cũng nên có một nút để người dùng đi trực tiếp đến trang Cart.

• Cart Page (cart.jsp): Chỉ ra danh sách tất cả các sản phẩm ở trong cookie giỏ hàngnày. Khi liệt kê sản phẩm nên có các thông tin về tên sản phẩm, giá và một hộp thoạitext cho phép nhập số lượng (người dùng có thể thay đổi số lượng sản phẩm ở đây), vàmột nút để xoá sản phẩm ra khỏi giỏ hàng. Trang này có ba nút: một nút để tiếp tụcviệc mua hàng (đưa người dùng trở về trang Products), nút thứ hai để cập nhật cookiesau khi đã sửa số lượng một mặt hàng muốn mua trong hộp thoại text, và nút thứ ba đểchấp nhận hoá đơn này, đưa người dùng trực tiếp tới trang Confirm.

• Confirm Page (confirm.jsp): Liệt kê hoá đơn cuối cùng. Có hai nút ở trang này. Mộtnút huỷ hoá đơn và một nút để chấp nhận. Nút huỷ sẽ xoá cookie này và đưa ngườidùng về trang Index. Nút chấp nhận sẽ cập nhật hoá đơn vào cơ sở dữ liệu, xoá cookienày và trả người dùng về trang Index.

Dành cho độc giả

Trong bài tập trước, thay thế trang product.jsp bằng trang search.jsp. Trang này chophép người dùng tìm kiếm sản phẩm theo tên hoặc mô tả sản phẩm. Nên có một hộpthoại dạng text để nhập thông tin cần tìm và các nút lựa chọn (radio button) cho phépngười dùng lựa chọn giữa tìm-bằng-tên và tìm-bằng-mô-tả. Trang xử lý kết quả tìmkiếm nên giống như trang products.jsp (đã trình bày trong bài tập trước) và được gọi làproduct.jsp. Nên truy cập tới tất cả các bản ghi mà nội dung tìm kiếm là một chuỗi concủa tên hoặc thông tin mô tả. Để tích hợp với bài tập trước, việc đơn giản là thay thế tấtcả các liên kết tới products.jsp bằng search.jsp.

Dành cho độc giả

Viết một chương trình xác thực đơn giản (không cần mã hoá phawords). Chúng ta coimột người dùng là đã xác thực nếu cô ấy cung cấp cặp username-phaword đúng; ngượclại, chúng ta nói người dùng đó là chưa được xác thực. Để đơn giản, giả sử rằng bạn cómột lược đồ cơ sở dữ liệu chỉ lưu trữ customer id và phaword:

• Phawords(cid: integer, username: string, phaword: string)• Khi người dùng đăng nhập vào hệ thống, như thế nào và ở đâu bạn ghi lại

thông tin này.

274/470

• Thiết kế một trang cho phép một người dùng đã đăng ký đăng nhập vào hệthống.

• Thiết kế một trang tiêu đề (header) để kiểm tra xem người dùng vào thăm trangnày đã đăng nhập rồi.

Dành cho độc giả

TechnoBook.com đang trong quá trình tổ chức lại Website. Vấn đề chính là làm thế nàoquản lý hiệu quả một số lượng lớn kết quả tìm kiếm. Trong một nghiên cứu về việcchương trình tương tác với người dùng, người ta biết rằng những người dùng hiện đạimuốn hiển thị 20 kết quả tìm kiếm trong một lần, và họ muốn chương trình thực hiệnnhư vậy. Những truy vấn trả về một đợt các kết quả được gọi là top N queries. (Xemphần 25.5 để biết cơ sở dữ liệu hỗ trợ việc này). Ví dụ, kết quả từ 1-20 được trả về, sauđó từ 21-40, sau đó 41-60 và tiếp tục như thế. Các công nghệ khác nhau được sử dụngđể thực hiện điều này và TechnoBooks.com muốn thực hiện hai công nghệ.

• Dữ liệu: Tạo một cơ sở dữ liệu với một bảng Books và sách trong đó sử dụng địnhdạng theo sau. Có 111 cuốn sách trong cơ sở dữ liệu của bạn với tiêu đề là AAA, BBB,CCC, DDD hoặc EEE, nhưng khoá của mỗi cuốn sách có cùng tiêu đề là không tuầntự.Books(bookid:INTEGER,title:CHAR(80),author:CHAR(80),price:REAL) For i = 1 to 111 { Insert the tuple (i, "AAA", "AAAAuthor", 5.99) i = i + 1 Insert the tuple (i, "BB", "BBBAuthor", 5.99) i = i + 1 Insert the tuple (i, "CCC", "CCCAuthor", 5.99) i = i + 1 Insert the tuple (i, "DDD", "DDDAuthor", 5.99) i = i + 1 Insert the tuple (i, "EEE", "EEEAuthor", 5.99)

• Công nghệ Placeholder: Một cách tiếp cận đơn giản nhất tới top N queries là lưu trữmột placeholder cho bộ giá trị kết quả đầu tiên và cuối cùng, và sau đó thực hiện cùngmột truy vấn. Khi kết quả truy vấn được trả về, bạn có thể lặp đi lặp lại placeholder vàtrả về tập 20 kết quả phía sau hoặc phía trước.

• Viết một Webpage bằng JSP để hiển thị nội dung của bảng Books, sắp xếp chúng theotrường Title và Bookid, và hiển thị 20 kết quả tìm thấy trong một lần, có nút liên kếtvới 20 kết quả tiếp theo, và nút quay trở lại 20 kết quả phía trước. Để làm được điềunày bạn nên sử dụng placeholders. Giả sử rằng bạn đang hiển thị các bản ghi từ 21 đến40, thì nút liên kết đến kết quả phía trước sẽ là display.jsp?lower=21 và nút liên kết đếncác kết quả tiếp theo sẽ là display.jsp?upper=40.

• Bạn không nên hiển thị một đường liên kết tới những kết quả trước (previous link) nếunhư không có kết quả nào ở phía trước; không nên hiển thị đường liên kết tới những

275/470

kết quả sau (next link) nếu kết quả đã hiển thị hết. Khi trang của bạn được gọi lại đểlấy tập kết quả khác, bạn có thể thực hiện cùng truy vấn này để có được tất cả các bảnghi, đệ quy trên tập kết quả này cho đến khi bạn ở điểm bắt đầu đúng, sau đó hiển thị20 kết quả tiếp theo.

• Cái gì là ưu điểm và nhược điểm của công nghệ này?• Công nghệ ràng buộc truy vấn: Công nghệ thứ hai để thực hiện top N queries là đẩy

các ràng buộc vào truy vấn (trong mệnh đề WHERE). Sử dụng mệnh đề này giúp chokết quả trả về ít hơn, vì thế tiết kiệm được giá phải trả cho việc thực hiện đệ quy. Ví dụ,xem xét bảng sau, sắp xếp theo (title, primary key).

• Trong cụm (batch) 1, dòng từ 1 đến 5 được hiển thị, và trong cụm 2 các dòng từ 6 đến10 được hiển thị, và tiếp tục. Sử dụng công nghệ placeholder, tất cả 15 dòng kết quả sẽđược trả về trong mỗi cụm. Sử dụng công nghệ ràng buộc truy vấn, cụm 1 hiển thị cáckết quả từ 1 đến 5 nhưng trả về kết quả từ 1 đến 15, cụm 2 hiển thị kết quả từ 6 đến 10nhưng trả về chỉ kết quả từ 6 đến 15, và cụm 3 sẽ hiển thị kết quả từ 11 đến 15 nhưngtrả về chỉ kết quả 11 đến 15.

• Ràng buộc có thể được đẩy vào truy vấn vì sự sắp xếp của bảng này. Xem xét truy vấnsau cho cụm 2 (hiển thi kết quả từ 6 đến 10). EXEC SQL SELECT B.Title FROMBooks B WHERE (B.Title = 'DDD' AND B.Bookid > 101) OR(B.Title > 'DDD') ORDER BY B.Title, B.Bookid

• Đầu tiên truy vấn này lấy ra tất cả các cuốn sách có tiêu đề là ‘DDD’, nhưng khoáchính lớn hơn khoá chính của bản ghi số 5 (bản ghi số 5 có khoá chính là 101). Ở đâysẽ trả về bản ghi số 6. Cũng như bất cứ quyển sách nào có tiêu đề đằng sau ‘DDD’cũng được trả về. Sau đó bạn có thể hiển thị 5 bản ghi đầu tiên.

• Thông tin sau cần được lưu lại để có những nút Previous và Next để hiển thị nhiều kếtquả hơn:

• Previous: Tiêu đề của bản ghi đầu tiên trong tập previous, và khoá chính củabản ghi đầu tiên trong tập previous.

276/470

• Next: Tiêu đề của bản ghi đầu tiên trong tập next, và khoá chính của bản ghiđầu tiên trong tập next.

• Có bốn phần của thông tin có thể được lập trình cho các nút Previous và Next nhưtrong phần trước. Sử dụng bảng cơ sở dữ liệu từ phần trước, viết một trang JavaServerhiển thị thông tin về 20 bản ghi mỗi lần. Trang này nên có các nút Previous và Next đểhiển thị các bản ghi trước và các bản ghi đằng sau. Sử dụng truy vấn có ràng buộc đểcó được tập bản ghi Next và Previous.

Dành cho độc giả

BÀI TẬP LỚN

Trong chương này, bạn tiếp tục các bài tập ở chương trước và tạo ra các phần khác củaứng dụng tại lớp giữa và lớp trình diễn. Các tài liệu liên quan đến các bài tập này có thểtìm thấy tại địa chỉ:

http://www.cs.wise.edu/~ dbbook

Nhớ lại Website Notown Records bạn đã làm trong Bài 6.6. Tiếp theo, bạn được yêucầu để phát triển website này. Thiết kế các phần của website làm việc ở lớp giữa và lớptrình diễn, và kết hợp chương trình bạn viết trong Bài 6.6 để truy cập cơ sở dữ liệu.

• 1. Trình bày chi tiết về các Webpage mà người dùng có thể truy cập. Luôn luôn lưu ýđến các vấn đề sau:

• Tất cả người dùng đều bắt đầu ở một trang chung.• Với mỗi hành động (action), người dùng cung cấp những thông tin đầu vào

nào? Họ cung cấp nó như thế nào, bằng việc kích trên một liên kết hay thôngqua một Form HTML .

• Thứ tự của các bước mà người dùng đi qua để đến một bản ghi? Biểu diễn dòngứng dụng mức cao bằng việc chỉ ra cách thức mỗi hành động người dùng đượcquản lý.

• 2. Viết các Webpage trong HTML không có nội dung động.• 3. Viết một trang cho phép người dùng đăng nhập vào trang. Sử dụng các cookies để

lưu trữ thông tin cố định ở trình duyệt của người dùng.• 4. Phát triển trang đăng nhập này bằng JavaScrip để kiểm tra rằng username chỉ được

chứa những ký tự từ a đến z.• 5. Phát triển các trang cho phép người dùng lưu trữ các sản phẩm trong một giỏ hàng

chỉ khi người dùng này đã đăng nhập. Nếu người dùng này chưa đăng nhập thì khôngcho phép họ thêm các sản phẩm vào giỏ hàng. Thực hiện chức năng này bằng cách sửdụng JSP để kiểm tra thông tin cookie của người dùng.

• 6. Tạo ra các trang còn lại để hoàn thiện Website.

Giành cho độc giả

277/470

Nhớ lại bài tập về công ty dược đã làm ở Bài 6.7 trong chương 6. Làm theo các bướctrong Bài 7.7 để thiết kế ứng dụng và lớp trình diễn và hoàn thiện Website.

Giành cho độc giả

Nhớ lại bài tập về cơ sở dữ liệu của trường đại học đã làm trong Bài 8 ở chương 6. Làmtheo các bước trong Bài 7 để thiết kế ứng dụng và lớp trình diễn và hoàn thiện Website.

Giành cho độc giả

Nhớ lại bài tập về đặt về máy bay đã làm trong Bài 6.9 ở chương 6. Làm theo các bướctrong Bài 7.7 để thiết kế ứng dụng và lớp trình diễn và hoàn thiện Website.

Giành cho độc giả

TÀI LIỆU THAM KHẢO

Phiên bản mới nhất của các chuẩn được đề cập trong chương này có thể tìm trongwebsite của tổ chức World Wide Web (www.w3.org). Nó chứa những liên kết tới nhữngthông tin về HTML, cascading style sheets, XML, XSL, và nhiều thứ khác. Quyển sáchcủa Hall giới thiệu chung về những công nghệ lập trình Web [357]: một điểm bắt đầutốt để nghiên cứu trên Web là trang www.Webdeveloper.com. Có rất nhiều quyển giớithiệu về lập trình CGI, ví dụ [210, 198]. Trang JavaSoft (java.sun.com) là điểm bắt đầutốt để nghiên cứu về servlets, JSP và tất cả các công nghệ khác liên quan đến Java.Quyển của Hunter[394] là những giới thiệu ban đầu hữu ích về Java servlets. Microsofthỗ trợ Active Server Pages (ASP), một công nghệ có thể so sánh được với JSP. Nhiềuhơn thông tin về ASP có thể được tìm thấy trên trang Microsoft Developer's Network(msdn.microsoft.com).

Có một địa chỉ rất tuyệt vời đề cập đến những ưu điểm của XML, ví dụ www.xml.comvà www.ibm.com/xml, tại đây cũng có các liên kết tới các chuẩn khác. Có nhữngquyển sách tốt đề cấp đến nhiều khía cạnh khác nhau của XML, ví dụ [195, 158.597, 474. 381, 320]. Thông tin về UNICODE có thể được tìm thấy trong websitehttp://www.imicode.org. Thông tin về JavaServer Pages và servlets có thể được tìm thấytại java.sim.com, java.sun.com/products/jsp và Java.sun.com/products/servlet.

278/470

Tổng quan về lưu trữ và chỉ sốDữ liệu trong một DBMS là một tập hợp của các bản ghi, hoặc file, và mỗi file chứa mộthoặc nhiều trang. Lớp phần mềm files and access methods (files và các phương thứctruy cập) tổ chức dữ liệu cẩn thận để hỗ trợ truy cập nhanh đến tập dữ liệu mong muốn.Việc hiểu các bản ghi được tổ chức như thế nào rất cần thiết để chúng ta có thể sử dụnghệ thống cơ sở dữ liệu một cách hiệu quả, và đó là mục đích chính của chương này.

Tổ chức file là phương pháp sắp xếp các bản ghi trong một file khi file này được lưu trữtrên đĩa. Mỗi tổ chức file làm cho các phép thao tác hiện tại trở nên hiệu quả hơn nhưngcó thể làm những phép thao tác khác phải trả chi phí cao hơn.

Xem xét một file chứa các bản ghi về các nhân viên, mỗi bản ghi chứa các trường age,name, và sal, file này sẽ được sử dụng như một ví dụ trong chương này. Nếu chúng tamuốn truy cập đến các các bản ghi theo thứ tự tăng dần của tuổi (age), việc sắp xếp filenày theo tuổi là một cách tổ chức file tốt, nhưng duy trì file theo thứ tự sẽ phải trả chiphí đắt nếu file này thường xuyên có sự thay đổi. Thêm nữa, chúng ta thường muốn hỗtrợ nhiều hơn một phép thao tác trên một tập hợp các bản ghi. Trong ví dụ của chúngta, chúng ta cũng muốn truy cập tất cả các nhân viên có lương lớn hơn $5000. Chúng taphải quét toàn bộ file để tìm những bản ghi thoả mãn.

Một công nghệ gọi là đánh chỉ mục hoá có thể trợ giúp khi chúng ta phải truy cập đếnmột tập các bản ghi theo nhiều cách. Phần 2 giới thiệu về đánh chỉ mục, một khía cạnhquan trọng của tổ chức file trong một DBMS. Chúng ta biểu diễn tổng quan về các cấutrúc dữ liệu chỉ mục trong Phần 3; những trình bày chi tiết sẽ có trong Chương 10 và 11.

Chúng ta sẽ minh hoạ sự quan trọng của việc lựa chọn tổ chức file thích hợp trong Phần4 thông qua một phân tích đơn giản của một vài tổ chức file. Mô hình định giá sử dụngtrong phân tích này được trình bày trong Phần 4.1, cũng được sử dụng trong nhữngchương cuối. Phần 5 chúng ta nhấn mạnh một số lựa chọn quan trọng được làm trongquá trình tạo các chỉ mục. Việc lựa chọn tập hợp các chỉ mục để xây dựng thường đượccho là nhiệm vụ của người quản trị giúp cải thiện khả năng thực thi của hệ thống.

Dữ liệu trong thiết bị lưu trữ ngoài

Một DBMS lưu trữ một khối lượng khổng lồ dữ liệu, và dữ liệu phải ổn định khi thựcthi chương trình. Vì thế, dữ liệu được lưu trong các thiết bị lưu trữ ngoài như đĩa, băngtừ, và chỉ được nạp vào trong bộ nhớ chính khi quá trình xử lý cần đến nó. Một đơn vịthông tin đọc hoặc ghi từ đĩa được gọi là một trang. Kích thước của mỗi trang là mộttham biến của DBMS, và có giá trị điển hình là 4KB hoặc 8KB.

279/470

Chi phí của một trang I/O (input từ đĩa tới bộ nhớ chính và output từ bộ nhớ chính rađĩa) có ảnh hưởng lớn đến chi phí của các phép toán cơ sở dữ liệu, và các hệ thống cơ sởdữ liệu thường tối ưu hoá rất cẩn thận chi phí này. Những chi tiết về các files chứa cácbản ghi được lưu trữ vật lý trên đĩa như thế nào và bộ nhớ chính được sử dụng như thếnào được trình bày trong Chương 9. Những điểm lưu ý sau là quan trọng và phải luônnhớ:

• Các đĩa là các thiết bị lưu trữ ngoài quan trọng nhất. Nó cho phép chúng ta truycập bất kỳ trang nào với một chi phí (nhiều hoặc ít hơn) một giá cố định nàođó. Tuy nhiên, nếu chúng ta đọc một vài trang theo thứ tự mà chúng đã đượcsắp xếp vật lý, thì chi phí này có thể ít hơn nhiều so với việc đọc các trang nàytheo một thứ tự ngẫu nhiên.

• Băng từ là thiết bị truy cập tuần tự và chúng bắt chúng ta phải đọc dữ liệu từngtrang một theo thứ tự, trang này sau trang kia. Chúng hữu dụng cho các dữ liệukhông được truy cập thường xuyên.

• Mỗi bản ghi trong một file có một định danh gọi là record id hay ngắn gọn làrid. Rid có thể được sử dụng để xác định địa chỉ của trang chứa bản ghi (chứarid) này.

Dữ liệu được đọc vào bộ nhớ để xử lý, và viết vào đĩa để lưu trữ lâu dài bằng một phầnmềm gọi là quản lý vùng đệm. Khi lớp files and access methods (thường được nhắc tớilà lớp file) cần xử lý một trang nào đó, nó yêu cầu hệ thống quản lý vùng đệm nạp trangnày, xác định rid của trang. Hệ thống quản lý vùng đệm nạp trang này từ đĩa nếu nókhông đang sẵn sàng trong bộ nhớ.

Những khoảng trống trên đĩa được quản lý bởi disk space manager (bộ quản lý khônggian đĩa), theo như kiến trúc phần mềm DBMS đã biểu diễn trong Phần 1.8. Khi lớpfiles and access methods cần thêm các khoảng trống để nhận thêm các bản ghi mới trongmột file nào đó, nó yêu cầu disk space manager định vị một trang đĩa bổ sung cho filenày: nó cũng thông báo cho disk space manager khi nó không còn cần đến một trang đĩanào đó của nó. Disk space manager giữ lại dấu vết của các trang đang được lớp file sửdụng; nếu một trang nào không còn cần cho lớp file nữa, space manager sẽ ghi nhớ điềunày, và tái sử dụng các vùng trống nếu lớp file yêu cầu một trang mới sau đó.

Trong phần còn lại của chương này, chúng ta sẽ tập trung vào lớp files and accessmethods.

Tổ chức file và đánh chỉ mục

File của các bản ghi là một khái niệm trừu tượng quan trọng trong DBMS, và được thựcthi bằng lớp files and access methods. Một file có thể được tạo, xoá bỏ, và có thể thêmhoặc xoá các bản ghi trong nó. Nó cũng hỗ trợ việc quét file; một thao tác quét cho phép

280/470

chúng ta duyệt tuần tự tất cả các bản ghi trong file. Một quan hệ được lưu trữ như mộtfile của các bản ghi.

File lưu trữ các bản ghi dưới dạng tập hợp các trang. Nó giữ lại dấu vết của các trangđã định vị cho từng file, và nếu trong file có các bản ghi được thêm vào hay xoá đi, nócũng lưu lại những vùng trống có thể trong các trang của file này.

Một cấu trúc file đơn giản nhất là file không sắp xếp thứ tự, còn gọi là file đống (heapfile). Các bản ghi trong heap file được lưu trữ theo thứ tự ngẫu nhiên trong các trang.Một tổ chức heap file hỗ trợ truy cập tới tất cả các bản ghi, hoặc truy cập tới một bảnghi cụ thể nào đó thông qua rid của nó; bộ quản lý file phải lưu lại vị trí các trang trongfile. (Chúng ta sẽ trình bày cách heap file thực thi thế nào trong Chương 9).

Một chỉ mục là một cấu trúc dữ liệu giúp tổ chức các bản ghi dữ liệu trên đĩa để tối ưucác phép toán truy cập. Một chỉ mục cho phép chúng ta truy cập hiệu quả tất cả các bảnghi thoả mãn các điều kiện tìm kiếm trên các trường khoá tìm kiếm của chỉ mục này.Chúng ta có thể cũng tạo ra các chỉ mục trên một tập các bản ghi dữ liệu, mỗi chỉ mụccó một khoá tìm kiếm khác nhau, để tăng tốc độ các thao tác tìm kiếm.

Xem xét ví dụ về các bản ghi nhân viên của chúng ta. Chúng ta có thể lưu trữ các bảnghi trong một file nào đó đã được chỉ mục trên trường tuổi của nhân viên. Thêm nữa,chúng ta có thể tạo ra một file chỉ mục bổ trợ trên trường salary, để tăng tốc các truyvấn cần thông tin về lương của nhân viên. File đầu tiên chứa các bản ghi về nhân viên,và file thứ hai chứa các bản ghi cho phép chúng ta định vị được các bản ghi nhân viênthoả mãn điều kiện truy vấn trên lương.

Chúng ta sử dụng khái niệm cổng vào dữ liệu để dẫn đường tới các bản ghi được lưu trữtrong một file chỉ mục. Một cổng vào dữ liệu có giá trị khoá tìm kiếm k, ký hiệu là k*,chứa đầy đủ thông tin để định vị (một hoặc nhiều) các bản ghi dữ liệu có giá trị khoá tìmkiếm k. Chúng ta có thể thực hiện tìm kiếm trên một chỉ mục để tìm ra các cổng vào dữliệu mong muốn, và sau đó sử dụng nó để lấy ra các bản ghi dữ liệu. Và đây là một cáchthực hiện rất hiệu quả.

Có ba Trường hợp (Alternative) chính về những gì được lưu trữ trong một cổng vào dữliệu của một chỉ mục:

1. Cổng vào dữ liệu k* là một bản ghi dữ liệu thực sự (có giá trị khoá tìm kiếm k).2. Cổng vào dữ liệu là một cặp (k, rid ), trong đó rid là record id của một bản ghi

dữ liệu có giá trị khoá tìm kiếm k.3. Cổng vào dữ liệu là cặp (k, rid-list ), trong đó rid-list là một danh sách các

record ids của các bản ghi dữ liệu có giá trị khoá tìm kiếm k.

Tất nhiên, nếu chỉ mục này được sử dụng để lưu trữ các bản ghi dữ liệu thực, thì trongAlternative (1), mỗi cổng vào dữ liệu k* là một bản ghi dữ liệu với khoá tìm kiếm có

281/470

giá trị k. Chúng ta có thể xem chỉ mục như một tổ chức file đặc biệt. Vì thế một tổ chứcfile chỉ mục có thể được sử dụng thay vì một file được sắp hoặc một file mà các bản ghikhông được sắp thứ tự lộn xộn.

Alternatives (2) và (3), chứa những cổng vào dữ liệu trỏ đến các bản ghi dữ liệu, độclập với tổ chức file sử dụng các indexed file (tức là, file chứa các bản ghi dữ liệu).Alternative (3) đề xuất một cách sử dụng không gian đĩa tốt hơn Alternative (2), trongđó các cổng vào dữ liệu có thể thay đổi độ lớn, phụ thuộc vào số lượng các bản ghi dữliệu và giá trị khoá tìm kiếm được cho.

Nếu chúng ta muốn xây dựng nhiều hơn một chỉ mục trên một tập hợp các bản ghi dữliệu- ví dụ, chúng ta muốn xây dựng các chỉ mục trên cả hai trường age và sal cho mộttập hợp các bản ghi nhân viên- thì tối đa chỉ một trong hai chỉ mục này nên sử dụngAlternative(1) vì chúng ta nên tránh việc lưu trữ các bản ghi dữ liệu nhiều lần.

Các chỉ mục phân cụm

Khi một file nào đó được tổ chức để thứ tự của các bản ghi dữ liệu là giống nhau hoặcgần với thứ tự của các cổng vào dữ liệu trong một vài chỉ mục, thì chúng ta nói rằngchỉ mục này được phân cụm (clustered); ngược lại, nó là chỉ mục không phân cụm(unclustered index). Theo định nghĩa, chỉ mục sử dụng Alternative (1) là chỉ mục đượcphân cụm. Chỉ mục sử dụng Alternative (2) hoặc (3) có thể là một chỉ mục phân cụmchỉ nếu các bản ghi dữ liệu này được sắp xếp theo trường khoá tìm kiếm. Ngược lại, nếuthứ tự các bản ghi dữ liệu là ngẫu nhiên, hoàn toàn xác định bởi thứ tự vật lý của chúng,thì không có cách nào để sắp xếp những cổng vào dữ liệu này trong một chỉ mục theocùng một thứ tự.

Thực tế, các file hiếm khi được lưu trữ theo thứ tự vì chi phí để duy trì việc này rất đắtnếu dữ liệu này cần được cập nhật. Vì thế trên thực tế, chỉ mục phân cụm là một chỉ mụcsử dụng Alternative (1), và các chỉ mục sử dụng Alternatives (2) hoặc (3) là chỉ mụckhông phân cụm.

Đôi khi chúng ta coi chỉ mục đang sử dụng Alternative (1) là clustered file, vì các cổngvào dữ liệu là các bản ghi dữ liệu thực sự, và vì thế chỉ mục này là một file chứa cácbản ghi dữ liệu. (Như đã quan sát ở trên, việc tìm và quét trên một chỉ mục sẽ trả về chỉnhững cổng vào dữ liệu của nó, dù cho là chỉ mục này chứa những thông tin khác dùngđể tổ chức các cổng vào dữ liệu.)

Chi phí của việc sử dụng một chỉ mục để đáp lại một truy vấn tìm kiếm miền có thể rấtrất lớn tuỳ vào chỉ mục này có được phân cụm không. Nếu chỉ mục này được phân cụm,tức là, chúng ta đang sử dụng khoá tìm kiếm của một clustered file, rids trong các cổngvào dữ liệu trỏ tới một tập hợp các bản ghi kề nhau, và chúng ta chỉ cần truy cập một vàitrang dữ liệu. Nếu chỉ mục này là không phân cụm, mỗi cổng vào dữ liệu có thể chứa

282/470

một rid trỏ tới một trang dữ liệu riêng biệt, dẫn tới số lượng các trang dữ liệu I/Os nhiềubằng số lượng các cổng vào dữ liệu ứng với phép chọn miền, như minh hoạ trong Hình1. Điểm này được bàn thêm trong Chương 13.

Chỉ mục không phân cụm sử dụng Alternative (2)

Các chỉ mục chính và chỉ mục phụ

Một chỉ mục trên một tập các trường trong đó có khoá chính (xem Chương 3) được gọilà chỉ mục chính; những chỉ mục khác được gọi là các chỉ mục phụ. (Cụm từ chỉ mụcchính và chỉ mục phụ đôi khi được sử dụng với nghĩa khác. Chỉ mục sử dụng Alternative(1) được gọi là chỉ mục chính, và chỉ mục sử dụng Alternatives (2) hoặc (3) được gọi làchỉ mục phụ.)

Hai cổng vào dữ liệu được gọi là trùng nhau nếu chúng có cùng giá trị của trường khoátìm kiếm liên quan đến chỉ mục này. Chỉ mục chính được đảm bảo là không chứa sựtrùng nhau, nhưng chỉ mục trên các trường khác có thể chứa sự trùng nhau. Nói chung,các chỉ mục phụ sẽ chứa sự trùng nhau. Nếu chúng ta biết rằng không tồn tại sự trùngnhau, tức là chúng ta biết rằng khoá tìm kiếm chứa một một vài khoá dự tuyển, chúng tagọi chỉ mục này là chỉ mục duy nhất.

Một vấn đề quan trọng là các cổng vào dữ liệu trong một chỉ mục được tổ chức như thếnào để hỗ trợ truy cập dữ liệu hiệu quả. Chúng ta sẽ bàn đến trong phần sau.

283/470

Các cấu trúc dữ liệu chỉ mục

Một cách để tổ chức cổng vào dữ liệu là băm các cổng vào dữ liệu dựa trên khoá tìmkiếm. Một cách khác để tổ chức các cổng vào dữ liệu là xây dựng một cấu trúc dữ liệudạng-cây, cấu trúc này dùng để định hướng tìm kiếm các cổng vào dữ liệu. Chúng tôigiới thiệu hai cách tiếp cận cơ bản này trong phần này. Chúng ta sẽ nghiên cứu chi tiếtvề chỉ mục dựa trên cây trong Chương 10 và chỉ mục dựa trên băm trong Chương 11.

Chúng ta ghi nhớ rằng việc lựa chọn công nghệ chỉ mục dựa trên cây hoặc dựa trên bămcó thể được kết hợp với bất kỳ một trong ba Alternative.

Chỉ mục dựa trên băm

Chúng ta có thể tổ chức các bản ghi sử dụng một công nghệ gọi là băm để nhanh chóngtìm được các bản ghi có giá trị khoá tìm kiếm bằng giá trị đưa vào. Ví dụ, nếu file củacác bản ghi nhân viên được băm dựa trên trường name, chúng ta có thể truy cập tất cảcác bản ghi về Joe.

Trong cách tiếp cận này, các bản ghi trong file được nhóm lại trong một buckets, trongđó một bucket chứa một trang chính và có thể là các trang khác được liên kết trong mộtchuỗi.

Một bản ghi nào đó thuộc về bucket nào đó có thể được xác định bằng cách thực hiệnmột hàm đặc biệt trên khoá tìm kiếm, hàm này gọi là hàm băm. Cho một bucket, cấutrúc chỉ mục dựa trên băm cho phép chúng ta truy cập trang chính của bucket này trongmột hoặc hai đĩa I/Os.

Đối với việc thêm bản ghi, bản ghi được thêm vào một bucket phù hợp cùng với cáctrang ‘tràn’ nếu cần thiết. Để tìm kiếm một bản ghi nếu biết giá trị khoá tìm kiếm, chúngta áp dụng hàm băm này để xác định bucket nào chứa bản ghi và tìm trong tất cả cáctrang của bucket này. Nếu chúng ta không có giá trị khoá tìm kiếm, ví dụ, chỉ mục nàyđược xây dựng dựa trên sal và chúng ta muốn tìm các bản ghi có giá trị tuổi bằng mộttuổi nào đó nhập vào, chúng ta phải quét tất cả các trang trong file này.

Trong chương này, chúng ta giả sử rằng việc áp dụng một hàm băm tới (khoá tìm kiếmcủa) một bản ghi nào đó cho phép chúng ta xác định và truy cập được trang chứa bản ghinày chỉ bằng một thao tác I/O. Trên thực tế, các cấu trúc chỉ mục dựa trên băm thườngthực hiện việc thêm, xoá và cho phép chúng ta truy cập đến trang chứa bản ghi này bằngmột hoặc hai thao tác I/Os (xem Chương 11).

Chỉ mục băm được minh hoạ trong Hình 2, nơi mà dữ liệu được lưu trong một file đượcbăm trên trường age; các cổng vào dữ liệu trong file chỉ mục đầu tiên này là các bản ghidữ liệu thực. Việc áp dụng hàm băm trên trường age xác định được trang chứa bản ghi

284/470

này. Hàm băm h trong ví dụ này thực sự rất đơn giản; nó chuyển giá trị khoá tìm kiếmthành biểu diễn nhị phân và sử dụng hai bit ít quan trọng nhất để định danh bucket.

Hình 2 cũng chỉ ra chỉ mục với khoá tìm kiếm sal chứa cặp (sal, rid) là các cổng vào dữliệu. Rid (viết tắt của record id) cấu thành nên cổng vào dữ liệu trong chỉ mục thứ hainày là một con trỏ trỏ tới một bản ghi có giá trị khoá tìm kiếm sal (và được chỉ ra tronghình này là một mũi tên trỏ tới bản ghi dữ liệu này).

Việc sử dụng ký hiệu này được giới thiệu trong Phần 2, Hình 2 minh hoạ Alternatives(1) và (2) cho các cổng vào dữ liệu. File của các bản ghi nhân viên được băm trên trườngage, và Alternative (1) được sử dụng cho các cổng vào dữ liệu. Chỉ mục thứ hai trêntrường sal cũng sử dụng việc băm để xác định các cổng vào dữ liệu – bây giờ là cặp(sal, rid của bản ghi nhân viên), tức là Alternative (2) được sử dụng cho các cổng vàodữ liệu.

Index-Organized File Hashed trên age, với Chỉ mục Hỗ trợ trên sal

Ghi nhớ rằng khoá tìm kiếm cho một chỉ mục nào đó có thể là một hoặc nhiều trường,và nó không cần định danh duy nhất một bản ghi. Ví dụ, trong chỉ mục salary, hai cổngvào dữ liệu có cùng khoá tìm kiếm giá trị là 6003. (Có sự lạm dụng trong sử dụng kháiniệm khoá. Khoá chính hoặc khoá dự tuyển - những trường định danh duy nhất một bảnghi; xem Chương 3- không liên quan đến khái niệm của khoá tìm kiếm.

Chỉ mục dựa trên cây

Ngoài cách sử dụng chỉ mục dựa trên băm, chúng ta còn có thể sử dụng cấu trúc dữ liệudạng cây để tổ chức các bản gho. Các cổng vào dữ liệu được sắp xếp theo thứ tự của giá

285/470

trị khoá tìm kiếm, và một cấu trúc dữ liệu tìm kiếm phân cấp được duy trì để định hướngviệc tìm kiếm.

Hình 3 chỉ ra các bản ghi nhân viên như Hình 2, nhưng lần này nó được tổ chức trongmột chỉ mục cấu trúc cây với khoá tìm kiếm là age. Với mỗi nút trong hình này (ví dụ,các nút có nhãn A, B, Ll, L2) là một trang vật lý, và việc truy cập một nút cần một I/Ođĩa.

Mức thấp nhất của cây này gọi là mức lá, chứa các cổng vào dữ liệu; trong ví dụ củachúng ta đó là những bản ghi nhân viên. Để minh hoạ những ý tưởng này tốt hơn, chúngta vẽ Hình 3 như là ở đó có việc thêm vào các bản ghi nhân viên, một số có tuổi nhỏhơn 22 và một số có tuổi lớn hơn 50 (giá trị tuổi thấp nhất và cao nhất xuất hiện trongHình 2.) Những bản ghi nhân viên có tuổi nhỏ hơn 22 sẽ được xuất hiện trong các tranglá (L1), và các bản ghi có tuổi lớn hơn 50 sẽ xuất hiện trong các trang lá (L3).

Chỉ mục có cấu trúc dạng cây

Cấu trúc này cho phép chúng ta định vị các cổng vào dữ liệu với các giá trị khoá tìmkiếm trong một vùng mong muốn một cách hiệu quả. Tất cả các tìm kiếm bắt đầu ở nútcao nhất, gọi là nút gốc, và nội dung của các trang ở mức không-lá định hướng việc tìmkiếm tới trang lá đúng. Các trang không-lá chứa các nút phân tách nhau bởi giá trị khoátìm kiếm. Con trỏ bên trái của giá trị khoá k trỏ tới cây con chứa chỉ những cổng vào dữliệu nhỏ hơn k. Con trỏ bên phải của giá trị khoá k trỏ tới cây con chứa chỉ những cổngvào dữ liệu lớn hơn hoặc bằng k. Trong ví dụ của chúng ta, giả sử rằng chúng ta muốntìm tất cả cổng vào dữ liệu với 24 < age < 50. Mỗi đường đi từ nút gốc tới một nút controng Hình 2 có một nhãn giải thích nội dung chứa trong cây con đó. (Mặc dù các nhãncủa các đường đi còn lại không được chỉ ra, nhưng chúng ta cũng có thể dễ dàng suyluận ra.) Trong ví dụ tìm kiếm của chúng ta, chúng ta tìm các cổng vào dữ liệu có giá trịkhoá tìm kiếm > 24, và nó được định hướng là ở nút con giữa, nút A. Kiểm tra nội dung

286/470

của nút này, chúng ta lại được định hướng để tìm tiếp trong nút B. Kiểm tra nội dungcủa nút B, chúng ta lại được định hướng để tìm tiếp trong nút lá L1, nút này chứa cáccổng vào dữ liệu chúng ta đang tìm.

Quan sát thấy rằng các nút là L2 và L3 cũng chứa những cổng vào dữ liệu thoả mãn điềukiện của chúng ta. Để thuận lợi cho việc truy cập các cổng vào dữ liệu dữ liệu như vậytrong khi tìm kiếm, tất cả các trang lá được duy trì trong một danh sách liên kết đôi. Vìthế, chúng ta có thể đến trang L2 sử dụng con trỏ next trên trang L1, và sau đó đến trangL3 sử dụng con trỏ next trên L2.

Vì thế, số lượng thao tác I/Os trong quá trình tìm kiếm bằng với chiều dài đường đi từgốc đến lá cộng với số các trang lá chứa các cổng vào dữ liệu thoả mãn. B+tree là mộtcấu trúc chỉ mục đảm bảo rằng tất cả các đường đi từ gốc đến lá trong một cây nào đósẽ có chiều dài tương đương, tức là, cấu trúc này luôn cân bằng về chiều cao. Việc tìmkiếm một trang lá thoả mãn nhanh hơn tìm kiếm nhị phân tất cả các trang trong một fileđược sắp vì mỗi nút không phải là lá có thể phù hợp với một số lượng lớn các con trỏ,và chiều cao của cây trong thực tế ít khi nhiều hơn ba hoặc bốn. Chiều cao của cây cânbằng là chiều dài của đường đi từ gốc đến lá; trong Hình 3, chiều cao của cây là ba. Sốlượng các I/Os để truy cập một trang lá mong muốn nào đó là bốn, bao gồm gốc và cáctrang lá. (Trong thực tế, gốc thường nằm trong buffer pool vì nó thường xuyên đượctruy cập, và chúng ta cần ba thao tác I/Os cho một cây có chiều cao bằng ba.)

Số lượng trung bình các con của một nút không phải là lá được gọi là fan-out của cây.Nếu tất cả các nút không phải là lá có n con, một cây chiều cao h sẽ có nh trang lá. Trongthực tế, các nút không có cùng số lượng các con, nhưng khi sử dụng F là giá trị trungbình của n, chúng ta vẫn có được số lượng các trang lá xấp xỉ là Fh. Trong thực tế, Fít nhất là 100, có nghĩa là cây có chiều cao bằng bốn sẽ chứa 100 triệu trang lá. Vì thế,chúng ta có thể phải tìm kiếm trong một file có 100 triệu trang lá và tìm ra trang chúngta muốn mà chỉ cần sử dụng bốn thao tác I/Os; trong khi đó, tìm kiếm nhị phân của filetương đương sẽ mất log2100.000.000 (over 25) I/Os.

So sánh các tổ chức file

Bây giờ chúng ta sẽ so sánh chi phí của một số các thao tác đơn giản trên các tổ chứcfile cơ bản được thực hiện trên một tập các bản ghi nhân viên. Chúng tôi giả sử rằng cácfile các các chỉ mục được tổ chức theo khoá tìm kiếm tổ hợp là (age,sal), và tất cả cácthao tác được xác định trên những trường này. Các tổ chức file chúng ta đề cập như sau:

• File chứa các bản ghi nhân viên có thứ tự ngẫu nhiên, hoặc heap file.• File chứa các bản ghi nhân viên được sắp xếp trên hai trường (age, sal).• Clustered B+tree file với khoá tìm kiếm là (age, sal).• Heap file với một unclustered B+ tree index trên (age, sal).• Heap file với một unclustered hash index trên (age. sal).

287/470

Mục đích của chúng ta là nhấn mạnh sự quan trọng của việc lựa chọn một tổ chức filephù hợp, và danh sách trên bao gồm các lựa chọn khác nhau được xem xét trong thựctế. Rõ ràng, chúng ta có thể lưu các bản ghi theo thứ tự được sắp hoặc không. Chúng tacũng có thể xây dựng một chỉ mục trên file dữ liệu.

Các thao tác chúng ta xem xét bao gồm:

• Quét: Truy cập tất cả các bản ghi trong file này. Các trang trong file này phảiđược đưa vào buffer pool từ đĩa. Ở đây cũng có một CPU overhead cho từngbản ghi phục vụ việc định vị bản ghi này trên trang (trong buffer pool này).

• Tìm kiếm với điều kiện bằng: Truy cập tất cả các bản ghi thoả mãn điều kiệnchọn bằng; ví dụ, “Tìm các bản ghi nhân viên có age 23 và sal 50.” Các trangchứa các bản ghi thoả mãn điều kiện bằng này phải được nạp vào từ đĩa, và cácbản ghi thỏa mãn phải được đặt vào trong các trang được truy cập.

• Tìm kiếm với điều kiện miền: Truy cập tất cả các bản ghi thoả mãn điều kiệnchọn miền; ví dụ, “Tìm tất cả các bản ghi nhân viên có age lớn hơn 35”.

• Thêm một bản ghi: Khi thêm một bản ghi vào trong file, chúng ta phải xácđịnh trang nào trong file sẽ chứa bản ghi này, nạp trang này từ đĩa vào bộ nhớ,sửa nó để có bản ghi mới, và sau đó viết trang này trở lại ra đĩa.

• Xoá một bản ghi: Khi xoá một bản ghi được định danh bởi rid của nó, chúngta phải xác định trang nào đang chứa bản ghi này, đưa nó vào bộ nhớ từ đĩa,sửa nó, và viết nó trở lại đĩa. Tuỳ vào cách tổ chức file, chúng ta có thể phảinạp, sửa và viết trở lại những trang liên quan nếu cần.

Mô hình định giá

Trong so sánh về các tổ chức file của chúng ta, và trong cuối chương này, chúng ta sửdụng một mô hình định giá đơn giản để cho phép ước lượng chi phí (theo thời gian thựcthi) của các thao tác cơ sở dữ liệu khác nhau. Chúng ta sử dụng B để ký hiệu cho sốlượng các trang dữ liệu khi các bản ghi được dồn đầy vào trong trang mà không cònkhông gian lãng phí nào, và R để ký hiệu cho số lượng các bản ghi trong mỗi trang. Thờigian trung bình để đọc hoặc ghi một trang đĩa là D, và thời gian trung bình để xử lý mộtbản ghi (ví dụ, so sánh một giá trị của trường với một hằng số nào đó) là C. Trong tổchức file băm, chúng ta sử dụng một hàm gọi là hàm băm để ánh xạ một bản ghi vàomột dải của các số; thời gian yêu cầu để áp hàm băm này cho một bản ghi nào đó là H.Với các chỉ mục cây, chúng ta sẽ sử dùng F để ký hiệu cho fan-out, như đề cập trongPhần 3.3, fan-out có giá trị ít nhất là 100.

Ngày nay giá trị của D bằng khoảng 15milli giây, C và H = 100nano giây; vì thế chúngta hy vọng là chi phí cho I/O là chủ yếu. I/O thường chiếm phần lớn hơn rất nhiều sovới giá của các thao tác khác, và vì thế việc tính được chi phí I/O sẽ cung cấp cho chúngta chi phí xấp xỉ khá đúng. Thêm nữa, tốc độ CPU hiện nay tăng lên đáng kể, ngược lạitốc độ xử lý trên đĩa không tăng lên tương ứng. (Mặt khác, khi kích thước bộ nhớ chính

288/470

tăng lên, số lượng các trang được đưa vào bộ nhớ chính cùng tăng lên, dẫn đến số lượngcác yêu cầu I/O ít đi!) Chúng ta tập trung vào các thành phần I/O trong mô hình địnhgiá, và chúng ta giả sử hằng số C là chi phí xử lý mỗi bản ghi trong bộ nhớ trong. Bạnhãy luôn lưu ý đến những quan sát sau:

Những hệ thống thực phải đề cập đến những ảnh hưởng khác đến chi phí, như giá CPU(và chi phí truyền dữ liệu qua mạng trong các cơ sở dữ liệu phân tán).

Mặc dù chúng ta chỉ tập trung vào chi phí I/O, mô hình chính xác xem xét tất cả khíacạnh cũng sẽ rất phức tạp. Vì thế, chúng ta sử dụng một mô hình đơn giản trong đóchúng ta chỉ đếm số lượng các trang đọc hoặc ghi vào đĩa và dùng nó làm thước đo I/O.Chúng ta bỏ qua vấn đề quan trọng là truy cập theo khối trong phân tích của chúng ta-thông thường, các hệ thống đĩa cho phép chúng ta đọc một khối các trang bằng chỉ mộtyêu cầu I/O. Chi phí sẽ bằng thời gian cần để tìn trang đầu tiên trong khối và chuyểntất cả các trang trong khối này vào bộ nhớ. Việc truy cập theo khối như thế này có thểrẻ hơn nhiều so với phát ra một yêu cầu I/O ứng với mỗi trang trong khối, đặc biệt nếunhững yêu cầu này không được thực hiện liên tiếp, vì chúng ta sẽ phải cộng thêm chiphí tìm kiếm từng trang trong khối.

Chúng ta bàn đến những thành phần liên quan đến mô hình định giá bất cứ khi nàonhững giả định đơn giản này ảnh hưởng đến những kết luận quan trọng của chúng ta.

Heap file

Quét: Chi phí là B(D+RC) vì chúng ta phải truy cập B trang, mỗi trang mất một thờigian là D, và với mỗi trang, cần phải xử lý R bản ghi và mỗi bản ghi mất thời gian C.

Tìm kiếm với phép chọn bằng: Giả sử chúng ta biết rằng có chính xác một bản ghi thoảmãn điều kiện bằng, tức là, việc chọn lọc được xác định dựa trên một khoá dự tuyển.Trung bình, chúng ta phải quét một nửa file, giả sử rằng bản ghi này tồn tại và việc phânbố giá trị trong trường tìm kiếm là đồng đều. Với mỗi trang dữ liệu được truy cập, chúngta phải kiểm tra tất cả các bản ghi trên trang này để xem nó có phải là bản ghi cần tìm.Chi phí là 0.5B(D + RC). Tuy nhiên, nếu không có bản ghi nào thoả mãn điều kiện chọn,chúng ta phải quét toàn bộ file để chắc chắn điều này. Nếu phép chọn không dựa trêntrường khoá dự tuyển (ví dụ, “Tìm các nhân viên có age=18”, chúng ta luôn luôn phảiquét toàn bộ file vì các bản ghi có age = 18 có thể xuất hiện nhiều lần trong toàn bộ file,và chúng ta không biết có bao nhiêu bản ghi thoả mãn đang tồn tại.

Tìm kiếm với phép chọn miền: Toàn bộ file phải được quét vì các bản ghi thoả mãnphải có thể xuất hiện ở bất kỳ đâu trong file này, và chúng ta không biết có bao nhiêubản ghi thoả mãn đang tồn tại. Chi phí là B(D + RC).

289/470

Thêm: Chúng ta giả sử rằng các bản ghi luôn được thêm vào cuối của file. Chúng taphải nạp trang cuối cùng trong file này vào bộ nhớ trong, thêm bản ghi, và viết trang nàytrở lại đĩa. Chi phí là 2D + C.

Xoá: Chúng ta phải tìm bản ghi cần xoá, loại bỏ bản ghi này ra khỏi trang, và viết trangđã sửa này trở về đĩa. Để đơn giản, chúng ta giả sử rằng không có một sự cố gắng nénfile nào được thực hiện để tiết kiệm không gian trống sinh ra sau khi xoá bản ghi.

Trong thực tế, một thư mục hoặc một cấu trúc dữ liệu khác được sử dụng để giữ lại dấuvết của các vùng trống, và các bản ghi được thêm vào khe trống đầu tiên có thể, nộidung này được trình bày trong Chương 9. Điều này làm cho chi phí thêm và xoá giảmđi nhưng không ảnh hưởng đến so sánh của chúng ta.Chi phí là chi phí tìm kiếm cộng với C + D.

Chúng ta giả sử rằng bản ghi bị xoá được xác định sử dụng record id. Vì chúng ta cóthể dễ dàng xác định được page id thông qua record id, nên chúng ta có thể đọc trực tiếptrang này. Vì thế, chi phí tìm kiếm là D.

Nếu bản ghi bị xoá được xác định bằng cách sử dụng điều kiện bằng hoặc điều kiện miềntrên một số trường, chi phí tìm kiếm được trình bày trong phần thảo luận về các phépchọn bằng và phép chọn miền. Chi phí của việc xoá cũng bị ảnh hưởng bởi số lượng cácbản ghi thoả mãn, vì tất cả các trang chứa những bản ghi này cũng phải được sửa đổitheo.

Sorted Files

Quét: Chi phí là B(D + RC) bởi vì tất cả các trang phải được kiểm tra. Ghi nhớ rằngtrường hợp này không tốt hay xấu hơn trường hợp các file không được sắp xếp. Tuynhiên, thứ tự các bản ghi được quét tương ứng với thứ tự được sắp, tức là, tất các cácbản ghi được quét theo thứ tự của age, và sau đó nếu age bằng nhau thì chúng quét theothứ tự của sal.

Tìm kiếm với phép chọn bằng: Chúng ta giả sử rằng phép chọn bằng này được so sánhtheo cặp hai trường là (age, sal), và lưu ý là các bản ghi được sắp xếp theo hai trườngnày. Mặt khác, chúng ta giả sử rằng điều kiện chọn được xác định trên ít nhất một trườngđầu tiên trong khoá tổ hợp (ví dụ, age = 30). Nếu không (ví dụ, điều kiện là sal = 50hoặc department = “Toy”), thứ tự được xếp này không giúp được chúng ta và chi phígiống hệt như trường hợp của heap file.

Chúng ta có thể định vị trang đầu tiên chứa bản ghi cần tìm bằng tìm kiếm nhị phântrong log2B bước. (Phân tích này giả sử rằng các trang trong file được sắp này được lưutrữ tuần tự, và chúng ta có thể truy cập trang thứ i trên file này một cách trực tiếp). Mỗibước yêu cầu một thao tác I/O đĩa và hai phép so sánh. Khi trang được biết, bản ghi thoả

290/470

mãn đầu tiên có thể được định vị lại bằng tìm kiếm nhị phân trên trang này với chi phílà Clog2R. Như vậy, tổng chi phí là Dlog2B + Clog2R, nó được cải thiện đáng kể so vớitìm kiếm trên heap file.

Nếu có một số bản ghi thoả mãn (ví dụ, “Tìm tất cả các bản ghi có age=18”), chúngđược bảo đảm là liền kề nhau do các bản ghi được sắp xếp trên trường age, và vì thế chiphí truy cập tất cả các bản ghi này bằng chi phí xác định bản ghi đầu tiên (Dlog2B +Clog2R) cộng với chi phí đọc tất cả các bản ghi thoả mãn một cách tuần tự. Lý tưởngthì tất cả các bản ghi thoả mãn được đặt vừa trong một trang đơn. Nếu không có bản ghinào thoả mãn, chi phí này được xác định bằng chi phí tìm kiếm bản ghi thoả mãn đầutiên, đó là tìm trang chứa bản ghi thoả mãn và thực hiện tìm kiếm trên trang này.

Tìm kiếm với phép chọn miền: Một lần nữa giả sử rằng phép chọn miền được so sánhtrên khoá tổ hợp này, bản ghi đầu tiên thoả mãn điều kiện chọn được xác định giống nhưtrong tìm kiếm với điều kiện bằng. Sau đó, các trang dữ liệu được truy cập một cáchtuần tự để tìm ra tất cả các bản ghi thoả mãn điều kiện; điều này tương tự như trong tìmkiếm bằng với rất nhiều bản ghi thoả mãn.

Chi phí là chi phí tìm kiếm cộng với chi phí truy cập tập các bản ghi thoả mãn điều kiệntìm kiếm. Với các phép chọn có miền nhỏ, tất cả các bản ghi thoả mãn có thể xuất hiệntrong trang này. Với các miền tìm kiếm lớn hơn, chúng ta phải nạp thêm các trang đểchứa các bản ghi thoả mãn.

Thêm: Để thêm một bản ghi nào đó mà vẫn duy trì được thứ tự sắp xếp, đầu tiên chúngta phải tìm vị trí có thể thêm được trong file này, thêm bản ghi vào và sau đó viết lại cáctrang này lên đĩa (giả sử rằng file này không có khe rỗng nên tất cả các bản ghi cũ phảidịch chuyển một slot). Để lấy trung bình, chúng ta có thể giả sử rằng các bản ghi đượcthêm sẽ ở giữa của file. Vì thế, chúng ta phải đọc nửa cuối của file này và sau đó viếtnó quay trở lại đĩa sau khi thêm bản ghi mới. Chi phí bằng chi phí của việc tìm vị trí đặtbản ghi mới cộng với 2•(0.5B(D + RC)), tức là bằng chi phí tìm kiếm cộng B(D+RC).

Xoá: Chúng ta phải tìm bản ghi cần xoá, loại bản ghi này khỏi trang và viết trang đượcsửa này quay lại đĩa. Chúng ta cũng phải đọc và ghi tất cả các trang phía sau vì tất cảbản ghi theo sau bản ghi được xoá phải được dồn lại phía trước để không bị lãng phívùng trống trên đĩa.

Không như heap file, ở đây không có cách nào có chi phí thấp để quản lý vùng trốngtrên đĩa, vì thế chúng ta phải xem xét chi phí của việc nén file khi bản ghi được xoá.Chi phí tương tự như thao tác thêm, tức là bằng chi phí tìm kiếm cộng với B(D + RC).Khi biết rid của bản ghi cần xoá, chúng ta có thể tìm được trang chứa bản ghi này mộtcách trực tiếp.

291/470

Nếu các bản ghi cần xoá được xác định bằng điều kiện bằng hoặc miền, chi phí của việcxoá này phục thuộc vào số lượng các bản ghi thoả mãn điều kiện. Nếu điều kiện nàyđược xác định trên trường được sắp, các bản ghi thoả mãn được đảm bảo là liền kề nhau,và bản ghi đầu tiên thoả mãn có thể được xác định bằng tìm kiếm nhị phân.

Clustered Files

Trong clustered file, kết quả nghiên cứu trên phạm vi rộng đã chỉ ra rằng các trangthường được sử dụng khoảng 67%. Vì thế, số lượng các trang dữ liệu vật lý khoảng1.5B, và chúng ta sử dụng quan sát này trong phân tích sau.

Quét: Chi phí của việc quét bằng khoảng 1.5B(D + RC) bởi vì tất cả các trang phải đượckiểm tra; chi phí này tương đương với trường hợp các file được sắp, cùng với nhữngđiều chỉnh hiển nhiên khi số lượng các trang dữ liệu tăng lên. Ghi nhớ rằng mô hình chiphí của chúng ta không cân nhắc đến sự khác nhau trong chi phí khi I/O tuần tự. Chúngta hy vọng là các file được sắp làm việc tốt hơn trong trường hợp này, dù cho clusteredfile sử dụng ISAM.

Tìm kiếm với phép chọn bằng: Chúng ta giả sử rằng phép chọn bằng được so sánh trênkhoá tìm kiếm (age, sal). Chúng ta có thể xác định được trang đầu tiên chứa bản ghi cầntìm trong logf1.5B bước, tức là bằng với việc tìm ra tất cả các trang từ gốc đến lá phùhợp. Trong thực tế, trang gốc dường như luôn ở buffer pool và chúng ta tiết kiệm đượcmột I/O, nhưng chúng ta bỏ quan điều này trong khi phân tích. Mỗi bước yêu cầu mộtI/O đĩa và hai phép so sánh. Đối với mỗi trang, bản ghi thoả mãn đầu tiên có thể đượcđịnh vị lại bằng một tìm kiếm nhị phân trên trang này với chi phí bằng Clog2R. Tổngchi phí là DlogF1.5B + Clog2R, nó được cải thiện đáng kể so với tìm kiếm thậm chí trêncác sorted files.

Nếu có một số bản ghi thoả mãn (ví dụ, “Tìm tất cả các bản ghi có age=18”), chúngđược bảo đảm là liền kề nhau do các bản ghi được sắp xếp trên trường age, và vì thế chiphí truy cập tất cả các bản ghi này bằng chi phí xác định bản ghi đầu tiên (Dlog2B +Clog2R) cộng với chi phí đọc tất cả các bản ghi thoả mãn một cách tuần tự.

Tìm kiếm với phép chọn miền: Một lần nữa giả sử rằng phép chọn miền được so sánhvới trên khoá tổ hợp này, bản ghi đầu tiên thoả mãn điều kiện chọn được xác định giốngnhư trong tìm kiếm với điều kiện bằng. Sau đó, các trang dữ liệu được truy cập một cáchtuần tự (sử dụng các liên kết phía trước và phía sau ở mức lá) để tìm ra tất cả các bảnghi thoả mãn điều kiện; điều này tương tự như trong tìm kiếm bằng với rất nhiều bảnghi thoả mãn.

Thêm: Để thêm một bản ghi nào đó, đầu tiên chúng ta phải tìm trang lá để thêm bản ghinày trong chỉ mục, đọc tất cả các trang từ gốc đến lá. Sau đó chúng ta phải thêm bản ghimới. Hầu hết thời gian, trang lá có những vùng trống đủ để thêm bản ghi mới, và tất cả

292/470

chúng ta cần phải làm là viết ra ngoài những trang lá sau khi sửa. Đôi khi, trang lá đầyvà chúng ta cần truy cập và sửa những trang khác, nhưng điều này là hiếm khi xảy ra vàchúng ta có thể bỏ qua nó. Vì thế, tổng chi phí bằng chi phí tìm kiếm cộng với một thaotác viết DlogF1.5B + Clog2R + D.

Xoá: Chúng ta phải tìm bản ghi cần xoá, loại bỏ nó khỏi trang, và viết trang được sửanày ra đĩa. Những trình bày và phân tích chi phí cho trường hợp thêm được áp dụng tốtở đây.

Heap File với Unclustered Tree Index

Số lượng các trang lá trong một chỉ mục phụ thuộc vào kích thước của cổng vào dữliệu. Chúng ta giả sử rằng mỗi cổng vào dữ liệu trong chỉ mục này có kích thước bằngmột phần mười kích thước một bản ghi dữ liệu nhân viên. Số lượng các trang lá trongchỉ mục này là 0.1(1.5B) = 0.15B nếu chúng ta biết các trang chỉ mục thường sử dụngkhoảng 67% khả năng lưu trữ của nó. Tương tự, số lượng các cổng vào dữ liệu trên mộttrang là 10(0.67R) = 6.7R.

Quét: Xem Hình 1 minh hoạ về một chỉ mục không phân cụm. Để quét toàn bộ file chứacác bản ghi nhân viên, chúng ta có thể quét mức lá của chỉ mục này và với mỗi cổng vàodữ liệu quét bản ghi dữ liệu tương ứng nằm trong file để thu được các bản ghi dữ liệuđược sắp theo (age, sal).

Chúng ta có thể đọc tất cả các cổng vào dữ liệu với chi phí 0.15B(D+6.7RC) I/Os. Bâygiờ chúng ta đi đến một phần quan trọng: Chúng ta phải tìm các bản ghi dữ liệu với mỗicổng vào dữ liệu trong chỉ mục này. Chi phí của việc tìm các bản ghi nhân viên là mộtI/O ứng với mỗi bản ghi, vì chỉ mục này không phân cụm và mỗi cổng vào dữ liệu trênmột trang lá của chỉ mục này có thể trỏ đến một trang khác trong file nhân viên. Chi phícủa bước này là BR(D+C). Nếu chúng ta muốn các bản ghi nhân viên được sắp theo thứtự, sẽ là tốt hơn nếu chúng ta bỏ qua chỉ mục này và quét file nhân viên một cách trựctiếp và sau đó sắp xếp nó. Một quy tắc đơn giản là file có thể được sắp bằng thuật toánhai-đường trong đó mỗi đường yêu cầu đọc và ghi toàn bộ file. Vì thế, chi phí I/O củaviệc sắp xếp file có B trang là AB, chi phí này ít hơn nhiều so với chi phí sử dụng chỉmục không phân cụm.

Tìm kiếm với phép chọn bằng: Chúng ta giả sử rằng phép chọn bằng được so sánh trênkhoá tìm kiếm (age, sal). Chúng ta có thể xác định được trang đầu tiên chứa cổng vàodữ liệu cần tìm trong logf0.15B bước, tức là bằng với việc tìm ra tất cả các trang từ gốcđến lá phù hợp. Mỗi bước yêu cầu một I/O đĩa và hai phép so sánh. Đối với mỗi trang,cổng vào dữ liệu thoả mãn đầu tiên có thể được định vị lại bằng một tìm kiếm nhị phântrên trang này với chi phí bằng Clog26.7R. Bản ghi dữ liệu thoả mãn đầu tiên có thểđược tìm trong file nhân viên bằng một thao tác I/O khác. Tổng chi phí là DlogF0.15B+ Clog26.7R + D, nó được cải thiện đáng kể so với tìm kiếm trên các sorted files.

293/470

Nếu có một số bản ghi thoả mãn (ví dụ, “Tìm tất cả các bản ghi có age=18”), chúngkhông được bảo đảm là liền kề nhau. Chi phí truy cập tất cả các bản ghi này là chi phíđịnh vị cổng vào dữ liệu thoả mãn đầu tiên DlogF0.15B + Clog26.7R cộng với một thaotác I/O ứng bvới một bản ghi thoả mãn. Vì thế chi phí sử dụng một chỉ mục không phâncụm phụ thuộc nhiều vào số lượng các bản ghi thoả mãn.

Tìm kiếm với phép chọn miền: Một lần nữa giả sử rằng phép chọn miền được so sánhvới trên khoá tổ hợp này, bản ghi đầu tiên thoả mãn điều kiện chọn được xác định giốngnhư trong tìm kiếm với điều kiện bằng. Sau đó, các cổng vào dữ liệu được truy cập mộtcách tuần tự (sử dụng các liên kết phía trước và phía sau ở mức lá của chỉ mục này) đểtìm ra tất cả các bản ghi thoả mãn điều kiện. Với mỗi cổng vào dữ liệu thoả mãn, chúngta phải mất thêm một thao tác I/O để truy cập các bản ghi nhân viên tương ứng. Chi phícó thể trở nên quá lớn một cách nhanh chóng khi số lượng các bản ghi thỏa mãn điềukiện chọn miền tăng lên. Như một quy tắc ngón tay cái, nếu 10% bản ghi dữ liệu thoảmãn điều kiện chọn, sẽ tốt hơn nếu chúng ta truy cập tất cả các bản ghi nhân viên, sắpxếp chúng và sau đó giữ lại những bản ghi thoả mãn điều kiện chọn.

Thêm: Đầu tiên chúng ta phải thêm bản ghi này vào heap file nhân viên, chi phí là2D+C. Thêm nữa, chúng ta phải thêm cổng vào dữ liệu tương ứng trong chỉ mục này.Việc tìm một trang lá chính xác có cho phí DlogF0.5B + Clog26.7R, và viết nó ra ngoàisau khi thêm cổng vào dữ liệu mới mất chi phí là D.

Xoá: Chúng ta cần định vị bản ghi dữ liệu cần xoá trong file nhân viên và cổng vào dữliệu trong file chỉ mục, và bước tìm kiếm này có chi phí Dlogf0.15B+ Clog26.7R + D.Sau đó chúng ta cần viết ra ngoài những trang đã bị thay đổi trong file chỉ mục và filedữ liệu, chi phí là 2D.

Heap File với Unclustered Hash Index

Giống như đối với unclustered tree indexes, chúng ta giả sử rằng mỗi cổng vào dữ liệucó kích thước bằng một phần mười kích thước một bản ghi dữ liệu. Chúng ta chỉ đề cậpđến băm tĩnh trong phân tích của chúng ta, và để đơn giản chúng ta giả sử rằng khôngcó các chuỗi tràn.

Sự thay đổi trong cách băm ít ảnh hưởng đến vấn đề chuỗi tràn, và có chi phí trungbình cao hơn rất ít đối với mỗi thao tác tìm kiếm.

Trong một file được băm tĩnh, các trang thường sử dụng khoảng 80% khả năng lưu trữcủa nó (để có vùng trống phục vụ thao tác thêm và tối thiểu hoá khả năng overflows khifile được mở rộng). Đạt được điều này bằng cách thêm một trang mới vào bucket khicác bản ghi được nạp vào hashed file nếu mỗi trang đang tồn tại đều đã sử dụng 80%khả năng của nó. Vì thế số lượng các trang cần để lưu các cổng vào dữ liệu sẽ bằng1.25 lần số lượng các trang trong trường hợp các cổng vào dữ liệu đã đầy, tức là bằng

294/470

1.25(0.105) = 0.125B. Số lượng các cổng vào dữ liệu đặt vừa khít trong một trang là10(0.80R) = 8R.

Quét: Như đối với unclustered tree index, tất cả các cổng vào dữ liệu có thể được truycập với chi phí thấp, ở mức 0.125B(D + 8RC) I/Os. Tuy nhiên, với mỗi cổng vào dữliệu, chúng ta phải chịu thêm một thao tác I/O để truy cập bản ghi dữ liệu tương ứng,chi phí của bước này là R(D + C). Chi phí này là quá lớn và thêm nữa, kết quả lại khôngđược sắp xếp. Vì thế không có các thao tác quét trên chỉ mục băm.

Tìm kiếm với phép chọn bằng: Thao tác này được hỗ trợ rất hiệu quả bởi các phépchọn so sánh, tức là các điều kiện bằng được xác định với mỗi trường trong khoá tìmkiếm tổ hợp (age, sal). Chi phí của việc xác định một trang chứa các cổng vào dữ liệuthoả mãn là H. Giả sử rằng bucket này gồm chỉ một trang (tức là, không có các trangtràn), việc truy cập nó mất chi phí là D. Nếu chúng ta giả sử rằng chúng ta tìm các cổngvào dữ liệu sau khi quét một nửa số bản ghi trên trang này, chi phí của việc quét trangnày là 0.5(8R)C = 4RC. Cuối cùng, chúng ta phải truy cập các cổng vào dữ liệu từ filenhân viên, chi phí là D. Vì thế, tổng chi phí là H + 2D + 4RC, chi phí này thậm chí cònthấp hơn chi phí đối với tree index.

Nếu một vài bản ghi thoả mãn, chúng không được đảm bảo là được đặt liền kề nhau. Chiphí truy cập tất cả các bản ghi như vậy bằng chi phí của việc xác định cổng vào dữ liệuđầu tiên thoả mãn (H + D + 4RC) cộng với một I /O ứng với một bản ghi thoả mãn. Vìthế, chi phí sử dụng chỉ mục không phân cụm phụ thuộc rất nhiều vào số lượng các bảnghi thoả mãn.

Tìm kiếm với phép chọn miền: Toàn bộ heap file chứa các bản ghi nhân viên phảiđược quét với chi phí là B(D + RC).

Thêm: Đầu tiên chúng ta phải thêm bản ghi này vào heap file, chi phí là 2D + C. Thêmnữa, trang tương ứng trong chỉ mục này phải được xác định, thay đổi để thêm một cổngvào dữ liệu mới, và sau đó viết nó trở lại đĩa. Chi phí là H + 2D + C.

Xoá: Chúng ta cần định vị bản ghi dữ liệu cần xoá trong file nhân viên và cổng vào dữliệu trong file chỉ mục; bước tìm kiếm này có chi phí là H + 2D + 4RC. Bây giờ, chúngta cần viết ra ngoài những trang được thay đổi trong chỉ mục và file dữ liệu, chi phí là2D.

So sánh chi phí I/O

Hình 4 so sánh chi phí I/O với các cấu trúc file khác nhau chúng ta đã trình bày ở trên.Heap file có cách lưu trữ hiệu quả và hỗ trợ thao tác quét và thêm các bản ghi một cáchnhanh chóng. Tuy nhiên, nó lại chậm trong các thao tác tìm kiếm và xoá.

295/470

Sort file cũng có cách lưu trữ hiệu quả, nhưng lại chậm trong các thao tác thêm và xoábản ghi. Việc tìm kiếm thực hiện nhanh hơn trong heap files. Bạn nên ghi nhớ rằng trongmột DBMS thực, một file dường như không bao giờ được sắp xếp hoàn toàn.

So sánh chi phí I/O

Clustered file có tất cả các ưu điểm của sorted file và nó hỗ trợ việc thêm và xoá mộtcách hiệu quả. Tìm kiếm thậm chí còn nhanh hơn cả sorted files, mặc dù sorted file cóthể nhanh hơn khi có một số lượng lớn các bản ghi dữ liệu được truy cập một cách tuầntự, vì I/O theo khối được thực hiện hiệu quả.

Unclustered tree và hash indexes thực hiện tìm kiếm, thêm và xoá nhanh hơn nhưngquét và tìm kiếm miền lại chậm. Hash indexes thực hiện nhanh hơn một chút trên cáctìm kiếm bằng, nhưng chúng không hỗ trợ tìm kiếm miền.

Tóm lại, Hình 4 chỉ ra rằng không có tổ chức file nào hiệu quả hơn hẳn trong tất cả cáctrường hợp.

Chỉ mục và điều chỉnh hiệu xuất

Trong phần này, chúng ta trình bày tổng quan về những lựa chọn khi sử dụng các chỉmục để cải thiện thực thi trong một hệ thống cơ sở dữ liệu. Việc lựa chọn chỉ mục có ảnhhưởng rất lớn đến quá trình thực thi hệ thống, và phải được thực hiện trong ngữ cảnhmột lưu lượng công việc nào đó, hoặc các thao tác truy vấn và cập nhật.

Khi nghiên cứu về các chỉ mục và thực thi yêu cầu chúng ta phải hiểu về cách đánhgiá truy vấn và điều khiển tương tranh. Vì thế chúng ta quay trở lại chủ đề này trongChương 20, chương này chúng ta sẽ bàn luận về phần này. Cụ thể, chúng ta sẽ nghiêncứu các ví dụ bao gồm nhiều bảng trong Chương 20 vì nó yêu cầu có những hiểu biếtnhất dịnh về các thuật toán kết nối và các kế hoạch đánh giá truy vấn.

296/470

Tác động của Lưu lượng công việc

Điều đầu tiên được xem xét là lưu lượng công việc nào cần thực thi và những thao tácphổ biến. Các tổ chức file và các chỉ mục khác nhau tạo ra sự khác nhau trong thực thicác phép toán, phần này chúng ta đã nghiên cứu ở trên.

Nói chung, chỉ mục giúp truy cập các cổng vào dữ liệu thoả mãn điều kiện chọn nào đómột cách hiệu quả. Nhớ lại trong phần trước chúng ta có hai kiểu phép chọn quan trọng:phép chọn bằng và phép chọn miền. Công nghệ chỉ mục hoá dựa trên băm được tối ưuchỉ cho những phép chọn bằng và thực sự không tốt trong các phép chọn miền, nó cònkhông tốt bằng cách quét toàn bộ các bản ghi. Công nghệ chỉ mục hoá dựa trên cây hỗtrợ cả hai loại phép chọn này một cách hiệu quả đã giải thích vì sao chúng được sử dụngrộng rãi. Cả chỉ mục cây và băm đều hỗ trợ các phép thêm, xoá và sửa thực sự hiệu quả.Đặc biệt, chỉ mục dựa trên cây yêu cầu file chứa các bản ghi đã được sắp xếp. Nhữngbàn luận của chúng ta về các chỉ mục có cấu trúc cây (B+tree) trong Phần 3.2 nhấn mạnhhai ưu điểm quan trọng của các files được sắp:

1. Chúng ta có thể quản lý việc thêm và xoá các cổng vào dữ liệu một cách hiệuquả.

2. Việc tìm ra trang lá chứa một bản ghi cần tìm theo giá trị khoá tìm kiếm nhanhhơn nhiều so với tìm kiếm nhị phân trên các trang trong một file được sắp.

Một nhược điểm là các trang trong file được sắp có thể được đặt trên đĩa theo thứ tự vậtlý, làm nó nhanh hơn nhiều so với truy cập một vài trang theo thứ tự tuần tự. Tất nhiên,việc thêm và xoá trên một file được sắp phải trả một chi phí rất lớn. Một biến thể củaB+trees được gọi là Indexed Sequential Access Method (ISAM) đưa ra những lợi íchcủa việc định vị các trang lá một cách tuần tự. Các thao tác thêm và xoá không đượcquản lý tốt trong các B-|- trees, nhưng lại tốt hơn trong một file được sắp xếp. Chúng tasẽ nghiên cứu về các chỉ mục cấu trúc cây chi tiết trong Chương 10.

Tổ chức Chỉ mục phân cụm

Như chúng ta đã nhìn thấy trong Phần 2.1, một chỉ mục phân cụm là một tổ chức filechứa các bản ghi dữ liệu bên dưới. Các bản ghi dữ liệu có thể lớn, và chúng ta nêntránh tái tạo chúng; vì thế chỉ có nhiều nhất một chỉ mục phân cụm ứng với một tậpcác bản ghi. Mặt khác, chúng ta có thể xây dựng một vài chỉ mục không phân cụm trênmột file dữ liệu. Giả sử rằng các bản ghi nhân viên được sắp xếp theo age, hoặc sắpxếp trong clustered file với khoá tìm kiếm là age. Thêm nữa, nếu chúng ta có một chỉmục trên trường sal. Chúng ta cũng có thể xây dựng một chỉ mục không phân cụm trêndepartment, nếu ở đó có một trường như vậy.

Duy trì một Chỉ mục phân cụm đắt hơn so với duy trì một file được sắp xếp hoàn toán.Khi một bản ghi mới được thêm vào một trang lá đã đầy, trang lá mới phải được định vị

297/470

và một vài bản ghi đang tồn tại phải được chuyển đến trang mới này. Nếu các bản ghiđược xác định bằng page id kết hợp với slot(khe) như trong các hệ cơ sở dữ liệu hiện tại,thì tất cả các vùng trong cơ sở dữ liệu trỏ tới bản ghi được di chuyển này phải được cậpnhật lại để nó trỏ tới vùng mới. Việc định vị tất cả các vùng như vậy và thực hiện nhữngcập nhật này có thể cần một vài thao tác I/O đĩa. Việc phân cụm (Clustering) phải đượcsử dụng rất thận trọng, chỉ cần khi những truy vấn có tần suất sử dụng thường xuyênđược hưởng lợi nhiều từ việc phân cụm này. Đặc biệt, không có lý do xác đáng nào đểxây dựng một clustered file sử dụng băm vì các truy vấn miền không thể được trả lờibằng cách sử dụng các chỉ mục băm.

Để đối mặt với giới hạn là chỉ có duy nhất một chỉ mục có thể được phân cụm, chúng tanên xem xét xem khoá tìm kiếm của chỉ mục có thể trả lời truy vấn hiệu quả không. Nếunhư vậy, các hệ thống cơ sở dữ liệu hiện đại đủ thông minh để tránh việc truy cập cácbản ghi dữ liệu thực sự. Ví dụ, nếu chúng ta có một chỉ mục trên age, và chúng ta muốntính tuổi tung bình của các nhân viên, DBMS có thể làm điều này bằng một kiểm tra đơngiản trên toàn bộ chỉ mục này. Đây là một ví dụ của đánh giá chỉ-chỉ-số. Trong đánhgiá chỉ-chỉ-số của một truy vấn nào đó, chúng ta không cần quét toàn bộ các bản ghi dữliệu trong các file chứa các quan hệ liên quan trong truy vấn này; chúng ta có thể đánhgiá truy vấn này hoàn toàn dựa vào các chỉ mục trên các files. Một lợi ích quan trọngcủa đánh giá chỉ-chỉ-số là nó làm việc hiệu quả với các chỉ mục không phân cụm, và chỉnhững cổng vào dữ liệu của chỉ mục này được sử dụng trong các truy vấn. Vì thế, chỉmục không phân cụm có thể được sử dụng để tăng tốc các truy vấn hiện tại nếu chúngta nhận ra rằng DBMS này sẽ khai thác đánh giá chỉ-chỉ-số.

Thiết kế các ví dụ minh hoạ Chỉ mục phân cụm

Để minh hoạ việc sử dụng chỉ mục phân cụm trên một truy vấn miền, xem xét một ví dụsau:

SELECT E.dno FROM Employees E WHERE E.age > 40

Nếu chúng ta có một chỉ mục B+tree trên age, chúng ta có thể sử dụng nó để truy cậpchỉ những bộ giá trị thoả mãn điều kiện chọn E.age> 40. Tỷ lệ nhân viên có tuổi lớnhơn 40 là bao nhiêu? Nếu gần như tất cả mọi người đều có tuổi lớn hơn 40, chúng ta sẽhưởng lợi từ việc sử dụng một chỉ mục trên age; việc quét tuần tự của quan hệ này cũngsẽ có hiệu quả tương tự. Tuy nhiên, giả sử rằng chỉ có 10% nhân viên có tuổi lớn hơn40, thì sử dụng chỉ mục nào sẽ hữu ích? Câu trả lời phụ thuộc vào việc có hay khôngmột chỉ mục được phân cụm. Nếu chỉ mục này không phân cụm, chúng ta có thể có mộttrang I/O với mỗi nhân viên, và thực hiện như vậy sẽ phải trả chi phí cao hơn việc thựchiện quét tuần tự, thậm chí chỉ 10% nhân viên thoả mãn yêu cầu! Mặt khác, một chỉ mụcB+tree phân cụm trên age yêu cầu chỉ 10% của I/Os đối với quét tuần tự (bỏ qua mộtvài I/Os cần để duyệt từ gốc đến trang lá được truy cập đầu tiên và I/Os cho các lá củachỉ mục liên quan).

298/470

Ví dụ khác, xem xét sự tinh chỉnh sau của truy vấn phía trên:

SELECT E.dno, COUNT(*) FROM Employees E WHERE E.age > 10GROUP BY E.dno

Nếu B+tree index đang sẵn sàng trên trường age, chúng ta có thể truy cập các bộ giá trịsử dụng nó, sắp xếp các bộ giá trị được truy cập trên dno, và vì thế trả lời được truy vấnnày. Tuy nhiê, đây có lẽ không phải là kế hoạch tốt nếu hầu như tất cả các nhân viên cótuổi lớn hơn 10. Kế hoạch này đặc biệt không hiệu quả nếu chỉ mục này không phải làchỉ mục phân cụm.

Hãy cùng chúng tôi xem xét xem liệu chỉ mục trên dno có thể phù hợp với mục đích củachúng ta hơn không. Chúng tôi có thể sử dụng chỉ mục này để truy cập tất cả các bộ giátrị, nhóm theo dno, và đếm số lượng các bộ giá trị có age>10 với mỗi dno. (Chiến lượcnày có thể được sử dụng với cả các chỉ mục băm và B+tree; chúng ta chỉ yêu cầu cácbộ giá trị được nhóm, không cần thiết được sắp xếp theo dno.) Thêm nữa, hiệu quả phụthuộc chủ yếu vào việc có hay không một chỉ mục được phân cụm. Nếu là có, kế hoạchnày dường như là kế hoạch tốt nhất nếu điều kiện trên age không qua khắt khe. (Dù làchúng ta có một chỉ mục không phân cụm trên age, nếu điều kiện trên age không quákhắt khe, chi phí của việc sắp xếp các bộ giá trị trên dno sẽ khá cao.) Nếu chỉ mục nàykhông được phân cụm, chúng ta có thể thực hiện một trang I/O trên mỗi bộ giá trị trongEmployees, và kế hoạch này sẽ phải trả một giá đắt ‘khủng khiếp’. Thực vậy, nếu chỉmục này không được phân cụm, bộ tối ưu hoá sẽ lựa chọn kế hoạch dựa trên việc sắpxếp trên dno. Vì thế, truy vấn này đề nghi rằng chúng ta xây dựng một chỉ mục phâncụm trên dno nếu điều kiện trên age không quá khắt khe. Nếu điều này quá khắt khe,chúng ta sẽ xem xét việc xây dựng một chỉ mục (không cần thiết phải phân cụm) trênage thay vào đó.

Việc phân cụm cũng quan trọng cho một chỉ mục được xây dựng dựa trên khoá tìm kiếmmà khoá tìm kiếm này không chứa khoá dự tuyển, tức là, một chỉ mục trong đó có mộtmột vài cổng vào dữ liệu có thể có cùng một giá trị khoá. Để minh hoạ điểm này, chúngtôi trình bày về truy vấn sau:

SELECT E.dno FROM Employees E WHERE E.hobby='Stamps'

Nếu rất nhiều người sưu tập tem (stamps), việc truy cập các bộ giá trị thông qua một chỉmục không phân cụm trên hobby có thể rất không hiệu quả. Nó có lẽ rẻ hơn nếu chỉ quétquan hệ này để truy cập tất cả các bộ giá trị và áp đặt việc chọn on-the-fly tới các bộ giátrị được truy cập.

Vì thế, nếu một truy vấn nào đó quá quan trọng, chúng ta nên xem xét việc xây dựngmột chỉ mục trên trường hobby là chỉ mục phân cụm. Mặt khác, nếu chúng ta giả sử rằngeid là khoá của Employees, và thay thế điều kiện E.hobby ='Stamps' bằng E.eid=552,

299/470

chúng ta biết rằng có nhiều nhất một bộ giá trị của Employees sẽ thoả mãn điều kiệnchọn này. Trong trường hợp này, sẽ không có ích lợi nào của việc xây dựng một chỉ mụcphân cụm.

Truy vấn tiếp theo chỉ ra các hàm nhóm ảnh hưởng như thế nào đến việc lựa chọn cácchỉ mục:

SELECT E.dno, C0UNT(*) FROM Employees E GROUP BY E.dno

Một kế hoạch rõ ràng cho truy vấn này là sắp xếp Employees trên dno để tính toán sốlượng các nhân viên ứng với mỗi dno. Tuy nhiên, nếu một chỉ mục nào đó- băm hoặcB+tree trên dno đang sẵn sàng, chúng ta có thể thực hiện truy vấn này chỉ bằng cáchquét trên chỉ mục. Với mỗi giá trị dno, chúng ta chỉ đơn giản là đếm số lượng các cổngvào dữ liệu trong chỉ mục này. Ghi nhớ rằng sẽ không có vấn đề gì về việc chỉ mụcnày được phân cụm hay không vì chúng ta không bao giờ truy cập những bộ giá trị củaEmployees.

Khoá tìm kiếm tổ hợp

Khoá tìm kiếm của một chỉ mục có thể chứa một vài trường; những khoá như vậy đượcgọi là khoá tìm kiếm tổ hợp hoặc các khoá móc nối. Ví dụ, xem xét tập hợp các bản ghinhân viên, với các trường name, age, và sal, được lưu trữ theo thứ tự sắp xếp của name.Hình 5 minh hoạ sự khác nhau giữa chỉ mục tổ hợp có khoá là (age, sat), chỉ mục tổ hợpcó khoá là (sal, age), một chỉ mục có khoá là age, và một chỉ mục có khoá là sal. Tất cảcác chỉ mục được minh hoạ trong hình này đều sử dụng Alternative(2) cho các cổng vàodữ liệu.

Nếu một khóa tìm kiếm là tổ hợp, một truy vấn bằng là một truy vấn mà mỗi trườngtrong đó được gán bằng một hằng số cụ thể. Ví dụ, chúng ta có thể yêu cầu để truy cậptất các cổng vào dữ liệu với age = 20 và sal = 10. Tổ chức file băm hỗ trợ chỉ nhữngtruy vấn bằng, vì sử dụng một hàm băm sẽ xác định được bucket chứa các bản ghi cầntìm chỉ khi có một giá trị được xác định ứng với mỗi trường trong khoá tìm kiếm.

Đối với một chỉ mục khoá tổ hợp, trong truy vấn miền không phải tất cả các trường trongkhoá tìm kiếm này được gán với giá trị hằng số. Ví dụ, chúng ta có thể yêu cầu truy cậptất cả các cổng vào dữ liệu có age=20; truy vấn này ngụ ý trường sal có thể nhận giá trịbất kỳ. Ví dụ khác của truy vấn miền, chúng ta có thể yêu cầu truy cập các bộ giá trịthoả mãn điều kiện age < 30 và sal > 40.

300/470

Các chỉ mục khoá tổ hợp

Ghi nhớ rằng chỉ mục này không thể giúp đỡ truy vấn sal > 40, vì như quan sát, chỉ mụcnày tổ chức các bản ghi theo trường age đầu tiên, sau đó đến trường sal. Nếu age khôngđược xác định ở bên trái, các bản ghi thoả mãn có thể nằm trải rộng trên toàn bộ chỉmục. Chúng ta nói rằng một chỉ mục nào đó phù hợp với một điều kiện chọn nào đó nếuchỉ mục này có thể được sử dụng để truy cập chỉ những bộ giá trị thoả mãn điều kiệnnày. Với các điều kiện chọn có dạng condition ∧…∧ condition, chúng ta có thể địnhnghĩa khi nào một chỉ mục phù hợp với điều kiện chọn như sau:

Những thảo luận thêm được trình bày trong phần 14.2Với một chỉ mục băm, một điều kiện chọn phù hợp với một chỉ mục nếu nó chứa mộtđiều kiện bằng (‘trường = hằng số’) trên tất cả các trường trong khoá tìm kiếm tổ hợpcủa chỉ mục này. Với chỉ mục cây, điều kiện chọn phù hợp với chỉ mục nếu nó chứamột điều kiện bằng hoặc điều kiện miền trên tiền tố của khoá tìm kiếm tổ hợp này. (Vídụ, (age) và (age, sal, department) là tiền tố của khoá (age, sal, department), nhưng(age, department) và (sal, department) thì không.

Sự cân bằng trong việc lựa chọn khoá tổ hợp

Một chỉ mục khoá tổ hợp có thể hỗ trợ một miền rộng lớn của các truy vấn vì nó phùhợp với nhiều điều kiện chọn. Thêm nữa, vì các cổng vào dữ liệu trong một chỉ mục tổhợp chứa nhiều thông tin về bản ghi dữ liệu (tức là, nhiều trường hơn so với chỉ mụcmột-thuộc-tính), có nhiều cơ hội hơn cho các chiến lược đánh giá chỉ chỉ mục. (Nhớ lạitrong phần 5.2 rằng một đánh giá chỉ chỉ mục không cần truy cập tới các bản ghi dữ liệu,nhưng cần tìm tất cả các giá trị của trường được yêu cầu trong cổng vào dữ liệu của cácchỉ mục.)

301/470

Mặt tiêu cực là, một chỉ mục tổ hợp phải được cập nhật khi có bất kỳ thao tác (thêm,sửa, xoá) nào thực hiện trên bất kỳ trường nào trong khoá tìm kiếm này. Một chỉ mục tổhợp dường như cũng lớn hơn một khoá tìm kiếm một-thuộc-tính vì kích thước của cáccổng vào dữ liệu lớn hơn. Với một chỉ mục B+tree tổ hợp, điều này cũng có nghĩa làtiềm năng tăng lên theo số lượng các mức, mặc dù khả năng nén khoá có thể được sửdụng để giảm nhẹ vấn đề này (xem Phần 10.8.1)

Các ví dụ của khoá tổ hợp

Xem xét truy vấn sau đây, truy vấn này trả về tất cả các nhân viên có 20 < age < 30 và3000 < sal < 5000:

SELECT E.eid FROM Employees E WHERE E.age BETWEEN 20 AND30 AND E.sal BETWEEN 3000 AND 5000

Chỉ mục tổ hợp trên (age, sal) có thể giúp đỡ thực thi truy vấn này nếu các điều kiệntrong mệnh đề WHERE là các phép chọn rõ ràng. Hiển nhiên, một chỉ mục băm sẽkhông giúp đỡ thực thi truy vấn này; một chỉ mục B+ tree (hoặc ISAM) được yêu cầu.Rõ ràng rằng một chỉ mục phân cụm dường như hiệu quả hơn một chỉ mục không phâncụm. Với truy vấn này, các điều kiện trên age và sal là các phép chọn bằng, một chỉ mụcB+tree trên (age, sal) sẽ hiệu quả như sử dụng chỉ mục phân cụm B+tree trên (sal, age).Tuy nhiên, thứ thự của các thuộc tính trong khoá tìm kiếm có thể gây ra vấn đề lớn, nhưminh hoạ trong truy vấn tiếp theo:

SELECT E.eid FROM Employees E WHERE E.age = 25 AND E.salBETWEEN 3000 AND 5000

Trong ví dụ của truy vấn này, chỉ mục phân cụm B+tree trên (age, sal) sẽ mang đến mộtthực thi tốt vì các bản ghi được sắp xếp theo age đầu tiên (nếu hai bản ghi có cùng giátrị age) sau đó mới đến sal. Vì thế, tất cả các bản ghi có age=25 sẽ được phân cụm cùngnhau. Mặt khác, chỉ mục phân cụm B+tree trên (sal, age) sẽ không thực thi tốt bằng.Trong trường hợp này, các bản ghi đầu tiên được sắp xếp theo sal, và vì thế hai bản ghicó cùng giá trị age (cụ thể, age=25) có thể thực sự ở cách xa nhau. Thực tế mà nó, chỉmục này cho phép chúng ta sử dụng các truy vấn miền trên sal, nhưng không phải là cáctruy vấn bằng trên age để truy cập các bộ giá trị. (Thực thi tốt trên cả hai biến thể củatruy vấn này có thể đạt được bằng cách sử dụng một chỉ mục không gian đơn. Chúng tasẽ bàn về các loại chỉ mục này trong Chương 28)

Các chỉ mục tổ hợp sẽ hữu ích trong việc đối mặt với rất nhiều các truy vấn có hàmnhóm. Xem xét:

SELECT AVG (E.sal) FROM Employees E WHERE E.age = 25 ANDE.sal BETWEEN 3000 AND 5000

302/470

Một chỉ mục tổ hợp B+tree trên (age, sal) cho phép chúng trả lời truy vấn này bằng việcquét chỉ-chỉ-số. Một chỉ mục tổ hợp B+tree trên (sal, age) cũng cho phép chúng ta trả lờitruy vấn này bằng việc quét chỉ-chỉ-số, mặc dù trong trường hợp này có nhiều các cổngvào dữ liệu chỉ mục được truy cập hơn là trong trường hợp sử dụng chỉ mục trên (age,sal).

Đây là một biến thể của ví dụ phía trên:

SELECT E.dno, COUNT(*) FROM Employees E WHERE E.sal=10,000 GROUP BY E.dno

Một chỉ mục nào đó trên chỉ dno không cho phép chúng ta định giá truy vấn này cùngvới việc quét chỉ-chỉ-số, vì chúng ta cần tìm trường sal của mỗi bộ giá trị để xác địnhđiều kiện sal = 10,000. Tuy nhiên, chúng ta có thể sử dụng kế hoạch chỉ-chỉ-số nếuchúng ta có một chỉ mục tổ hợp B+tree trên (sal, dno) hoặc (dno, sal). Trong một chỉmục với khoá là (sal, dno), tất cả các cổng vào dữ liệu có sal = 10,000 được đặt sát nhau.(dù chỉ mục này được phân cụm hay không). Thêm nữa, các cổng vào dữ liệu được sắpxếp theo dno, nên nó dễ dàng để đếm được số lượng các bản ghi trong mỗi nhóm dno.Ghi nhớ rằng chúng ta cần truy cập chỉ những cổng vào dữ liệu có sal = 10,000.

Một quan sát đáng giá là chiến lược này không làm việc nếu mệnh đề WHERE đượcthay đổi để sử dụng sal > 10,000. Mặc dù nó thoả mãn để truy cập chỉ những cổng vàodữ liệu chỉ mục- tức là, một chiến lược chỉ-chỉ-số vẫn được áp dụng- các cổng vào dữliệu này bây giờ phải được sắp xếp theo dno để định danh các nhóm (vì hai cổng vàodữ liệu có cùng một dno nhưng khác nhau giá trị của sal vẫn không được đặt gần nhau.)Một chỉ mục cùng với khoá (dno, sal) sẽ tốt hơn cho truy vấn này: Các cổng vào dữ liệucùng với một giá trị dno cung cấp được sắp xếp cùng nhau, và mỗi nhóm các cổng vàodữ liệu như vậy tự bản thân nó được sắp xếp theo sal. Với mỗi nhóm dno, chúng ta cóthể loại bỏ các cổng vào dữ liệu cùng với sal không lớn hơn 10,000 và đếm phần cònlại. (Sử dụng chỉ mục này ít hiệu quả hơn là quét chỉ-chỉ-số với khoá (sal, dno) cho truyvấn với sal = 10,000, vì chúng ta phải đọc tất cả các cổng vào dữ liệu.)

Ví dụ, giả sử chúng ta muốn tìm lương nhỏ nhất ứng với mỗi dno.

SELECT E.dno, MIN(E.sal) FROM Employees E GROUP BY E.dno

Một chỉ mục nào đó chỉ trên dno không cho phép chúng ta đánh giá truy vấn này bằngcách thực hiện quét chỉ-chỉ-số. Tuy nhiên, chúng ta có thể sử dụng kế hoạch chỉ-chỉ-sốnếu chúng ta có một chỉ mục tổ hợp B+tree trên (dno, sal). Ghi nhớ rằng tất cả các cổngvào dữ liệu trong chỉ mục này cùng với một giá trị dno cung cấp được lưu trữ cùng nhau(dù chỉ mục này có được phân cụm hay không). Thêm nữa, nhóm của các cổng vào dữliệu này tự bản thân nó được sắp xếp theo sal. Một chỉ mục trên (sal, dno) cho phép

303/470

chúng ta tránh truy cập các bản ghi dữ liệu, nhưng các cổng vào dữ liệu chỉ mục phảiđược lưu trữ trên dno.

Thực thi chỉ mục trong SQL: 1999

Một câu hỏi tự nhiên đến trong lúc này là chúng ta có thể tạo các chỉ mục trong SQLnhư thế nào. Chuẩn SQL: 1999 không chứa bất cứ câu lệnh tạo hay xoá các cấu trúc chỉmục. Thực tế, chuẩn này thậm chí không yêu cầu SQL hỗ trợ thực thi chỉ mục! Nhưngtrong thực tiễn, tất nhiên tất cả các phần mềm DBMS quan hệ đều hỗ trợ một hoặc nhiềuloại chỉ mục. Câu lệnh sau tạo một chỉ mục B+tree như sau – chúng ta bàn về các chỉmục B+tree trong Chương 10.

CREATE INDEX IndAgeRating ON Students WITH STRUCTURE =BTREE, KEY = (age, gpa)

Điều này chỉ ra rằng chỉ mục B+trê được tạo trên bảng Students sử dụng hai cột age vàgpa như là khoá. Vì thế, các giá trị khoá được cặp đôi dưới dạng (age, gpa) và có mộtcổng vào phân biện cho mỗi cặp như vậy. Ngay khi được tạo, chỉ mục này được DBMSduy trì một cách tự động bằng cách thêm hoặc loại bỏ các cổng vào dữ liệu tương ứngvới việc thêm và xoá các bản ghi trên quan hệ Students.

Câu hỏi ôn tập

Trả lời những câu hỏi tổng kết sau, câu trả lời có thể tìm thấy trong các phần được liệtkê bên cạnh.

• DBMS lưu trữ các dữ liệu ổn định ở đâu? Nó mang dữ liệu vào bộ nhớ chính đểxử lý như thế nào? Thành phần DBMS nào đọc và ghi dữ liệu từ bộ nhớ chính,và đơn vị I/O là gì? (Phần 1)

• Tổ chức file là gì? Chỉ mục là gì? Mối quan hệ giữa các file và các chỉ mục?Chúng ta có thể có một vài chỉ mục trên một file chứa các bản ghi được không?Một chỉ mục bản thân nó có thể lưu trữ các bản ghi dữ liệu được không (tức là,làm việc như file)? (Phần 2)

• Khoá tìm kiếm cho một chỉ mục là gì? Cổng vào dữ liệu trong một chỉ mục làgì? (Phần 2)

• Chỉ mục phân cụm là gì? Chỉ mục chính là gì? Có bao nhiêu chỉ mục phân cụmđược xây dựng trên một file? Có bao nhiêu chỉ mục không được phân cụm cóthể được xây dựng trên một file? (Phần 2.1)

• Dữ liệu được tổ chức như thế nào trong hash-based index? Khi nào bạn sẽ sửdụng hash-based index? (Phần 3.1)

• Dữ liệu được tổ chức như thế nào trong tree-based index? Khi nào bạn sẽ sửdụng tree-based index? (Phần 3.2)

304/470

• Xem xét các phép thực thi sau: quét, phép chọn bằng và chọn miền, thêm, xoá,và các tổ chức file sau: heap files,sorted files, clustered files, heap files cùngvới một unclustered tree index trên khoá tìm kiếm, và heap files cùng với mộtunclustered hash index. Tổ chức file nào là phù hợp nhất đối với mỗi phép toán(Phần 4)

• Cái gì đóng góp chính đối vào chi phí của các phép toán cơ sở dữ liệu? Bàn vềmô hình chi phí đơn giản để phản ánh điều này. (Phần 4.1)

• Lưu lượng công việc ảnh hưởng như thế nào đến thiết kế cơ sở dữ liệu vật lý đểcó những quyết định như là những chỉ mục nào sẽ được xây dựng? Vì sao việclựa chọn chỉ mục ảnh hưởng quan trọng đến thiết kế cơ sở dữ liệu vật lý?(Phần 5)

• Những vấn đề nào được xem xét trong việc sử dụng các chỉ mục phân cụm?Phương pháp đánh giá chỉ-chỉ-số là gì? Lợi ích chính của nó là gì? (Phần 5.2)

• Khoá tìm kiếm tổ hợp là gì? Những ưu và nhược điểm của khoá tìm kiếm tổhợp là gì? (Phần 5.3)

• Các câu lệnh SQL nào hỗ trợ việc tạo chỉ mục? (Phần 5.4)

Bài tập

Trả lời những câu hỏi sau về dữ liệu trên bộ nhớ ngoài trong một DBMS:

1. Vì sao DBMS lưu trữ dữ liệu trên bộ nhớ ngoài?2. Vì sau chi phí I/O đóng vai trò quan trọng trong DBMS?3. Record id là gì? Cho một record id, có bao nhiêu thao tác I/O cần thiết để đưa

được bản ghi này vào bộ nhớ chính.

Vai trò của bộ quản lý vùng đệm trong một DBMS? Vai trò của bộ quản lý khoảngkhông đĩa? Các lớp này tương tác với lớp phương thức truy cập và file (file and accessmethods layer) như thế nào?

Câu trả lời với mỗi câu hỏi như sau:

• Một DBMS lưu trữ dữ liệu ở bộ nhớ ngoài vì số lượng dữ liệu vô cùng lớn, vànó vẫn phải duy trì những thực thi của các chương trình.

• Chi phí I/O đặc biệt quan trọng với DBMS vì chi phí của nó chi phối rất lớnđến hầu hết các thao tác cơ sở dữ liệu. Việc tối ưu hóa các thao tác I/O có thểgiúp cải thiện đáng kể tốc độ thực thi hệ thống.

• Một record id, gọi tắt là rid, cho phép định danh một bản ghi cụ thể trong mộttập các bản ghi. Rid có tính chất là chúng ta có thể xác định được địa chỉ đĩacủa trang đang chứa bản ghi này. Số lượng các yêu cầu I/O để đọc một bản ghiđược gọi là 1 I/O.

• Trong một DBMS, bộ quản lý vùng đệm đọc dữ liệu từ nơi đang lưu trữ nó vàotrong bộ nhớ cũng như viết dữ liệu từ bộ nhớ vào trong vùng lưu trữ. Bộ quản

305/470

lý đĩa quản lý các cùng lưu trữ vật lý của dữ liệu cho DBMS. Khi file và lớpphương pháp truy cập cần xử lý đĩa, nó yêu cầu bộ quản lý vùng đệm nạp cáctrang và đặt nó vào bộ nhớ nếu nó đang không sẵn sàng trong bộ nhớ. Khi cácfile và lớp phương pháp truy cập cần thêm không gian để lưu trữ bản ghi mớivào trong một file nào nó, nó yêu cầu bộ quản lý không gian đĩa chỉ định mộttrang đĩa bổ sung.

Trả lời những câu hỏi sau về dữ liệu trên bộ nhớ ngoài trong một DBMS:

1. Vì sao DBMS lưu trữ dữ liệu trên bộ nhớ ngoài?2. Vì sau chi phí I/O đóng vai trò quan trọng trong DBMS?3. Record id là gì? Cho một record id, có bao nhiêu thao tác I/O cần thiết để đưa

được bản ghi này vào bộ nhớ chính.

Vai trò của bộ quản lý vùng đệm trong một DBMS? Vai trò của bộ quản lý khoảngkhông đĩa? Các lớp này tương tác với lớp phương thức truy cập và file (file and accessmethods layer) như thế nào?

Câu trả lời với mỗi câu hỏi như sau:

1. Một DBMS lưu trữ dữ liệu ở bộ nhớ ngoài vì số lượng dữ liệu vô cùng lớn, và nó vẫnphải duy trì những thực thi của các chương trình.

2. Chi phí I/O đặc biệt quan trọng với DBMS vì chi phí của nó chi phối rất lớn đến hầuhết các thao tác cơ sở dữ liệu. Việc tối ưu hóa các thao tác I/O có thể giúp cải thiện đángkể tốc độ thực thi hệ thống.

3. Một record id, gọi tắt là rid, cho phép định danh một bản ghi cụ thể trong một tập cácbản ghi. Rid có tính chất là chúng ta có thể xác định được địa chỉ đĩa của trang đangchứa bản ghi này. Số lượng các yêu cầu I/O để đọc một bản ghi được gọi là 1 I/O.

4. Trong một DBMS, bộ quản lý vùng đệm đọc dữ liệu từ nơi đang lưu trữ nó vào trongbộ nhớ cũng như viết dữ liệu từ bộ nhớ vào trong vùng lưu trữ. Bộ quản lý đĩa quản lýcác cùng lưu trữ vật lý của dữ liệu cho DBMS. Khi file và lớp phương pháp truy cập cầnxử lý đĩa, nó yêu cầu bộ quản lý vùng đệm nạp các trang và đặt nó vào bộ nhớ nếu nóđang không sẵn sàng trong bộ nhớ. Khi các file và lớp phương pháp truy cập cần thêmkhông gian để lưu trữ bản ghi mới vào trong một file nào nó, nó yêu cầu bộ quản lýkhông gian đĩa chỉ định một trang đĩa bổ sung.

Trả lời những câu hỏi sau về file và các chỉ mục:

1. Các phép toán được hỗ trợ bởi file chứa các bản ghi?2. Chỉ mục trên file chứa các bản ghi là gì? Khoá tìm kiếm trên một chỉ mục là gì?

Vì sao chúng ta cần đến các chỉ mục?

306/470

Minh hoạ của quan hệ Students được sắp xếp theo age3. Các khả năng có thể của các cổng vào dữ liệu trong một chỉ mục nào đó?4. Sự khác nhau giữa chỉ mục chính và chỉ mục phụ? Cổng vào dữ liệu trùng lặp

trong một chỉ mục? Chỉ mục chính có thể chứa sự trùng lặp không?5. Sự khác nhau giữa chỉ mục phân cụm và chỉ mục không phân cụm? Nếu một

chỉ mục nào đó chứa các bản ghi dữ liệu giống như các ‘cổng vào dữ liệu’, nócó thể được không phân cụm (unclustered) không?

6. Trên một file, bạn có thể tạo bao nhiêu chỉ mục được phân cụm? Bạn sẽ luôntạo ít nhất một chỉ mục phân cụm cho một file?

7. Xem xét Alternatives (1), (2) and (3) cho các 'cổng vào dữ liệu' trong một chỉmục nào đó, như đã bàn đến trong Phần 8.2. Tất cả chúng đều thích hợp chocác chỉ mục thứ cấp? Giải thích.

Dành cho độc giả

Xem xét một quan hệ được lưu theo thứ tự sắp xếp ngẫu nhiên, trong đó chỉ có một chỉmục không phân cụm trên trường sal. Nếu bạn muốn truy cập tới tất cả các bản ghi cósal > 20, thì sử dụng chỉ mục này luôn là lựa chọn tốt nhất? Giải thích?

Không. Trong trường hợp này, mỗi cổng vào dữ liệu thỏa mãn có thể chứa một rid, ridnày trỏ tới một trang dữ liệu cụ thể, dẫn tới số lượng trang dữ liệu I/O bằng với số lượngcác cổng vào dữ liệu thỏa mãn điều kiện của truy vấn. Trong trường hợp này, sử dụngchỉ mục sẽ không tốt như sử dụng phương pháp quét file.

Xem xét minh hoạ của quan hệ Students trong Hình 8.6, nó được sắp xếp theo age: Vớinhững mục đích của câu hỏi này, giả sử rằng những bộ giá trị này được lưu trữ trongmột file được sắp theo thứ tự đã chỉ ra; bộ giá trị đầu tiên trên trang 1, bộ giá trị thứ haicũng ở trên trang 1; và tiếp tục. Mỗi trang có thể lưu trữ được ba bản ghi; vì thế bản ghithứ 4 sẽ ở trên trang 2. Giải thích mỗi chỉ mục sau đây sẽ chứa những cổng vào dữ liệunào. Nếu thứ tự của các cổng vào dữ liệu là quan trọng, thì điều gì xảy ra và giải thíchvì sao. Nếu một chỉ mục nào đó không xây dựng được, hãy giải thích vì sao.

1. Một chỉ mục không phân cụm trên age sử dụng Alternative (1).2. Một chỉ mục không phân cụm trên age sử dụng Alternative (2).3. Một chỉ mục không phân cụm trên age sử dụng Alternative (3).

307/470

4. Một chỉ mục phân cụm trên age sử dụng Alternative (1).5. Một chỉ mục phân cụm trên age sử dụng Alternative (2).6. Một chỉ mục phân cụm trên age sử dụng Alternative (3).7. Một chỉ mục không phân cụm trên gpa sử dụng Alternative (1).8. Một chỉ mục không phân cụm trên gpa sử dụng Alternative (2).9. Một chỉ mục không phân cụm trên gpa sử dụng Alternative (3).

10. Một chỉ mục phân cụm trên gpa sử dụng Alternative (1).11. Một chỉ mục phân cụm trên gpa sử dụng Alternative (2).12. Một chỉ mục phân cụm trên gpa sử dụng Alternative (3).

So sánh chi phí I/O

Dành cho độc giả

Giải thích sự khác nhau giữa các chỉ mục băm và chỉ mục B+tree. Cụ thể, trình bày cáctruy vấn bằng và truy vấn miền làm việc như thế nào thông qua một ví dụ.

Chỉ mục băm được xây dựng bằng việc sử dụng một hàm băm để ánh xạ nhanh chóngmột giá trị khóa tìm kiếm đến một vùng cụ thể trong một mảng nào đó- giống như là mộtdanh sách các phần tử và được gọi là buckets. Những buckets thường được xây dựngđể ở đó có nhiều vùng buckets hơn là ở đó có nhiều giá trị khóa tìm kiếm, và hàm bămđược lựa chọn để nó không thường xuyên xảy ra trường hợp hai giá trị khóa tìm kiếmcó cùng một bucket. Chỉ mục B+tree được xây dựng bằng việc sắp xếp dữ liệu trên khóatìm kiếm và duy trì cấu trúc dữ liệu tìm kiếm dạng phân cấp, cấu trúc này trực tiếp tìmra một trang chính xác của các cổng vào dữ liệu. Việc thêm và xóa trong một chỉ mụcdựa trên băm rất đơn giản. Nếu hai giá trị khóa tìm kiếm cùng băm tới một bucket, gọilà sự xung đột, thì một danh sách liên kết được hình thành để kết nối nhiều bản ghi trongmột bucket đơn nào đó. Trong trường hợp có quá nhiều sự xung đột xảy ra, số lượngcác buckets được tăng lên. Ngoài ra, việc duy trì một cấu trúc dữ liệu tìm kiếm phân cấpB+tree được coi là đắt đỏ hơn vì nó phải cập nhật lại khi có bất kỳ thao tác thêm hoặcxóa bản ghi dữ liệu. Nói chung, hầu hết thao tác thêm và xóa sẽ không sửa cấu trúc dữliệu, nhưng cây sẽ phải cấu trúc lại khi nó trở nên quá-đầy.

Các chỉ mục băm đặc biệt tốt đối với các tìm kiếm bằng vì nó cho phép một bản ghinào đó được tìm kiếm rất nhạn với chi phí trung bình là 1.2 I/Os. Mặt khác, các chỉ mục

308/470

B+tree có chi phí từ 3-4 I/Os ứng với mỗi bản ghi. Giả sử rằng chúng ta có một quan hệnhân viên có khó chính là eid và tổng số 10,000 bản ghi. Việc tìm kiếm tất cả các bảnghi sẽ mất chi phí là 12,000 I/Os đối với các chỉ mục băm, trong khi đó đối với các chỉmục B+tree thì chi phí này là 30,000-40,000.

Với các truy vấn miền, các chỉ mục băm thực hiện rất không tốt, vì chúng có thể phảiđọc một số lượng trang bằng với số lượng các bản ghi do dữ liệu không được sắp xếptheo nhóm hoặc tập hợp nào một cách dễ dàng. Mặt khác, các chỉ mục B+tree có chi phí3-4 I/Os cộng với số lượng các trang hoặc các bộ giá trị thỏa mãn, tương ứng với chỉmục B+tree phân cụm hay không phân cụm. Giả sử rằng chúng ta quay lại ví dụ về quanhệ nhân viên có 10,000 bản ghi và 10 bản ghi trên mỗi trang. Cũng như vậy, giả sử rằngở đó có một chỉ mục trên sal và truy vấn với điều kiện age< 20, như vậy ở đây sẽ có5,000 bản ghi thỏa mãn. Chỉ mục băm có thể có chi phí 1000,000 I/Os vì tất cả các trangcó thể được đọc cho tất cả bản ghi. Một chỉ mục không phân cụm B+tree sẽ có chi phílà 5,004 I/Os trong khi một chỉ mục phân cụm B+tree sẽ có chi phí là 505 I/Os. Trongtrường hợp này ta nên sử dụng một chỉ mục phân cụm bất cứ khi nào có thể.

Điền các chi phí I/O tương ứng trong Hình 7.

Dành cho độc giả

Nếu bạn được tạo một chỉ mục nào đó trên một quan hệ, bạn sẽ tuân theo những hướngdẫn nào? Bàn về:

1. Lựa chọn chỉ mục chính.2. Các chỉ mục phân cụm khác với các chỉ mục không phân cụm.3. Các chỉ mục băm khác với các chỉ mục cây.4. Sử dụng một file được sắp hơn là sử dụng một chỉ mục dựa trên cây.5. Lựa chọn khoá tìm kiếm cho chỉ mục này. Khóa tìm kiếm tổ hợp là gì, và

những hướng dẫn nào được thực hiện trong việc lựa chọn các khoá tìm kiếm tổhợp. Các kế hoạch chỉ-chỉ-số là gì, và ảnh hưởng của các kế hoạch đánh giáchỉ-chỉ-số đối việc lựa chọn khoá tìm kiếm cho chỉ mục là gì?

Câu trả lời với mỗi câu hỏi như sau:

• Việc lựa chọn khóa chính được làm dựa trên ngữ nghĩa của dữ liệu. Nếu chúngta cần truy cập các bản ghi dựa trên giá trị của khóa chính, chúng ta nên xâydựng một chỉ mục sử dụng khóa này như là khóa tìm kiếm. Nếu chúng ta cầntruy cập các bản ghi dựa trên giá trị của các trường không liên quan đến khóachính, thì chúng ta xây dựng chỉ mục phụ sử dụng (kết hợp) những trường nàynhư là khóa tìm kiếm.

• Chỉ mục phân cụm cho phép thực hiện truy vấn miền tốt hơn nhiều, nhưng việcthực hiện tìm kiếm bằng cũng như chỉ mục không phân cụm. Thêm nữa, chi phí

309/470

của việc duy trì chỉ mục phân cụm thông thường cao hơn chỉ mục không phâncụm. Vì thế, chúng ta nên tạo một chỉ mục phân cụm chỉ khi các truy vấn miềnlà quan trọng trên khóa tìm kiếm của nó. Chỉ có nhiều nhất là một chỉ mục phâncụm trên một quan hệ, và nếu các truy vấn miền mong muốn có nhiều hơn mộtsự kết hợp của nhiều trường, thì chúng ta phải chọn một sự kết hợp quan trọngnhất và làm nó thành khóa tìm kiếm của chỉ mục phân cụm.

• Nếu các chỉ mục miền được thực hiện thường xuyên, thì chúng ta nên sử dụngmột B+tree trên chỉ mục này của quan hệ vì các chỉ mục băm không thể thựchiện được các truy vấn miền. Nếu các truy vấn bằng được thực hiện nhiều hơnthì chỉ mục băm là lựa chọn tốt nhất vì chúng cho phép truy cập nhanh hơnB+tree.

• Đầu tiên là, cả các file được sắp và các chỉ mục dựa-trên-cây đều cho phép tìmkiếm nhanh hơn. Việc thêm và xóa đối với các chỉ mục dựa-trên-cây thực hiệnnhanh hơn nhiều so với các file được sắp. Mặc khác việc quét và các tìm kiếmmiền cùng với nhiều phép so sánh sẽ thực hiện nhanh hơn nhiều so với các chỉmục dựa-trên-cây. Vì thế, nếu chúng ta có dữ liệu chỉ-đọc (những dữ liệukhông được thay đổi thường xuyên), thì chúng ta nên sử dụng file được sắp,ngược lại, nếu chúng ta có dữ liệu có khả năng được thay đổi thường xuyên, thìchúng ta nên sử dụng chỉ mục dựa-trên-cây.

• Khóa tìm kiếm kết hợp là khóa chứa một vài trường. Khóa tìm kiếm kết hợp cóthể hỗ trợ một vùng rộng lớn cũng như tăng khả năng cho một kế hoạch chỉ-chỉ-số nào đó, nhưng nó cần chi phí cao hơn để duy trì và lưu trữ. Một kế hoạchchỉ-chỉ-số là một kế hoạch đánh giá truy vấn nơi chúng ta chỉ cần truy cập cácchỉ mục để nhận được các bản ghi dữ liệu, mà không cần trực tiếp tới các bảnghi dữ liệu để trả về kết quả cho truy vấn này. Hiển nhiên, những kế hoạch chỉ-chỉ-số nhanh hơn nhiều những kế hoạch thông thường vì nó không yêu cầu đọccác bản ghi dữ liệu. Nếu chúng ta thường xuyên thực hiện các phép thao tác chỉyêu cầu truy cập một trường, ví dụ lấy giá trị trung bình của một trường nào đó,thì việc tạo ra một khóa tìm kiếm trên trường này sẽ có lợi vì sau đó chúng tacó thể hoàn thành nó bằng một kế hoạch chỉ-chỉ-số.

Xem xét yêu cầu xoá sử dụng một điều kiện bằng. Với một trong năm cách tổ chức file,chi phí là bao nhiêu nếu không có bản ghi nào thoả mãn? Chi phí là bao nhiêu nếu điềukiện này không dựa trên khoá.

Dành cho độc giả

Những tổng kết chính nào bạn có thể đưa ra sau khi bàn luận về năm cách tổ chức filecơ bản trong Phần 8.4. Bạn sẽ lựa chọn cách tổ chức file nào nếu các thao tác thườngxuyên nhất là:

1. Tìm các bản ghi theo miền giá trị.2. Thực hiện thêm và quét, trong đó thứ tự của các bản ghi không quan trọng.

310/470

3. Tìm một bản ghi nào đó theo giá trị của một trường cụ thể.

Tổng kết chính về năm cách tổ chức file là tất cả năm cách chúng ta nêu ra đều cónhững ưu và nhược điểm. Không có cách tổ chức file nào là hoàn toàn tốt trong tất cảcác trường hợp. Việc lựa chọn các cấu trúc thích hợp cho một tập dữ liệu nào đó có thểcó ảnh hưởng đáng kể đến việc thực hiện trên. Một file không được sắp xếp là tốt nhấttrong trường hợp chúng ta chỉ mong muốn quét toàn bộ file. Một file chỉ mục băm làtốt nhất nếu như thao tác phổ biến nhất là phép chọn bằng. Một file được sắp là tốt nhấtnếu chúng ta muốn thực hiện các truy vấn miền và dữ liệu là động. Một chỉ mục khôngphân cụm B+tree là hữu ích đối với các phép chọn trên các miền nhỏ, tốt nhất là chúngta phân cụm trên khóa tìm kiếm khác để hỗ trợ một số truy vấn phổ biến.

• 1. Sử dụng những trường này như là khóa tìm kiếm, chúng ta sẽ chọn cách tổchức file sắp xếp hoặc một B+tree phân cụm phụ thuộc vào việc dữ liệu là tĩnhhoặc không.

• 2. Heap file là lựa chọn tốt nhất trong trường hợp này.• 3. Sử dụng trường này như là khóa tìm kiếm, sử dụng một file chỉ mục băm sẽ

là lựa chọn tốt nhất.

Xem xét quan hệ sau:

Emp(eid: integer, sal: integer, age: real, did: integer)

Ở đây có một chỉ mục phân cụm trên eid và một chỉ mục không phân cụm trên age.

1. Bạn sẽ sử dụng các chỉ mục này như thế nào để thiết lập một ràng buộc là: eidlà một khoá?

2. Cung cấp một ví dụ của lệnh cập nhật mà tốc độ của nó được cải thiện do cócác chỉ mục này.

3. Cung cấp một ví dụ của lệnh cập nhật mà tốc độ của nó bị chậm xuống do cócác chỉ mục này.

4. Bạn có thể cung cấp một ví dụ của lệnh cập nhật mà tốc độ của nó không tănghay giảm do có các chỉ mục này.

Dành cho độc giả

Xem xét các quan hệ sau:

Emp(eid: integer, ename: varchar, sal: integer, age:integer, did: integer) Dept(did: integer, budget: integer,floor: integer, mgr_eid: integer)

311/470

Lương (sal) nằm trong miền từ $10,000 tới $100,000, tuổi (age) nằm trong khoảng từ 20to 80, mỗi phòng (Dept) có trung bình khoảng năm nhân viên, có 10 tầng, và ngân sách(budgets) của mỗi phòng khoảng từ $10,000 tới $1 million.

Với mỗi truy vấn sau, chỉ mục nào bạn sẽ lựa chọn để tăng tốc độ của truy vấn. Nếu hệcơ sở dữ liệu của bạn không hỗ trợ các kế hoạch chỉ-chỉ-số (tức là, các bản ghi dữ liệuluôn được truy cập ngay cả khi thông tin có đầy đủ trong các cổng vào dữ liệu chỉ mục),câu trả lời của bạn sẽ thay đổi như thế nào? Giải thích tóm tắt.

1. Truy vấn: In ra ename, age, và sal của tất cả nhân viên1. Chỉ mục băm phân cụm trên các trường (ename, age, sat) của Emp.2. Chỉ mục băm không phân cụm trên các trường (ename, age, sal) của

Emp.3. Chỉ mục phân cụm B+ tree trên các trường (ename, age, sal) của Emp.4. Chỉ mục băm không phân cụm trên các trường (eid, did) của Emp.5. Không chỉ mục

2. Truy vấn: Tìm các dids của các phòng ở trên tầng 10 và ngân sách ít hơn$15,000.

1. Chỉ mục băm phân cụm trên trường floodcủa Dept.2. Chỉ mục băm không phân cụm trên trường floodcủa Dept.3. Chỉ mục phân cụm B+ tree trên các trường (floor, budget) của Dept.4. Chỉ mục phân cụm B+ tree trên các trường budget của Dept.5. Không chỉ mục

Câu trả lời với mỗi câu hỏi như sau:

1. Chúng ta nên tạo một chỉ mục băm không phân cụm trên các trường (ename, age, sal)của Emp (b) vì sau đó chúng ta có thể thực hiện quét chỉ-chỉ-số. Nếu hệ thống của chúngta không bao gồm các kế hoạch chỉ-chỉ-số thì chúng ta không nên tạo chỉ mục cho truyvấn này (e). Vì truy vấn này yêu cầu chúng ta truy cập tất cả các bản ghi Emp, nên chỉmục này không giúp chúng ta bất cứ điều gì, và vì thế chúng ta nên truy cập các bản ghisử dụng thao tác quét file.

2. Chúng ta nên tạo một chỉ mục phân cụm ‘rậm rạp’ B+tree (c) trên các trường (floor,budget) của Dept, vì sau đó các bản ghi này sẽ được sắp xếp theo những trường này. Vìthế khi thực hiện truy vấn này, bản ghi đầu tiên có floor=10 phải được truy cập, sau đócác bản ghi khác có floor=10 có thể được đọc theo thứ tự của budget. Ghi nhớ rằng kếhoạch này- không phải là tốt nhất cho truy vấn này- không phải là một kế hoạch chỉ-chỉ-số (phải tìm kiếm dids).

BÀI TẬP LỚN

Trả lời những câu hỏi sau:

312/470

• Các công nghệ chỉ mục nào được Minibase hỗ trợ?• Những Alternatives của các cổng vào dữ liệu được hỗ trợ?• Những chỉ mục phân cụm được hỗ trợ?

TÀI LIỆU THAM KHẢO

Một vài cuốn sách bàn về các tổ chức file [29, 312, 442, 531, 648, 695, 775].

Những tài liệu tham khảo về các chỉ mục băm và B+tree được nêu trong Chương 10 và11.

313/470

Tổng quan về đánh giá truy vấnTrong chương này, chúng tôi trình bày tổng quan về cách thức thực hiện các truy vấntrong một hệ quản trị cơ sở dữ liệu quan hệ. Chúng ta bắt đầu bằng việc bàn về cáchquản lý dữ liệu bao gồm các bảng và các chỉ mục trong Phần 1. Dữ liệu về cấu trúc, còngọi là metadata, được lưu trữ trong các bảng đặc biệt gọi là các danh mục hệ thống,được sử dụng để tìm ra cách tốt nhất thực hiện một truy vấn.

Các truy vấn SQL được biên dịch sang đại số quan hệ và các bước tiến hành thực hiệntruy vấn được biểu diễn bằng các phép toán của đại số quan hệ dưới dạng Hình cây, cácphép toán được biểu diễn trong các nút. Vì thế, việc thực thi các phép toán quan hệ đượctối ưu một cách cẩn thận để cho truy vấn được thực hiện tốt nhất có thể. Chúng tôi giớithiệu việc đánh giá các phép toán trong Phần 2 và trình bày các thuật toán đánh giá chohàng loạt các phép toán trong Phần 3.

Nhìn chung, các truy vấn thường có một vài các phép toán, và có nhiều cách để kết hợpcác phép toán này. Quá trình tìm ra cách tốt nhất để thực hiện truy vấn được gọi là tốiưu hoá truy vấn. Chúng tôi giới thiệu về tối ưu hoá truy vấn trong Phần 4. Công việc cơsở để tối ưu hoá truy vấn là xem xét một số kế hoạch thực hiện truy vấn đó, minh hoạtrong ví dụ của Phần 5. Phần 6 xem xét các bước tiến hành thực hiện một truy vấn nếuthực hiện thủ công.

Công việc này được trình bày một cách đầy đủ, chi tiết để người đọc hiểu được cáchthức các hệ thống cơ sở dữ liệu thực hiện các truy vấn. Chương này cung cấp kiến thứcnền tảng của việc thực hiện truy vấn. Thực thi các phép toán quan hệ và tối ưu hoá truyvấn được trình bày thêm trong Chương 13, 14 và 15; những chương này trình bày sâuhơn về cách thức các hệ thống cơ sở dữ liệu thực hiện điều này như thế nào.

Chúng ta xem xét một số truy vấn ví dụ sử dụng lược đồ quan hệ sau:

Sailors(sid: integer, sname: string, rating: integer, age:real) Reserves(sid: integer, bid: integer, day: dates,rname: string)

Chúng ta giả sử rằng mỗi một bộ giá trị của quan hệ Reserver có dung lượng là 40 bytes,vì thế mỗi trang có thể quản lý 100 bộ giá trị của quan hệ này, và giả sử chúng ta có1000 trang chứa các bộ giá trị. Tương tự, chúng ta giả sử rằng mỗi bộ giá trị của quan hệSailors có dung lượng là 50 bytes, vì thế mỗi trang có thể quản lý 80 bộ giá trị Sailors,và chúng ta có 500 trang chứa các bộ giá trị này.

314/470

Danh mục hệ thống

Chúng ta có thể lưu trữ một bảng sử dụng một trong số một vài cấu trúc file khác nhau,và chúng ta có thể tạo ra một hoặc nhiều chỉ mục- mỗi một chỉ mục được lưu trong mộtfile- trên mỗi bảng. Ngược lại, trong một DBMS quan hệ, mỗi file chứa các bộ giá trịtrong một bảng hoặc các cổng vào chỉ mục. Tập hợp các file này tương ứng với các bảngcủa người dùng và các chỉ mục biểu diễn dữ liệu trong cơ sở dữ liệu.

DBMS quan hệ duy trì thông tin về tất cả các bảng và các chỉ mục có trong nó. Nhữngthông tin định nghĩa các bảng và các chỉ mục được lưu trong một tập các bảng đặc biệtgọi là các bảng danh mục. Một ví dụ về bảng danh mục được minh hoạ trong Hình 1.Các bảng danh mục còn được gọi là từ điển dữ liệu, danh mục hệ thống, hay đơn giảngọi là danh mục.

Thông tin trong danh mục

Hãy cùng chúng tôi xem xét những nội dung được lưu trong danh mục. Ở mức tối thiểu,chúng ta có thông tin về hệ thống, như kích thước của buffer pool và kích thước trang,và những thông tin về các bảng, chỉ mục, và khung nhìn.

• Với mỗi bảng:◦ Thông tin về tên bảng, tên file, cấu trúc file (ví dụ, heap file) của file

lưu trữ bảng.◦ Tên chỉ mục của mỗi chỉ mục trên bảng.◦ Các ràng buộc toàn vẹn (ví dụ, ràng buộc khoá chính, khoá ngoại) trên

bảng.• Với mỗi chỉ mục:

◦ Tên chỉ mục và cấu trúc của chỉ mục (ví dụ, B-tree).◦ Các thuộc tính khoá tìm kiếm (search key).

• Với mỗi khung nhìn:◦ Thông tin về tên khung nhìn và định nghĩa của nó.

Thêm nữa, các thống kê về các bảng và các chỉ mục được lưu trữ trong các danh mục hệthống và được cập nhật định kỳ (không phải bất cứ lúc nào khi bảng được thay đổi).

Những thông tin sau được lưu trữ chung:

• Lực lượng: Số lượng các bộ giá trị Ntuples(R) của mỗi bảng R.• Kích thước: Số lượng các trang Npages(R) của mỗi bảng R.• Lực lượng chỉ mục: Số lượng các giá trị khoá khác nhau Nkeys(I) của mỗi chỉ

mục.• Kích thước chỉ mục: Số lượng các trang INPages(I) của mỗi chỉ mục .(Với

một chỉ mục B+ tree, chúng ta có INpages là số lượng các trang lá.)

315/470

• Chiều cao chỉ mục: Số lượng các mức không phải là lá IHeight(I) của mỗi câychỉ mục.

• Miền chỉ mục: Giá trị khoá nhỏ nhất Ilow(I) và giá trị khoá lớn nhất Ihigh(I)của mỗi chỉ mục.

Chúng ta giả sử rằng kiến trúc cơ sở dữ liệu trình bày ở Chương 1 được sử dụng. Thêmnữa, chúng ta giả sử rằng mỗi file của các bản ghi được thực thi như là một file riêng rẽcủa các trang. Tất nhiên những file khác tổ chức như có thể. Ví dụ, một file trang có thểchứa các trang lưu trữ các bản ghi từ các file bản ghi khác nhau.

Danh mục cũng chứa những thông tin về người dùng, như thông tin về tài khoảnngười dùng và thông tin xác thực người dùng. (Ví dụ, người dùng joe có thể sửa bảngReservers, nhưng anh ta chỉ có quyền đọc bảng Sailors).

Danh mục được lưu trữ như thế nào

Một đặc điểm của DBMS quan hệ là bản thân danh mục hệ thống là một tập hợp cácbảng. Ví dụ, chúng ta có thể lưu trữ thông tin về các thuộc tính của các bảng trong mộtbảng danh mục gọi là Attribute_Cat:

Atttribute_Cat(attr_name: string, rel_name: string, type:string, position: integer)

Giả sử rằng cơ sở dữ liệu chứa hai bảng đã được giới thiệu ở đầu chương:

Sailors(sid: integer, sname: string, rating: integer, age:real) Reserves(sid: integer, bid: integer, day: dates,rname: string)

Hình 1 chỉ ra các bộ giá trị của bảng Attribute_Cat biểu diễn các thuộc tính của haibảng này. Ghi nhớ rằng ngoài những bộ giá trị biểu diễn các thuộc tính của Sailors vàReserves còn có những bộ giá trị khác biểu diễn các thuộc tính của chính quan hệ này.Những bộ giá trị này chỉ ra một đặc điểm quan trọng: danh mục các bảng biểu diễn tấtcả các bảng trong cơ sở dữ liệu và cả chính bản thân nó. Khi thông tin về một bảng đượcyêu cầu, nó sẽ được lấy ra từ danh mục hệ thống.

Cách tổ chức danh mục hệ thống là một tập hợp các bảng tỏ ra rất hiệu quả. Ví dụ, cácbảng danh mục có thể được truy cập giống như một bảng bất kỳ, sử dụng ngôn ngữ truyvấn của DBMS! Thêm nữa, tất cả các công nghệ thực thi và quản lý các bảng đều có thểáp dụng cho các bảng danh mục. Những lựa chọn cho các bảng danh mục và lược đồ củanó không phải là duy nhất và được làm bởi những người thực thi DBMS. Các hệ thốngthực thay đổi theo thiết kế lược đồ của nó, nhưng danh mục luôn được thực thi như một

316/470

tập các bảng và cơ bản là nó chỉ ra cấu trúc của các dữ liệu được lưu trữ trong cơ sở dữliệu.

Minh hoạ dữ liệu của quan hệ Attribute_Cat

Giới thiệu về đánh giá phép toán

Một số các thuật toán có thể được thực thi trên các phép toán quan hệ. Có một số nhântố giúp cho các thuật toán được thực hiện tốt nhất, bao gồm kích thước của các bảng,các chỉ mục đang tồn tại và thứ tự sắp xếp các bản ghi trong bảng, kích thước của bufferpool và những luật được áp lên buffer.

Trong Phần này chúng ta trình bày một số công nghệ phổ biến được sử dụng trong việcphát triển các thuật toán đánh giá các phép toán quan hệ, và giới thiệu khái niệm vềđường truy cập, những cách khác nhau mà các dòng của bảng có thể được truy cập.

Ba công nghệ phổ biến

Các thuật toán cho các phép toán quan hệ thường có nhiều điểm chung. Có một vài côngnghệ được sử dụng để phát triển các thuật toán cho mỗi phép toán.

• Chỉ mục (Indexing): Nếu một lựa chọn hoặc điều kiện kết nối được xác định,sử dụng chỉ mục để kiểm tra xem các bộ giá trị nào thoả mãn điều kiện.

• Lặp (Iteration): Kiểm tra tất cả các bộ giá trị của bảng đầu vào, từng bộ một.Nếu chúng ta chỉ cần một vài trường trong bảng này và ở đây có một chỉ mụccủa khoá chứa tất cả các trường này, thì thay vì việc kiểm tra các bộ giá trị,chúng ta có thể quét tất cả các cổng vào chỉ mục.

• Phân vùng (Partitioning): Bằng việc phân vùng các bộ giá trị dựa trên khóasắp xếp, chúng ta có thể phân tích một phép toán nào đó thành một tập các phéptoán mà giá phải trả để thực hiện nó là rẻ hơn.

317/470

Sắp xếp và Băm là các công nghệ phân vùng được sử dụng phổ biến nhất.

Chúng ta bàn đến vai trò của chỉ mục trong Phần 2.2. Lặp và phân vùng được trình bàytrong Phần 3.

Đường dẫn

Đường dẫn truy cập là một cách để truy cập các bộ giá trị từ một bảng nào đó bao gồm(1) một bảng được quét hoặc (2) một chỉ mục cộng thêm với một điều kiện lựa chọnphù hợp. Tất cả các phép toán quan hệ đều chấp nhận đầu vào là một hoặc nhiều bảng,và các phương pháp truy cập đến các bộ giá trị góp Phần đáng kể vào việc định giá cácphép toán.

Xem xét một yêu cầu lựa chọn đơn giản là một kết nối với điều kiện attr op value, trongđó op là một phép toán so sánh <, <, =, ^, >, hoặc >. Những lựa chọn như thế này đượcgọi là liên kết bình thường (conjunctive normal form (CNF)), và mỗi điều kiện đượcgọi là một liên kết. Một chỉ mục được xem là phù hợp với một điều kiện lựa chọn nếuchỉ mục này có thể được sử dụng để truy cập đến chỉ những bộ giá trị thoả mãn điềukiện.

Một chỉ mục băm (hash index) phù hợp với một CNF selection nếu có một thành Phầncó dạng attribute=value ứng với từng khoá tìm kiếm của chỉ mục (index’s search key)trong câu lệnh lọc.

Một chỉ mục dạng cây phù hợp với một CNF selection nếu có một thành Phần có dạngattribute op value ứng với mỗi thuộc tính trong một tiền tố nào đó của khoá tìm kiếmcủa chỉ mục. {{a} và {a,b} là những tiền tố của khoá {a,b,c}, nhưng {a,c} và {b,c} thìkhông.)

Ghi nhớ rằng op có thể là bất kỳ phép so sánh nào.

Những ví dụ sau minh hoạ về đường dẫn truy cập:

Nếu chúng ta có một hash index H trên khoá tìm kiếm là <rname,bid,sid>, chúng tacó thể sử dụng chỉ mục này để truy cập đến chỉ những bộ giá trị trong quan hệ Sailorsthoả mãn điều kiện rname='Joe' ∧ bid=5 ∧ sid=3. Chỉ mục này phù hợp với toàn bộđiều kiện rname='Joe' ∧ bid=5 ∧ sid=3. Ngược lại, nếu điều kiện chọn là rname='Joe'∧ bid=5, hoặc một điều kiện nào đó dựa trên ngày/tháng (date), chỉ mục này sẽ khôngphù hợp. Tức là, nó không thể được sử dụng để truy vấn đến những bộ giá trị thoả mãnnhững điều kiện này.

318/470

Ngược lại, nếu chỉ mục này là một B+tree, nó sẽ phù hợp với cả rname='Joe'∧ bid=5∧sid=3 và rname='Joe' ∧ bid=5. Tuy nhiên, nó sẽ không phù hợp với điều kiện bid=5 ∧sid=3 (vì những bộ giá trị này được sắp xếp chính theo rname).

Nếu chúng ta có một chỉ mục (hash hoặc tree) trên khoá tìm kiếm <bid, sid> và điềukiện lọc là rname='Joe'∧ bid=5 ∧ sid=3, chúng ta có thể sử dụng chỉ mục này để truycập đến các bộ giá trị thoả mãn điều kiện bid=5 ∧sid=3; Đây là những kết nối chính.Những cụm nhỏ của các bộ giá trị thoả mãn điều kiện kết nối (và nếu chỉ mục là phâncụm) xác định số lượng các trang được truy cập. Sau đó, điều kiện bổ sung về rnameđược áp dụng lên những bộ giá trị trên để loại đi những bộ giá trị không thoả điều kiệnrname= ‘Joe’.

Nếu chúng ta có một chỉ mục nào đó trên khoá tìm kiếm <bid, sid> và chúng ta cũngcó một chỉ mục B+tree trên day, điều kiện lọc là day < 8/9/2002 ∧ bid=5 ∧ sid=3 chochúng ta một lựa chọn. Cả hai chỉ mục đều phù hợp với điều kiện lọc, và chúng ta có thểsử dụng cả hai để truy cập đến các bộ giá trị trong Reserves. Bất cứ chỉ mục nào chúngta sử dụng, các kết nối trong điều kiện lọc không phù hợp với chỉ mục (ví dụ, bid=5∧sid=3 nếu chúng ta sử dụng chỉ mục B+tree trên day) phải được kiểm tra ứng với mỗibộ giá trị được truy cập.

Lựa chọn các đường dẫn truy cập

Lựa chọn một đường dẫn truy cập là số lượng những trang truy cập (các trang chỉ mụccộng với các trang dữ liệu) nếu chúng ta sử dụng đường dẫn truy cập này để truy cậpđến những bộ giá trị mong muốn. Nếu bảng chứa một chỉ mục nào đó phù hợp với yêucầu lọc dữ liệu, có ít nhất hai đường dẫn truy cập: chỉ mục và việc quét file dữ liệu. Đôikhi, tất nhiên, chúng ta có thể quét chính bản thân chỉ mục (hơn là quét file dữ liệu hoặcsử dụng chỉ mục để duyệt file dữ liệu), cung cấp cho chúng ta đường dẫn truy cập thứba.

Đường dẫn truy cập được lựa chọn nhiều nhất là đường dẫn truy cập tới ít trang nhất vìnó tối thiểu hoá được chi phí phải trả cho truy cập dữ liệu. Việc lựa chọn các đường dẫntruy cập phụ thuộc vào những kết nối chính trong điều kiện lựa chọn (bao gồm cả nhữngảnh hưởng của các chỉ mục liên quan). Mỗi kết nối làm việc như một bộ lọc trên bảng.Tỷ lệ của các bộ giá trị trong bảng thoả mãn một kết nối nào đó được gọi là nhân tốgiảm. Khi ở đó có một vài kết nối chính, tỷ lệ của các bộ giá trị thoả mãn tất cả các kếtnối chính này có thể xấp xỉ bằng tích của các nhân tố giảm.

Giả sử chúng ta có một chỉ mục băm H trên quan hệ Sailors với khoá tìm kiếm chínhlà < rname,bid,sid >, và chúng ta có điều kiện lọc là rname='Joe' ∧bid=5 ∧ sid=3.Chúng ta có thể sử dụng chỉ mục này để truy cập đến các bộ giá trị thoả mãn cả ba điềukiện nối. Danh mục chứa số lượng những giá trị khoá phân biệt trong chỉ mục băm này

319/470

Nkeys(H), cũng như là số lượng các trang trong bảng sailor Npages. Tỷ lệ của trang thoảmãn các kết nối chính là Npages(Sailors) ⋅ 1

NKeys(H) .

Nếu chỉ mục này có khoá tìm kiếm < bid, sid >, kết nối chính là bid=5 ∧ sid=3. Nếuchúng ta biết số lượng những giá trị phân biệt trong cột bid, chúng ta có thể ước lượngđược nhân tố giảm cho kết nối đầu tiên. Thông tin này có giá trị trong danh mục nếu cómột chỉ mục nào đó với bid là khoá tìm kiếm; nếu không, bộ tối ưu hoá sẽ sử dụng giátrị mặc định là 1/10. Sự tăng lên của các nhân tố giảm với bid=5 và sid=3 cung cấp chochúng ta tỷ lệ các bộ giá trị được truy cập; nếu chỉ mục được phân cụm, đây cũng là tỷlệ của các trang truy cập. Nếu chỉ mục này không phân cụm, mỗi bộ dữ liệu được truycập có thể ở trên các trang khác nhau (xem lại Phần 8.4).

Chúng ta ước lượng được nhân tố giảm với một điều kiện miền như day > 8/9/2002bằng việc giả sử rằng những giá trị trong cột này được phân bố đều nhau. Nếu có B+treeT với khoá day, nhân tố giảm là High(T) − value

High(T) − Low(T)

Các thuật toán cho các phép toán quan hệ

Trong Phần này chúng tôi sẽ trình bày về các thuật toán đánh giá cho các phép toán quanhệ chính. Những ý tưởng quan trọng được giới thiệu ở đây, và những nghiên cứu sâuhơn sẽ được trình bày trong Chương 14. Trong chương 6, chúng ta chỉ xem xét chi phíI/Os và định giá chi phí này thông qua các trang I/Os. Trong chương này, chúng ta sửdụng những ví dụ chi tiết để minh hoạ cách định giá của mỗi thuật toán.

Mặc dù chúng tôi không trình bày công thức định giá một cách chính xác trong chươngnày, nhưng người đọc nên áp dụng những ý tưởng đã nêu để tính toán cho những ví dụkhác.

Phép chọn

Phép chọn là phép toán truy cập các bộ giá trị từ bảng, và cách thực thi của nó đã đượcbàn đến trong Phần access paths. Để tổng kết, cho một phép chọn có dạng δ R.attr op value(R), nếu ở đây không có chỉ mục nào trên R.attr thì chúng ta phải quét toàn bộ R.

Nếu có một hoặc nhiều chỉ mục trên R phù hợp với phép chọn này, chúng ta có thể sửdụng chỉ mục này để truy cập tới các bộ giá trị thoả mãn, và áp dụng bất kỳ điều kiệnchọn còn lại nào để giới hạn tập kết quả. Ví dụ, xem xét một phép chọn có dạng rname< ‘C%’ trên bảng Reserves. Giả sử rằng tên được phân bố đều theo ký tự đầu tiên, đểđơn giản, chúng ta ước lượng khoảng 10% bộ giá trị của bảng Reserves sẽ có trong kếtquả. Ở đây có tổng số 10,000 bộ giá trị, hoặc 100 trang. Nếu chúng ta có một chỉ mụcB+tree trên trường rname của Reserves, chúng ta có thể truy cập tới các bộ giá trị thoảmãn điều kiện với 100 I/Os (cộng thêm một vài I/Os để chuyển từ gốc tới các trang lá

320/470

phù hợp để bắt đầu việc quét). Tuy nhiên, nếu chỉ mục này là unclustered, chúng ta cóthể phải có 10,000 I/Os trong trường hợp xấu nhất, vì mỗi bộ giá trị có thể là nguyênnhân chúng ta phải đọc cả một trang.

Xem Phần 14.1 để có nhiều thông tin hơn về việc thực thi của các phép chọn.

Phép chiếu

Phép chiếu là phép toán lấy ra các cột của bảng. Một yêu cầu phải trả giá đắt của phéptoán này là phải đảm bảo rằng không có những bộ giá trị trùng nhau trong kết quả. Vídụ, nếu chúng ta chỉ muốn lấy ra hai cột sid và bid trong bảng Reserves, chúng ta có thểcó những bộ giá trị trùng nhau.

Nếu cho phép có sự trùng lặp (tức là, từ khoá DISTINCT không được chỉ ra trong mệnhđề SELECT), phép chiếu đơn thuần chỉ lấy ra một tập con các trường trong bảng đầuvào. Điều này có thể được thực hiện đơn giản bằng việc lấy ra các trường trong bảnghoặc trong chỉ mục có chứa những trường cần thiết.

Nếu chúng ta muốn loại những bộ giá trị trùng nhau, chúng ta phải sử dụng đến sự chiatách. Giả sử chúng ta muốn lấy {sid, bid} trong Reserves. Chúng ta có thể chia tách nhưsau (1) quét Reserves để lấy cặp {sid, bid} và (2) sắp xếp các cặp này sử dụng {sid, bid}như là khoá sắp xếp. Sau đó, chúng ta có thể quét những cặp được sắp xếp và dễ dàngloại bỏ những cặp trùng lặp vì những cặp này nằm sát cạnh nhau.

Sắp xếp một lượng lớn dữ liệu trên đĩa là một phép toán rất quan trọng trong các hệ cơsở dữ liệu, và được trình bày trong Chương 13.

Phép chiếu có thể được tối ưu bằng việc kết hợp việc quét bảng Reserves với việc quéttrong bước đầu tiên của sắp xếp. Tương tự, việc quét các cặp đã sắp xếp có thể được kếthợp với bước cuối cùng của việc sắp xếp. Với cách thực hiện tối ưu như vậy, phép chiếucó sự loại bỏ trùng lặp yêu cầu (1) bước đầu tiên là toàn bộ bảng được quét và chỉ cặp{sid, bid} được viết ra, và (2) bước cuối cùng sau khi tất cả các cặp được quét, chỉ duynhất một bản sao của mỗi cặp được viết ra. Thêm nữa, có thể có một bước trung giantrong đó tất cả các cặp được đọc ra và viết lên đĩa.

Sự hiệu quả của các chỉ mục thích hợp có thể dẫn tới những kế hoạch ít tốn kém hơnkhi có yêu cầu sắp xếp đồng thời loại các giá trị trùng lặp. Nếu chúng ta có một chỉ mụctrong đó khoá tìm kiếm chứa tất cả các trường có trong phép chiếu, chúng ta có thể sắpxếp dữ liệu ngay trong chỉ mục. Nếu tất cả các thuộc tính có trong phép chiếu xuất hiệntrong một tiền tố nào đó của khoá tìm kiếm của mỗi chỉ mục phân cụm, chúng ta cóthể làm điều này nhanh hơn; chúng ta đơn giản có thể truy cập toàn bộ dữ liệu sử dụngnhững chỉ mục này, và sự trùng lặp dễ dang bị loại bỏ vì chúng đứng gần nhau. Những

321/470

kế hoạch này là những ví dụ bổ sung của các chiến lược đánh giá chỉ-chỉ-số, Phần nàysẽ được trình bày trong Phần 8.5.2.

Xem Phần 14.3 để có nhiều thông tin hơn về việc thực thi của các phép chiếu.

Liên kết

Liên kết là phép toán đắt và rất phổ biến. Vì thế, chúng được nghiên cứu một cách rộngrãi, và các hệ thống tiêu biểu hỗ trợ một số thuật toán để thực thi phép toán này.

Xem xét một phép liên kết của Reserves với Sailors, với điều kiện nối là Reserves.sid= Sailors.sid. Một trong số các bảng này, giả sử là Sailors, có một chỉ mục trên cột sid.Chúng ta có thể quét từng bộ giá trị của Reserves, sử dụng chỉ mục này để khảo sátSailor lấy ra những bộ giá trị phù hợp. Cách tiếp cận này được gọi là liên kết lặp lồngnhau chỉ mục.

Giả sử rằng chúng ta có một hash-based index sử dụng Alternative (2) trên thuộc tínhsid của quan hệ Sailors và trung bình nó cần khoảng 1.2 I/Os để truy cập tới trang thíchhợp của chỉ mục này. Vì sid là một khoá của Sailors, chúng ta có nhiều nhất một bộgiá trị thỏa mãn điều kiện. Thực tế, sid trong Reserves là một khoá ngoại tham chiếutới Sailors, và vì thế chúng ta có chính xác một bộ giá trị của Sailor ứng với mỗi bộgiá trị của Reserves. Hãy cùng chúng tôi xem xét giá phải trả của việc quét Reserves vàsử dụng chỉ mục này để truy cập tới bộ giá trị của Sailors ứng với mỗi bộ giá trị trongReserves. Giá phải trả cho việc quét Reserves là 1000. Có 100*1000 bộ giá trị trongReserves. Ứng với mỗi bộ giá trị này, việc truy cập trang chỉ mục chứa rid phù hợp vớibộ giá trị của Sailors phải trả là 1.2 I/Os (trung bình); thêm nữa, chúng ta phải truy cậptới trang lưu Sailors chứa bộ giá trị thoả mãn. Vì thế chúng ta có 100,000*(1+1.2) I/Osđể truy cập tới các bộ giá trị Sailors thoả mãn. Tổng cộng là 221,000 I/Os.

Nếu chúng ta không có chỉ mục phù hợp với điều kiện nối trên cả hai bảng, chúng takhông thể sử dụng lặp lồng nhau chỉ mục. Trong trường hợp này, chúng ta có thể sắpxếp cả hai bảng dựa trên cột liên kết, và sau đó quét chúng để tìm ra những bộ giá trịthoả mãn. Cách làm này gọi là liên kết sắp-xếp-trộn. Giả sử rằng chúng ta có thể sắpxếp Reserves trên hai pha, và Sailors cũng trên hai pha, hãy cùng chúng tôi xem xétgiá phải trả của liên kết sắp-xếp-trộn. Xem xét liên kết này trên hai bảng Reserves vàSailors. Vì chúng ta đọc và ghi Reserves trên mỗi pha, giá sắp xếp là 2*2*1000=4000 I/Os. Thêm nữa, pha thứ hai của thuật toán liên kết sắp-xếp-trộn yêu cầu một việc quét bổsung trên cả hai bảng. Vì thế, tổng chi phí phải trả là 4000 + 2000 + 1000 + 500 = 7500I/Os.

Quan sát thấy rằng chi phí của liên kết sắp-xếp-trộn, cái mà không yêu cầu có sẵn mộtchỉ mục, thấp hơn giá thành của liên kết lặp lồng nhau chỉ mục. Thêm nữa, kết quả củaliên kết sắp-xếp-trộn được sắp xếp trên (các) cột liên kết. Các thuật toán liên kết khác

322/470

không dựa trên chỉ mục có sẵn và rẻ hơn lặp lồng nhau chỉ mục được biết đến là (lặplồng nhau trên khối và nối băm; xem thêm trong Chương 14). Dựa vào đây, bạn Trả lờivì sao lại đề cập đến lặp lồng nhau chỉ mục ở đây?

Lặp lồng nhau chỉ mục có một tính chất rất tốt đó là tăng trưởng. Chi phí của liên kếttrong ví dụ tăng trưởng theo số lượng bộ giá trị của Reserves mà chúng ta xử lý. Vì thế,nếu một số điều kiện lựa chọn trong truy vấn cho phép chúng ta chỉ cần quan tâm đếnmột tập con các bộ giá trị trong Reserves, chúng ta có thể tránh được việc phải thực hiệnliên kết toàn bộ thực thể. Ví dụ, giả sử rằng chúng ta chỉ muốn thực liên kết cho các bộgiá trị có boat là 101, và ở đó sẽ chỉ có một vài giá trị của Reserves thỏa mãn. Với mỗibộ giá trị này, chhúng ta tìm kiếm trong Sailors. Nếu chúng ta sử dụng liên kết sắp-xếp-trộn thì chúng ta phải quét toàn bộ bảng Sailors ít nhất một lần, và giá thành của riêngbước này đã lớn hơn toàn bộ giá thành của liên kết lặp lồng nhau chỉ mục.

Quan sát thấy rằng việc lựa chọn liên kết lặp lồng nhau chỉ mục dựa trên việc xem xétbản thân truy vấn, bao gồm các điều kiện chọn, không chỉ đơn thuần là bản thân phéptoán liên kết. Điều này dẫn chúng ta đến chủ đề tiếp theo là tối ưu hoá truy vấn, mụcđích của nó chính là tìm ra được kế hoạch tốt cho toàn bộ truy vấn.

Xem Phần 14.4 để có thêm thông tin.

Những phép toán khác

Một truy vấn SQL có thể chứa mệnh đề group-by và các hàm nhóm. Các kết quả truyvấn khác nhau có thể được kết hợp bằng phép hợp, phép giao, phép trừ.

Các phép toán tập hợp như phép hợp và phép giao phải trả giá đắt cho việc loại bỏ nhữnggiá trị trùng nhau, giống như phép chiếu. Cách tiếp cận sử dụng để thực thi phép chiếucó thể dễ dàng tương thích với các phép toán này. Xem Phần 14.5 để có thêm thông tin.

Group-by được thực hiện thông qua việc sắp xếp, các bảng đầu vào có một chỉ mục dạngcây với một khóa tìm kiếm phù hợp với các thuộc tính được nhóm. Trong trường hợpnày, chúng ta có thể truy cập tới các bộ giá trị sử dụng một chỉ mục theo thứ tự phù hợpmà không cần sử dụng bước sắp xếp. Các phép toán nhóm được thực thi sử dụng cácbiến đếm phụ lưu trong bộ nhớ chính như là các bộ giá trị được truy cập. Xem chi tiếttrong Phần 14.6.

Giới thiệu về tối ưu hoá truy vấn

Tối ưu hoá truy vấn là một trong những công việc quan trọng nhất của một RDBMS(Relational DBMS). Một trong những ưu điểm của các ngôn ngữ truy vấn quan hệ là nócó nhiều cách khác nhau để thực hiện một truy vấn, vì thế hệ thống phải đánh giá đượctruy vấn. Một truy vấn có thể được viết bằng nhiều cách khác nhau, và giá phải trả cho

323/470

từng cách là khác nhau. Chúng ta không thể hy vọng luôn tìm được kế hoạch tốt nhấtcho một truy vấn nào đó, nhưng chúng ta hy vọng tìm ra một kế hoạch đủ tốt.

Nhiều thông tin hơn về tối ưu hoá truy vấn và các lớp (layer) thực thi trong kiến trúcDBMS được chỉ ra trong Hình 2. Các truy vấn được biên dịch, sau đó được gửi tới bộtối ưu hoá truy vấn, nơi có trách nhiệm chỉ ra một cách thực thi có hiệu quả. Bộ tối ưuhoá đưa ra các kế hoạch khác nhau và lựa chọn một kế hoạch có giá ít tốn kém nhất.

Các kế hoạch được xem xét bởi một bộ tối ưu hoá truy vấn quan hệ có thể được hiểubằng việc nhận thức rằng một truy vấn về bản chất giống như một biểu thức đại số σ - π- , và các phép toán còn lại được thực hiện trên kết quả của biểu thức σ - π - .

Biên dịch, Tối ưu và Thực hiện truy vấn

Bộ tối ưu thương mại hóa: Các bộ tối ưu hiện tại của các RDBMS chứa các gói Phầnmềm cực kỳ phức tạp, nhiều chi tiết tỉ mỉ, và họ nói rằng phải mất 40 tới 50 năm công(man-years) để nỗ lực phát triển.

Việc tối ưu hoá giống như một biểu thức đại số quan hệ bao gồm hai bước cơ bản:

• Liệt kê các kế hoạch cho biểu thức này. Điển Hình , bộ tối ưu xem xét một tậpcon nào đó của tất cả các kế hoạch có thể vì số lượng các kế hoạch có thể là rấtlớn.

• Định giá cho mỗi kế hoạch đã liệt kê và lựa chọn một kế hoạch có giá thấpnhất.

324/470

Các kế hoạch đánh giá truy vấn

Một kế hoạch đánh giá truy vấn (hay gọi đơn giản là kế hoạch) được biểu diễn dướidạng Hình cây các phép đại số quan hệ, cùng với chú thích bổ sung ở mỗi nút chỉ ra cácphương thức truy cập đối với mỗi bảng và phương thức thực hiện sử dụng với mỗi phéptoán quan hệ.

Xem xét truy vấn SQL sau:

SELECT S.sname FROM Reserves R, Sailors S WHERE R.sid =S.sid AND R.bid = 100 AND S.rating > 5

Truy vấn này có thể được biểu diễn trong đại số quan hệ như sau:

π sname(σ bid=100 ∧ rating>5(Reserves sid=sid Sailors))

Biểu thức này được chỉ ra dưới dạng Hình cây trong Hình 3. Biểu thức đại số này đượcsử dụng là một thành Phần để đánh giá truy vấn- đầu tiên chúng ta thực hiện kết nối tựnhiên giữa Reserves và Sailors, sau đó thực hiện phép chọn và cuối cùng là thực hiệnphép chiếu lấy ra trường sname.

Truy vấn được biểu diễn bằng đại số quan hệ dưới dạng Hình cây

325/470

Kế hoạch đánh giá cho một truy vấn ví dụ

Để có được một kế hoạch đánh giá đầy đủ, chúng ta phải quyết định việc thực hiện trênmỗi phép toán đại số quan hệ liên quan. Ví dụ, chúng ta có thể sử dụng liên kết lặp lồngnhau đơn giản trong đó Reserves là bảng phía ngoài và áp dụng phép chọn và phép chiếutới mỗi bộ giá trị trong kết quả của phép nối này; kết quả của phép nối trước khi thựchiện chọn và chiếu không bao giờ được lưu trữ lại toàn bộ. Kế hoạch đánh giá truy vấnnày được chỉ ra trong Hình 4.

Trong Hình vẽ kế hoạch đánh giá truy vấn, chúng ta thống nhất rằng bảng phía ngoài làmột nút con phía trái của phép toán liên kết. Chúng ta sẽ sử dụng thống nhất nguyên tắcnày từ đây trở về sau.

Truy vấn đa-toán-tử: Truyền liên tục

Khi một truy vấn sử dụng nhiều toán tử, kết quả của toán tử này được truyền liên tục(pipeline) tới toán tử khác mà không tạo ra một bảng phụ để lưu trữ kết quả tạm thời.Kế hoạch trong Hình 4 cho thấy đầu ra của phép nối giữa Sailors và Reserves được đưavào phép chọn và phép chiếu theo sau.

Thực hiện liên hoàn như vậy làm tiết kiệm giá thành của việc viết ra kết quả trung gianvà đọc trở lại nó, giá thành tiết kiệm được này thực tế rất đáng kể. Nếu đầu ra của mộtphép toán được lưu trữ trong bảng phụ phục vụ quá trình xử lý phép toán tiếp theo,chúng ta nói rằng các bộ giá trị này được hiện thực hoá.

Giá thành của thực hiện theo kiểu truyền liên tục thấp hơn so với kiểu hiện thực hoá vàđược thực hiện bất cứ khi nào nếu thuật toán của toán tử này cho phép.

Có rất nhiều cơ hội dành cho kiểu thực hiện truyền liên tục đối với những kế hoạch truyvấn điển Hình , thậm chí những kế hoạch đơn giản chỉ bao gồm các phép chọn. Xem xétmột truy vấn chọn trong đó chỉ một Phần của điều kiện chọn phù hợp với một chỉ mụcnào đó. Chúng ta giả sử truy vấn có hai điều kiện chọn: Điều kiện đầu tiên là điều kiệnchính, và thứ hai là điều kiện còn lại. Chúng ta có thể đánh giá truy vấn này bằng việc

326/470

áp dụng điều kiện chính và viết kết quả này lên một bảng tạm, sau đó áp dụng điều kiệncòn lại lên bảng tạm này. Ngược lại, sử dụng việc truyền liên tục sẽ áp dụng điều kiệnthứ hai lên mỗi bộ giá trị của tập kết qủa của điều kiện thứ nhất và thêm những bộ giá trịthoả mãn vào kết quả cuối cùng. Khi bảng đầu vào chịu tác động của toán tử một toánhạng (ví dụ, phép chọn hoặc phép chiếu) và thực hiện truyền liên tục lên nó, chúng tagọi phép toán này được thực hiện theo kiểu on-the-fly.

Sau đây là một ví dụ thường gặp, xem xét một kết nối có dạng (A B) C, Hình 5chỉ ra dạng cây của kết nối này.

Cây truy vấn minh hoạ việc thực hiện truyền liên tục

Cả hai liên kết có thể được thực hiện bằng việc sử dụng một số phiên bản của các phéplặp lồng nhau liên kết. Việc thực hiện được bắt đầu từ nút gốc, và nút liên kết giữa A vàB sẽ đưa ra các bộ giá trị kết quả của phép nối này khi nút cha yêu cầu. Khi nút gốc cómột trang nào đó chứa các bộ giá trị từ phía nút con bên trái của nó (bảng phía ngoài),nó sẽ thực hiện nối với quan hệ phía trong và lấy ra những bộ giá trị phù hợp (sử dụngchỉ mục hoặc quét); trang hiện tại chứa các bộ giá trị của nút con bên trái sau đó sẽ bịloại bỏ. Việc này được thực hiện lặp đi lặp lại với các trang tiếp theo. Thực hiện theokiểu truyền liên tục có hiệu quả lớn, nó không viết kết quả của phép nối trung gian rafile tạm bởi vì kết quả được đưa ra, xử lý và loại bỏ cùng đồng thời.

Giao diện lập trình con chạy

Kế hoạch đánh giá truy vấn được biểu diễn bằng một cây các phép toán quan hệ, cácphép toán này được thực hiện theo thứ tự. Mối phép toán có một hoặc nhiều đầu vào vàmột đầu ra, đó là những nút trong cây.

Để đơn giản cho việc phối hợp thực hiện một kế hoạch, các phép toán quan hệ được biểudiễn trong các nút của cây thường hỗ trợ một giao diện lập trình con chạy thống nhất,ẩn đi những thực hiện chi tiết bên trong mỗi phép toán. Giao diện lập trình con chạybao gồm các hàm open, get_next, và close. Hàm open khởi động trạng thái của con chạybằng việc định vị các bộ đệm cho các đầu vào và đầu ra của nó. Phần mã chương trìnhcủa chức năng get_next được gọi là hàm get_next trên mỗi nút đầu vào để xử lý các bộgiá trị đầu vào. Các bộ giá trị kết quả của quá trình xử lý được đặt trong bộ đệm đầu racủa mỗi phép toán, và trạng thái của mỗi iterator được cập nhật để biết có bao nhiêu đầu

327/470

vào đã được xử lý. Khi tất cả các bộ giá trị đầu ra đã được xử lý thông qua việc gọi lặpđi lặp lại get_next, hàm close được gọi để đóng con chạy.

Giao diện lập trình con chạy hỗ trợ việc xử lý truyền liên tục một cách tự nhiên; việctruyền liên tục hay hiện thực hoá các bộ giá trị đầu vào được gói trong đoạn mã chươngtrình đặc trưng của phép toán để xử lý các bộ giá trị đầu vào. Nếu thuật toán này thực thimỗi phép toán cho phép các bộ giá trị đầu vào được xử lý hoàn toàn sau khi chúng đượcnhận, những bộ giá trị đầu vào không phải là hiện thực hoá và việc đánh giá chúng làtruyền liên tục. Nếu thuật toán này kiểm tra cùng các giá trị đầu vào một vài lần, chúnglà hiện thực hoá.

Giống như những chi tiết của việc thực thi các phép toán, quyết định này được ẩn đibởi các giao diện lập trình con chạy của mỗi phép toán. Giao diện lập trình con chạycũng được sử dụng để đóng gói các phương thức truy cập như các chỉ mục B+trees vàhash-based. Nhìn bề ngoài, các phương thức truy cập có thể được nhìn thấy như là cácphép toán xử lý một chuỗi các bộ giá trị đầu vào. Trong trường hợp này, hàm open cóthể được sử dụng để gán những điều kiện lựa chọn đường dẫn truy cập.

Các kế hoạch khác: Một ví dụ dẫn dắt

Xem xét ví dụ truy vấn trong Phần 4. Giả sử chúng ta xem xét giá thành của kế hoạchtrong Hình 4. Chúng ta bỏ qua giá thành của việc viết ra kết quả cuối cùng vì điều nàylà Phần chung của tất cả các thuật toán, và nó không ảnh hưởng tới giá thành của cácPhần liên quan khác. Giá của phép kết nối là 1000+1000*500= 501,000 trang I/Os. Cácphép chọn và phép chiếu được thực hiện là on-the-fly và không có I/Os bổ sung. Vì thế,tổng giá thành của kế hoạch này sẽ là 501,000 trang I/Os. Kế hoạch này được thừa nhậnlà ngờ nghệch; tuy nhiên, nó sẽ là ngờ nghệch hơn nữa nếu phép nối được đối xử nhưphép nhân-chéo đi theo một phép chọn nào đó.

Bây giờ, chúng ta xem xét một số kế hoạch khác cho việc đánh giá truy vấn này. Mỗi kếhoạch sẽ có những cải tiến so với kế hoạch ban đầu và giới thiệu một vài ý tưởng tối ưuhoá ở Phần còn lại của chương này.

Các phép chọn được đẩy xuống

Phép nối là phép toán quan hệ có giá thành đắt, và một ý kiến hay ở đây là giảm càngnhiều càng tốt kích thước của các bảng tham gia kết nối. Một cách tiếp cận sớm với cácphép chọn là: nếu có một phép chọn nào đó xuất hiện sau một phép nối thì tốt nhất là cố“đẩy” phép chọn lên đằng trước phép nối. Ví dụ, phép chọn với bid=100 chỉ bao gồmcác thuộc tính của Reserves và có thể áp dụng trên Reserves trước khi thực hiện nối.Tương tự, phép chọn với rating>5 chỉ gồm các thuộc tính của Sailors và có thể áp dụngtrên Sailor trước phép nối. Hãy cùng chúng tôi giả sử rằng, các phép chọn được thực thiđơn giản sử dụng việc quét file, kết quả của mỗi phép chọn được viết lên một bảng tạm

328/470

trên đĩa, và vì thế các bảng tạm này được nối sử dụng một phép kết nối sắp-xếp-trộn.Kết quả của kế hoạch đánh giá truy vấn được chỉ ra trong Hình 6.

Hãy cùng chúng tôi giả sử rằng ở đây có năm trang đệm đang sẵn sàng và chúng ta cầnước lượng giá thành của kế hoạch này. (Trên thực tế, có nhiều trang đệm có thể đang sẵnsàng. Chúng ta chọn số lượng nhỏ này đơn giản chỉ để minh hoạ ví dụ này). Giá thànhcủa việc áp dụng điều kiện chọn bid=100 cho Reserves là chi phí của việc quét Reserves(1000 trang) cộng với chi phí để viết kết quả lên một bảng tạm, gọi là T1.

Phương án 2: Kế hoạch đánh giá truy vấn

(Ghi nhớ rằng giá của việc viết kết quả tạm thời lên bảng phụ không thể được bỏ qua-chúng ta chỉ có thể bỏ qua giá của viết ra kết quả cuối cùng của truy vấn vì nó là Phầnchung của mọi kế hoạch). Để ước lượng kích thước của t1, chúng ta yêu cầu bổ sungthêm thông tin, nếu chúng ta giả sử rằng số lượng người phục vụ (thuỷ thủ) trên một tàunào đó là 1, chỉ có một bộ giá trị xuất hiện trong kết quả. Thêm nữa, nếu chúng ta biếtrằng có 100 tàu, chúng ta có thể giả sử rằng số lượng người phục vụ dàn ra trên tất cảcác tàu và ước lượng số trang của T1 là 10. Cụ thể, giả sử rằng số lượng các trang trongT1 thực sự là 10.

Chi phí của việc thực hiện truy vấn rating>5 trên Sailors là chi phí của việc quét bảngSailors (500 trang) cộng với chi phí của việc viết kết quả ra một bảng tạm, giả sử T2.Nếu chúng ta giả sử rằng ratings được phân bố trong khoảng từ 1 đến 10, chúng ta cóthể ước lượng được kích thước của T2 là 250 trang.

Để làm một kết nối sắp-xếp-trộn giữa T1 và T2, hãy cùng chúng tôi giả sử rằng hai bảngnày đã được sắp xếp và sau đó đã được trộn. Vì năm trang bộ đệm đã ở chế độ sẵn sàng,chúng ta có thể sắp xếp T1 (có 10 trang) trong hai pha. Hai pha này thực hiện 5 trangmỗi lần và kết quả xuất ra pha thứ nhất và sau đó thực hiện trộn trong pha thứ hai. Trongmỗi pha, chúng ta đọc và viết 10 trangs; ví thế, giá của sắp xếp T1 là 2*2*10=40 trang

329/470

I/Os. Chúng ta cần bốn pha để sắp xếp T2 nơi có 250 trang. Giá là 2*4*250=2000 trangI/Os. Để trộn các phiên bản đã được sắp của T1 và T2, chúng ta cần quét những bảngnày, và giá của bước này là 10+250=260. Phép chiếu cuối cùng được thực hiện theo kiểuon-the-fly, và như đã nói ở trên chúng ta bỏ qua giá của việc viết ra kết quả cuối cùng.

Tổng chi phí của kế hoạch chỉ ra trong Hình 6 là tổng chi phí của các phép chọn(1000+10+500+250=1760) và chi phí của phép nối là (40+2000+260 = 2300), do đó có4060 trang I/Os.

Phép nối sắp-xếp-trộn là một trong số một vài các phương pháp nối. Chúng ta có thểgiảm giá của kế hoạch này bằng việc chọn một phương pháp nối khác. Như một lựachọn, giả sử rằng chúng ta sử dụng kết nối lặp lồng nhau trên khối thay vì kết nối sắp-xếp-trộn. Sử dụng T1 như là bảng phía ngoài, với mỗi khối của T1 là ba-trang, chúng taquét toàn bộ T2; do đó chúng ta quét T2 bốn lần. Vì thế, giá của phép nối là giá của việcquét T1 (10) cộng với giá của việc quét T2 (4*250=1000). Giá của kế hoạch này bây giờlà 1760+1010=2770 trang I/Os.

Một cải tiến tiếp theo là đẩy phép chiếu xuống, giống như chúng ta đã đẩy các phép chọnxuống dưới phép nối. Quan sát thấy rằng chỉ có thuộc tính sid trong T1 và thuộc tínhsid và sname trong T2 được yêu cầu. Vì chúng ta quét Reserves và Sailors để thực hiệncác phép chọn, nên chúng ta có thể loại đi những cột không mong muốn. Phép chiếuon-the-fly này giảm đi kích thước của bảng tạm T1 và T2. Việc giảm kích thước của T1là đáng kể vì chỉ có một trường kiểu integer cần giữ lại. Thực tế là bây giờ T1 đủ trongba trang đệm, và chúng ta có thể thực hiện một kết nối lặp lồng nhau trên khối cùng vớiviệc quét bảng T2. Chi phí của bước kết nối giảm xuống dưới 250 trang I/Os, và tổngchi phí của kế hoạch này giảm xuống khoảng 2000 I/Os.

Sử dụng chỉ mục

330/470

Một kế hoạch đánh giá truy vấn sử dụng các chỉ mục

Nếu các chỉ mục đã được thiết lập và đang sẵn sàng trên các bảng Reserves và Sailors,thì các kế hoạch đánh giá truy vấn sẽ tốt hơn nữa. Ví dụ, giả sử rằng chúng ta có chỉ mụcbăm tĩnh phân cụm trên trường bid của Reserves và chỉ mục băm khác trên trường sidcủa Sailors. Chúng ta có thể sử dụng kế hoạch đánh giá truy vấn trong Hình 7.

Phép chọn bid=100 được thực hiện trên Reserves bằng việc sử dụng một chỉ mục bămtrên bid để truy cập chỉ những bộ giá trị phù hợp. Như ví dụ trước, nếu chúng ta biếtrằng có 100 tàu và người phục vụ được dải ra trên tất cả các tàu, chúng ta có thể ướclượng được số lượng các bộ giá trị được chọn là 100,000/100=1000. Vì chỉ mục trên bidlà phân cụm, nên có 1000 bộ giá trị xuất hiện liên tiếp trong cùng một bộ đệm; vì thế giásẽ là 10 trang I/Os.

Với mỗi bộ giá trị được chọn, chúng ta truy cập đến các bộ giá trị thoả mãn của Sailorssử dụng một chỉ mục băm trên trường sid; các bộ giá trị trong Reserves được lựa chọnkhông được hiện thực hoá và kết nối này được thực hiện theo kiểu truyền liên tục. Vớimỗi bộ giá trị trong kết qủa của phép kết nối, chúng ta thực hiện việc lọc với rating>5và phép chiếu lấy ra sname theo kiểu on-the-fly. Có một vài điểm quan trọng cần ghinhớ ở đây:

1. Vì kết quả của phép chọn trên Reserves là không hiện thực hoá, nên việc tối ưu hoáphép chiếu đối với các trường cần ở bước sau là không cần thiết (và không được sử dụngtrong kế hoạch chỉ ra trong Hình 7).

2. Trường nối sid là khoá của Sailors. Vì thế, có nhiều nhất một bộ giá trị trong Sailorstương ứng với một bộ giá trị nào đó của Reserves. Chi phí của việc truy cập bộ giá trị

331/470

tương ứng này phụ thuộc vào việc thư mục chỉ mục băm trên cột sid của Sailors có đặtvừa vào bộ nhớ và trên các trang tràn (nếu có). Tuy nhiên, chi phí ở đây không phụthuộc vào việc chỉ mục chỉ mục này có phải là phân cụm không bởi vì có nhiều nhất mộtbộ giá trị của Sailors và những yêu cầu đối với các bộ giá trị của Sailors được thực hiệntheo trật tự ngẫu nhiên của sid (bởi vì các bộ giá trị của Reserves được truy cập theo bidvà vì thế được xem xét theo trật tự ngẫu nhiên của sid). Với mỗi chỉ mục băm, 1.2 trangI/Os (trung bình) là một ước lượng tốt về chi phí cho một truy cập dữ liệu. Giả sử rằngchỉ mục băm trên sid của Sailors được sử dụng trong Alternative(1) cho các cổng vàodữ liệu, 1.2 I/Os là giá để truy cập một bộ giá trị của Sailors phù hợp (và nếu một tronghai Alternative khác được sử dụng, thì giá sẽ là 2.2 I/Os).

3. Chúng ta đã lựa chọn không đẩy phép chọn rating>b lên trên phép nối, có một lý doquan trọng cho quyết định này. Nếu chúng ta thực hiện phép chọn trước phép nối, phépchọn này sẽ bao gồm cả việc quét Sailors, giả sử rằng không có chỉ mục nào đang sẵnsàng trên trường rating của Sailors. Thêm nữa, dù có hay không có một chỉ mục như vậyđang sẵn sàng, thì kết quả của phép chọn này cũng không có chỉ mục trên trường sid (trừkhi chúng ta xây dựng một chỉ mục độc lập như vậy để phục vụ cho những kết nối đằngsau). Việc đẩy các phép chọn lên trước các phép nối là một ý tưởng rất tốt, nhưng điềunày không phải lúc nào cũng đúng. Điển Hình như trong ví dụ này, việc có các chỉ mụchữu ích đang tồn tại là lý do phép chọn không nên được đẩy lên. (Trong những trườnghợp khác, các phép chọn nên được đẩy lên trên phép nối).

Giả sử chúng ta cần ước lượng chi phí của kế hoạch chỉ ra trong Hình 7. Việc chọn cácbộ giá trị của Reserves có giá là 10 I/Os, như chúng tôi đã trình bày phía trên. Có 1000bộ giá trị như vậy, và với mỗi bộ, chi phí của việc tìm bộ giá trị tương ứng trong Sailorstrung bình là 1.2 I/Os. Chi phí của bước này (phép nối) vì thế là 1200 I/Os. Tất cả cácphép chọn còn lại và các phép chiếu được thực hiện theo kiểu on-the-fly. Tổng chi phícủa kế hoạch này là 1210 I/Os.

Như đã lưu ý ở phía trên, kế hoạch này không tận dụng được chỉ mục phân cụm củaSailors. Nó có thể được tinh chỉnh thêm nếu chỉ mục trên trường sid của Sailors làphân cụm. Giả sử chúng ta hiện thực hoá các kết quả của phép chọn với bid=100 trênReserves và sắp xếp các kết quả này trên bảng tạm. Bảng này sẽ chứa 10 trang. Việcchọn các bộ giá trị có giá là 10 trang I/Os (như trước), việc viết kết quả ra bảng tạmcó chi phí là 10 I/Os nữa, và với 5 trang đệm, việc sắp xếp trên bảng tạm này sẽ mất2*2*10=40 I/Os. (Chi phí này sẽ giảm nếu chúng ta đẩy phép chiếu lấy sid lên trên). Cộtsid của các bộ giá trị trong Reserves chỉ yêu cầu 3 trang và có thể được sắp xếp trong bộnhớ với năm trang đệm). Bây giờ, các bộ giá trị Reserves được chọn có thể được truycập theo thứ tự của sid.

Nếu một thuỷ thủ nào đó phục vụ trên một tàu nhiều lần, tất cả các bộ giá trị củaReserves tương ứng được truy cập một cách liên tiếp và tất cả chúng có thể được tìm

332/470

thấy trong một buffer pool. Kế hoạch cải tiến này cũng chứng minh một điều rằng, việcthực hiện theo kiểu truyền liên tục không phải lúc nào cũng là một chiến lược tốt nhất.

Việc kết hợp việc đẩy các phép chọn lên và sử dụng các chỉ mục trong kế hoạch này rấthiệu quả. Nếu các bộ giá trị được chọn trong bảng phía ngoài nối với một bộ giá trị duynhất bên trong, thì phép nối này trở nên rất tầm thường, và những ích lợi của việc thựchiện kế hoạch ngờ nghệch trong Hình 6 thậm chí lại gây ấn tượng. Ví dụ theo sau minhhoạ tình trạng này:

SELECT S.sname FROM Reserves R, Sailors S WHERE R.sid =S.sid AND R.bid = 100 AND S.rating > 5 AND R.day = '8/9/2002'

Kế hoạch đánh giá truy vấn của ví dụ thứ hai

Kết quả của kế hoạch thực hiện truy vấn này được chỉ ra trong Hình 8 sai khác khôngđáng kể so với kế hoạch trong Hình 7. Phép chọn day='8/9/2002' được thực hiện on-the-fly trên kết quả của phép chọn với bid=100.

Giả sử rằng bid và day là khoá của Reserves. (Ghi nhớ rằng giả định này khác với lượcđồ đã trình phía trên trong chương này). Hãy cùng chúng tôi ước lượng chi phí của kếhoạch trong Hình 8. Phép chọn bid=100 có giá là 10 trang I/Os như đã nói ở trên, vàđiều kiện bổ sung day ='8/9/2002' được áp dụng theo kiểu on-the-fly sẽ loại đi tất cả trừ(nhiều nhất) một bộ giá trụi của Reserves. Có nhiều nhất một bộ giá trị của Sailors tươngứng, và nó được truy cập bởi 1.2 I/Os (trung bình). Phép chọn trên rating và sau đó làphép chiếu lấy sname được áp dụng theo kiểu on-the-fly không mất thêm giá thành. Vì

333/470

thế, giá tổng cộng của kế hoạch này trong Hình 8 mất khoảng 11 I/Os. Ngược lại, nếuchúng ta thay đổi kế hoạch ngờ nghệch trình bày trong Hình 6 để thực hiện phép chọntrên day và phép chọn bid=100 thì giá còn lại là 501,000 I/Os.

Bộ tối ưu hoá điển Hình làm gì

Tối ưu hoá truy vấn sử dụng đại số quan hệ có thể tạo ra rất nhiều biểu thức tương đươngứng với một truy vấn. Với mỗi biểu thức như vậy, tất cả các công nghệ thực thi có thểđược áp dụng cho các phép toán quan hệ có liên quan trong biểu thức này, vì thế có thểphát sinh thêm những kế hoạch mới. Bộ tối ưu hoá sẽ ước lượng giá thành phải trả chotừng phương án và chọn một phương án có giá thấp nhất.

Cân nhắc các kế hoạch thay thế

Hai biểu thức đại số trên cùng một tập các bảng đầu vào được gọi là tương đương nếuchúng sinh ra cùng một kết quả trên tất cả các minh hoạ dữ liệu của các bảng đầu vào.Sự tương đương của các biểu thức đại số quan hệ đóng vai trò trung tâm trong việc xácđịnh các kế hoạch thay thế.

Xem xét một truy vấn cơ bản chứa một mệnh đề SELECT, một mệnh đề FROM, và mộtmệnh đề WHERE. Truy vấn này có thể dễ dàng biểu diễn bằng một biểu thức đại số; cáctrường đề cập trong mệnh đề SELECT được chiếu từ kết quả của phép nhân-chéo cácbảng trong mệnh đề FROM sau khi đã áp dụng các phép chọn trong mệnh đề WHERE.Sử dụng sự tương đương có thể giúp chúng ta chuyển biểu thức ban đầu thành một vàibiểu thức tương đương với nó. Cụ thể:

• Các phép chọn và nhân-chéo có thể được kết hợp trong các phép nối.• Các phép nối có thể được sắp xếp lại thứ tự.• Các phép chiếu và phép chọn làm giảm kích thước của đầu vào có thể được đẩy

lên trên các phép nối.

Truy vấn được trình bày trong Phần 5 minh hoạ những điểm trên, việc đẩy phép chọntrong truy vấn này lên trên phép nối đã tạo ra một kế hoạch đánh giá tốt hơn rất nhiều.Chúng tôi trình bày về sự tương đương của các biểu thức đại số quan hệ trong Phần 15.3.

Các kế hoạch sâu-trái

Xem xét một truy vấn có dạng A B C D; đây là phép nối tự nhiên trên bốn bảng.Ba cây đại số quan hệ trong Hình 9 là tương đương nhau. Theo quy ước, cây con bêntrái của nút kết nối là bảng phía ngoài và cây con bên phải là bảng phía trong. Bằng việcthêm vào những chi tiết như các phương thức kết nối tại mỗi nút thì có thể dễ hiểu đểthực hiện một vài kế hoạch đánh giá truy vấn trên những cây này.

334/470

Ba cây kết nối

Hai cây đầu trong Hình 9 là những ví dụ về cây tuyến tính. Trong một cây tuyến tính,có ít nhất một con của phép nối là bảng cơ sở. Cây đầu tiên là ví dụ về cây sâu-trái(left-deep)- con phải của mỗi nút là bảng cơ sở. Cây thứ ba là ví dụ về cây không tuyếntính hay còn gọi là cây rậm rạp (bushy tree).

Các bộ tối ưu hoá thông thường sử dụng cách tiếp cận lập trình động (xem Phần 15.4.2)để tìm kiếm các kế hoạch sâu-trái một cách hiệu quả. Vì thế loại cây thứ hai và thứ bakhông bao giờ được xem xét. Ta thấy cây đầu tiên biểu diễn một kế hoạch trong đó Avà B được nối trước, sau đó kết quả của phép nối này được nối với C, sau đó kết quảnày được tiếp tục nối với D. Có 235 những kế hoạch sâu-trái được tạo ra chỉ do thay đổithứ tự các bảng được kết nối. Nếu một kế hoạch nào đó trong số những kế hoạch này cóphép chọn và phép chiếu có điều kiện thì những điều kiện này được áp dụng sớm nhấtcó thể sẽ cung cấp một lựa chọn về thứ tự kết nối các bảng.

Tất nhiên, quyết định này loại trừ rất nhiều kế hoạch mà chi phí của nó có thể ít hơnchi phí của kế hoạch tốt nhất sử dụng một cây sâu-trái; chúng ta phải chịu một thực tếrằng bộ tối ưu hoá sẽ không bao giờ tìm được những kế hoạch như vậy. Có hai lý do củaquyết định này để tập trung vào các kế hoạch sâu-trái, hoặc những kế hoạch dựa trên cáccây sâu-trái:

1. Khi số lượng các kết nối tăng lên, số lượng các kế hoạch tăng lên nhanh chóng.2. Các cây sâu-trái cho phép chúng ta đưa ra tất cả các kế hoạch theo kiểu truyền

liên tục đầy đủ (fully pipelined); tức là các kế hoạch trong đó tất cả các kết nốiđược đánh giá sử dụng truyền liên tục. (Các bảng bên trong luôn phải đượchiện thực hoá bởi vì chúng ta phải kiểm tra toàn bộ bảng bên trong ứng với mỗigiá trị của bảng bên ngoài. Vì thế, một kế hoạch trong đó một bảng bên trong làkết quả của phép nối bắt buộc chúng ta phải hiện thực hoá kết quả của phép nốiđó.)

Ước lượng chi phí của một kế hoạch

Giá của một kế hoạch là tổng giá của các phép toán bên trong nó. Giá của các phép toánquan hệ riêng lẻ trong một kế hoạch được ước lượng sử dụng thông tin lấy từ danh mụchệ thống, các thuộc tính (ví dụ, kích cỡ, thứ tự sắp xếp) của các bảng đầu vào. Chúng ta

335/470

minh hoạ cách ước lượng chi phí của các kế hoạch toán-tử-duy-nhất (single-operatorr)trong Phần 2 và3, và cách ước lượng giá của các kế hoạch đa-toán-tử (multi-operator)trong Phần 5.

Nếu chúng ta tập trung vào giá của I/O, giá của một kế hoạch nào đó có thể được chialàm ba Phần : (1) đọc các bảng đầu vào (có thể nhiều lần trong trường hợp nối và cácthuật toán sắp xếp), (2) viết lên các bảng tạm, và có thể (3) sắp xếp kết quả cuối cùng(nếu truy vấn cần loại bỏ các giá trị trùng lặp hoặc đầu ra cần được sắp xếp). Phần thứba là chung cho tất cả các kế hoạch (trừ khi kết quả là đầu vào của một thủ tục nào đó),và trong trường hợp kế hoạch được thực hiện theo kiểu truyền liên tục hoàn toàn (fully-pipelined), không yêu cầu bảng tạm nào phải ghi ra.

Vì thế, giá của một kế hoạch truyền liên tục hoàn toàn bị chi phối bởi Phần (1). Giá nàyphụ thuộc Phần lớn vào các đường dẫn truy cập được sử dụng để đọc các bảng đầu vào;tất nhiên, các đường dẫn truy cập được sử dụng lặp đi lặp lại để truy cập các bộ giá trịthoả mãn trong một thuật toán kết nối là đặc biệt quan trọng.

Với những kế hoạch không phải theo kiểu truyền liên tục hoàn toàn, giá của các bảngtạm phải hiện thực hoá là rất đáng kể. Giá của việc hiện thực hoá các kết quả tạm phụthuộc vào kích thước của nó, và kích thước này cũng ảnh hưởng đến các phép toán trongđó các bảng tạm là dữ liệu đầu vào. Số lượng các bộ giá trị trong kết quả của một phépchọn được ước lượng bằng tích của kích thước đầu vào nhân với hệ số giảm do các điềukiện chọn. Số lượng các bộ giá trị trong kết quả của một phép chiếu giống với đầu vàotrong trường hợp sự trùng lặp không được loại bỏ, còn nếu sự trùng lặp bị loại bỏ thì sốlượng các bộ giá trị trong kết quả sẽ ít hơn đầu vào vì nó chứa ít trường hơn.

Kích thước kết quả của một phép nối có thể được ước lượng bằng việc nhân kích thướckết quả lớn nhất, là tích của các kích thước của các bảng đầu vào, với hệ số giảm củađiều kiện kết nối. Hệ số giảm của điều kiện nối columnl = column2 có thể được xấp xỉbằng công thức 1

MAX(NKeys(I1),NKeys(I2)) nếu có các chỉ mục I1 và I2 tương ứng trên column1và column2. Công thức này áp dụng trong trường hợp mỗi giá trị khoá trong chỉ mụcnhỏ hơn, giả sử I1 có một giá trị tương ứng trong chỉ mục khác.

Câu hỏi tổng kết

Trả lời những câu hỏi sau, kết quả có thể được tìm thấy ở các mục liệt kê bên cạnh.

• Metadata là gì? Dữ liệu nào của metadata được lưu trữ trong danh mục hệthống. Trình bày những thông tin lưu trong mỗi quan hệ, mỗi chỉ mục (Phần1).

• Danh mục bản thân nó được lưu như một tập các quan hệ. Giải thích vì sao?(Phần 1)

336/470

• Ba công nghệ nào được sử dụng chung trong các thuật toán đánh giá các phéptoán quan hệ? (Phần 2)

• Đường dẫn truy cập là gì? Khi nào một chỉ mục so sánh được (math) với mộtđiều kiện tìm kiếm? (Phần 2.2)

• Các cách tiếp cận chính để đánh giá các phép chọn là gì? Cụ thể, trình bày vềviệc sử dụng các chỉ mục. (Phần 3.1)

• Các cách tiếp cận chính để đánh giá các phép chiếu là gì? Điều gì làm các phépchiếu trở nên tốn kém? (Phần 3.2)

• Các cách tiếp cận chính để đánh giá các phép nối là gì? Vì sao các phép nốiphải là các phép toán đắt? (Phần 3.3)

• Mục đích của tối ưu hoá truy vấn là gì? Nó có tìm ra kế hoạch tốt nhất không?(Phần 4)

• DBMS biểu diễn một kế hoạch đánh giá truy vấn quan hệ như thế nào? (Phần4.1)

• Đánh giá truyền liên tục là gì? Lợi ích của nó là gì? (Phần 4.2)• Trình bày về giao diện lập trình con chạy của các phép toán và các phương thức

truy cập. Mục đích của nó là gì? (Phần 4.3)• Vì sao chúng ta bàn về sự khác nhau về chi phí giữa các kế hoạch khác nhau

cho một truy vấn. Cung cấp ví dụ minh hoạ ảnh hưởng của việc đẩy các phépchọn lên, các lựa chọn về phương thức kết nối, và lợi ích của các chỉ mục thíchhợp. (Phần 5)

• Vai trò của sự tương đương trong đại số quan hệ đối với tối ưu hoá truy vấn?(Phần 6)

• Các cách biểu diễn kế hoạch khác nhau được bộ tối hoá truy vấn quan hệ điểnHình xem xét là gì? Giải thích về các cách biểu diễn này. (Phần 6.1)

• Giá của các kế hoạch được ước lượng như thế nào? Vai trò của danh mục hệthống là gì? Sự lựa chọn đường dẫn truy cập là gì, và nó ảnh hưởng đến chi phícủa một kế hoạch như thế nào? Vì sao việc ước lượng được kích thước của kếtquả truy vấn lại quan trọng? (Phần 6.2)

Bài tập

Trả lời tóm tắt những câu hỏi sau:

1. Trình bày ba công nghệ phổ biến được sử dụng khi phát triển các thuật toán chocác phép toán quan hệ. Giải thích vì sao ba công nghệ này có thể được sử dụngđể thiết kế thuật toán cho phép chọn, phép chiếu, và phép nối.

2. Đường dẫn truy cập là gì? Khi nào một chỉ mục so sánh được với một đườngdẫn truy cập? Liên kết chính là gì, và vì sao nó quan trọng?

3. Thông tin nào đượca lưu trong các danh mục hệ thống?4. Lợi ích của việc làm cho các danh mục hệ thống là các quan hệ là gì?5. Mục đích của tối ưu hoá truy vấn là gì? Vì sao việc tối ưu hoá lại quan trọng?6. Trình bày về truyền liên tục (pipelining) và những lợi ích của nó?

337/470

7. Cung cấp một truy vấn ví dụ mà kế hoạch thực hiện của nó không thể sử dụngđược cách truyền liên tục.

8. Trình bày về giao diện lập trình con chạy và giải thích những ưu điểm của nó.9. Các thống kê trong cơ sở dữ liệu đóng vao trò gì trong tối ưu hóa truy vấn?

10. Những quyết định thiết kế quan trọng được làm trong bộ tối ưu hoá System Rlà gì?

11. Vì sao bộ tối ưu hoá truy vấn chỉ đề cập đến các cây liên kết sâu-trái? Cung cấpmột ví dụ của một truy vấn và một kế hoạch không được giải quyết do giới hạnnày.

Câu Trả lời với từng câu hỏi như sau:

1. Ba công nghệ phổ biến được sử dụng là chỉ mục hóa, con chạy, và sự phân vùng:

• Chỉ mục hóa: Nếu một phép chọn hoặc điều kiện nối được xác định, nó sửdụng một chỉ mục nào đó để kiểm tra chỉ những bộ giá trị thỏa mãn điều kiệnnày.

• Con chạy: Kiểm tra tất cả các bộ giá trị trong một bảng đầu vào nào đó, bộ giátrị này sau bộ giá trị kia. Nếu chúng ta chỉ cần một vài trường của mỗi bộ giá trịvà ở đây có một chỉ mục chứa tất cả các trường này, thì thay vì kiểm tra các bộgiá trị dữ liệu, chúng ta chỉ cần quét tất cả các cổng vào dữ liệu chỉ mục.

• Sự phân vùng: Bằng việc phân chia các bộ giá trị trên một khóa sắp xếp nàođó, chúng ta có thể phân tích một thao tác nào đó thành một tập các thao táctrên các vùng khác nhau với chi phí thấp hơn. Sắp xếp hoặc băm là hai côngnghệ phân vùng được sử dụng phổ biến.

Chúng có thể được sử dụng để thiết kế các thuật toán cho phép chọn, phép chiếu và cácphép nối, như sau:

• Phép chọn: Với một phép chọn nào đó có nhiều hơn một bộ giá trị thỏa mãn(thông thường, nhỏ hơn 5%), sử dụng chỉ mục như B+trees sẽ rất hữu ích. Cáctruy vấn này thường là các truy vấn miền. Nó cho phép chúng ta không chỉ tìmđược bộ giá trị thỏa mãn đầu tiên nhanh nhất, mà còn có thể tìm được những bộgiá trị khác sớm hơn (đặc biệt trong trường hợp chỉ mục này được phân cụm).Với một điều kiện chọn nào đó cùng với một truy vấn bằng mà chỉ có rất ít(thường là 1) bộ giá trị phù hợp, việc phân vùng sử dụng chỉ mục băm thườnglà thích hợp. Nó cho phép chúng ta tìm ra một bộ giá trị chính xác mà chúng tađang tìm kiếm chỉ với chi phí rất thấp (chỉ một hoặc hai I/Os).

• Phép chiếu: Phép chiếu yêu cầu chúng ta loại bỏ một số trường hiện tại củađầu vào, điều này có thể dẫn đến sự trùng lặp trong tập kết quả. Nếu chúng takhông cần loại bỏ sự trùng lặp này, thì công nghệ con chạy có thể quản lý hiệuquả vấn đề này. Ngược lại, nếu chúng ta cần loại bỏ sự trùng lặp, việc phânvùng dữ liệu và áp dụng khóa sắp xếp sẽ tốt hơn.

338/470

Trong trường hợp có nhiều chỉ mục thích hợp đang sẵn sàng, thì chúng ta có thể có đượcnhững kế hoạch rẻ hơn cho việc sắp xếp các bộ giá trị trong quá trình loại bỏ sự trùnglặp vì tất cả dữ liệu có thể được sắp xếp trên chỉ mục này (trong trường hợp này chúngta chỉ đơn giản so sánh các cổng vào dữ liệu cạnh nhau để kiểm tra sự trùng lặp).

• Phép nối: Đây là phép thao tác có chi phí đắt đỏ nhất, có thể kết hợp sử dụngcả ba công nghệ. Phép nối thường có nhiều phép chọn và các Phần tử đượcchiếu ra, vì thế việc có các chỉ mục thích hợp và các phân vùng dữ liệu như trênlà rất quan trọng. Bất cứ khi nào có thể, các phép chọn độc lập và các phépchiếu được áp dụng cho hai quan hệ nên được thực thi trước khi thực hiện phépnối để giảm kích thước của bảng trung gian.

Ví dụ, xem xét phép nối hai quan hệ có 100,000 bộ giá trị ở mỗi quan hệ và chỉ có 5%các bộ giá trị thỏa mãn trong mỗi bảng. Việc thực hiện phép nối trước khi áp dụng cácđiều kiện chọn sẽ dẫn đến kích thước bảng trung gian rất lớn và sau đó lại phải tìm kiếmcác phép chọn phù hợp. Cách làm khác là, chúng ta áp dụng các phép chọn trước. Sauđó chúng ta có thể thực hiện một phép nối của 5000 bộ giá trị thỏa mãn nhận được saukhi áp dụng phép chọn trên mỗi bảng, thì việc tìm kiếm và quản lý các bộ giá trị này sẽnhanh hơn đáng kể.

2. Đường truy cập là một đường để truy cập các bộ giá trị trong một bảng nào đó, nóyêu cầu một thao tác quét file hoặc một chỉ mục nào đó cộng với một điều kiện chọn phùhợp. Một chỉ mục phù hợp với một điều kiện chọn nếu chỉ mục này có thể được sử dụngđể truy cập chỉ các bộ giá trị thỏa mãn điều kiện này. Một chỉ mục có thể phù hợp vớimột số các phép liên kết trong một điều kiện chọn nào đó, có thể nó không phù hợp vớitoàn bộ điều kiện và chúng ta coi phép liên kết mà chỉ mục này phù hợp là các liên kếtchính trong phép chiếu này. Các liên kết chính rất quan trọng vì chúng cho phép chúngta nhanh chóng bỏ qua các thông tin mà chúng ta không cần đến và chỉ tập trung vàoviệc tìm kiếm/ sắp xếp những dữ liệu liên quan nhiều nhất đến những điều kiện chọnnày.

3. Thông tin về các quan hệ, chỉ mục, và các khung nhìn được lưu trữ trong các danhmục hệ thống. Nó bao gồm các tên file, kích thước file, và cấu trúc file, tên thuộc tínhvà kiểu dữ liệu, danh sách các khóa, và các ràng buộc.

Các thông tin thống kê được lưu trữ phổ biến nhất bao gồm:

1. Lực lượng – Số lượng các bộ giá trị trong mỗi quan hệ.2. Kích thước – số lượng các trang trong mỗi quan hệ.3. Lực lượng chỉ mục - số lượng các giá trị khóa phân biệt cho từng chỉ mục.4. Kích thước chỉ mục - số lượng các trang của từng chỉ mục (hoặc số lượng các

trang trái)5. Chiều cao chỉ mục - số lượng các mức không-lá của từng chỉ mục cây.

339/470

6. Miền chỉ mục - giá trị khóa hiện tại nhỏ nhất và lớn nhất của từng chỉ mục.

4. Có một số ưu điểm của việc lưu trữ các danh mục hệ thống như là các quan hệ. Cácdanh mục hệ thống có tất cả các ưu điểm của các quan hệ về mặt thực thi và quản lý: lưutrữ thông tin hiệu quả và các khả năng truy vấn phong phú. Lựa chọn cái gì được lưu trữtrong các danh mục hệ thống là công việc của người xây dựng DBMS.

5. Mục đích của tối ưu hóa truy vấn là tránh các kế hoạch tồi nhất và tìm ra được một kếhoạch đủ tốt. Mục đích của nó không phải là tìm ra được một kế hoạch tốt nhất. Sự khácnhau trong chi phí của kế hoạch tốt và kế hoạch tồi là rất lớn: kế hoạch truy vấn tốt cóthể đánh giá truy vấn theo thời gian tính bằng giây, trong khi đó kế hoạch tồi có thể phảimất nhiều ngày!

6. Truyền liên tục (Pipelining) cho phép chúng ta tránh được việc tạo và đọc các quanhệ tạm; giảm được các chi phí I/Os.

7. Các truy vấn rậm rạp (bushy) không thể tận dụng được các ưu điểm của việc truyềnliên tục vì những giới hạn của bộ đệm và tài nguyên của CPU. Xem xét một kế hoạchtrong đó chúng ta phải thực hiện một phép chọn trên hai quan hệ, sau đó là phép nối.Chúng ta không thể luôn sử dụng được việc truyền liên tục trong chiến lược này, vì kếtquả của phép chọn đầu tiên có thể không đặt vừa bộ nhớ, và chúng ta phải đợi phép chọnthứ hai hoàn thành trước khi chúng ta có thể bắt đầu thực hiện phép nối.

8. Giao diện con chạy cho một thao tác nào đó bao gồm các hàm open, get next, và close;nó ẩn đi những chi tiết về cách thức thực thi, và cho phép chúng ta xem tất cả các núttrong một kế hoạch truy vấn.

9. Bộ tối ưu hóa truy vấn sử dụng các thống kê để tăng khả năng chọn được một kếhoạch thực thi truy vấn tốt nhất. Các thống kê này được sử dụng để tính toán các nhân tốgiảm trong đó các nhân tố này bị ảnh hưởng bởi các chỉ mục và các đầu vào khác nhau.

10. Một số các quyết định thiết kế quan trọng trong bộ tối ưu hóa System R là:

1. Sử dụng các thống kê về một minh họa cơ sở dữ liệu nào đó để tính toán chi phícủa một kế hoạch đánh giá truy vấn nào đó.

2. Một quyết định để xem xét chỉ những kế hoạch có các phép nối nhị phân, trongđó quan hệ phía trong là quan hệ cơ sở. Điều này giúp làm giảm số lượng cáckế hoạch khác nhau phải xem xét.

3. Một quyết định để tập trung cho việc tối ưu hóa trên lớp các truy vấn SQLkhông có sự lồng nhau và đối xử với các truy vấn lồng nhau theo một cách đặcbiệt.

4. Một quyết định để thực hiện loại bỏ các giá trị trùng lặp của các phép chiếu(loại bỏ là bước cuối cùng trong đánh giá truy vấn khi truy vấn này có mệnh đềDISTINCT).

340/470

5. Mô Hình chi phí bao gồm cả chi phí của CPU và chi phí I/O.

11. Có hai lý do chính để quyết định chỉ tập trung vào các kế hoạch sâu-trái là:

1. Khi số lượng các phép nối tăng lên, số lượng các kế hoạch khác nhau cũng tănglên rất nhanh chóng và việc tỉa không gian của các kế hoạch khác nhau trở nêncần thiết.

2. Cây sâu-trái cho phép chúng ta đưa ra tất cả các kế hoạch chỉ có truyền liên tục;tức là, các kế hoạch trong đó tất cả các phép nối được đánh giá sử dụng việctruyền liên tục.

Xem xét phép nối A B C D. Kế hoạch (A B) (C D) sẽ không bao giờ đượcxem xét vì nó là một cây rậm rạp.

Xem xét quan hệ R(a, b, c, d) chứa 5,000,000 bản ghi, trong đó mỗi trang dữ liệu củaquan hệ này lưu được 10 bản ghi. R được tổ chức như một file đã sắp xếp bởi các chỉmục phụ. Giả sử rằng R.a là một khoá dự tuyển của R, với các giá trị nằm trong dải từ 0đến 4,999,999 và R được sắp xếp theo thứ tự của R.a. Với mỗi truy vấn đại số quan hệtheo sau, cách tiếp cận nào trong ba cách sau là rẻ nhất:

• Truy cập file được sắp của R một cách trực tiếp.• Sử dụng một chỉ mục B+ tree (clustered) trên thuộc tính R.a.• Sử dụng một chỉ mục băm tuyến tính trên thuộc tính R.a.• σa<50,000(R)• σa=50,000(R)• σa >50,000 ∧ a<50,010(R)• σ a ≠50,000(R)

Dành cho độc giả

Với mỗi truy vấn SQL sau, với mỗi quan hệ liên quan, liệt kê các thuộc tính phảiđược kiểm tra để đưa ra câu Trả lời . Tất cả các truy vấn liên quan đến các quan hệsau: Emp(eid: integer, did: integer, sal: integer, hobby:char(20)) Dept((did: integer, dname: char(20), floor:integer, budget: real) 1. SELECT * FROM Emp 2. SELECT *FROM Emp, Dept 3. SELECT * FROM Emp E, Dept D WHERE E.did= D.did 4. SELECT E.eid, D.dname FROM Emp E, Dept D WHEREE.did = D.did

Câu Trả lời với mỗi câu hỏi như sau: 1. E.eid, E.did, E.sal, E.hobby2. E.eid, E.did, E.sal, E.hobby, D.did, D.dname, D.floor,D.budget 3. E.eid, E.did, E.sal, E.hobby, D.did, D.dname,D.floor, D.budget 4. E.eid, D.dname, E.did, D.did

341/470

Xem xét lược đồ quan hệ Sailors sau: Sailors(sid: integer, sname:string, rating: integer, age: real) Với mỗi chỉ mục sau, liệt kê chỉmục nào phù hợp với các điều kiện chọn cung cấp. Nếu phù hợp, hãy liệt kê những kếtnối chính?

1. Một chỉ mục B+tree trên khoá tìm kiếm < Sailors.sid >.• σSailors.sid<50,000(Sailors)• σSailors.sid=50,000(Sailors)• Một chỉ mục băm trên khoá tìm kiếm < Sailors.sid >.• σSailors.sid<50,000(Sailors)• σSailors.sid=50,000(Sailors)• Một chỉ mục B+tree trên khoá tìm kiếm < Sailors.sid, Sailors.age >.

1. σ Sailors.sid<50,000 ∧ Sailors.age=2l(Sailors)2. σ Sailors.sid=50,000 ∧ Sailors.age>2l(Sailors)3. σ Sailors.sid=50,000(Sailors)4. σ Sailors.age=2l(Sailors)

• Một chỉ mục băm trên khoá tìm kiếm < Sailors.sid, Sailors.age >.1. σSailors.sid=50,000∧Sailors.age=21(Sailors)2. σSailors.sid=50,000 ∧ Sailors.age>21(Sailors)

Dành cho độc giả

Xem xét lại lược đồ quan hệ với quan hệ Sailors sau:

Sailors(sid: integer, sname: string, rating: integer, age:real)

Giả sử rằng mỗi bộ giá trị của Sailors có chiều dài là 50 bytes, do đó mỗi trang có thểnắm giữ 80 bộ giá trị Sailors, và do đó chúng ta có 500 trang cho những bộ giá trị này.Với mỗi điều kiện chọn sau, ước lượng số lượng các trang đã truy cập.

1. Giả sử rằng chúng ta có một chỉ mục B+ tree là T trên khoá tìm kiếm <Sailors.sid>,và giả sử rằng IHeight(T)=4, INPages(T) = 50, Low(T) = 1, và High(T)=100,000.

(a) σ Sailors.sid<50,000(Sailors)

(b) σ Sailors.sid=50,000(Sailors)

2. Giả sử rằng chúng ta có một chỉ mục băm là T trên khoá tìm kiếm < Sailors.sid >, vàgiả sử rằng IHeight(T)=2, INPages(T)=50, Low(T)=1, và High(T)=100,000.

(a) σ Sailors.sid<50,000(Sailors)

342/470

(b) σ Sailors.sid=50,000(Sailors)

Câu Trả lời với mỗi câu hỏi như sau:

1. (a) Giả sử việc phân bố là đồng nhất, có khoảng một nửa của 40000 bản ghi sẽ thỏamãn điều kiện chọn. Tổng chi phí là chi phí của việc tìm ra được nút đầu tiên (4 I/Os)cộng với chi phí của việc truy cập các bộ giá trị thỏa mãn. Nếu chỉ mục này là phân cụm,thì tổng chi phí là 4 + 250 I/O’s = 254 I/O’s. Nếu chỉ mục này không phân cụm, thì chiphí của việc truy cập mỗi bộ giá trị thỏa mãn sẽ là 20,000 I/O’s (một I/O cho mỗi bộ giátrị phù hợp), dẫn đến tổng chi phí là 20,004 I/O’s. Nếu chỉ mục này không phân cụm,thì thực hiện thao tác quét file dường như là phương pháp thích hợp nhất với chi phí là500 I/O’s.

(b) Vì sid là khóa chính của quan hệ này nên chúng ta hy vọng chỉ có một bộ giá trị phùhợp với chỉ mục băm này, vì thế chi phí là chiều cao của cây (4 I/O’s) cộng với chi phícủa việc đọc một trang chứa bộ giá trị thỏa mãn (1 I/O), tổng cộng là 5 I/Os.

2. (a) Vì một chỉ mục băm nào đó trên sid không thể giúp chúng ta trong các truy vấnmiền, nên chỉ mục này là vô ích, và vì thế chúng ta phải thực hiện thao tác quét file vớichi phí là 500 trang I/Os (chi phí của việc đọc toàn bộ quan hệ).

(b) Vì sid là khóa chính của quan hệ này, nên chúng ta hy vọng chỉ có một bộ giá trị phùhợp với chỉ mục băm này, vì thế chi phí chỉ là chiều cao của cây (2 I/Os) cộng với chiphí của việc đọc trang chứa bộ giá trị thỏa mãn này (1 I/O), tổng cộng là 3 I/Os.

Xem xét hai phương thức kết nối trình bày trong Phần 3.3. Giả sử rằng chúng ta kết nốihai quan hệ R và S, và danh mục hệ thống chứa những thống kê thích hợp về R và S.Viết công thức cho việc ước lượng giá của index nested loops join và sort-merge join,xem xét trong cả trường hợp chỉ mục B+tree và chỉ mục băm. (Với chỉ mục băm, bạn cóthể giả sử rằng bạn có thể truy cập đến trang chỉ mục chứa rid của bộ giá trị tương ứnglà 1.2 I/Os(trung bình)).

Dành cho độc giả.

Ghi nhớ: Những Bài tập bổ sung đối với những vấn đề trình bày trong chương này cóthể tìm trong Phần Bài tập tại Chương 14 và 15.

Tài liệu tham khảo

Xem Phần tham khảo của Chương 14 và 15.

343/470

Tổng quan về quản lý giao dịchTrong chương này, chúng ta tìm hiểu xung quanh khái niệm giao dịch, là nền móngcho việc thực thi tương tranh và khôi phục lại cơ sở dữ liệu khi xảy ra sự cố trong mộtDBMS nào đó. Một giao dịch được định nghĩa là một thực thi của chương trình ngườidùng trong một DBMS, và nó khác với một thực thi của một chương trình bên ngoàiDBMS (ví dụ, một chương trình C trên Unix). (Thực thi cùng một chương trình nhiềulần sẽ đưa ra nhiều giao dịch).

Vì những lý do thực thi, DBMS phải xen các thao tác của một vài giao dịch. (Chúng tôitrình bày chi tiết về động cơ của việc xen vào này trong Phần 3.1). Tuy nhiên, việc xenvào này được làm một cách cẩn thận để đảm bảo rằng kết quả của việc thực thi đồngthời các giao dịch vẫn tương đương với kết quả khi nó được thực thi một cách độc lập.DBMS quản lý các thực thi tương tranh như thế nào là một công việc quan trọng củaquản lý giao dịch và là chủ đề của điều khiển tương tranh. Một vấn đề liên quan chặtchẽ đến điều khiển tương tranh là cách DBMS quản lý các giao dịch chưa thành công,hoặc các giao dịch bị hủy trước khi nó thành công. DBMS đảm bảo rằng những giaodịch khác sẽ không nhìn thấy những thay đổi do những giao dịch chưa thành công gâyra. Cách để thực hiện điều này là chủ đề của khôi phục sự cố. Trong chương này, chúngtôi cung cấp phần giới thiệu tổng quan về điều khiển tương tranh và khôi phục sự cố củaDBMS. Hai chương sau sẽ đi sâu hơn về những vấn đề này.

Trong Phần 2, chúng tôi trình bày bốn tính chất cơ bản của các giao dịch và cách thứcDBMS đảm bảo những tính chất này. Phần 2 trình bày một cách trừu tượng về thực hiệnmột vài giao dịch xen kẽ, được gọi là lịch trình. Phần 3 trình bày một vài vấn đề có thểphát sinh ra do việc thực thi xen lẫn gây ra. Chúng tôi giới thiệu về điều khiển tươngtranh dựa-trên-khóa trong Phần 5, một cách tiếp cận được sử dụng rộng rãi. Phần 6 xemxét việc khóa và các tính chất của giao dịch trong ngữ cảnh của SQL. Cuối cùng, trongPhần 7, chúng tôi trình bày về cách một hệ cơ sở dữ liệu khôi phục sự cố và những bướcphải làm trong suốt quá trình hỗ trợ khôi phục sự cố.

Tính chất ACID

Chúng tôi đã giới thiệu khái niệm giao dịch trong Phần 1.7. Tóm tắt lại, một giao dịchlà một thực thi của một chương trình người dùng, DBMS coi nó là một chuỗi các thaotác đọc và ghi.

DBMS phải đảm bảo bốn tính chất của giao dịch để duy trì dữ liệu khi đối mặt với điềukhiển tương tranh và những lỗi hệ thống:

344/470

1. Người dùng mong muốn việc thực thi mỗi giao dịch là nguyên tử (atomic):Tất cả các thao tác nằm trong giao dịch được thực hiện thành công hoặc thất bạihoàn toàn. Người dùng không phải lo lắng về ảnh hưởng của các giao dịchchưa được thành công (giả sử, có sự cố xảy ra khi giao dịch này đang trong quátrình thực hiện).

2. Mỗi giao dịch được thực thi không tranh chấp với các giao dịch khác, phải đảmbảo tính chất nhất quán (consistency) của cơ sở dữ liệu. DBMS thừa nhậnrằng tính nhất quán được đảm bảo trên mỗi giao dịch. Việc đảm bảo tính chấtnày của giao dịch là trách nhiệm của người dùng.

3. Người dùng nên có thể hiểu được một giao dịch mà không cần xem xét nhữngảnh hưởng của các giao dịch tương tranh khác đang chạy, thậm chí DBMS cóthể chèn vào các thao tác khác vì những lý do thực thi. Tính chất này đôi khiđược nói tới như là tính chất cô lập (isolution). Các giao dịch được cô lập, haycòn gọi là được bảo vệ từ những ảnh hưởng của các giao dịch tương tranh khác.

4. Khi DBMS thông báo cho người dùng biết rằng giao dịch đã thành công hoàntoàn, những ảnh hưởng của nó nên được duy trì ngay cả khi hệ thống gặp sự cốtrước khi tất cả những thay đổi này kịp lưu lại trên đĩa. Tính chất này được gọilà bền vững (durability).

Nhóm từ ACID đôi khi được sử dụng để nói đến bốn tính chất của giao dịch, là viết tắtcủa các từ: Atomicity, Consistency, Isolation và Durability. Bây giờ, chúng ta xem xétcách DBMS đảm bảo các tính chất này.

Nhất quán và Cô lập

Người dùng mong muốn có được sự đảm bảo về tính nhất quán của giao dịch. Tức là,người dùng yêu cầu thực hiện một giao dịch nào đó phải đảm bảo rằng khi hoàn thànhgiao dịch này cơ sở dữ liệu vẫn đảm bảo tính ‘nhất quán’. Ví dụ, người dùng có yêucầu chuyển tiền giữa các tài khoản trong ngân hàng, việc chuyển tiền này phải đảm bảorằng tổng giá trị các tài khoản sau khi chuyển không thay đổi. Để chuyển tiền từ một tàikhoản này đến một tài khoản khác, giao dịch phải trừ tiền của một tài khoản- đưa cơ sởdữ liệu tới trạng thái không nhất quán tạm thời. Cơ sở dữ liệu trở nên nhất quán nếu sốtiền này được cộng vào tài khoản thứ hai. Nếu có một lỗi nào đó xảy ra khiến tài khoảnthứ hai nhận được ít hơn một đô la so với số tiền tài khoản thứ nhất đã bị trừ, DBMSkhông thể phát hiện được sự không nhất quán dữ liệu này.

Tính cô lập đảm bảo rằng mặc dù có một số hành động của các giao dịch có thể bị xenvào, thì các giao dịch vẫn được thực hiện một cách tuần tự. (Chúng tôi sẽ trình bày cáchthức DBMS đảm bảo tính chất này trong Phần 4). Ví dụ, nếu hai giao dịch T1 và T2được thực hiện tương tranh, kết quả cuối cùng được bảo đảm tương đương với việc thựchiện T1 sau T2 hoặc T2 sau T1. Nếu mỗi giao dịch dẫn đến các minh họa dữ liệu khácnhau, việc thực thi một vài giao dịch theo thứ tự (trên minh họa dữ liệu nhất quán banđầu) sẽ thu được minh họa dữ liệu cuối cùng nhất quán.

345/470

Nhất quán cơ sở dữ liệu là tính chất mà khi thực hiện tất cả các giao dịch, các minhhọa dữ liệu đều ở trạng thái nhất quán. Cơ sở dữ liệu nhất quán đạt được do các tínhchất của giao dịch: nguyên tử, cô lập và nhất quán. Tiếp đến, chúng tôi trình bày về tínhnguyên tử và bền vững trong DBMS.

Nguyên tử và Bền vững

Các giao dịch có thể không thành công được vì ba lý do. Đầu tiên, giao dịch có thể bịtừ chối hoặc thực thi không thành công do trong quá trình thực hiện nó dẫn đến một dịthường dữ liệu nào đó. Nếu một giao dịch bị DBMS từ chối thực hiện vì lý do bên trong,nó sẽ khởi động lại và thực hiện một lần nữa. Thứ hai, hệ thống này có lẽ gặp sự cố (vídụ, do mất nguồn điện) trong khi giao dịch đang thực hiện. Thứ ba, giao dịch có thể gặpphải một tình huống không mong muốn (ví dụ, đọc một giá trị dữ liệu không được mongmuốn hoặc không thể truy cập tới một đĩa nào đó) và quyết định hủy bỏ nó.

Tất nhiên người dùng nghĩ rằng các giao dịch bị dừng giữa chừng này sẽ dẫn cơ sở dữliệu đến trạng thái không nhất quán. Vì thế, DBMS phải tìm cách để loại bỏ những ảnhhưởng của các giao dịch này tới cơ sở dữ liệu. Tức là, nó phải đảm bảo tính nguyên tửcủa giao dịch: Tất cả các phép thực thi trong giao dịch sẽ thành công, hoặc thất bại hoàntoàn. DBMS đảm bảo tính nguyên tử của giao dịch bằng việc cho khôi phục lại nhữngthao tác của các giao dịch chưa thành công. Người dùng có thể không cần để ý đến việcDBMS sửa các giao dịch chưa thành công như thế nào. Để có thể làm điều này, DBMSduy trì một bản ghi, gọi là lịch sử, lưu lại tất cả các thao tác ghi vào cơ sở dữ liệu. Thôngtin lịch sử này được sử dụng để đảm bảo tính bền vững: Nếu hệ thống gặp sự cố trướckhi những giao dịch đã thành công kịp lưu lên đĩa, thông tin lịch sử được sử dụng để ghinhớ và hoàn thành phần việc chưa xong này khi hệ thống khởi động lại.

Các thành phần của DBMS đảm bảo tính chất nguyên tử và bền vững được gọi là quảnlý phục hồi, chúng ta bàn thêm trong Phần 7.

Giao dịch và Lịch trình

Một giao dịch được DBMS xem như là một chuỗi, hay một danh sách các thao tác. Cácthao tác này có thể bao gồm việc đọc và ghi các đối tượng cơ sở dữ liệu. Để đơn giản,chúng tôi giả sử rằng đối tượng O luôn được đọc vào một biến của chương trình cũng cótên là O. Chúng tôi có thể biểu diễn thao tác đọc đối tượng O của giao dịch T là RT(O),tương tự, chúng tôi có thể biểu diễn thao tác ghi là WT(O). Khi giao dịch T được xóakhỏi ngữ cảnh này, chúng ta hãy quên đi những ký hiệu này.

Đối với việc đọc và ghi, mỗi giao dịch phải chỉ rõ nó có thành công (giao dịch thànhcông hoàn toàn) hay hủy bỏ (tức là, giao dịch gặp sự cố và tất cả các thao tác đã thựchiện trong giao dịch phải khôi phục lại). Abort(T) biểu diễn thao tác T bị hủy bỏ, vàCommit(T) biểu diễn T thành công.

346/470

Chúng ta có hai giả định quan trọng:

1. Các giao dịch ảnh hưởng lẫn nhau chỉ thông qua các thao tác đọc và ghi cơ sởdữ liệu: ví dụ, chúng không được phép trao đổi những thông báo.

2. Cơ sở dữ liệu là một tập cố định các đối tượng độc lập. Khi các đối tượng đượcthêm vào hoặc xóa khỏi cơ sở dữ liệu hoặc giữa các đối tượng tồn tại nhữngmối quan hệ thì một vài vấn đề sẽ nảy sinh.

Nếu giả định đầu tiên bị vi phạm, DBMS sẽ không có cách nào để phát hiện hoặc chốnglại sự không nhất quán của dữ liệu, và người viết ứng dụng không thể đảm bảo sự đúngđắn của chương trình. Chúng tôi giải thích giả định thứ hai trong Phần 6.2.

Lịch trình là một danh sách các thao tác (đọc, viết, từ chối thực hiện, hoặc thành công)của các giao dịch, và thứ tự hai thao tác trong giao dịch T xuất hiện trong lịch trình phảigiống với thứ tự nó xuất hiện trong T. Lịch trình biểu diễn sự tuần tự thực hiện của cácthao tác. Ví dụ, lịch trình trong Hình 2 chỉ ra thứ tự thực hiện của các thao tác trong haigiao dịch T1 và T2. Chúng tôi biểu diễn mỗi thao tác trong một dòng. Chúng tôi nhấnmạnh rằng lịch trình biểu diễn các thao tác của các giao dịch nhìn từ phía DBMS. Thêmvào những thao tác này, một giao dịch có thể thực hiện những thao tác khác, như đọchoặc ghi từ các file hệ điều hành, đánh giá các biểu thức số học, vv…; tuy nhiên, chúngtôi giả sử rằng các thao tác này được thực hiện mà không ảnh hưởng đến những giaodịch khác.

Lịch trình của hai giao dịch

Ghi nhớ rằng lịch trình trong Hình 2 không chứa các thao tác hủy bỏ hoặc thành côngcủa mỗi giao dịch. Lịch trình chứa cả những thao tác này được gọi là lịch trình đầy đủ.Một lịch trình đầy đủ phải chứa tất cả các thao tác của tất cả các giao dịch xuất hiệntrong nó. Nếu các thao tác của các giao dịch khác nhau không được chèn vào, tức là, cácgiao dịch này được thực hiện từ bắt đầu tới kết thúc, tuần tự từng giao dịch- thì chúngtôi gọi lịch trình này là lịch trình tuần tự (serial schedule).

Các giao dịch thực thi tương tranh

Trong phần giới thiệu về khái niệm lịch trình ở trên, chúng tôi đã dùng một cách phùhợp để biểu diễn các các giao dịch thực hiện xen kẽ. Các thao tác này nhằm cải thiện

347/470

khả năng thực thi của hệ thống, nhưng không phải tất cả mọi thao tác đều được phép.Trong phần này, chúng ta xem xét những thao tác, hay là những lịch trình nào DBMScho phép.

Động cơ của thực thi tương tranh

Lịch trình trong Hình 2 biểu diễn sự thực hiện xen kẽ của hai giao dịch. Để đảm bảo tínhcô lập của giao dịch trong khi cho phép hai giao dịch được thực hiện đồng thời là khókhăn nhưng cần thiết vì những lý do thực thi. Đầu tiên, trong khi một giao dịch đang đợiđể đọc một trang vào từ đĩa, CPU có thể xử lý những giao dịch khác. Có được điều nàybởi vì các thao tác I/O có thể được làm song song với các thao tác khác của CPU. Việcchồng thao tác I/O và thao tác trên CPU làm giảm thời gian nghỉ của CPU, đĩa và cảithiện khả năng của hệ thống (số lượng trung bình các giao dịch được hoàn thành trongmột khoảng thời gian nào đó). Thứ hai, sự xen lẫn thực hiện của một giao dịch ngắn vớimột giao dịch dài thường cho phép giao dịch ngắn thực hiện nhanh hơn. Nếu thực hiệntuần tự, giao dịch ngắn có thể phải xếp hàng đằng sau một giao dịch dài, dẫn đến thờigian phản hồi chậm.

Sự tuần tự

Lịch trình tuần tự trên một tập S các giao dịch là một lịch trình mà kết quả thực hiệncủa nó tương đương với kết quả thực hiện các giao dịch này theo các lịch trình khácnhau.

Ví dụ, lịch trình trong Hình 2 là lịch trình tuần tự. Mặc dù các thao tác trong T1 và T2xen kẽ nhau, nhưng kết quả của lịch trình này tương đương với việc thực hiện T1 (toànbộ) và sau đó thực hiện T2. Như ta quan sát được, việc đọc và ghi đối tượng A của giaodịch T1 không ảnh hưởng đến việc đọc và ghi đối tượng A của giao dịch T2, và chúngta có thể ‘đảo’ thứ tự T1, T2.

Lịch trình tuần tự

348/470

Việc thực hiện các giao dịch này theo các thứ tự khác nhau có thể đưa đến những kếtquả khác nhau nhưng giả sử tất cả chúng đều được chấp nhận. Để nhìn thấy điều này,lưu ý rằng hai giao dịch trong Hình 2 có thể được thực hiện như Hình 3. Lịch trình nàycũng là lịch trình tuần tự, tương đương với lịch trình T2; T1. Nếu T1 và T2 được gửi tớiDBMS đồng thời, cả hai lịch trình này có thể được lựa chọn.

Định nghĩa về lịch trình tuần tự phía trên không bao gồm trường hợp các lịch trình chứacác giao dịch bị hủy bỏ. Chúng ta mở rộng định nghĩa này để nó bao hàm cả các lịchtrình bị hủy bỏ trong Phần 3.4.

Lịch trình tuần tự khác

Cuối cùng, chúng ta ghi nhớ rằng một DBMS có thể thực hiện các giao dịch có lịch trìnhkhông tuần tự. Điều này có thể xảy ra vì hai lý do. Thứ nhất, DBMS này có lẽ sử dụngmột cơ chế điều khiển tương tranh để đảm bảo các lịch trình không tuần tự được thựchiện như các lịch trình tuần tự (ví dụ xem trong Phần 17.6.2). Thứ hai, SQL cung cấpcho người lập trình ứng dụng khả năng chỉ dẫn cho DBMS để nó lựa chọn các lịch trìnhkhông tuần tự (xem Phần 6).

Những dị thường do thực thi xen kẽ

Hai thao tác trên cùng một đối tượng dữ liệu sẽ xảy ra xung đột nếu một trong số chúnglà thao tác viết. Ba tình trạng dị thường có thể xảy ra khi các thao tác của hai giao dịchT1 và T2 xung đột với nhau: Trong xung đột viết-đọc (WR), T2 đọc một đối tượng dữliệu trước khi T1 viết lên nó; tương tự, chúng ta định nghĩa xung đột đọc-viết (RW) vàxung đột viết-viết (WW).

Đọc dữ liệu chưa được hoàn thành (xung đột WR)

Nguyên nhân đầu tiên dẫn đến dị thường là giao dịch T2 có thể đọc một đối tượng Ađang được giao dịch T1 sửa, trong khi T1 chưa thành công. Việc đọc này được gọi làđọc bẩn (dirty read). Ví dụ đơn giản sau minh họa như thế nào một lịch trình có thể

349/470

dẫn đến tình trạng cơ sở dữ liệu không nhất quán. Xem xét hai giao dịch T1 và T2, mỗigiao dịch này chạy độc lập sẽ dẫn đến tình trạng nhất quán của dữ liệu: T1 chuyển $100từ A tới B, và T2 tăng cả A và B lên 6%. Giả sử rằng các thao tác này được thực hiệnxen kẽ như sau (1) T1 thực hiện khấu trừ $100 của tài khoản A, sau đó (2) T2 đọc giátrị hiện tại của tài khoản A và B và tăng cả A và B lên 6%, và sau đó (3) tăng tài khoảnB lên $100. Lịch trình này được minh họa trong Hình 4. Kết quả của lịch trình này khácvới kết quả của lịch trình mà hai giao dịch thực hiện tuần tự. Vấn đề này xảy ra do T2đọc đối tượng A trước khi T1 hoàn thành tất cả các thay đổi.

Đọc dữ liệu chưa hoàn thành

Minh họa chỉ ra rằng T1 có lẽ viết một số giá trị vào A làm thay đổi sự nhất quán của cơsở dữ liệu. Việc này sẽ không gây hại gì nếu T1 và T2 được thực hiện tuần tự, bởi vì T2sẽ không gặp phải sự không nhất quán (tạm thời). Tuy nhiên, việc thực thi xen kẽ này đãdẫn đến tình trạng không nhất quán tạm thời và trạng thái cuối cùng của cơ sở dữ liệu sẽkhông nhất quán.

Ghi nhớ rằng mặc dù một giao dịch phải đưa cơ sở dữ liệu đến trạng thái nhất quán saukhi nó thành công, nhưng nó không yêu cầu phải nhất quán trong quá trình đang thựcthi. Ví dụ: Để chuyển tiền từ một tài khoản này đến một tài khoản khác, giao dịch sẽphải trừ tiền ở một tài khoản, dẫn đến tình trạng không nhất quán tạm thời của cơ sở dữliệu, và sau đó cộng số tiền này vào tài khoản thứ hai, khôi phục lại trạng thái nhất quáncủa cơ sở dữ liệu.

Đọc không thể lặp lại (Xung đột RW)

Lý do thứ hai dẫn đến tình trạng không nhất quán là giao dịch T2 có thể thay đổi giá trịcủa đối tượng A trong khi đối tượng này đã được T1 đọc và T1 vẫn đang trong quá trìnhthực hiện.

Nếu T1 cố gắng đọc lại giá trị của A, nó sẽ có một kết quả khác. Tình trạng này có thểkhông xảy ra nếu hai giao dịch thực hiện tuần tự. Việc đọc này được gọi là đọc khôngthể lặp lại (unrepeatable read).

350/470

Để hiểu được lý do tại sao, chúng ta cùng xem xét ví dụ sau. Giả sử A là số bản saocủa một quyển sách. Một giao dịch đặt hàng mua sách thực hiện việc đọc A, nó kiểmtra thấy rằng A đang lớn hơn 0, và giảm A đi. Giao dịch T1 đọc A và nhìn thấy giá trịlà 1. Giao dịch T2 cũng đọc A và nhìn thấy giá trị là 1, giảm A xuống bằng 0 và hoànthành giao dịch. Giao dịch T1 sau đó cố gắng giảm A và lỗi xảy ra (nếu ở đây có mộtràng buộc toàn vẹn là không cho phép A có giá trị âm).

Tình trạng này có thể không bao giờ xảy ra nếu T1 và T2 thực hiện tuần tự; giao dịchthứ hai sẽ đọc A và nhìn thấy 0, vì thế nó sẽ không thực hiện hóa đơn này (và vì thế nósẽ không cố gắng giảm giá trị của A).

Viết đè lên dữ liệu chưa hoàn thành (xung đột WW)

Lý do thứ ba dẫn đến dị thường là giao dịch T2 có thể viết đè giá trị lên đối tượng A-đối tượng đã được T1 sửa, trong khi T1 vẫn đang trong quá trình thực hiện. Ngay cả khiT2 không đọc giá trị của A do T1 đã viết lên, thì vẫn có vấn đề tiềm ẩn như minh họasau.

Giả sử rằng Harry và Larry là hai nhân viên, lương của họ phải duy trì bằng nhau. Giaodịch T1 thiết đặt lương của họ là $2000 và giao dịch T2 thiết đặt là $1000. Nếu chúngta thực hiện hai giao dịch này theo thứ tự T1 trước T2 thì cả hai người đều nhận lươnglà $1000; ngược lại nếu T2 trước T1 thì lương của họ là $2000. Ghi nhớ rằng không cógiao dịch nào thực hiện thao tác đọc lương trước khi ghi đè lên nó- thao tác viết như vậygọi là viết mù.

Bây giờ, đề cập đến việc thực thi xen kẽ các thao tác của T1 và T2: T2 thiết đặt lươngcủa Harry là $1000, T1 thiết đặt lương của Larry là $2000, T2 thiết đặt lương của Larrylà $1000 và giao dịch này được thành công, và cuối cùng T1 thiết đặt lương của Harrylà $2000 và giao dịch được thành công. Kết quả này không tương đương với kết quả khihai giao dịch thực hiện theo thứ tự, và lịch trình xen kẽ này vì thế không được gọi là lịchtrình tuần tự. Nó vi phạm ràng buộc là lương của hai nhân viên này phải bằng nhau.

Lịch trình bao gồm các giao dịch bị hủy bỏ

Bây giờ chúng ta mở rộng định nghĩa về sự tuần tự tới cả những giao dịch bị hủy bỏ. Tấtcả các thao tác của các giao dịch bị hủy bỏ phải được thực hiện lại, và vì thế chúng tacó thể tưởng tượng rằng giao dịch này không được thực hiện gì kể từ lúc nó bắt đầu. Sửdụng suy nghĩ này, chúng ta mở rộng định nghĩa về lịch trình tuần tự như sau: Một lịchtrình tuần tự trên tập S các giao dịch là một lịch trình mà ảnh hưởng của nó trên bất kỳminh họa cơ sở dữ liệu nhất quán nào được đảm bảo là tương đương với các lịch trìnhtuần tự khác của các giao dịch trong S.

351/470

Định nghĩa này dựa trên suy nghĩ rằng các thao tác của các giao dịch bị hủy bỏ sẽ đượckhôi phục lại hoàn toàn, điều này có thể không thực hiện được trong một vài trường hợp.Ví dụ, giả sử rằng (1) một chương trình chuyển tiền T1 khấu trừ $100 từ tài khoản A,sau đó (2) một chương trình tính lãi xuất T2 đọc giá trị hiện tại của tài khoản A và B vàthêm vào đó 6%, sau đó nó thành công, và sau đó (3) T1 bị hủy bỏ. Lịch trình này đượcminh họa trong Hình 5.

Một lịch trình không thể khôi phục

Bây giờ, T2 đã đọc giá trị của A. (Nhớ lại rằng ảnh hưởng của các giao dịch bị hủy bỏkhông hỗ trợ khả năng quan sát các giao dịch khác). Nếu T2 không thành công, chúngta có thể phải đối mặt với tình trạng hủy bỏ chồng, T1 bị hủy bỏ và T2 cũng bị hủy bỏtheo, và cứ thế kéo theo những giao dịch khác. Nhưng T2 đã thành công, và vì thế chúngta không thể khôi phục lại những thao tác trong nó. Chúng ta nói rằng lịch trình này làkhông thể khôi phục. Trong một lịch trình có thể khôi phục, các giao dịch thành côngchỉ sau khi tất cả các giao dịch khác liên quan đã đọc xong những thay đổi của giao dịchnày.

Có những vấn đề tiềm ẩn khác trong việc khôi phục lại các thao tác của một giao dịch.Giả sử rằng giao dịch T2 viết đè lên giá trị của đối tượng A – giá trị này đã được giaodịch T1 sửa, trong khi đó T1 vẫn đang trong quá trình thực thi, và T1 sau đó bị hủy bỏ.Tất cả các thay đổi của T1 trên các đối tượng cơ sở dữ liệu được khôi phục lại như trướckhi T1 thực hiện. (Chúng ta tìm hiểu chi tiết về cách một giao dịch hủy bỏ được quản lýnhư thế nào trong Chương 18). Khi T2 bị hủy bỏ và những thay đổi của nó được khôiphục lại, những thay đổi của T2 cũng bị mất, ngay cả khi T2 quyết định thành công. Vídụ, nếu A ban đầu có giá trị là 5, sau đó được T1 thay đổi thành 6, và được T2 thay đổithành 7, nếu bây giờ T1 bị hủy bỏ, giá trị của A trở về bằng 5. Ngay cả khi T2 thànhcông, những tác động tới A cũng bị mất. Một công nghệ điều khiển tương tranh gọi làStrict 2PL được giới thiệu trong Phần 4 có thể tránh được vấn đề này (như trình bàytrong Phần 17.1).

352/470

Điều khiển tương tranh dựa trên khóa

DBMS phải được đảm bảo rằng chỉ có những lịch trình có khả năng khôi phục, và tuầntự là được phép và không có thao tác nào của các giao dịch thành công lại bị mất trongquá trình khôi phục các giao dịch bị hủy bỏ. DBMS thường sử dụng giao thức khóa đểđạt được điều này. Khóa có thể được đặt trên các đối tượng cơ sở dữ liệu. Giao thứckhóa là tập các quy tắc đằng sau mỗi giao dịch (và do DBMS thiết đặt) để đảm bảorằng, mặc dù các thao tác của một số giao dịch khác có thể được chèn vào, nhưng kếtquả cuối cùng sẽ tương đương với việc các giao dịch được thực hiện tuần tự. Các giaothức khóa khác nhau sử dụng các kiểu khóa khác nhau, như khóa chia sẻ hoặc khóa độcquyền, chúng ta sẽ bàn đến các loại khóa này trong phần giao thức Strict 2PL.

Khóa 2-pha nghiêm ngặt (Strict 2PL)

Giao thức khóa được sử dụng rộng rãi nhất, gọi là khóa hai pha nghiêm ngặt, hoặc Strict2PL, có hai nguyên tắc. Thứ nhất là:

• Nếu một giao dịch T muốn đọc (sau đó là sửa) một đối tượng, đầu tiên nó yêucầu một khóa chia sẻ (sau đó là khóa độc quyền) trên đối tượng này.

Tất nhiên, một giao dịch có khóa độc quyền cũng có thể đọc đối tượng này. DBMS đảmbảo rằng nếu một giao dịch nào đó nắm giữ khóa độc quyền trên một đối tượng, thìkhông có giao dịch nào khác được nắm giữ khóa chia sẻ và khóa độc quyền trên cùngđối tượng đó. Quy tắc thứ hai của Strict 2PL là:

• Tất cả khóa do một giao dịch nào đó nắm giữ sẽ được giải phóng khi giao dịchnày hoàn thành.

Việc yêu cầu và giải phóng khóa của một giao dịch nào đó được DBMS thực hiện tựđộng; người dùng không phải lo lắng về vấn đề này. (Chúng ta bàn về cách thức ngườilập trình ứng dụng có thể lấy ra các thuộc tính của các giao dịch và điều khiển việc khóatrong Phần 6.3).

Về hiệu quả, giao thức khóa cho phép thực hiện các giao dịch xen kẽ một cách ‘an toàn’.Nếu hai giao dịch truy cập đến hai phần phân biệt của cơ sở dữ liệu, chúng sẽ có đượccác khóa chúng cần đồng thời và vui vẻ thực hiện các công việc của chúng. Ngược lại,nếu hai giao dịch cùng truy cập đến một đối tượng và một trong số chúng muốn sửa dữliệu, những thao tác của chúng phải được thực hiện theo thứ tự- tất cả các thao tác củamột trong số hai giao dịch này (giao dịch có khóa trên đối tượng này trước) được thànhcông trước khi (khóa này được giải phóng và) giao dịch thứ hai được xử lý.

Chúng ta biểu diễn thao tác của một giao dịch T yêu cầu khóa chia sẻ (tiếp đến là khóađộc quyền) trên đối tượng O là ST(O) (và XT(O)). Ví dụ, xem xét lịch trình trong Hình

353/470

4. Việc thực hiện xen kẽ này có thể dẫn đến kết quả không tương đương với kết quả thựchiện theo bất kỳ thứ tự nào của ba giao dịch. Ví dụ, T1 có thể thay đổi A từ 10 thành20, sau đó T2 (đọc giá trị 20 của A) có thể thay đổi B từ 100 thành 200, và sau đó T1 sẽđọc giá trị 200 của B. Nếu chạy tuần tự, T1 hoặc T2 sẽ thực hiện trước, và đọc giá trị 10của A và 100 của B: Rõ ràng, việc thực hiện xen kẽ này không tương đương với thực thituần tự.

Lịch trình Strict 2PL

Nếu giao thức Strict 2PL được sử dụng, việc thực hiện xen kẽ như vậy sẽ không đượcphép. Hãy cùng chúng tôi nhìn xem vì sao. Giả sử rằng các giao dịch đều được xuất phátnhư trước, T1 sẽ có được khóa độc quyền trên A trước và sau đó đọc và ghi A (Hình 6).Sau đó, T2 sẽ yêu cầu khóa trên A. Tuy nhiên, yêu cầu này không được chấp nhận chođến khi T1 giải phóng khóa độc quyền của nó trên A, và vì thế DBMS vẫn trì hoãn thựchiện T2. Bây giờ, T1 đã có khóa độc quyền trên B, nó thực hiện đọc và ghi B, sau đókết thúc giao dịch, tại thời điểm này các khóa của T1 được giải phóng. Khóa của T2 bâygiờ được phép và T2 tiến hành công việc của nó. Trong ví dụ này, các kết quả của giaothức khóa trong thực thi tuần tự hai giao dịch được chỉ ra trong Hình 7.

Lịch trình minh họa Strict 2PL với thực hiện tuần tự

Tuy nhiên, các thao tác của các giao dịch khác nhau có thể được thực thi xen kẽ. Ví dụ,xem xét việc thực hiện xen kẽ hai giao dịch chỉ ra trong Hình 8. Nó chỉ ra rằng thuậntoán Strict 2PL cho phép chỉ những lịch trình tuần tự. Không có dị thường nào trình bàytrong Phần 3.3 có thể xảy ra khi DBMS áp dụng Strict 2PL.

354/470

Lịch trình Strict 2PL với các thao tác xen kẽ

Khóa chết (DeadLocks)

Xem xét ví dụ sau. Giao dịch T1 đặt một khóa độc quyền trên đối tượng A, T2 đặt mộtkhóa độc quyền trên B, T1 yêu cầu một khóa độc quyền trên B và nó được vào hàngđợi, và T2 yêu cầu một khóa độc quyền trên A và nó được vào hàng đợi. Bây giờ, T1đang chờ T2 giải phóng khóa của nó và T2 chờ T1 giải phóng khóa của nó. Như vậy mộtvòng tròn của các giao dịch chờ đợi các khóa được giải phóng được gọi là khóa chết.Rõ ràng, hai giao dịch này sẽ không thể đi xa hơn được nữa. Tệ hơn, chúng nắm giữ cáckhóa mà có thể các giao dịch khác đang yêu cầu. DBMS phải tránh được tình trạng nàyhoặc phát hiện được nó; cách tiếp cận phổ biến là phát hiện và giải quyết nó.

Một cách đơn giản để giải quyết khóa chết là sử dụng cơ chế thời gian sống (timeout).Nếu một giao dịch phải chờ đợi quá lâu để có một khóa, chúng ta có thể cho rằng nóđang nằm trong vòng tròn khóa chết. Chúng ta bàn chi tiết hơn về khóa chết trong Phần17.2.

Thực thi của khóa

Các lược đồ dựa trên khóa được thiết kế để giải quyết xung đột giữa các giao dịch vàsử dụng hai cơ chế cơ bản: ngăn chặn và hủy bỏ. Cả hai cơ chế này đều thực hiện: Cácgiao dịch đã bị ngăn chặn có thể nắm giữ các khóa làm cho các giao dịch khác phải đợi,và việc hủy bỏ và khởi động lại một giao dịch nào đó hiển nhiên là sẽ mất thời gian vìphải thực hiện lại những công việc mà giao dịch này đã làm được. Vấn đề khóa chết làmột minh họa tuyệt vời về việc ngăn chặn, trong đó một tập các giao dịch sẽ vĩnh viễnbị ngăn lại trừ khi một trong số các giao dịch gặp hiện tượng khóa chết này được DBMShủy bỏ.

Trong thực tế, ít hơn 1% giao dịch gặp rắc rối bởi khóa chết, và một số lượng tươngđối bị hủy bỏ. Vì thế, tràn khóa là lý do chính dẫn đến việc ngăn chặn. Xem xét việc trìhoãn ngăn chặn làm ảnh hưởng đến throughtput (số lượng các giao dịch đưa vào) như

355/470

thế nào. Đầu tiên, một vài giao dịch xung đột nhau, và throughput tăng lên tỷ lệ thuậnvới số lượng các giao dịch đang được thực hiện. Khi có nhiều giao dịch thực thi đồngthời trên cùng một số đối tượng cơ sở dữ liệu, rất có thể số lượng các giao dịch bị ngănchặn tăng lên. Vì thế, việc trì hoãn dẫn đến tăng sự ngăn chặn tương ứng với số lượngcác giao dịch đang thực hiện, và throughtput tăng chậm hơn nhiều so với số lượng cácgiao dịch đang thực hiện. Trên thực tế, có một điểm mà khi thêm vào các giao dịch khácsẽ làm giảm throughput. Chúng ta giả sử rằng hệ thống thrashing (bị nghẽn) ở điểm này,như minh họa trong Hình 9.

Lock Thrashing

Nếu một hệ thống cơ sở dữ liệu bắt đầu gặp hiện nghẽn, người quản trị cơ sở dữ liệu nêngiảm số lượng các giao dịch được thực hiện đồng thời (active transactions). Theo kinhnghiệm, nghẽn quan sát được khi 30% giao dịch đang hoạt động bị ngăn lại, và DBAnên điều chỉnh lại tỷ lệ của các giao dịch bị ngăn lại nếu hệ thống gặp hiện tượng nghẽn.

Throughput có thể được tăng lên bằng ba cách:

• Khóa trên các đối tượng có kích thước nhỏ nhất có thể được (giảm khả năng haigiao dịch cần cùng khóa).

• Giảm thời gian nắm giữ khóa của giao dịch (để các giao dịch có thời gian bịngăn chặn ngắn hơn).

• Giảm các điểm nóng (hot spots). Điểm nóng là một đối tượng cơ sở dữ liệuđược truy cập và cập nhật thường xuyên. Các điểm nóng có thể ảnh hưởngđáng kể đến khả năng thực thi.

Chúng tôi trình bày về cải thiện khả năng thực thi bằng cách tối thiểu hóa thời gian khóanắm giữ và cách sử dụng các công nghệ để đối mặt với các điểm nóng trong Phần 20.10.

SQL hỗ trợ giao dịch

Phần trước chúng ta đã nghiên cứu về giao dịch và quản lý giao dịch. Bây giờ chúng taxem xét việc SQL hỗ trợ người dùng quản lý giao dịch như thế nào.

356/470

Tạo và chấm dứt các giao dịch

Một giao dịch sẽ được khởi động một cách tự động khi người dùng thực thi một câulệnh truy cập đến cơ sở dữ liệu hoặc các danh mục, như một truy vấn SQL, một lệnh cậpnhật, hoặc một lệnh CREATE TABLE.

Khi giao dịch được khởi tạo, những câu lệnh của nó được thực hiện như một phầncủa giao dịch này cho đến khi giao dịch được kết thúc bằng lệnh COMMIT hoặcROLLBACK.

Trong SQL: 1999, hai tính năng mới được cung cấp để hỗ trợ các ứng dụng có các giaodịch có thời gian chạy dài, hoặc phải chạy một vài giao dịch sau một giao dịch khác. Đểhiểu được điều này, nhớ lại rằng tất cả các thao tác của một giao dịch phải được thựchiện theo thứ tự, không kể đến việc các thao tác của giao dịch khác được xen vào. Chúngta có thể nghĩ rằng mỗi giao dịch là một tập các bước được thực hiện tuần tự.

Tính năng đầu tiên được gọi là savepoint, cho phép chúng ta xác định một điểm tronggiao dịch mà trong trường hợp giao dịch bị hủy thì những thao tác trong giao dịch nàysẽ được khôi phục lại tính từ điểm đằng sau từ khóa rollback.

SQL: 1999 Những giao dịch lồng nhau: Khái niệm về một giao dịch là một tập các thaotác được thực hiện một cách ‘nguyên tử’ đã được đưa vào trong SQL: 1999 với việcthêm tính năng savepoint. Điều này cho phép rollback lại một phần của giao dịch (chứkhông phải toàn bộ). SQL hỗ trợ tính năng này trong các giao dịch lồng nhau. Ý tưởnglà giao dịch có thể được thực hiện lồng trong những giao dịch khác, mỗi giao dịch concó thể được rollback.

Trong một giao dịch có thời gian chạy dài, chúng ta có thể muốn định nghĩa nhiều điểmsavepoint:

SAVEPOINT <savepoint name>

Các lệnh rollback có thể chỉ ra điểm savepoint như sau:

ROLLBACK TO SAVEPOINT <savepoint name>

Nếu chúng ta định nghĩa ba điểm savepoint A, B và C theo thứ tự, và sau đó rollbacktới điểm A thì tất cả các thao tác từ điểm A được khôi phục lại, bao gồm cả việc tạo racác điểm savepoint là B và C. Thực tế, savepoint A tự bản thân nó sẽ mất khi chúng tarollback tới nó, và nếu chúng ta muốn rollback lại điểm này một lần nữa, chúng ta phảixây dựng lại nó. Đứng trên quan điểm của khóa, các khóa có được sau điểm savapointA có thể được giải phóng khi chúng ta rollback lại từ điểm A.

357/470

Bạn nên so sánh việc sử dụng các vị trí savepoints với cách tiếp cận thứ hai là xem tậpcác thao tác nằm giữa các vị trí savepoints là một giao dịch. Cơ chế savepoint có hai ưuđiểm. Đầu tiên, chúng ta có thể rollback đến một vị trí savepoint bất kỳ. Trong khi cáchtiếp cận thứ hai, chúng ta chỉ có thể rollback đến vị trí savepoint gần nhất. Thứ hai, sửdụng savepoint có thể tránh được overhead xảy ra khi khởi tạo nhiều giao dịch.

Ngay cả khi sử dụng cơ chế savepoint, các ứng dụng có thể yêu cầu chúng ta chạy mộtsố giao dịch một cách tuần tự. Để giảm thiểu được overhead trong những tình huốngnày, SQL: 1999 giới thiệu một tính năng khác, gọi là chained transactions (giao dịchtheo chuỗi). Chúng ta có thể cho một giao dịch nào đó thành công hoặc khôi phục lạivà ngay lập tức khởi tạo một giao dịch khác. Thực hiện điều này bằng cách sử dụng từkhóa AND CHAIN trong các câu lệnh COMMIT và ROLLBACK.

Chúng ta nên khóa cái gì?

Cho đến bây giờ, chúng tôi đã trình bày về giao dịch và điều khiển tương tranh một cáchtrừu tượng trong đó cơ sở dữ liệu chứa một tập cố định các đối tượng, và mỗi giao dịchlà một chuỗi các thao tác đọc và ghi lên các đối tượng riêng rẽ. Một câu hỏi quan trọngcần xem xét là trong ngôn ngữ SQL, DBMS coi cái gì là một đối tượng khi thiết đặtkhóa ứng với một câu lệnh SQL nào đó (tức là, một phần của giao dịch).

Xem xét truy vấn sau:

SELECT S.rating, MIN (S.age) FROM Sailors S WHERE S.rating= 8

Giả sử rằng truy vấn này là một phần của giao dịch T1 và câu lệnh SQL sửa lại tuổi(age) của một thủy thủ nào đó, giả sử Joe – người có rating = 8, là một phần của giaodịch T2. ‘Đối tượng’ nào sẽ được DBMS khóa khi thực thi các giao dịch này? Bằng trựcgiác, chúng ta phải phát hiện được sự xung đột giữa các giao dịch này. DBMS có thểthiết đặt một khóa chia sẻ lên trên bảng Sailor cho T1 và lập một khóa độc quyền lêntrên Sailors cho T2, điều này sẽ đảm bảo rằng hai giao dịch này được thực thi một cáchcó thứ tự. Tuy nhiên, cách tiếp cận này có hiệu quả thấp trong điều khiển tương tranh, vàchúng ta có thể làm tốt hơn bằng việc khóa các đối tượng nhỏ hơn, chính là phần dữ liệumà mỗi giao dịch thực sự truy cập đến. Vì thế, DBMS có thể thiết đặt một khóa chia sẻchỉ trên tất cả các dòng có rating = 8 cho giao dịch T1 và thiết đặt khóa độc quyền chỉtrên dòng cần thay đổi cho giao dịch T2. Như vậy, những giao dịch chỉ-đọc khác (nhữnggiao dịch không bao gồm các dòng có rating=8) có thể được xử lý mà không cần đợi T1và T2 thực thi xong.

Như trong minh họa của ví dụ này, DBMS có thể khóa các đối tượng ở các mức khácnhau: Chúng ta có thể khóa toàn bộ bảng hoặc thiết đặt các khóa mức-dòng. Khóa mức-dòng là tốt hơn nhưng lại phức tạp hơn. Ví dụ, một giao dịch cần kiểm tra một vài dòng

358/470

thỏa mãn điều kiện tìm kiếm nào đó và thay đổi nó có thể sẽ thực hiện tốt nhất bằngcách thiết đặt khóa chia sẻ lên toàn bộ bảng và thiết đặt khóa độc quyền lên trên nhữngdòng mà nó muốn thay đổi. Chúng tôi trình bày thêm về vấn đề này trong Phần 17.5.3.

Điểm thứ hai cần lưu ý là các câu lệnh SQL truy cập đến một tập các bản ghi thỏa mãnmột số điều kiện nào đó. Trong ví dụ trước, giao dịch T1 truy cập tất cả các dòng córating=8. Chúng tôi đã đề nghị rằng có thể giải quyết vấn đề này bằng cách đặt khóachia sẻ lên trên tất cả các dòng của Sailors có rating=8. Không may thay, điều nàykhông đơn giản như vậy. Để nhìn thấy vì sao, xem xét câu lệnh SQL để thêm một sailormới có rating=8 và chạy câu lệnh này trong giao dịch T3. (Quan sát thấy rằng ví dụ nàyvi phạm giả thiết của chúng ta là cố định số lượng đối tượng trong cơ sở dữ liệu, nhưngtrên thực tế chúng ta phải đối mặt với tình trạng này).

Giả sử rằng DBMS thiết đặt các khóa chia sẻ lên trên tất cả các dòng Sailors đang tồntại có rating=8 cho T1. Điều này không ngăn được giao dịch T3 tạo một dòng mới córating=8 và đặt một khóa độc quyền lên trên dòng này. Nếu dòng mới này có giá trị agenhỏ hơn các dòng đang tồn tại, kết quả trả về của T1 phụ thuộc vào thời điểm nó đượcthực hiện liên quan đến T2. Tuy nhiên, lược đồ khóa của chúng ta đã được đưa ra màkhông đề cập đến thứ tự của hai giao dịch này.

Hiện tượng này được gọi là phantom (dữ liệu ma): Một giao dịch nào đó truy cập đếnmột tập các đối tượng (trong SQL gọi là một tập các bộ giá trị) hai lần và nhìn thấynhững kết quả khác nhau, ngay cả khi nó không sửa bất kỳ bộ giá trị nào. Để tránh vấnđể phantom, DBMS phải khóa tất cả các dòng có khả năng có rating=8 cho T1. Mộtcách để làm điều này là khóa toàn bộ bảng, chấp nhận khả năng xử lý tương tranh thấp.Chúng ta cũng có thể sử dụng những ưu điểm của chỉ số để làm điều này tốt hơn, phầnnày sẽ được bàn đến trong Phần 17.5.1, nhưng nói chung việc ngăn chặn phantoms cóthể có ảnh hưởng đáng kể trong điều khiển tương tranh.

Sẽ là tốt nếu ứng dụng này thỏa hiệp được để T1 chấp nhận khả năng không chính xáccủa dữ liệu mà từ đó có thể dẫn đến phantoms. Nếu được như vậy, các tiếp cận là thiếtđặt các khóa chia sẻ lên trên các bộ giá trị đang tồn tại cho T1 là phù hợp vì nó sẽ cảithiện được khả năng thực thi của hệ thống. SQL cho phép người lập trình thực hiện lựachọn này- và những lựa chọn tương tự khác, chúng ta sẽ tìm hiểu trong phần tiếp theo.

Các tính chất của giao dịch trong SQL

Để cung cấp cho người lập trình khả năng điều khiển khóa trên các giao dịch của họ,SQL cho phép họ xác định ba tính chất của một giao dịch: phương thức truy cập, kíchthước chuẩn đoán, và mức cô lập. Kích thước chuẩn đoán chỉ ra số lượng các lỗi có thểđược ghi lại; chúng ta sẽ bàn thêm về tính chất này.

359/470

Nếu phương thức truy cập là READ ONLY, giao dịch này sẽ không được phép sửa cơsở dữ liệu. Vì thế, các câu lệnh INSERT, DELETE, UPDATE, và CREATE sẽ khôngđược phép thực thi. Nếu chúng ta phải thực hiện một trong số các câu lệnh này, phươngthức truy cập sẽ phải được thiết đặt là READ WRITE. Với những giao dịch có phươngthức truy cập là READ ONLY, chỉ cần thực hiện các khóa chia sẻ, vì thế nó sẽ tăng khảnăng thực hiện tương tranh.

Dựa vào mức độ ‘dung thứ’ với những dữ liệu không chính xác, mức cô lập đượcphân thành bốn loại: READ UNCOMMITTED, READ COMMITTED, REPEATABLEREAD, và SERIALIZABLE. Ảnh hưởng của những mức cô lập này được tổng kết trongHình 10. Trong ngữ cảnh này, dirty read và unrepeatable read được định nghĩa nhưthông thường.

Các mức cô lập của SQL-92

Mức cô lập cao nhất của giao dịch T là SERIALIZABLE. Mức cô lập này đảm bảo rằngT chỉ đọc những thay đổi được làm bằng các giao dịch đã thành công, không có giá trịnào được đọc hoặc viết bởi T lại được một giao dịch nào khác thay đổi cho đến khi Tthành công, và nếu T đọc một tập các giá trị thỏa mãn một vài điều kiện tìm kiếm, tậpnày không được thay đổi bởi các giao dịch khác cho đến khi T thành công (tức là, Ttránh được hiện tượng phantom).

Khi thực thi dựa trên khóa, một giao dịch SERIALIZABLE có được các khóa trước khiđọc hoặc ghi các đối tượng, bao gồm các khóa trên tập các đối tượng có yêu cầu thayđổi (xem Phần 17.5.1) và nắm các khóa này cho đến khi kết thúc, theo Strict 2PL.

REPEATABLE READ đảm bảo rằng T chỉ đọc những thay đổi được làm bằng các giaodịch đã thành công và không có giá trị nào được đọc hoặc ghi bởi T lại được một giaodịch khác thay đổi cho đến khi T thành công. Tuy nhiên, T có thể vẫn gặp hiện tượngphantom; ví dụ, trong khi T kiểm tra tất cả các bản ghi của Sailors có rating=1, giaodịch khác có thể thêm một bản ghi mới cho Sailors mà giao dịch T đã bỏ lỡ.

Một giao dịch REPEATABLE READ thiết đặt tập các khóa như là giao dịchSERIALIZABLE, nhưng nó không thực hiện việc khóa chỉ số; tức là, nó chỉ khóa nhữngđối tượng độc lập, không phải là tập các đối tượng. Chúng tôi trình bày về việc khóa chỉsố chi tiết trong Phần 17.5.1.

360/470

READ COMMITTED đảm bảo rằng T chỉ đọc những thay đổi được làm bởi các giaodịch đã thành công, và không có giá trị nào được viết bởi T lại được một giao dịch khácthay đổi cho đến khi T thành công. Tuy nhiên, giá trị được đọc bởi T có thể được sửabởi các giao dịch khác trong khi T vấn đang trong quá trình thực thi, và T có khả nănggặp phải hiện tượng phantom.

Giao dịch READ COMMITTED có được các khóa độc quyền trước khi thực hiện việcviết lên đối tượng và nắm giữ những khóa này cho đến khi kết thúc. Nó cũng có đượccác khóa chia sẻ trước khi đọc các đối tượng, nhưng những khóa này được giải phóngngay lập tức.

Giao dịch READ UNCOMMITTED T có thể đọc những đối tượng đang được giao dịchkhác thay đổi; rõ ràng, đối tượng này có thể được thay đổi trong khi T đang trong quátrình thực thi, và T rất có thể gặp phải vấn đề phantom.

Giao dịch READ UNCOMMITTED không có được khóa chia sẻ trước khi đọc các đốitượng; giao dịch này dễ gặp phải vấn đề phantom nhất; đến mức mà SQL ngăn cấm giaodịch này tự bản thân nó làm bất kỳ thay đổi nào – giao dịch READ UNCOMMITTEDyêu cầu phải có phương thức truy cập READ ONLY. Vì giao dịch này không có đượckhóa cho việc đọc các đối tượng và nó không được phép viết lên đối tượng (và vì thếkhóa độc quyền không bao giờ được yêu cầu), nên nó không bao giờ có bất kỳ yêu cầukhóa nào.

Mức cô lập SERIALIZABLE an toàn nhất và được nhiều giao dịch yêu cầu nhất. Tuynhiên, một số giao dịch có thể chạy với mức cô lập thấp hơn, và số lượng các khóa đượcyêu cầu nhỏ hơn sẽ góp phần để cải thiện khả năng thực thi của hệ thống. Ví du, mộttruy vấn thống kê yêu cầu tìm tuổi trung bình của các thủy thủ có thể chạy ở mức cô lậplà READ COMMITTED hoặc thậm chí ở mức READ UNCOMMITTE, bởi vì một vàigiá trị thiếu hoặc không chính xác sẽ không ảnh hưởng đáng kể đến kết quả cuối cùngdo số lượng thủy thủ lớn.

Mức cô lập và phương thức truy cập có thể được thiết đặt sử dụng lện SETTRANSACTION. Ví dụ, lệnh sau xác định giao dịch hiện tại là SERIALIZABLE vàREAD ONLY:

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE READ ONLY

Khi một giao dịch được khởi tạo, giá trị mặc định là SERIALIZABLE và READWRITE.

361/470

Giới thiệu về khôi phục sự cố

Quản lý sự cố của một DBMS có nhiệm vụ đảm bảo giao dịch là nguyên tử và bền vững.Nó đảm bảo tính nguyên tử bằng việc khôi phục lại những thao tác của các giao dịchchưa thành công, và bền vững bằng cách đảm bảo rằng tất cả thao tác của các giao dịchthành công vẫn được thực hiện đầy đủ nếu hệ thống gặp sự cố.

Khi DBMS khởi động lại sau sự cố, hệ thống quản lý khôi phục phải mang cơ sở dữ liệutrở về trạng thái nhất quán. Hệ thống quản lý sự cố có nhiệm vụ khôi phục lại nhữngthao tác của những giao dịch bị hủy bỏ. Để xem hệ thống khôi phục sự cố làm gì, chúngta cần phải hiểu những gì xảy ra trong suốt quá trình thực hiện bình thường.

Quản lý giao dịch của một DBMS điều khiển việc thực thi của các giao dịch. Trước khiđọc và ghi các đối tượng, các khóa phải được yêu cầu (và giải phóng ở thời điểm sauđó) tùy thuộc vào giao thức khóa được lựa chọn. Để đơn giản, chúng ta có giả sử sau:

Viết nguyên tử: Việc viết một trang nào đó lên đĩa là một thao tác nguyên tử.

Điều này ngụ ý rằng hệ thống sẽ không gặp sự cố trong quá trình viết. Trên thực tế, việcviết lên đĩa không có tính chất này, và nhiều bước phải được thực hiện trong quá trìnhkhởi tạo sau sự cố (Phần 18.6) để đảm bảo rằng việc ghi gần đây nhất lên một trang nàođó phải được hoàn thành thành công, và đối phó với những hậu quả nếu việc ghi nàykhông thành công.

Các khung dữ liệu bị lấy cắp và các trang bị cưỡng chế

Đối với việc viết lên các đối tượng, có hai câu hỏi sau nảy sinh:

1. Những thay đổi trên đối tượng O trong buffer pool được giao dịch T thực hiện có thểđược viết lên trên đĩa trước khi T thành công không? Việc viết này được thực hiện khigiao dịch khác muốn đưa vào một trang và hệ thống quản lý vùng đệm lựa chọn framechứa đối tượng O để thay thế. Nếu việc viết như vậy được phép, chúng ta nói rằng cáchtiếp cận steal được sử dụng. (Nói một cách thân mật, giao dịch thứ hai ‘lấy cắp (steal)’một frame từ T).

2. Khi một giao dịch thành công, chúng ta phải đảm bảo rằng tất cả các thay đổi nóđã làm với các đối tượng trong buffer pool được áp đặt tới đĩa ngay lập tức? Nếu vậy,chúng ta nói rằng cách tiếp cận force được sử dụng.

Đứng trên quan điểm thực thi của hệ thống quản lý khôi phục, đơn giản nhất là sử dụngmột hệ thống quản lý vùng đệm với cách tiếp cận là force, no-steal. Nếu cách tiếp cậnno-steal được sử dụng, chúng ta không phải khôi phục lại những thay đổi của giao dịchbị hủy bỏ (vì những thay đổi này chưa được ghi lên đĩa), và nếu cách tiếp cận force được

362/470

sử dụng, chúng ta khôi phục lại những thay đổi của giao dịch đã thành công nếu sự cốđến sau (bởi vì tất cả các thay đổi được đảm bảo đã được ghi lên đĩa ở thời điểm giaodịch thành công).

Tuy nhiên, những chính sách này có những nhược điểm quan trọng. Cách tiếp nhận no-steal cho rằng tất cả các trang được sửa bằng các giao dịch đang thực hiện đều có thểnằm trong buffer pool, giả sử này không thực tế. Còn cách tiếp cận force phải trả giácho I/O quá đắt. Nếu một trang được cập nhật liên tiếp bởi 20 giao dịch, nó sẽ được viếtlên đĩa 20 lần. Mặt khác, với cách tiếp cận no-force, việc sửa và viết lên đĩa một trangchỉ bằng một lần dù cho có 20 thao tác cập nhật nếu trang này nằm trọn vẹn trong bufferpool.

Vì những lý do này, hầu hết các hệ thống đều sử dụng cách tiếp cận steal, no-force. Vìthế, nếu frame bẩn và được lựa chọn để thay thế, những trang nằm trong frame này đượcviết lên đĩa ngay cả khi giao dịch đang sửa vẫn trong quá trình thực hiện (steal); thêmnữa, các trang trong buffer pool được sửa bằng một giao dịch nào đó không bắt buộcphải ghi lên đĩa khi giao dịch thành công (no-force).

Các bước khôi phục của một thực thi thông thường

Quản lý khôi phục của một DBMS duy trì một số thông tin trong suốt quá trình thực thithông thường để nó có thể đảm bảo thực hiện được các công việc cần thiết khi sự cố xảyra. Cụ thể, lịch sử của tất cả các thay đổi tới cơ sở dữ liệu được ghi lại một cách ổn định.Việc ghi lại này được thực hiện bằng cách duy trì nhiều bản sao của thông tin (có thểtrong các vùng khác nhau) trên các thiết bị lưu trữ như đĩa và băng từ.

Như những trình bày trong Phần 7, một điều quan trọng là đảm bảo rằng toàn bộ lịch sửcủa những thay đổi phải được lưu trữ trên các thiết bị an toàn trước khi những thay đổiđó thực sự được thực hiện. (Nhớ lại rằng cách thực thi này đã được biết đến là Write-Ahead Log, hay còn gọi là WAL).

Tinh chỉnh hệ thống khôi phục phụ: Thực thi của DBMS có thể có hiệu quả cao nhờvào các hệ thống khôi phục phụ. Người quản trị hệ thống có thể mất một vài bước đểtinh chỉnh những hệ thống này, như chính xác hóa kích thước của file lịch sử và quản lýnó trên đĩa như thế nào, điều khiển tốc độ các trang đệm được ghi lên đĩa, lựa chọn mộtchu kỳ checkpointing tốt và vv…

Thông tin lịch sử này có thể giúp hệ thống quản lý khôi phục phục hồi lại các thao táccủa các giao dịch chưa hoàn thành và các giao dịch bị hủy bỏ. Ví dụ, một giao dịch nàođó đã thành công trước khi sự cố xảy ra đã cập nhật xong tới bản sao của đối tượng trongbuffer pool, và thay đổi này chưa kịp viết lên đĩa vì nó sử dụng cách tiếp cận no-force.Những thay đổi này phải được xác định bằng cách sử dụng thông tin lịch sử này và sauđó thực hiện việc viết lên đĩa. Thêm nữa, những thay đổi của các giao dịch không thành

363/470

công trước khi sự cố xảy ra có lẽ đã được viết lên đĩa do cách tiếp cận steal. Những thayđổi này phải được xác định nhờ vào thông tin lịch sử này và sau đó khôi phục lại.

Khối lượng công việc trong quá trình khôi phục tương ứng với những thay đổi đã đượclàm bởi các giao dịch thành công mà chưa kịp ghi lên đĩa trước khi xảy ra sự cố. Đểgiảm thời gian dành cho khôi phục sự cố, DBMS định kỳ bắt buộc các trang đệm phảighi lên đĩa trong quá trình thực thi sử dụng một tiến trình nền (trong khi vẫn đảm bảorằng toàn bộ lịch sử ghi lại những thay đổi của những trang này phải được ghi lên đĩatrước tiên). Một tiến trình được gọi là checkpointing, lưu lại những thông tin về các giaodịch đang hoạt động và các trang buffer pool bẩn, cũng như giúp giảm thời gian khôiphục một sự cố. Checkpoints được trình bày trong Phần 18.5.

Tổng quan về ARIES

ARIES là một thuật toán khôi phục được thiết kế để phục vụ cách tiếp cận steal, no-force. Khi hệ thống khôi phục được yêu cầu sau khi một sự cố xảy ra, nó thực hiện babước. Trong bước Phân tích, nó xác định các trang bẩn trong buffer pool (tức là, nhữngthay đổi đã không được ghi lên đĩa) và các giao dịch đang hoạt động ở thời điểm xảy rasự cố. Trong bước Khôi phục lại, nó lặp lại tất cả các thao tác, khởi động lại từ một điểmthích hợp trong file lịch sử, và khôi phục tới trạng thái cơ sở dữ liệu ở thời điểm xảy rasự cố. Cuối cùng, trong bước Khôi phục lại, nó không thực hiện lại những thao tác củacác giao dịch chưa thành công, để cơ sở dữ liệu phản ánh những thao tác của các giaodịch đã thành công. Thuật toán ARIES được trình bày sâu hơn trong Chương 18.

Tính nguyên tử: Việc thực thi Rollback

Là quan trọng để nhận ra rằng hệ thống khôi phục phụ cũng có nhiệm vụ thực thi lệnhROLLBACK một giao dịch đơn. Thực tế, những công việc phức tạp trong quá trình khôiphục lại một giao dịch đơn được xác định trong bước Khôi phục lại. Tất cả các bản ghilịch sử ứng với một giao dịch nào đó được tổ chức trong một danh sách liên kết và có thểđược truy cập một cách hiệu quả theo thứ tự nghịch đảo để thuận lợi cho việc rollbackgiao dịch.

Câu hỏi tổng kết

Câu trả lời của những câu hỏi sau có thể được tìm thấy trong phần bên cạnh.

• Tính chất ACID là gì? Định nghĩa tính nguyên tử, tính nhất quán, tính cô lập,và tính bền vững và minh họa chúng thông qua các ví dụ. (Phần 1)

• Định nghĩa các khái niệm giao dịch, lịch trình, lịch trình đầy đủ và lịch trìnhtuần tự. (Phần 2)

• Vì sao DBMS thực hiện các giao dịch đồng thời một cách xen kẽ? (Phần 3)

364/470

• Khi nào hai thao tác trên cùng một đối tượng xung đột nhau? Định nghĩa nhữngdị thường có thể xảy ra do xung đột (đọc bẩn, đọc không thể lặp lại). (Phần 3)

• Lịch trình tuần tự là gì? Lịch trình có thể khôi phục là gì? Lịch trình nào có thểtránh được hủy bỏ chồng? Lịch trình nghiêm ngặt là gì? (Phần 3)

• Giao thức khóa là gì? Trình bày về giao thức khóa hai-pha nghiêm ngặt (Strict2PL). Bạn có thể nói gì về các lịch trình được giao thức này cho phép? (Phần4)

• Trình bày về việc ngăn chặn và hủy bỏ và giải thích nó quan trọng như thế nàotrong thực tế. (Phần 5)

• Thrashing là gì? DBA nên làm gì khi hệ thống gặp hiện tượng này? (Phần 5)• Throughtput có thể được tăng lên như thế nào? (Phần 5)• Các giao dịch được tạo và hủy bỏ như thế nào trong SQL? Savepoints là gì?

Các giao dịch chuỗi là gì? Giải thích savepoints và giao dịch chuỗi hữu dụng vìsao? (Phần 6)

• Vấn đề phantom là gì? Nó ảnh hưởng gì tới thực thi? (Phần 6.2)• Các tính chất nào của giao dịch có thể được người lập trình điều khiển trong

SQL? Trình bày về sự khác nhau giữa các phương thức truy cập và các mức côlập? Những vấn đề nào nên được đề cập trong việc lựa chọn phương thức truycập và mức cô lập cho một giao dịch nào đó? (Phần 6.3)

• Trình bày như thế nào các mức cô lập khác nhau được thực thi khi các khóađược thiết đặt. Bạn có thể nói gì về chi phí khóa tương ứng (Phần 6.3)

• Tính năng nào hệ thống quản lý khôi phục của DBMS cung cấp? Hệ thốngquản lý giao dịch làm gì? (Phần 7)

• Trình bày chính sách steal và force trong ngữ cảnh của quản lý bộ đệm. Chínhsách nào được sử dụng trong thực tế và nó ảnh hưởng đến khôi phục như thếnào? (Phần 7.1)

• Các bước khôi phục trong quá trình thực thi thông thường? DBA có thể điềukhiển gì để giảm thời gian khôi phục sau một sự cố? (Phần 7.2)

• Thông tin lịch sử được sử dụng trong rollback giao dịch và khôi phục sự cố nhưthế nào? (Phần 7.2, 7.3, và 7.4)

Bài tập

Trả lời tóm tắt những câu hỏi sau:

• Giao dịch là gì? Nó khác với chương trình bình thường khác (trong một ngônngữ lập trình như C) như thế nào?

• Định nghĩa những khái niệm sau: tính nguyên tử, tính nhất quán, tính cô lập, vàtính bền vững, lịch trình, viết mù, đọc bẩn, đọc không thể lặp lại, lịch trình cókhả năng tuần tự, lịch trình có khả năng phục hồi, lịch trình tránh hủy bỏchồng.

• Trình bày Strict 2PL.

365/470

• Vấn đề phantom là gì? Nó có thể xảy ra trong một cơ sở dữ liệu mà ở đó tậpcác đối tượng được cố định, chỉ có giá trị trong đó có thể thay đổi?

Câu trả lời cho mỗi câu hỏi như sau:

1. Một Giao dịch là một thực thi của một chương trình người dùng, và được DBMS xemnhư một chuỗi các thao tác. Các thao tác này có thể được thực hiện bằng một giao dịchnào đó bao gồm: các phép đọc và viết lên các đối tượng cơ sở dữ liệu, trong khi đó cácthao tác trong một chương trình thông thường có thể bao gồm dữ liệu đầu vào của ngườidùng, truy cập các thiết bị mạng, xây dựng giao diện người dùng, vv...

2. Từng khái niệm được mô tả như sau:

1. Nguyên tử (atomic): Tất cả các thao tác nằm trong giao dịch được thực hiệnthành công hoặc thất bại hoàn toàn. Người dùng không phải lo lắng về ảnhhưởng của các giao dịch chưa được thành công (giả sử, có sự cố xảy ra khi giaodịch này đang trong quá trình thực hiện).

2. Nhất quán: Mỗi giao dịch được thực thi không tranh chấp với các giao dịchkhác, phải đảm bảo tính chất nhất quán của cơ sở dữ liệu. DBMS thừa nhậnrằng tính nhất quán được đảm bảo trên mỗi giao dịch. Việc đảm bảo tính chấtnày của giao dịch là trách nhiệm của người dùng.

3. Cô lập: Người dùng nên có thể hiểu được một giao dịch mà không cần xem xétnhững ảnh hưởng của các giao dịch tương tranh khác đang chạy, thậm chíDBMS có thể chèn vào các thao tác khác vì những lý do thực thi. Tính chất nàyđôi khi được nói tới như là tính chấtcô lập.Các giao dịch được cô lập, hay còngọi là được bảo vệ từ những ảnh hưởng của các giao dịch tương tranh khác.

4. Bền vững: Khi DBMS thông báo cho người dùng biết rằng giao dịch đã thànhcông hoàn toàn, những ảnh hưởng của nó nên được duy trì ngay cả khi hệ thốnggặp sự cố trước khi tất cả những thay đổi này kịp lưu lại trên đĩa.

5. Lịch trình là một chuỗi các giao dịch (có thể xếp chồng).6. Viết mù là việc một giao dịch nào đó viết lên một đối tượng mà thậm chí

không đọc đối tượng này.7. Đọc bẩn xảy ra khi một giao dịch nào đó đọc một đối tượng mà đối tượng này

đang được thay đổi bằng một giao dịch chưa thành công khác.8. Đọc không thể lặp lại xảy ra khi một giao dịch nào đó không thể đọc cùng một

giá trị đối tượng nhiều hơn một lần, thậm chí giao dịch này không được phépthay đổi giá trị. Giả sử giao dịch T2 thay đổi giá trị của đối tượng A – đốitượng đang được đọc bằng một giao dịch T1 trong khi T1 vẫn đang trong quátrình xử lý. Nếu T1 cố gắng đọc giá trị A một lần nữa, nó sẽ có một kết quảkhác, mặc dù nó không thay đổi A.

9. Lịch trình có khả năng tuần tự trên một tập S của các giao dịch là một lịchtrình mà ảnh hưởng của nó trên bất kỳ minh họa cơ sở dữ liệu nhất quán nào

366/470

đều giống với lịch trình tuần tự hoàn toàn trên tập các giao dịch thành côngtrong S.

10. Lịch trình có khả năng phục hồi là một lịch trình mà trong đó một giao dịchcó thể được thành công chỉ sau khi tất cả các giao dịch khác đọc nó đã thànhcông.

11. Lịch trình tránh hủy bỏ chồng là một trong số các giao dịch chỉ đọc nhữngthay đổi của các giao dịch đã thành công. Một lịch trình như vậy không chỉ cókhả năng phục hồi, việc hủy bỏ một giao dịch có thể được hoàn thành màkhông hủy bỏ chồng các giao dịch khác.

3. Strict 2PL là một giao thức khóa được sử dụng rộng rãi nhất trong đó 1) Một giaodịch yêu cầu một khóa chia sẻ/ độc quyền trên một đối tượng trước khi nó đọc/ sửa đốitượng đó. 2) Tất cả các khóa mà giao dịch nắm bắt được giải phóng khi giao dịch đóthành công.

4. Vấn đề dữ liệu ma là tình trạng mà một giao dịch nào đó truy cập đến một tập cácđối tượng trong hai lần và nhìn thấy các kết quả khác nhau, mặc dù bản thân nó khôngthay đổi bất kỳ đối tượng nào và tuân thủ giao thức strick 2PL. Vấn đề này thường nảysinh trong các cơ sở dữ liệu động nơi mà một giao dịch không thể được giả sử rằng nóđược khóa tất cả các đối tượng theo một loại yêu cầu (ví dụ, tất cả các thủ thủ có xếphạng (rank) là 1; những thủy thủ mới có rank bằng 1 có thể được thêm vào bởi giao dịchthứ hai sau khi một giao dịch đã khóa tất cả các đối tượng liên quan). Nếu một tập cácđối tượng cơ sở dữ liệu được cố định lại và chỉ những giá trị của các đối tượng này cóthể được thay đổi, thì vấn đề dữ liệu ma không thể xảy ra vì giao dịch khác không thểthêm các đối tượng mới vào cơ sở dữ liệu.

Xem xét những thao tác sau được T1 thực hiện trên đối tượng X và Y của cơ sở dữ liệu:

R(X), W(X), R(Y), W(Y)

1. Cung cấp một ví dụ của giao dịch T2 mà khi chạy đồng thời với T1 nó sẽ ảnhhưởng tới T1.

2. Sử dụng Strict 2PL như thế nào sẽ tránh được sự ảnh hưởng giữa hai giao dịch.3. Strict 2PL được sử dụng trong rất nhiều hệ thống cơ sở dữ liệu. Cung cấp hai lý

do khiến nó được sử dụng rộng rãi.

Dành cho độc giả

Xem xét một cơ sở dữ liệu có hai đối tượng X và Y và giả sử rằng có hai giao dịch T1và T2. Giao dịch T1 đọc X và Y, sau đó ghi lên X. Giao dịch T2 đọc X và Y, sau đó ghilên cả X và Y.

1. Cho một ví dụ về một lịch trình chứa các thao tác của T1 và T2 trên đối tượngX và Y có thể dẫn đến xung đột ghi-đọc.

367/470

2. Cho một ví dụ về một lịch trình chứa các thao tác của T1 và T2 trên đối tượngX và Y có thể dẫn đến xung đột đọc-ghi.

3. Cho một ví dụ về một lịch trình chứa các thao tác của T1 và T2 trên đối tượngX và Y có thể dẫn đến xung đột ghi-ghi.

4. Với mỗi lịch trình trong ba lịch trình trên, chỉ ra rằng Strict 2PL không chophép lịch trình nào.

Câu trả lời cho mỗi câu hỏi như sau:

1. Lịch trình trong một xung đột ghi-đọc:

T2:R(X), T2:R(Y), T2:W(X), T1:R(X) ...

T1:R(X) ở đây là một phép đọc bẩn.

2. Lịch trình trong một xung đột đọc-ghi:

T2:R(X), T2:R(Y), T1:R(X), T1:R(Y), T1:W(X) ...

Bây giờ T2 sẽ có một phép đọc không có khả năng lặp trên X.

3. Lịch trình trong một xung đột ghi-ghi:

T2:R(X), T2:R(Y), T1:R(X), T1:R(Y), T1:W(X), T2:W(X) ...

Bây giờ T2 viết đè lên những dữ liệu chưa thành công.

4. Strict 2PL giải quyết những xung đột này như sau:

1. Trong S2PL, T1 không thể có một khóa chia sẻ trên X vì T2 sẽ không nắmkhóa độc quyền trên X. Vì thế, T1 sẽ không phải đợi cho đến khi T2 kết thúc.

2. Ở đây T1 không thể có một khóa độc quyền trên X bởi vì T2 sẽ không nắm giữkhóa chia sẻ hoặc khóa độc quyền trên X.

3. Như trên.

Chúng tôi gọi một giao dịch chỉ đọc các đối tượng trong cơ sở dữ liệu là giao dịch chỉ-đọc, ngược lại giao dịch này sẽ được gọi là giao dịch đọc-ghi. Trả lời tóm tắt những câuhỏi sau:

1. Lock thashing là gì và nó xảy ra khi nào?2. Cái gì xảy ra với throughput của hệ cơ sở dữ liệu nếu số lượng các giao dịch

đọc-ghi tăng lên?3. Cái gì xảy ra với throughput của hệ cơ sở dữ liệu nếu số lượng các giao dịch

chỉ-đọc tăng lên?

368/470

4. Trình bày ba cách tinh chỉnh hệ thống của bạn để làm tăng throughput giaodịch.

Dành cho độc giả.

Giả sử rằng DBMS nhận ra sự tăng lên (tăng một đối tượng có giá trị nguyên lên 1) vàgiảm đi như là các thao tác (ngoài các thao tác đọc và ghi thông thường). Một giao dịchlàm tăng giá trị một đối tượng nào đó mà không cần biết giá trị của đối tượng đó; tăngvà giảm này được gọi là viết mù. Ngoài hai khóa chia sẻ và khóa độc quyền, hai khóađặc biệt khác được hỗ trợ: Một đối tượng nào đó phải được khóa theo phương thức Itrước khi tăng nó lên và khóa theo phương thức D trước khi giảm nó. Khóa I tương thíchvới các khóa I và D khác trên cùng đối tượng, nhưng không tương thích với các khóa S(khóa chia sẻ) và X (khóa độc quyền).

1. Minh họa việc sử dụng các khóa I và D như thế nào để có thể tăng được sựtương tranh. (Chỉ ra một lịch trình sử dụng các khóa S và X được Strict 2PLcho phép. Giải thích cách sử dụng các khóa I và D như thế nào để có thể cónhiều thao tác được thực hiện xen kẽ, trong khi vẫn phải thỏa mãn Strict 2PL).

2. Giải thích cách Strick 2PL đảm bảo sự tuần tự khi có sự hiện diện của các khóaI và D.

Câu trả lời cho mỗi câu hỏi như sau:

1. Coi hai giao dịch sau như là ví dụ:

T1: Tăng A, Giảm B, Đọc C;

T2: Tăng B, Giảm A, Đọc C.

Nếu chỉ sử dụng giao thức 2PL, tất cả các thao tác là phiên bản của việc viết mù, chúngphải thực hiện các khóa độc quyền trên các đối tượng. Theo giao thức 2PL, T1 có mộtkhóa độc quyền trên A, nếu T2 bây giờ có một khóa độc quyền trên B, thì ở đây sẽ cómột khóa chết. Ngay cả khi T1 đủ nhanh để đạt được khóa độc quyền trên B trước, thìbây giờ T2 sẽ không bị đóng khối cho đến khi T1 kết thúc. Ở đây sẽ có ít xung đột. Nếukhóa I và D được sử dụng, vì I và D là tương thích, T2 đạt được khóa I trên A, và khóaD trên B; T2 có thể vẫn đạt được khóa I trên B, khóa D trên A; cả hai giao dịch có thểđược thực thi xen kẽ.

2. Các cặp thao tác xung đột là:

RW, WW, WR, IR, IW, DR, DW

Chúng ta biết rằng strict 2PL đề nghị ba cặp đầu tiên là cùng thứ tự trong một số lịchtrình tuần tự. Chúng ta có thể cũng chỉ ra rằng mặc dù có sự hiện diện của các khóa I và

369/470

D, strict 2PL cũng yêu cầu 4 cặp sau là cùng thứ tự trong một số lịch trình tuần tự. Nghĩvề khóa I (hoặc D) trong tình huống này như là khóa độc quyền, vì khóa I(D) khôngtương thích với các khóa S và X theo bất kỳ cách nào (tức là, không thể có khóa S hoặcX nếu một giao dịch khác đang có một khóa I hoặc khóa D). Vì thế sự tuần tự được đảmbảo.

Trả lời những câu hỏi sau: SQL hỗ trợ bốn mức cô lập và hai phương thức truy cập, nhưvậy có tổng số 8 sự kết hợp giữa mức cô lập và phương thức truy cập. Mỗi sự kết hợpđịnh nghĩa một lớp các giao dịch; những câu hỏi sau dựa vào 8 lớp này:

1. Xem xét bốn mức cô lập của SQL. Trình bày về những hiện tượng sau có thểxảy ra ở mỗi mức cô lập: đọc bẩn, đọc không thể lặp lại, vấn đề phantom.

2. Với mỗi mức cô lập, nêu những ví dụ về giao dịch có thể chạy an toàn ở mứccô lập này. Phương thức truy cập của giao dịch quan trọng vì sao?

Dành cho độc giả.

Xem xét lược đồ quan hệ dùng để đăng ký học tại trường đại học như sau:

Student(snum: integer, sname: string, major: string,level: string, age: integer) Class(name: string, meets_at:time, room: string, fid: integer) Enrolled(snum: integer,cname: string) Faculty (fid: integer, fname: string,deptid: integer)

Ý nghĩa của các quan hệ này rất dễ hiểu; ví dụ, Enrolled (Đăng ký) có một bản ghi ứngvới mỗi cặp student-class (sinh viên – lớp) để ghi lại thông tin sinh viên đăng ký lớphọc.

Với mỗi giao dịch sau đây, trình bày về mức cô lập bạn sẽ sử dụng và giải thích vì saobạn chọn nó?

1. Một sinh viên nào đó được (xác định bằng snum) đăng ký lớp học có tên là‘Introduction to Database Systems’

2. Thay đổi đăng ký của một sinh viên nào đó (xác định bằng snum) từ lớp nàysang một lớp khác.

3. Gán một khoa mới (xác định bằng fid) cho lớp có số lượng sinh viên ít nhất.4. Với mỗi lớp, chỉ ra số lượng sinh viên đăng ký trong lớp đó.

Câu trả lời cho mỗi câu hỏi như sau:

370/470

• Bởi vì chúng ta đang thêm một dòng mới vào bảng Enrolles, nên chúng takhông cần bất kỳ khóa nào trên các dòng đang tồn tại. Vì thế chúng ta sẽ sửdụng READ UNCOMMITTED.

• Vì chúng ta đang cập nhật một dòng đang tồn tại trong bảng Enrolles, chúng tacần một khóa độc quyền trên dòng đang được cập nhật. Vì thế chúng ta sẽ sửdụng READ COMMITTED.

• Để ngăn chặn những giao dịch thực hiện việc thêm và cập nhật bảng Enrollestrong khi chúng ta đang đọc nó (tránh xảy ra trường hợp gặp phải dữ liệu ma),chúng ta sẽ cần sử dụng SERIALIZABLE.

• Như trên.

Xem xét lược đồ sau:

Suppliers(sid: integer, sname: string, address: string)Parts(pid: integer, pname: string, color: string)Catalog(sid: integer, pid: integer, cost: real)

Quan hệ Catalog (Danh mục) liệt kê giá các sản phẩm (Parts) của các nhà cung cấp(Suppliers).

Với mỗi giao dịch sau đây, trình bày về mức cô lập bạn sẽ sử dụng và giải thích vì saobạn chọn nó?

1. Giao dịch thêm một sản phẩm mới vào danh mục.2. Giao dịch tăng giá một sản phẩm của một nhà cung cấp.3. Giao dịch xác định tổng số mặt hàng của một nhà cung cấp nào đó.4. Giao dịch chỉ ra ứng với mỗi sản phẩm, nhà cung cấp nào cung cấp sản phẩm

này với giá thấp nhất.

Dành cho độc giả.

Xem xét cơ sở dữ liệu có lược đồ quan hệ như sau:

Suppliers(sid: integer, sname: string, address: string)Parts(pid: integer, pname: string, color: string)Catalog(sid: integer, pid: integer, cost: real)

Quan hệ Catalog (Danh mục) liệt kê giá các sản phẩm (Parts) của các nhà cung cấp(Suppliers).

Xem xét ba giao dịch T1, T2 và T3; T1 luôn có mức cô lập là SERIALIZABLE. Chúngta cho T1 và T2 chạy đồng thời và sau đó cho T1 và T2 chạy đồng thời. Nêu một minhhọa cơ sở dữ liệu và các câu lệnh SQL cho T1 và T2 mà kết quả của việc chạy T2 ở

371/470

mức cô lập đầu tiên khác với chạy T2 ở mức cô lập thứ hai. Đồng thời xác định lược đồchung của T1 và T2 và giải thích vì sao kết quả này khác nhau.

SERIALIZABLE versus REPEATABLE READ. REPEATABLE READversus READ COMMITTED. READ COMMITTED versus READUNCOMMITTED.

Câu trả lời cho mỗi câu hỏi như sau

1. Giả sử có một minh họa cơ sở dữ liệu của bảng Catalog và các câu lệnh SQL như sau:

SELECT * FROM Catalog C WHERE C.cost < 100 EXCEPT (SELECT* FROM Catalog C WHERE C.cost < 100 ) INSERT INTO catalog(sid, pid, cost) VALUES (99, 38, 75.25)

Khi chúng ta sử dụng SERIALIZABLE, chúng ta sẽ hy vọng rằng câu lệnh SQL đầutiên không trả về gì cả. Nhưng thay vì đó chúng ta sử dụng REPEATABLE READ, thìvấn đề dữ liệu ma có thể sẽ xảy ra khi thêm một bộ dữ liệu mới vào bảng này, vì thếcâu lệnh SQL đầu tiên trả về kết quả sai (trong trường hợp có một bộ dữ liệu được thêmbằng câu SQL thứ hai).

2. Giả sử rằng cùng một minh họa dữ liệu như trên và các câu lệnh SQL chỉ ra như sau:

UPDATE Catalog SET cost = cost * 0.95 WHERE sid = 31UPDATE Catalog SET cost = cost * 0.95 WHERE sid = 31

Khi chúng ta sử dụng READ COMMITTED trên các câu lệnh SQL trên, việc đọc khôngthể lặp lại có thể xảy ra dẫn đến một giá trị không đúng được gán vào chi phí. Nhưngvấn đề này không thể xảy ra khi chúng ta sử dụng REPEATABLE READ.

3. Giả sử rằng cùng một minh họa dữ liệu như trên và các câu lệnh SQL chỉ ra như sau:

(giả sử READ UNCOMMITTED có thể viết tới cơ sở dữ liệu):

372/470

UPDATE Catalog SET cost = cost * 0.95 SELECT C.sid, C.pidFROM Catalog C WHERE C.cost = 36.22

Khi chúng ta sử dụng READ UNCOMMITTED trên các câu lệnh SQL trên, việc đọcbẩn có thể xảy ra vì câu lệnh SQL đầu tiên có thể được kết thúc trong khi câu lệnhthứ nhất đang đọc. Nhưng vấn đề này không thể xảy ra khi chúng ta sử dụng READUNCOMMITTED.

Tài liệu tham khảo

Khái niệm về giao dịch và những hạn chế của chúng được trình bày trong [332]. Môhình giao dịch chính thống được tổng quát hóa từ một vài mô hình giao dịch có từ trướcđược công bố trong [182].

Khóa hai-pha được giới thiệu trong [252], một bài báo cũng trình bày về các khái niệmgiao dịch, phantoms, và khóa. Những vấn đề của thực thi tuần tự được trình bày trong[92, 581].

Một tài liệu tuyệt vời trình bày rất sâu về xử lý giao dịch có thể tìm trong [90] và [770].[338] là một tài liệu kinh điển về chủ đề này.

373/470

Tinh chỉnh lược đồ và các dạng chuẩn hoáThiết kế cơ sở dữ liệu mức khái niệm cung cấp cho chúng ta một tập các lược đồ quanhệ và các ràng buộc toàn vẹn, đây có thể được coi là điểm bắt đầu tốt để đến được kếtquả thiết kế cơ sở dữ liệu cuối cùng. Những thiết kế ban đầu này phải được tinh chỉnhbằng việc đưa các ràng buộc toàn vẹn vào thiết kế chi tiết chứ không đơn thuần là cáccấu trúc của mô hình ER, điều kiện thực hiện và các luồng thực hiện đặc trưng. Trongchương này, chúng ta bàn về việc sử dụng các ràng buộc toàn vẹn để tinh chỉnh lược đồkhái niệm đạt được do chuyển từ một thiết kế mô hình ER thành một tập các quan hệ.Luồng thực hiện và những vấn đề khác được trình bày trong Chương sau.

Chúng ta tập trung vào một phần quan trọng của các ràng buộc gọi là các phụ thuộchàm. Những loại khác của các ràng buộc toàn vẹn, ví dụ các phụ thuộc đa trị và các phụthuộc liên kết cũng cung cấp những thông tin hữu ích. Đôi khi chúng có thể phát hiện racác dư thừa mà các phụ thuộc hàm không tự mình phát hiện được. Chúng ta trình bàynhững phụ thuộc hàm này một cách tóm tắt.

Chương này được tổ chức như sau. Phần 1 là tổng quan về cách tiếp cận tinh chỉnh lượcđồ đã trình bày trong chương này. Chúng tôi giới thiệu các phụ thuộc hàm trong Phần 2.Phần 3 chỉ ra những lý do để có được các phụ thuộc hàm bổ sung từ một tập phụ thuộchàm cho trước. Phần 4 giới thiệu về các dạng chuẩn của quan hệ; một dạng chuẩn củamột quan hệ được dùng làm thước đo về sự dư thừa trong quan hệ đó. Một quan hệ códư thừa có thể được tách ra thành các quan hệ nhỏ hơn vẫn chứa những thông tin đónhưng không còn dư thừa nữa. Chúng ta bàn về việc tách quan hệ và đặc điểm của nótrong Phần 5, và các quan hệ có thể tách thành các quan hệ nhỏ hơn ở dạng chuẩn mongmuốn trong Phần 6.

Phần 7 trình bày một số ví dụ minh hoạ việc chuyển một thiết kế mô hình ER thành cáclược đồ quan hệ, tuy nhiên các lược đồ này có thể vẫn còn sự dư thừa, và chúng ta bànvề cách thức tinh chỉnh những lược đồ này để loại bỏ dư thừa. Phần 8 trình bày về nhữngloại phụ thuộc khác trong thiết kế cơ sở dữ liệu. Chúng tôi tổng kết những trình bày vềchuẩn hoá dữ liệu bằng việc nghiên cứu ví dụ Cửa hàng Internet trong Phần 9.

Giới thiệu về tinh chỉnh lược đồ

Bây giờ, chúng tôi trình bày tổng quan về các vần đề mà tinh chỉnh lược đồ có thể giảiquyết được và một cách tiếp cận tinh chỉnh dựa trên phân rã quan hệ. Mặc dù phân rãcó thể tránh được dư thừa, nhưng nó có thể dẫn tới các vấn đề khác của bản thân nó nênchúng ta phải thận trọng khi sử dụng.

374/470

Các vấn đề tồn tại khi có sự dư thừa

Lưu trữ dư thừa thông tin, tức là một thông tin được lưu nhiều lần trong cơ sở dữ liệu cóthể dẫn tới một số vấn đề sau:

• Lưu trữ dư thừa: Một số thông tin được lưu trữ lặp đi lặp lại.• Dị thường khi cập nhật: Nếu một bản sao của dữ liệu lặp này được cập nhật,

thì cơ sở dữ liệu có thể xảy ra hiện tượng không nhất quán, trừ khi tất cả cácbản sao này được cập nhật tương tự.

• Dị thường khi thêm dữ liệu: Bạn có thể gặp phải trường hợp không thể thêmđược thông tin vào vì muốn thêm những thông tin này lại cần phải thêm nhữngthông tin khác không liên quan đến nó.

• Dị thường khi xoá dữ liệu: Khi bạn xoá một bộ dữ liệu, bạn có thể làm mấtnhững dữ liệu khác lẽ ra không được xóa.

Xem xét một quan hệ được chuyển từ thực thể Hourly_Emps trong Chương 2:

Hourly-Emps(ssn, name, lot, rating, hourly_wages, hours_worked)

Trong chương này, để ngắn gọn chúng ta bỏ qua thông tin về kiểu thuộc tính, vì chúngta chỉ tập trung vào các thuộc tính nào có trong quan hệ. Chúng ta cũng gọi tắt tên cácthuộc tính bằng ký tự đầu tiên của mỗi thuộc tính. Ví dụ, chúng ta gọi lược đồ quan hệcủa Hourly_Emps là SNLRWH (trong đó WH là viết tắt của thuộc tính hourly_wages).

Khoá của Hourly_Emps là ssn. Thêm nữa, giả sử rằng thuộc tính hourly_wages đượcxác định bởi thuộc tính rating. Tức là, nếu chúng ta biết giá trị của rating thì chúng tacũng sẽ suy ra được giá trị của hourly_wages. Ràng buộc toàn vẹn này là một ví dụ vềmột phụ thuộc hàm. Nó dẫn đến khả năng có sự dư thừa trong quan hệ Hourly_Emps,như minh hoạ trong Hình 1.

Một minh hoạ của quan hệ Hourly_Emps

Nếu một giá trị xuất hiện trong cột rating của hai bộ giá trị, thì ràng buộc toàn vẹn nóivới chúng ta rằng cùng một giá trị phải xuất hiện trong cột hourly_wages ứng với bộ giátrị đó. Sự dư thừa này dẫn đến một số vấn đề như đã trình bày phía trên:

375/470

• Lưu trữ dư thừa: Giá trị rating bằng 8 thì hourly_wages sẽ bằng 10 và cặp giátrị này lặp lại ba lần.

• Dị thường khi cập nhật: Giá trị hourly_wages trong bộ đầu tiên có thể được cậpnhật trong khi các hai bộ giá trị khác không được cập nhật tương ứng.

• Dị thường khi thêm: Chúng ta không thể thêm một bộ giá trị của một nhân viêntrừ khi chúng ta biết được hourly_wages tương ứng với rating của nhân viênđó.

• Dị thường khi xoá: Nếu chúng ta xoá tất cả các bộ giá trị ứng với một giá trịrating nào đó (ví dụ, chúng ta xóa các bộ giá trị Smethurst và Guldu), chúng tasẽ làm mất cặp giá trị rating và hourly_wages tương ứng của nó.

Lý tưởng mà nói chúng ta muốn một lược đồ không có sự dư thừa, nhưng đôi khi chúngta vẫn chấp nhận một lược đồ có sự dư thừa do những ưu điểm về mặt thực thi của nó.Chúng ta sẽ quyết định điều này một cách sáng suốt.

Các giá trị rỗng

Việc sử dụng các giá trị rỗng có thể giải quyết được một số vấn đề trên. Như chúng tanhìn thấy trong ví dụ, các giá trị rỗng không thể cung cấp một giải pháp trọn vẹn, nhưngchúng có thể cung cấp một số hỗ trợ.

Xem xét ví dụ quan hệ Hourly_Emps. Rõ ràng, các giá trị rỗng không thể giúp chúng taloại bỏ được lưu trữ dư thừa hoặc là dị thường khi cập nhật. Nhưng dường như nó lạigiải quyết được vấn đề dị thường khi thêm bộ và dị thường khi xoá bộ. Trong minh hoạnày, để đối phó với ví dụ dị thường khi thêm bộ, chúng ta có thể thêm một bộ giá trịcủa nhân viên (employee) với giá trị rỗng trong trường hourly_wages. Tuy nhiên, nhữnggiá trị rỗng này không giải quyết được tất cả các dị thường khi thêm bộ. Ví dụ, chúngta không thể thêm vào một giá trị hourly_wage nào đó ứng với một rating trừ khi đã cómột nhân viên có rating này, bởi vì chúng ta không thể lưu một giá trị rỗng trong trườngssn vì đây là khoá chính. Tương tự, để đối phó với ví dụ dị thường khi xoá bộ, chúngta có thể nghĩ đến việc lưu một bộ giá trị với các giá trị rỗng trong tất cả các trường trừtrường rating và hourly_wages. Tuy nhiên, giải pháp này không thể thực hiện được vìtrường khoá chính là ssn không thể nhận giá trị rỗng. Vì thế, các giá trị rỗng không phảilà một giải pháp có thể giải quyết được vấn đề dư thừa, mặc dù chúng có thể được sửdụng để hỗ trợ trong một số trường hợp.

Phân rã một lược đồ quan hệ

Sự dư thừa tăng lên khi các thuộc tính trong quan hệ có nhiều ràng buộc với nhau. Cácphụ thuộc hàm (trong trường hợp này là các ràng buộc toàn vẹn) có thể được sử dụng đểđịnh nghĩa tình trạng này và được sử dụng để tinh chỉnh lược đồ. Rất nhiều vấn đề sinhra do dư thừa có thể được hoá giải bằng việc phân rã lược đồ quan hệ lớn thành nhữnglược đồ quan hệ ‘nhỏ hơn’.

376/470

Việc phân rã một lược đồ quan hệ R bao gồm việc thay thế một lược đồ quan hệ bằnghai (hay nhiều) lược đồ quan hệ nhỏ hơn chứa các thuộc tính của R và khi kết hợp cácthuộc tính trong các lược đồ quan hệ nhỏ hơn này lại thì ta sẽ được lược đồ quan hệ Rban đầu. Trong phần này chúng ta xem xét việc phân rã thông qua vài ví dụ sau.

Chúng ta có thể phân rã quan hệ Hourly_Emps thành hai quan hệ nhỏ hơn:

Hourly-Emps2(ssn, name, lot, rating, hours_worked)

Wages(rating, hourly_wages)

Những minh hoạ dữ liệu của các quan hệ này tương ứng với minh hoạ dữ liệu của quanhệ Hourly_Emps trong Hình 1 được chỉ ra trong Hình 2.

Minh hoạ của quan hệ Hourly_Emps2 và Wages

Bằng cách lưu trữ như thế này chúng ta có thể dễ dàng ghi lại giá trị của hourly_wagesứng với bất kỳ giá trị nào của rating bằng việc bổ sung một bộ giá trị vào Wages dùcho là không có nhân viên nào có giá trị rating này trong minh hoạ hiện tại của quanhệ Hourly_Emps. Việc thay đổi lương (wage) tương ứng với xếp hạng (rating) của nhânviên được thực hiện chỉ đơn giản bằng việc cập nhật duy nhất một bộ giá trị của Wages.Cách làm này hiệu quả hơn rất nhiều so với phải cập nhật nhiều bộ giá trị như trong thiếtkế ban đầu, và nó loại bỏ những vấn đề tiềm tàng nảy sinh do sự không nhất quán dữliệu.

Các vấn đề liên quan đến việc phân rã

Trừ khi chúng ta rất cẩn thận, việc phân rã một lược đồ quan hệ có thể tạo ra nhiều khókhăn hơn là mang lại lợi ích. Hai câu hỏi quan trọng sau đây phải thường xuyên đượclặp đi lặp lại:

1. Quan hệ này có cần phải phân rã không?2. Những vấn đề nảy sinh do phân rã mang đến là gì?

377/470

Để trả lời câu hỏi thứ nhất, một số dạng chuẩn đã được đề xuất đối với quan hệ. Nếumột lược đồ quan hệ nằm trong số một trong những dạng chuẩn này, chúng ta sẽ biếtđược có những vấn đề nào không thể nảy sinh. Việc xem xét dạng chuẩn của một lượcđồ quan hệ có thể giúp chúng ta đi đến quyết định có hoặc không phân rã nó. Nếu chúngta quyết định một lược đồ quan hệ nào đó phải được phân rã, thì chúng ta phải chọn mộtphân rã cụ thể nào đó (ví dụ, một tập các quan hệ nhỏ hơn sẽ được thay thế cho mộtquan hệ ban đầu).

Đối với câu hỏi thứ hai, hai tính chất của việc phân rã phải được xem xét. Tính chất kếtnối không mất thông tin sẽ giúp chúng ta khôi phục lại được bất kỳ minh hoạ dữ liệucủa quan hệ ban đầu nào từ các minh hoạ dữ liệu của các quan hệ nhỏ hơn. Tính chấtbảo toàn phụ thuộc hàm có thể giúp chúng ta áp đặt bất kỳ ràng buộc nào lên quan hệban đầu bằng việc áp đặt một số ràng buộc lên trên các quan hệ nhỏ hơn. Tức là, chúngta không cần thực hiện việc nối các quan hệ nhỏ hơn lại để kiểm tra xem một ràng buộcnào đó trên quan hệ ban đầu có bị vi phạm không.

Trên quan điểm của việc thực hiện, các truy vấn trên quan hệ gốc có thể yêu cầu chúngta phải kết nối các quan hệ nhỏ hơn đã được tách ra. Nếu những truy vấn này thườngxuyên được yêu cầu, thì phân tách quan hệ có thể không được chấp nhận. Trong trườnghợp này, chúng ta nên lựa chọn giải pháp là sống chung với vấn đề dư thừa và khôngnên phân rã quan hệ. Một điểm quan trọng là bạn phải ý thức được các vấn đề tiềm tàngnảy sinh do lưu trữ dư thừa và bạn phải làm một số việc để tránh chúng (ví dụ, bạn cóthể thêm một số kiểm tra trong khi lập trình). Trong một số trường hợp, việc phân ra cóthể cải thiện được việc thực hiện. Điều này xảy ra trong trường hợp, ví dụ, hầu hết cáctruy vấn và các kiểm tra cập nhật chỉ trên một quan hệ con nào đó. Chúng ta không bànđến những ảnh hưởng của việc phân rã đối với thực thi truy vấn trong chương này; vấnđề này sẽ được tìm hiểu trong Phần 20.8.

Mục đích của chúng ta trong chương này là giải thích một số khái niệm quan trọng vàcác hướng dẫn khi thiết kế dựa trên lý thuyết của phụ thuộc hàm. Một người thiết kế cơsở dữ liệu tốt nên hiểu rõ ràng về các dạng chuẩn, kỹ thuật phân rã quan hệ và các vấnđề tiềm tàng khi thực hiện phân rã. Ví dụ, người thiết kế thường đặt ra các câu hỏi như:Quan hệ đang ở dạng chuẩn nào? Phân tách có bảo toàn được phụ thuộc hàm không?Mục đích của chúng ta là giải thích khi nào cần nhấn mạnh những câu hỏi này và ý nghĩacủa các câu trả lời.

Phụ thuộc hàm

Phụ thuộc hàm là một kiểu ràng buộc toàn vẹn cung cấp khái niệm của khoá. Giả sử Rlà một lược đồ quan hệ và X và Y là hai tập con không rỗng của các thuộc tính trong R.Chúng ta nói rằng một minh hoạ r của R thoả mãn phụ thuộc hàm X→Y nếu hai bộ bấtkỳ t1 và t2 trong r thoả mãn:

378/470

Nếu t1.X =t2.X thì t1.Y=t2.Y.

Chúng ta sử dụng ký hiệu t1.X cho phép chiếu của bộ giá trị t1 trên các thuộc tính trongX. Một Phụ thuộc hàm X → Y nói rằng nếu hai bộ giá trị có cùng giá trị của X thì nó sẽcó cùng giá trị của Y.

Hình 3 minh hoạ ý nghĩa của phụ thuộc hàm AB → C bằng việc chỉ ra một trường hợpthoả mãn phụ thuộc hàm này. Hai bộ giá trị đầu tiên chỉ ra rằng một phụ thuộc hàmkhông giống như một ràng buộc khoá: Mặc dù phụ thuộc hàm này không bị vi phạm,AB rõ ràng không phải là khoá của quan hệ này. Các bộ giá trị thứ ba và bốn minh hoạrằng nếu hai bộ giá trị khác nhau trong trường A hoặc trường B thì chúng có thể khácnhau trong trường C mà không vi phạm ràng buộc này. Tuy nhiên, nếu chúng ta thêmmột bộ á a1, b1, c2, d2 ñ vào minh hoạ dữ liệu này thì kết quả sau khi thêm sẽ vi phạmràng buộc này; để nhìn thấy vi phạm này, bạn hãy so sánh bộ giá trị đầu tiên trong hìnhminh hoạ với bộ giá trị mới thêm.

Minh hoạ dữ liệu thoả mãn ràng buộc AB→C

Nhớ lại rằng minh hoạ của một quan hệ chỉ đúng khi nó thoả mãn tất cả các ràng buộctoàn vẹn, bao gồm tất cả các phụ thuộc hàm. Như ghi nhớ trong Phần 3.2, các ràng buộctoàn vẹn được xác định dựa trên các nguyên tắc quản lý của bài toán. Khi xem một minhhoạ của một quan hệ, chúng ta có thể phát hiện ra được nó vi phạm một phụ thuộc hàmnào đó. Tuy nhiên, chúng ta không thể suy luận ra được có một phụ thuộc hàm tồn tạitrong một quan hệ khi nhìn vào nhiều minh hoạ của nó, bởi vì một phụ thuộc hàm giốngnhư ràng buộc toàn vẹn, nó phải được thoả mãn trên mọi minh hoạ dữ liệu của quan hệ.

Ràng buộc khoá chính là một trường hợp đặc biệt của phụ thuộc hàm. Các thuộc tínhtrong khoá đóng vai trò của X, và tập tất cả các thuộc tính trong quan hệ đóng vai trò củaY. Tuy nhiên, trong định nghĩa phụ thuộc hàm không yêu cầu X là tập tối thiểu; trongkhi đó ràng buộc khoá chính thì yêu cầu X là tập tối thiểu. Nếu X → Y, trong đó Y làtập tất cả các thuộc tính, và có một số tập con V của X trong đó V→ Y thì X gọi là mộtsiêu khoá.

Trong phần còn lại của chương này, chúng ta có một số ví dụ về các phụ thuộc hàmkhông phải là các ràng buộc khoá.

379/470

Những tranh luận về phụ thuộc hàm

Cho một tập các phụ thuộc hàm trên một lược đồ quan hệ R, trong một số trường hợp cóthể có các phụ thuộc hàm phát sinh trên R. Xem xét ví dụ:

Workers(ssn, name, lot, did, since)

Chúng ta biết rằng ssn→ did, vì ssn là khoá, và có phụ thuộc hàm did→lot trên Workers.Do đó, trong bất kỳ minh hoạ đúng của Workers, nếu hai bộ giá trị có cùng giá trị ssn,chúng phải có cùng giá cùng giá trị did (do phụ thuộc hàm đầu tiên), và bởi vì chúng cócùng giá trị của did, chúng phải có cùng giá trị của lot (do phụ thuộc hàm thứ hai). Vìthế, phụ thuộc hàm ssn → lot cũng phải có trên Workers.

Chúng ta giả sử rằng f là một phụ thuộc hàm được suy diễn từ tập phụ thuộc hàm F nếutất cả các minh hoạ của f thoả mãn tất cả các phụ thuộc hàm trong F; tức là, f có tất cảcác phụ thuộc hàm mà F nắm giữ. Ghi nhớ rằng tất cả các minh hoạ dữ liệu của f phảithoả mãn tất cả các phụ thuộc hàm trong F.

Bao đóng của một tập phụ thuộc hàm

Một tập của tất cả các phụ thuộc hàm được suy diễn từ một tập F đã cho của các phụthuộc hàm được gọi là bao đóng của F, ký hiệu là F+. Một câu hỏi quan trọng là làmthế nào chúng ta có thể suy diễn, hoặc là tính toán ra được bao đóng này.Câu trả lời ởđây rất đơn giản, rõ ràng. Có ba quy tắc sau, họi là hệ tiên đề Armstrong, có thể được ápdụng lặp đi lặp lại để có thể đưa ra được tất cả các phụ thuộc hàm có thể suy diễn từ F.Chúng ta sử dụng X, Y và Z là tập các thuộc tính trên lược đồ quan hệ R.

• Phản xạ: Nếu X ⊇ Y, thì X→ Y• Tăng trưởng: Nếu X→Y, thì XZ→ YZ với bất kỳ tập Z nào.• Bắc cầu: Nếu X→Y và Y→ Z, thì X→Z.

Định lý 1: Hệ tiên đề Armstrong là đúng, vì nó suy diễn ra chỉ một tập F+ khi áp dụngtrên một tập F của các phụ thuộc hàm. Chúng cũng là đầy đủ, vì áp dụng lặp đi lặp lạicác quy tắc này sẽ suy diễn ra tất cả các phụ thuộc hàm trong tập bao đóng F+.

Tính đúng đắn của hệ tiên đề Armstrong có thể được chứng minh dễ dàng. Tính đầy đủkhó chứng minh hơn, xem bài tập 17.

Sử dụng một số quy tắc bổ sung có thể giúp ta tính được tập F+ dễ dàng hơn.

• Luật hợp: Nếu X→Y và X→Z thì X→YZ.• Luật phân rã: Nếu X→ YZ thì X→Y và X→Z.

380/470

Những luật bổ sung này không phải là cốt lõi; tính đúng đắn của chúng có thể đượcchứng minh sử dụng hệ tiên đề Armstrong.

Để minh hoạ việc sử dụng những luật này của phụ thuộc hàm, xem xét một lược đồ quanhệ có các phụ thuộc hàm A→B và B→C. Trong một phụ thuộc hàm trival, phía phải chỉchứa các thuộc tính xuất hiện bên phía trái; những phụ thuộc hàm này luôn chứa tínhphản xạ. Sử dụng tính phản xạ chúng ta có thể đưa ra tất cả các phụ thuộc hàm trivial códạng:

X→Y trong đó Y ⊆ X, X ⊆ ABC, và Y ⊆ ABC.

Do tính bắc cầu ta có A→C. Do áp dụng các luật mở rộng chúng ta có các phụ thuộchàm nontrivial:

AC→ BC, AB→ AC, AB→ CB

Xem xét ví dụ tiếp theo về quan hệ Contracts:

Contracts ( contractid , supplierid, projectid, deptid, partid, qty, value)

Chúng ta gọi tắt lược đồ này là CSJDPQV tương ứng với các thuộc tính.

Lược đồ này có các ràng buộc toàn vẹn sau:

• C là khoá: C→ CSJDPQV.• JP→ C.• SD→P.

Một số phụ thuộc hàm nằm trong bao đóng của tập phụ thuộc hàm này là:

Từ JP→ C, C→ CSJDPQV và luật bắc cầu, ta có thể suy ra JP→ CSJDPQV.

Từ SD→P và các luật tăng trưởng, ta có thể suy ra SDJ→ JP.

Từ SDJ→ JP, JP → CSJDPQV, và luật bắc cầu, ta có SDJ→ CSJDPQV (Lưu ý, ở đâyta không rút gọn được J ở hai phía. Phụ thuộc hàm không giống như phép tính số học!)

Chúng ta có thể suy diễn ra một số phụ thuộc hàm trong tập bao đóng bằng cách sư dụngluật tăng trưởng và phân rã. Ví dụ, từ C→ CSJDPQV sử dụng phân rã chúng ta có thểsuy ra:

C→ C, C→S, C→ J, C→ D, …

Cuối cùng, chúng ta có một các phụ thuộc hàm trivial từ luật phản xạ.

381/470

Bao đóng của thuộc tính

Nếu chúng ta chỉ muốn kiểm tra một phụ thuộc hàm nào đó, giả sử X→Y có nằm trongbao đóng F của các phụ thuộc hàm, chúng ta có thể làm điều này rất hiệu quả mà khôngcần tính bao đóng F. Đầu tiên chúng ta tính bao đóng của thuộc tính X+ trên tập phụthuộc hàm F, đó là một tập của các thuộc tính A trong đó X→ A có thể được suy diễnsư dụng hệ tiên đề Armstrong. Thuật toán trong Hình 4 đưa ra bao đóng của một tập Xcác thuộc tính.

Thuật toán tính bao đóng của tập thuộc tính X

Định lý 2 Thuật toán chỉ ra trong Hình 4 tính được tập thuộc tính là bao đóng X+ củatập thuộc tính X trên tập phụ thuộc hàm F.

Chứng minh định lý này được đề cập trong Bài 15. Thuật toán này có thể được thay đổiđể tìm ra các khoá bằng cách bắt đầu từ tập X chỉ chứa một thuộc tính đơn và dừng ngaykhi bao đóng chứa tất cả các thuộc tính trong lược đồ quan hệ. Bằng việc thay đổi thuộctính khởi đầu và thứ tự các phụ thuộc hàm mà thuật toán xem xét chúng ta sẽ nhận đượctất cả các khoá dự tuyển.

Các dạng chuẩn

Cho một lược đồ quan hệ, chúng ta cần khẳng định xem đó có phải là một thiết kế tốthay là chúng ta cần phải phân rã nó thành nhiều quan hệ nhỏ hơn. Khẳng định này phảiđược dẫn dắt dựa trên hiểu biết về những vấn đề gì sẽ xảy ra với lược đồ hiện tại. Đểcung cấp dẫn dắt này, có một vài dạng chuẩn được đưa ra. Nếu một lược đồ quan hệlà một trong những dạng chuẩn này, chúng ta biết rằng có những vấn đề với dữ liệu sẽkhông bao giờ xuất hiện.

Các dạng chuẩn đưa ra dựa trên tập các phụ thuộc hàm bao gồm dạng chuẩn 1 (1NF),dạng chuẩn 2 (2NF), dạng chuẩn 3 (3NF) và dạng chuẩn Boyce-Codd (BCNF).

Các dạng chuẩn này được sắp xếp theo thự tự tăng dần của các yêu cầu hạn chế dữ liệu:Tất cả các quan hệ ở dạng BCNF thì cũng đã ở dạng 3NF, tất cả các quan hệ ở dạng 3NFthì cũng đã ở dạng 2NF, tất cả các quan hệ ở dạng 2, 3NF thì cũng đã ở dạng 1NF. Mộtquan hệ ở dạng chuẩn 1 nếu tất cả các trường chứa những giá trị nguyên tử. Mặc dù một

382/470

số hệ thống cơ sở dữ liệu mới đang làm suy yếu đi yêu cầu này, nhưng trong chươngnày chúng ta giả sử rằng yêu cầu này là bắt buộc. 2NF là chuẩn được quan tâm chủ yếutrong quá khứ. Trên quan điểm thiết kế cơ sở dữ liệu, 3NF và BCNF là hai chuẩn quantrọng.

Trong khi nghiên cứu về các dạng chuẩn, tập các phụ thuộc hàm đóng vai trò hết sứcquan trọng. Xem xét một lược đồ quan hệ R có các thuộc tính ABC và có phụ thuộc hàmA→B. Như vậy, nếu có một vài bản ghi có cùng giá trị của A thì cũng phải có cùng giátrị của B. Khả năng dư thừa có thể dự đoán được bằng cách sử dụng thông tin về phụthuộc hàm.

Chúng ta bàn về cách phát hiện dư thừa bằng sử dụng thông tin phụ thuộc hàm. TrongPhần 8, chúng ta trình bày về các ràng buộc toàn vẹn phức tạp hơn gọi là MVD, các phụthuộc hàm liên kết và các dạng chuẩn dựa trên chúng.

Dạng chuẩn Boyce-Codd

Giả sử R là một lược đồ quan hệ, F là một tập phụ thuộc hàm trên R, X là tập thuộc tínhcủa R, và A là một thuộc tính nào đó của R. R ở dạng chuẩn Boyce Codd nếu, với tất cảcác phụ thuộc hàm X→A trong F, một trong những câu sau là đúng:

• A∈ X; có nghĩa là đó là một phụ thuộc hàm trivial, hoặc• X là một siêu khoá.

Trong một quan hệ BCNF, mỗi một bộ giá trị có thể được nghĩ như một thực thể hoặcmột mối quan hệ, xác định bằng một khoá và các thuộc tính còn lại. Nếu chúng ta sửdụng hình oval để biểu diễn một thuộc tính hoặc một tập các thuộc tính và vẽ các cungđể xác định các phụ thuộc hàm thì một quan hệ ở dạng BCNF có cấu trúc như Hình 5,để đơn giản minh hoạ này giả sử rằng chỉ có một khoá. (Nếu có một vài khoá dự tuyển,mỗi khoá dự tuyển đóng vai trò của KHOÁ, các thuộc tính khác không có một thuộctính nào nằm trong khoá dự tuyển.)

Các phụ thuộc hàm trong quan hệ BCNF

BCNF đảm bảo rằng không có dư thừa nào được phát hiện mà chỉ sử dụng thông tinvề phụ thuộc hàm. Vì thế nó là dạng chuẩn tốt nhất (đứng trên quan điểm dư thừa dữliệu) nếu chúng ta chỉ đưa vào thông tin về phụ thuộc hàm. Nhận xét này được minh hoạtrong Hình 6.

383/470

Minh hoạ quan hệ ở dạng BCNF

Hình này chỉ ra (hai bộ giá trị trong) minh hoạ của một quan hệ có ba thuộc tính X, Y vàA. Có hai bộ có cùng giá trị trong cột X. Bây giờ giả sử rằng chúng ta biết rằng minh hoạnày thoả mãn một phụ thuộc hàm là X→A. Chúng ta có thể nhìn thấy rằng một trong sốcác bộ giá trị có một giá trị a trong cột A. Chúng ta có thể suy diễn ra giá trị trong cột Acủa bộ giá trị thứ hai? Sử dụng phụ thuộc hàm này, chúng ta có thể kết luận rằng bộ giátrị thứ hai sẽ có giá trị là a trong cột này.

Nhưng trạng thái này không phải là một ví dụ của sự dư thừa? Chúng ta thấy giá trị ađược lưu trữ hai lần. Điều này có được xảy ra trong một quan hệ ở dạng BCNF? Câutrả lời là KHÔNG! Nếu quan hệ này ở dạng BCNF, vì A được suy ra từ X nên X phảilà một khoá. (Ngược lại, phụ thuộc hàm X→ A sẽ vi phạm BCNF). Nếu X là một khoá,thì y1=y2, có nghĩa la hai bộ giá trị này phải giống hệt nhau. Vì một quan hệ được địnhnghĩa là một tập các bộ giá trị, chúng ta không thể có hai bản ghi giống hệt nhau và tìnhtrạng chỉ ra trong Hình 6 không thể xuất hiện.

Vì thế, nếu một quan hệ ở dạng BCNF, tất cả các trường của tất cả các bộ giá trị ghi lạimột phần của thông tin, nó không thể được suy diễn (sử dụng chỉ các phụ thuộc hàm) từcác giá trị trong tất cả các trường khác trong (tất cả các bộ của) minh hoạ quan hệ đó.

Dạng chuẩn ba

Giả sử R là một lược đồ quan hệ, F là một tập các phụ thuộc hàm trên R, X là tập concác thuộc tính của R, và A là một thuộc tính nào đó của R. R ở dạng chuẩn ba nếu, vớitất cả các phụ thuộc hàm X→ A trong F, một trong những điều kiện sau là đúng:

• A∈ X; có nghĩa là đó là một phụ thuộc hàm trivial, hoặc• X là một siêu khoá, hoặc• A là một phần của một khoá nào đó của R.

Định nghĩa của 3NF tương tự với định nghĩa của BCNF, chỉ khác nhau ở điều kiện thứba. Tất cả các quan hệ ở BCNF thì cũng ở 3NF. Để hiểu được điều kiện thứ ba, nhớ lạirằng khoá của một quan hệ là một tập tối thiểu các thuộc tính có thể xác định được tất cảcác thuộc tính của quan hệ. A phải là một phần của khoá (bất kỳ khoá nào nếu quan hệnày có nhiều khoá). Việc tìm ra tất cả các khoá của một lược đồ quan hệ là một bài toánNP-đầy đủ, vì thế khó có thể xác định được một lược đồ quan hệ có ở dạng 3NF không.

384/470

Giả sử rằng có một phụ thuộc hàm X→A dẫn đến quan hệ vi phạm 3NF. Có hai trườnghợp:

• X là một tập con hoàn toàn của một khoá K nào đó. Phụ thuộc hàm như thế nàyđôi khi được gọi là phụ thuộc hàm bộ phận. Trong trường hợp này, chúng talưu cặp (X,A) là dư thừa. Ví dụ, xem xét quan hệ Reserves có các thuộc tínhSBDC như trong Phần 7.4. Khoá duy nhất là SBD, va chúng ta có phụ thuộchàm S→ C. Chúng ta lưu lại mã số thẻ tín dụng của một thủy thủ nhiều lầnbằng với số lần phục vụ của thuỷ thủ đó.

• X không phải là tập con hoàn toàn của bất kỳ khoá nào. Phụ thuộc hàm như thếnày đôi khi được gọi là phụ thuộc hàm bắc cầu, vì nó có nghĩa là chúng ta cómột chuỗi các phụ thuộc hàm K→X→A. Ví dụ, xem xét quan hệ Hourly_Empsvới các thuộc tính SNLRWH trong phần 7.1. Khoá chỉ là S, nhưng có một phụthuộc hàm R→W, như vậy chúng ta có chuỗi phụ thuộc hàm S→ R→W. Hậuqủa là chúng ta không thể lưu được một bản ghi về nhân viên S có rating R màkhông biết lương tính theo giờ (hourly wage) ứng với rating này. Điều này dẫnđến các dị thường khi thêm, xóa và sửa dữ liệu.

Các phụ thuộc hàm bộ phận được minh hoạ trong Hình 7, và phụ thuộc hàm bắc cầuđược minh hoạ trong Hình 8.

Phụ thuộc hàm bộ phận

Phụ thuộc hàm bắc cầu

Tất cả các lược đồ quan hệ có thể được phân rã thành một tập các quan hệ ở dạng 3NF.Điều này không đúng với các quan hệ ở BCNF. Có lẽ vì thế mà chúng ta thoả hiệp làkhi thiết kế các quan hệ nên đưa về dạng chuẩn 3. Như trong Chương 20, chúng ta đôikhi chấp nhận cả những quan hệ chưa phải là chuẩn 3 vì những lý do liên quan đến thựcthi hệ thống.

385/470

Không giống BCNF, sự dư thừa có thể xảy ra với 3NF. Những vấn đề liên quan đến sựtồn tại của các phụ thuộc hàm bộ phận và bắc cầu, nếu có một phụ thuộc hàm nontrivialX→ A và X không là một siêu khoá, lúc này quan hệ này ở 3NF vì A là một phần củamột khoá nào đó. Để hiểu được điều này, chúng ta cùng tìm hiểu quan hệ Reserves cócác thuộc tính SBDC và một phụ thuộc hàm S→C minh hoạ ràng buộc một thuỷ thủ sửdụng một thẻ tín dụng duy nhất để nhận tiền phục vụ của mình. S không phải là mộtkhoá, và C không phải là một phần của một khoá nào đó. (Thực tế, chỉ có một khoálà SBD). Do đó, quan hệ này không ở 3NF; cặp (S,C) lưu trữ dư thừa. Tuy nhiên, nếuchúng ta biết rằng thẻ tín dụng sẽ xác định duy nhất một chủ nhân, chúng ta sẽ có phụthuộc hàm C→S, có nghĩa là CBD cũng là một khoá của Reserves. Vì thế, phụ thuộchàm S→ C không vi phạm 3NF, và Reserves ở dạng 3NF. Tuy nhiên, trong tất cả cácbộ giá trị chứa cùng giá trị S, cặp (S,C) bị lưu trữ dư thừa.

Chúng ta nhận thấy rằng định nghĩa của dạng chuẩn 2 về cơ bản không cho phép tồn tạicác phụ thuộc hàm bộ phận. Vì thế, nếu một quan hệ ở dạng chuẩn ba (chuẩn không chophép tồn tại cả phụ thuộc hàm bộ phận và phụ thuộc hàm bắc cầu) thì nó cũng ở dạngchuẩn hai.

Tính chất của sự phân rã

Phân rã là một công cụ cho phép chúng ta loại bỏ dư thừa. Như ghi nhớ trong Phần 1.3,tuy nhiên, vấn đề quan trọng là phải kiểm tra để phân rã này không phát sinh những vấnđề mới. Cụ thể, chúng ta nên kiểm tra xem việc phân rã này có thể cho phép chúng takhôi phục lại được quan hệ gốc không, và nó có cho phép chúng ta kiểm tra lại các ràngbuộc toàn vẹn một cách hiệu quả không. Chúng ta sẽ bàn đến những tính chất này trongphần tiếp theo.

Phân rã không mất kết nối

Giả sử R là một lược đồ quan hệ và F là tập các phụ thuộc hàm trên R. Một phân rã Rthành hai lược đồ có các tập thuộc tính X và Y được gọi là một phân rã không mất kếtnối trên tập F nếu, với tất cả các minh hoạ r của R thoả mãn các phụ thuộc hàm trong F,thì π X(r) π Y(r) = r. Nói các khác, chúng ta có thể khôi phục lại quan hệ ban đầu từnhững quan hệ đã phân rã.

Bằng việc thay thế minh hoạ r trong Hình 9 bằng các minh hoạ πSP(r) và πPD(r), chúngta thấy mất một số thông tin. Chúng ta có thể thấy rằng các bộ giá trị (s1, p1, d3) và (s3,p1, d1) không được quản lý. Vì thế, sự phân rã của lược đồ SPD thành SP và PD là cómất mát nếu như minh hoạ r trong hình này là đúng. (Quan sát ví dụ tương tự của quanhệ Contracts trong Phần 2.5.3).

Tất cả phân rã loại bỏ dư thừa phải là các phân rã không mất thông tin. Kiểm tra đơngiản sau đây rất hữu ích:

386/470

Định lý 3 Giả sử R là một quan hệ và F là tập các phụ thuộc hàm trên R. Sự phân rã Rthành các quan hệ con với tập thuộc tính tương ứng là R1 và R2 không mất thông tin nếuvà chỉ nếu F+ chứa phụ thuộc hàm R1 Ç R2 →R1 hoặc phụ thuộc hàm R1Ç R2 → R2.

Xem xét quan hệ Hourly_Emps một lần nữa. Nó có các thuộc tính SNLRWH, va phụthuộc hàm R→W làm quan hệ vi phạm 3NF. Chúng ta loại bỏ vi phạm này bằng cáchphân rã quan hệ thành hai quan hệ nhỏ hơn SNLRH và RW. Vì R là thuộc tính chungcủa cả hai quan hệ được phân rã và có phụ thuộc hàm R→W nên phân rã này là phân rãkhông mất kết nối.

Ví dụ này minh hoạ một quan sát phổ biến đi kèm với Định lý 3:

Nếu R có phụ thuộc hàm X→Y và X Ç Y là rỗng, thì phân rã R thành R-Y và XY làphân rã không mất mát.

X xuất hiện trong cả R-Y (vì X Ç Y bằng rỗng) và XY, và nó là một khoá của XY.

Một quan sát quan trọng khác, chúng ta phát biểu mà không chứng minh, phải làm vớicác phân rã lặp đi lặp lại. Giả sử rằng một quan hệ R được phân rã thành R1 và R2 thôngqua phép phân rã không mất kết nối, và R1 được phân rã thành R11 và R12 thông quamột phép phân rã không mất mát khác. Vì thế, phép phân rã R thành R11, R12 và R2 làphép phân rã không mất kết nối; bằng việc nối R11 và R12 chúng ta khôi phục lại đượcR, và sau đó nối R1 với R2 ta khôi phục lại được R.

Phân rã bảo toàn phụ thuộc hàm

Xem xét quan hệ Contracts có các thuộc tính CSJDPQV trong Phần 3.1. Các phụ thuộchàm của quan hệ này là: C→ CSJDPQV, JS→ C, và SD → P. Vì SD không phải là mộtkhoá nên phụ thuộc hàm SD→P là nguyên nhân làm cho quan hệ này vi phạm BCNF.

Chúng ta có thể phân rã Contracts thành hai lược đồ quan hệ nhỏ hơn là CSJDQV vàSDP để giải quyết vi phạm này; phân rã này không mất kết nối. Tuy nhiên có một vấnđề ở đây. Chúng ta có thể thực thi ràng buộc toàn vẹn JP → C dễ dàng khi một bộ giátrị được thêm vào quan hệ Contracts thì đảm bảo rằng không tồn tại bộ giá trị nào cócùng giá tri JP nhưng lại khác giá trị C. Khi chúng ta phân rã Contracts thành CSJDQVvà SDP, việc thực thi ràng buộc này yêu cầu một phép kết nối đắt của hai quan hệ khicó bất kỳ một bộ giá trị nào được thêm vào CSJDQV. Chúng ta nói rằng phân rã này làkhông bảo toàn phụ thuộc hàm.

Để định nghĩa phân rã bảo toàn phụ thuộc hàm một cách chính xác, chúng tôi giới thiệukhái niệm về phép chiếu của các phụ thuộc hàm.

Giả sử R là một lược đồ quan hệ được phân rã thành hai lược đồ có tập thuộc tính là Xvà Y tương ứng, F là tập các phụ thuộc hàm trên R. Phép chiếu của F trên X là một tập

387/470

các phụ thuộc hàm trong bao đóng F+ (không chỉ là F) mà chỉ gồm các thuộc tính trongX. Chúng ta ký hiệu phép chiếu của F trên tập thuộc tính X là FX. Ghi nhớ rằng một phụthuộc hàm U→ V nằm trong F+ chỉ khi tất cả các thuộc tính của U và V nằm trong X.

Phép phân rã của lược đồ quan hệ R (với các phụ thuộc hàm F) thành các lược đồ vớicác tập thuộc tính X và Y là phép phân rã bảo toàn phụ thuộc hàm nếu (FXÈFY)+=F+.Tức là, nếu chúng ta lấy các phụ thuộc hàm trong FX và F¬¬Y và tính bao đóng củaphép hợp giữa chúng, chúng ta sẽ được tất cả các phụ thuộc hàm trong bao đóng của F.Vì thế, chúng ta cần thực thi chỉ những ràng buộc trong FX và FY; tất cả các phụ thuộchàm trong F+ chắc chắn sẽ thoả mãn. Để thực thi FX, chúng ta chỉ cần kiểm tra nhữngquan hệ X (khi thêm bản ghi vào quan hệ này). Để thực thi FY, chúng ta chỉ cần kiểmtra quan hệ Y.

Để đánh giá đúng sự cần thiết phải xem xét bao đóng F+ trong khi tính phép chiếu củaF, giả sử rằng một quan hệ R có các thuộc tính ABC được phân rã thành hai quan hệAB và BC. Tập phụ thuộc hàm F trên R bao gồm A→B, B→C và C→A. Ở đây A→Bở trong FAB và B→C ở trong FBC. Nhưng phép phân rã này có bảo toàn phụ thuộc hàmkhông? Điều gì xảy ra đối với C→A?

Bao đóng của F chứa tất cả các phụ thuộc hàm trong F cộng với A→C, B →A và C→B.Kết quả là, FAB cũng chứa B→A và FBC chứa C→B. Vì thế, FAB È FBC chứa A→B, B→ C, B → A, và C → B. Bao đóng của tập phụ thuộc hàm trong FAB và FBC bây giờbao gồm C → A (được suy ra từ C → B, B → A, và luật bắc cầu). Vì thế, phép phân rãnày bảo toàn được phụ thuộc hàm C → A.

Định nghĩa này cung cấp cho chúng ta thuật toán dễ hiểu để kiểm tra một phép phân rãnào đó có bảo tồn phụ thuộc hàm không. (Thuật toán này có độ phức tạp là hàm mũ củakích thước tập phụ thuộc hàm. Thuật toán có độ phức tạp đa thức được xem xét trongBài tập 9.)

Chúng ta bắt đầu phần này bằng một ví dụ của phép phân rã không mất kết nối nhưngkhông bảo toàn phụ thuộc hàm. Các phép phân rã khác bảo toàn phụ thuộc hàm nhưnglại mất kết nối. Ví dụ đơn giản là quan hệ có các thuộc tính ABC và phụ thuộc hàmA→B và quan hệ này được phân rã thành AB và BC.

Chuẩn hoá

Để hiểu được các khái niệm này cần phải hiểu được vai trò của các dạng chuẩn hoá vàviệc phân rã nó trong thiết kế cơ sở dữ liệu, chúng ta xem xét các thuật toán được sửdụng để chuyển một quan hệ thành các quan hệ con ở BCNF hoặc 3NF. Nếu một lượcđồ quan hệ không ở BCNF, nó có thể được chuyển thành tập các lược đồ quan hệ BCNFbằng phép phân rã không mất kết nối. Nhưng đáng tiếc, phép phân rã này có thể không

388/470

bảo toàn phụ thuộc hàm. Tuy nhiên, phép phân rã một lược đồ quan hệ thành các lượcđồ quan hệ con ở dạng 3NF luôn bảo toàn được phụ thuộc hàm và không mất kết nối.

Phép phân rã thành BCNF

Bây giờ chúng ta trình bày một thuật toán để phân rã một lược đồ quan hệ R với tập phụthuộc hàm F thành một tập các lược đồ quan hệ ở dạng BCNF:

1. Giả sử rằg R không ở BCNF. Giả sử X ⊂ R, A là một thuộc tính đơn trong R,và X→A là một phụ thuộc hàm gây ra sự vi phạm BCNF. Phân rã R thành R-Avà XA.

2. Nếu R-A hoặc XA không ở BCNF, thì phân rã chúng tiếp tục bằng cách thựchiện đệ quy thuật toán này.

R-A là ký hiệu của tập các thuộc tính của R trừ thuộc tính A, và XA là ký hiệu của haithuộc tính X và A. Vì X→A vi phạm BCNF, nó không phải là phụ thuộc hàm trivial;thêm nữa, A là một thuộc tính đơn. Vì thế, A không nằm trong X; tức là XÇA bằng rỗng.Vì thế, mỗi phân rã trong Bước 1 là phép phân rã không mất kết nối.

Tập các phụ thuộc hàm liên quan đến R-A và XA là phép chiếu của F trên các thuộc tínhcủa chúng. Nếu một trong số các quan hệ mới không phải BCNF, chúng ta tiếp tục phânrã chúng trong Bước 2. Phép phép phân rã này cuối cùng cũng tạo ra được một tập cáclược đồ quan hệ ở BCNF. Thêm nữa, phép nối các quan hệ thông qua thuật toán này sẽcho ta được quan hệ ban đầu. (tức là, phép phân rã này không mất mát kết nối.)

Xem xét quan hệ Contracts có các thuộc tính CSJDPQV và khoáC. Chúng ta được cungcấp các phụ thuộc hàm JP → C và SD → P. Bằng việc sử dụng phụ thuộc hàm SD → Pđể thực hiện phân rã, chúng ta có hai lược đồ SDP và CSJDQV. SDP ở dạng BCNF. Giảsử rằng chúng ta cũng có ràng buộc là từ một dự án ta suy ra được đơn vị tài trợ: J → S.Như vậy, lược đồ CSJDQV không ởBCNF. Vì thế, chúng ta tiếp tục phân rã nó thành JSvà CJDQV. Tất cả các lược đồ quan hệ SDP, JS, và CJDQV ởBCNF, và tập các lược đồnày là kết quả của phép phân rã không mất kết nối của CSJDQV.

Các bước của quá trình phân rã này có thể được biểu diễn dưới dạng một cây như Hình10. Gốc của cây là quan hệ ban đầu CSJDPQV, và các lá là các quan hệ ở BCNF- kếtquả của thuật toán phân rã: SDP, JS, và CSDQV. Như quan sát trên hình, mỗi nút trunggian là các con của nó sinh ra do phụ thuộc hàm được chỉ ra phía dưới nút.

389/470

Phân rã CSJDQV thành SDP, JS, và CJDQV

Dư thừa trong BCNF

Phân rã CSJDQV thành SDP, JS, và CJDQV không bảo toàn phụ thuộc hàm. Phụ thuộchàm JP→C không thể được bảo toàn mà không có kết nối. Một cách để giải quyết tìnhtrạng này là thêm một quan hệ có các thuộc tính CJP. Nhưng hậu quả của giải pháp nàylà lưu trữ dư thừa thông tin.

Một điểm tinh tế: Mỗi lược đồ CJP, SDP, JS, và CJDQV đều ở BCNF, không có dư thừanào có thể dự đoán được mà chỉ sử dụng thông tin phụ thuộc hàm. Cụ thể, nếu chúng tanối các minh hoạ quan hệ của SDP và CJDQV và thực hiện phép chiếu lấy ra các thuộctính CJP, chúng ta phải có chính xác minh hoạ quan hệ này trên lược đồ CJP. Chúng tanhìn trong Phần 4.1 ở đây không có dư thừa trong một quan hệ BCNF đơn. Ví dụ nàychỉ ra rằng dư thừa có thể vẫn xảy ra trên các quan hệ chéo mặc dù không có dư thừatrong từng quan hệ.

Những lựa chọn trong việc phân rã thành BCNF

Giả sử có một vài phụ thuộc hàm vi phạm BCNF. Tuỳ thuộc vào các phụ thuộc hàm nàychúng ta có thể lựa chọn bước phân rã tiếp theo, chúng ta có thể thu được tập các quanhệ BCNF khác nhau tuỳ theo cách chúng ta lưa chọn thứ tự thực hiện các phụ thuộchàm. Xem xét Contracts. Chúng ta vừa phân rã nó thành SDP, JS, và CJDQV. Giả sửchúng ta lựa chọn cách phân rã quan hệ ban đầu CSJDPQV thành JS và CJDPQV, dựavào phụ thuộc hàm J → S. Chỉ còn hai phụ thuộc hàm trên CJDPQV là JP → C và phụthuộc hàm khoá là C→CJDPQV. Vì JP là một khoá nên CJDPQV ở BCNF. Vì thế, lượcđồ JS và CJDPQV là kết quả của phép phân rã không mất kết nối của quan hệ Contractsthành các quan hệ BCNF.

390/470

Những bài học ở đây là lý thuyết của phụ thuộc hàm, nó nói cho chúng ta khi nào cósự dư thừa và cung cấp cho chúng ta những manh mối về các phân rã có thể được sửdụng để giải quyết vấn đề này, nhưng nó không thể phân biệt được sự khác nhau giữanhững khả năng phân rã. Người thiết kế phải xem xét những khả năng này và lựa chọnmột trong số đó dựa vào ngữ cảnh của ứng dụng.

BCNF và Sự bảo toàn phụ thuộc hàm

Đôi khi, sự phân rã thành các quan hệ BCNF không bảo tồn được các phụ thuộc hàm.Ví dụ, xem xét một lược đồ quan hệ SBD, trong đó S (Sailor) là thuỷ thủ đã phục vụtrên tàu B (Boat) vào ngày D (Date). Nếu chúng ta có một phụ thuộc hàm SB→D (mộtthuỷ thủ phục vụ trên một tàu suốt cả ngày) và D→B, SBD không ở BCNF vì D khôngphải là khoá. Nếu chúng ta có gắng phân rã nó thì chúng ta không thể bảo tồn được phụthuộc hàm SB→D.

Phân rã thành 3NF

Rõ ràng, cách tiếp cận chúng ta đã trình bày về phân rã không mất kết nối thành các quanhệ BCNF cũng sẽ áp dụng được để phân rã thành 3NF mà không mất kết nối. (Chúngta có thể dừng lại dễ dàng hơn nếu chúng ta chấp nhận phân rã một quan hệ thành cácquan hệ con chỉ ở 3NF). Nhưng cách tiếp cận này không đảm bảo sẽ bảo toàn được phụthuộc hàm.

Một thay đổi đơn giản nhưng có thể thu được một phân rã thành các quan hệ 3NF màthoả mãn cả hai điều kiện: bảo tồn phụ thuộc hàm và không mất kết nối. Trước khichúng ta trình bày về thay đổi đơn giản này, chúng tôi cần giới thiệu khái niệm về phủtối thiểu của một tập phụ thuộc hàm.

Phủ tối thiểu của một tập phụ thuộc hàm

Một phủ tối thiểu của một tập phụ thuộc hàm F là một tập G của các phụ thuộc hàm thoảmãn:

1. Tất cả các phụ thuộc hàm trong F đều ở dạng X→A, trong đó A là một thuộctính đơn.

2. Bao đóng F+ bằng bao đóng G+.3. Nếu chúng ta nhận được tập H của các phụ thuộc hàm từ tập G bằng việc xoá

một hoặc nhiều phụ thuộc hàm hoặc xoá các thuộc tính từ một phụ thuộc hàmtrong G thì F+ ≠ H+.

Phủ tối thiểu của một tập phụ thuộc hàm F là một tập phụ thuộc hàm tương đương vàtối thiểu theo hai khía cạnh: (1) Tất cả các phụ thuộc hàm là nhỏ nhất có thể; có nghĩa làmỗi thuộc tính ở phía trái là thực sự cần đến và phía phải chỉ có một thuộc tính đơn. (2)Bao đóng của tất cả các phụ thuộc hàm ở trong đó bằng với F+.

391/470

Ví dụ, giả sử F là một tập các phụ thuộc hàm:

A→B, ABCD → E, EF → G, EF → H, và ACDF → EG.

Đầu tiên, chúng ta viết lại phụ thuộc hàm ACDF → EG để có được các phụ thuộc hàmmà bên phải chỉ là các thuộc tính đơn:

ACDF → E và ACDF → G.

Tiếp theo, xem xét phụ thuộc hàm ACDF→G. Phụ thuộc hàm có thể được suy diễn từcác phụ thuộc hàm sau:

A→ B, ABCD → E và EF → G.

Vì thế, chúng ta có thể xoá nó. Tương tự, chúng ta có thể xoá ACDF→ E. Xem xét tiếpABCD→ E. Vì có A→B, chúng ta có thể thay nó bằng ACD→E. Vì thế, phủ tối thiểucủa F là tập:

A→ B, ACD → E, EF → G, và EF → H.

Ví dụ trước cung cấp một thuật toán để tính được phủ tối thiểu của một tập phụ thuộchàm F:

1. Đưa các phụ thuộc hàm về dạng chuẩn tắc: Tập phụ thuộc hàm G chỉ chứa cácphụ thuộc hàm mà bên phải chỉ có một thuộc tính đơn.

2. Tối thiểu hoá phía trái của từng phụ thuộc hàm: Với mỗi phụ thuộc hàm trongG, kiểm tra mỗi thuộc tính ở phía trái để xem có thể xoá được nó mà vẫn bảotoàn sự tương đương với F+.

3. Xoá các phụ thuộc hàm dư thừa: Kiểm tra mỗi phụ thuộc hàm còn lại trong Gđể xem có thể xoá được nó mà vẫn bảo toàn được sự tương đương với F+.

Ghi nhớ rằng thứ tự áp dụng các phụ thuộc hàm có thể mang đến các phủ tối thiểu khácnhau; có thể có một vài phủ tối thiểu của một tập phụ thuộc hàm.

Một điểm quan trọng, chúng ta cần phải tối thiểu hoá phía bên trái của các phụ thuộchàm trước khi kiểm tra các phụ thuộc hàm dư thừa. Nếu hai bước này bị đảo ngược, tậpphụ thuộc hàm cuối cùng có thể vẫn chứa một số phụ thuộc hàm dư thừa (tức là, nó chưaphải là phủ tối thiểu), như minh hoạ ví dụ sau. Giả sử F là một tập các phụ thuộc hàm,mỗi phụ thuộc hàm đều đã ở dạng chuẩn tắc:

ABCD → E, E → D, A → B, và AC → D.

Quan sát thấy rằng ở đây không có phụ thuộc hàm nào dư thừa; nếu chúng ta kiểm traphụ thuộc hàm dư thừa trước, chúng ta sẽ có phủ tối thiểu vẫn chính là tập này. Phía trái

392/470

của phụ thuộc hàm ABCD→E có thể được thay thế bằng AC mà vẫn đảm bảo tươngđương với F+, và chúng ta sẽ dừng lại ở đây nếu chúng ta kiểm tra phụ thuộc hàm dưthừa trước khi tối thiểu hoá phía trái. Tuy nhiên, tập phụ thuộc hàm này không phải làphủ tối thiểu.

AC→E, E→D, A→B, và AC→D.

Hai phụ thuộc hàm đầu tiên có thể suy ra được phụ thuộc hàm cuối cùng do luật bắccầu, vì thế ta có thể xoá được nó mà vẫn bảo toàn được sự tương đương với F+. AC→Dchỉ trở nên dư thừa sau khi chúng ta thay thế ABCD→E bằng AC→E. Nếu chúng ta tốithiểu phía trái trước sau đó mới kiểm tra các phụ thuộc hàm nào dư thừa thì chúng ta sẽnhận được một tập gồm ba phụ thuộc hàm đầu tiên trong danh sách phía trên, đây mớilà phủ tối thiểu thực sự.

Phân rã về 3NF bảo toàn phụ thuộc hàm

Trở lại vấn đề phân rã một quan hệ thành các quan hệ ở dạng 3NF bảo toàn phụ thuộchàm và không mất kết nối, giả sử R là một quan hệ có tập phụ thuộc hàm F là một phủtối thiểu, và giả sử R được phân rã thành các quan hệ R1, R¬2, …, Rn và phân rã nàykhông mất kết nối. Với 1≤ i ≤ n, giả sử rằng Ri ở 3NF và giả sử rằng Fi là phép chiếucủa F trên các thuộc tính của Ri. Thực hiện những công việc sau:

• Xác định tập N của các phụ thuộc hàm trong F mà không được bảo toàn, tức lànó không nằm trong bao đóng của phép hợp của Fis.

• Với mỗi phụ thuộc hàm X→A, tạo ra một lược đồ quan hệ XA và thêm nó vàophân rã của R.

Theo như ta đã biết, tất cả phụ thuộc hàm trong F được bảo tồn nếu chúng ta thay thế Rbằng các Ri cộng với lược đồ có dạng XA ở bước trên. Các Ris đã cung cấp đều ở dạng3NF. Chúng ta có thể thấy rằng mỗi lược đồ XA đều ở dạng 3NF: Vì X→A nằm trongphủ tối thiểu F, không tồn tại phụ thuộc hàm Y→A nào mà Y là tập con của X. Vì thế,X là khoá của XA. Thêm nữa, nếu có bất kỳ phụ thuộc hàm nào khác tồn tại trong XA,phía phải có thể bao gồm chỉ các thuộc tính trong X vì A là một thuộc tính đơn (vì X→Alà một phụ thuộc hàm trong một phủ tối thiểu). Vì X là một khoá của XA nên không cóphụ thuộc hàm nào khác có thể là nguyên nhân dẫn đến quan hệ này vi phạm 3NF (mặcdù chúng có thể gây ra vi phạm BCNF).

Để tối ưu hoá, nếu tập N chứa một số phụ thuộc hàm có cùng phía trái, giả sử X→A1,X →A2, ... , X → An. Chúng ta có thể thay thế chúng bằng một phụ thuộc hàm tươngđương là X → Ai...An. Vì thế, chúng ta có được một lược đồ quan hệ XAi ...An, thay vìcó một số lược đồ quan hệ XA1,… XAn.

393/470

Xem xét lược đồ quan hệ Contracts có các thuộc tính CSJDPQV và các phụ thuộc hàmJP → C, SD → P, và J → S. Nếu chúng ta tách CSJDPQV thành SDP và CSJDQV, thìSDP ở BCNF, nhưng CSJDQV không thậm chí ở 3NF. Vì thế chúng ta chia nó tiếp tụcthành JS và CJDQV. Lược đồ quan hệ SDP, JS, và CJDQV ở 3NF (thực tế là ở BCNF),và sự phân rã này là không mất kết nối. Tuy nhiên, phụ thuộc hàm JP → C không đượcbảo toàn. Vấn đề này có thể được giải quyết bằng cách thêm một lược đồ quan hệ CJPvào phân rã này.

Tổng hợp thành 3NF

Chúng ta giả sử rằng quá trình thiết kế được khởi đầu từ một lược đồ ER, và các phụthuộc hàm được sử dụng để hướng dẫn việc phân rã. Thuật toán thực hiện việc phân rãkhông mất kết nối và bảo toàn phụ thuộc hàm được trình bày trong phần trước (phân rãkhông mất kết nối thành 3NF) rất rõ ràng, và thuật toán này giải quyết việc bảo toàn phụthuộc hàm bằng cách thêm vào các lược đồ quan hệ.

Một cách tiếp cận khác, gọi là tổng hợp, cách này đưa tất cả các thuộc tính vào một quanhệ R và xác định phủ tối thiểu của các phụ thuộc hàm F trên R và thêm một lược đồquan hệ XA tới phân rã của R ứng với mỗi phụ thuộc hàm X→A trong F.

Tập kết quả chứa các lược đồ quan hệ đều ở 3NF và bảo toàn tất cả các phụ thuộc hàm.

Nếu nó không phải là phân rã không mất kết nối, chúng ta có thể giải quyết bằng việcthêm một lược đồ quan hệ chứa những thuộc tính xuất hiện trong một vài khoá.

Thuật toán này cung cấp cho chúng ta một phân rã thành các quan hệ 3NF mà bảo toànphụ thuộc hàm và không mất kết nối và có độ phức tạp đa thức- để tính phủ tối thiểu cóthể dùng các thuật toán có độ phức tạp đa thức, và một khoá có thể được tìm bằng thờigian là đa thức (mặc dù việc tìm tất cả các khoá được biết là bài toán NP-đầy đủ). Sựtồn tại của một thuật toán đa thức để thực hiện phân rã một lược đồ quan hệ thành cáclược đồ con ở 3NF thật đáng kinh ngạc vì chúng ta biết rằng việc kiểm tra một lược đồnào đó có ở dạng 3NF hay không là một bài toán NP-đầy đủ.

Ví dụ, xem xét lược đồ quan hệ ABC với các phụ thuộc hàm F={A → B, C → B}. Quabước thực hiện đầu tiên ta thu được các lược đồ quan hệ AB và BC. Đây không phảilà một phân rã không mất kết nối của ABC; AB Ç BC là B, và cả B→A và B→C đềukhông nằm trong F+. Nếu chúng ta thêm một lược đồ AC, chúng ta có được một phépphân rã không mất kết nối. Tập các quan hệ AB, BC và AC là kết quả của phép phân rãkhông mất kết nối và bảo toàn phụ thuộc hàm được thực hiện bằng cách sử dụng phéptổng hợp tốt hơn là tiến hành phân rã lặp. Chúng ta ghi nhớ rằng sự phân rã thực hiệntheo cách tiếp cận tổng hợp phụ thuộc nhiều vào phủ tối thiểu sử dụng.

Ví dụ khác của cách tiếp cận tổng hợp, xem xét quan hệ Contracts có các thuộc tínhCSJDPQV và các phụ thuộc hàm sau:

394/470

C → CSJDPQV, JP → C, SD → P, và J → S.

Tập phụ thuộc hàm này không phải là một phủ tối thiểu vì thế chúng ta cần tìm đượcmột tập phủ tối thiểu nào đó. Đầu tiên, chúng ta thay thế C→ CSJDPQV bằng tập phụthuộc hàm:

C → S, C → J, C → D, C → P, C → Q, và C→ V.

Phụ thuộc hàm C → P được suy diễn từ C → S, C → D, và SD → P; vì thế chúng ta cóthể bỏ nó. Phụ thuộc hàm C → S được suy diễn từ C → J và J → S; vì thế chúng ta cóthể xoá nó. Từ đó, chúng ta có phủ tối thiểu là:

C → J, C → D, C → Q, C → V, JS → C, SD → P, và J → S.

Sử dụng thuật toán này đảm bảo sự bảo toàn phụ thuộc hàm, chúng ta thu được các lượcđồ quan hệ CJ, CD, CQ, CV, CJP, SDP, và JS. Chúng ta có thể cải tiến lược đồ này bằngcách kết hợp các quan hệ có C là khoá thành lược đồ CDJPQ V. Thêm nữa, chúng ta cóSDP và JS trong phân rã của chúng ta.

So sánh phân rã này với phân rã đã thực hiện trong phần trước, chúng ta thấy chúngthực sự tương tự, chỉ có sự khác nhau là CDJPQV được thay bằng CJP và CJDQV. Nóichung, chúng không có sự khác biệt đáng kể.

Tinh chỉnh lược đồ trong thiết kế cơ sở dữ liệu

Chúng ta đã biết việc chuẩn hoá có thể giảm dư thừa như thế nào và cũng đã bàn đếnmột vài cách tiếp cận để chuẩn hoá một quan hệ. Bây giờ chúng ta đề cập đến cách ápdụng các ý tưởng này trong thực tế.

Người thiết kế cơ sở dữ liệu sử dụng một phương pháp thiết kế khái niệm, ví dụ nhưthiết kế ER để có được thiết kế cơ sở dữ liệu ban đầu. Từ đây, cách tiếp cận là phân rãlặp đi lặp lại được sử dụng để giảm dư thừa là cách tiếp cận tự nhiên nhất sử dụng cácphụ thuộc hàm và các công nghệ chuẩn hoá.

Trong phần này, chúng ta tiến hành tinh chỉnh lược đồ sau khi thiết kế ER. Một câuhỏi ở đây là chúng ta có thể có được các quan hệ phân rã bằng cách chuyển từ lược đồER. Một thiết kế lược đồ ER tốt có thể ánh xạ ra một tập các quan hệ không có dư thừakhông? Không may là thiết kế ER là một công việc phức tạp, nó có tính chủ quan vànhiều ràng buộc không biểu diễn được. Những ví dụ trong phần này được dùng để minhhoạ vì sao phân rã quan hệ sử dụng thiết kế ER có lẽ cần thiết.

395/470

Các ràng buộc trên một thực thể

Xem xét lại quan hệ Hourly_Emps. Ràng buộc chỉ ra thuộc tính ssn là một khoá có thểđược biểu diễn như một phụ thuộc hàm:

{ssn} → {ssn, name, lot, rating, hourly_wages, hours_worked)

Để ngắn gọn, chúng ta viết như sau S→ SNLRWH, sử dụng một ký tự duy nhất ứng vớimỗi thuộc tính và bỏ đi những ký tự cách. Thêm nữa, quan hệ này còn có ràng buộc từthuộc tính hourly_wages có thể xác định được giá trị của thuộc tính rating: R→W.

Như chúng ta nhìn thấy trong Phần 1.1, phụ thuộc hàm này dẫn đến dư thừa trong lưutrữ. Nó không thể được biểu diễn bằng các khái niệm của mô hình ER. Chỉ nhữngphụ thuộc hàm xác định tất cả các thuộc tính trong một quan hệ mới có thể biểu diễnđược trong mô hình ER. Vì thế, chúng ta không thể nhận ra nó khi chúng ta xem xétHourly_Emps trong quá trình xây dựng mô hình ER.

Chúng ta có thể đồng ý rằng vấn đề này có thể tránh được bằng cách thêm vào một tậpthực thể gọi là Wage_Table (có các thuộc tính rating và hourly_wages) và một kiểu liênkết Has_Wages giữa hai bảng Hourly_Emps và Wage_Table. Tuy nhiên, không phải dễdàng đạt được thiết kế tốt do quá trình mô hình hoá này bị ảnh hưởng nhiều bởi ý kiếnchủ quan của người thiết kế. Việc có các công nghệ chuẩn để giải quyết vấn đề này vàchỉ dẫn chúng ta tới một thiết kế tốt hơn là rất cần thiết. Giá trị của những công nghệnày không thể được đánh giá thấp khi thiết kế những lược đồ lớn có tới hàng trăm bảng.

Các ràng buộc trên một kiểu liên kết

Ví dụ trước minh hoạ như thế nào các phụ thuộc hàm có thể hỗ trợ tinh chỉnh nhữngquyết định chủ quan đã thực hiện trong suốt quá trình thiết kế ER, nhưng chúng ta cũngđồng ý rằng một lược đồ ER tốt có thể cho chúng ta cùng một tập các quan hệ (giốngvới chúng ta tiếp cận bằng các công nghệ đã trình bày). Ví dụ tiếp theo chỉ ra rằng nhờvào thông tin về phụ thuộc hàm, một thực thể có thể dẫn tới một tập các quan hệ chứkhông chỉ là một quan hệ như là cách sử dụng thiết kế ER.

Chúng ta xem lại ví dụ trong Chương 2. Giả sử rằng chúng ta có kiểu thực thể Parts,Suppliers, và Departments, và kiểu liên kết Contracts giữa chúng. Lược đồ Contracts cócác thuộc tính CQPSD. Một hợp đồng C (Contract) có contract idxác định rằng một nhàcung cấp S (supplier)sẽ cung cấp một số lượng Q của một mặt hàng P (part) cho đơn vịD (Departments). (Chúng ta thêm một trường contract id so với phiên bản của quan hệContracts đã trình bày trong Chapter 2.)

Chúng ta có một quy tắc là một đơn vị chỉ mua một loại sản phẩm ở một nhà cung cấp.Vì thế, nếu có một vài hợp đồng có cùng nhà cung cấp và đơn vị thì chúng phải có cùnggiá trị của loại sản phẩm. Ràng buộc này là DS→ P.

396/470

Chúng ta lại gặp dư thừa và những vấn đề tồn tại do dư thừa sinh ra. Chúng ta có thể giảiquyết tình trạng này bằng cách phân rã Contracts thành hai quan hệ có các thuộc tínhCQSD và SDP. Quan hệ SDP ghi lại loại sản phẩm mà một nhà cung cấp bán cho mộtđơn vị, và quan hệ CQSD ghi lại những thông tin bổ sung của một hợp đồng. Nó khônggiống kết quả nhận được khi sử dụng mô hình ER, vì sử dụng cách này chúng ta chỉ thuđược một quan hệ.

Xác định các thuộc tính của thực thể

Ví dụ này chỉ ra việc kiểm tra cẩn thận các phụ thuộc hàm có thể dẫn tới những hiểubiết tốt hơn về các thực thể và các kiểu liên kết giữa chúng; cụ thể nó chỉ ra rằng cácthuộc tính có thể dễ dàng được gắn vào những thực thể ‘sai’ trong quá trình thiết kế ER.Lược đồ ER trong Hình 11 chỉ ra một kiểu liên kết gọi là Work_In tương tự với kiểuliên lết Work_In trong Chương 2 nhưng nó được thêm một ràng buộc khoá chỉ ra rằngmột nhân viên có thể làm việc chỉ ở nhiều nhất một phòng. (Quan sát mũi tên kết nối từEmployees tới Works_In.)

Hình 11 Kiểu liên kết Works_In

Sử dụng ràng buộc khoá này, chúng ta có thể chuyển lược đồ ER này thành hai quan hệ:

Workers( ssn , name, lot, did, since)

Departments( did , dname, budget)

Kiểu thực thể Employees và kiểu liên kết Works_In được ánh xạ thành một quan hệ đơnWorkers. Việc ánh xạ này dựa trên cách tiếp cận thứ hai trình bày trong Phần 2.4.1.

Bây giờ, giả sử rằng các nhân viên được chỉ định bãi để xe dựa vào phòng họ làm việc,và tất cả các nhân viên trong một phòng được chỉ định tới cùng một bãi đỗ xe. Ràngbuộc này không được biểu diễn trong lược đổ của Hình 11. Đây là một ví dụ khác củamột phụ thuộc hàm: did→lot. Dư thừa trong thiết kế này có thể được loại bỏ bằng việcphân rã quan hệ Workers thành hai quan hệ:

397/470

Workers2(sid, name, did, since)

Dept_Lots(did, lot)

Trong thiết kế mới này có nhiều lưu ý. Nó có thể thay đổi được chỗ để xe liên quan đếnmột phòng bằng cách cập nhật duy nhất một bộ giá trị trong quan hệ thứ hai. (tức là,không có dị thường khi cập nhật). Chúng ta có thể có một chỗ để xe ứng với một phòngngay cả khi phòng đó hiện tại không có nhân viên nào mà không sử dụng các giá trịrỗng (tức là, không có dị thường khi xoá). Chúng ta có thể thêm một nhân viên vào mộtphòng nào đó bằng việc thêm một bộ giá trị vào quan hệ đầu tiên ngay cả khi nhân viênnày chưa thuộc phòng nào (tức là, không có dị thường khi thêm bộ).

Việc kiểm tra hai quan hệ Departments và Dept_Lots, hai quan hệ này có cùng khoá,chúng ta thấy rõ rằng một bộ Departments và một bộ Dept_Lots có cùng giá trị khoábiểu diễn cùng một thực thể. Quan sát này được phản ánh trong lược đồ ER của hình 12.

Kiểu liên kết Works_In sau khi sửa

Chuyển luợc đồ này thành mô hình quan hệ ta có:

Workers2(ssn, name, did, since)

Departments(did, dname, budget, lot)

Quan sát ta thấy chỗ để xe liên quan tới các nhân viên, mặt khác, các ràng buộc toàn vẹncho thấy rằng trong ví dụ này chỗ để xe liên quan thực sự đến các phòng. Xử lý trongmô hình ER có thể bỏ xót điểm này. Thực hiện chuẩn hoá nghiêm khắc thì không.

Xác định kiểu thực thể

Xem xét một biến thể của lược đồ Reserves được sử dụng trong các chương trước. Giảsử Reserves chứa các thuộc tính S, B và D như trước, trong đó thuỷ thủ S có phục vụtrên tàu B vào ngày D. Thêm nữa, giả sử có một thuộc tính C ghi lại thẻ tín dụng đểthanh toán tiền phục vụ cho thuỷ thủ. Chúng ta sử dụng ví dụ này để minh hoạ thông tinvề phụ thuộc hàm có thể được sử dụng để tinh chỉnh thiết kế lược đồ ER như thế nào.

398/470

Cụ thể, chúng tôi minh hoạ thông tin về phụ thuộc hàm được sử dụng để quyết định xemmột khái niệm nào đó có thể được mô hình hoá như một thực thể hay là một thuộc tính.

Giả sử tất cả các thuỷ thủ sử dụng một thẻ tín dụng duy nhất để nhận tiền phục vụ củamình. Ràng buộc này được biểu diễn bằng một phụ thuộc hàm S→C. Ràng buộc này chỉra rằng trong quan hệ Reserves chúng ta lưu lại mã số của thẻ tín dụng trong mỗi lầnthuỷ thủ đó phục vụ, và chúng ta có sự dư thừa và những dị thường khi cập nhật. Để giảiquyết vấn đề này chúng ta phân rã quan hệ Reserves thành hai quan hệ có các thuộc tínhSBD và SC. Như vậy, một quan hệ lưu thông tin về sự phục vụ của thủy thủ, và một lưuthông tin về các thẻ tín dụng.

Chúng ta có thể nghĩ rằng thiết kế ER sẽ dẫn đến những quan hệ này. Một cách tiếp cậnlà giới thiệu một tập thực thể gọi là Credit_Card có một thuộc tính đơn là cardno, và mộtkiểu liên kết là Has_Card giữa hai quan hệ Sailors và Credit_Card. Với ghi nhớ là mỗithẻ tín dụng do một thuỷ thủ sở hữu, chúng ta có thể ánh xạ Has_Card và Credit-Cardsthành một quan hệ đơn có các thuộc tính SC. Chúng ta có lẽ không mô hình hoá nhữngmã số thẻ tín dụng như các thực thể nếu mục đích chính của chúng ta đối với các mãsố thẻ là để ghi lại thẻ tín dụng nào được sử dụng trong mỗi lần trả tiền phục vụ; trongtrường hợp này ta chỉ cần sử dụng một thuộc tính để mô hình hóa nó.

Cách tiếp cận thứ hai là xem cardno là một thuộc tính của Sailors. Nhưng cách này rấtkhông tự nhiên- một thuỷ thủ có lẽ có nhiều thẻ, và chúng ta không quan tâm đến tất cảcác thẻ của họ. Chúng ta chỉ quan tâm đến một thẻ được sử dụng để trả tiền cho họ, nhưvậy tốt nhất trong trường hợp này là chúng ta mô hình hoá nó như một thuộc tính củakiểu liên kết Reserves.

Khi nghĩ về những vấn đề thiết kế của ví dụ này, cách hữu ích là đầu tiên chúng ta xemcardno là một thuộc tính của Reserves sau đó tinh chỉnh các bảng kết quả bằng cách sửdụng thông tin về phụ thuộc hàm. (Chúng ta có thể tinh chỉnh thiết kế này bằng cáchthêm cardno vào bảng thu được từ Sailors hoặc bằng việc tạo một bảng mới có các thuộctính SC).

Những kiểu khác của phụ thuộc hàm

Phụ thuộc hàm có lẽ là kiểu ràng buộc quan trọng và phổ dụng nhất đứng trên quan điểmcủa thiết kế cơ sở dữ liệu. Tuy nhiên, có một số kiểu phụ thuộc hàm. Cụ thể, có một lýthuyết đã được xây dựng tốt cho thiết kế cơ sở dữ liệu là các phụ thuộc hàm đa trị(MVD)và các phụ thuộc hàm liên kết. Bằng việc sử dụng những loại phụ thuộc hàm này, chúngta có thể xác định được các vấn đề có thể dẫn đến dư thừa mà không phát hiện được khichỉ sử dụng các phụ thuộc hàm đơn.

399/470

Phần này minh hoạ những loại dư thừa có thể phát hiện được bằng cách sử dụng MVD.Chúng ta cũng đề cập đến vai trò của phụ thuộc hàm inclusion trong thiết kế cơ sở dữliệu.

Phụ thuộc hàm đa trị

Giả sử rằng chúng ta có một quan hệ gồm các thuộc tính course, teacher, và book, vàđược ký hiệu là CTB. Trong đó giáo viên T có thể dạy khoá học C, và quyển sách B làtài liệu của khoá học này. Ở đây không có phụ thuộc hàm nào; khoá của quan hệ là CTB.Tuy nhiên, tài liệu của khoá học phụ thuộc vào giáo viên dạy. Minh hoạ trong Hình 13chỉ ra tình trạng này.

Quan hệ ở BCNF có dư thừa được MVD phát hiện

Lưu ý ba điểm ở đây:

• Lược đồ quan hệ CTB ở BCNF; vì thế chúng ta sẽ không nghĩ đến việc phân rãnó thêm nữa nếu chúng ta chỉ nhìn vào những phụ thuộc hàm của quan hệ này.

• Có sự dư thừa ở đây. Thực tế là giáo viên Green có thể dạy Physics101 đượcghi lại một lần ứng với mỗi tài liệu của khoá học. Tương tự, Optics là tài liệucủa môn học Physics101 được ghi lại một lần ứng với một giáo viên dạy.

• Sự dư thừa có thể được loại bỏ bằng cách phân rã CTB thành CT và CB.

Sự dư thừa trong ví dụ này là do có một ràng buộc là các tài liệu cho một khoá học phụthuộc vào giáo viên dạy, điều này không thể biểu diễn được bằng khái niệm của các phụthuộc hàm. Ràng buộc này là một ví dụ về MVD. Chúng ta sẽ mô hình hoá tình trạngnày sử dụng hai kiểu liên kết nhị phân. Giáo viên (T) sẽ có các thuộc tính CT và Tàiliệu(B) có các thuộc tính CB. Vì ở đây có hai mối liên kết độc lập, việc mô hình hoáchúng bằng một kiểu liên kết bậc ba cùng với các thuộc tính CTB là không phù hợp.(Xem phần 2.5.3 đã trình bày về sự khác nhau giữa mối liên kết bậc ba và mối liên kếtbậc hai).Tuy nhiên nếu tiếp cận theo hướng thiết kế ER chúng ta sẽ tạo ra một kiểu liênkết bậc ba. Sau đó, phân tích cẩn thận thông tin về MVD sẽ phát hiện ra vấn đề này.

Giả sử R là một lược đồ quan hệ và giả sử X và Y là tập con của R. X→→Y được gọilà MVD trên R nếu, trên tất cả minh hoạ hợp lý r của R, mỗi giá trị X có một tập giá trịtương ứng trên Y và tập này độc lập với các giá trị trong các thuộc tính khác.

400/470

Chính thức, nếu có MVD X→→Y trên R và Z= R-XY, điều kiện sau phải đúng trên mọiminh hoạ hợp lý r của R:

Nếu t1 ∈ r, t2 ∈ r và t1.X=t2.X thì tồn tại một vài t3 ∈ r sao cho t3.XY = t1.XY vàt2.Z=t3.Z.

Hình 14 minh hoạ định nghĩa này. Nếu chúng ta có hai bộ giá trị đầu tiên và nói rằng cóMVD X→→Y trên quan hệ này, chúng ta có thể suy diễn rằng minh hoạ quan hệ nàycũng phải chứa bộ thứ ba. Thực tế, bằng việc hoán đổi vai trò của hai bộ giá trị đầu tiên-xem bộ đầu tiên là bộ thứ hai và bộ thứ hai là bộ thứ nhất- chúng ta có thể suy ra rằngbộ giá trị thứ 4 cũng phải ở trong minh hoạ quan hệ này.

Minh hoạ định nghĩa MVD

Bảng sau đề xuất một cách khác để nghĩ về MVD: Nếu có X→→Y trên R, thì π YZ(σX=x(R)) = πY(σX=x(R)) ×πZ(σX=x(R)) trong tất cả các minh hoạ hợp pháp của R, với bấtkỳ giá trị x nào xuất hiện trong cột X của R. Diễn đạt cách khác, xem xét các nhóm củacác bộ giá trị trong R có cùng giá trị của X. Trong mỗi nhóm, xem xét phép chiếu trêncác thuộc tính YZ. Phép chiếu này phải bằng với phép nhân chéo giữa các phép chiếutrên Y và Z. Tức là, giá trị X, các giá trị Y và các giá trị là độc lập. (Từ định nghĩa nàyta có thể dễ dàng nhận ra rằng X→→Y tồn tại bất cứ khi nào X→Y tồn tại). Nếu tồn tạiphụ thuộc hàm X→Y, thì có chính xác một giá trị Y ứng với một giá trị X nào đó và cácđiều kiện trong định nghĩa MVD đều thoả mãn. Không có điều ngược lại, như minh hoạtrong Hình 14).

Quay trở lại ví dụ CTB của chúng ta, ràng buộc về tài liệu của khoá học độc lập với giáoviên dạy có thể được biểu diễn bằng C→→T. Sử dụng các khái niệm của MVD, ràngbuộc này có thể được đọc như sau:

Nếu (có một bộ giá trị nào đó chỉ ra rằng) C được dạy bằng giáo viên T,

và (có một bộ giá trị nào đó chỉ ra rằng) C có tài liệu là B,

thì (có một bộ giá trị nào đó chỉ ra rằng) C được dạy bởi T và tài liệu là B.

Cho một tập phụ thuộc hàm và các MVD, chúng ta có thể suy diễn ra một số các phụthuộc hàm và MVD khác nhờ vào ba luật trong hệ tiên đề Armstrong và năm luật bổsung. Ba luật bổ sung sau chỉ áp dụng cho các MVD:

401/470

• Luật bù cho MVD: Nếu X→→Y thì X→→R – XY.• Luật tăng trưởng cho MVD: Nếu X→→Y và W ⊇ Z thì WX→→YZ.• Luật bắc cầu cho MVD: Nếu X→→Y và X→→Z, thì X →→(Z –Y).

Xem một ví dụ sử dụng những luật này, vì chúng ta có C→→T trên quan hệ CTB. Luậtbù của MVD cho phép chúng ta suy diễn ra C→→CTB – CT, tức là C→→B. Hai luậtcòn lại phối hợp giữa phụ thuộc hàm và MVDs:

• Tái tạo: Nếu X→Y thì X→→Y.• Kết hợp: Nếu X→→Y và có một W mà WÇ Y rỗng, W→Z, và Y ⊇ Z thì X →

Z.

Dạng chuẩn bốn

Dạng chuẩn bốn là dạng tổng quát trực tiếp của BCNF. Giả sử P là một lược đồ quan hệ,A và Y là các tập con không rỗng của P, và F là một tập phụ thuộc hàm có cả MVDs.P được gọi là dạng chuẩn bốn (4NF) nếu tất cả các MVD X→→Y trên R đều thoả mãnyêu cầu sau:

• Y ⊆ X hoặc XY = R, hoặc• X là một siêu khoá.

Trong định nghĩa này, một điểm quan trọng phải lưu ý là định nghĩa của một khoá khôngthay đổi – khoá này phải xác định duy nhất tất cả các thuộc tính thông qua các phụ thuộchàm. X→→Y là một trivial MVD nếu Y ⊆ X ⊆ R hoặc XY = R trivial.

Quan hệ CTB không ở dạng 4NF vì C→→ T là một nontrivial MVD và C không phảilà khoá. Chúng ta có thể loại bỏ dư thừa bằng cách phân rã CTB thành CT và CB; mỗiquan hệ con này đều ở dạng 4NF.

Để sử dụng thông tin MVD đầy đủ, chúng ta phải hiểu về lý thuyết của MVDs. Nhiềukhi chỉ sử dụng thông tin về FD cũng đủ để phát hiện được sự dư thừa mà không cầnsử dụng đến thông tin về MVD. Vì thế, đôi khi chúng ta không cần xác định tất cả cácMVDs.

Nếu một lược đồ quan hệ ở BCNF, và có ít nhất một trong các khoá của nó chứa mộtthuộc tính đơn, thì nó cũng ở 4NF.

Xem xét một lược đồ quan hệ ABCD và giả sử rằng nó có các FD: A→ BCD và MVD:B→→C. Xem xét chỉ những phụ thuộc hàm này, lược đồ quan hệ này như là phản ví dụvới kết quả. Quan hệ có một khoá, nó là BCNF và không phải là 4NF vì B→→C gây ravi phạm chuẩn này. Hãy cùng chúng tôi xem xét nó kỹ càng hơn.

402/470

Ba bộ giá trị nằm trong minh hoạ hợp pháp của ABCD

Hình 15 chỉ ra ba bộ giá trị trong minh hoạ ABCD thoả mãn MVD B→→C. Từ địnhnghĩa về MVD, nếu có hai bộ t1 và t2, thì bộ t3 cũng nằm trong minh hoạ này. Xem xétbộ t2 và t3. Từ phụ thuộc hàm A→ BCD và thực tế là hai bộ này có cùng giá trị của A,chúng ta có thể suy ra rằng c1=c2. Vì thế, chúng ta thấy rằng FD B→C cũng phải cótrên ABCD bất cứ khi nào có FD A→ BCD và MVD B→→C. Nếu có B→→C, quanhệ ABCD sẽ không ở BCNF (trừ khi bổ sung phụ thuộc hàm để B là một khoá)!

Vì thế, phản ví dụ này lại không thực sự là phản ví dụ - mà nó minh hoạ sự quan trọngcủa việc xác định tất cả các FDs trên một quan hệ một cách đúng đắn. Trong ví dụ này,không chỉ có A→BCD là FD; mà còn có FD B→C nhưng nó không được xác định từđầu. Với một tập FDs và MVDs cho trước, các luật suy diễn có thể được sử dụng để suyra các FDs (MVDs) khác.

Phụ thuộc liên kết (Join Dependency)

Phụ thuộc liên kết là sự tổng quát hoá của MVDs. Một phụ thuộc liên kết (JD) {R1,…, Rn} được nói là có trên quan hệ R nếu R1, …, Rn là một phân rã không mất kết nốicủa R.

Một MVD X→→Y trên một quan hệ R có thể được biểu diễn như một JD {XY,X(R-Y)}. Ví dụ, trong quan hệ CTB, MVD C→→T có thể được biểu diễn như một JD

{CT, CB}.

Không như FDs và MVDs, JDs không có các luật suy diễn đúng đắn và đầy đủ.

Dạng chuẩn năm

Một lược đồ quan hệ R được nói là ở dạng chuẩn năm(5NF) nếu với tất cả các phụthuộc liên kết {R1, …, Rn} trên R, một trong những điều kiện sau đây đúng:

• Ri = R với một số i, hoặc• JD được ngụ ý là một tập các FDs trên R mà phía trái của chúng là một khoá

của R.

Điều kiện thứ hai xứng đáng có một vài giải thích, vì chúng ta không trình bày các luậtsuy diễn cho các FDs và JDs cùng nhau. Chúng ta phải có thể chỉ ra rằng việc phân rãR thành {R1, …, Rn} là không mất kết nối bất cứ khi nào có phụ thuộc khoá (FDs mà

403/470

phía trái của nó là khoá của R). JD {R1, …, Rn} là một trivial JD nếu Ri=R với mộtsố i.

Nếu một lược đồ quan hệ ở 3NF và mỗi khoá của nó chứa một thuộc tính đơn thì nócũng ở 5NF.

Nhận xét trên rất hữu ích trong thực tế vì nó cho phép chúng ta kết luận được một quanhệ nào đó ở 5NF mà không cần xác định các MVDs và JDs trên quan hệ đó.

Các phụ thuộc bao gồm (Inclusion Dependencies)

MVDs và JDs có thể được sử dụng để hướng dẫn thiết kế cơ sở dữ liệu, mặc dù chúngít phổ biến hơn là FDs và khó hơn để nhận và suy luận ra nó. Ngược lại, phụ thuộc baogồm (IDs) rất phổ biến và dễ nhận ra. Tuy nhiên, chúng lại ít ảnh hưởng đến việc thiếtkế cơ sở dữ liệu (dựa trên thiết kế ER).

Một ID có dạng là một vài cột của một quan hệ nằm trong những cột khác (thường làquan hệ thứ hai). Ràng buộc khoá là một ví dụ của một ID; (các) cột tham chiếu trongmột quan hệ phải nằm trong (các) cột khoá chính của quan hệ được tham chiếu. Ví dụ,nếu R và S là hai quan hệ đạt được bằng việc ánh xạ hai kiểu thực thể mà tất cả thực thểR cũng là thực thể của S; chúng ta sẽ có một ID; phép chiếu lấy ra các thuộc tính khoátrên R cũng bằng với trên S.

Một điểm cần phải nhớ là chúng ta không nên chia tách các nhóm thuộc tính tham giatrong một ID. Ví dụ, chúng ta có một phụ thuộc bao gồm AB⊆ CD, nếu phân rã lược đồquan hệ chứa AB, chúng ta nên chắc chắn rằng có ít nhất một lược đồ kết quả chứa cảA và B. Nếu không thì chúng ta không thể kiểm tra được phụ thuộc bao gồm AB ⊆ CDmà không xây dựng lại quan hệ chứa AB.

Trong thực tế hầu hết các ID đều dựa trên khoá, tức là chỉ bao gồm các khoá. Các ràngbuộc khoá ngoại là một ví dụ của ID dựa trên khoá. Một lược đồ ER chứa các phân cấpISA (xem Phần 2.4.4) cũng dẫn đến các ID dựa trên khoá. Nếu tất cả các ID đều dựatrên khoá thì hiếm khi chúng ta phải lo lắng về việc phân chia nhóm thuộc tính tham giatrong IDs, vì việc phân rã thường không phân tách khoá chính. Tuy nhiên, nhớ là việcchuyển từ 3NF thành BCNF luôn phải phân tách một số khoá (không phải là khoá chínhlà tốt nhất!).

Trường hợp nghiên cứu: CỬA HÀNG INTERNET

Nhớ lại trong Phần 3.8 DBDudes đã chấp nhận lược đồ sau:

Books(isbn: CHAR(10),title: CHAR(8), author: CHAR(80),qty_in_stock: INTEGER, price: REAL, year_published:

404/470

INTEGER) Customers(cid: INTEGER, cname: CHAR(80), address:CHAR(200)) Orders( ordernum: INTEGER, isbn: CHAR(10),cid:INTEGER, cardnum: CHAR(16), qty: INTEGER, order_date:DATE, ship_date: DATE)

DBDudes phân tích tập các quan hệ xem có sự dư thừa không. Quan hệ Book chỉ cómột khoá là (isbn), và không có phụ thuộc hàm nào. Vì thế Books ở dạng BCNF. Quanhệ Customers cũng chỉ có một khoá là (cid) và không có phụ thuộc hàm nào. Vì thế,Customers cũng ở BCNF.

DBDudes cũng xác định cặp á ordernum, isbn ñ là khoá của bảng Orders. Thêm nữa, vìmỗi hoá đơn (order) được một khách hàng đặt vào một ngày xác định cùng với mã tàikhoản xác định, nên quan hệ này có ba phụ thuộc hàm sau:

ordernum → cid, ordernum → order_date, và ordernum →cardnum

Các chuyên gia ơ DBDudes kết luận rằng quan hệ Orders thậm chí không ở 3NF. (Bạncó thể nhìn thấy vì sao?). Họ quyết định phân rã Orders thành hai quan hệ:

Orders(ordernum, cid, order_date, cardnum), vàOrderlists(ordernum,isbn, qty, ship_date)

Kết quả là cả hai quan hệ này đều ở BCNF, và việc phân rã này không mất kết nối vìordernum là một khoá của Orders (mới). Người đọc nên kiểm tra lại xem phân rã này cóbảo toàn phụ thuộc hàm không.

Cuối cùng, chúng tôi cung cấp SQL DDL của quan hệ Orders và Orderlists như sau:

Lược đồ ER phản ánh thiết kế cuối cùng

405/470

CREATE TABLE Orders ( ordernum INTEGER, cid INTEGER,order_date DATE, cardnum CHAR(16), PRIMARY KEY (ordernum),FOREIGN KEY (cid) REFERENCES Customers) CREATE TABLEOrderlists(ordernum INTEGER, isbn CHAR(10), qty INTEGER,ship_date DATE, PRIMARY KEY (ordernum, isbn), FOREIGN KEY(isbn) REFERENCES Books)

Câu hỏi ôn tập

Trả lời những câu hỏi sau, phần gợi ý được chỉ ra bên cạnh.

• Giải thích về sự dư thừa và những vấn đề nó có thể gây ra. Cung cấp những vídụ về dị thường khi thêm, xoá, và cập nhật. Các giá trị rỗng có thể giúp giảiquyết những vấn đề này? Chúng có phải là những giải pháp đầy đủ? (Phần 1.1)

• Phân rã là gì và nó giải quyết vấn đề dư thừa như thế nào? Những vấn đề gì cóthể xảy ra khi sư dụng phân rã? (Phần 1.1 và 1.3)

• Định nghĩa các phụ thuộc hàm (FDs). Khoá chính liên quan đến FDs như thếnào? (Phần 2)

• Khi nào một phụ thuộc hàm f được suy diễn từ một tập F các FDs? Định nghĩaTiên đề Amstrong’s, và giải thích câu sau: “Chúng là một tập các luật đầy đủvà đúng đắn để suy diễn phụ thuộc hàm” (Phần 3)

• Bao đóng F+ của một tập F các FDs là gì? Bao đóng X+ của một tập các thuộctính X trên tập các phụ thuộc hàm F là gì? (Phần 3)

• Định nghĩa 1NF, 2NF, 3NF và BCNF. Động cơ để đưa một quan hệ về BCNFlà gì? Động cơ để đưa một quan hệ về 3NF là gì? (Phần 4)

• Khi nào một phân rã của một lược đồ quan hệ P thành hai lược đồ quan hệ X vàY được nói là một phân rã không mất kết nối? Vì sao tính chất này lại rất quantrọng? Cung cấp điều kiện cần và đủ để kiểm tra một phân rã là không mất kếtnối. (Phần 5.1)

• Khi nào một phân rã được gọi là bảo toàn phụ thuộc? Vì sao tính chất này thựcsự hữu ích? (Phần 5.2)

• Chúng ta có thể thu được một phân rã không mất kết nối từ một quan hệ thànhcác quan hệ con ở BCNF như thế nào? Cung cấp một ví dụ để chỉ ra rằng có thểcó phân rã về BCNF không bảo toàn phụ thuộc. Một quan hệ có thể được phânrã theo các cách khác nhau để đạt được các kết quả phân rã khác nhau. (Phần6.1)

• Phủ tối thiểu của một tập FDs là gì? Trình bày một thuật toán để tính toán phủtối thiểu của một tập FDs và minh hoạ nó bằng một ví dụ. (Phần 6.2)

• Trình bày như thế nào thuật toán phân rã thành BCNF không mất kết nối lại cóthể tương thích để có được phân rã thành 3NF không mất kết nối và bảo toànphụ thuộc. Trình bày phép tổng hợp để thu được một phân rã thành 3NF nhưvậy. Minh hoạ cả hai cách tiếp cận bằng một ví dụ. (Phần 6.2)

406/470

• Trình bày cách thức tinh chỉnh lược đồ thông qua phân tích phụ thuộc và chuẩnhoá có thể cải thiện được lược đồ thu được từ thiết kế ER. (Phần 7)

• Định nghĩa phụ thuộc đa trị, phụ thuộc liên kết, và phụ thuộc bao gồm. Trìnhbày việc sử dụng những phụ thuộc này trong thiết kế cơ sở dữ liệu. Định nghĩa4NF và 5NF, và giải thích vì sao chúng tránh được những loại dư thừa màBCNF không loại trừ được. Trình bày cách thức kiểm tra một quan hệ ở 4NFvà 5NF mà chỉ sử dụng FDs. (Phần 8)

Bài tập

Trả lời tóm tắt những câu hỏi sau:

1. Định nghĩa khái niệm phụ thuộc hàm.2. Vì sao có một số phụ thuộc hàm gọi là trivial?3. Đưa ra một tập phụ thuộc hàm trên lược đồ R(A,B,C,D) trong đó AB là khoá

chính để R ở 1NF nhưng không ở 2NF.4. Đưa ra một tập phụ thuộc hàm trên lược đồ R(A,B,C,D) trong đó AB là khoá

chính để R ở 2NF nhưng không ở 3NF.5. Xem xét lược đồ quan hệ R(A,B,C) có FD B→C. Nếu A là một khoá dự tuyển

của R thì R có thể ở BCNF không? Nếu có thì phải có những điều kiện gì? Nếukhông, giải thích vì sao.

6. Giả sử chúng ta có một lược đồ quan hệ R(A,B,C) biểu diễn mối liên kết giữahai kiểu thực thể có khoá A và B, giả sử R có các phụ thuộc hàm A→B vàB→A. Giải thích ý nghĩa của cặp phụ thuộc hàm này.

1. Giả sử R là một lược đồ quan hệ và giả sử X, Y là hai tập con của tập các thuộc tínhcủa R. Chúng ta nói Y là phụ thuộc hàm trên X, viết là X→Y, nếu như các giá trị của Yđược xác định bằng các giá trị của X. Nói cách khác, với bất kỳ hai bộ giá trị r1 và r2trong (bất kỳ minh họa của) R:

π X(r1) = πX (r2) ⇒ πY (r1) = πY(r2)

2. Một số phụ thuộc hàm được coi là trivial (không có giá trị) vì chúng chứa các thuộctính không cần thiết – những thuộc tính không cần được liệt kê. Xem xét phụ thuộc hàm:A→ AB. Vì A luôn suy ra A, nên thuộc tính A bên phía phải là không cần thiết và cóthể xóa đi được. Dạng chính xác không có phụ thuộc hàm trivial là: A→B.

3. Xem xét tập các phụ thuộc hàm: AB → CD và B → C. ABhiển nhiên là khóa củaquan hệ này vì AB→CD nên AB→ABCD. Nó là một khóa chính vì ở đây không có tậpnào nhỏ hơn tập này có thể làm khóa trên R(A, B, C, D). Phụ thuộc hàm: B→C vi phạm2NF vì:

• C Є B là sai; tức là nó không phải là một trivial FD.

407/470

• B không phải là siêu khóa.• C không phải là một phần của một khóa nào đó trên R.• B là tập con của khóa AB.

4. Xem xét tập phụ thuộc hàm: AB → CD và C → D. AB rõ ràng là khóa của quan hệnày vì AB → CD nên suy ra AB → ABCD. Nó là một khóa chính vì không có tập connào của nó có thể làm khóa trên R (A, B, C, D). Phụ thuộc hàm: C → D vi phạm 3NFnhưng không vi phạm 2NF vì:

• D Є C là sai; tức là, nó không phải là một trivial FD.• C không phải là một siêu khóa• D không phải là một phần của một khóa nào đó trên R.

5. Cách duy nhất để R ở dạng BCNF là B chứa một khóa nào đó, tức là B là một khóacủa R.

6. Nó có nghĩa là mối quan hệ này là một-một. Tức là một thực thể A tương ứng với duynhất một thực thể B và ngược lại.

Xem xét quan hệ R với 5 thuộc tính ABCDE. Bạn được cho các phụ thuộc hàm sau: A→ B, BC → E, và ED → A.

1. Liệt kê các khóa của R.

2. R ở dạng 3NF không?

3. R ở dạng BCNF không?

Dành cho độc giả.

Xem xét quan hệ trong Hình 1.

1. Liệt kê danh sách các phụ thuộc hàm thỏa mãn minh họa quan hệ này.

2. Giả sử rằng giá trị của thuộc tính Z ở bản ghi cuối cùng trong quan hệ này được thayđổi từ z3 thành z2. Bây giờ liệt kê tất cả các phụ thuộc hàm mà minh họa quan hệ nàythỏa mãn.

408/470

Quan hệ ở Bài 3

1. Danh sách các hàm phụ thuộc trên R:

Z → Y, X → Y, và XZ → Y

2. Tương tự phần 1. Tập phụ thuộc hàm không thay đổi.

Giả sử bạn được cung cấp một quan hệ với các thuộc tính ABCD.

1. Giả sử rằng không có bản ghi nào có các giá trị rỗng. Viết một truy vấn SQL kiểm traxem có tồn tại phụ thuộc hàm A→B.

2. Một lần nữa giả sử rằng không có bản ghi nào có giá trị rỗng. Viết một câu lệnh SQLđể thiết đặt ràng buộc A→B cho quan hệ này.

3. Giả sử rằng các bản ghi này có thể có các giá trị rỗng. Thực hiện hai câu hỏi trên vớigiả thiết này.

Dành cho độc giả

Xem xét tập các quan hệ và các phụ thuộc hàm sau đây. Giả sử mỗi quan hệ có đượcthông qua việc phân rã quan hệ gồm các thuộc tính ABCDEFGHI và tất cả các phụ thuộchàm trên quan hệ ABCDEFGHI được liệt kê trong mỗi câu hỏi. (Các câu hỏi này là độclập với nhau). Đối với mỗi quan hệ (con): (a) Dạng chuẩn lớn nhất của quan hệ này làdạng nào? (b)Nếu không ở dạng BCNF, thì hãy phân rã nó thành một tập các quan hệ ởdạng BCNF?

1. R1(A,C,B,D,E), A → B, C → D

2. R2(A,B,F), AC → E, B → F

3. R3(A,D), D → G, G → H

4. R4(D,C,H,G), A → I, I → A

5. R5(A,I,C,E)

409/470

1. 1NF. Phân rã BCNF: AB, CD, ACE.

2. 1NF. Phân rã BCNF: AB, BF

3. BCNF.

4. BCNF.

5. BCNF.

Giả sử chúng ta có ba bộ giá trị sau trong một minh họa đúng của lược đồ quan hệ Scùng với ba thuộc tính ABC (được liệt kê theo thứ tự): (1,2,3), (4,2,3) và (5,3,3)

1. Phụ thuộc hàm nào sau đây không nằm trên lược đồ S?

(a) A → B, (b) BC → A, (c) B → C

2. Bạn có thể chỉ ra phụ thuộc nào có trên lược đồ S?

Dành cho độc giả

Giả sử bạn được cung cấp một quan hệ R với 4 thuộc tính ABCD. Với mỗi tập phụthuộc hàm sau, thực hiện các yêu cầu: (a) Chỉ ra các khóa dự tuyển của R. (b) Xác địnhdạng chuẩn cao nhất mà R thỏa mãn (1NF, 2NF, 3NF, BCNF). (c) Nếu R không ở dạngBCNF, hãy phân rã nó về các quan hệ ở dạng BCNF mà vẫn bảo toàn phụ thuộc hàm:

1. C → D, C → A, B → C

2. B → C, D → A

3. ABC → D, D → A

4. A → B, BC → D, A → C

5. AB → C, AB → D, C → A, D → B

1. (a) Khóa dự tuyển là: B.

(b) R ở dạng 2NF nhưng không phải là 3NF.

(c) C → D và C → A, cả hai đều vi phạm BCNF. Có một cách phân rã mà vẫn duy trìđược phụ thuộc hàm là phân tích R thành AC, BC và CD.

2. (a) Khóa dự tuyển là BD.

410/470

(b) R ở dạng 1NF nhưng không ở dạng 2NF.

(c) B → C và D → A, cả hai đều vi phạm BCNF. Phân rã thành: AC, BC và BD (nhậnđược từ phân rã đầu tiên thành AD và BCD) ở dạng BCNF mà vẫn bảo toàn dữ liệu vàliên kết.

3. (a) Khóa chính là ABC, BCD

(b) R ở dạng 3NF nhưng không ở dạng BCNF.

(c) ABCD không ở dạng BCNF vì D → A và D không phải là khóa. Tuy nhiên nếuchúng ta phân rã R thành AD, BCD thì chúng ta không thể bảo toàn được phụ thuộc hàmABC → D. Như vậy ở đây không thể phân rã thành BCNF.

4. (a) Khóa dự tuyển là: A.

(b) R ở dạng 2NF nhưng không ở dạng 3NF (vì có phụ thuộc hàm BC → D).

(c) BC → D vi phạm BCNF vì BC không chứa khóa. Vì thế, chúng ta phân rã R thành:BCD, ABC.

5. (a) Khóa dự tuyển là: AB, BC, CD, AD

(b) R ở dạng 3NF nhưng không là BCNF vì có phụ thuộc hàm : C → A.

c) C → A và D → B, cả hai đều dẫn đến vi phạm. Vì thế phân rã thành: AC, BCD nhưngviệc này không bảo toàn được phụ thuộc hàm AB → C và AB → D, và BCD vẫn khôngở dạng BCNF vì phụ thuộc hàm D → B. Vì vậy chúng ta cần phân rã tiếp: AC, BD,CD. Tuy nhiên khi chúng ta cố gắng không để mất các phụ thuộc hàm bằng cách thêmvào ABC và ABD, thì những quan hệ này không còn ở dạng BCNF. Vì vậy quan hệ nàykhông thể được phân rã thành BCNF.

Xem xét tập thuộc tính R= ABCDEGH và các phụ thuộc hàm: F = {AB →C, AC → B,AD → E, B → D, BC → A, E → G}.

1. Với mỗi tập thuộc tính, thực hiện các công việc sau: (i) Tính toán tập các phụ thuộchàm trên tập thuộc tính này và viết ra một tập tối thiểu. ii) Tên dạng chuẩn cao nhấtkhông bị vi phạm bởi quan hệ chứa những thuộc tính này. (iii) Phân rã quan hệ nàythành tập các quan hệ ở BCNF nếu nó không ở BCNF.

(a) ABC, (b) ABCD, (c) ABCEG, (d) DCEGH, (e) ACEH

2. Khi phân rã R = ABCDEG thành các quan hệ con sau, vẫn với tập các phụ thuộc hàmF như trên, các quan hệ này có: (a) bảo toàn phụ thuộc hàm? b) không mất mát liên kết?

411/470

(a) {AB, BC, ABDE, EG}

(b) {ABC, ACDE, ADG}

Dành cho độc giả.

Giả sử R được phân rã thành R1, R2,..., Rn. Giả sử F là tập các phụ thuộc hàm trên R.

1. F được bảo toàn trong tập các quan hệ được phân rã có nghĩa là gì?

2. Trình bày thuật toán thời gian đa thức để kiểm tra sự bảo toàn phụ thuộc hàm.

3. Chúng ta thường được yêu cầu để tính toán bao đóng của tập phụ thuộc hàm FDs.Cho một ví dụ trong đó việc xem xét bao đóng là cần thiết trong khi kiểm tra sự bảo toànphụ thuộc hàm.

• Giả sử Fi là ký hiệu phép chiếu của F trên Ri. F được bảo toàn nếu bao đóngcủa Fi bằng với F.

• Chúng ta sẽ biểu diễn thuật toán kiểm tra bảo toàn phụ thuộc hàm trong đó lựclượng của F là đa thức. Với mỗi phụ thuộc hàm X → Y Є F kiểm tra xem nó cóở trong F không như sau: bắt đầu từ tập S (của các thuộc tính trong) X. Với mỗiquan hệ Ri, tính bao đóng của S ∩ Ri liên quan đến F và chiếu bao đóng này tớitập các thuộc tính của Ri. Nếu kết quả này nằm trong các thuộc tính bổ sung,thì thêm chúng vào S. Lặp lại cho đến khi không có sự thay đổi nào trong S.

• Có một ví dụ trong mục 5.2 của giáo trình.

Giả sử bạn được cho một quan hệ R(A,B,C,D). Với mỗi tập phụ thuộc hàm, thực hiệnnhững yêu cầu sau: (a) Xác định khóa dự tuyển của R. (b) Chỉ ra có hoặc không mộtphép phân rã tốt của R.

1. B → C, D → A; phân rã thành BC và AD.

2. AB → C, C → A, C → D; phân rã thành ACD và BC.

3. A → BC, C → AD; phân rã thành ABC và AD.

4. A → B, B → C, C → D; phân rã thành AB và ACD.

5. A → B, B → C, C → D; phân rã thành AB, AD và CD.

Dành cho độc giả

Xem xét một quan hệ R có ba thuộc tính ABC. Nó được phân rã thành các quan hệ conlà R1 có các thuộc tính AB và R2 có các thuộc tính BC.

412/470

• Chỉ ra định nghĩa của phép phân rã không mất mát kết nối cùng với một ví dụ.Trả lời câu hỏi này bằng việc viết ra một biểu thức đại số quan hệ chứa R, R1và R2.

• Giả sử rằng có B→C. Việc phân rã R thành R1 và R2 có mất kết nối không?Xem xét câu trả lời của bạn cùng với quan sát rằng không có các phụ thuộchàm R1 ∩ R2 → R1 và cũng không có phụ thuộc hàm R1 ∩ R2 → R2, cânnhắc những kiểm tra đơn giản khi đưa ra điều kiện cần và đủ cho việc phân rãkhông mất mát kết nối trong Phần 15.6.1.

• Nếu bạn được cung cấp các minh họa của R1 và R2, bạn có thể nói gì về minhhọa của R? Trả lời câu hỏi này bằng cách liệt kê các bộ giá trị được định nghĩatrong R và các bộ giá trị có khả năng trong R.

Minh họa của R1 = {(5,1), (6,1)}

Minh họa của R2 = {(1,8), (1,9)}

Bạn có thể chắc chắn rằng thuộc tính B là hoặc không là một khóa của R?

1. Phân rã R thành R1 và R2 là không mất mát nếu và chỉ nếu:

R1 R1.B=R2.B R2=R

Ghi nhớ rằng đây là lược đồ quan hệ, không có minh họa dữ liệu nào trên chúng.

2. Dành cho độc giả

1. Chúng ta có thể nói rằng minh họa R từ những minh họa đã cho R1 và R2 phảilà một tập con của tập các bộ giá trị ABC: {(5,1,8), (5,1,9), (6,1,8), (6,1,9)},{(5,1,8), (6,1,9)}, {(5,1,9), (6,1,8)}. Cụ thể, R chứa ít nhất hai bộ giá trị nhưngkhông nhiều hơn 4. Điều này cũng suy ra rằng thuộc tính B không phải là mộtkhóa của R (vì R có ít nhất hai bộ giá trị phân biệt có cùng giá trị B).

Giả sử rằng chúng ta có bốn bộ giá trị trong quan hệ S có ba thuộc tính ABC: (1,2,3),(4,2,3), (5,3,3), (5,3,4). Những phụ thuộc hàm (→), phụ thuộc hàm đa trị (→→) nào sauđây có thể suy ra là không nằm trên S?

1. A→B

2. A→→B

3. BC→A

4. BC→→A

413/470

5. B→C

6. B→→C

Dành cho độc giả

Cho quan hệ R có năm thuộc tính ABCDE.

1. Với mỗi minh họa sau của R, chỉ ra rằng nó có vi phạm (a) phụ thuộc hàm: BC→ Dvà (b) phụ thuộc hàm đa trị BC →→ D:

(a) { } (tức là, quan hệ rỗng)

(b) {(a,2,3,4,5), (2,a,3,5,5)}

(c) {(a,2,3,4,5), (2,a,3,5,5), (a,2,3,4,6)}

(d) {(a,2,3,4,5), (2,a,3,4,5), (a,2,3,6,5)}

(e) {(a,2,3,4,5), (2,a,3,7,5), (a,2,3,4,6)}

(f ) {(a,2,3,4,5), (2,a,3,4,5), (a,2,3,6,5), (a,2,3,6,6)}

(g) {(a,2,3,4,5), (a,2,3,6,5), (a,2,3,6,6), (a,2,3,4,6)}

2. Nếu mỗi minh họa của R được liệt kê ở trên là đúng, bạn có thể nói gì về phụ thuộchàm A →B?

1. Chú ý: Câu trả lời phụ thuộc vào giá trị a. Trừ khi được nói rõ ràng rằng câu trả lời ápdụng cho mọi giá trị của a.

(a) { }(quan hệ rỗng) không vi phạm phụ thuộc hàm nào

(b) {(a,2,3,4,5), (2,a,3,5,5)}:

Nếu a=2 thì BC→D là vi phạm (còn lại thì không).

BC→→D không vi phạm (với mọi giá trị của a).

(c) {(a,2,3,4,5), (2,a,3,5,5), (a,2,3,4,6)}:

BC→D bị vi phạm nếu a=2 (còn lại thì không)

414/470

Nếu a=2 thì BC→→D vi phạm (xem xét các bộ giá trị (2,a,3,5,5) và (a,2,3,4,6); nếu a=2 cũng phải có (2,a,3,5,6)).

(d) {(a,2,3,4,5), (2,a,3,4,5), (a,2,3,6,5)}:

BC → D bị vi phạm (xem xét bộ giá trị thứ nhất (a,2,3,4,5) và thứ ba (a,2,3,6,5))

BC →→ D không bị vi phạm.

(e) {(a,2,3,4,5), (2,a,3,7,5), (a,2,3,4,6)}:

Nếu a=2 thì BC→D bị vi phạm (còn lại thì không)

Nếu a=2 thì BC →→ D bị vi phạm (còn lại thì không).

(f) {(a,2,3,4,5), (2,a,3,4,5), (a,2,3,6,5), (a,2,3,6,6)}:

BC→D không có. (Xem xét bộ giá trị thứ nhất và thứ ba).

BC →→ C bị vi phạm. Xem xét bộ giá trị thứ nhất và thứ 4. Để có phụ thuộc hàm này,ở đây phải có bộ giá trị (a,2,3,4,6).

(g) {(a,2,3,4,5), (a,2,3,6,5), (a,2,3,6,6), (a,2,3,4,6)}:

BC → D không có. (Xem xét bộ giá trị đầu tiên và thứ ba).

BC →→ C không bị vi phạm.

2. Chúng ta không thể nói bất cứ điều gì về hàm phụ thuộc A→B.

JDs được thúc đẩy bằng một thực tế rằng đôi khi một quan hệ không thể được phân rãthành hai quan hệ nhỏ hơn mà bảo toàn được liên kết, nhưng có thể được phân rã thànhba hoặc nhiều hơn các quan hệ con. Ví dụ, một quan hệ có các thuộc tính supplier, part,và project, ký hiệu là SPJ, không có phụ thuộc hàm và phụ thuộc hàm đa trị. Có JD{SP, PJ, JS}.

Từ JD này, tập các lược đồ quan hệ SP, PJ, và JS là phân rã bảo toàn liên kết của SPJ.Xây dựng một minh họa của SJD để cho thấy rằng không có hai trong số những lược đồnày đáp ứng được yêu cầu.

Trả lời mỗi câu hỏi như sau:

1. Chứng minh rằng thuật toán cho trong Hình 4 là đúng trong việc tính toán bao đóngcủa một tập thuộc tính X.

415/470

2. Trình bày một thuật toán có thời gian tuyến tính để tìm ra bao đóng của một tập thuộctính. Chứng minh rằng thuật toán của bạn là đúng.

Câu trả lời với mỗi câu hỏi như sau:

1. Dành cho độc giả

2. Nhớ lại rằng bao đóng của tập thuộc tính X liên quan tới tập các thuộc tính A mà Σthỏa mãn X → A.

// Initialize

X+ := X;

FdSet := Σ;

do

{

for each FD Y → Z in FdSet such that X+ ⊇ Y

{

X+ := X+ union Z;

Remove Y → Z from FdSet;

}

} until ( X+ does not change) ;

Giả sử n= | Σ | là ký hiệu lực lượng của Σ. Thì vòng lặp thực hiện nhiều nhất n lần vìvới mỗi con chạy chúng ta hoặc là loại bỏ vĩnh viễn một phụ thuộc hàm nào đó từ tập Σ,hoặc là dừng tất cả cùng nhau. Bằng cách lựa chọn cấu trúc dữ liệu đúng, thuật toán nàysẽ có kích thước tuyến tính là Σ.

Giả sử có FD X → Ylà phụ thuộc hàm đơn, trong đó Y là một thuộc tính đơn.

1. Thay thế FD AB→CD bằng tập các phụ thuộc hàm đơn nhỏ nhất.

2. Chứng minh rằng FD X→Y trong tập các phụ thuộc hàm F có thể được thay bằng tậpcác phụ thuộc hàm đơn để F+ bằng với bao đóng của tập các phụ thuộc hàm mới.

416/470

Dành cho độc giả

Chứng minh rằng tiên đề Amstrong là đúng đắn và đầy đủ cho các FD được suy diễn.Tức là, thực hiện lặp đi lặp lại các tiền đề này trên tập F của các FDs sẽ đưa ra chính xáccác phụ thuộc hàm trong F+.

Insert Solution Text Here

Xem xét quan hệ R có các thuộc tính ABCDE. Giả sử có các phụ thuộc hàm sau đây:A → BC, BC → E, và E → DA. Tương tự, giả sử S là một quan hệ có các thuộc tínhABCDEvà giả sử có các phụ thuộc hàm sau: A → BC, B → E, và E → DA. Bạn khôngbiết được có hay không có những phụ thuộc hàm khác đang tồn tại.

1. R là BCNF?

2. R là 4NF?

3. R là 5NF?

4. S là BCNF?

5. S là 4NF?

6. S là 5NF?

Dành cho độc giả

Giả sử R là một lược đồ quan hệ với F là tập các phụ thuộc hàm. Chứng minh rằng phânrã của R thành R1 và R2 là không mất mát kết nối nếu và chỉ nếu F+ chứa R1 ∩R2 →R1hoặc R1 ∩ R2 → R2.

Với cả hai chiều (nếu và chỉ nếu) chúng ta sử dụng ký hiệu:

C = R1∩R2, X = R1−C, Y = R2−C, vì thế R1 = XC, R2 = CY , và R = XCY .

(⇐): Với chiều này, giả sử chúng ta được cung cấp phụ thuộc hàm C → X. (Trường hợpX→ C tương tự.)

Giả sử r là một minh họa của lược đồ R và giả sử (x1, c, y1) và (x2, c, y2) là hai bộ giátrị trong r. Phụ thuộc hàm C→X dẫn đến x1=x2. Vì thế, (x1, c, y2) tương tự như (x2, c,y2) và (x2,c,y1) tương tự như (x1, c, y1), vì thế cả hai bộ này (x1, c, y2) và (x2, c, y1) đềunằm trong r. Vì thế r thỏa mãn JD: R = R1 R2. Vì r là một minh họa dữ liệu tùy ý nênchúng ta đã chứng minh được rằng phân rã này là không mất mát.

417/470

(⇒): Với chiều này, giả sử rằng không có C→ X cũng như C→Y. Chúng ta sẽ chứngminh rằng phép nối này là mất mát bằng cách chỉ ra một minh họa quan hệ nào đó viphạm JD: R1 R2. Giả sử chúng ta được cho một số tập của các phụ thuộc hàm Σ, đểR có một phép nối không mất mát với Σ. Điều này có nghĩa là bất kỳ minh họa r nàothảo mãn Σ, chúng ta có

r = r1 r2 trong đó r1 = πR1(r), r2 = πR2 (r).

Sau đó chứng minh rằng

{C → X, C → Y} ∩ Σ+ = ∅.

Chứng minh điều này bằng phản chứng. Giả sử rằng phép hợp {C → X,C → Y } ∩ Σ+

là rỗng. Giả sử r1 là một minh họa của lược đồ này và không thỏa mãn phụ thuộc hàmC→X và r2 là một minh họa không thỏa mãn phụ thuộc hàm C→Y. Chọn c để các bộgiá trị (x1, c, y1), (x2, c, y2) ∈ r1 trong đó x1 ≠ x2 và c’ để (x’1, c’, y’1), (x’2, c’, y’2) ∈r2 trong đó y’1 ≠ y’2.

Sử dụng phép chọn để thay thế r1 bằng π R.C=c(r1) và r2 bằng π R.C=c’ (r2). Vì r1 và r2 làhữu hạn và các tập hợp miền là vô hạn, chúng ta có thể giả sử mà không mất tính tổngquát (bằng cách thay đổi một số các giá trị của các bộ trong r1 và r2 nếu cần thiết) để

c=c’

π A(r1) Ç π A (r2) = ∅ với mỗi thuộc tính A ∈ X

π B(r1) Ç π B (r2) = ∅ với mỗi thuộc tính B ∈ Y

Bây giờ xem xét quan hệ r1 È r2. Đây là một minh họa của lược đồ R thỏa mãn Σ. Tuynhiên, (x1, c, y’1) ∉ r1 È r2, vì thế minh họa r1 È r2 không thỏa mãn JD: R1 R2.

Xem xét lược đồ R với các phụ thuộc hàm F được phân rã thành các lược đồ cùng vớicác thuộc tính X và Y. Chỉ ra rằng phép phân rã này bảo toàn phụ thuộc hàm nếu F ⊆(FXÈFY )+.

Dành cho độc giả.

Chứng minh rằng thuật toán phân rã một quan hệ thành các quan hệ con ở dạng 3NF bảotoàn phụ thuộc hàm và không mất mát kết nối (Phần 6.2) là đúng.

Dành cho độc giả

418/470

Chứng minh rằng việc tổng hợp thành 3NF đưa ra được một phép phân rã không mấtkết nối và vẫn giữ được tất cả các thuộc tính ban đầu.

Dành cho độc giả

Chứng minh rằng MVD X →→ Y trên quan hệ R có thể được biểu diễn bằng

{XY, X(R − Y )}.

Viết Z = R − Y. Vì, R = YXZ. X →→ Y nói rằng nếu (y1, x, z1), (y2, x, z2) ∈ R thì (y1,x, z2), (y2, x, z1) cũng ∈ R. Nhưng đây là chính xác nếu nói rằng R= {XY, X(R−Y)}.

Chứng minh rằng, nếu R chỉ có một khóa thì R ở BCNF nếu và chỉ nếu nó ở 3NF.

Dành cho độc giả

Chứng minh rằng, nếu R ở 3NF và tất cả các khóa là thuộc tính đơn, thì R ở BCNF.

Vì tất cả các khóa là thuộc tính đơn, nên chúng ta biết rằng với bất kỳ phụ thuộc hàmthỏa mãn X→A, trong đó A là một khóa. Thông qua định nghĩa của phụ thuộc hàm, nếubiết X thì cũng biết A. Điều này có nghĩa là nếu biết X, chúng ta biết một khóa nào đócủa quan hệ này, vì thế X phải là một siêu khóa. Điều này thỏa mãn tất cả các tính chấtcủa BCNF.

Chứng minh những phát biểu sau:

1. Nếu một lược đồ quan hệ nào đó ở BCNF và ít nhất một khóa của nó chứa một thuộctính đơn thì nó cũng ở 4NF.

2. Nếu một lược đồ quan hệ ở 3NF và mỗi khóa có một thuộc thíh đơn thì nó cũng ở5NF.

Dành cho độc giả

Trình bày một thuật toán để kiểm tra xem một quan hệ nào đó có ở BCNF không. Thuậttoán này nên là đa thức theo kích thước của tập phụ thuộc hàm được cho. (Kích thướclà tổng trên tất cả các phụ thuộc hàm của số lượng các thuộc tính xuất hiện trong phụthuộc hàm.) Có thuật toán đa thức để kiểm tra xem lược đồ quan hệ này có ở dạng 3NFkhông?

Giả sử |F| là ký hiệu của kích thước của sự biểu diễn lược đồ, tức là tập của tất cả cácphụ thuộc hàm của lược đồ này. Cũng như vậy, giả sử |f| là số lượng các phụ thuộc hàmtrên lược đồ này. Trong Bài 15 chúng ta biết rằng với mỗi thuộc tính trong lược đồ này,chúng ta có thể tính được bao đóng của các thuộc tính phía trái với thời gian O(|F|).

419/470

Thuật toán này để kiểm tra xem R ở BCNF bao gồm việc tính toán bao đóng của tậpthuộc tính bên phía trái của từng phụ thuộc hàm. Nếu một trong số chúng không bằngU trong đó U là tập của tất cả các thuộc tính, thì R không ở BCNF. Ngược lại kết luậnrằng R ở BCNF.

Rõ ràng độ phức tạp trong trường hợp xấu nhất của thuật toán này là O(|f|•|F|). Vì |f|được giới hạn bởi |F| nên độ phức tạp thời gian là |F|.

Mặt khác, không có một thuật toán nào kiểm tra một quan hệ có ở 3NF hay không vớiđộ phức tạp thời gian là đa thức. Vì để kiểm tra một phụ thuộc hàm đã cho nào đó cóvi phạm 3NF hay không chúng ta cần kiểm tra xem phía tay phải là nguyên tố không,tức là, là một tập con của một vài khóa của lược đồ này. Nhưng việc xác định (tất cả)các khóa của lược đồ này bao gồm việc kiểm tra tất cả các tập con của U. Cuối cùng làbài toán thuộc tính nguyên tố được biết là bài toán NP-đầy đủ và vấn đề 3NF rõ ràng làcũng khó như vậy, vì thế nó cũng là NP-đầy đủ.

Trình bày một thuật toán để kiểm tra xem một quan hệ nào đó có ở BCNF không. Thuậttoán này nên là đa thức theo kích thước của tập phụ thuộc hàm được cho. (Kích thướclà tổng trên tất cả các phụ thuộc hàm của số lượng các thuộc tính xuất hiện trong phụthuộc hàm.) Có thuật toán đa thức để kiểm tra xem lược đồ quan hệ này có ở dạng 3NFkhông?

Dành cho độc giả

Chứng minh rằng thuật toán phân rã một quan hệ thành các quan hệ con ở dạng BCNFtrong Phần 6.1 (tức là, nó đưa ra một tập các quan hệ ở BCNF và không mất mát kếtnối) là đúng và sẽ dừng lại.

1. Giả sử X ⊂ R , A là một thuộc tính đơn của R và X→A là một phụ thuộc hàm gây rasự vi phạm BCNF. Phân rã thành R − A và XA.

2. Nếu R − A hoặc XA không ở BCNF, tiếp tục phân rã chúng một cách đệ quy áp dụngthuật toán này.

Chứng minh sự đúng đắn của thuật toán được chia thành 3 phần:

Chứng minh rằng tất cả các phân rã là không mất mát:

Với mỗi phân rã R thành R − A và XA , nó là không mất mát theo định lý 3 của chươngnày. Đầu tiên, chúng ta nói rằng (R − A) Ç (XA) = X vì: X ⊂ R, và A không nằm trongX. Có phụ thuộc hàm X→A thì suy ra X→ XA bởi Luật hợp, vì thế (R − A) Ç (XA)→ XA và theo Định lý 3, phân rã này là không mất mát. Tuy nhiên, phân rã này có thểkhông bảo tồn phụ thuộc hàm.

420/470

Chứng minh rằng thuật toán sẽ dừng lại

Các phân rã của quan hệ R sẽ đưa ra các quan hệ R − A và XA. R−A sẽ có ít thuộc tínhhơn R vì A không rỗng, và vì phụ thuộc hàm này vi phạm BCNF nên A phải nằm trongR. Thêm nữa, XA có ít thuộc tính hơn R nên X ⊂ R và XA ≠ R. Điều này là rõ ràng vìnếu chúng ta giả sử rằng XA=R thì chúng ta có thể kết luận rằng X là siêu khóa vì XA→R và X→A nên X→R do tính bắc cầu. Điều này là trái với giả thiết rằng phụ thuộc hàmnày vi phạm BCNF nên chúng ta kết luận rằng XA ≠ R.

Nếu chúng ta giả sử rằng n là số các thuộc tính trong quan hệ ban đầu R, thì có nhiềunhất (2n-1) phân rã thuật toán sẽ thực hiện trước khi nó dừng lại. Khi một quan hệ nàođó chỉ chứa thuộc tính đơn, nó là BCNF và không thể được phân rã tiếp vì ở đây khôngcó các phụ thuộc hàm chúng ta có thể áp dụng để nó vi phạm BCNF.

Chứng minh rằng tất cả quan hệ trong tập cuối cùng đều ở BCNF

Như đã trình bày trong phần trước về vấn đề này, trong trường hợp xấu nhất phân rã Rthành một tập của n quan hệ gồm các thuộc tính đơn với n là số lượng các thuộc tính củaquan hệ ban đầu R. Như đã trình bày ở trên, mỗi quan hệ rõ ràng là ở BCNF. Quá trìnhphân rã có thể, và trong trường hợp xấu nhất, dừng trước khi chúng ta phân rã thành cácquan hệ chỉ có các thuộc tính đơn, thuật toán sẽ chỉ dừng khi tất cả các tập con của Rđều ở BCNF.

Tài liệu tham khảo

Tài liệu trình bày về lý thuyết phụ thuộc hàm và cách sử dụng nó trong thiết kế cơ sở dữliệu [3, 45, 501, 509, 747]. Những bài báo hay về chủ đề này gồm [755, 41, 5].

FDs được giới thiệu trong [187], cùng với khái niệm về 3NF, và các tiên đề để suy diễnphụ thuộc hàm được trình bày trong [38]. BCNF được giới thiệu trong [188]. Khái niệmvề một minh họa quan hệ được nghiên cứu trong [328]. FDs được tổng quát hoá thànhcác mô hình dữ liệu mức ngữ nghĩa trong [768].

Việc tìm một khoá là bài toán NP-đầy đủ được trình bày trong [497]. Phân rã không mấtkết nối được trình bày trong [28, 502, 627]. Phân rã bảo toàn phụ thuộc hàm được trìnhbày trong [74]. [81] giới thiệu về phủ tối thiểu. Phân rã một quan hệ thành các quan hệcon ở 3NF được trình bày trong [81, 98] và thành BCNF được trình bày trong [742].[412] chỉ ra rằng việc kiểm tra một quan hệ có ở 3NF không là bài toán NP-đầy đủ. [253]giới thiệu về 4NF và trình bày về việc phân rã thành 4NF. Fagin giới thiệu những dạngchuẩn khác trong [254] (dạng chuẩn project-join) và [255] (dạng chuẩn domain-key).Ngược lại với những nghiên cứu rộng lớn về phân rã theo chiều dọc, hiện nay đã có mộtsố nghiên cứu về cách phân rã theo chiều ngang. [209] nghiên cứu về phân rã này.

421/470

MVDs được nghiên cứu đầu tiên bởi Delobel [211], Fagin [253], và Zaniolo [789]. Tiênđề cho FDs và MVDs được trình bày trong [73]. [593] chỉ ra rằng không có tiên đề choJDs, mặc dù [662] cung cấp một tiên đề cho một lớp phổ biến của các phụ thuộc hàm.Những điều kiện đầy đủ cho 4NF và 5NF dưới dạng FDs được trình bày trong Phần 8 làbắt nguồn từ [205]. Các tiếp cận để thiết kế cơ sở dữ liệu sử dụng thông tin phụ thuộchàm để xây dựng các minh hoạ quan hệ dữ liệu được trình bày trong [508, 509].

422/470

Thiết kế cơ sở dữ liệu vật lý và những điềuchỉnh thiết kếCách một DBMS thực thi những truy vấn và cập nhật thông thường là thước đo cuốicùng để đánh giá phần thiết kế cơ sở dữ liệu. DBA có thể cải thiện khả năng thực thibằng cách xác định những nút cổ chai trong quá trình thực hiện và điều chỉnh một vàitham số của DBMS (ví dụ, kích thước của buffer pool hoặc tần số của checkpointing)hoặc thêm phần cứng để loại bỏ những nút cổ chai. Tuy nhiên, bước đầu tiên để đạt đượchiệu quả trong thực thi là lựa chọn được thiết kế cơ sở dữ liệu tốt, đây là nội dung chínhcủa chương này.

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ếnhà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ủangườ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ẩngiú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

423/470

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ôngcụ 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ệuvà 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 tacó 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átvà 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:

424/470

• 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 ghinợ 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ỉnhcơ 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.

425/470

• 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ộtsố 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úngta 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ủanó. 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ổ sung

426/470

này sẽ là ứng cử viên trong danh sách chỉ mục của chúng ta. Nói chung, những truy cậ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ợitừ 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úngta 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ếmlà đ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ợpnà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.

427/470

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ênmộ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 chocá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 địnhtạ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ậtthườ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ụ saukhô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 tinbổ 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:

428/470

SELECT E.ename, D.mgr FROM Employees E, Departments DWHERE 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ínhdname 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ủaDepartments 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ìmcác bộ giá trị tương ứng trong Employees bằng việc sử dụng một chỉ mục trên thuộctí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 dnocủ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êntrườ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 trongDepartments 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ênage sau đó được áp dụng theo kiểu on-the-fly. Tuy nhiên, không như những thay đổitrướ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ủaEmployees nếu chúng ta có một chỉ mục nào đó trên trường age. Trong trường hợp nàychú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êndname (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ốinhữ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ạchnà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ụngtrong 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.

429/470

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ạmvi 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ư trongtruy 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ủaDepartments. Nhưng chỉ mục nào trên Employees là tốt nhất? Một chỉ mục B+tree trênthuộ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 đượcphâ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 ứngtrong 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ònlạ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ênhobby) 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ộcvà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ềungườ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ụcbăm trên hobby là tốt nhất.

430/470

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 DWHERE 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êndname 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ênxâ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 trongcủ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ấtnê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àychứ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ấnkiể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 truyvấ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ệunà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 DWHERE 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áclợ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ậpcá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ỉ

431/470

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

432/470

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ậttự 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ếutớ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ết1: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ắpgiáp từ các sản phẩm khác, như nội dung của bảng Assembly chỉ ra), trường cost đượctí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ườngpartid. 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úngta 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ácbả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ủaAssembly(A) thoả mãn P.pid = A.partid theo sau. Cách tiếp cận này cải thiện được việclư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 ngaylậ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ộtchỉ 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ếnlượ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

433/470

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 địnhvị 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úngta 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ủaphâ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ìmtổ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ạitươ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

434/470

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ụmvì 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 WHERED.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 tacó 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ốilặ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ườnghợ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ốthơ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ụcB+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ủaEmployees đều chứa trong cổng vào dữ liệu của bộ giá trị đó trong chỉ mục này. Chúngta 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. (Ghinhớ 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.

435/470

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ụcthí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!

(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à: ∑i = 1

c 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ụ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.

436/470

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ôngcụ 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àycó 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

437/470

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ùngcó 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 chonó 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

438/470

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 tavề 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úngta đã bàn luận ở trên:

SELECT D.mgr FROM Employees E, Departments D WHERED.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ườngdno 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ạchnhư 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ủaEmployees.

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ụmtrên trường dno của Employees và thay thế nó bằng một chỉ mục được phân cụm.

439/470

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ọncó 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ựctế 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 xemxé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.

440/470

• Trong những trường hợp khác, chúng ta có lẽ muốn thực hiện phi chuẩn. Tứclà, 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ùnglà 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áckế 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. Thaythế đ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à

441/470

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ộtbộ 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 pidbằng partid) cho dự án J (với jid bằng projectid) quản lý bởi phòng D (với deptid bằngdid), 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ùngmộ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òngnà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ểudiễ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ủanhữ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úngta chỉ tập trung vào quan hệ Contracts.

442/470

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à Cvà 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àmkhô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 tasẽ 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àysử 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 quanhệ Contracst. Vì did là một khóa của Departments, bây giờ chúng ta có một phụ thuộchà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ếtdư 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.

443/470

• 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àmJP→ 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ếtlậ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ểmtra ràng buộc này như sau:

CREATE ASSERTION checkDep CHECK ( NOT EXISTS ( SELECT *FROM PartInfo PI, ContractInfo CI WHEREPI.supplierid=CI.supplierid AND CI.deptid=Cl.deptid GROUPBY 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ênlà 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ệ Contractsthà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

444/470

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ạmrà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ểmchuẩ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ể đượcthự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ậtphổ 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áchợ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ảmsự 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ị ảnhhưở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ệnkhả 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ảikế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ệ đượcphâ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ứclà 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 connà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 đấugiá). 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ệnvalue > 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âncụm trên trường value của Contracts. Một lựa chọn nữa là chúng ta thay thế Contractsbằng hai quan hệ gọi là LargeContracts và SmallContracts, với ý nghĩa như trên.

445/470

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ìngọi là Contracts:

CREATE VIEW Contracts (cid, supplierid, projectid, deptid,partid, qty, value) AS ((SELECT * FROM LargeContracts)UNION (SELECT * FROM SmallContracts))

Tuy nhiên, với các truy vấn có thể thực hiện được chỉ cần LargeContracts thì chỉ cầntruy cập trực tiếp trên LargeContracts mà không phải trên khung nhìn. Thực hiện cáctruy 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ếtquả 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ùngContracts 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ơnmộ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ã.

Các lựa chọn cho điều chỉnh chỉ mục và khung nhìn

Bước đầu tiên trong điều chỉnh một khung nhìn nào đó là hiểu được các kế hoạch màDBMS đã sử dụng để đánh giá truy vấn. Các hệ thống thường cung cấp một số khả năngđể xác định các kế hoạch đã được sử dụng để đánh giá truy vấn. Khi chúng ta hiểu đượccác kế hoạch nào mà hệ thống đã lựa chọn, chúng ta có thể cân nhắc các cách thức đểcải thiện khả năng thực thi. Chúng ta có thể xem xét các lựa chọn khác nhau của chỉmục hoặc có thể đồng-phân-cụm hai quan hệ cho các truy vấn có sự liên kết, việc nàysẽ được định hướng bằng những hiểu biết của chúng ta về các kế hoạch cũ và một kếhoạch tốt hơn nào đó mà chúng ta muốn DBMS sử dụng. Chi tiết tương tự như quá trìnhthiết kế ban đầu.

Một điều nên làm là trước khi tạo các chỉ mục mới, chúng ta nên cân nhắc xem có nênviết lại các truy vấn này mà vẫn sử dụng các chỉ mục đã tồn tại. Ví dụ, xem xét truy vấnsau có từ nối OR.

SELECT E.dno FROM Employees E WHERE E.hobby= ‘Stamps’ ORE.age=10

Nếu chúng ta có hai chỉ mục trên cả hobby và age, chúng ta có thể sử dụng các chỉmục này để truy cập các bộ giá trị cần thiết, nhưng bộ tối ưu có lẽ không nhận ra đượcđiều này. Bộ tối ưu có lẽ xem xét các điều kiện trong mệnh đề WHERE tuần tự, quétEmployees, và áp các điều kiện chọn theo kiểu on-the-fly. Giả sử chúng ta viết lại truyvấn này dùng phép hợp của hai truy vấn, một truy vấn có mệnh đề WHERE E.hobby

446/470

='Stamps' và truy vấn khác có mệnh đề WHERE E.age=10. Khi đó mỗi truy vấn đượcthực hiện một cách hiệu quả với việc hỗ trợ của cả hai chỉ mục trên hobby và age.

Chúng ta cũng nên xem xét việc viết lại các truy vấn để tránh một số phép toán phải trảgiá đắt. Ví dụ, truy vấn có mệnh đề DISTINCT để loại đi các giá trị trùng nhau, truy vấndạng này sẽ phải trả giá đắt. Vì thế, chúng ta nên loại mệnh đề DISTINCT bất cứ khinào có thể. Ví dụ, với một truy vấn trên một quan hệ đơn, chúng ta có thể loại bỏ mệnhđề DISTINCT bất cứ khi nào có cả hai tình huống sau:

• Chúng ta không quan tâm đến sự hiện diện của các bộ giá trị trùng nhau.• Các thuộc tính được nhắc đến trong mệnh đề SELECT bao gồm một khoá dự

tuyển của quan hệ này.

Đôi khi một truy vấn có mệnh đề GROUP BY và HAVING có thể được thay thế bằngmột truy vấn mà không có hai mệnh đề này, do vậy loại bỏ được một thao tác sắp xếp.Ví dụ, xem xét:

SELECT MIN (E.age) FROM Employees E GROUP BY E.dno HAVINGE.dno=102

Truy vấn này tương đương với truy vấn:

SELECT MIN (E.age) FROM Employees E WHERE E.dno=102

Các truy vấn phức tạp thường được viết lại trong một số bước sử dụng một quan hệtạm. Chúng ta có thể viết lại những truy vấn này mà không có quan hệ tạm để nó chạynhanh hơn. Xem xét truy vấn để tính lương trung bình của các phòng có người quản lýlà Robinson:

SELECT * INTO Temp FROM Employees E, Departments D WHEREE.dno=D.dno AND D.mgrname= ‘Robinson’ SELECT T.dno, AVG(T.sal) FROM Temp T GROUP BY T.dno

Truy vấn này có thể được viết lại như sau:

SELECT E.dno, AVG (E.sal) FROM Employees E, Departments DWHERE E.dno=D.dno AND D.mgrname= ‘Robinson’ GROUP BY E.dno

Việc viết lại truy vấn này mà không cần sử dụng quan hệ trung gian Temp làm nó thựchiện nhanh hơn. Thực tế, bộ tối ưu có thể tìm được một kế hoạch chỉ-chỉ-số rất hiệuquả, kế hoạch này không bao giờ truy cập các bộ giá trị Employees nếu ở đó có một chỉmục B+tree tổ hợp trên (dno, sal). Ví dụ này còn minh hoạ cho nhận xét sau: Bằng việcviết lại các truy vấn để tránh những bảng tạm không cần thiết, chúng ta không chỉ tránh

447/470

được việc tạo ra các quan hệ tạm, chúng ta còn mở ra nhiều khả năng tối ưu cho các bộtối ưu hóa khám phá.

Tuy nhiên, trong một số trường hợp, nếu bộ tối ưu hoá không thể tìm ra được kế hoạchtốt cho các truy vấn phức tạp (như các truy vấn lồng nhau có nhiều quan hệ liên quan),thì việc nên làm là viết lại truy vấn để nó sử dụng các bảng tạm và định hướng cho bộtối ưu hoá lựa chọn một kế hoạch tốt.

Thực tế, các truy vấn lồng nhau thường không hiệu quả vì rất nhiều bộ tối ưu không giảiquyết tốt chúng, như đã trình bày trong Phần 5. Vì thế, chúng ta nên viết lại các truy vấnlồng nhau và các truy vấn liên kết. Như đã lưu ý ở trên, chúng ta có thể viết lại nhữngtruy vấn này bằng cách sử dụng các bảng tạm và các công nghệ khác (được làm bằngcác bộ tối ưu hoá là tốt nhất) đã được nghiên cứu rộng rãi.

Khả năng viết lại các truy vấn lồng nhau thành không lồng nhau sử dụng các bảng tạmđược minh họa trong Phần 5.

Ảnh hưởng của tương tranh

Trong một hệ thống có nhiều người sử dụng đồng thời, chúng ta phải xem xét thêm mộtsố điểm. Các giao dịch thực hiện khoá trên một số trang mà chúng đang truy cập, vì thếcác giao dịch khác bị ngăn không được truy cập những trang này.

Như những trình bày trong Phần 16.5, để thực thi đạt hiệu quả cao thì thời gian ngănchặn phải được tối thiểu hoá và chúng ta đã chỉ ra hai cách để giảm thời gian này.

• Giảm thời gian nắm giữ các khoá của các giao dịch.• Giảm các hot spots.

Bây giờ chúng ta bàn đến các công nghệ được sử dụng để đạt đến hai đích này.

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ếnchươ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ếtthú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áckhoá 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ụcliê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

448/470

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ậptớ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 (xemphầ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ịchnhỏ 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ộtloạ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ảigiả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ântí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ủadữ 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ấnnà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 đưara 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ơnnhư REPEATABLE READ hoặc READ COMMITTED (Phần 16.6). Các mức cô lậpthấ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 đượcsử 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ậtmộ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àoquan hệ Employees theo thứ tự của eid và chúng ta có một chỉ mục B+tree trên eid, mỗibộ 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 hotspots 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ộtchỉ 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ớivà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ì

449/470

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ủamỗ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ácbả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 đượcthê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ụcB+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ụcnà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áchot 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 trongmộ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úngta 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ảyra 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íchthướ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ằngnhau. Trong trường hợp này chỉ mục ISAM sẽ cần chi phí khoá thấp hơn (và giảm đượcsự 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áctrang 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 bucketnà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.

Trường hợp nghiên cứu: Cửa hàng Internet

Xem lại ví dụ của chúng ta, DBDudes Dudes xem xét các luồng công việc cho cửa hàngB&N. Người chủ của cửa hàng mong muốn những khách hàng của anh ấy được tìmkiếm sách theo mã ISBN trước khi đặt hàng. Quá trình đặt hàng thông qua hóa đơn baogồm việc thêm một bản ghi vào bảng Orders và thêm một hoặc nhiều bản ghi vào quanhệ Orderlists. Nếu số lượng hàng đặt của khách hàng đã có sẵn, thì người ta sẽ chuẩn bịđưa hàng và ngày giao hàng (ship_date) trong quan hệ Orderlists được thiết đặt. Thêmnữa, số lượng sách trong kho thay đổi theo thời gian, vì các hóa đơn đặt hàng đến thì

450/470

hàng được chuyển đi, số lượng trong kho sẽ giảm. Còn khi nhà cung cấp mang sách đếnthì số lượng này sẽ tăng lên.

Nhóm DBDudes bắt đầu bằng việc xem xét tìm kiếm sách theo ISBN. Vì isbn là mộtkhóa, một truy vấn bằng theo mã isbn sẽ trả về nhiều nhất một bản ghi. Vì thế, để tăngtốc độ các truy vấn của khách hàng tìm kiếm sách theo isbn, DBDudes quyết định xâydựng một chỉ mục không phân cụm trên isbn.

Tiếp theo, ta xem xét việc cập nhật số lượng một cuốn sách nào đó. Để cập nhật giá trịqty_in_stock cho một quyển sách, đầu tiên chúng ta phải tìm kiếm quyển sách này; sửdụng chỉ mục trên isbn sẽ tăng tốc độ công việc này. Vì giá trị của trường qty_in_stockđược cập nhật rất thường xuyên, DBDudes cũng xem xét việc phân vùng quan hệ Bookstheo chiều dọc thành hai quan hệ sau:

BooksQty(isbn, qty)

BookRest(isbn, title, author, price, year_published)

Nhưng không may là việc phân vùng theo chiều dọc này làm chậm đi rất nhiều các truyvấn thường xuyên khác: Bây giờ, việc tìm kiếm theo ISBN để truy cập tất cả thông tinvề một quyển sách nào đó yêu cầu một kết nối giữa BooksQty và BooksRest. Vì thếDBDudes quyết định không phân vùng quan hệ Books nữa.

DBDudes nghĩ rằng có thể khách hàng cũng muốn tìm kiếm sách theo tiêu đề (title) vàtác giả (author), và từ đó họ quyết định thêm một chỉ mục không phân cụm trên title vàauthor- duy trì các chỉ mục này không đắt vì số đầu sách hiếm khi thay đổi.

Tiếp theo, DBDudes xem xét quan hệ Customers. Một khách hàng nào đó đầu tiên đượcxác định đầu tiên bằng mã số của họ. Vì thế, truy vấn thường gặp nhất trên quan hệCustomers là truy vấn bằng theo mã khách hàng, và DBDudes quyết định xây dựng mộtchỉ mục phân cụm trên cid để tối ưu được thời gian thực hiện truy vấn này.

Chuyển đến quan hệ Orders, DBDudes nhìn thấy rằng sẽ có hai truy vấn: thêm các hóađơn mới và truy cập các hóa đơn đang tồn tại. Cả hai truy vấn này sẽ có thuộc tínhordernum là khóa tìm kiếm và vì thế DBDudes quyết định xây dựng một chỉ mục trênnó. Kiểu chỉ mục nên là gì: B+tree hay chỉ mục băm?

Vì mã số hóa đơn (order numbers) được thêm vào một cách tuần tự và tương ứng vớingày lập hóa đơn (order date) nên việc sắp xếp theo order numbers hiệu quả thì sắpxếp theo order date cũng hiệu quả. Vì thế DBDudes quyết định xây dựng một chỉ mụcB+tree phân cụm trên ordernum. Mặc dù các thao tác được đề cập từ đầu đến bây giờđều không thích cả chỉ mục B+tree và chỉ mục băm, nhưng B&N muốn kiểm soát tốtnhững thao tác hàng ngày xảy ra và chỉ mục phân cụm B+tree là lựa chọn tốt hơn chonhững truy vấn phạm vi. Tất nhiên, điều này có nghĩa là việc truy cập tất cả các hóa đơn

451/470

ứng với một khách hàng nào đó sẽ phải trả giá đắt đối với những khách hàng có nhiềuhóa đơn, vì việc phân cụm theo ordernum sẽ không cho phép phân cụm theo các thuộctính khác, ví dụ như là cid.

Các thao tác trong quan hệ Orderlists hầu như là các thao tác thêm bản ghi, và đôi khicó thêm thao tác cập nhật ngày chuyển hàng (shipment date) hoặc một truy vấn liệt kêtất cả các thành phần của một hóa đơn nào đó. Nếu Orderlists được lưu theo thứ tự sắpxếp của ordernum, tất cả các thao tác thêm được chèn vào cuối của quan hệ và vì thếsẽ rất hiệu quả. Một chỉ mục phân cụm B+tree trên ordernum duy trì thứ tự sắp xếp nàyvà cũng giúp tăng tốc độ của việc truy cập tất cả các thành phần của một hóa đơn nàođó. Để cập nhật một shipment date, chúng ta cần tìm kiếm bộ giá trị này theo ordernumvà isbn. Chỉ mục trên ordernum hỗ trợ tốt điều này. Mặc dù một chỉ mục nào đó trên(ordernum, isbn) sẽ thực tốt hơn nhưng các thao tác thêm sẽ không được thực hiện hiệuquả như sử dụng chỉ mục chỉ trên ordernum; vì thế DBDudes quyết định chỉ mục trênquan hệ Orderlists chỉ bằng một thuộc tính ordernum.

Đ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óirằ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 ghirấ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ốnsá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 đơnchư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 Ordersvà 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áctruy 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âygiờ, 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ủamộ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.

452/470

Tiêu chuẩn đánh giá DBMS

Phía trên chúng ta đã xem xét cách cải thiện thiết kế cơ sở dữ liệu để đạt được kết quảthực thi tốt hơn. Tuy nhiên, khi cơ sở dữ liệu lớn lên, DBMS có thể không còn khả năngcung cấp các công cụ hỗ trợ thực thi tốt nữa, mặc dù thiết kế đã tốt nhất có thể, vì thếchúng ta phải xem xét cách nâng cấp hệ thống của chúng ta, cụ thể là mua các phần cứngnhanh hơn và bổ sung thêm bộ nhớ. Chúng ta cũng có thể cân nhắc khả năng chuyển cơsở dữ liệu của chúng ta sang một DBMS mới.

Khi đánh giá các sản phẩm DBMS, khả năng thực thi là một vấn đề quan trọng. DBMSlà một tập hợp của các phầm mềm phức tạp, và các nhà cung cấp khác nhau có thể cónhững chiến lược phát triển sản phẩm của họ khác nhau để nhắm vào các thị trường. Vídụ, một số hệ thống được thiết kế để thực hiện hiệu quả các truy vấn phức tạp, trongkhi các hệ thống khác lại được thiết kế để thực hiện tốt các giao dịch đơn giản. Để hỗtrợ người dùng lựa chọn một DBMS phù hợp với yêu cầu của họ, một vài tiêu chuẩn đãđược phát triển. Nó bao gồm các tiêu chuẩn để đo khả năng thực thi một lớp hiện tại củacác ứng dụng (ví dụ, tiêu chuẩn TPC) và các tiêu chuẩn để đo hiệu quả thực thi của mộtDBMS trên một dãy các thao tác (ví dụ, Wisconsin benchmark).

Tiêu chuẩn nên gọn nhẹ, dễ hiểu. Chúng cũng nên đo được các thực thi cực lớn (ví dụ,giao dịch trên một giây hay còn gọi là tps) cũng như tỷ lệ giá/thực thi (ví dụ $/tsp) chocác luồng dữ liệu điển hình trong một miền ứng dụng nào đó. Transaction ProcessingCouncil (TPC) được tạo ra để định nghĩa các tiêu chuẩn cho quá trình xử lý giao dịchvà các hệ thống cơ sở dữ liệu. Các tiêu chuẩn nổi tiếng đã được các nhà nghiên cứu vàcác tổ chức công nghệ đề xuất. Các Tiêu chuẩn do các nhà phát triển hệ thống đưa ra sẽkhông hữu ích đối với việc so sách các hệ thống khác nhau (mặc dù chúng có thể hữuích trong việc xác định một hệ thống nào đó quản lý một luồng công việc cụ thể tốt nhưthế nào).

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 địnhnghĩ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ạngmáy tính cộng với DBMS, ngược lại TPC-B benchmark xem xét chỉ riêng DBMS. Cáctiê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ácnhau, 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ịchphâ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ộtcá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 sosá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ừngkhá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 giaodị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ể

453/470

thay thế hoàn toàn được TPC-A và TPC-B như là một benchmark xử lý giao dịch chuẩntắc.

Query Benchmarks: Wisconsin benchmark được sử dụng rộng rãi để đo sự thực thi củacá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 truyvấn phức tạp hơn, và AS3AP benchmark đo khả năng thực thi của luồng công việc giữacá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 Councilcũ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. Sequoia2000 benchmark được thiết kế để so sánh các DBMS hỗ trợ các hệ thống thông tin địalý.

Object-Database Benchmarks: Benchmarks 001 và 007 đo khả năng thực thi của cáchệ thống cơ sở dữ liệu hướng đối tượng. Bucky benchmark đo khả năng thực thi của cáchệ 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êuchuẩ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 ghinhớ 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 đượclự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 DBMSquan 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ôngviệ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ệmcho 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ũngxem xét ngữ cảnh mà benchmark này được đánh giá. Ví dụ, thời gian thực hiện của cáctruy 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ộthệ 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ệnchậ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ựchiệ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.

454/470

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ằngcách thay đổi các benchmark chuẩn một cách tinh tế hoặc thay thế các công việc trongmộ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.

Bài tập

Xem xét lược đồ BCNF sau, nó là một phần cơ sở dữ liệu của một công ty (những thôngtin không liên quan đến câu hỏi đã bị lược bỏ):

Emp (eid, ename, addr, sal, age, yrs, deptid)

Dept (did, dname, floor, budget)

Giả sử bạn biết rằng sáu truy vấn sau là sáu truy vấn quan trọng nhất trong các lưu lượngcông việc và chúng có tần xuất xuất hiện và tầm quan trọng ngang nhau.

• Liệt kê eid, ename, và addr của các nhân viên ở một độ tuổi nào đó do ngườidùng nhập vào.

• Liệt kê eid, ename, và addr của các nhân viên làm việc trong một phòng nào đódo người dùng nhập vào.

• Liệt kê eid và addr của các nhân viên có tên nào đó do người dùng nhập vào.• Liệt kê lương trung bình của các nhân viên.• Liệt kê lương trung bình của các nhân viên theo từng tuổi, tức là với mỗi giá trị

của tuổi lưu trong cơ sở dữ liệu, liệt kê tuổi và lương trung bình tương ứng vớituổi đó.

• Liệt kê tất cả thông tin về các phòng, sắp xếp theo thứ tự tầng.1. Cho những thông tin trên và giả sử rằng sáu truy vấn này quan trọng hơn bất kỳ

một lệnh cập nhật nào, thiết kế lược đồ vật lý cho cơ sở dữ liệu này để các lưulượng công việc mong muốn được thực hiện hiệu quả. Cụ thể, bạn hãy quyếtđịnh những thuộc tính nào sẽ được chỉ mục và các chỉ mục này có phân cụmhay không phân cụm. Giả sử rằng chỉ có các chỉ mục B+tree là kiểu chỉ mụcđược hỗ trợ bởi các DBMS và khóa có thể là thuộc tính đơn hay đa-thuộc-tính.Chỉ rõ thiết kế vật lý của bạn bằng việc xác định các thuộc tính bạn đề nghị chỉmục hóa qua B+tree phân cụm hay không phân cụm.

2. Thiết kế lại lược đồ vật lý giả sử rằng tập các truy vấn quan trọng ở trên đượcthay bằng tập các truy vấn sau:

• Liệt kê eid và addr của các nhân viên nào đó do người dùng nhập vào.• Liệt kê lương lớn nhất của nhân viên.• Liệt kê lương trung bình của các nhân viên theo phòng; tức là với mỗi giá trị

của deptid, liệt kê deptid và lương trung bình của các nhân viên trong phòngđó.

• Liệt kê tổng ngân sách (budget) của tất cả các phòng theo tầng; tức là với mỗitầng, liệt kê tầng và tổng ngân sách tương ứng.

455/470

• Giả sử rằng lưu lượng công việc được điều chỉnh tự động bằng công cụ điềuchỉnh chỉ mục tự động. Gạch đầu dòng những bước chính mà thuật tóan điềuchỉnh chỉ mục thực hiện và tập các cấu hình ứng cử viên sẽ được xem xét.

Câu trả lời với mỗi câu hỏi như sau:

• Nếu chúng ta tạo ra một chỉ mục B+tree ‘rậm rạp’ trên <age, sal> của quan hệEmp, chúng ta có thể thực hiện quét chỉ-chỉ-số để trả lời truy vấn thứ năm. Chỉmục băm sẽ không phục vụ mục đích của chúng ta, vì các cổng vào dữ liệu sẽkhông được sắp xếp trên age! Nếu việc quét chỉ-chỉ-số không cho phép tạo ramột chỉ mục phân cụm B+tree chỉ trên trường age của Emp.

• Chúng ta nên tạo ra một chỉ mục B+tree không phân cụm trên depid của quanhệ Emp và một chỉ mục không phân cụm khác trên <dname, did> của quan hệDept. Sau đó, chúng ta có thể thực hiện việc tìm kiếm chỉ-chỉ-số trên Dept vàsau đó lấy các bản ghi của Emp với depid thích hợp cho truy vấn thứ hai.

• Chúng ta nên tạo ra một chỉ mục không phân cụm trên ename của quan hệ Empcho truy vấn thứ ba.

• Chúng ta muốn một chỉ mục phân cụm B+tree ‘thưa thớt’ trên trường floor củachỉ mục Dept để chúng ta có thể có phòng ứng với mỗi tầng theo thứ tự của cáctầng cho truy vấn thứ sáu.

• Cuối cùng, chỉ mục không phân cụm ‘rậm rạp’ trên sal sẽ cho phép chúng tatính trung bình lương của tất cả các nhân viên sử dụng việc quét chỉ-chỉ-số. Tuynhiên, chỉ mục B+tree không phân cụm ‘rậm rạp’ trên <age, sal> được tạo rađể hỗ trợ Truy vấn (5) cũng có thể sử dụng để tính lương trung bình của tất cảcác nhân viên, và nó cũng tốt cho truy vấn này giống như khi chúng ta sử dụngmột chỉ mục nào đó chỉ trên trường sal. Vì thế chúng ta không nên tạo ra mộtchỉ mục riêng rẽ chỉ trên sal.

2.

• Chúng ta nên tạo ra một chỉ mục B+tree không phân cụm trên ename cho quanhệ Emp để chúng ta có thể tìm các nhân viên cùng với một tên cụ thể nào đócho truy vấn đầu tiên một cách hiệu quả. Đây không phải là kế hoạch chỉ-chỉ-số.

• Một chỉ mục B+tree không phân cụm trên sal cho quan hệ Emp sẽ giúp tìm ralương cao nhất cho truy vấn thứ hai. (Nó thực hiện tốt hơn chỉ mục băm vì hàmnhóm là MAX-chúng ta có thể đơn giản đi xuống trang lá phía phải nhất trongchỉ mục B+tree). Đây không phải là kế hoạch chỉ-chỉ-số.

• Chúng ta nên tạo ra một chỉ mục B+tree không phân cụm trên <deptid, sal> củaquan hệ Emp để chúng ta có thể thực hiện việc quét chỉ-chỉ-số trên tất cả cácnhân viên của một phòng nào đó. Nếu các kế hoạch chỉ-chỉ-số không được hỗtrợ, thì chỉ mục B+tree phân cụm ‘thưa thớt’ trên deptid sẽ là tốt nhất. Nó sẽcho phép chúng ta truy cập các bộ giá trị theo deptid.

456/470

• Chúng ta nên tạo ra một chỉ mục không phân cụm ‘rậm rạp’ trên <floor,budget> cho Dept. Điều này sẽ cho phép chúng ta tính tổng các ngân sách theotầng sử dụng một kế hoạch chỉ-chỉ-số. Nếu các kế hoạch chỉ-chỉ-số không đượchỗ trợ, chúng ta nên tạo ra một chỉ mục B+tree phân cụm ‘thưa thớt’ trêntrường floor cho quan hệ Dept để chúng ta có thể tìm ra các phòng trên mỗitầng theo thứ tự của tầng.

Xem xét lược đồ quan hệ BCNF sau, nó là một phần của cơ sở dữ liệu của một trườngđại học (những thông tin không liên quan đến câu hỏi đã bị lược bỏ):

Prof(ssno, pname, office, age, sex, specialty, dept_did)

Dept( did , dname, budget, num_majors, chair_ssno)

Giả sử bạn biết rằng năm truy vấn sau đây là các truy vấn thường gặp nhất trong lưulượng công việc của trường đại học này và cả năm truy vấn có tần suất xuất hiện và tầmquan trọng ngang nhau.

• Liệt kê pname, age, và office của các giáo sư (professors) theo giới tính (sex)người dùng nhập vào (male hoặc female) và có lĩnh vực nghiên cứu đặc biệt(specialty) do người dùng nhập vào (ví dụ, “recursive query processing”).Giảsử rằng trường đại học này có nhiều nhóm nghiên cứu khác nhau, ít xảy ra khảnăng có nhiều giáo sư có cùng lĩnh vực nghiên cứu đặc biệt.

• Liệt kê tất cả thông tin về các bộ môn và các giáo sư ở một độ tuổi nào đó dongười dùng nhập vào.

• Liệt kê did, dname, và chairperson name của các bộ môn có giá trị num_majorsnào đó do người dùng nhập vào.

• Liệt kê ngân quỹ thấp nhất của một bộ môn nào đó• Liệt kê tất cả các thông tin về các giáo sư là người lãnh đạo bộ môn.

Những truy vấn này xảy ra thường xuyên hơn nhiều so với các lệnh cập nhật, vì thế bạnnên xây dựng bất cứ chỉ mục nào có thể làm tăng tốc độ các truy vấn này. Tuy nhiên,bạn không nên xây dựng các chỉ mục không cần thiết, vì các lệnh cập nhật sẽ xảy ra (vàsẽ bị chậm vì các chỉ mục không cần thiết này). Bạn hãy thiết kế một lược đồ vật lý chotrường đại học này để nó thực hiện tốt những lưu lượng công việc mong muốn. Cụ thể,bạn hãy quyết định những thuộc tính nào sẽ được chỉ mục và có phân cụm hay khôngphân cụm. Giả sử rằng các chỉ mục B+tree và chỉ mục băm là kiểu chỉ mục được hỗ trợbởi các DBMS và khóa có thể là thuộc tính đơn hay đa-thuộc-tính.

1. Chỉ rõ thiết kế vật lý của bạn bằng việc xác định các thuộc tính nên chỉ mục hóa, vớimỗi chỉ mục bạn chỉ rõ nó được phân cụm hay không phân cụm và nó nên là B+tree haylà chỉ mục băm.

457/470

2. Giả sử rằng lưu lượng công việc này được điều chỉnh bằng công cụ điều chỉnh chỉmục tự động. Gạch đầu dòng những bước chính mà thuật toán điều chỉnh chỉ mục thựchiện và tập các cấu hình ứng cử viên sẽ được xem xét.

3. Thiết kế lại lược đồ vật lý, giả sử rằng năm truy vấn quan trọng trên được thay bằngcác truy vấn khác:

• Liệt kê từng bộ môn và các lĩnh vực nghiên cứu đặc biệt do các giáo sư của bộmôn đó thực hiện.

• Tìm bộ môn có num_majors thấp nhất.• Tìm giáo sư trẻ nhất là người lãnh đạo bộ môn.

Dành cho độc giả

Xem xét lược đồ BCNF sau, đây là một phần cơ sở dữ liệu của một công ty (nhữngthông tin không liên quan đến câu hỏi đã bị lược bỏ):

Project(pno, proj_name, proj_base_dept, proj_mgr, topic, budget)

Manager(mid, mgr_name, mgr_dept, salary, age, sex)

Ghi nhớ rằng mỗi dự án được thực hiện bằng một vài phòng, mỗi người quản lý là nhânviên trong một vài phòng, và người quản lý của một dự án nào đó không nhất thiết phảilà nhân viên của phòng thực hiện dự án đó. Giả sử bạn biết rằng năm truy vấn sau đây lànăm truy vấn quan trọng nhất và cả năm truy vấn đều có tần xuất xuất hiện và tầm quantrọng ngang nhau:

• Liệt kê mgr_name, age, và salary của người quản lý có giới tính nào đó dongười dùng nhập vào (male hoặc female) đang làm việc tại một phòng nào đó.Bạn có thể giả sử rằng, có rất nhiều phòng và mỗi phòng có rất ít người quản lýdự án.

• Liệt kê tên của tất cả dự án cùng với người quản lý ở độ tuổi nào đó do ngườidùng nhập vào (ví dụ, tuổi nhỏ hơn 30).

• Liệt kê tên của tất cả các phòng mà người quản lý trong phòng này quản lý dựán do chính phòng này thực hiện.

• Liệt kê tên của các dự án có ngân sách thấp nhất.• Liệt kê tên của tất cả người quản lý trong cùng một phòng.

Những truy vấn này xảy ra thường xuyên hơn nhiều so với các lệnh cập nhật, vì thế bạnnên xây dựng bất cứ chỉ mục nào có thể làm tăng tốc độ các truy vấn này. Tuy nhiên,bạn không nên xây dựng các chỉ mục không cần thiết, vì các lệnh cập nhật sẽ xảy ra(và sẽ bị chậm vì các chỉ mục không cần thiết này). Bạn hãy thiết kế một lược đồ vật lýđể nó thực hiện tốt những lưu lượng công việc mong muốn. Cụ thể, bạn hãy quyết địnhnhững thuộc tính nào sẽ được chỉ mục và các chỉ mục này có phân cụm hay không phân

458/470

cụm. Giả sử rằng các chỉ mục B+tree và chỉ mục băm là kiểu chỉ mục được hỗ trợ bởicác DBMS và khóa có thể là thuộc tính đơn hay đa-thuộc-tính.

1. Chỉ rõ thiết kế vật lý của bạn bằng việc xác định các thuộc tính bạn đề nghị chỉmục hóa, với mỗi chỉ mục bạn chỉ rõ nó được phân cụm hay không phân cụmvà nó nên là B+tree hay là chỉ mục băm.

2. Giả sử rằng lưu lượng công việc này được điều chỉnh bằng công cụ điều chỉnhchỉ mục tự động. Gạch đầu dòng những bước chính mà thuật toán điều chỉnhchỉ mục thực hiện và tập các cấu hình ứng cử viên sẽ được xem xét.

3. Thiết kế lại lược đồ vật lý, giả sử rằng năm truy vấn quan trọng trên được thaybằng các truy vấn khác:

• Tìm tổng số ngân quỹ của các dự án được quản lý bằng mỗi người quản lý; tứclà, liệt kê tất cả proj_mgr và tổng số ngân quỹ của các dự án được người quảnlý này quản lý tương ứng.

• Tìm tổng số ngân quỹ của các dự án được quản lý bằng mỗi người quản lýnhưng chỉ với những người quản lý nằm trong độ tuổi nào đó do người dùngnhập vào.

• Tìm số lượng các người quản lý là nam giới (male).• Tìm tuổi trung bình của tất cả người quản lý.

Câu trả lời với mỗi câu hỏi như sau:

1.

• Với truy vấn đầu tiên, chúng ta nên tạo ra một chỉ mục băm không phân cụm‘rậm rạp’ trên mgr_dept cho quan hệ Manager. Chúng ta bỏ qua sex ra khỏikhóa trong chỉ mục này vì nó rất ít khi được chọn, tuy nhiên, việc có nó khôngphải trả chi phí đắt vì trường này dường như không được cập nhật thườngxuyên.

• Chúng ta nên tạo ra một chỉ mục B+tree không phân cụm trên<age_mgr_dept,mid>cho quan hệ Manager, và chỉ mục băm không phân cụmtrên <proj_base_dept, proj_mgr> cho quan hệ Project. Chúng ta có thể thựchiện việc quét chỉ-chỉ-số để tìm ra tất cả các nhà quản lý có tuổi nằm trongmiền được xác định, và sau đó băm vào trong quan hệ Project để có được têncác dự án. Nếu việc quét chỉ-chỉ-số không được hỗ trợ, chỉ mục trên Managernên là một chỉ mục phân cụm trên age.

• Với truy vấn thứ ba chúng ta không cần một chỉ mục mới. Chúng ta có thể quéttất cả managers và sử dụng chỉ mục băm trên <proj_base_dept, proj_mgr>trênquan hệ Project để kiểm tra mgr_dept = proj_base_dept.

• Chúng ta có thể tạo ra một chỉ mục không phân cụm B+tree trên budget trongquan hệ Project và sau đó đi xuống cây này để tìm ra budget thấp nhất cho truyvấn thứ tư.

459/470

• Với truy vấn thứ năm, chúng ta nên tạo ra một chỉ mục băm không phân cụm‘rậm rạp’ trên pno của quan hệ Project. Chúng ta có thể có proj_base_dept củaproject bằng cách sử dụng chỉ mục này, và sau đó sử dụng chỉ mục băm trênmgr_dept để có được những người quản lý của phòng này. Ghi nhớ rằng mộtchỉ mục nào đó trên <pno, proj_base_dept> của Project sẽ cho phép chúng tathực hiện việc quét chỉ-chỉ-số trên Project. Tuy nhiên, vì ở đây có chính xácmột phòng với mỗi dự án (pno là khóa) nên nó dường như không nhanh hơnđáng kể. (Nó chỉ tiết kiệm được 1 I/O trên mỗi dự án.)

2.

• Với truy vấn đầu tiên, chúng ta nên tạo ra một chỉ mục B+tree không phân cụmtrên <proj_mgr, budget> cho quan hệ Project. Việc quét chỉ-chỉ-số sau đó đượcsử dụng để thực hiện truy vấn này. Nếu việc quét chỉ-chỉ-số không được hỗ trợ,chỉ mục phân cụm trên proj_mgr sẽ là tốt nhất.

• Nếu chúng ta tạo ra một chỉ mục B+tree phân cụm ‘thưa thớt’ trên <age, mid>cho quan hệ Manager, chúng ta có thể thực hiện việc quét chỉ-chỉ-số trên chỉmục này để tìm ra được các ids của người quản lý trong miền đã cho. Sau đó,chúng ta có thể sử dụng việc quét chỉ-chỉ-số của chỉ mục B+tree trên<proj_mgr, budget> để tính ra tổng ngân sách của các dự án do từng ngườiquản lý phụ trách. Nếu việc quét chỉ-chỉ-số không được hỗ trợ, chỉ mục nàytrên Manager sẽ là chỉ mục B+tree phân cụm trên age.

• Một chỉ mục băm không phân cụm trên sex sẽ chỉ ra những người quản lý theosex và cho phép chúng ta tính số lượng những người có giới tính là male sửdụng một thao tác quét chỉ-chỉ-số. Nếu các thao tác quét chỉ-chỉ-số không đượchỗ trợ, thì không có chỉ mục nào giúp được chúng ta để thực hiện truy vấn thứba.

• Chúng ta nên tạo ra một chỉ mục băm không phân cụm trên age cho truy vấnthứ tư. Tất cả chúng ta cần để làm là tính trung bình của tuổi (age) sử dụng việcquét chỉ-chỉ-số. Nếu các kế hoạch chỉ-chỉ-số không được phép thì không có chỉmục nào hỗ trợ được chúng ta.

Câu lạc bộ Globetrotters được tổ chức thành các Hội (Chapter). Người đứng đầu(President) của một hội nào đó không bao giờ đứng đầu một hội khác, và mỗi hội cungcấp cho người đứng đầu hội đó một khoản lương. Các hội có thể chuyển đến địa điểmmới, và người đứng đầu được bầu lại khi (và chỉ khi) hội được chuyển đi. Dữ liệu nàyđược lưu trong quan hệ G(C,S,L,P), trong đó C là Chapter (Hội), S là Salary (Lương),L là Location (Địa điểm), và P là President (Người đứng đầu). Dạng truy vấn sau đượcyêu cầu thường xuyên, và bạn phải trả lời nó mà không cần thực hiện kết nối: "Ai làngười đứng đầu của hội X khi nó ở địa điểm Y?"

1. Liệt kê danh sách các FDs có trên G.

460/470

2. Quan hệ G có những khóa dự tuyển nào?

3. Quan hệ G đang ở dạng chuẩn nào?

4. Thiết kế một lược đồ cơ sở dữ liệu tốt cho câu lạc bộ này. (Nhớ rằng thiết kế của bạnphải thực hiện được truy vấn trên!)

5. Thiết kế của bạn ở dạng chuẩn nào? Cung cấp một ví dụ truy vấn chạy chậm trên lượcđồ này hơn là trên quan hệ G.

6. Có phân rã nào của G thành các quan hệ ở BCNF mà không mất kết nối và bảo toànphụ thuộc hàm không?

7. Có lý do nào tốt để chấp nhận một quan hệ ở dạng chuẩn thấp hơn 3NF không? Sửdụng ví dụ này, thêm các ràng buộc nếu cần thiết để minh họa câu trả lời của bạn.

Dành cho độc giả

Xem xét quan hệ ở dạng BCNF sau, quan hệ này bao gồm mã sản phẩm, kiểu sản phẩm(ví dụ, quả hay là bó), giá, và số lượng có trong kho.

Parts (pid, pname, cost, num_avail)

Bạn được biết là hai truy vấn sau cực kỳ quan trọng:

• Tìm tổng số lượng có trong kho của từng kiểu sản phẩm, ứng với tất cả cáckiểu.

• Liệt kê pids của các sản phẩm có giá cao nhất.1. Trình bày thiết kế vật lý bạn lựa chọn cho quan hệ này. Tức là, loại cấu trúc file

dùng để lưu tập các bản ghi của Parts, và bạn sẽ tạo ra những chỉ mục nào?2. Giả sử sau này khách hàng của bạn vẫn phàn nàn về khả năng thực thi của hệ

thống. Vì bạn không có khả năng mua thêm phần cứng và phần mềm mới, nênbạn phải cân nhắc để thiết kế lại lược đồ. Bạn sẽ thiết kế lại lược đồ quan hệ, tổchức file và các chỉ mục trên các quan hệ này như thế nào.

3. Câu trả lời đối với hai câu hỏi trên thay đổi như thế nào nếu hệ thống của bạnkhông hỗ trợ các chỉ mục có khóa tìm kiếm đa-thuộc-tính?

Câu trả lời với mỗi câu hỏi như sau:

1. Cấu trúc heap file có thể được sử dụng cho quan hệ Parts. Một chỉ mục B+tree khôngphân cụm ‘thưa thớt’ trên <pname, num_avail> và một chỉ mục không phân cụm ‘thưathớt’ trên <cost, pid> có thể được tạo ra để thực hiện hiệu quả truy vấn này.

461/470

2. Vấn đề này có thể là do bộ tối ưu hóa có lẽ không xem xét các kế hoạch chỉ-chỉ-số,những kế hoạch này có thể được thực hiện sử dụng lược đồ được biểu diễn ở trên. Vì thếchúng ta có thể thay bằng việc tạo ra các chỉ mục phân cụm trên <pid, cost> và <pname,num_avail>. Để làm điều này chúng ta phải phân vùng dọc quan hệ này thành hai quanhệ là Parts1(pid, cost) và Parts2( pid, pname, num_avail). Nếu các chỉ mục này bảnthân nó không được thực hiện, thì chúng ta có thể thay bằng sử dụng các tổ chức fileđược sắp cho hai quan hệ được chia tách này).

3. Nếu các khóa đa-thuộc-tính không được phép thì chúng ta có các chỉ mục B+tree phâncụm trên cost và trên pname trên cả hai quan hệ.

Xem xét các quan hệ ở BCNF sau, hai quan hệ này chứa thông tin về các nhân viên(Emp) và các phòng (Dept) nơi họ làm việc.

Emp(eid, sal, did)

Dept(did, location, budget)

Bạn được nói rằng hai truy vấn sau thực sự quan trọng:

• Tìm địa điểm (location) nơi mà một nhân viên nào đó làm việc.• Kiểm tra xem ngân quỹ (budget) của một phòng nào đó có lớn hơn lương của

từng nhân viên trong phòng đó không.1. Trình bày thiết kế vật lý bạn lựa chọn cho quan hệ này. Tức là, loại cấu trúc file

bạn lựa chọn để lưu tập các bản ghi của những quan hệ này, và bạn sẽ tạo ranhững chỉ mục nào?

2. Giả sử sau này khách hàng của bạn vẫn phàn nàn về khả năng thực thi của hệthống. Vì bạn không có khả năng mua thêm phần cứng và phần mềm mới, bạnphải cân nhắc để thiết kế lại lược đồ. Bạn sẽ thiết kế lại lược đồ quan hệ, tổchức file và các chỉ mục trên các quan hệ này như thế nào.

3. Giả sử rằng hệ thống cơ sở dữ liệu của bạn không thực hiện hiệu quả những cấutrúc chỉ mục này. Bạn sẽ làm gì trong trường hợp này.

Dành cho độc giả

Xem xét các quan hệ ở BCNF sau, hai quan hệ này chứa thông tin về các nhân viên(Emp) và các phòng (Dept) nơi họ làm việc.

Dept ( did , dname, location, managerid)

Emp ( eid , sal)

Bạn được nói rằng hai truy vấn sau thực sự quan trọng:

462/470

• Liệt kê tên (dname) và mã người quản lý (managerid) của từng phòng trongmột địa điểm nào đó do người dùng nhập vào, kết quả được sắp xếp theo thứ tựcủa tên phòng.

• Tìm lương (sal) trung bình của các nhân viên làm quản lý phòng tại một địađiểm (location) nào đó do người dùng nhập vào. Bạn có thể giả sử rằng khôngcó nhiều hơn một người quản lý trong một phòng.

• Trình bày các cấu trúc file và các chỉ mục bạn sẽ lựa chọn.• Sau này bạn nhận ra rằng các quan hệ này thường xuyên được cập nhật. Vì các

chỉ mục có thể làm chậm tốc độ của các lệnh cập nhật, bạn có nghĩ rằng để cảithiện khả năng thực thi của hệ thống này bạn sẽ không sử dụng các chỉ mụckhông?

Câu trả lời với mỗi câu hỏi như sau:

1. Tổ chức heap file cho hai quan hệ này là hiệu quả nếu chúng ta tạo ra các chỉ mụcsau. Đầu tiên, chỉ mục B+tree phân cụm trên <location, dname> sẽ cải thiện được thựcthi (chúng ta không thể liệt kê tên của các nhà quản lý vì ở đây không có biểu diễn thuộctính name). Chúng ta cũng có thể có một chỉ mục băm trên eid của quan hệ Emp để tăngtốc độ truy vấn thứ hai: chúng ta tìm tất cả các manageridstừ chỉ mục B+tree này, sauđó sử dụng chỉ mục băm để tìm ra lương (sal) của họ.

2. Thiếu các chỉ mục, chúng ta có thể sử dụng phân rã ngang cho quan hệ Dept. Chúngta cũng có thể thử với các tổ chức file được sắp, cùng với quan hệ Dept được sắp trêndname và Emp trên eid.

Với mỗi truy vấn sau, chỉ ra một nguyên nhân khiến bộ tối ưu hóa có thể không tìmđược một kế hoạch tốt. Viết lại truy vấn này để nó có thể tìm được một kế hoạch thựchiện tốt. Các chỉ mục có thể và các ràng buộc được liệt kê trước mỗi truy vấn; giả sửrằng các lược đồ quan hệ phù hợp với các thuộc tính được đề cập đến trong các truy vấnnày.

1. Một chỉ mục có trên thuộc tính age:

SELECT E.dno

FROM Employee E

WHERE E.age=20 OR E.age=10

2. Một chỉ mục B+tree trên thuộc tính age:

SELECT E.dno

FROM Employee E

463/470

WHERE E.age<20 AND E.agOlO

3. Một chỉ mục có trên thuộc tính age:

SELECT E.dno

FROM Employee E

WHERE 2*E.age<20

4. Không có chỉ mục nào:

SELECT DISTINCT *

FROM Employee E

5. Không có chỉ mục nào:

SELECT AVG (E.sal)

FROM Employee E

GROUP BY E.dno

HAVING E.dno=22

6. Thuộc tính sid của Reserves là khóa ngoại tham chiếu tới Sailors:

SELECT S.sid

FROM Sailors S, Reserves R

WHERE S.sid=R.sid

Dành cho độc giả

Xem xét hai cách để đưa ra tên của những người nhân viên kiếm được hơn $100000 vàtuổi của họ bằng với tuổi của người quản lý họ. Đầu tiên, thực hiện một truy vấn lồngnhau:

SELECT E1. ename

FROM Emp E1

464/470

WHERE E1.sal > 100 AND E1.age = ( SELECT E2.age

FROM Emp E2, Dept D2

WHERE E1.dname = D2.dname AND D2.mgr = E2.ename )

Thứ hai, truy vấn chứa một định nghĩa khung nhìn:

SELECT E1.ename

FROM Emp E1, MgrAge A

WHERE E1.dname = A.dname AND E1.sal > 100 AND E1.age = A.age

CREATE VIEW MgrAge (dname, age)

AS SELECT D.dname, E.age

FROM Emp E, Dept D

WHERE D.mgr = E.ename

1. Trình bày một trường hợp mà truy vấn đầu tiên thực hiện tốt hơn truy vấn thứhai.

2. Trình bày một trường hợp mà truy vấn thứ hai thực hiện tốt hơn truy vấn đầutiên.

3. Bạn có thể xây dựng một truy vấn bằng vượt trội cả hai truy vấn này khi tất cảnhân viên kiếm được hơn $100000 có tuổi là 35 hoặc 40? Giải thích ngắn gọn.

1. Xem xét trường hợp khi ở đây có rất ít hoặc không có nhân viên nào có lương lớn hơn100000. Thì trong truy vấn thứ nhất phần lồng nhau sẽ không được tính, ngược lại trongtruy vấn thứ hai phép nối giữa Emp và MgrAge sẽ được tính không kể đến số lượng cácnhân viên có lương lớn hơn 100000.

Cũng như vậy, nếu ở đây có một chỉ mục trên dname, thì phần lồng nhau của truy vấnthứ nhất sẽ hiệu quả. Tuy nhiên, chỉ mục này không ảnh hưởng tới khung nhìn này trongtruy vấn thứ hai vì nó được sử dụng từ một khung nhìn nào đó.

2. Trong trường hợp khi ở đây có một số lượng lớn các nhân viên có sal>100000 vàquan hệ Dept lớn, trong truy vấn đầu tiên phép nối giữa Dept và Emp sẽ được tính chomỗi bộ giá trị trong Emp thỏa mãn điều kiện E1.sal > 100000, ngược lại phép nối đượctính chỉ một lần.

465/470

3. Trong trường hợp này, phép chọn liên quan đến age sẽ có chi phí rất cao. Vì thế nếuchúng ta có một chỉ mục trên <age, sal> thì truy vấn sau có thể thực hiện tốt hơn.

SELECT E1.ename

FROM Emp E1

WHERE E1.age=35 AND E1.sal > 100 AND E1.age =

( SELECT E2.age

FROM Emp E2, Dept D2

WHERE E1.dname = D2.dname AND D2.mgr = E2.ename)

UNION

SELECT E1.ename

FROM Emp E1

WHERE E1.age = 40 AND E1.sal > 100 AND E1.age =

( SELECT E2.age

FROM Emp E2, Dept D2

WHERE E1.dname = D2.dname AND D2.mgr = E2.ename)

Các câu hỏi ôn tập

Trả lời những câu hỏi sau và câu trả lời có thể tìm trong phần được liệt kê bên cạnh.

• Nêu các thành phần của luồng công việc? (Phần 1.1)• Những quyết định nào cần phải được đưa ra trong quá trình thiết kế vật lý?

(Phần 1.2)• Trình bày sáu hướng dẫn mức-cao cho việc lựa chọn chỉ mục. (Phần 2)• Khi nào chúng ta nên tạo ra các chỉ mục phân cụm? (Phần 4)• Đồng-phân-cụm là gì, và khi nào chúng ta nên sử dụng nó? (Phần 4.1)• Kế hoạch chỉ-chỉ-số là gì, và chúng ta tạo ra các chỉ mục cho các kế hoạch chỉ-

chỉ-số như thế nào? (Phần 5)• Vì sao điều chỉnh chỉ mục tự động là một vấn đề khó? Cho ví dụ. (Phần 6.1)• Cung cấp một ví dụ cho thuật toán điều chỉnh chỉ mục tự động. (Phần 6.2)• Vì sao điều chỉnh cơ sở dữ liệu quan trọng? (Phần 7)

466/470

• Chúng ta điều chỉnh chỉ mục, lược đồ khái niệm, các truy vấn và các khungnhìn như thế nào? (Từ phần 7.1 tới 7.3)

• Những lựa chọn của chúng ta trong việc điều chỉnh lược đồ khái niệm là gì?Các công nghệ theo sau nó là gì và khi nào chúng ta áp dụng chúng: chọn cácdạng chuẩn yếu hơn, phi chuẩn hóa, phân rã theo chiều dọc và chiều ngang.(Phần 8)

• Những lựa chọn nào chúng ta làm trong điều chỉnh chỉ mục và khung nhìn?(Phần 9)

• Ảnh hưởng của khóa đối với thực thi cơ sở dữ liệu? Chúng ta có thể giảm sựtương tranh của khóa và các hot spots như thế nào? (Phần 10)

• Vì sao chúng ta có các tiêu chuẩn? Bạn có thể trình bày một vài tiêu chuẩn phổdụng? (Phần 12)

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ẩnhó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ủamộ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ôngcụ 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áchtó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ỉnhcơ 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ó baogồ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àytrong [739]. Tiêu chuẩn Sequoia 2000 được trình bày trong [720].

467/470

Tham gia đóng góp

Tài liệu: Hệ quản trị Cơ sở dữ liệu

Biên tập bởi: Ths. Phạm Hoàng Nhung

URL: http://voer.edu.vn/c/9d6bddd9

Giấy phép: http://creativecommons.org/licenses/by/3.0/

Module: Lời nói đầu

Các tác giả: Ths. Phạm Hoàng Nhung

URL: http://www.voer.edu.vn/m/6bc24ce9

Giấy phép: http://creativecommons.org/licenses/by/3.0/

Module: Tổng quan về các hệ thống cơ sở dữ liệu

Các tác giả: Ths. Phạm Hoàng Nhung

URL: http://www.voer.edu.vn/m/583a66bf

Giấy phép: http://creativecommons.org/licenses/by/3.0/

Module: Giới thiệu thiết kế cơ sở dữ liệu

Các tác giả: Ths. Phạm Hoàng Nhung

URL: http://www.voer.edu.vn/m/79f110dd

Giấy phép: http://creativecommons.org/licenses/by/3.0/

Module: Mô hình quan hệ

Các tác giả: Ths. Phạm Hoàng Nhung

URL: http://www.voer.edu.vn/m/7296f3ea

Giấy phép: http://creativecommons.org/licenses/by/3.0/

Module: Đại số quan hệ và các phép toán logic

Các tác giả: Ths. Phạm Hoàng Nhung

URL: http://www.voer.edu.vn/m/bafe5831

Giấy phép: http://creativecommons.org/licenses/by/3.0/

Module: Truy vấn, Ràng buộc, Trigger

Các tác giả: Ths. Phạm Hoàng Nhung

URL: http://www.voer.edu.vn/m/ab50f5e8

468/470

Giấy phép: http://creativecommons.org/licenses/by/3.0/

Module: Phát triển ứng dụng cơ sở dữ liệu

Các tác giả: Ths. Phạm Hoàng Nhung

URL: http://www.voer.edu.vn/m/2438ee7d

Giấy phép: http://creativecommons.org/licenses/by/3.0/

Module: Các ứng dụng Internet

Các tác giả: Ths. Phạm Hoàng Nhung

URL: http://www.voer.edu.vn/m/7eee4ec0

Giấy phép: http://creativecommons.org/licenses/by/3.0/

Module: Tổng quan về lưu trữ và chỉ số

Các tác giả: Ths. Phạm Hoàng Nhung

URL: http://www.voer.edu.vn/m/7d5f38ac

Giấy phép: http://creativecommons.org/licenses/by/3.0/

Module: Tổng quan về đánh giá truy vấn

Các tác giả: Ths. Phạm Hoàng Nhung

URL: http://www.voer.edu.vn/m/1cde9f70

Giấy phép: http://creativecommons.org/licenses/by/3.0/

Module: Tổng quan về quản lý giao dịch

Các tác giả: Ths. Phạm Hoàng Nhung

URL: http://www.voer.edu.vn/m/f8eee705

Giấy phép: http://creativecommons.org/licenses/by/3.0/

Module: Tinh chỉnh lược đồ và các dạng chuẩn hoá

Các tác giả: Ths. Phạm Hoàng Nhung

URL: http://www.voer.edu.vn/m/0f19e466

Giấy phép: http://creativecommons.org/licenses/by/3.0/

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

Các tác giả: Ths. Phạm Hoàng Nhung

URL: http://www.voer.edu.vn/m/81d787cf

Giấy phép: http://creativecommons.org/licenses/by/3.0/

469/470

Chương trình Thư viện Học liệu Mở Việt Nam

Chương trình Thư viện Học liệu Mở Việt Nam (Vietnam Open Educational Resources– VOER) được hỗ trợ bởi Quỹ Việt Nam. Mục tiêu của chương trình là xây dựng khoTài nguyên giáo dục Mở miễn phí của người Việt và cho người Việt, có nội dung phongphú. Các nội dung đểu tuân thủ Giấy phép Creative Commons Attribution (CC-by) 4.0do đó các nội dung đều có thể được sử dụng, tái sử dụng và truy nhập miễn phí trướchết trong trong môi trường giảng dạy, học tập và nghiên cứu sau đó cho toàn xã hội.

Với sự hỗ trợ của Quỹ Việt Nam, Thư viện Học liệu Mở Việt Nam (VOER) đã trở thànhmột cổng thông tin chính cho các sinh viên và giảng viên trong và ngoài Việt Nam. Mỗingày có hàng chục nghìn lượt truy cập VOER (www.voer.edu.vn) để nghiên cứu, họctập và tải tài liệu giảng dạy về. Với hàng chục nghìn module kiến thức từ hàng nghìntác giả khác nhau đóng góp, Thư Viện Học liệu Mở Việt Nam là một kho tàng tài liệukhổng lồ, nội dung phong phú phục vụ cho tất cả các nhu cầu học tập, nghiên cứu củađộc giả.

Nguồn tài liệu mở phong phú có trên VOER có được là do sự chia sẻ tự nguyện của cáctác giả trong và ngoài nước. Quá trình chia sẻ tài liệu trên VOER trở lên dễ dàng nhưđếm 1, 2, 3 nhờ vào sức mạnh của nền tảng Hanoi Spring.

Hanoi Spring là một nền tảng công nghệ tiên tiến được thiết kế cho phép công chúng dễdàng chia sẻ tài liệu giảng dạy, học tập cũng như chủ động phát triển chương trình giảngdạy dựa trên khái niệm về học liệu mở (OCW) và tài nguyên giáo dục mở (OER) . Kháiniệm chia sẻ tri thức có tính cách mạng đã được khởi xướng và phát triển tiên phongbởi Đại học MIT và Đại học Rice Hoa Kỳ trong vòng một thập kỷ qua. Kể từ đó, phongtrào Tài nguyên Giáo dục Mở đã phát triển nhanh chóng, được UNESCO hỗ trợ và đượcchấp nhận như một chương trình chính thức ở nhiều nước trên thế giới.

470/470