CƠ SỞ DỮ LIỆU

TRƯỜNG ĐẠ
ẠI HỌC NGÂN HÀNG TP. HỒ CHÍ MINH
KHOA CÔNG NGH

NGHỆ THÔNG TIN
GIÁO TRÌNH
NHÓM BIÊN SOẠN:

SO
Trịnh
nh Hoàng Nam (Ch
(Chủ biên)
Nguyễn
Nguy Thị Trà Linh
Tạ Thị Hoàng Mai

MỤC LỤC
LỜI MỞ ĐẦU ......................................................................................................... 1
CHƯƠNG 1: TỔNG QUAN VỀ HỆ THỐNG CƠ SỞ DỮ LIỆU ..................... 3
1.1 Hệ thống hướng tập tin.................................................................................... 5
1.2 Hệ thống hướng cơ sở dữ liệu ......................................................................... 6
1.3 Mục tiêu của các hệ cơ sở dữ liệu ................................................................... 7
1.4 Hệ quản trị cơ sở dữ liệu ................................................................................. 8
1.5 Người dùng cơ sở dữ liệu .............................................................................. 13
1.6 Ngôn ngữ và giao diện ngôn ngữ dữ liệu ...................................................... 15
CHƯƠNG 2: MÔ HÌNH THỰC THỂ KẾT HỢP ............................................ 22
2.1. Mô hình thực thể kết hợp ............................................................................... 24
2.2. Một ứng dụng của mô hình thực thể kết hợp................................................. 25
2.3. Các khái niệm trong mô hình thực thể kết hợp ............................................. 27
2.4. Các vấn đề khi thiết kế mô hình thực thể kết hợp ..........................................40
CHƯƠNG 3: MÔ HÌNH THỰC THỂ KẾT HỢP MỞ RỘNG ...................... 49
3.1 Những hạn chế của mô hình thực thể kết hợp............................................... 51
3.2 Các khái niệm trong mô hình thực thể kết hợp mở rộng .............................. 52
3.3 Một ứng dụng của mô hình thực thể kết hợp mở rộng ................................. 63
3.4 Các công cụ mô hình thiết kế cơ sở dữ liệu .................................................. 64
CHƯƠNG 4: MÔ HÌNH DỮ LIỆU QUAN HỆ ................................................ 71
4.1 Các khái niệm cơ bản .................................................................................... 73
4.2 Ràng buộc toàn vẹn trên mô hình quan hệ và lược đồ dữ liệu quan hệ ........ 80
4.3 Các toán tử cập nhật trên quan hệ ................................................................. 85
CHƯƠNG 5: ĐẠI SỐ QUAN HỆ VÀ PHÉP TÍNH QUAN HỆ ..................... 94
5.1 Phép toán một ngội........................................................................................ 96
5.2 Các phép toán hai ngôi .................................................................................. 99
5.3 Các phép toán khác .................................................................................... 108
5.4 Phép tính quan hệ trên bộ ............................................................................ 112
5.5 Phép tính quan hệ trên miền ........................................................................ 120
CHƯƠNG 6: THIẾT KẾ CƠ SỞ DỮ LIỆU QUAN HỆ ................................ 128
6.1 Các giai đoạn thiết kế cơ sở dữ liệu quan hệ .............................................. 130
6.2 Thiết kế cơ sở dữ liệu ý niệm ...................................................................... 133
6.3 Thiết kế cơ sở dữ liệu luận lý ...................................................................... 139
CHƯƠNG 7: NGÔN NGỮ TRUY VẤN CÓ CẤU TRÚC ............................. 162
7.1 Định nghĩa dữ liệu và các kiểu dữ liệu ........................................................ 164
7.2 Các ràng buộc cơ bản trong SQL ................................................................ 168
7.3 Các câu lệnh thay đổi lược đồ cơ sở dữ liệu................................................ 174
7.4 Các truy vấn cơ bản trong SQL ................................................................... 176
7.5 Các câu truy vấn phức tạp ........................................................................... 185
7.6 Các lệnh cập nhật dữ liệu trong SQL........................................................... 196
CHƯƠNG 8: LÝ THUYẾT THIẾT KẾ CƠ SỞ DỮ LIỆU QUAN HỆ ....... 206
8.1 Phụ thuộc hàm ............................................................................................. 208
8.2 Hệ tiên đề các phụ thuộc hàm và phép suy dẫn logic .................................. 211
8.3 Một số vấn đề khi thiết kế lược đồ cơ sở dữ liệu quan hệ ........................... 223
8.4 Phân tách quan hệ ........................................................................................ 224
8.5 Các dạng chuẩn của mô hình dữ liệu quan hệ ............................................ 231
8.6 Các phương pháp chuẩn hóa cơ sở dữ liệu quan hệ ................................... 237
CHƯƠNG 9: TỐI ƯU HÓA TRUY VẤN ....................................................... 250
9.1 Tổng quan về tối ưu hóa truy vấn ................................................................ 252
9.2 Phương pháp ước lượng cây đại số quan hệ ................................................ 253
9.3 Nguyên tắc tối ưu hóa .................................................................................. 254
9.4 Kỹ thuật tối ưu hóa các biểu thức đại số quan hệ ........................................ 256
9.5 Tối ưu hóa bằng khung nhìn ........................................................................ 265
LỜI MỞ ĐẦU
Trong thời đại bùng nổ thông tin, vai trò của hệ thống thông tin ngày càng trở nên quan
trọng đối với mọi lĩnh vực hoạt động của doanh nghiệp, đặc biệt trong việc nâng cao khả
năng cạnh tranh thông qua các hoạt động phát triển sản phẩm, giảm giá thành, mở rộng
thị trường, … Phần lớn các hệ thống thông tin trong doanh nghiệp đều đòi hỏi phải duy
trì toàn bộ dữ liệu ở quá khứ, không ngừng bổ sung thêm các dữ liệu mới được ghi nhận
ở hiện tại, và dự đoán các kết quả sẽ xuất hiện trong tương lai. Các dữ liệu này không chỉ
được sử dụng để thống kê, phân tích, đánh giá tổ chức ở thời điểm hiện tại, mà còn có
khả năng hỗ trợ đưa ra những quyết định ở nhiều cấp quan trọng khác nhau. Chính vì lẽ
đó, cơ sở dữ liệu trở thành một bộ phận gắn liền với hệ thống thông tin của doanh nghiệp,
và được coi là một phần không thể tách rời khỏi doanh nghiệp.
Thuật ngữ Cơ sở dữ liệu giờ đây được áp dụng rộng rãi trong nhiều lĩnh vực ngoài Công
nghệ thông tin, như là Tài chính – Ngân hàng, Kế toán – Kiểm toán, Thẩm định dự án, …
Bản thân môn học Cơ sở dữ liệu cũng xuất hiện ở các chương trình đào tạo khác nhau với
nhiều trình độ khác nhau từ trung cấp, cao đẳng, đến đại học, và cả sau đại học.
Trên thị trường hiện nay có khá nhiều tài liệu tham khảo về Cơ sở dữ liệu, nhưng hầu hết
đều nhắm đến đối tượng người đọc là những sinh viên khối ngành Công nghệ thông tin
hoặc có những kiến thức nhất định về công nghệ thông tin. Xuất phát từ thực tế đó, chúng
tôi bắt tay biên soạn giáo trình Cơ sở dữ liệu với cách tiếp cận đơn giản dễ hiểu, phù hợp
với mọi đối tượng người đọc, kể cả những người chưa từng tham gia bất kỳ lớp học nào
về công nghệ thông tin.
1
Giáo trình tập trung trình bày những kiến thức cần thiết về cơ sở dữ liệu, từ những khái
niệm cơ bản khi mới bắt đầu làm quen, cho đến những vấn đề quan trọng, có tính quyết
định tới sự thành bại khi xây dựng một cơ sở dữ liệu thực tế. Với các kiến thức lý thuyết
được trình bày một cách cô đọng, ngắn gọn và dễ hiểu; các ví dụ minh họa đa dạng,
phong phú, chúng tôi hy vọng giáo trình này đáp ứng được nhu cầu nghiên cứu và học
tập của nhiều đối tượng người học khác nhau.
Mặc dù có rất nhiều cố gắng trong công tác biên soạn, nhưng giáo trình chắc chắn sẽ có ít
nhiều khiếm khuyết. Chúng tôi rất mong nhận được các ý kiến đóng góp để có thể hoàn
thiện giáo trình trong lần tái bản tiếp theo.
TP. Hồ Chí Minh, tháng 07 năm 2011

NHÓM BIÊN SOẠN
2
C
CHHƯ
ƯƠƠN
NGG
1
TỔNG QUAN VỀ
HỆ THỐNG CƠ SỞ DỮ LIỆU
Mục tiêu
Chương này cung cấp cho người đọc các khái niệm cơ bản về cơ sở dữ liệu
giúp có cái nhìn ban đầu về cơ sở dữ liệu, hệ quản trị cơ sở dữ liệu và mối
tương quan giữa chúng với nhau.
Nội dung
Hệ thống hướng tệp tin
Hệ thống hướng cơ sở dữ liệu
Hệ quản trị cơ sở dữ liệu
Người dùng cơ sở dữ liệu
Ngôn ngữ và giao diện ngôn ngữ dữ liệu
Email: namth@buh.edu.vn 3
Giới thiệu
Khái niệm cơ sở dữ liệu ra đời từ rất sớm, và kể từ đó, cơ sở dữ liệu trở thành một
bộ phận không thể tách rời đối với các hệ thống thông tin trên máy tính. Cơ sở dữ
liệu ra đời trong bối cảnh hàng loạt vấn đề phát sinh trong các hệ thống sử dụng
tệp tin làm phương tiện để lưu trữ dữ liệu.
Chúng ta bắt đầu tìm hiểu cơ sở dữ liệu bằng việc giới thiệu một loại công cụ hỗ
trợ giao tiếp với cơ sở dữ liệu, đó là hệ quản trị cơ sở dữ liệu. Tiếp theo chúng ta
phân loại các đối tượng người dùng cơ sở dữ liệu dựa trên quyền hạn và trách
nhiệm của họ đối với cơ sở dữ liệu. Cuối cùng, chúng ta làm quen với ba nhóm
ngôn ngữ mà qua đó chúng ta tương tác với hệ quản trị cơ sở dữ liệu: ngôn ngữ
định nghĩa dữ liệu, ngôn ngữ thao tác dữ liệu, và ngôn ngữ điều khiển dữ liệu.
1.1 HỆ THỐNG HƯỚNG TỆP TIN
Một tệp tin có thể xem là một cặp hồ sơ lưu trữ các thông tin liên quan đến từng
công việc riêng biệt. Việc xử lý để lấy ra thông tin theo yêu cầu được thực hiện
một cách thủ công. Tuy nhiên, theo thời gian, khối lượng thông tin ngày càng lớn,
việc xử lý để lấy các thông tin theo yêu cầu ngày càng trở nên phức tạp. Do đó,
máy tính được đưa vào sử dụng. Các cặp hồ sơ được chuyển thành tệp trên máy
tính và việc xử lý thông tin được thể hiện bằng cách lập trình.
Hình 1.1. Mô hình hoạt động hệ thống hướng tệp tin.
Việc áp dụng hệ thống hướng tệp tin có một số ưu điểm như sau:
Việc xây dựng các ứng dụng cũng như các tệp tin dữ liệu đáp ứng cho từng
công việc riêng biệt cho nên về cơ bản ít tốn thời gian, không đòi hỏi đầu tư
nhiều về thời gian, vật chất, đồng thời lại có thể nhanh chóng đưa vào sử
dụng.
Thông tin được khai thác chỉ phục vụ cho một số ít người sử dụng với một
số mục đích cụ thể, cho nên tính an toàn cao, khả năng đáp ứng nhanh
chóng, kịp thời.
Tuy nhiên, các hệ thống kiểu này cũng có nhiều nhược điểm, cụ thể như sau:
Dư thừa thông tin, cùng một thông tin được lưu trữ nhiều điểm khác nhau.
Điều này gây ra việc lãng phí bộ nhớ, dễ dàng gây sai sót trong khi cập nhật
dữ liệu, dữ liệu trở nên thiếu đồng bộ, không nhất quán, thậm chí còn xung
đột lẫn nhau.
Sự phụ thuộc chặt chẽ giữa chương trình ứng dụng. Mỗi khi có sự thay đổi
về cấu trúc tệp và các dữ liệu trong tệp, chương trình ứng dụng khai thác
thông tin trên tệp đó cũng phải thay đổi theo. Điều này gây ra khó khăn lớn
cho việc bảo trì hệ thống.
Để khắc phục những nhược điểm nói trên, hệ thống hướng cơ sở dữ liệu ra đời và
không ngừng phát triển cho đến ngày nay.
1.2 HỆ THỐNG HƯỚNG CƠ SỞ DỮ LIỆU

Dữ liệu là những sự kiện có thể ghi lại được, và thường không có ý nghĩa. Trong
khi đó, thông tin là ý nghĩa của dữ liệu sau khi đã được người sử dụng xử lý trong
một ngữ cảnh cụ thể nào đó.
Cơ sở dữ liệu là hệ thống các dữ liệu có cấu trúc được lưu trữ trên các thiết bị lưu
trữ thứ cấp để thỏa mãn nhu cầu khai thác thông tin của nhiều người sử dụng hoặc
nhiều chương trình ứng dụng với nhiều mục đích khác nhau. Trong khái niệm này,
chúng ta cần nhấn mạnh cơ sở dữ liệu phải là một tập hợp các dữ liệu có liên quan
về mặt luận lý, chứ không phải là những dữ liệu rời rạc, không có mối quan hệ với
nhau. Các dữ liệu này phải có cấu trúc, và chúng phải có khả năng đáp ứng các
nhu cầu khai thác thông tin của nhiều người sử dụng.
Sự ra đời của các hệ thống hướng cơ sở dữ liệu đã giải quyết triệt để những vấn đề
mà hệ thống hướng tệp tin gặp phải trước đó, cụ thể như sau:
Giảm sự trùng lặp dữ liệu xuống mức thấp nhất, và do đó đảm bảo được
tính nhất quán và toàn vẹn dữ liệu.
Đảm bảo dữ liệu có thể được truy xuất theo nhiều cách khác nhau.
Khả năng chia sẻ thông tin cho nhiều người sử dụng và nhiều ứng dụng
khác nhau dùng dữ liệu đó.
1.3 MỤC TIÊU CỦA HỆ THỐNG HƯỚNG CƠ SỞ
DỮ LIỆU
Hệ thống hướng cơ sở dữ liệu với những ưu điểm tuyệt đối của nó so với hệ thống
hướng tệp tin ra đời trước đó đã nhanh chóng được giới chuyên môn chấp nhận và
đưa vào triển khai. Khi xây dựng một hệ thống hướng cơ sở dữ liệu thương mại
hay phi thương mại, chúng ta đều hướng tới thực hiện các mục tiêu chính yếu sau
đây:
a) Đảm bảo ý nghĩa của dữ liệu. Dữ liệu có tính chia sẻ, nhiều người có
quyền sử dụng, thậm chí là thay đổi giá trị của dữ liệu, từ đó làm thay đổi ý
nghĩa của dữ liệu. Do đó, dữ liệu cần thường xuyên được theo dõi, kiểm tra,
rà soát, và cập nhật để phản ánh đúng giá trị mà nó đại diện.
b) Đảm bảo tính riêng tư và quyền khai thác dữ liệu của người sử dụng.
Mặc dù dữ liệu có tính chia sẻ, nhưng không phải tất cả dữ liệu đều được
chia sẻ, hoặc là không phải bất kỳ người sử dụng nào cũng có quyền khai
thác như nhau đối với một dữ liệu cụ thể. Người sử dụng không chỉ có thể
thiết lập các thông số liên quan đến việc chia sẻ dữ liệu dùng chung, mà còn
có thể cấp quyền và thu hồi quyền khai thác dữ liệu đối với những người
dùng khác trong hệ thống.
c) Đảm bảo giải quyết xung đột dữ liệu. Xuất phát từ việc dữ liệu được chia
sẻ, sự xung đột về quyền khai thác dữ liệu sẽ xuất hiện giữa những người
dùng khác nhau trong hệ thống. Cùng một dữ liệu đó, cùng lúc có nhiều yêu
cầu thực hiện thêm, sửa, hay xóa. Hệ thống nhìn chung không thể xử lý
đồng thời tất cả các yêu cầu đó cùng lúc. Do đó, chúng ta cần phải duy trì
cơ chế ưu tiên truy xuất dữ liệu cũng như cơ chế giải quyết tình trạng khóa
chết trong quá trình khai thác cạnh tranh.
d) Đảm bảo toàn vẹn dữ liệu khi có sự cố. Cơ sở dữ liệu thường được xem là
một bộ sưu tập dữ liệu trong một khoảng thời gian dài thường là vài năm,
vài chục năm, thậm chí cả trăm năm. Do đó, để đảm bảo dữ liệu được lưu
trữ liên tục, chúng ta cần phải xây dựng cơ chế sao lưu, phục hồi nhằm đảm
bảo dữ liệu được nguyên vẹn và không bị gián đoạn trong trường hợp hệ
thống gặp sự cố.
1.4 HỆ QUẢN TRỊ CƠ SỞ DỮ LIỆU

1.4.1 Định nghĩa
Hệ quản trị cơ sở dữ liệu nhìn chung là một hệ thống phần mềm hướng đến việc
thực hiện các nhiệm vụ sau đây:
Định nghĩa cơ sở dữ liệu bao gồm việc đặc tả các kiểu dữ liệu, các cấu
trúc, và các ràng buộc cho dữ liệu sẽ được lưu trữ trong cơ sở dữ liệu.
Xây dựng cơ sở dữ liệu bao gồm việc lưu trữ các dữ liệu trên các phương
tiện lưu trữ được hệ quản trị cơ sở dữ liệu kiểm soát.
Thao tác cơ sở dữ liệu bao gồm việc thực hiện các chức năng truy vấn cơ
sở dữ liệu để lấy ra những thông tin cần thiết, cập nhật cơ sở dữ liệu để
phản ánh sự các thay đổi trong thế giới thực và tạo ra các báo cáo từ dữ liệu
trong cơ sở dữ liệu.
Nói cách khác, hệ quản trị cơ sở dữ liệu là công cụ giúp người sử dụng hay các
chương trình ứng dụng tương tác với cơ sở dữ liệu. Cả ba yếu tố này hình thành
nên một hệ thống hướng cơ sở dữ liệu (xem hình 1.2).
Hình 1.2. Mô hình hoạt động của hệ thống hướng cơ sở dữ liệu.
1.4.2 Phân loại
Thực tế, có rất nhiều tiêu chí có thể được sử dụng để phân loại các hệ quản trị cơ
sở dữ liệu. Ở đây, chúng tôi chỉ giới thiệu ba tiêu chí quan trọng nhất, đó là mô
hình dữ liệu, tính đa người dùng, và tính phân tán của hệ quản trị cơ sở dữ liệu.
a) Dựa trên mô hình dữ liệu

Mô hình dữ liệu quan hệ (relational data model): là mô hình dữ liệu chủ
yếu được sử dụng trong hầu hết các hệ quản trị cơ sở dữ liệu thương mại
hiện nay.
Mô hình dữ liệu phân cấp ( hierarchical data model)và mô hình dữ liệu
mạng (network data model): phổ biến trong quá khứ, những ứng dụng
lâu đời vẫn còn sử dụng các mô hình này cho tới ngày nay.
Mô hình dữ liệu đối tượng (object oriented data model): được hiện thực
trong một số hệ thống thương mại nhưng chưa được sử dụng rộng rãi.
Mô hình dữ liệu đối tượng – quan hệ (object relational data model): ra
đời do quá trình phát triển các hệ quản trị cơ sở dữ liệu có liên quan nối
tiếp với nhau, là sự kết hợp của mô hình quan hệ và nhiều khái niệm
trong cơ sở dữ liệu đối tượng.
b) Dựa trên số người dùng mà hệ thống hỗ trợ
Hệ thống đơn người dùng (single-user database management system):
chỉ hỗ trợ mỗi người dùng tại một thời điểm. Loại này thường chỉ sử
dụng với các máy PC.
Hệ thống đa người dùng (multi-user database management system): hỗ
trợ nhiều người dùng đồng thời, loại này chiếm đa số các loại hệ quản
trị cơ sở dữ liệu.
c) Dựa trên vị trí đặt hệ thống
Hệ quản trị cơ sở dữ liệu tập trung (centralized data management
system): là hệ quản trị cơ sở dữ liệu có dữ liệu chỉ chứa tại một nơi duy
nhất. Loại này vẫn có thể hỗ trợ đa người dùng.
Hệ quản trị cơ sở dữ liệu phân tán (distributed data management
system): chứa dữ liệu và phần mềm hệ quản trị cơ sở dữ liệu tại nhiều
nơi khác nhau, kết nối với nhau thông qua đường truyền mạng.
1.4.3 Các chức năng của một hệ quản trị cơ sở dữ liệu

Một hệ quản trị cơ sở dữ liệu được đánh giá là tốt, nếu thực hiện được các chức
năng cơ bản sau đây:
Lưu trữ các định nghĩa, các mô tả về bản thân cơ sở dữ liệu (siêu dữ liệu)
trong một từ điển dữ liệu. Hệ quản trị cơ sở dữ liệu sử dụng từ điển dữ liệu
để tìm kiếm các cấu trúc dữ liệu và các mối liên kết theo yêu cầu của người
sử dụng. Mọi sự thay đổi trong cơ sở dữ liệu đều được ghi nhận vào từ điển
dữ liệu. Nói cách khác, sự độc lập giữa chương trình ứng dụng và dữ liệu
được đảm bảo tối đa.
Tạo ra các cấu trúc phức tạp theo yêu cầu để lưu trữ dữ liệu. Người sử dụng
được giải phóng khỏi việc định nghĩa và lập trình cho các đặc trưng vật lý
của dữ liệu. Công việc này do hệ quản trị cơ sở dữ liệu đảm nhiệm.
Chuyển đổi yêu cầu ý niệm về dữ liệu của người sử dụng thành các câu
lệnh xác định vị trí lưu trữ vật lý và lấy ra các dữ liệu theo yêu cầu.
Tạo ra một cơ chế phân quyền và gán quyền chặt chẽ, đảm bảo sự riêng tư
và an toàn bảo mật trong cơ sở dữ liệu.
Hỗ trợ cơ chế cho phép nhiều người sử dụng cùng truy cập đến cơ sở dữ
liệu.
Cung cấp các phương thức sao lưu, phục hồi dữ liệu nhằm đảm bảo sự an
toàn và toàn vẹn dữ liệu.
Cung cấp các phương tiện ngôn ngữ hỗ trợ người sử dụng thực hiện các tác
vụ liên quan tới cơ sở dữ liệu.
1.4.4 Cấu trúc tổng thể của hệ quản trị cơ sở dữ liệu
Một hệ quản trị cơ sở dữ liệu được phân thành nhiều phân hệ, mỗi phân hệ thực
hiện một chức năng trong hệ thống tổng thể. Hình 1.3 minh họa các thành phần cơ
bản của một hệ quản trị cơ sở dữ liệu.
Trong số các thành phần cấu thành nên hệ quản trị cơ sở dữ liệu, bản thân cơ sở dữ
liệu và từ điển dữ liệu thường được lưu trữ trên ổ đĩa cứng và do hệ điều hành
quản lý theo cơ chế input, output. Bộ quản lý dữ liệu lưu trữ cấp cao sử dụng các
thông tin về hệ quản trị cơ sở dữ liệu vốn được lưu trữ trên ở đĩa cứng. Đường kẻ
đứt nối và các điểm đánh dấu A, B, C, D, E cho biết tác động của bộ quản lý dữ
liệu lưu trữ cấp cao đối với hoạt động của hệ quản trị cơ sở dữ liệu. Nhiệm vụ
chính của bộ quản lý dữ liệu lưu trữ cấp cao là đảm bảo quá trình trao đổi dữ liệu
giữa ổ đĩa lưu trữ với dữ liệu của hệ thống thông qua việc quản lý hoạt động của
các bộ đệm trong bộ nhớ chính. Một khi dữ liệu nằm trong các bộ đệm của bộ nhớ
chính, không chỉ bản thân hệ quản trị cơ sở dữ liệu mà cả những trình ứng dụng
cũng có thể sử dụng dữ liệu này.
Trình biên dịch ngôn ngữ định nghĩa dữ liệu thực hiện các định nghĩa lược đồ
được khai báo trong các lệnh định nghĩa dữ liệu và lưu giữ thông tin về các lược
đồ này trong từ điển dữ liệu của hệ quản trị cơ sở dữ liệu. Từ điển dữ liệu về cơ
bản là nơi chứa đựng toàn bộ thông tin về cơ sở dữ liệu như là tên, kích thước các
tệp tin, tên và kiểu của các thực thể dữ liệu, thông tin về các lược đồ, các ràng
buộc trong cơ sở dữ liệu. Các thành phần của hệ quản trị cơ sở dữ liệu sẽ sử dụng
các thông tin trong từ điển dữ liệu mỗi khi có nhu cầu.
Bộ xử lý cơ sở dữ liệu chịu trách nhiệm xử lý các truy cập cơ sở dữ liệu mỗi khi
chúng xuất hiện. Nó tiếp nhận và thực thi các yêu cầu từ người sử dụng hoặc trình
ứng dụng thông qua các trình biên dịch tương ứng như là trình biên dịch ngôn ngữ
định nghĩa dữ liệu, trình biên dịch ngôn ngữ thao tác dữ liệu, trình biên dịch truy
vấn, ... Các thành phần này phối hợp hoạt động thành một thể thống nhất, đảm bảo
thực hiện đầy đủ các chức năng của một hệ quản trị cơ sở dữ liệu.
Hình 1.3. Cấu trúc tổng thể của hệ quản trị cơ sở dữ liệu
1.5 NGƯỜI DÙNG CƠ SỞ DỮ LIỆU

Như đã trình bày ở trên, hệ quản trị cơ sở dữ liệu là bộ công cụ hỗ trợ thực hiện
các hoạt động trên một (số) cơ sở dữ liệu nào đó. Tuy nhiên, không phải người sử
dụng nào cũng được quyền thao tác trực tiếp hoặc gián tiếp (thông qua trình ứng
dụng) trên hệ quản trị cơ sở dữ liệu. Ở đây, chúng ta sẽ phân biệt một số nhóm
người dùng cơ sở dữ liệu dựa trên sự phân loại quyền thực hiện các thao tác trên
hệ quản trị cơ sở dữ liệu.
1.5.1 Nhóm quản trị cơ sở dữ liệu
Quản trị viên cơ sở dữ liệu là nhóm người dùng được phân quyền mạnh nhất trong
hệ thống hướng cơ sở dữ liệu, nhóm người dùng này có quyền thực hiện mọi thao
tác trên cơ sở dữ liệu, hệ quản trị cơ sở dữ liệu và các phần mềm có liên quan
nhằm đảm bảo hoạt động hiệu quả, chính xác, nhanh chóng và liên tục của hệ
thống. Cụ thể, nhóm quản trị cơ sở dữ liệu có quyền thực hiện các hoạt động sau
đây:
Phân quyền truy cập cơ sở dữ liệu.
Giám sát quá trình vận hành cơ sở dữ liệu.
Sao lưu, khôi phục cơ sở dữ liệu.
Phân bổ tài nguyên phần cứng, phần mềm khi hệ thống có nhu cầu.
Chịu trách nhiệm trong trường hợp hệ thống có lỗ hổng bảo mật hoặc thời
gian đáp ứng chậm.
1.5.2 Nhóm thiết kế cơ sở dữ liệu

Nhóm thiết kế cơ sở dữ liệu là nhóm người chịu trách nhiệm về việc phân tích và
thiết kế cơ sở dữ liệu, đảm bảo cơ sở dữ liệu được thiết kế đúng đắn, chính xác,
hiệu quả, an toàn, đáp ứng tất cả các yêu cầu về dữ liệu trong hiện tại và tương lai.
Cụ thể, nhóm thiết kế cơ sở dữ liệu thực hiện các công việc sau đây:
Lựa chọn các cấu trúc phù hợp để biểu diễn và lưu trữ dữ liệu.
Làm việc với những người dùng cơ sở dữ liệu tiềm năng để nắm bắt được
yêu cầu của họ nhằm đảm bảo các bản thiết kế phù hợp với yêu cầu.
Liên hệ với từng nhóm người dùng để xây dựng các khung nhìn dữ liệu cho
phù hợp với cấu trúc cơ sở dữ liệu và yêu cầu của mỗi nhóm. Bản thiết kế
cuối cùng phải thỏa mãn yêu cầu của tất cả các nhóm.
Thông thường, nhóm thiết kế cơ sở dữ liệu được xếp chung với nhóm quản trị cơ
sở dữ liệu.
1.5.3 Nhóm người dùng cuối
Người dùng cuối là nhóm người có nhu cầu truy cập cơ sở dữ liệu để thực hiện các
thao tác khai thác hay quản lý nội dung của cơ sở dữ liệu. cơ sở dữ liệu tồn tại
chính là để đáp ứng nhu cầu dữ liệu của nhóm người dùng này. Cụ thể, nhóm
người dùng cuối có nhu cầu thực hiện các thao tác sau đây:
Truy xuất dữ liệu phục vụ nhu cầu tương tác hoặc thống kê với nhiều khung
nhìn khác nhau.
Cập nhật dữ liệu theo hình thức trực tuyến hoặc theo phiên.
Tùy từng sự phân quyền, gán quyền cụ thể, người dùng cuối có thể tương tác trực
tiếp với cơ sở dữ liệu thông qua hệ quản trị cơ sở dữ liệu, hoặc tương tác gián tiếp
với cơ sở dữ liệu thông qua các chương trình ứng dụng có khai báo sử dụng cơ sở
dữ liệu.
1.5.4 Nhà phân tích hệ thống và nhân viên lập trình ứng dụng
Nhà phân tích hệ thống có nhiệm vụ xác định yêu cầu của những người dùng cuối
để xây dựng đặc tả các giao tác đáp ứng nhu cầu của họ. Sau đó, nhân viên lập
trình ứng dụng sử dụng những đặc tả này để hiện thực chương trình, và họ tiến
hành thử nghiệm, xử lý lỗi, lập tài liệu cũng như bảo trì những giao tác được xây
dựng sẵn này. Cả hai loại người dùng này thường được gọi chung là kỹ sư phần
mềm. Họ cần phải thật quen thuộc với cấu trúc của hệ quản trị cơ sở dữ liệu để
hoàn thành công việc của mình.
1.5.5 Nhân viên bảo trì hệ thống

Nhóm người dùng cuối cùng, nhưng không kém phần quan trọng đối với hệ thống
hướng cơ sở dữ liệu đó là nhóm nhân viên bảo trì hệ thống. Những người này tuy
không trực tiếp làm việc với cơ sở dữ liệu nhưng công việc của họ nhằm giúp cho
hệ thống hoạt động liên tục 24/24. Nhiệm vụ chính của nhóm người dùng này bao:
thiết kế, phát triển và vận hành hệ quản trị cơ sở dữ liệu. Nhóm nhân viên bảo trì
hệ thống được phân loại như sau:
Nhân viên thiết kế/ hiện thực hệ thống: làm nhiệm vụ thiết kế và hiện thực
giao diện và các chức năng của hệ quản trị cơ sở dữ liệu nhằm cung cấp cho
người sử dụng một phần mềm đóng gói hoàn chỉnh.
Nhân viên phát triển công cụ: làm nhiệm vụ thiết kế và hiện thực các gói
phần mềm đi kèm với hệ quản trị cơ sở dữ liệu nhằm nâng cao hiệu suất
trong thiết kế và sử dụng cơ sở dữ liệu. Chúng bao gồm các gói phần mềm
hỗ trợ việc thiết kế cơ sở dữ liệu, theo dõi hiệu suất, giao diện ngôn ngữ tự
nhiên, đồ họa, giả lập, mô phỏng, và thử nghiệm dữ liệu. Những công cụ đi
kèm này thường được các nhà cung cấp phát triển và đưa vào thị trường.
1.6 NGÔN NGỮ VÀ GIAO DIỆN NGÔN NGỮ DỮ

LIỆU
Hệ quản trị cơ sở dữ liệu về cơ bản là một phần mềm cung cấp nhiều tiện ích hỗ
trợ người dùng thực hiện các thao tác quản lý, thiết kế, cập nhật và truy vấn dữ
liệu. Tuy nhiên, cũng như nhiều hệ thống khác, để có thể thao tác được với hệ
quản trị cơ sở dữ liệu, người dùng cần phải thực hiện đúng các cơ chế, nắm rõ các
quy tắc do hệ quản trị cơ sở dữ liệu đặt ra. Nói cách khác, để hệ quản trị cơ sở dữ
liệu thực hiện đúng ý đồ, người sử dụng cần phải truyền đạt mệnh lệnh theo đúng
cách mà hệ quản trị cơ sở dữ liệu quy định.
Hệ thống các hướng dẫn thực hiện mệnh lệnh do hệ quản trị cơ sở dữ liệu quy định
được thể hiện thông qua tập ngôn ngữ và các giao diện dành riêng cho từng nhóm
đối tượng người dùng. Chỉ những mệnh lệnh được quy định trong tập ngôn ngữ
này mới được hệ quản trị cơ sở dữ liệu thực thi, ngược lại, người sử dụng sẽ nhận
được thông báo lỗi tương ứng.
Trong phần này, chúng ta sẽ lần lượt tìm hiểu ba ngôn ngữ dữ liệu phổ biến nhất
được hệ quản trị cơ sở dữ liệu hỗ trợ người sử dụng:
Ngôn ngữ định nghĩa dữ liệu.
Ngôn ngữ thao tác dữ liệu.
Ngôn ngữ điều khiển dữ liệu.
1.6.1 Ngôn ngữ định nghĩa dữ liệu

Ngôn ngữ định nghĩa dữ liệu là loại ngôn ngữ được sử dụng để định nghĩa cấu trúc
của các thành phần trong cơ sở dữ liệu. Khi đó hệ quản trị cơ sở dữ liệu đóng vai
trò là một trình biên dịch chuyên xử lý các câu lệnh định nghĩa dữ liệu nhằm xác
định đặc tả cấu trúc các lược đồ và lưu trữ các đặc tả này trong danh mục của cơ
sở dữ liệu.
Thông qua ngôn ngữ định nghĩa dữ liệu, chúng ta có thể tạo mới, chỉnh sửa, và
xóa các lược đồ trong cơ sở dữ liệu. Do vai trò quan trọng của mình, cho nên ngôn
ngữ định nghĩa dữ liệu được dành riêng cho nhóm quản trị và thiết kế cơ sở dữ
liệu.
1.6.2 Ngôn ngữ thao tác dữ liệu

Khi các lược đồ đã được hiện thực thành các cơ sở dữ liệu, người sử dụng có nhu
cầu thực hiện các thao tác như thu thập, chèn, sửa, và xóa dữ liệu. Hệ quản trị cơ
sở dữ liệu cung cấp cho người sử dụng ngôn ngữ thao tác dữ liệu như là một
phương tiện giúp họ tương tác với cơ sở dữ liệu. Do tính phổ biến của mình, ngôn
ngữ này dành cho mọi đối tượng người sử dụng.
1.6.3 Ngôn ngữ điều khiển dữ liệu

Ngoài hai loại ngôn ngữ dữ liệu nói trên, hệ quản trị cơ sở dữ liệu còn cung cấp
cho người dùng ngôn ngữ điều khiển dữ liệu nhằm hỗ trợ họ thực hiện các khai
báo bảo mật thông tin và cấp quyền hạn khai thác cơ sở dữ liệu cho những người
sử dụng khác trong hệ thống. Ngôn ngữ này dành cho nhóm quản trị viên cơ sở dữ
liệu và một số người dùng đặc biệt khác trong hệ thống.
1.6.4 Các giao diện ngôn ngữ dữ liệu
Để thuận tiện cho người sử dụng thực hiện các tác vụ trên cơ sở dữ liệu, hệ quản
trị cơ sở dữ liệu cung cấp các giao diện thích hợp cho từng nhóm người sử dụng
cơ sở dữ liệu cũng như cho từng ngôn ngữ dữ liệu.
Các loại giao diện được hệ quản trị cơ sở dữ liệu hỗ trợ hiện nay bao gồm:
Giao diện trình đơn dùng cho web client hay trình duyệt: loại này thường
gồm các danh mục lựa chọn gọi là trình đơn nhằm hướng dẫn người dùng
các bước tạo lập yêu cầu.
Giao diện form: để thêm dữ liệu vào, người dùng có thể điền đầy đủ thông
tin vào một form hướng dẫn. Ngoài ra, họ còn có thể điền chỉ một vài thông
tin vào form rồi yêu cầu hệ quản trị cơ sở dữ liệu thu thập những dữ liệu
trùng khớp với các mục đã điền. Các form thường xây dựng dành cho
những dùng thông thường với các giao tác đã được tạo sẵn.
Giao diện người dùng đồ họa: hiển thị mỗi lược đồ cho người dùng dưới
dạng sơ đồ. Người dùng sẽ đặc tả truy vấn bằng việc thao tác với các sơ đồ
này. Loại giao diện này thường bao gồm cả trình đơn và form.
Giao diện ngôn ngữ tự nhiên: loại này chấp nhận các yêu cầu bằng tiếng
Anh hay một ngôn ngữ khác. Một giao diện ngôn ngữ tự nhiên thường có
“lược đồ” của riêng nó, tương tự như lược đồ ý niệm cơ sở dữ liệu, và một
từ điển các từ vựng chính.
Giao diện này hoạt động bằng cách tham khảo các từ vựng trong lược đồ
của nó cũng như trong từ điển để thông dịch các yêu cầu. Nếu thông dịch
thành công, giao diện này sẽ sinh một truy vấn cấp cao tương ứng và gửi
đến hệ quản trị cơ sở dữ liệu yêu cầu xử lý. Ngược lại, giao diện sẽ phát
sinh một hộp thoại yêu cầu người dùng hiệu chỉnh yêu cầu.
Giao diện dành cho người dùng thông thường: những loại người dùng
thông thường như các giao dịch viên ngân hàng, thường chỉ có một số thao
tác lặp đi lặp lại trên cơ sở dữ liệu. Các nhà phân tích và thiết kế sẽ tạo cho
mỗi nhóm người dùng này một loại giao diện đặc biệt bao gồm các câu lệnh
tắt giúp họ giảm bớt thời gian mô tả những tác vụ thường xuyên sử dụng.
Giao diện dành cho quản trị cơ sở dữ liệu: hầu hết hệ quản trị cơ sở dữ liệu
đều chứa một số câu lệnh cần quyền truy cập đặc biệt mà chỉ có quản trị cơ
sở dữ liệu mới có quyền thực hiện. Những câu lệnh này bao gồm việc tạo
tài khoản, thiết lập các thông số hệ thống, gán thông tin tài khoản, chỉnh
sửa lược đồ và tái tổ chức cấu trúc lưu trữ của cơ sở dữ liệu.
1.7 TÓM TẮT

Trong chương này chúng ta định nghĩa cơ sở dữ liệu như là một bộ sưu tập các dữ
liệu có liên quan về mặt luận lý, trong đó dữ liệu được hiểu như là những sự kiện
có thể được ghi lại được và thường không có ý nghĩa. Cơ sở dữ liệu thông thường
phản ánh thế giới thực theo một quan điểm cụ thể hướng tới phục vụ cho một số
nhóm người vì một hoặc nhiều mục đích cụ thể nào đó. Hệ quản trị cơ sở dữ liệu
là một phần mềm thực hiện chức năng hiện thực và duy trì cơ sở dữ liệu trên máy
tính. Bản thân cơ sở dữ liệu và hệ quản trị cơ sở dữ liệu là hai thành phần cấu
thành nên hệ thống hướng cơ sở dữ liệu. Tiếp theo chúng ta tìm hiểu nhiệm vụ,
quyền hạn cụ thể cho từng nhóm người sử dụng cơ sở dữ liệu để cuối cùng, chúng
ta nghiên cứu các ngôn ngữ dữ liệu và giao diện ngôn ngữ dữ liệu hỗ trợ người
dùng tương tác với hệ quản trị cơ sở dữ liệu.
C
CHHƯ
ƯƠƠN
NGG
2
MÔ HÌNH THỰC THỂ KẾT HỢP
Mục tiêu
Chương này tập trung nghiên cứu một phương pháp dùng để xác định cấu trúc của
cơ sở dữ liệu. Phương pháp này được xây dựng dựa trên mô hình thực thể kết hợp.
Đây được xem như là nhiệm vụ quan trọng đầu tiên mà nhân viên thiết kế dữ liệu
phải thực hiện trong quy trình phát triển cơ sở dữ liệu cho hệ thống thông tin.
Nội dung
Tổng quan về mô hình thực thể kết hợp.
Các thành phần của mô hình thực thể kết hợp.
Các vấn đề liên quan đến hoạt động thiết kế mô hình thực thể kết hợp.
Giới thiệu
Mô hình thực thể kết hợp từ khi được ra đời đã được xem như là nền tảng của các
phương pháp phân tích và thiết kế hệ thống. Nó được sử dụng rộng rãi trong các
công cụ hỗ trợ công nghệ phần mềm (computer-aided software engineering, viết
tắt là CASE), và trong các hệ thống cơ sở dữ liệu. Mô hình này được xem là nền
tảng của mô hình chu trình phát triển ứng dụng và phần mềm hệ quản trị cơ sở dữ
liệu DB2 cùng của IBM.
Mặc dù hiện nay, trong thiết kế cơ sở dữ liệu người ta thường ưu tiên sử dụng
ngôn ngữ mô hình hóa hợp nhất (unified modelling language, viết tắt là UML),
nhưng mô hình thực thể kết hợp tỏ ra thích hợp hơn đối với những người mới bắt
đầu nghiên cứu về cơ sở dữ liệu và tìm cách xây dựng cơ sở dữ liệu đầu tiên cho
bản thân mình.
Chính vì lý do đó, chúng tôi chọn mô hình thực thể kết hợp làm đối tượng nghiên
cứu trong giáo trình này nhằm tạo điều kiện thuận lợi để người đọc có thể dễ dàng
tiếp cận và thực hiện thành thạo các thao tác đặc tả dữ liệu bằng ngôn ngữ mô hình
hóa theo hướng thực thể kết hợp.
2.1 MÔ HÌNH THỰC THỂ KẾT HỢP
Như chúng ta đã biết, hầu hết các ứng dụng công nghệ thông tin hiện nay đều cần
sử dụng đến cơ sở dữ liệu cho dù với những mục đích khác nhau. Hai hệ thống
phần mềm có cùng chức năng những được áp dụng tại hai tổ chức khác nhau thì
không chỉ khác nhau về mặt tổ chức, mà còn có thể khác nhau về mặt dữ liệu. Nói
cách khác, cơ sở dữ liệu luôn phản ánh đúng thực trạng của tổ chức đang sử dụng
nó. Làm thế nào để chúng ta có thể đạt được một cơ sở dữ liệu thể hiện nguyên
vẹn tình trạng hiện tại của tổ chức và đáp ứng đầy đủ mọi nhu cầu về dữ liệu của
người sử dụng? Chúng ta nhất thiết cần phải xây dựng bản thiết kế cơ sở dữ liệu
cho tổ chức.
Mô hình thực thể kết hợp (entity relationship model) được xây dựng dựa trên sự
đặc tả thế giới thực bao gồm một tập các đối tượng cơ sở có tên gọi là tập thực thể,
và một tập các liên kết giữa các đối tượng này với nhau. Mô hình này còn được
gọi là mô hình ý niệm hay là mô hình khái niệm vì nó được xây dựng chủ yếu trên
nền tảng các khái niệm trong tổ chức, và thực tế, nó được dùng để biểu diễn cấu
trúc tổng thể của tổ chức. Mô hình thực thể kết hợp là một trong hai phương pháp
thiết kế cơ sở dữ liệu phổ biến nhất hiện nay (phương pháp còn lại sử dụng ngôn
ngữ mô hình hóa hợp nhất UML).
Mục đích của việc xây dựng mô hình thực thể kết hợp là cung cấp cho chúng ta
một bức tranh tổng thể về kết cấu dữ liệu của hệ thống, mà không quan tâm đến
việc sẽ hiện thực dữ liệu đó ra sao. Như vậy, mô hình thực thể kết hợp sẽ giúp
chúng ta trả lời câu hỏi trong cơ sở dữ liệu có những dữ liệu gì và chúng liên quan
với nhau ra sao, chứ không cho biết làm sao để đạt được cơ sở dữ liệu đó.
2.2 MỘT ỨNG DỤNG CỦA MÔ HÌNH THỰC THỂ
KẾT HỢP
Để thuận lợi cho người đọc, trong toàn bộ giáo trình này chúng tôi sử dụng duy
nhất một cơ sở dữ liệu để minh họa cho mọi ví dụ. Cơ sở dữ liệu này xây dựng
dựa trên nhu cầu thực tế của một công ty chuyên về công nghệ thông tin, cụ thể
như sau:
Công ty được tổ chức thành nhiều đơn vị với các thông tin bao gồm: tên
đơn vị, số hiệu đơn vị. Mỗi đơn vị có thể có nhiều văn phòng đại diện tại
những địa điểm khác nhau. Đơn vị được quản lý bởi một nhân viên giữ
chức vụ trưởng đơn vị. Hệ thống cũng yêu cầu phải duy trì thông tin về
ngày ký quyết định bổ nhiệm cho từng trưởng đơn vị.
Mỗi đơn vị điều hành nhiều dự án. Thông tin về dự án bao gồm: tên dự án,
số hiệu, và địa điểm thực hiện dự án.
Công ty duy trì thông tin về nhân viên bao gồm: họ và tên, mã số, mức
lương, giới tính, ngày sinh và ngày ký hợp đồng làm việc với công ty. Mỗi
nhân viên thuộc biên chế một đơn vị nhưng có thể tham gia nhiều dự án
khác nhau. Các dự án này không nhất thiết phải do cùng một đơn vị quản
lý. Công ty cũng theo dõi thời gian (tính bằng số giờ làm việc trong tuần)
tham gia từng dự án của mỗi nhân viên. Ngoài ra, mỗi nhân viên còn chịu
sự giám sát của một nhân viên khác.
Cuối cùng, công ty có chế độ bảo hiểm dành cho người thân của nhân viên.
Thông tin về người thân bao gồm tên, giới tính, ngày sinh và mối liên hệ
với nhân viên.
Do hầu hết các hệ quản trị cơ sở dữ liệu cũng như các công cụ phát triển phần
mềm được xây dựng trên nền ngôn ngữ tiếng Anh, cho nên chúng ta cũng cần ánh
xạ tất cả thông tin được yêu cầu trên đây sang ngôn ngữ tiếng Anh để thuận tiện
trong quá trình cài đặt và sử dụng sau này. Từ bản đặc tả nói trên, chúng ta nhận
thấy trong cơ sở dữ liệu COMPANY có bốn nhóm đối tượng cơ sở (cùng các
thông tin đi kèm) được liệt kê sau đây:
Đơn vị Department
Tên đơn vị DName
Số hiệu đơn vị DNumber
Các địa điểm DLocation
Dự án Project
Tên dự án PName
Số hiệu dự án PNumber
Địa điểm PLocation
Nhân viên Employee
Họ và tên EName
Mã số ESSN
Giới tính ESex
Mức lương ESalary
Ngày sinh EBirthdate
Ngày bắt đầu EStartdate
Thân nhân Dependent
Tên DName
Giới tính DSex
Ngày sinh DBirthdate
Mối liên hệ DRelationship
Bên cạnh đó, sau khi phân tích bản đặc tả, chúng ta cũng phát hiện ra được các
mối liên quan giữa các đối tượng cơ sở với nhau. Chúng được này được trình bày
theo tên theo sau là các đối tượng cơ sở. Cụ thể như sau:
Quản lý Manage
Điều hành Control
Dự án Project
Biên chế Works for
Tham gia Works on
Dự án Project
Giám sát Supervise
Phụ thuộc Belong to
Tiếp theo, để làm quen với mô hình thực thể kết hợp, chúng ta tìm hiểu các thành
phần cơ bản tạo nên mô hình này và các định nghĩa khác có liên quan tới việc thiết
kế mô hình thực thể kết hợp.
2.3 CÁC KHÁI NIỆM

2.3.1 Thực thể và thuộc tính
Đối tượng trung tâm của mô hình thực thể kết hợp chính là thực thể. Thực thể là
những đối tượng dữ liệu cơ bản chứa nội dung các thông tin cần thu thập. Do đó,
thực thể có thể là một sự vật hoặc một hiện tượng tồn tại độc lập trong thế giới
thực; nó cũng có thể là một đối tượng tồn tại dưới dạng vật lý (như là con người,
cuốn sách, …) hoặc ở dạng ý niệm (như là công ty, lớp học, …).
Các thực thể được phân biệt với nhau nhờ các đặc trưng của nó. Hai thực thể khác
nhau thì phải có ít nhất một đặc trưng có giá trị khác nhau. Người ta gọi mỗi đặc
trưng của thực thể là một thuộc tính của thực thể đó. Khi xác định thuộc tính cho
một kiểu thực thể, chúng ta cần phải lựa chọn miền giá trị cho thuộc tính đó. Miền
giá trị của một thuộc tính thực chất là tập hợp các giá trị mà thuộc tính đó có thể
nhận được. Miền giá trị có thể là tập các số nguyên, các số thực, các xâu ký tự,
hoặc là tập liệt kê một số giá trị cụ thể. Miền giá trị cũng có thể là một tích
Decartes của nhiều tập giá trị khác nhau. Tập thực thể là tập hợp các thực thể có
cùng kiểu thực thể.
VÍ DỤ 2.1: Miền giá trị của thuộc tính.

Trong CSDL COMPANY trình bày ở trên, mỗi thực thể DEPARTMENT có ba
thuộc tính, lần lượt là DName, DNumber, và DLocation, trong khi mỗi thực thể
DEPENDENT có tới bốn thuộc tính, lần lượt là DName, DSex, DBirthdate, và
DRelationship. Miền giá trị của DNumber có thể là tập các số nguyên, của
DBirthdate là tập các giá trị ngày tháng, của DSex có thể là tập liệt kê gồm hai giá
trị {‘F’,’M’} ứng với hai giới tính Nữ và Nam.

Đối với mỗi thực thể chúng ta cần phải xác định giá trị cụ thể cho từng thuộc tính
của nó. Các giá trị thuộc tính đó sau này sẽ là những thành phần dữ liệu được lưu
trữ trong CSDL.
VÍ DỤ 2.2: Giá trị của thực thể.

Thực thể DEPARTMENT được mô tả trong ví dụ 2.1 có các giá trị lần lượt cho
các thuộc tính DName, DNumber, DLocation là ‘Phòng Phần mềm trong nước’, 1,
và {‘TP. Hà Nội’, ‘TP. Hồ Chí Minh’}.

2.3.1.1 Thuộc tính đơn và thuộc tính tổ hợp
Trong mô hình thực thể kết hợp mỗi thuộc tính biểu diễn một đặc trưng riêng của
tập thực thể và mỗi thực thể có một giá trị tại từng thuộc tính này. Thuộc tính tổ
hợp là thuộc tính có thể phân thành nhiều thuộc tính nhỏ hơn. Trong khi đó, thuộc
tính không thể phân rã được nữa gọi là thuộc tính đơn. Thuộc tính tổ hợp có lúc
được dùng như một thuộc tính đơn, tuy nhiên, trong nhiều trường hợp chúng ta lại
quan hệ tới từng thành phần riêng lẻ của nó.
VÍ DỤ 2.3: Thuộc tính đơn và thuộc tính tổ hợp.

Trong tập thực thể EMPLOYEE, thuộc tính ESSN là một thuộc tính đơn, vì
chúng ta không thể phân rã thuộc tính này thành nhiều thuộc tính khác. Trong khi
đó, chúng ta có thể xem thuộc tính EName (họ tên nhân viên) là thuộc tính tổ hợp,
nó có thể được phân rã thành hai thuộc tính đơn khác là EFName, ELName với ý
nghĩa lần lượt là họ và tên nhân viên.

2.3.1.2 Thuộc tính đơn trị và đa trị
Một thực thể tại mỗi thuộc tính có một giá trị tương ứng. Trong nhiều trường hợp,
giá trị này là một giá trị đơn, và chúng ta gọi là thuộc tính đơn trị. Tuy nhiên, cũng
có trường hợp, giá trị của một thuộc tính không phải là giá trị đơn, mà là một tập
hợp của nhiều giá trị đơn. Khi đó, thuộc tính được gọi là đa trị. Mỗi thuộc tính đa
trị có thể có giới hạn trên và giới hạn dưới để ràng buộc số giá trị tối đa và tối
thiểu của thuộc tính đó trong từng thực thể.
VÍ DỤ 2.4: Thuộc tính đơn trị và thuộc tính đa trị

Trong tập thực thể DEPARTMENT, thuộc tính DNAME là thuộc tính đơn trị,
trong khi thuộc tính DLocation lại là thuộc tính đa trị, nó cho biết các địa điểm mà
thực thể đang xét có văn phòng đại diện. Trong trường hợp chúng ta chỉ cho phép
một đơn vị có tối đa 5 văn phòng đại diện, giới hạn trên của thuộc tính này là 5.

2.3.1.3 Thuộc tính lưu trữ và thuộc tính dẫn xuất
Như đã trình bày ở trên, thuộc tính cho biết đặc trưng của thực thể, giá trị của
thuộc tính dùng để phân biệt các thực thể với nhau, và được lưu trữ trong cơ sở dữ
liệu. Thuộc tính lưu trữ là thuộc tính mà giá trị của nó không phụ thuộc vào bất cứ
thuộc tính nào khác. Trong khi đó, thuộc tính dẫn xuất là thuộc tính mà giá trị có
được là do kết quả của phép tính toán dựa trên các thuộc tính khác. Đôi khi, người
ta còn gọi thuộc tính lưu trữ là thuộc tính độc lập còn thuộc tính dẫn xuất là thuộc
tính phụ thuộc.
VÍ DỤ 2.5: Thuộc tính lưu trữ và thuộc tính dẫn xuất.

Giả sử tập thực thể EMPLOYEE được mở rộng bằng một thuộc tính EAge với ý
nghĩa biểu diễn độ tuổi hiện tại của nhân viên. Rõ ràng, giá trị của thuộc tính này
có thể được tính từ giá trị của thuộc tính EBirthdate tương ứng. Do đó, thuộc tính
EAge gọi là thuộc tính dẫn xuất. Thuộc tính EBirthdate không phụ thuộc vào bất
kỳ thuộc tính nào khác nên gọi là thuộc tính lưu trữ.

2.3.1.4 Giá trị null
Nói đến một thực thể cụ thể, tức là chúng ta nói đến giá trị tại các thuộc tính của
thực thể đó. Tuy nhiên, với một số thuộc tính của thực thể, chúng ta có thể không
biết giá trị của chúng có tồn tại hay không, hoặc nếu tồn tại thì không biết cụ thể là
gì, hay không thể sử dụng các giá trị đó ở thời điểm hiện tại, … Khi đó, chúng ta
có thể sử dụng một giá trị đặc biệt, đó là giá trị null với nhiều cách diễn giải khác
nhau: giá trị không biết, giá trị tồn tại nhưng không xác định, hoặc thuộc tính
tương ứng không áp dụng cho thực thể đang xem xét.
VÍ DỤ 2.6: Giá trị NULL.

Giả sử một thực thể EMPLOYEE có giá trị null tại thuộc tính EBirthdate. Điều
này chỉ có thể được giải thích là do chúng ta không biết thông tin về ngày sinh của
nhân viên đó.

2.3.1.5 Tập thực thể
Trong mô hình thực thể kết hợp, chúng ta không biểu diễn các thực thể riêng lẻ.
Có nghĩa là, giả sử chúng ta có 5 thực thể phân biệt có cùng các thuộc tính là
Name, Number, Location, thì không nhất thiết chúng ta phải thể hiện cả 5 thực thể
đó trên mô hình. Thay vào đó, chúng ta chỉ cần biểu diễn một khái niệm đại diện
cho cả 5 thực thể giống nhau đó. Khái niệm này được gọi là tập thực thể
DEPARTMENT. Tập thực thể được định nghĩa như là một nhóm các thực thể có
các thuộc tính giống nhau. Để biểu diễn tập thực thể, chúng ta cần cung cấp tên
gọi (duy nhất) và danh sách các thuộc tính của tập thực thể đó.
VÍ DỤ 2.7: Tập thực thể trong cơ sở dữ liệu COMPANY.

Như vậy trong COMPANY ứng với mỗi nhóm đối tượng cơ sở chúng ta có một
tập thực thể cùng tên kèm theo các thuộc tính của chúng. Ví dụ như tập thực thể
DEPARTMENT có các thuộc tính DName, DNumber, và DLocation. Tương tự
như thế đối với các tập thực thể EMPLOYEE, PROJECT, và DEPENDENT.

Để biểu diễn tập thực thể và các thuộc tính kèm theo trên mô hình thực thể kết hợp
chúng ta sử dụng hai loại hình vẽ là hình chữ nhật và hình elip. Hình 2.8 sau đây
sẽ cho chúng ta hình ảnh về mô hình thực thể kết hợp đối với ứng dụng mẫu được
trình bày trong mục 2.2.
Hình 2.1. Biểu diễn các tập thực thể trong CSDL COMPANY.
2.3.1.6 Thuộc tính khóa
Như đã trình bày, tập thực thể là tập hợp các thực thể có cùng các thuộc tính. Theo
khái niệm tập hợp, hai phần tử trong cùng tập hợp thì không thể giống nhau. Do
đó, hai thực thể trong một tập thực thể cũng không thể giống nhau. Mỗi thực thể
được phân biệt bởi một bộ giá trị ứng với các thuộc tính của nó. Vì thế, hai thực
thể trong một tập thực thể phải có ít nhất một giá trị khác nhau trong hai bộ giá trị
tương ứng của chúng. Nói cách khác, hai thực thể này phải khác nhau ở tại ít nhất
một thuộc tính (gọi là thuộc tính phân biệt).
Nếu trong tập thực thể có một thuộc tính có khả năng phân biệt tất cả các thực thể
trong tập thực thể đó, thì thuộc tính đó được gọi là khóa của tập thực thể. Tuy
nhiên, không phải lúc nào trong tập thực thể cũng tồn tại một thuộc tính như thế.
Khi đó, chúng ta phải tìm kiếm một tập hợp gồm nhiều thuộc tính có khả năng
phân biệt hai thực thể bất kỳ, và cũng gọi chúng là khóa của tập thực thể.
Một cách khái quát, trong một tập thực thể, luôn tồn tại một tập hợp gồm ít nhất
một thuộc tính có khả năng phân biệt hai thực thể bất kỳ trong tập thực thể đó. Tập
hợp các thuộc tính này được gọi là khóa của tập thực thể đang xét.
VÍ DỤ 2.8: Thuộc tính khóa của tập thực thể.

Trong tập thực thể EMPLOYEE, không có hai thực thể nào có thể có giá trị giống
nhau tại thuộc tính ESSN. Do đó, {ESSN} là khóa của EMPLOYEE. Nếu chúng
ta giả định rằng, tại một địa điểm không thể có hai dự án cùng tên, thì {PName,
PLocation} là một khóa của tập thực thể PROJECT.

Một tập thực thể có thể có nhiều khóa, các khóa này không nhất thiết có số thuộc
tính giống nhau, thậm chí, một thuộc tính cũng có thể xuất hiện trong nhiều khóa.
Chúng ta chọn một trong số các khóa của tập thực thể, thường là khóa có ít thuộc
tính nhất, làm khóa chính, những khóa còn lại được gọi là khóa phụ. Chú ý rằng,
trong trường hợp khóa có một thuộc tính, chúng ta chỉ cần ghi tên thuộc tính mà
bỏ qua ký hiệu tập hợp đi kèm.
VÍ DỤ 2.9: Khóa chính và khóa phụ của tập thực thể.
Trong tập thực thể PROJECT, với giả định như trong ví dụ 2.8, tập các thuộc tính
{PName, PLocation} là một khóa. Ngoài ra, trong tập thực thể này, không thể có
hai thực thể có giá trị bằng nhau tại thuộc tính PNumber, PNumber là một khóa
khác của PROJECT. Chúng ta chọn PNumber là khóa chính, trong khi {PName,
PLocation} là khóa phụ của tập thực thể PROJECT.

2.3.2 Các liên kết
2.3.2.1 Định nghĩa
Trong định nghĩa về cơ sở dữ liệu chúng ta có phát biểu rằng cơ sở dữ liệu là một
tập hợp nhiều dữ liệu có mối liên quan về mặt ý nghĩa với nhau. Mặt khác, mô
hình thực thể kết hợp phản ánh thế giới thực mà cơ sở dữ liệu muốn lưu trữ. Vậy,
làm thế nào để mô hình thực thể kết hợp có thể phản ánh được các mối liên quan
về mặt ý nghĩa của các dữ liệu, mà cụ thể là mối liên quan giữa các tập thực thể?
Các liên kết được sử dụng để thực hiện nhiệm vụ đó.
Theo đó, một liên kết là một sự kết hợp giữa một số thực thể. Các thực thể này có
thể thuộc các tập thực thể khác nhau, hoặc thuộc cùng một tập thực thể. Một kiểu
liên kết giữa các tập thực thể được định nghĩa như là tập hợp các liên kết giữa các
thực thể thuộc các tập thực thể nói trên.
Xét theo quan điểm toán học, kiểu liên kết R giữa các tập thực thể E1, E2, …, En
thực chất là một quan hệ toán học trên E1, E2, …, En và được ký hiệu là
R⊆E1×E2×…×En. Trong đó, mỗi liên kết ri ⊆ R kết hợp n thực thể e1, e2, …, en với
nhau (ei ∈ Ei) và được gọi là một thể hiện của kiểu liên kết R. Vì kiểu liên kết R có
sự tham gia của n tập thực thể, nên R còn gọi là liên kết bậc n. Nói cách khác, bậc
của kiểu liên kết chính là số tập thực thể tham gia trong liên kết đó.
VÍ DỤ 2.10: Liên kết hai ngôi.
Trong COMPANY ứng với mỗi mối liên quan giữa các đối tượng cơ sở chúng ta
tạo một kiểu liên kết cùng tên kèm theo các tập thực thể tham gia trong kiểu liên
kết đó. Ví dụ, chúng ta có kiểu liên kết MANAGES giữa hai tập thực thể
DEPARTMENT và EMPLOYEE. Đây là kiểu liên kết bậc hai (còn gọi là hai
ngôi) do có hai tập thực thể tham gia trong liên kết.

2.3.2.2 Phân loại
Để đảm bảo mối liên hệ về mặt ngữ nghĩa của các kiểu thực thể, chúng ta cần phải
chọn lựa kiểu liên kết cũng như các kiểu thực thể tham gia trong các kiểu liên kết
đó. Người ta tiến hành phân loại các kiểu liên kết chủ yếu dựa trên số lượng các
tập thực thể tham gia trong một liên kết: liên kết bậc 2 (liên kết hai ngôi) và liên
kết bậc cao (từ 3 trở lên). Thực tế liên kết bậc 2 là loại liên kết phổ biến nhất,
trong khi một liên kết bậc cao có thể được phân tách thành nhiều liên kết bậc 2 mà
vẫn đảm bảo đầy đủ ý nghĩa của liên kết. Ví dụ sau đây sẽ cho chúng ta thấy cách
thức chuyển đổi một liên kết bậc 3 thành 3 liên kết bậc 2.
VÍ DỤ 2.11: Phân rã liên kết nhiều ngôi thành nhiều liên kết hai ngôi.
Giả sử trong COMPANY chúng ta định nghĩa thêm tập thực thể REPORT nhằm
mục đích thể hiện các báo cáo mà mỗi nhân viên đã thực hiện theo định kỳ cho
từng dự án mà họ tham gia. Rõ ràng trong trường hợp này, kiểu liên kết WORKS
ON có sự tham gia của ba tập thực thể là EMPLOYEE, PROJECT, và
REPORT. Chúng ta có thể phân tách kiểu liên kết 3 ngôi này thành các kiểu liên
kết 2 ngôi bằng cách thay thế kiểu liên kết WORKS ON bằng tập thực thể
WORKS ON, sau đó, tạo 3 liên kết 2 ngôi giữa WORKS ON với lần lượt
EMPLOYEE, PROJECT, và REPORT.
Hình 2.2. Biến đổi liên kết ba ngôi thành các liên kết hai ngôi

Tiếp theo, chúng ta tìm cách phân loại các kiểu liên kết 2 ngôi dựa trên số lượng
các thực thể tham gia trong một liên kết. Giá trị này được thể hiện bằng một con
số được biểu diễn ngay trên mô hình thực thể kết hợp. Chúng ta có ba trường hợp
phân biệt: liên kết một – một, liên kết một – nhiều và liên kết nhiều – nhiều:
a) Liên kết một – một là dạng liên kết đơn giản nhất của kiểu liên kết hai ngôi.
Nó diễn tả mối quan hệ giữa một thực thể trong tập thực thể này với nhiều nhất
một thực thể trong tập thực thể kia và ngược lại.
VÍ DỤ 2.12: Biểu diễn liên kết một – một.

Trong COMPANY kiểu liên kết MANAGES là kiểu liên kết một – một nếu chúng
ta có giả định như sau: tại mỗi thời điểm một đơn vị có duy nhất một trưởng đơn
vị; ngược lại, mỗi nhân viên có thể là trưởng của (nhiều nhất) một đơn vị nào đó
mà thôi
Hình 2.3. Biểu diễn liên kết một – một trong CSDL COMPANY

b) Liên kết một – nhiều là loại liên kết mà trong đó một thực thể trong tập thực
thể E2 được kết hợp với nhiều thực thể trong tập thực thể E1, nhưng mỗi thực
thể trong tập thực thể E1 chỉ kết hợp với nhiều nhất một thực thể trong tập thực
thể E2. Loại liên kết này được gọi là liên kết nhiều – một từ E1 đến E2.
VÍ DỤ 2.13: Biểu diễn liên kết một – nhiều.

Trong COMPANY kiểu liên kết WORKS FOR là kiểu liên kết nhiều – một từ
EMPLOYEE đến DEPARTMENT với ý nghĩa một đơn vị quản lý nhiều nhân
viên, một nhân viên thuộc biên chế của nhiều nhất một đơn vị.
Hình 2.4. Biểu diễn liên kết một – nhiều trong CSDL COMPANY

c) Liên kết nhiều – nhiều là loại liên kết mà trong đó không có sự giới hạn về số
lượng thực thể trong mỗi tập thực thể tham gia. Nói cách khác, với kiểu liên
kết nhiều – nhiều giữa hai tập thực thể E1 và E2, chúng ta có thể hiểu là mỗi
thực thể trong tập thực thể E1 có thể kết hợp với nhiều thực thể trong tập thực
thể E2 và ngược lại.
VÍ DỤ 2.14: Biểu diễn liên kết nhiều – nhiều.

Trong COMPANY kiểu liên kết WORKS ON là kiểu liên kết nhiều – nhiều giữa
EMPLOYEE và PROJECT với ý nghĩa một nhân viên có thể tham gia nhiều dự
án, và ngược lại, một dự án có nhiều nhân viên cùng tham gia.
Hình 2.5. Biểu diễn liên kết nhiều – nhiều trong CSDL COMPANY

2.3.2.3 Thuộc tính của liên kết và vai trò của tập thực thể trong liên kết
Khi thể hiện kiểu liên kết trong mô hình thực thể kết hợp, để người đọc có thể hiểu
chính xác về nhiệm vụ của từng tập thực thể trong liên kết chúng ta xác định vai
trò của từng tập thực thể tham gia trong liên kết đó.
VÍ DỤ 2.15: Vai trò của thực thể trong liên kết.

Xét kiểu liên SUPERVISES giữa hai thực thể cùng thuộc tập thực thể
EMPLOYEE. Để thể hiện rõ vai trò của từng thực thể trong liên kết (nhân viên
nào là quản lý trực tiếp cho nhân viên kia), chúng ta cần thể hiện rõ vai trò của
chúng ngay trên liên kết này. Cụ thể như sau:
Hình 2.6. Biểu diễn vai trò của tập thực thể trong liên kết
Rõ ràng, với vai trò supervisor, một nhân viên là lãnh đạo trực trực tiếp của không
hoặc nhiều nhân viên khác. Ngược lại, với vai trò supervisee, một nhân viên chịu
sự quản lý của nhiều nhất một nhân viên khác.

Trong mô hình thực thể kết hợp, thuộc tính không chỉ được dùng để thể hiện đặc
trưng của tập thực thể, mà nó còn được dùng để bổ sung thông tin cho kiểu liên
kết. Trong trường hợp sau, thuộc tính được gọi là thuộc tính của kiểu liên kết,
thuộc tính gắn với liên kết. Ví dụ 2.16 sẽ cho chúng ta biết tại sao phải sử dụng
thuộc tính của kiểu liên kết mà không phải là thuộc tính của tập thực thể.
VÍ DỤ 2.16: Thuộc tính của liên kết.

Trong COMPANY kiểu liên kết WORKS ON cho chúng ta biết mỗi nhân viên
tham gia nhiều dự án, và ngược lại, một dự án có nhiều nhân viên tham gia. Tuy
nhiên, nhu cầu thông tin về tham gia các dự án của nhân viên không chỉ có thế.
Chúng ta muốn biết chi tiết về số giờ lao động mà mỗi nhân tham gia từng dự án.
Thông tin này chỉ có thể là một thuộc tính (với tên gọi là Hours). Vấn đề đặt ra là
thuộc tính này gắn liền với tập thực thể nào, EMPLOYEE hay PROJECT? Nếu
đây là thuộc tính của EMPLOYEE, nghĩa là mỗi nhân viên có một giá trị duy
nhất tại thuộc tính Hours. Phải chăng mọi nhân viên đều tham gia các dự án với số
giờ lao động bằng nhau và bằng chính giá trị tại thuộc tính Hours? Điều này là
không thực tế. Tương tự, nếu Hours là thuộc tính của PROJECT, chẳng lẽ mọi
nhân viên tham gia một dự án đều có số giờ lao động bằng nhau và bằng chính giá
trị tại thuộc tính Hours của dự án đó? Điều này cũng phi lý. Như vậy, thuộc tính
Hours không là thuộc tính của EMPLOYEE, mà cũng không là thuộc tính của
PROJECT. Nó là thuộc tính của kiểu liên kết WORKS ON, nó bổ sung thông tin
cho liên kết này với đúng ý nghĩa của liên kết này: mỗi liên kết trong kiểu liên kết
WORKS ON cho biết sự kết hợp giữa một nhân viên và một dự án.
Hình 2.7. Biểu diễn thuộc tính của liên kết WOKRSON trong CSDL COMPANY.

2.3.3 Tập thực thể yếu
Trong quá trình định danh các tập thực thể và các kiểu liên kết giữa các tập thực
thể, chúng ta nhận thấy có trường hợp tập thực thể E1 phụ thuộc chặt chẽ vào tập
thực thể E2 thông qua kiểu liên kết R. Sự phụ thuộc này có thể được diễn tả như
sau: mỗi thực thể e2 trong E2 kết hợp với nhiều thực thể e1 trong E1 theo các liên
kết r trong R. Khi thực thể e2 bị xóa ra khỏi E2, tất cả các thực thể e1 và các liên
kết r nói trên đều lần lượt bị xóa ra khỏi E1 và R mà không có bất kỳ sự lựa chọn
nào khác. Khi đó, người ta gọi E1 là tập thực thể yếu, R là kiểu liên kết hỗ trợ, và
E2 là tập thực thể hỗ trợ. Ví dụ sau đây minh họa chi tiết một tập thực thể yếu
trong COMPANY.
VÍ DỤ 2.17: Tập thực thể yếu.
Trong COMPANY, tập thực thể DEPENDENT cho biết thông tin về người thân
của mỗi nhân viên thông qua kiểu liên kết BELONG TO. Rõ ràng, mỗi nhân viên
có nhiều người thân, ngược lại, mỗi người thân chỉ có quan hệ gia đình với một
nhân viên nào đó. Giả sử một nhân viên tên An có hai người thân tên gọi lần lượt
là Bình và Lành. Điều gì xảy ra với hai thực thể ứng với hai người thân tên Bình
và Lành nếu thực thể ứng với nhân viên tên An bị xóa khỏi tập thực thể
EMPLOYEE? Rõ ràng, lúc này người tên An không còn là nhân viên của công ty,
và như vậy, không có lý do gì để công ty duy trì thông tin về những người thân
của anh ta. Kết quả, hai thực thể ứng với hai người thân tên Bình và Lành bị xóa ra
khỏi tập thực thể DEPENDENT. Chính vì sự phụ thuộc chặt chẽ này, cho nên tập
thực thể DEPENDENT được gọi là tập thực thể yếu, còn HAS và EMPLOYEE
có tên gọi lần lượt là kiểu liên kết hỗ trợ, và tập thực thể hỗ trợ.
Hình 2.8. Biểu diễn tập thực thể yếu DEPENDENT trong CSDL COMPANY

Như vậy, tập thực thể E1 được gọi là yếu khi nó phụ thuộc vào tập thực thể E2
thông qua một kiểu liên kết hỗ trợ có tên là R. Các điều kiện sau đây xác định E1 là
tập thực thể yếu và R là kiểu liên kết hỗ trợ:
Kiểu liên kết R là loại liên kết hai ngôi nhiều – một từ E1 đến E2
Tập thực thể E1 không có khóa, nó phải nhận khóa từ tập thực thể E2 về làm
khóa cho nó.
VÍ DỤ 2.18: Khóa của tập thực thể yếu.
Tập thực thể DEPENDENT không có khóa, do đó nó phải nhận khóa từ tập thực
thể EMPLOYEE về làm khóa. Như vậy, khóa của DEPENDENT là {ESSN,
DName}.

2.4 CÁC VẤN ĐỀ KHI THIẾT KẾ MÔ HÌNH THỰC

THỂ KẾT HỢP
2.4.1 Các ký hiệu sử dụng trong mô hình thực thể kết hợp
Khi thiết kế mô hình thực thể kết hợp, chúng ta chú trọng biểu diễn cấu trúc của
dữ liệu thông qua các tập thực thể, các thuộc tính, các kiểu liên kết hơn là biểu
diễn những thể hiện cụ thể của dữ liệu. Sở dĩ chúng ta làm như thế là bởi vì cấu
trúc dữ liệu sau khi đã được cài đặt thành cơ sở dữ liệu và đưa vào sử dụng thì rất
ít bị thay đổi. Những sự thay đổi liên quan đến cấu trúc của cơ sở dữ liệu thường
rất tốn kém cả về thời gian lẫn chi phí.
Bảng 2.1 tóm tắt lại toàn bộ ký hiệu được sử dụng trong mô hình thực thể kết hợp
và ý nghĩa của chúng.
2.4.2 Quy tắc đặt tên trong mô hình thực thể kết hợp
Trong quá trình thiết kế cơ sở dữ liệu nói chung và mô hình thực thể kết hợp nói
riêng, việc xác định tên gọi cho các tập thực thể, thuộc tính, kiểu liên kết và các
vai trò không phải lúc nào cũng thuận lợi. Bản thiết kế của chúng ta phải vừa rõ
ràng, mạch lạc, đầy đủ ý nghĩa vì không phải chỉ chúng ta, những người thiết kế,
sử dụng nó, mà còn nhiều nhóm người dùng khác cũng có nhu cầu tham khảo nó.
Chúng ta có xu hướng đặt tên cho các thành phần trong mô hình thực thể kết hợp
bằng các từ ngữ có ý nghĩa, càng đơn giản càng tốt. Chúng ta nên chọn tên tập
thực thể là các danh từ số ít, bởi vì tên tập thực thể thường áp dụng cho từng thực
thể riêng lẻ của tập thực thể đó. Ngoài ra, chúng ta quy ước sử dụng chữ in hoa để
biểu diễn tên tập thực thể và tên kiểu liên kết, chữ in thường để thể hiện các vai
trò; với thuộc tính, ký tự đầu tiên ghi hoa, các ký tự khác ghi thường.
Thực tế, khi đọc một bản đặc tả yêu cầu dữ liệu của hệ thống, chúng ta hoàn toàn
có đầy đủ cơ sở để xây dựng được mô hình thực thể kết hợp đáp ứng đầy đủ các
yêu cầu đặt ra. Nhìn chung, các danh từ chung chỉ sự vật, hiện tượng cần được ghi
nhận chính là các tập thực thể; các tính từ, hoặc các danh từ diễn tả tính chất, hoặc
đặc trưng thường là các thuộc tính; các động từ thể hiện mối liên quan giữa các tập
thực thể chính là kiểu liên kết.
Bảng 2.1. Tóm tắt các ký hiệu trong mô hình thực thể kết hợp
KÝ HIỆU Ý NGHĨA VÍ DỤ MINH HỌA
Tập thực thể
Tập thực thể yếu
Kiểu liên kết
Kiểu liên kết hỗ trợ
Thuộc tính
Thuộc tính khóa
Thuộc tính đa trị
Thuộc tính tổ hợp
Thuộc tính dẫn xuất
Một nguyên tắc quan trọng khi trình bày mô hình thực thể kết hợp đó là các mô
hình của chúng ta được thiết kế để có thể đọc được từ trái sang phải, từ trên xuống
dưới theo chiều hướng của các kiểu liên kết. Chính vì vậy, đôi khi chúng ta phải
đặt lại tên cho kiểu liên kết để có thể đáp ứng được yêu cầu này.
Như vậy, sau khi tổng hợp tất cả các vấn đề đã trình bày ở trên, chúng ta có mô
hình thực thể kết hợp hoàn chỉnh cho cơ sở dữ liệu COMPANY giới thiệu ở mục
2.2.
Hình 2.9. Biểu diễn cơ sở dữ liệu COMPANY bằng mô hình thực thể kết hợp.
2.5 TÓM TẮT

Trong chương này chúng ta trình bày một mô hình được được sử dụng để thiết kế
cấu trúc của cơ sở dữ liệu: mô hình thực thể kết hợp. Mô hình này tập trung biểu
diễn cấu trúc của dữ liệu và các ràng buộc cấu trúc trên dữ liệu chứ không quan
tâm đến các thao tác trên dữ liệu. Chúng ta lần lượt tìm hiểu các thành phần cơ bản
của mô hình thực thể kết hợp: tập thực thể, thuộc tính, và kiểu liên kết. Tập thực
thể phản ánh các sự vật, hiện tượng trong thế giới thực cần được thể hiện trong cơ
sở dữ liệu. Chúng ta phân biệt các thực thể trong tập thực thể bởi các giá trị tại các
thuộc tính của chúng. Trong khi thuộc tính biểu diễn các đặc trưng, tính chất của
tập thực thể, kiểu liên kết lại được sử dụng để mô tả mối liên quan giữa các tập
thực thể với nhau. Tùy theo số lượng các tập thực thể tham gia trong kiểu liên kết
mà chúng ta xác định bậc của kiểu liên kết. Riêng đối với kiểu liên kết hai ngôi,
chúng ta còn xác định được lực lượng của từng tập thực thể tham gia trong liên
kết. Nhờ đó, chúng ta phân biệt ba loại kiểu liên kết hai ngôi: một – một, một –
nhiều, và nhiều – nhiều. Cuối cùng, chúng ta định nghĩa một kiểu liên kết hai ngôi
nhiều – một đặc biệt, kiểu liên kết hỗ trợ. Một kiểu liên kết gọi là hỗ trợ khi nó thể
hiện mối quan hệ phụ thuộc giữa hai tập thực thể: các thực thể trong tập thực thể
này tồn tại hay không là do một thực thể trong tập thực khác quyết định.
C
CHHƯ
ƯƠƠN
NGG
3
MÔ HÌNH
THỰC THỂ KẾT HỢP MỞ RỘNG
Mục tiêu
Người đọc được trang bị các kiến thức về mô hình thực thể kết hợp mở rộng với
các khái niệm về sự kế thừa, quá trình khái quát hóa và chuyên biệt hóa, các loại
ràng buộc không trùng lắp, ràng buộc toàn phần, … nhằm giải quyết một lớp yêu
cầu dữ liệu mà mô hình thực thể kết hợp không thể đáp ứng được.
Nội dung
Những hạn chế của mô hình thực thể kết hợp.
Các thành phần của mô hình thực thể kết hợp mở rộng.
Ngôn ngữ mô hình hóa hợp nhất.
Giới thiệu
Mô hình thực thể kết hợp mở rộng, đúng khi tên gọi của nó, là một sự mở rộng từ
mô hình thực thể kết hợp với các khái niệm có liên quan đến mối liên kết cha/con
giữa các tập thực thể. Mối liên kết này được thể hiện thông qua hai quá trình:
chuyên biệt hóa và khái quát hóa. Hai quá trình này được tiến hành ngược nhau,
nếu quá trình chuyên biệt hóa tạo các lớp con từ một lớp cha, thì quá trình khái
quát hóa tạo lớp cha từ các lớp con. Các quá trình này có thể dựa trên các ràng
buộc trên thuộc tính hoặc do người sử dụng tự định nghĩa. Ngoài ràng buộc trên
thuộc tính, trong chuyên biệt hóa còn có hai ràng buộc khác, đó là ràng buộc
không trùng lắp và ràng buộc toàn phần. Các ràng buộc này quyết định hành vi
thêm mới hay xóa bỏ thực thể ra khỏi các lớp trong mối liên kết cha/con.
Với mô hình thực thể kết hợp mở rộng, chúng ta có thể giải quyết các vấn đề phát
sinh khi sử dụng mô hình thực thể kết hợp để thiết kế dữ liệu cho các hệ thống lớn,
phức tạp, nhiều tầng nhiều lớp.
3.1 NHỮNG HẠN CHẾ CỦA MÔ HÌNH THỰC THỂ
KẾT HỢP
Mô hình thực thể kết hợp được xem là phương pháp đơn giản nhất để thiết kế cấu
trúc dữ liệu dựa trên yêu cầu của người sử dụng. Phương pháp này được sử dụng
rộng rãi trong quá khứ khi chúng ta có nhu cầu thiết kế cơ sở dữ liệu cho các hệ
thống sử dụng cơ sở dữ liệu đơn giản, một cấp. Tuy nhiên, có những vấn đề phát
sinh khi áp dụng phương pháp này trong việc xây dựng các cơ sở dữ liệu phức tạp,
đa cấp.
Ở phần cuối chương hai, chúng ta đã đề xuất một bản thiết kế cơ sở dữ liệu sử
dụng mô hình thực thể kết hợp cho ví dụ mẫu được trình bày trong mục 2.2. Bây
giờ, chúng ta bổ sung thêm một số yêu cầu cho phần đặc tả dữ liệu, và tìm cách
hiện thực hóa các yêu cầu đó bằng mô hình thực thể kết hợp:
Nhân viên trong công ty được phân chia làm nhiều nhóm khác nhau, dựa
vào nhiệm vụ mà từng nhân viên đảm nhận trong công ty. Chúng ta có ba
nhóm nhân viên: nhân viên văn phòng, nhân viên kỹ thuật và nhân viên lái
xe. Mỗi nhóm nhân viên ngoài những đặc trưng chung của một nhân viên,
còn có các đặc trưng riêng.
Công ty duy trì thông tin về người thân đối với nhân viên trong nhóm kỹ sư
thay vì đối với toàn bộ nhân viên trong công ty.
Chỉ với hai yêu cầu đặc tả tương đối đơn giản trên đây, mô hình thực thể kết hợp
đã bộc lộ một số nhược điểm của nó:
Để mô tả các nhóm nhân viên với những đặc tính khác nhau, chúng ta cần
tạo những tập thực thể khác nhau (1). Cụ thể ở đây, ngoài tập thực thể
EMPLOYEE, chúng ta cần phải sử dụng thêm ba tập thực thể khác lần
lượt là SECRETARY, ENGINEER và DRIVER. Ba tập thực thể có các
thuộc tính của riêng nó và các thuộc tính chung tương tự như
EMPLOYEE. Tiếp theo, với mối quan hệ được mô tả giữa các tập thực thể
này với nhau, chúng ta nhận thấy, mỗi nhân viên chỉ có thể đảm nhiệm một
công việc trong công ty mà thôi, nếu người này là nhân viên kỹ thuật thì
không thể là nhân viên hành chính hay nhân viên lái xe được. Do đó, mỗi
thực thể trong EMPLOYEE chỉ có thể xuất hiện duy nhất một lần ở đâu đó
trong SECRETARY, ENGINEER, và DRIVER. Mô hình thực thể kết
hợp không thể biểu diễn được các mối quan hệ dạng như thế này.
Để mô tả các nhóm nhân viên với những đặc tính khác nhau, chúng ta tạo
một tập thực thể EMPLOYEE duy nhất chứa tất cả thuộc tính của các
nhóm nhân viên nói trên (2). Khi đó, thuộc tính riêng của nhóm sẽ giúp xác
định một thực thể trong EMPLOYEE thuộc nhóm nào. Tuy nhiên, trong
trường hợp này, chúng ta không thể diễn giải trên mô hình mối quan hệ
giữa hai tập thực thể EMPLOYEE và DEPENDENT. Công ty chỉ muốn
duy trì thông tin về người thân của kỹ sư mà thôi.
Từ (1) và (2) chúng ta thấy rằng, mô hình thực thể kết hợp chỉ thích hợp đối với
những dữ liệu ngang hàng và đơn giản. Mô hình này không thể biểu diễn được dữ
liệu phân cấp, một trong những đặc điểm cơ bản của hầu hết các cơ sở dữ liệu ứng
dụng hiện nay. Mô hình thực thể kết hợp mở rộng là sự lựa chọn cần thiết, giúp
giải quyết các vấn đề mà mô hình thực thể kết hợp (cổ điển) không thể giải quyết.
3.2 CÁC KHÁI NIỆM TRONG MÔ HÌNH THỰC

THỂ KẾT HỢP MỞ RỘNG
Để khắc phục những hạn chế nói trên của mô hình thực thể kết hợp, hay nói cách
khác để cải tiến mô hình thực thể kết hợp nhằm mở rộng lớp bài toán được giải
quyết bởi mô hình này, người ta xây dựng mô hình thực thể kết hợp mở rộng.
Đúng như tên gọi, mô hình mới này được phát triển từ mô hình thực thể kết hợp
với sự mở rộng thêm một số khái niệm: lớp con, lớp cha, khái quát hóa, chuyên
biệt hóa, và sự kế thừa.
3.2.1 Lớp con, lớp cha và sự kế thừa
Một trong những khái niệm quan trọng nhất của mô hình thực thể kết hợp mở rộng
đó là khái niệm về lớp con của một tập thực thể. Như chúng ta đã định nghĩa ở
chương trước, tập thực thể là một tập hợp các thực thể được xác định bởi các
thuộc tính giống nhau được lưu trữ trong cơ sở dữ liệu. Trong nhiều trường hợp,
một tập thực thể có thể được phân chia làm nhiều nhóm thực thể khác nhau, từng
thành viên trong mỗi nhóm đều thuộc tập thực thể ban đầu. Sự phân nhóm này dựa
trên một số đặc trưng nào đó, và cần được biểu diễn một cách tường minh. Người
ta gọi mỗi nhóm được phân tách là lớp con, còn tập thực thể ban đầu được gọi là
lớp cha trong phép phân nhóm nói trên. Mối liên kết từ lớp cha đến từng lớp con
được gọi là mối liên kết lớp cha/lớp con hay gọi tắt là liên kết cha/con. Loại liên
kết này còn có tên gọi khác là liên kết ISA (is a part of).
VÍ DỤ 3.1: Liên kết cha/con trong mô hình thực thể kết hợp mở rộng.
Các thực thể trong tập thực thể EMPLOYEE được trình bày trong cơ sở dữ liệu
COMPANY có thể được phân biệt thành nhiều nhóm khác nhau dựa vào đặc thù
của công việc được giao, như là ENGINEER (kỹ sư), SECRETARY (thư ký), và
DRIVER (lái xe). Trong trường hợp này EMPLOYEE gọi là lớp cha, còn các tập
thể ENGINEER, SECRETARY và DRIVER có chung tên gọi là lớp con trong
phép phân nhóm dựa trên đặc thù công việc được giao. Trong ví dụ này, chúng ta
có ba mối liên kết cha/con giữa EMPLOYEE và ENGINEER, giữa
EMPLOYEE và SECRETARY, giữa EMPLOYEE và DRIVER.
Hình 3.1. Các mối liên kết cha/con trong CSDL COMPANY

Một điều quan trọng mà chúng ta cần phải ghi nhớ là trong mối liên kết cha con,
mỗi thực thể của lớp con biểu diễn cùng một sự vật trong thế giới thực với một
thực thể nào đó của lớp cha. Nếu trong lớp con ENGINEER có một thực thể với
giá trị tại thuộc tính EName là ‘Lê Duy Anh’, thì trong lớp cha EMPLOYEE cũng
có một thực thể có giá trị tương tự tại thuộc tính EName. Vì vậy, mỗi thực thể của
lớp con là một thực thể trong lớp cha, nhưng với một vai trò đặc biệt. Nói cách
khác, vai trò đặc biệt này chính là đặc trưng được dùng để phân chia các thực thể
của lớp cha thành nhiều lớp con. Ngoài ra, một thực thể của lớp cha, có thể xuất
hiện trong nhiều lớp con hoặc không thuộc lớp con nào cả, nhưng một thực thể
xuất hiện trong lớp con, thì chắc chắn phải một thành viên của lớp cha.
VÍ DỤ 3.2: Mối liên kết cha/con trong mô hình thực thể kết hợp mở rộng.
Chúng ta có một kỹ sư nhưng đang làm công tác văn phòng. Do đó, nhân viên này
là một thực thể của EMPLOYEE, và đồng thời cũng thuộc cả SECRETARY lẫn
ENGINEER. Ngược lại, nếu một người được xem là nhân viên lái xe trong công
ty (thuộc DRIVER) thì chắc chắn anh ta phải là nhân viên của công ty (tức là một
thành viên của EMPLOYEE).

Một khái niệm quan trọng khác có liên quan tới mối liên kết cha/con đó là sự kế
thừa. Chúng ta đã biết một tập thực thể được xác định bởi các thuộc tính và các
mối liên kết mà nó tham gia trong đó. Bởi vì mỗi thực thể trong lớp con biểu diễn
cùng một sự việc trong thế giới thực với một thực thể nào đó của lớp cha, cho nên
chúng sẽ có cùng giá trị tại các thuộc tính của mình. Chúng ta nói rằng, các thực
thể trong lớp con kế thừa tất cả các thuộc tính của lớp cha và các kiểu liên kết mà
lớp cha tham gia trong đó. Ngoài các thuộc tính và các kiểu liên kết được kế thừa
từ lớp cha, bản thân lớp con cũng có các thuộc tính và các kiểu liên kết riêng mà
lớp cha không có. Như vậy, lớp con với các thuộc tính và các kiểu liên kết mà nó
tham gia trong đó cũng có thể được xem là một tập thực thể.
VÍ DỤ 3.3: Các lớp con có thể có thuộc tính riêng.
Các lớp con trong mối liên kết cha/con với lớp cha EMPLOYEE có thể có các
thuộc tính và các kiểu liên kết riêng. Chẳng hạn như, lớp con SECRETARY có
thuộc tính riêng là TypingSpeed (tốc độ đánh máy), lớp con ENGINEER có thuộc
tính riêng là EngType (lĩnh vực chuyên môn), hoặc lớp DRIVER cũng có thuộc
tính riêng là Vehicle (loại xe). Các thuộc tính này được thể hiện trong hình sau
đây.
Hình 3.2. Bên cạnh các thuộc tính được kế thừa từ lớp cha,
lớp con còn có thể có các thuộc tính riêng

3.2.2 Chuyên biệt hóa
Với định nghĩa về mối liên kết cha/con như ở trên, chúng ta có thể dễ dàng nhận
thấy có hai quá trình liên quan đến mối liên kết này: quá trình chuyên biệt hóa và
quá trình khái quát hóa.
Chuyên biệt hóa là quá trình xác định một tập các lớp con của một tập thực thể.
Tập thực thể đang xét được gọi là lớp cha của quá trình này. Tập các lớp con được
hình thành trong quá trình chuyên biệt hóa được định nghĩa dựa trên một số đặc
điểm phân biệt giữa thực thể này với thực thể khác trong lớp cha.
VÍ DỤ 3.4: Chuyên biệt hóa dựa trên thuộc tính.
Quá trình chuyên biệt hóa lớp cha EMPLOYEE thành nhiều lớp con
ENGINEER, SECRETARY, DRIVER dựa vào đặc thù của công việc được
giao. Chúng ta đặt tên cho thuộc tính này JobType. Một sự chuyên biệt hóa khác
có thể thực hiện trên lớp cha EMPLOYEE thành nhiều lớp con FULLTIME
(làm việc toàn thời gian), EXPERIENCED (có kinh nghiệm), và
QUALIFICATION (có bằng cấp). Hình sau đây minh họa chi tiết hai phép
chuyên biệt hóa của tập thực thể EMPLOYEE.
Hình 3.3. Chuyên biệt hóa lớp cha thành nhiều lớn con

Bây giờ chúng ta hãy xét một mối liên kết cha/con giữa hai tập thực thể P (viết tắt
của Parent, tức là cha) và C (viết tắt của Children, tức là con). Rõ ràng, với mỗi
thực thể xuất hiện trong C, thì phải có một thực thể tương ứng trong P, sao cho
chúng cùng phản ánh một sự vật trong thế giới thực. Ngược lại, cứ mỗi thực thể
trong P, chúng ta hoặc tìm thấy một, hoặc không tìm thấy thực thể nào trong C để
chúng cùng phản ánh một sự vật trong thế giới thực. Rõ ràng, đây có thể xem như
là một kiểu liên kết hai ngôi một – một giữa hai tập thực thể P và C. Có điều khác
biệt duy nhất, với kiểu liên kết hai ngôi một – một trong mô hình thực thể kết hợp
được trình bày ở chương trước, hai thực thể tham gia trong liên kết về cơ bản là
hai thực thể khác nhau, phản ánh hai sự vật khác nhau trong thế giới thực, còn
trong kiểu liên kết cha/con, hai thực thể tham gia cùng phản ánh một sự vật trong
thế giới thực.
Cùng với sự tương đồng nói trên, hai nguyên nhân sau đây lý giải tại sao người ta
lại đưa khái niệm về mối liên kết cha/con và các quá trình chuyên biệt hóa/khái
quát hóa vào trong mô hình dữ liệu:
Lớp con có thể có các thuộc tính riêng mà lớp cha không có. Khi đó lớp
con sẽ được tạo ra để nhóm các thực thể có chung những thuộc tính này lại
với nhau. Thành viên của lớp con này vẫn tiếp tục chia sẻ với các thành
viên của lớp con khác những thuộc tính của lớp cha.
Lớp con có thể có các kiểu liên kết riêng mà lớp cha không có. Thành viên
của lớp con vẫn kế thừa các kiểu liên kết có liên quan tới lớp cha.
Như vậy, quá trình chuyên biệt hóa cần trải qua các giai đoạn sau đây:
1) Định nghĩa một tập các lớp con của một tập thực thể.
2) Xác định các thuộc tính riêng của lớp con.
3) Xác định các kiểu liên kết riêng của lớp con với các tập thực thể khác hoặc
với các lớp con khác.
3.2.3 Khái quát hóa

Ngược lại với chuyên biệt hóa, từ một lớp cha xác định các lớp con dựa trên một
số thuộc tính phân loại, khái quát hóa là quá trình xây dựng một tập thực thể mới
dựa trên kết quả phân tích đặc điểm giống và khác nhau của một số tập thực thể.
Các tập thực thể tham gia quá trình khái quát hóa được gọi là các lớp con, còn tập
thực thể mới được tạo ra có tên gọi là lớp cha. Đây cũng là một mối liên kết
cha/con giữa các tập thực thể với nhau.
VÍ DỤ 3.5: Khái quát hóa dựa trên các thuộc tính dùng chung.
Quá trình khái quát hóa các tập thực thể ENGINEER, SECRETARY, DRIVER
để phát hiện những thuộc tính chung của chúng. Các thuộc tính chung này lần lượt
là ESSN, EName, ESex, ESalary, EBirthdate, và EStartdate. Để không lặp lại các
thuộc này tính, chúng ta tạo một tập thực thể có tên gọi là EMPLOYEE với các
thuộc tính nêu trên. Các tập thực thể ban đầu sẽ có mối liên kết cha/con với
EMPLOYEE để kế thừa các thuộc tính của nó.

3.2.4 Ràng buộc trong chuyên biệt hóa và khái quát hóa
Nhìn chung, chúng ta có thể áp dụng nhiều phép chuyên biệt hóa khác nhau lên
cùng một tập thực thể. Ví dụ 3.3 trên đây minh họa cho hai phép chuyên biệt hóa
lên cùng tập thể EMPLOYEE.
Với định nghĩa về chuyên biệt hóa, chúng ta thấy rằng một thực thể bất kỳ trong
lớp cha có thể thuộc về nhiều lớp con khác nhau trong mỗi phép chuyên biệt hóa.
Số lượng các lớp con được tạo ra phụ thuộc vào đặc điểm của phép chuyên biệt
hóa được áp dụng. Số lớp con do một phép chuyên biệt hóa tạo ra có thể là một
hay nhiều hơn một. Đồng thời, để có thể xác định chính xác một thực thể nằm
trong một lớp con nào đó, chúng ta có thể sử dụng một điều kiện phân nhóm dựa
trên giá trị của một số thuộc tính trong lớp cha. Các lớp con được xác định như thế
này được gọi là lớp con định nghĩa trước. Nếu tất cả các lớp con đều có điều kiện
phân nhóm trên cùng một thuộc tính, thì phép chuyên biệt hóa được gọi là được
định nghĩa theo thuộc tính, và thuộc tính đó có tên gọi là thuộc tính phân nhóm. Ví
dụ sau đây là một phép chuyên biệt hóa theo thuộc tính.
VÍ DỤ 3.6: Chuyên biệt hóa theo thuộc tính.

Với thuộc tính JobType trong tập thực thể EMPLOYEE, chúng ta có thể xác định
ba lớp con dựa trên điều kiện liên quan đến thuộc tính này, mà cụ thể là ba giá trị
‘Secretary’, ‘Driver, và ‘Engineer’. Điều kiện này nói rằng, nếu một thực thể
trong EMPLOYEE mà có giá trị tại JobType là ‘Secretary’ thì nó sẽ thuộc lớp
con SECRETARY. Tương tự như vậy đối với hai giá trị ‘Driver và ‘Engineer’.
Hình 3.4. Chuyên biệt hóa lớp EMPLOYEE theo thuộc tính JobType.

Khi không có điều kiện phân nhóm, lớp con là do người dùng tự định nghĩa.
Người dùng xác định các thành viên của lớp con bằng cách thêm lần lượt từng
thực thể của lớp cha vào một hoặc một số lớp con nào đó. Quá trình này diễn ra
cho đến khi các lớp con được xây dựng xong mới thôi.
Quan sát ví dụ 3.6, chúng ta có thể nhận thấy rằng, một thực thể trong lớp cha
EMPLOYEE không thể xuất hiện trong nhiều hơn một lớp con. Điều này có
nghĩa là, trong phép chuyên biệt hóa dựa trên một thuộc tính đơn trị, các lớp con
luôn không trùng lắp, hay luôn không có phần tử chung. Người ta đặt tên cho loại
ràng buộc này là ràng buộc không trùng lắp (ký hiệu là d, viết tắt của disjoint)
trong phép chuyên biệt hóa. Trong trường hợp phép chuyên biệt hóa không duy trì
ràng buộc không trùng lắp, một thực thể trong lớp cha có thể xuất hiện trong nhiều
lớp con. Nói cách khác, các lớp con có thể trùng lắp. Chúng ta ký hiệu phép
chuyên biệt hóa được phép trùng lắp là o (viết tắt của overlap).
Loại ràng buộc cuối cùng được định nghĩa trong phép chuyên biệt hóa, đó là ràng
buộc đầy đủ. Ràng buộc này giúp chúng ta phân biệt phép chuyên biệt hóa là toàn
phần hay một phần. Ràng buộc toàn phần phát biểu rằng mọi thực thể của lớp cha
phải là thành viên của ít nhất một lớp con. Trong khi đó, ràng buộc từng phần lại
cho biết một thực thể của lớp cha có thể không nằm trong bất kỳ lớp con nào cả.
Ví dụ 3.7 giúp chúng ta thể hiện đồng thời hai loại ràng buộc này trên mô hình
thực thể kết hợp.
VÍ DỤ 3.7: Ràng buộc toàn phần và ràng buộc từng phần.

Nếu như tồn tại một thực thể thuộc EMPLOYEE mà không thuộc bất kỳ lớp con
SECRETARY, DRIVER, và ENGINEER, thì chúng ta gọi phép chuyên biệt hóa
tương ứng là từng phần. Còn trong trường hợp mỗi thực thể thuộc EMPLOYEE
bắt buộc phải thuộc ít nhất một trong ba lớp con FULLTIME (nhân viên toàn thời
gian), EXPERIENCED (có kinh nghiệm thực tế), QUALIFICATION (có bằng
cấp chuyên môn), thì phép chuyên hóa này gọi là toàn phần.
Hình 3.5. Ràng buộc trong chuyên biệt hóa và khái quát hóa

Một điểm cần lưu ý là ràng buộc không trùng lắp và ràng buộc đầy đủ là hai ràng
buộc hoàn toàn độc lập. Vì vậy, mỗi phép chuyên biệt hóa sẽ thuộc một trong bốn
trường hợp sau đây:
Ràng buộc không trùng lắp và toàn phần
Ràng buộc không trùng lắp và từng phần
Ràng buộc có thể trùng lắp và toàn phần
Ràng buộc có thể trùng lắp và từng phần
Từ các ràng buộc nêu trên, chúng ta có thể suy ra một số quy tắc áp dụng cho
trường hợp thêm và loại bỏ thực thể ra khỏi lớp cha, lớp con:
Xóa một thực thể ở lớp cha dẫn tới việc thực thể này sẽ tự động bị xóa ra
khỏi tất cả các lớp con (mà nó là thành viên).
Thêm một thực thể vào lớp cha dẫn tới việc thực thể này sẽ tự động được
thêm vào các lớp con mà nó thỏa mãn điều kiện thành viên (đối với phép
chuyên biệt hóa theo thuộc tính).
Thêm một thực thể vào lớp cha trong phép chuyên biệt hóa toàn phần dẫn
đến việc thực thể này sẽ tự động được thêm vào ít nhất một lớp con trong
phép chuyên biệt hóa đang xét.
3.2.5 Cây phân cấp và lưới phân cấp

Như đã trình bày ở phần trước, bản chất của quá trình chuyên biệt hóa và khái quát
hóa và sự kế thừa. Trong khái niệm về sự kế thừa, chúng ta phân biệt đơn thừa kế
và đa thừa kế. Một lớp cha có thể có nhiều lớp con, và một lớp con cũng có thể có
nhiều lớp cha. Từ đó, chúng ta có thể tạo ra cây phân cấp (đơn thừa kế), hay lưới
phân cấp (đa thừa kế).
Một cách tương tự, vì mối liên kết cha/con trong mỗi phép chuyên biệt hóa là một
dạng liên kết cha/con trong phép kế thừa, cho nên chúng ta cũng có thể dùng cây
phân cấp hay lưới phân cấp để thể hiện mối liên kết cha/con trong các phép
chuyên biệt hóa trên cùng một tập các thực thể khác nhau. Sự phân cấp thể hiện
trong trường hợp này có ý nghĩa như sau: một lớp con trong phép chuyên biệt hóa
này có thể là lớp cha của phép chuyên biệt hóa khác. Ví dụ 3.8 minh họa lưới phân
cấp đối với tập thực thể EMPLOYEE.
VÍ DỤ 3.8: Cây phân cấp và lưới phân cấp.

Từ ví dụ 3.7 chúng ta định nghĩa một lớp KEY_MAN với điều kiện một thực thể
thuộc lớp này phải đồng thời là thành viên của hai lớp ENGINEER và
FULLTIME với ý nghĩa: kỹ sư chính phải là một kỹ sư ký hợp đồng làm việc
toàn thời gian với công ty.
Hình 3.6. Lưới phân cấp đối với tập thực thể EMPLOYEE

Để biểu diễn sự kế thừa bằng cây phân cấp hay lưới phân cấp, chúng ta cần chú ý
các đặc điểm sau đây. Các đặc điểm này được áp dụng với cả chuyên biệt hóa lẫn
khái quát hóa.
Trong cây hay lưới phân cấp, lớp con không chỉ thừa kế tất cả các thuộc
tính của lớp cha trực tiếp của nó mà còn thừa kế tất cả lớp cha khác cao hơn
(duyệt theo nhánh từ nó lên đến gốc).
Một thực thể có thể là thành viên của nhiều nút lá trong cây phân cấp. Ở
đây chúng ta định nghĩa nút lá là lớp không có lớp con.
Một lớp con có nhiều hơn một lớp cha được gọi là nút con chung. Khi đó,
lớp con chung sẽ thừa kế tất cả thuộc tính từ các lớp cha của nó.
Xét trường hợp lớp con chung được kế thừa từ nhiều lớp cha, các lớp cha
này lại là lớp con của một lớp cha khác. Các thuộc tính của lớp cha khác
này chỉ được xuất hiện duy nhất một lần trong lớp con chung.
3.3 MỘT ỨNG DỤNG CỦA MÔ HÌNH THỰC THỂ
KẾT HỢP MỞ RỘNG
Để minh họa việc ứng dụng mô hình thực thể kết hợp mở rộng để giải quyết bài
toán thực tế, chúng ta tiếp tục ví dụ mẫu được trình bày ở mục 2.2 với một số bổ
sung như sau:
Các nhân viên trong công ty được chia làm ba nhóm phân biệt, dựa trên đặc
điểm công việc mà họ thực hiện tại công ty: kỹ sư, thư ký, và nhân viên
phục vụ.
Công ty áp dụng một số chỉ tiêu để đánh giá nhân viên: thời gian làm việc,
kinh nghiệm thực tế, và bằng cấp chuyên môn.
Công ty thực hiện chế độ bảo hiểm y tế đối với người thân của các kỹ sư
làm việc toàn thời gian tại công ty.
Với những sự bổ sung nói trên, chúng ta có thể cải tiến lại mô hình được trình bày
trong hình 2.4 thành mô hình thực thể kết hợp mở rộng sau đây:
Hình 3.6. Mô hình thực thể kết hợp mở rộng của cơ sở dữ liệu COMPANY

3.4 CÁC CÔNG CỤ THIẾT KẾ MÔ HÌNH CƠ SỞ
DỮ LIỆU
Thiết kế mô hình cơ sở dữ liệu giữ vai trò quan trọng trong việc quản lý và khai
thác dữ liệu sau khi cơ sở dữ liệu đã được triển khai. Nhằm hỗ trợ người sử dụng
trong việc thiết kế cơ sở dữ liệu, đặc biệt là ở mức độ ý niệm như mô hình thực thể
kết hợp (mở rộng), một số công ty phần mềm đã được ra các sản phẩm thương mại
lẫn phi thương mại. Một số sản phẩm tiêu biểu trong lĩnh vực này: StarUML, Jude,
Rational Rose, Altova, Visio, … Các sản phẩm này có một đặc điểm chung là
được xây dựng trên ngôn ngữ mô hình hóa hợp nhất (Unified Modelling
Languages, viết tắt là UML). Trong phạm vi giáo trình, chúng ta không nghiên
cứu chi tiết về UML và các ứng dụng của nó trong lĩnh vực công nghệ phần mềm.
Chúng ta chỉ giới hạn nội dung trình bày ở việc ứng dụng UML để mô hình hóa
kiến trúc của cơ sở dữ liệu.
Thành phần cơ bản của UML là lớp với các khai báo về các trạng thái và hành vi
mà đối tượng của lớp đó được phép thực hiện. Chính vì lý do này mà UML được
sử dụng làm ngôn ngữ chính trong các hoạt động phân tích và thiết kế các hệ
thống thông tin hướng đối tượng. Lớp trong UML tương ứng với tập thực thể
trong mô hình thực thể kết hợp. Các thuộc tính của tập thực thể được xem như là
thuộc tính của lớp tương ứng trong UML.
Liên kết trong UML được xác định giữa hai lớp, tương ứng với một kiểu liên kết
hai ngôi giữa hai tập thực thể trong mô hình thực thể kết hợp. Đặc biệt, UML
không cho phép liên kết nhiều ngôi. Đó cũng chính là lý do tại sao trong chương 2,
chúng ta đã tìm cách phân tách kiểu liên kết nhiều ngôi thành nhiều kiểu liên kết
hai ngôi.
Hình 3.7. Lược đồ UML ứng với mô hình thực thể kết hợp của
cơ sở dữ liệu COMPANY được trình bày trong hình 2.4
Cuối cùng, UML hỗ trợ cấu trúc phân cấp bằng các mối liên kết cha/con tương tự
như đối với sự chuyên biệt hóa và khái quát trong mô hình thực thể kết hợp mở
rộng.
Hình 3.8. Lược đồ UML ứng với cây phân cấp được trình bày trong ví dụ 3.8
3.5 TÓM TẮT
Để có được một bản thiết kế cơ sở dữ liệu tốt, phản ánh đúng thế giới thực mà nó
cần thể hiện, nhân viên thiết kế cần phải được cung cấp một phương pháp luận
đúng đắn. Trong nhiều trường hợp mô hình thực thể kết hợp là một phương pháp
luận như thế. Tuy nhiên, với tính phức tạp ngày càng cao của các hệ thống thông
tin, có một số yêu cầu về cấu trúc dữ liệu mà mô hình này không thể đáp ứng
được.
Mô hình thực thể kết hợp mở rộng theo đúng tên gọi của nó là một sự mở rộng của
mô hình thực thể kết hợp với các khái niệm về chuyên biệt hóa, khái quát hóa, hai
thể hiện chính của sự kế thừa trong hướng đối tượng của một hệ thống thông tin.
Chuyên biệt hóa được xem như là quá trình phân tách các lớp con từ một lớp cha.
Việc phân tách có thể dựa trên giá trị của một (số) thuộc tính phân nhóm, hoặc do
người dùng tự định nghĩa. Một số ràng buộc khác liên quan đến quá trình chuyên
biệt hóa bao gồm: ràng buộc không trùng lắp và ràng buộc đầy đủ (ràng buộc toàn
phần). Ràng buộc không trùng lắp nói rằng một thực thể thuộc lớp cha chỉ có thể
thuộc nhiều nhất một lớp con của phép chuyên biệt hóa. Trong khi đó, ràng buộc
toàn phần đảm bảo mọi thực thể thuộc lớp cha phải thuộc ít nhất một lớp con của
phép chuyên biệt hóa.
Trên thị trường hiện nay có rất nhiều sản phẩm mô hình hóa cơ sở dữ liệu, đa số
các sản phẩm này đều được xây dựng trên ngôn ngữ mô hình hóa hợp nhất UML.
Do đó, trong phần cuối chương này, chúng tôi giới thiệu một phép biến đổi đơn
giản từ mô hình thực thể kết hợp (mở rộng) sang ngôn ngữ UML. Để tìm hiểu chi
tiết hơn về UML, đọc giả có thể xem thêm các tài liệu tham khảo ở cuối giáo trình
này.
C
CHHƯ
ƯƠƠN
NGG
4
MÔ HÌNH DỮ LIỆU QUAN HỆ
Mục tiêu
Chương này tập trung nghiên cứu mô hình dữ liệu quan hệ ở ba khía cạnh: tổ chức
dữ liệu quan hệ, các thao tác trên dữ liệu quan hệ, và ràng buộc toàn vẹn trên dữ
liệu quan hệ. Từ đó, người đọc được trang bị các kiến thức nền tảng về mô hình dữ
liệu được sử dụng phổ biến nhất hiện nay.
Nội dung
Các khái niệm cơ bản.
Ràng buộc toàn vẹn trên mô hình dữ liệu quan hệ.
Các toán tử cập nhật trên quan hệ.
Giới thiệu
Lịch sử hình thành và phát triển của các hệ cơ sở dữ liệu đã bước sang trang mới
kể từ khi Ted Codd công bố công trình nghiên cứu của mình vào năm 1970. Theo
Codd, để phát huy tối đa khả năng sáng tạo của người sử dụng, các hệ cơ sở dữ
liệu nên cung cấp cho họ một cái nhìn đơn giản, dễ hiểu về dữ liệu mà họ có nhu
cầu. Codd đề xuất sử dụng bảng dữ liệu hai chiều – với tên gọi là quan hệ – để mô
tả dữ liệu trong các hệ cơ sở dữ liệu. Việc mô tả này sẽ làm cho hệ cơ sở dữ liệu
trở nên phức tạp hơn, thậm chí, bản thân các yêu cầu xử lý dữ liệu cũng trở nên rắc
rối hơn. Tuy nhiên, đối với người sử dụng, họ không cần quan tâm tới việc dữ liệu
được lưu trữ như thế nào trong bộ nhớ, họ cũng không cần biết yêu cầu của họ
được thực thi ra sao; họ chỉ quan tâm tới việc làm sao xây dựng được các câu truy
vấn, và chúng cho ra kết quả đúng như họ mong muốn mà thôi. Do vậy, với đề
xuất của Codd, các câu truy vấn trở nên rất đơn giản, có thể được biểu diễn ở mức
trừu tượng cao, và gần gũi với người sử dụng. Trên nền tảng ứng dụng quan hệ
trong việc xây dựng hệ cơ sở dữ liệu, ngôn ngữ mô tả truy vấn mới được ra đời, đó
chính là ngôn ngữ truy vấn có cấu trúc SQL.
Các sản phẩm thương mại đầu tiên của mô hình dữ liệu quan hệ được công bố đầu
những năm 1980, với hai sản phẩm tiêu biểu là Oracle DBMS và hệ thống
SQL/DS trên hệ điều hành MVS của IBM. Từ đó đến nay, trên thị trường xuất
hiện nhiều hệ quản trị cơ sở dữ liệu có tên tuổi ứng dụng mô hình dữ liệu này, tiêu
biểu như là DB2 và Informix Dynamic Server (của IBM), Oracle và RBD (của
Oracle), SQLServer và Access (của Microsoft), …
Đã gần nửa thế kỷ từ khi khái niệm mô hình dữ liệu quan hệ ra đời, mô hình này
vẫn giữ vai trò chủ đạo, vẫn là nền tảng cho hầu hết các hệ cơ sở dữ liệu đang tồn
tại trên thị trường. Chính vì vậy, mô hình dữ liệu quan hệ là nội dung bắt buộc đối
với mọi sinh viên theo học các chương trình đào tạo về công nghệ thông tin, và hệ
thống thông tin.
4.1 CÁC KHÁI NIỆM CƠ BẢN
Mô hình quan hệ biểu diễn cơ sở dữ liệu như là tập hợp các quan hệ, mỗi quan hệ
có thể được coi là một bảng dữ liệu hai chiều gồm nhiều cột và nhiều hàng. Mỗi
hàng trong bảng (trừ hàng tiêu đề) biểu diễn một sự vật tương ứng với một thực
thể hoặc một liên kết trong thế giới thực. Tên bảng và tên các cột (tức hàng tiêu
đề) được dùng để diễn giải ý nghĩa của các giá trị tại mỗi hàng. Tất cả giá trị trong
cùng một cột (ngoại trừ tiêu đề cột) có cùng kiểu dữ liệu. Để bắt đầu với mô hình
dữ liệu quan hệ, chúng ta lần lượt tìm hiểu các khái niệm cơ bản của mô hình này.
4.1.1 Các khái niệm

4.1.1.1 Lược đồ quan hệ
Lược đồ quan hệ R, thường được ký hiệu là R(A1,A2,…,An), trong đó R là tên quan

hệ và A1,A2,…,An là danh sách các thuộc tính. Lược đồ quan hệ được dùng để mô
tả quan hệ, và R được gọi là tên của quan hệ được mô tả. Bậc của quan hệ là số
lượng các thuộc tính có trong lược đồ quan hệ.
VÍ DỤ 4.1: Lược đồ quan hệ EMPLOYEE.

Xét quan hệ EMPLOYEE có lược đồ như sau:
EMPLOYEE (ESSN, EName, ESalary, ESex, EBirthdate, EStartdate,
DNum, supervisorSSN)
Quan hệ này có tên là EMPLOYEE gồm tám thuộc tính, chứa thông tin về nhân
viên trong công ty.

4.1.1.2 Thuộc tính và miền giá trị của thuộc tính
Mỗi thuộc tính là một tính chất riêng biệt của đối tượng cần được lưu trữ trong cơ
sở dữ liệu. Các thuộc tính được xác định bởi một tên gọi, kiểu giá trị và miền giá
trị của chúng. Mỗi thuộc tính đều phải thuộc một kiểu dữ liệu cơ bản nào đó. Kiểu
dữ liệu có thể là vô hướng (String, Text, Character, Number, Logical, …) hoặc các
kiểu dữ liệu có cấu trúc được định nghĩa dựa trên các kiểu dữ liệu đã có sẵn. Mỗi
thuộc tính chỉ có thể nhận những giá trị trong một tập con của kiểu dữ liệu. Tập
hợp các giá trị mà thuộc tính A có thể nhận được gọi là miền giá trị của thuộc tính
A, và được ký hiệu là dom(A).
VÍ DỤ 4.2: Miền giá trị của thuộc tính.

Mỗi thuộc tính trong quan hệ EMPLOYEE (ví dụ 4.1) có tên riêng, thể hiện ý
nghĩa thông tin được thuộc tính lưu trữ và có miền giá trị riêng. Do đó lược đồ
quan hệ EMPLOYEE có thể được viết lại như sau:
EMPLOYEE (ESSN:int, EName:string, ESalary:int, ESex:int,
EBirthdate:date, EStartdate:date, DNum:int,supervisorSSN:int)

4.1.1.3 Bộ
Các hàng trong quan hệ, ngoại trừ hàng tiêu đề chứa tên các thuộc tính, được gọi
là các bộ của quan hệ. Mỗi thành phần trong bộ chứa giá trị tương ứng với từng
thuộc tính của quan hệ.
4.1.1.4 Thể hiện quan hệ
Thể hiện quan hệ tại một thời điểm bao gồm một số hữu hạn các bộ biểu diễn
trạng thái cụ thể của thế giới thực, và khi trạng thái của thế giới thực thay đổi, thể
hiện quan hệ cũng thay đổi theo, và trở thành một thể hiện quan hệ mới. Nói cách
khác, thể hiện của quan hệ luôn luôn biến đổi. Trong khi đó, lược đồ quan hệ R rất
ít khi bị thay đổi, ngoại trừ những trường hợp đặc biệt – ví dụ như khi chúng ta
cần thêm thuộc tính mới để thể hiện một thông tin mới chưa có trong quan hệ.
Việc thay đổi lược đồ quan hệ có thể phát sinh nhiều vấn đề, bởi vì chúng ta cần
phải thay đổi tất cả các bộ hiện có trong quan hệ.
VÍ DỤ 4.3: Thể hiện của quan hệ EMPLOYEE.

Hình 4.1 minh họa một thể hiện của quan hệ EMPLOYEE. Mỗi bộ trong quan hệ
(mỗi hàng trong bảng) biểu diễn một thực thể nhân viên cụ thể. Chúng ta biểu diễn
quan hệ như là bảng, với mỗi bộ được biểu diễn như là một hàng, và mỗi thuộc
tính tương ứng với tiêu đề cột.
Hình 4.1. Một thể hiện của quan hệ EMPLOYEE

4.1.1.5 Lược đồ cơ sở dữ liệu quan hệ
Trong mô hình quan hệ, cơ sở dữ liệu bao gồm nhiều quan hệ. Tập hợp các lược
đồ quan hệ của cơ sở dữ liệu được gọi là lược đồ cơ sở dữ liệu, hay ngắn gọn là
lược đồ cơ sở dữ liệu.
4.1.1.6 Cơ sở dữ liệu mẫu
Hình 4.2 minh hoạ lược đồ cơ sở dữ liệu COMPANY với các lược đồ quan hệ
được mô tả chi tiết như sau:
DEPARTMENT
Quan hệ này lưu trữ thông tin về phòng ban trong công ty bao gồm mã số phòng
ban, tên phòng ban, mã số trưởng phòng ban và thời điểm được bổ nhiệm.
EMPLOYEE
Quan hệ lưu trữ thông tin về nhân viên trong công ty bao gồm mã số nhân viên, họ
tên, mức lương, giới tính. Mỗi nhân viên thuộc biên chế của một phòng ban, và
chịu sự giám sát chéo của một nhân viên khác.
DEPENDENT
Quan hệ lưu trữ thông tin về thân nhân của nhân viên trong công ty, bao gồm tên
thân nhân, mã số nhân viên tương ứng, giới tính, ngày sinh, và mối quan hệ gia
đình với nhân viên.
PROJECT
Quan hệ lưu trữ thông tin về dự án của công ty, bao gồm mã số dự án, tên dự án,
mã số địa điểm triển khai dự án, mã số phòng ban chịu trách nhiệm quản lý dự án.
DEPLOCATION
Quan hệ lưu trữ thông tin về địa điểm mà công ty có văn phòng đại diện, bao gồm
tên địa điểm, mã số phòng ban có văn phòng tại địa điểm này.
WORKSON
Quan hệ lưu trữ thông tin về thời gian làm việc của nhân viên trong từng dự án,
cho biết nhân viên này tham gia dự án nào với số giờ làm việc trong tuần là bao
nhiêu.
WORKSON EMPLOYEE DEPARTMENT

ESSN ESSN DNumber
PNum EName DName
workHours ESalary mgrSSN
ESex mgrStartdate
EBirthdate
EStartdate
PROJECT DNum
PNumber supervisorSSN
PName DEPLOCATION
PLocation DNum
DNum DLocation
DEPENDENT
DName
ESSN
DSex
DBirthdate
DRelationship
Hình 4.2. Lược đồ cơ sở dữ liệu COMPANY
4.1.2 Các đặc trưng của quan hệ

4.1.2.1 Thứ tự của các bộ trong quan hệ
Quan hệ được định nghĩa như là tập hợp gồm nhiều bộ. Do đó, giữa các bộ trong
một quan hệ không có bất kỳ thứ tự sắp xếp nào. Điều này có nghĩa là khi thay đổi
trật tự hiển thị của các bộ trong quan hệ, chúng ta nhận được một biểu diễn tương
đương với biểu diễn ban đầu của quan hệ.
VÍ DỤ 4.4: Hai thể hiện tương đương của một quan hệ.
Hình sau đây minh hoạ hai thể hiện của quan hệ EMPLOYEE. Hai thể hiện này
được coi là tương đương với nhau vì các bộ dữ liệu của chúng giống hệt nhau, chỉ
khác thứ tự xuất hiện mà thôi.
Hình 4.3. Hai thể hiện của quan hệ EMPLOYEE

4.1.2.2 Thứ tự của các giá trị bên trong một bộ
Theo định nghĩa về bộ trong quan hệ R có n thuộc tính, một bộ t của quan hệ R
phải có n–thành phần. Đây là danh sách có thứ tự của n giá trị. Điều này có nghĩa
là các giá trị trong một bộ – hay các thuộc tính trong một quan hệ – phải tuân theo
một trật tự nhất định. Do đó, nếu chúng ta thay đổi trật tự hiển thị các thuộc tính
trong quan hệ, chúng ta phải thay đổi trật tự hiển thị của các cột chứa dữ liệu ứng
với các thuộc tính đó. Trong trường hợp này, chúng ta cũng sẽ nhận được một biểu
diễn mới tương đương với biểu diễn ban đầu của quan hệ.
VÍ DỤ 4.5: Hai thể hiện tương đương của một quan hệ.
Hình sau đây minh họa hai thể hiện của quan hệ EMPLOYEE. Hai thể hiện này
được coi là tương đương với nhau vì các bộ dữ liệu của chúng giống hệt nhau, chỉ
khác thứ tự xuất hiện của các thuộc tính mà thôi.
Hình 4.4. Hai thể hiện của quan hệ EMPLOYEE

4.1.2.3 Các giá trị thuộc tính trong bộ
Mọi giá trị trong bộ đều phải là giá trị đơn, nghĩa là các giá trị này không thể phân
chia thành các thành phần nhỏ hơn mà vẫn đáp ứng được các nguyên tắc cơ bản
của mô hình quan hệ.
Khi biểu diễn các giá trị không biết, hoặc không được áp dụng trong bộ, chúng ta
sử dụng một giá trị đặc biệt, đó là giá trị null. Chúng ta có nhiều diễn giải cho các
giá trị null, ví dụ như là giá trị không biết, giá trị tồn tại nhưng không xác định,
hoặc là thuộc tính không áp dụng cho bộ này.
VÍ DỤ 4.6: Giá trị NULL trong quan hệ.

Xét bộ dữ liệu tương ứng với nhân viên có mã số 30121050004, bộ dữ liệu này có
sáu giá trị đơn khác NULL tương ứng với sáu thuộc tính của quan hệ
EMPLOYEE. Trong khi đó, bộ dữ liệu liên quan tới nhân viên có mã số
30121050037 có giá trị NULL ứng với thành phần supervisorSSN. Điều này có thể
giải thích như sau:
a) Đây là nhân viên không chịu sự giám sát của bất kỳ nhân viên nào khác
b) Đây là nhân viên mới, chưa được bố trí người giám sát
c) Không có cơ chế giám sát đối với nhân viên này

4.1.2.4 Quan hệ
Lược đồ quan hệ có thể được hiểu như là một khai báo của quan hệ. Một số quan
hệ được dùng để biểu diễn các định nghĩa về thực thể, một số khác lại định nghĩa
mối liên kết giữa các thực thể. Trong thực tế, người ta không phân biệt hai loại
quan hệ này, và cả hai được gọi chung bằng một cái tên: quan hệ.
VÍ DỤ 4.7: Các loại quan hệ.

Xét ba lược đồ quan hệ sau đây:
EMPLOYEE(ESSN, EName, ESalary, …, DNum, supervisorSSN)
PROJECT(PNumber, PName, PLocation, DNum)
WORKSON(ESSN, PNum, workHours)
Hai lược đồ đầu tiên được dùng để biểu diễn các định nghĩa về thực thể: thực thể
nhân viên và thực thể dự án. Lược đồ thứ ba được dùng để biểu diễn mối liên kết
giữa hai các thực thể nhân viên và dự án: nhân viên này tham gia dự án nào với số
giờ làm việc trong tuần là bao nhiêu.

4.1.3 Ký hiệu sử dụng trong mô hình quan hệ
Trong giáo trình này, chúng ta thống nhất sử dụng các quy ước sau đối với mô
hình quan hệ:
Lược đồ quan hệ R có bậc n được ký hiệu là R(A1,A2,…,An).
Bộ t có n thành phần trong quan hệ r(R) được ký hiệu là t = <v1,v2,…,vn>
với vi là giá trị ứng với thuộc tính Ai
• Giá trị vi ứng với thuộc tính Ai trong bộ t được ký hiệu là t[Ai], t.Ai hay
t[i].
• t[Au,Av,…,Az] và t.(Au,Av,…,Az), với Au,Av,…,Az là tập con các thuộc tính
trong R, biểu diễn tập các bộ con với các giá trị <vu,vv,…,vz> từ bộ t ứng
với các thuộc tính trong danh sách Au,Av,…,Az nói trên.
Các ký tự Q, R, S biểu diễn tên quan hệ.
Các ký tự q,r,s biểu diễn thể hiện quan hệ.
Các ký tự t,u,v biểu diễn bộ trong quan hệ.
4.2 RÀNG BUỘC TOÀN VẸN TRÊN MÔ HÌNH

QUAN HỆ
Cơ sở dữ liệu chứa đựng thông tin, phản ánh bản chất của thế giới thực. Những
điều kiện mà thể hiện cơ sở dữ liệu bắt buộc phải thoả mãn tại mọi thời điểm gọi
là ràng buộc. Các ràng buộc này xuất phát từ những quy luật của thế giới thực
được cơ sở dữ liệu thể hiện. Chúng ta sẽ tìm hiểu các kiểu ràng buộc toàn vẹn dựa
trên lược đồ, bao gồm: ràng buộc miền giá trị, ràng buộc khóa chính, ràng buộc
giá trị null, ràng buộc tham chiếu.
4.2.1 Ràng buộc miền giá trị

Ràng buộc miền giá trị yêu cầu trong mỗi bộ, giá trị ứng với mỗi thuộc tính A phải
là đơn trị và phải thuộc miền giá trị dom(A).
VÍ DỤ 4.8: Ràng buộc miền giá trị.

Vì giới tính của một nhân viên chỉ có thể là nam hoặc nữ, cho nên miền giá trị
dom(ESex)={‘M’, ‘F’}. Điều này có nghĩa là, trong quan hệ EMPLOYEE tồn tại
một ràng buộc miền giá trị đối với thuộc tính ESex, và mọi bộ trong quan hệ
EMPLOYEE phải có giá trị là M, F, hoặc là NULL tại thành phần ESex.

4.2.2 Ràng buộc khóa
Quan hệ được định nghĩa là tập hợp các bộ. Do tất cả các phần tử trong tập hợp là
duy nhất, vì thế các bộ trong quan hệ cũng là duy nhất, nói cách khác ∀t1,t2∈r(R),
t1[A1,…,An] ≠ t2[A1,…,An]. Thực tế, trong một quan hệ R, có nhiều tập con các
thuộc tính A’ ⊆ A thỏa mãn tính chất này. Chúng ta gọi một tập con các thuộc tính
SK của lược đồ quan hệ R là siêu khoá khi các bộ trong R là duy nhất đối với tất cả
các thuộc tính trong SK. Điều này có nghĩa là, với bất kỳ hai bộ khác nhau t1, t2
trong thể hiện quan hệ r của R, chúng ta có ràng buộc t1[SK] ≠ t2[SK].
Rõ ràng mọi quan hệ đều có ít nhất một siêu khóa – đó là tập hợp tất cả các thuộc
tính của quan hệ đó. Siêu khóa có thể có thuộc tính thừa, tức là nếu bỏ các thuộc
tính đó đi, tập hợp các thuộc tính còn lại vẫn thỏa mãn tính chất của một siêu
khóa. Từ đó chúng ta đưa ra khái niệm về khóa – siêu khóa không có thuộc tính dư
thừa.
Như vậy, nếu gọi tập hợp con các thuộc tính K là một khoá của quan hệ R, K cần
phải thoả mãn đồng thời hai điều kiện sau đây:
1) K là siêu khóa;
2) K là siêu khóa nhỏ nhất, tức là mọi tập con thực sự của K đều không thể là
siêu khóa.
Dễ dàng nhận thấy rằng, nếu siêu khoá gồm duy nhất một thuộc tính thì siêu khoá
đó đồng thời là khoá. Giá trị của thuộc tính khóa được dùng để xác định từng bộ
duy nhất trong quan hệ. Chính vì vậy khóa là đặc trưng của lược đồ quan hệ, nó là
ràng buộc được áp dụng cho mọi thể hiện của lược đồ quan hệ. Khóa được xác
định từ ý nghĩa của các thuộc tính và có tính bất biến theo thời gian: nó tiếp tục
được duy trì khi chúng ta thêm mới các bộ dữ liệu vào trong quan hệ.
VÍ DỤ 4.9: Ràng buộc khóa trong quan hệ.

Việc xác định khoá, siêu khoá chịu sự ảnh hưởng mạnh mẽ từ nhận định chủ quan
của người xây dựng cơ sở dữ liệu. Trong quan hệ EMPLOYEE, nếu chúng ta giả
định rằng (1) trong công ty không có hai nhân viên cùng mã số, thì {ESSN} là một
khoá của quan hệ EMPLOYEE. Tương tự, với giả định (2) trong công ty không
có hai nhân viên cùng tên, cùng giới tính, thì {EName, ESex} là một khoá khác
của quan hệ EMPLOYEE. Vấn đề phát sinh ở chỗ, sau một thời gian hoạt động,
công ty tuyển dụng thêm nhiều nhân viên khác, và không có gì đảm bảo trước rằng
các nhân viên không thể trùng tên và giới tính. Vì thế, giả định (2) có thể bị phá
sản bất cứ lúc nào.

Thông thường, một lược đồ quan hệ có thể có nhiều hơn một khóa. Trong trường
hợp này, chúng ta chọn một khoá làm khoá chính, các khóa còn lại được gọi là
khóa phụ.
4.2.3 Ràng buộc giá trị NULL

Một kiểu ràng buộc khác trên thuộc tính đó là ràng buộc cho phép hay không cho
phép thuộc tính có giá trị null. Trong trường hợp một thuộc tính A nào đó trong
quan hệ R thuộc thiết lập là NOT NULL, mọi bộ trong quan hệ R không được phép
có giá trị null tại thành phần tương ứng với thuộc tính A.
VÍ DỤ 4.10: Ràng buộc giá trị NULL.

Dễ dàng nhận thấy, để định danh nhân viên, đầu tiên cần phải biết tên nhân viên
đó. Thuộc tính tên của nhân viên chắc chắn không thể nhận giá trị NULL. Như
vậy, trong quan hệ EMPLOYEE có một ràng buộc giá trị NOT NULL đối với
thuộc tính EName. Điều tương tự có đúng với thuộc tính supervisorSSN không?
Trong công ty, có những nhân viên không chịu sự giám sát của bất kỳ nhân viên
nào khác, chẳng hạn như giám đốc công ty. Vì thế, có thể chấp nhận giá trị NULL
đối với thuộc tính supervisorSSN trong quan hệ EMPLOYEE.

4.2.4 Ràng buộc thực thể
Ràng buộc toàn vẹn thực thể phát biểu rằng nếu tập con các thuộc tính K được
khai báo là khoá chính của quan hệ R thì tồn tại đồng thời một ràng buộc giá trị
null đối với tập con các thuộc tính K đó. Ràng buộc này sở dĩ quan trọng vì giá trị
khóa chính được dùng để phân biệt các bộ dữ liệu trong quan hệ, nếu khóa chính
cho phép giá trị null, thì chúng ta không thể phân biệt một số bộ có cùng giá trị
null đối với thuộc tính khóa chính.
VÍ DỤ 4.11: Ràng buộc thực thể trong quan hệ.

Giả định rằng thuộc tính khoá chính ESSN của quan hệ EMPLOYEE cho phép
nhận giá trị NULL. Khi đó, trong quan hệ EMPLOYEE có thể có nhiều bộ có giá
trị cùng là NULL tại thuộc tính ESSN. Trong trường hợp này, ESSN không thể
được dùng để phân biệt các bộ trong quan hệ EMPLOYEE. Điều này mâu thuẫn
với chính khái niệm khoá chính được dùng để phân biệt các bộ khác nhau trong
quan hệ.

4.2.5 Ràng buộc toàn vẹn tham chiếu
Trong khi ràng buộc khóa và ràng buộc toàn vẹn thực thể được định nghĩa trên
từng quan hệ riêng lẻ, ràng buộc toàn vẹn tham chiếu được xác định giữa hai quan
hệ với ý nghĩa một giá trị muốn xuất hiện trong quan hệ này phải xuất hiện trong
một quan hệ khác có liên quan. Ràng buộc toàn vẹn tham chiếu hiểu một cách đơn
giản là nếu một bộ của quan hệ R muốn tham chiếu tới quan hệ S, thì phải tham
chiếu tới một bộ hiện có sẵn của quan hệ S. Lúc bấy giờ, R là quan hệ tham chiếu,
còn S là quan hệ được tham chiếu. Để tồn tại một ràng buộc toàn vẹn tham chiếu
từ tập thuộc tính A của R tới tập thuộc tính B của S, các điều kiện sau đây phải
thoả mãn:
1) Các thuộc tính trong A có cùng miền giá trị với các thuộc tính trong B
tương ứng
2) Các thuộc tính trong B phải là khoá chính hoặc khoá phụ của S
3) Giá trị tại A của một bộ trong R hoặc là null, hoặc là giá trị tại B của
một bộ nào đó trong S
Để xác định được ràng buộc toàn vẹn tham chiếu đầu tiên chúng ta phải hiểu rõ ý
nghĩa và vai trò của mỗi (tập) thuộc tính trong từng lược đồ quan hệ của cơ sở dữ
liệu. Ràng buộc toàn vẹn tham chiếu xuất phát từ mối liên hệ giữa các tập thực thể
thế giới thực được biểu diễn bởi cơ sở dữ liệu.
VÍ DỤ 4.12: Ràng buộc toàn vẹn tham chiếu.

Xét hai lược đồ quan hệ sau đây:
DEPARTMENT(DNumber, DName, mgrSSN, mgrStartdate)
PROJECT(PNumber, PName, PLocation, DNum)
Mỗi dự án ngoài mã số, tên, còn có thông tin cho biết địa điểm thực hiện dự án
(PLocation), và mã số của đơn vị quản lý dự án (DNum). Đơn vị quản lý dự án
phải là một đơn vị của công ty, có nghĩa là phải nằm trong quan hệ
DEPARTMENT. Do đó, thuộc tính DNum của quan hệ PROJECT tham chiếu
tới thuộc tính DNumber của quan hệ DEPARTMENT; tồn tại ràng buộc toàn vẹn
tham chiếu từ PROJECT tới DEPARTMENT.

4.2.6 Ràng buộc toàn vẹn ngữ nghĩa
Các ràng buộc chúng ta vừa kể trên không bao gồm một lớp các ràng buộc phổ
biến còn được gọi là ràng buộc toàn vẹn ngữ nghĩa. Đúng theo tên gọi của mình,
kiểu ràng buộc này đảm bảo thể hiện cơ sở dữ liệu tại mọi thời điểm phản ánh
đúng tình trạng thế giới thực. Phần lớn các ràng buộc kiểu này đều do chương
trình ứng dụng cơ sở dữ liệu thiết lập và quản lý. Ngoài ra, chúng ta cũng có thể
dùng cấu trúc TRIGGER hoặc ASSERTION trong SQL92 để định nghĩa một số
ràng buộc toàn vẹn ngữ nghĩa đơn giản.
VÍ DỤ 4.13: Ràng buộc toàn vẹn ngữ nghĩa.

Xét hai phát biểu sau đây:
1. Một nhân viên có thể tham gia nhiều dự án với lượng thời gian tham gia
khác nhau, nhưng tổng thời gian làm việc hàng tuần của anh ta không được
vượt quá 56 giờ.
2. Mức lương của trưởng phòng trong mọi trường hợp đều lớn hơn lương của
các nhân viên trong bộ phận mà người này phụ trách.
Hai phát biểu trên đây chính là hai ràng buộc toàn vẹn ngữ nghĩa.

4.2.7 Ràng buộc phụ thuộc hàm
Một dạng khác của ràng buộc được đề cập đến trong phần sau là ràng buộc phụ
thuộc hàm. Kiểu ràng buộc này được xây dựng trên mối quan hệ giữa hai tập thuộc
tính X và Y trong cùng một quan hệ R. Ràng buộc này cho biết nếu hai bộ bất kỳ
của quan hệ R có giá trị bằng nhau tại các thuộc tính X, thì cũng sẽ có giá trị bằng
nhau tại các thuộc tính Y, ký hiệu phụ thuộc hàm X → Y. Chúng ta sử dụng các
phụ thuộc hàm và các kiểu phụ thuộc khác trong chương 8, như là công cụ để đánh
giá hiệu quả thiết kế và để chuẩn hóa các quan hệ nhằm nâng cao chất lượng của
chúng.
4.3 CÁC TOÁN TỬ CẬP NHẬT TRÊN QUAN HỆ

Các toán tử xử lý trong mô hình quan hệ có thể gom vào hai nhóm: truy vấn và
cập nhật. Sau khi định nghĩa lược đồ cơ sở dữ liệu thông qua việc xây dựng các
lược đồ quan hệ, chúng ta cần phải thực hiện thao tác cập nhật dữ liệu vào cơ sở
hiện có. Trên nền tảng đó, chúng ta mới có thể thực hiện các câu truy vấn dữ liệu.
Ba toán tử cập nhật cơ bản trên cơ sở dữ liệu quan hệ bao gồm: thêm mới, xoá, và
sửa. Mỗi khi các toán tử này thực hiện, thể hiện cơ sở dữ liệu bị thay đổi. Do đó,
chúng ta cần phải đảm bảo rằng thể hiện mới của cơ sở dữ liệu không vi phạm các
ràng buộc toàn vẹn đã khai báo trên các lược đồ quan hệ tương ứng.
4.3.1 Toán tử Insert – thêm một (số) bộ mới vào quan hệ

Toán tử Insert được dùng để thêm mới một (số) bộ vào quan hệ R. Để thực hiện
điều này, chúng ta cần phải cung cấp một danh sách có thứ tự các giá trị tương ứng
với các thuộc tính trong quan hệ R. Do toán tử Insert làm thay đổi thể hiện quan
hệ, cho nên chúng có thể vi phạm cả bốn loại ràng buộc đã nêu ở phần trước. Cụ
thể như sau:
1) Ràng buộc toàn vẹn miền giá trị có thể bị vi phạm nếu giá trị của thuộc tính
được thêm vào không nằm trong miền giá trị của thuộc tính đó.
2) Ràng buộc toàn vẹn khóa bị vi phạm nếu giá trị thuộc tính khóa trong bộ t
mới đã xuất hiện trong một bộ nào đó của quan hệ R.
3) Ràng buộc toàn vẹn thực thể bị vi phạm nếu khóa chính của bộ t mới là
NULL.
4) Ràng buộc toàn vẹn tham chiếu bị vi phạm nếu quan hệ R không bộ nào có
giá trị khóa chính giống với giá trị khóa ngoại của bộ t mới.
VÍ DỤ 4.14: Ràng buộc toàn vẹn dữ liệu bị vi phạm khi thêm mới một thực
thể.
Xét cơ sở dữ liệu mẫu trong hình 4.2. Ràng buộc toàn vẹn dữ liệu có thể bị vi
phạm trong các trường hợp sau:
a) Ràng buộc toàn vẹn miền giá trị bị vi phạm nếu thêm bộ (10, N‘Hệ thống
thông tin quản lý rừng’, N‘Gia Lai’, N‘Phòng Phần mềm trong nước’) vào
quan hệ PROJECT – giá trị tại thuộc tính DNum không là số nguyên.
b) Ràng buộc toàn vẹn khoá bị vi phạm nếu thêm bộ (10, N‘Hệ thống thông
tin quản lý rừng’, N‘Gia Lai’, 2) vào quan hệ PROJECT – hiện có sẵn bộ
có giá trị tại thuộc tính khoá PNumber là 10
c) Ràng buộc toàn vẹn thực thể bị vi phạm nếu thêm bộ (null, ‘Hệ thống thông
tin quản lý rừng’, N‘Gia Lai’, 2) vào quan hệ PROJECT – giá trị tại thuộc
tính khoá không thể là NULL
d) Ràng buộc toàn vẹn tham chiếu bị vi phạm nếu thêm bộ (10, ‘Hệ thống
thông tin quản lý rừng’, N‘Gia Lai’, 8) vào quan hệ PROJECT – trong
DEPARTMENT không có bộ nào có giá trị tại thuộc tính DNumber là 8.

4.3.2 Toán tử Delete – xóa một (số) bộ ra khỏi quan hệ
Toán tử Delete được dùng để xoá một (số) bộ ra khỏi quan hệ R. Các bộ được xoá
nhất thiết phải thoả mãn điều kiện xoá được khai báo bên trong lệnh Delete. Trong
trường hợp điều kiện này không được khai báo tường minh, tất cả các bộ hiện có
trong quan hệ R đều bị xoá (bản thân lược đồ quan hệ R vẫn giữ nguyên). Toán tử
này chỉ có thể vi phạm ràng buộc toàn vẹn tham chiếu, nếu bộ đang xóa được tham
chiếu từ các bộ khác trong cơ sở dữ liệu thông qua các quan hệ khóa chính – khóa
ngoại.
VÍ DỤ 4.15: Ràng buộc toàn vẹn dữ liệu bị vi phạm khi xoá một (số) bộ ra
khỏi quan hệ.
a) Ràng buộc toàn vẹn tham chiếu bị vi phạm, nếu xoá bộ có DNumber = 1
khỏi quan hệ DEPARTMENT – nhiều bộ trong quan hệ EMPLOYEE
đang tham chiếu tới bộ muốn xoá.
b) Ràng buộc toàn vẹn tham chiếu bị vi phạm , nếu xoá bộ có ESSN =
3010020004 khỏi quan hệ EMPLOYEE – nhiều bộ trong quan hệ
EMPLOYEE đang tham chiếu tới bộ muốn xoá.

4.3.3 Toán tử Update – cập nhật một (số) bộ trong quan hệ
Toán tử Update được sử dụng để thay đổi giá trị của một (số) thuộc tính trong một
(số) bộ của quan hệ R. Các bộ được cập nhật phải thoả mãn điều kiện cập nhật
được khai báo bên trong lệnh Update. Trong trường hợp điều kiện không được
khai báo tường minh, tất cả các bộ hiện có trong quan hệ R đều chịu ảnh hưởng
bởi thao tác này. Tương tự như toán tử Insert, toán tử này cũng có thể vi phạm cả
bốn loại ràng buộc đã nêu ở phần trước. Ví dụ 4.16 sau đây minh họa các trường
hợp ràng buộc toàn vẹn dữ liệu bị vi phạm khi toán tử Delete được thực thi.
VÍ DỤ 4.16: Ràng buộc toàn vẹn dữ liệu bị vi phạm khi sửa một (số) bộ có sẵn
trong quan hệ.
a) Ràng buộc toàn vẹn miền giá trị bị vi phạm, nếu thay đổi giá trị thuộc tính
ESex=‘U’ đối với bộ có ESSN=3010020004 trong quan hệ EMPLOYEE,
giá trị của thuộc tính ESex chỉ có thể là ‘F’, hoặc ‘M’.
b) Ràng buộc toàn vẹn khoá bị vi phạm, nếu thay đổi giá trị thuộc tính ESSN =
3010020004 đối với bộ có ESSN=3010020005 trong quan hệ EMPLOYEE
– trong quan hệ EMPLOYEE có sẵn một bộ khác có giá trị tại ESSN là
3010020004
c) Ràng buộc toàn vẹn thực thể bị vi phạm, nếu đưa giá trị thuộc tính ESSN về
NULL đối với bộ có ESSN = 3010020004 trong quan hệ EMPLOYEE –
giá trị tại thuộc tính khoá không thể NULL.
d) Ràng buộc toàn vẹn tham chiếu bị vi phạm, nếu thay đổi giá trị thuộc tính
DNum = 7 đối với bộ có ESSN=3010020004 trong quan hệ EMPLOYEE –
trong DEPARMENT không tồn tại bộ có giá trị tại DNumber là 7

4.3.4 Xử lý vi phạm ràng buộc toàn vẹn tham chiếu
Hệ quản trị cơ sở dữ liệu có nhiệm vụ duy trì các ràng buộc toàn vẹn dữ liệu để
đảm bảo cơ sở dữ liệu luôn thoả mãn các ràng buộc này mọi lúc mọi nơi. Giải
pháp mặc định là từ chối thực hiện các phép toán dẫn tới vi phạm ràng buộc toàn
vẹn. Trong trường hợp này, hệ quản trị cơ sở dữ liệu sẽ đưa ra lời giải thích tại sao
phép toán không được thực hiện. Giải pháp này được áp dụng triệt để đối với các
loại ràng buộc toàn vẹn miền giá trị, ràng buộc toàn vẹn khoá, và ràng buộc toàn
vẹn thực thể. Riêng đối với loại ràng buộc toàn vẹn tham chiếu, hệ quản trị cơ sở
dữ liệu còn cho phép người sử dụng được quyền lựa chọn một trong ba cách xử lý
mỗi khi chúng bị vi phạm:
1) Cơ chế mặc định: hệ quản trị cơ sở dữ liệu từ chối tất cả những phép toán vi
phạm ràng buộc toàn vẹn tham chiếu.
2) Cơ chế thay thế: Những thay đổi tại giá trị thuộc tính khoá của bộ được
chiếu tới vi phạm ràng buộc toàn vẹn tham chiếu sẽ tự động được cập nhật
tại giá trị thuộc tính khoá ngoại của bộ chiếu đi tương ứng.
3) Cơ chế giá trị null: Nếu sự thay đổi tại giá trị thuộc tính khoá ngoại của bộ
chiếu đi vi phạm ràng buộc toàn vẹn tham chiếu, thì giá trị này được thiết
lập là NULL.
4.4 TÓM TẮT
Trong chương này chúng ta đã tìm hiểu các khái niệm cơ bản về mô hình dữ liệu
quan hệ. Chúng ta bắt đầu với định nghĩa về lược đồ quan hệ, thuộc tính và miền
giá trị của thuộc tính. Chúng ta cũng đã phân biệt giữa thể hiện quan hệ và lược đồ
quan hệ. Cơ sở dữ liệu mẫu COMPANY cũng được mô tả chi tiết để người đọc có
thể dễ dàng tiếp cận nhằm phục vụ cho hệ thống các ví dụ xuyên suốt giáo trình
này.
Phần tiếp theo cũng chương này chúng ta tìm hiểu về các ràng buộc toàn vẹn trên
mô hình dữ liệu quan hệ. Các ràng buộc thực chất là các điều kiện đảm bảo dữ liệu
của chúng ta phù hợp với thực tế, phản án đúng thế giới thực mà nó lưu trữ. Chúng
ta nhấn mạnh ràng buộc khóa và ràng buộc toàn vẹn tham chiếu như là hai loại
ràng buộc phổ biến nhất trong mô hình dữ liệu quan hệ.
Tiếp theo, chúng tôi trình bày ba loại toán tử cập nhật trên quan hệ, bao gồm: thêm
mới, chỉnh sửa, và xóa bỏ một hoặc một số bộ cụ thể. Việc thêm, sửa và xóa dữ
liệu trong nhiều trường hợp sẽ dẫn đến vi phạm ràng buộc toàn vẹn dữ liệu. Cuối
cùng, chúng ta giới thiệu ba cơ chế có thể áp dụng trong trường hợp ràng buộc
toàn vẹn tham chiếu bị vi phạm: cơ chế mặc định, cơ chế thay thế, và cơ chế sử
dụng giá trị NULL.
C
CHHƯ
ƯƠƠN
NGG
5
ĐẠI SỐ QUAN HỆ VÀ
PHÉP TÍNH QUAN HỆ
Mục tiêu
Chương này trang bị cho người đọc các kiến thức về đại số quan hệ – các phép
toán thực hiện trên quan hệ, nhằm giúp người đọc có thực hiện các câu lệnh truy
vấn từ đơn giản đến phức tạp trên mô hình dữ liệu quan hệ. Bên cạnh đó, người
đọc còn được làm quen với một hình thức thể biện khác của đại số quan hệ, đó là
phép tính quan hệ, nền tảng của ngôn ngữ dữ liệu phổ biến nhất hiện nay: ngôn
ngữ truy vấn có cấu trúc.
Nội dung
Các phép toán một ngôi.
Các phép toán hai ngôi.
Các phép toán khác.
Phép tính quan hệ trên bộ.
Phép tính quan hệ trên miền.
Giới thiệu
Dữ liệu sau khi được định nghĩa, được sử dụng để lưu trữ thông tin. Ngày qua
ngày, thông tin được cập nhật liên tục, dữ liệu ngày càng trở nên phong phú, đồ sộ.
Tuy nhiên, dữ liệu đó sẽ chẳng có ý nghĩa gì, nếu người sử dụng không thể khai
thác được thông tin hữu ích từ chính nó. Vấn đề đặt ra ở đây là làm thế nào để
người sử dụng có thể đọc được thông tin lưu trữ trong cơ sở dữ liệu. Để làm được
điều đó, chúng ta cần xây dựng một tập hợp các phép toán được thực thi trên dữ
liệu có sẵn. Đối với mô hình dữ liệu quan hệ, tập hợp các phép toán này được gọi
là đại số quan hệ.
Các phép toán trong đại số quan hệ cho phép người sử dụng xây dựng quan hệ mới
từ một hoặc nhiều quan hệ có sẵn bằng cách thực hiện các yêu cầu truy vấn. Nhiều
phép toán quan hệ được thực hiện liên tiếp nhau, đầu ra của phép toán này là đầu
vào của phép toán kia, được gọi là biểu thức đại số quan hệ. Kết quả của một biểu
thức đại số quan hệ là một quan hệ mới – cũng chính là kết quả của phép toán
được thực hiện sau cùng.
Đại số quan hệ được coi như là nền tảng lý thuyết để xây dựng ngôn ngữ truy vấn
có cáu trúc SQL – ngôn ngữ sử dụng chính trong các hệ quản trị cơ sở dữ liệu
quan hệ. Đại số quan hệ là một phần không thể tách rời của mô hình dữ liệu quan
hệ. Nắm vững các kiến thức về đại số quan hệ tức là làm chủ được ngôn ngữ truy
vấn có cấu trúc SQL.
5.1 PHÉP TOÁN MỘT NGÔI
5.1.1 Phép chọn
Phép chọn là toán tử một ngôi, được áp dụng với quan hệ R, tạo ra quan hệ mới
cùng lược đồ với quan hệ R, nhưng có số bộ nhỏ hơn hoặc bằng số bộ trong R.
Phép chọn được như là một bộ lọc, chỉ cho phép giữ lại những bộ thỏa mãn điều
kiện chọn, và bỏ qua những bộ còn lại. Nói cách khác, bộ dữ liệu xuất hiện trong
kết quả của phép chọn phải là bộ thỏa mãn điều kiện chọn C liên quan tới các
thuộc tính của quan hệ R. Phép chọn được thực hiện trên từng bộ của quan hệ, do
đó điều kiện chọn C không thể liên quan tới nhiều hơn một bộ. Phép chọn này
được ký hiệu là σC(R).
Phép chọn hoạt động như sau: áp dụng điều kiện chọn C cho từng bộ t của quan hệ
R bằng cách thay thế các thuộc tính A của R xuất hiện trong C bằng các thành phần
t[A] tương ứng trong bộ t. Nếu sau khi thay thế, điều kiện chọn C cho kết quả
TRUE, thì bộ t được chọn xuất hiện trong quan hệ kết quả của phép chọn σC(R),
ngược lại, bộ t không được chọn. Điều kiện chọn C là một biểu thức lôgic được
tạo từ nhiều mệnh đề lôgic có dạng:
<tên thuộc tính><toán tử so sánh><hằng số>,
hoặc
<tên thuộc tính><toán tử so sánh><tên thuộc tính>
với <tên thuộc tính> là tên thuộc tính của R, <toán tử so sánh> có thể là = < ≤ > ≥
≠, và <hằng số> là giá trị hằng số thuộc miền giá trị của thuộc tính có tên là <tên
thuộc tính>. Trong biểu thức lôgic các mệnh đề lôgic được nối với nhau bởi các
toán tử lôgic và (AND), hoặc (OR), hay phủ định (NOT). Ví dụ 5.1 và 5.2 thể hiện
hai ví dụ đơn giản liên quan đến phép chọn trên quan hệ EMPLOYEE (hình 5.1).
Hình 5.1. Một thể hiện của quan hệ EMPLOYEE.
VÍ DỤ 5.1: Phép chọn với điều kiện chọn đơn giản.

Xét quan hệ EMPLOYEE với thể hiện như hình 5.1. Để chọn các nhân viên thuộc
đơn vị có mã số 1, chúng ta có thể dùng phép toán σDNum = 1(EMPLOYEE). Kết
quả của phép toán này được biểu diễn trong hình 5.2.
Hình 5.2. Phép chọn với điều kiện chọn đơn giản

VÍ DỤ 5.2: Phép chọn với điều kiện chọn phức tạp.
Với yêu cầu liệt kê tất cả nhân viên hoặc làm việc trong phòng 1 và có mức lượng
trên $85,000/năm, hoặc làm việc trong phòng 5 và có mức lương trên
$90,000/năm, điều kiện chọn tương ứng sẽ là (DNum = 1 AND ESalary > 85,000)
OR (DNum = 5 AND ESalary >90,000). Kết quả của phép chọn với điều kiện
chọn này được thể hiện trong hình 5.3 dưới đây.
Hình 5.3. Kết quả của phép chọn với điều kiện chọn phức tạp.

Chú ý rằng các phép so sánh = < ≤ > ≥ ≠ được áp dụng cho các thuộc tính có miền
giá trị thuộc kiểu dữ liệu số, và kiểu dữ liệu thời gian. Đối với thuộc tính có miền
giá trị là chuỗi ký tự, phép so sánh hai chuỗi được thực hiện trên từng ký tự của
chúng. Đối với các thuộc tính có miền giá trị không thể sắp xếp, chỉ có hai toán tử
= và ≠ được áp dụng. Ví dụ, đối với miền giá trị của thuộc tính giới tính
dom(ESex) = {‘F’, ‘M’}, không thể thực hiện phép so sánh giữa hai giá trị giới
tính khác nhau.
5.1.2 Phép chiếu

Nếu chúng ta xem quan hệ là một bảng dữ liệu hai chiều, thì phép toán chọn chọn
một số hàng trong bảng và loại bỏ những hàng còn lại. Phép toán chiếu thì ngược
lại, chọn một số cột trong bảng và loại bỏ những cột còn lại. Nói cách khác, phép
chiếu chia quan hệ thành hai quan hệ khác: một chứa các thuộc tính được chọn,
một chứa các thuộc tính không được chọn.
Kết quả của phép chiếu πA1,A2,…,Ak (R) là một quan hệ mới có k thuộc tính, với A1,
A2,…, Ak là các thuộc tính của quan hệ R (và còn được gọi là danh sách thuộc tính
chiếu). Phép chiếu xoá các bộ trùng nhau (nếu có) để đảm bảo kết quả trả về là
một tập hợp gồm nhiều bộ.
VÍ DỤ 5.3: Phép chiếu trên các thuộc tính đơn.
Sử dụng quan hệ EMPLOYEE với một thể hiện như trong hình 5.1, kết quả thực
hiện phép chiếu πEName,ESalary (EMPLOYEE) là một quan hệ có 2 thuộc tính và 21
bộ (hình 5.4a). Trong khi đó, phép chiếu πDNum, supervisorSSN (EMPLOYEE) lại cho
ra một quan hệ có 2 thuộc tính với 12 bộ mà thôi (hình 5.4b).
(a) πEName,ESalary (EMPLOYEE) (b) πDNum, supervisorSSN (EMPLOYEE)
Hình 5.4. Phép chiếu trên quan hệ EMPLOYEE

5.2 CÁC PHÉP TOÁN HAI NGÔI

5.2.1 Phép hợp, phép giao, và phép trừ
Vì quan hệ được định nghĩa như là một tập hợp các bộ, cho nên các phép toán tập
hợp cũng được coi là một bộ phận của đại số quan hệ. Các phép toán tập hợp
chúng ta có thể sử dụng bao gồm phép hợp, phép giao và phép trừ. Tuy nhiên, cả
ba phép toán tập hợp này chỉ có thể được áp dụng trên hai quan hệ, nếu hai quan
hệ này có tính khả hợp.
Hai quan hệ R(A1,A2,…,An) và S(B1,B2,…,Bn) được gọi là khả hợp nếu có cùng bậc
n và dom(Ai) = dom(Bi), ∀i∈{1,…,n}. Điều này có nghĩa là hai quan hệ R và S có
tính khả hợp, nếu có cùng số thuộc tính, và cùng miền giá trị cho từng cặp thuộc
tính tương ứng.
Chúng ta định nghĩa các phép toán tập hợp trên hai quan hệ có tính khả hợp R và S
như sau:
Phép hợp: kết quả của phép hợp, ký hiệu R ∪ S, là một quan hệ gồm các
bộ hoặc thuộc R, hoặc thuộc S, hoặc thuộc cả hai. Phép hợp tự bỏ các bộ
trùng nhau (nếu có): R ∪ S = {t | t ∈ R ∨ t ∈ S}
Phép giao: kết quả của phép giao, ký hiệu R ∩ S, là một quan hệ gồm các
bộ vừa thuộc R, vừa thuộc S: R ∩ S = {t | t ∈ R ∧ t ∈ S}
Phép trừ: kết quả của phép trừ, kỳ hiệu R − S, là một quan hệ gồm các bộ
chỉ thuộc R nhưng không thuộc S: R − S = {t | t ∈ R ∧ t ∉ S}
VÍ DỤ 5.4: Phép hợp trên quan hệ EMPLOYEE.

Để liệt kê các nhân viên hoặc làm việc trong phòng 1, hoặc có mức thu nhập trên
$90,000, chúng ta có thể thực hiện riêng rẽ hai phép chọn như sau:
RES_1 ← σDNum=1(EMPLOYEE)
RES_2 ← σESalary>90,000(EMPLOYEE)
Quan hệ RES_1 lưu trữ thông tin các nhân viên làm việc trong phòng 1 (hình 5.5),
quan hệ RES_2 lưu trữ thông tin các nhân viên có mức lương trên $90,000 (hình
5.6). Tiếp theo, chúng ta thực hiện phép hợp với hai kết quả thu được từ hai phép
chọn nói trên (hình 5.7).
Hình 5.5. Kết quả biểu thức σDNum=1(EMPLOYEE)

Hình 5.6. Kết quả biểu thức σESalary>90,000(EMPLOYEE)
Hình 5.7. Kết quả biểu thức σDNum=1(EMPLOYEE)∪σESalary>80,000(EMPLOYEE)

VÍ DỤ 5.5: Các phép toán tập hợp trên quan hệ EMPLOYEE.

Áp dụng hai quan hệ kết quả được trình bày trong ví dụ 5.4 trên đây, chúng ta có
thể giải quyết một số câu truy vấn phức tạp:
(1) Để liệt kê những nhân viên trong phòng 1 và có lương trên 90,000, chúng ta
áp dụng phép giao giữa hai quan hệ (hình 5.8):
RESULT ← RESULT1 ∩ RESULT2

Hình 5.8. Kết quả biểu thức σDNum=1(EMPLOYEE)∩σESalary>80,000(EMPLOYEE)
(2) Để liệt kê những nhân viên trong phòng 1 và không có lương trên 90,000,
chúng ta áp dụng phép trừ giữa hai quan hệ (hình 5.9):
RESULT ← RESULT1 – RESULT2
Hình 5.9. Kết quả biểu thức σDNum=1(EMPLOYEE)−σESalary>80,000(EMPLOYEE)

5.2.2 Phép nhân chéo
Tiếp theo, chúng ta tìm hiểu phép nhân chéo, được ký hiệu là ×. Đây là một phép
toán hai ngôi, và các quan hệ tham gia phép toán này không bắt buộc phải là khả
hợp. Phép toán này được dùng để tổ hợp các bộ từ hai quan hệ.
Nói chung, kết quả của phép nhân chéo của hai quan hệ R(A1,A2,…,An) và
S(B1,B2,…,Bm) là quan hệ Q(A1,A2,…,An,B1,B2,…,Bm) có n+m thuộc tính. Mỗi bộ
trong quan hệ kết quả Q là tổ hợp của một bộ trong R với một bộ trong S. Vì vậy,
nếu quan hệ R có nR bộ, quan hệ S có nS bộ, thì quan hệ kết quả Q = R × S có nR*nS
bộ. Trong trường hợp hai quan hệ R và S có những thuộc tính trùng tên, chúng ta
cần sử dụng tên lược đồ quan hệ theo sau là tên thuộc tính, ví dụ R.A và S.A.
VÍ DỤ 5.6: Phép nhân chéo hai quan hệ R và S.

Cho hai quan hệ R và S có lược đồ và thể hiện như trong hình 5.10a và 5.10b.
Phép nhân chéo R × S trả về kết quả là một quan hệ có 6 bộ (hình 5.10c). Để nhận
được kết quả này, mỗi bộ của quan hệ R đã kết nối với 3 bộ của quan hệ S. Vì B là

thuộc tính của cả R và S, chúng ta sử dụng R.S và S.B tương ứng trong lược đồ của
quan hệ R × S.
R S R×S
Hình 5.10. Hai quan hệ R, S và phép nhân chéo của chúng.

Dễ dàng nhận thấy rằng, nếu biểu thức đại số quan hệ chỉ gồm một phép nhân
chéo thì kết quả thu được không thực sự có ý nghĩa. Kết quả này là sự kết hợp
ngẫu nhiên giữa một bộ bất kỳ của R với một bộ bất kỳ của S. Để phép nhân chéo
có ý nghĩa hơn, người ta thường áp dụng phép chọn sau phép nhân chéo để chọn ra
những bộ thỏa mãn điều kiện nào đó cho trước.
VÍ DỤ 5.7: Sử dụng phép chọn và phép chiếu sau phép nhân chéo.
Để thực hiện yêu cầu truy vấn danh sách nhân viên cùng tên phòng ban quản lý
họ, chúng ta sử dụng biểu thức sau đây:
πEname, ESalary, supervisorSSN, DName (σDnumber = DNum(EMPLOYEE × DEPARTMENT))
Với yêu cầu trên đây, trước tiên chúng ta cần phải nhân chéo hai quan hệ
EMPLOYEE và DEPARTMENT để nhận về tất cả những khả năng có thể xảy
ra giữa một nhân viên với một phòng ban. Để loại bỏ những sự kết hợp không phù
hợp, chúng ta sử dụng một phép chọn trên quan hệ thu được sau phép nhân chéo.
Quan hệ kết quả của câu truy vấn trên được minh họa trong hình 5.11

Hình 5.11. Sử dụng kết hợp phép chọn, phép chiếu sau phép nhân chéo.

5.2.3 Phép kết theta

Phép kết theta, ký hiệu là ⋈C, được dùng để kết nối hai quan hệ với nhau thành
một quan hệ duy nhất với ý nghĩa: mỗi bộ trong quan hệ thứ nhất kết nối với mọi
bộ trong quan hệ thứ hai sao cho bộ kết quả thỏa mãn điều kiện kết C.
Quan hệ kết quả Q của phép kết theta giữa hai quan hệ R(A1,…,An) và S(B1,…,Bm)
có lược đồ Q(A1, …, An, B1, …, Bm). Trong trường hợp R và S có thuộc tính cùng
tên là V, chúng ta cần sử dụng ký hiệu R.V và S.V để phân biệt chúng trong lược
đồ của quan hệ kết quả Q.
Phép kết theta giữa hai quan hệ R và S dựa trên điều kiện C có thể được hiểu như
là phép chọn trên điều kiện C đối với kết quả trả về của phép nhân chéo giữa R và
S, tức là R ⋈C S = σC(R × S).

5.2.4 Phép kết bằng và kết tự nhiên
Trong thực tế, biểu thức điều kiện kết trong phép kết thường chỉ gồm các phép so
sánh bằng. Những phép kết với điều kiện kết như thế gọi là phép kết bằng (EQUI
JOIN). Các ví dụ chúng ta đã nhắc đến ở trên đều là kết bằng. Vì là phép kết với
điều kiện kết là phép so sánh bằng giữa một hay nhiều cặp thuộc tính, cho nên mỗi
bộ thuộc quan hệ kết quả có giá trị giống nhau tại (các) cặp thuộc tính được dùng
để kết đó.
Trong ví dụ 5.7, từng bộ trong quan hệ kết quả đều có giá trị giống nhau tại thuộc
tính DNumber và thuộc tính DNum, bởi vì quan hệ này là kết quả của một phép
kết bằng giữa hai thuộc tính này. Từ đó, chúng ta nhận thấy rằng xuất hiện hai
thuộc tính trong cùng quan hệ có giá trị giống nhau tại từng bộ là không cần thiết.
Kết tự nhiên là một dạng khác của phép kết, trong đó (các) cặp thuộc tính được
dùng để kết bằng chỉ xuất hiện một lần duy nhất trong quan hệ kết quả. Chính vì
thế, phép kết tự nhiên yêu cầu tên của hai (hoặc mỗi cặp) thuộc tính kết phải giống
nhau. Trong trường hợp điều kiện này không thỏa mãn, trước khi thực hiện phép
kết tự nhiên, chúng ta cần đổi tên các (cặp) thuộc tính đó. Theo định nghĩa này, kết
tự nhiên là một dạng kết bằng trong đó điều kiện bằng được kiểm tra đối với mọi
cặp thuộc tính cùng tên trong cả hai quan hệ.
Chúng ta cũng có thể định nghĩa phép kết tự nhiên như sau:
Q ← R *(<dsach1>,<dsach2>)S
Trong định nghĩa này, <dsach1> là danh sách i thuộc tính của R, và <dsach2> là
danh sách i thuộc tính của S. Hai danh sách này được dùng để xác định các điều
kiện so sánh bằng giữa từng cặp thuộc tính tương ứng, và các điều kiện này được
nói với nhau bằng phép toán lôgic AND. Chỉ các thuộc tính của quan hệ R –
<dsach1> – được giữ trong quan hệ kết quả Q.

VÍ DỤ 5.8: Thực hiện phép kết tự nhiên trên các cặp thuộc tính trùng tên.
Trong ví dụ sau đây, trước hết chúng ta đổi tên thuộc tính DNum của quan hệ
PROJECT thành DNumber – cùng tên với thuộc tính DNumber trong quan hệ
DEPARTMENT – và sau đó thực hiện phép kết tự nhiên:
PRO_DEP ← ρ(PNumber, PName, PLocation, DNumber) (PROJECT) *
DEPARTMENT
Câu truy vấn này có thể thực hiện trong hai bước như sau:
PRO ← ρ( PNumber, PName, PLocation, DNumber) (PROJECT)
PROJ_DEP ← PRO * DEPARTMENT
Thuộc tính DNumber được gọi là thuộc tính kết. Kết quả trả về của câu truy vấn
này được minh họa ở hình 5.12. Trong quan hệ PROJ_DEP, mỗi bộ của quan hệ
PROJECT kết với một bộ của quan hệ DEPARTMENT tương ứng, nhưng chỉ
duy nhất một thuộc tính kết DNumber được giữ lại.
Hình 5.12. Phép kết tự nhiên giữa PROJECT và DEPARTMENT.

VÍ DỤ 5.9: Thực hiện phép kết tự nhiên trên hai thuộc tính trùng tên.
Khi thực hiện phép kết tự nhiên trên thuộc tính ESSN đối với hai quan hệ
EMPLOYEE và DEPENDENT, chúng ta chỉ cần thực hiện câu truy vấn sau đây:
EMP_DEP ← πESSN, EName, ESalary, DName, Dbirthdate
EMPLOYEE*DEPENDENT
Kết quả truy vấn này được thể hiện trong hình 5.13.

Hình 5.13. Phép kết tự nhiên giữa EMPLOYEE và DEPENDENT.

Trường hợp tổng quát, nếu R có nR bộ, và S có nS bộ, kết quả của phép kết R ⋈<điều
kiện kết> S sẽ có từ 0 đến nR*nS bộ. Như chúng ta thấy, phép kết được dùng để tổ hợp
dữ liệu từ nhiều quan hệ khác nhau và kết quả được lưu trữ trong một quan hệ
đơn. Phép kết này còn được gọi là INNER JOIN để phân biệt với một dạng khác
của phép kết – đó là OUTER JOIN.
5.2.5 Tập đầy đủ các phép toán đại số quan hệ
Tập hợp các phép toán {σ, π, ∪, −, ×} được gọi là tập đầy đủ các phép toán đại số
quan hệ, nghĩa là tất cả các phép toán đại số quan hệ đều có thể được biểu diễn
như là một dãy các phép toán từ tập hợp này. Ví dụ, phép giao có thể được viết lại
như sau:
R ∩ S ≡ (R ∪ S) – ((R – S) ∪ (S – R))
Phép kết được thay thế bằng sự kết hợp của phép chọn và phép nhân chéo như sau:
R ⋈<dkien> S ≡ σ<dkien> (R × S)
Phép kết tự nhiên có thể được biểu diễn bằng dãy bốn phép toán đại số quan hệ
theo thứ tự là phép đổi tên, phép nhân chéo, phép chọn và phép chiếu.

Từ đó, chúng ta có thể khẳng định với năm phép toán trong tập hợp nói trên, mọi
truy vấn dữ liệu đều được xác định. Các phép toán không nằm trong tập hợp này –
như phép giao, phép kết, … – mặc dù không thực sự cần thiết, nhưng thực tế,
chúng vẫn giữ vai trò quan trọng và thường xuyên được sử dụng trong các ứng
dụng cơ sở dữ liệu.
5.3 CÁC PHÉP TOÁN KHÁC

Khi làm việc với cơ sở dữ liệu thực tế, đôi khi chúng ta gặp phải trường hợp các
yêu cầu dữ liệu không thể được biểu diễn bằng những phép toán đại số quan hệ nói
trên. Chính vì vậy, trong phần này, chúng ta định nghĩa mới một số phép toán
nhằm tăng cường khả năng biểu diễn yêu cầu dữ liệu của ngôn ngữ đại số quan hệ.
5.3.1 Các hàm kết hợp và phép gom nhóm

Dạng yêu cầu dữ liệu đầu tiên không thể biểu diễn bằng các phép toán cơ bản
trong đại số quan hệ là các hàm kết hợp toán học trên tập hợp các giá trị trong cơ
sở dữ liệu, như là hàm tính giá trị trung bình, tổng lương của tất cả nhân viên; hàm
tính tổng số nhân viên trong công ty; … Các hàm này được sử dụng trong các câu
truy vấn đơn giản thực hiện trên các bộ trong cơ sở dữ liệu. Các hàm phép tính áp
dụng trên tập hợp các giá trị số bao gồm: SUM, AVERAGE, MAXIMUM, và
MINIMUM. Hàm COUNT được dùng để đếm số bộ, hoặc số giá trị trong một
quan hệ.
Dạng yêu cầu dữ liệu thứ hai mà các phép toán cơ bản trong đại số quan hệ không
thể biểu diễn được là yêu cầu gom nhóm các bộ trong quan hệ theo giá trị của các
thuộc tính của nó, và sau đó áp dụng các hàm kết hợp lên từng nhóm một cách độc
lập. Ví dụ như yêu cầu thống kê mức thu nhập bình quân của mỗi đơn vị trong
công ty.
Chúng ta có thể định nghĩa phép toán hàm kết hợp, ký hiệu là ℑ (đọc là F), mô tả
các kiểu yêu cầu dữ liệu trên như sau:

<các thuộc tính gom nhóm> ℑ <các hàm kết hợp>(R)
với <các thuộc tính gom nhóm> là danh sách gồm m thuộc tính của quan hệ R, và
<danh sách hàm kết hợp> là danh sách các cặp (<hàm kết hợp> <thuộc tính>).
Trong mỗi cặp này, <hàm kết hợp> là một trong số các hàm kết hợp – bao gồm
SUM, AVERAGE, MAXIMUM, MINIMUM, COUNT – và <thuộc tính> là thuộc
tính của quan hệ R. Quan hệ kết quả có các thuộc tính gom nhóm trong <các thuộc
tính gom nhóm> cộng với một thuộc tính ứng với mỗi cặp (<hàm kết hợp> <thuộc
tính>) trong <danh sách hàm kết hợp>.
VÍ DỤ 5.10: Sử dụng phép gom nhóm cùng các hàm phép hợp.
Để liệt kê số lượng nhân viên, mức lương trung bình của nhân viên trong từng đơn
vị, chúng ta sử dụng biểu thức sau:
ρR(depNum, No_Of_Employees, Avg_Of_Salary)
(DNumℑ(COUNT ESSN),(AVERAGE ESalary) (EMPLOYEE))
Kết quả của phép toán trong hình 5.14. Ở đây, chúng ta sử dụng phép đổi tên, để
từ đó, quan hệ kết quả có ba thuộc tính mới, lần lượt là DNum ứng với mã số đơn
vị, No_Of_Employees ứng với số nhân viên, Avg_Of_Salary ứng với mức lương
trung bình của các nhân viên trong đơn vị đó.
Cũng trong ví dụ này, nếu chúng ta không sử dụng phép gom nhóm, hoặc không
cung cấp thuộc tính gom nhóm, thì các hàm kết hợp sẽ được áp dụng lên tất cả các
bộ trong quan hệ. Chính vì thế, quan hệ kết quả chỉ có một bộ duy nhất như trong
hình 5.16.
Hình 5.14. Phép gom nhóm sử dụng phép đổi tên trong quan hệ kết quả

Hình 5.15. Phép gom nhóm không sử dụng phép đổi tên trong quan hệ kết quả
Hình 5.16. Phép gom nhóm không sử dụng thuộc tính gom nhóm

Chúng ta cần phải ghi nhớ rằng, sau khi thực hiện các hàm kết hợp trên quan hệ,
kết quả trả về là một quan hệ chứ không phải là số – thậm chí nếu kết quả trả về
chỉ là một giá trị đơn lẻ. Chính vì vậy, đại số quan hệ là một hệ thống đóng.
5.3.2 Phép kết ngoài

Bây giờ chúng ta sẽ tìm hiểu một số mở rộng của phép kết để giải quyết một số
kiểu truy vấn mà phép kết thông thường không thể đưa ra lời giải đúng. Ví dụ như
khi xét phép kết tự nhiên R * S, chỉ những bộ từ R có bộ tương ứng từ S – và
ngược lại – mới xuất hiện trong quan hệ kết quả. Do đó, những bộ không tìm thấy
bộ tương ứng, hoặc có giá trị null tại thuộc tính kết đều bị loại bỏ ra khỏi quan hệ
kết quả.
Các phép kết ngoài (outer join) được dùng khi chúng ta muốn duy trì tất cả các bộ
từ R, hoặc từ S, hoặc từ cả R và S trong quan hệ kết quả của phép kết, cho dù
chúng có hay không có bộ tương ứng trong quan hệ còn lại. Phép kết được trình
bày trong mục 5.3 còn được gọi là phép kết trong (inner join).
VÍ DỤ 5.11: Thực hiện phép kết ngoài.

Liệt kê tên tất cả đơn vị kèm theo tên dự án mà đơn vị đó quản lý (nếu có).

Trước hết, chúng ta hãy thực hiện truy vấn này bằng cách sử dụng phép kết với
điều kiện bằng giữa DNumber của DEPARTMENT với DNum của PROJECT.
Phép kết này biểu diễn như sau:
RESULT ← πDNumber, DName, mgrSSN, PNumber, PName (DEPARTMENT
⋈DNumber=DNum PROJECT)
Dễ dàng nhận thấy rằng (hình 5.17), kết quả trả về chỉ chứa thông tin liên quan
đến 4 đơn vị, trong khi chúng ta biết chắc chắn rằng có 5 đơn vị trong cơ sở dữ
liệu COMPANY. Như vậy, kết quả này không phù hợp với yêu cầu của bài toán
(liệt kê tất cả đơn vị).
Hình 5.17. Kết quả phép kết trong với điều kiện kết DNumber = DNum giữa
DEPARTMENT và PROJECT.
Chúng ta có thể khắc phục sai sót trên bằng cách sử dụng phép kết ngoài như sau:
RESULT ← πDNumber, DName, mgrSSN, PNumber, PName (DEPARTMENT
⋉DNumber=DNum PROJECT)
Kết quả của phép kết này được thể hiện trong hình 5.18.
Hình 5.18. Kết quả phép kết ngoài trái với điều kiện kết DNumber = DNum
giữa DEPARTMENT và PROJECT.


Như vậy, phép kết trái duy trì các bộ trong quan hệ đầu tiên – tức bên trái – và tìm
bộ tương ứng trong quan hệ thứ hai – tức bên phải – hoặc để trống nếu không tìm
thấy. Tương tự như thế, phép kết phải duy trì các bộ trong quan hệ thứ hai – tức
bên phải – và tìm bộ tương ứng trong quan hệ thứ nhất – tức bên trái – hoặc để
trống nếu không tìm thấy. Và cuối cùng, phép kết đầy đủ, duy trì các bộ trong cả
hai quan hệ. Với mỗi bộ từ quan hệ này, nếu tìm thấy bộ tương ứng từ quan hệ kia
thì kết hợp chúng lại với nhau, còn nếu không thì các giá trị null tự động được
thiết lập.
5.4 PHÉP TÍNH QUAN HỆ TRÊN BỘ

Trong mục này, và mục tiếp theo, chúng tôi giới thiệu một ngôn ngữ truy vấn hình
thức khác cho mô hình dữ liệu quan hệ. Ngôn ngữ này có tên gọi là phép tính quan
hệ. Trong phép tính quan hệ, chúng ta xây dựng các biểu thức để biểu diễn câu
truy vấn dữ liệu, và vì thế, không có cách nào để đánh giá câu truy vấn này. Phép
tính quan hệ cho biết nhận được cái gì, hơn là nhận được như thế nào. Chính vì
vậy, phép tính quan hệ còn được gọi là ngôn ngữ phi thủ tục. Đây là điểm khác
biệt giữa phép tính quan hệ với đại số quan hệ, nơi chúng ta phải xây dựng biểu
thức gồm nhiều phép toán đại số quan hệ kế tiếp nhau nhằm mô tả yêu cầu truy
vấn dữ liệu. Biểu thức phép tính quan hệ được biểu diễn bằng nhiều cách khác
nhau, hoàn toàn không liên quan tới việc câu truy vấn được thực hiện như thế nào.
5.4.1 Biến bộ
Phép tính quan hệ trên bộ được xây dựng dựa trên các biến bộ. Mỗi biến bộ đại
diện cho một quan hệ, giá trị của biến bộ lần lượt là các bộ của quan hệ đó. Biểu
thức phép tính quan hệ trên bộ đơn giản có dạng:
{t | BIỂU_THỨC_ĐIỀU_KIỆN(t)}
với t là một biến bộ, và BIỂU_THỨC_ĐIỀU_KIỆN(t) là biểu thức điều kiện với
đối số t. Kết quả của câu truy vấn này là một tập hợp gồm các bộ t thỏa mãn điều
kiện được nêu trong BIỂU_THỨC_ĐIỀU_KIỆN.

Một cách đơn giản, chúng ta cần phải xác định đầy đủ các thông tin sau đây cho
một biểu thức tính toán quan hệ trên bộ:
Quan hệ phạm vi R cho từng biến bộ t, ký hiệu t∈R.
Điều kiện để kết hợp các bộ. Khi các biến bộ t duyệt qua toàn bộ quan hệ
phạm vi R tương ứng, chỉ những tổ hợp của các bộ đồng thời thỏa mãn điều
kiện kết hợp này (tức cho giá trị là TRUE) mới được giữ lại.
Tập hợp các thuộc tính được yêu cầu trả về ở phần kết quả. Giá trị của
những thuộc tính này thu được từ những tổ hợp được chọn trả về.
VÍ DỤ 5.12: Ví dụ về phép tính quan hệ trên bộ.

Để tìm kiếm tất cả nhân viên có lương nhiều hơn $80,000, chúng ta có thể dùng
biểu thức phép tính trên bộ như sau:
{ t | t ∈ EMPLOYEE ∧ t.ESalary > 80000 }
Điều kiện t∈EMPLOYEE chỉ đúng khi biến bộ t nhận giá trị là một bộ của
quan hệ EMPLOYEE. Mỗi bộ t này nếu thỏa mãn điều kiện t.ESalary >
80000 sẽ được xem là một kết quả của câu truy vấn nói trên. Chú ý rằng
t.ESalary là giá trị tại thuộc tính ESalary của bộ t. Trong nhiều trường hợp,
t.ESalary còn được viết là t[ESalary].
Câu truy vấn trên đây trả về tất cả giá trị thuộc tính của mỗi bộ t được chọn.
Trong trường hợp chúng ta chỉ muốn hiển trị một vài giá trị thuộc tính của
bộ t, chúng ta có thể viết:
{ t.EName | t∈EMPLOYEE ∧ t.ESalary > 80000 }

VÍ DỤ 5.13: Ví dụ về phép tính quan hệ trên bộ.
Cho biết ngày sinh và mức lương của các nhân viên có tên là Võ Việt Anh.
{t.EBirthdate, t.ESalary | t∈EMPLOYEE ∧ t.EName=N’Võ Việt Anh’}
Trong biểu thức này, đầu tiên chúng ta phải xác định các thuộc tính được
yêu cầu EBirthdate và ESalary cho mỗi bộ t được chọn. Sau đó chúng ta

mới xác định các điều kiện chọn cho mỗi bộ t thuộc EMPLOYEE thỏa
mãn điều kiện t.EName = ’Võ Việt Anh’.

5.4.2 Biểu thức và công thức trong phép tính quan hệ trên bộ
Biểu thức phép tính quan hệ trên bộ tổng quát có dạng:
{t1.Aj, t2.Ak, …, tn.Am | C(t1, t2, …, tn, tn+1, …, tn+m)}
với t1, t2, …, tn, tn+1, …, tn+m là các biến bộ, và Ai là thuộc tính của quan hệ mà ti
đại diện, và C là biểu thức điều kiện của phép tính quan hệ trên bộ. Biểu thức điều
kiện được xây dựng từ các công thức nguyên tố sau:
1) R(ti) là một công thức nguyên tố, với R là tên quan hệ, ti là biến bộ. Công
thức này cho biết biến bộ ti là một bộ của quan hệ có tên là R.
2) ti.A θ tj.B là một công thức nguyên tố, với ti, tj là các biến bộ, A là thuộc
tính của quan hệ do ti đại diện, B là thuộc tính của quan hệ do tj đại diện. θ
là toán tử so sánh = < ≤ > ≥ ≠.
3) ti.A θ c là một công thức nguyên tố, với ti là biến bộ, A là thuộc tính của
quan hệ do ti đại diện, c là giá trị hằng, θ là toán tử so sánh = < ≤ > ≥ ≠.
Các công thức nguyên tố nói trên có kết quả là đúng hoặc sai, kết quả này còn
được gọi là chân trị của công thức nguyên tố. Công thức nguyên tố (1) có chân trị
là đúng, nếu t là một bộ của quan hệ R; ngược lại, công thức (1) có chân trị là sai.
Các công thức nguyên tố (2), (3) có chân trị đúng, nếu giá trị thuộc tính của các bộ
liên quan thỏa mãn điều kiện so sánh đã nêu.
Công thức được xây dựng từ các công thức nguyên tố được kết nối với nhau bằng
các toán tử lô-gic như là AND, OR, và NOT. Công thức được định nghĩa theo quy
nạp toán học như sau:
1) Mọi công thức nguyên tố đều là công thức
2) Nếu P là công thức, thì
a. (P) là công thức, cho giá trị đúng khi P đúng; ngược lại, cho giá trị sai.

b. ¬(P) là công thức, cho giá trị đúng khi P sai; ngược lại, cho giá trị sai.
3) Nếu F1, F2 là công thức thì
c. F1 ∧ F2 là công thức, cho giá trị đúng khi cả F1 và F2 đều đúng; ngược
lại, cho giá trị sai.
d. F1 ∨ F2 là công thức, cho giá trị sai khi cả F1 và F2 đều sai; ngược lại,
cho giá trị đúng.
5.4.3 Lượng hóa tồn tại và lượng hóa phổ dụng

Trong phép tính quan hệ, ngoài các ký hiệu đã nêu ở trên, chúng ta còn sử dụng
hai ký hiệu đặc biệt có tên gọi là lượng hóa tồn tại (existential quantifier – ∃) và
lượng hóa phổ dụng (universal quantifier – ∀). Quy tắc xác định giá trị của công
thức có các ký hiệu này được trình bày trong quy tắc (4) và (5) dưới đây. Tuy
nhiên, trước tiên chúng ta sẽ định nghĩa biến tự do và biến kết buộc trong công
thức phép tính quan hệ:
Các biến bộ trong công thức nguyên tố F là biến tự do trong F.
Các biến bộ trong công thức ở dạng F1 ∧ F2, F1 ∨ F2, ¬(F1), và ¬(F2) là
biến tự do hay biến kết buộc phụ thuộc vào các biến bộ này là tự do hay kết
buộc trong từng công thức F1, F2.
Mọi biến bộ t tự do trong công thức F đều là kết buộc trong công thức F’,
nếu F’ = (∃t)(F), hay F’ = (∀t)(F).
Bây giờ chúng ta tiếp tục phát biểu quy tắc (4) và (5) đối với định nghĩa về công
thức đã nêu ở phần 5.4.2:
4) Nếu F là công thức, thì (∃t)(F) cũng là công thức, với t là một biến bộ.
Công thức (∃t)(F) cho ra kết quả đúng, nếu công thức F cho giá trị đúng với
ít nhất một bộ t nào đó. Ngược lại, (∃t)(F) cho ra kết quả sai.
5) Nếu F là công thức, thì (∀t)(F) cũng là công thức, với t là một biến bộ.
Công thức (∀t)(F) cho ra kết quả đúng, nếu công thức F cho giá trị đúng
với mọi bộ t. Ngược lại, (∀t)(F) cho ra kết quả sai.
VÍ DỤ 5.14: Sử dụng lượng hóa tồn tại trong phép tính quan hệ trên bộ.
Cho biết tên và lương của tất cả nhân viên làm việc trong phòng Nghiên cứu:
{t.EName, t.ESalary | t∈EMPLOYEE ∧ (∃d)(d∈DEPARTMENT ∧
d.depName = N‘Phòng Nghiên cứu’ ∧ d.DNum = t.dNum)}
Chỉ những biến bộ tự do trong biểu thức phép tính quan hệ mới có thể xuất hiện
trong phần kết quả (bên trái của ký hiệu |). Ở đây, t là biến bộ tự do duy nhất. Nếu
một bộ t nào đó thỏa mãn các điều kiện, thì các giá trị ứng với thuộc tính EName,
ESalary được xuất hiện trong phần kết quả. Điều kiện t ∈ EMPLOYEE cho ra kết
quả đúng, khi t nhận giá trị là một bộ trong quan hệ EMPLOYEE. Điều kiện
d.depName = N‘Phòng Nghiên cứu’ là điều kiện chọn ứng với điều kiện chọn
trong đại số quan hệ. Điều kiện d.DNumber = t.DNum là điều kiện kết, với vai trò
tương tự như trong phép kết JOIN (xem mục 4.3).

VÍ DỤ 5.15: Ví dụ về sử dụng biến tự do trong phép tính quan hệ trên bộ.

Với mỗi đơn vị, cho biết mã số đơn vị, tên đơn vị, họ tên, và ngày sinh của trưởng
đơn vị:
{d.DNumber, d.DName, m.EName, m.EBirthdate | d∈DEPARTMENT ∧
m∈EMPLOYEE ∧ d.MGRSSN=m.ESSN)}
Biểu thức này có hai biến bộ tự do, d và m, nhằm mục đích thực hiện phép kết
giữa quan hệ DEPARTMENT với quan hệ EMPLOYEE phù hợp với yêu cầu
truy vấn.


Chúng ta muốn truy vấn họ tên nhân viên và họ tên lãnh đạo trực tiếp của nhân
viên này. Biểu thức phép tính quan hệ như sau:
{ t.EName, s.EName | t∈EMPLOYEE ∧ s∈EMPLOYEE ∧
t.supervisorSSN = s.ESSN }


Cho biết tên các nhân viên tham gia dự án do đơn vị số 5 phụ trách:
{t.EName | t∈EMPLOYEE ∧ (∃s)(∃u)( s∈PROJECT ∧
u∈WORKS_ON∧s.DNum=5 ∧ u.PNum=s.PNumber ∧ u.ESSN=t.ESSN)}

5.4.4 Biến đổi tương đương giữa lượng hóa tồn tại và lượng hóa phổ
dụng
Phần tiếp theo chúng ta tìm hiểu các phép biến đổi tương đương từ biểu thức
lượng hóa tồn tại sang biểu thức lượng hóa phổ dụng, và ngược lại. Các phép biến
đổi này hoạt động trên ý nghĩa toán học của các biểu thức luận lý. Chúng ta có các
phép biến đổi tương đương sau:
(∀x)( P( x)) ≡ ¬(∃x)(¬P( x))
(∃x)( P( x)) ≡ ¬(∀x)(¬P( x))
(∀x )( P ( x) ∧ Q ( x)) ≡ ¬(∃x)(¬P ( x) ∨ ¬Q( x))
(∀x )( P ( x) ∨ Q ( x)) ≡ ¬(∃x)(¬P ( x) ∧ ¬Q( x))
(∃x)( P ( x ) ∧ Q( x)) ≡ ¬(∀x)(¬P ( x) ∨ ¬Q( x))
(∃x)( P ( x) ∨ Q( x)) ≡ ¬(∀x)(¬P( x) ∧ ¬Q( x))
5.4.5 Sử dụng phép lượng hóa phổ dụng

Một khi chúng ta sử dụng phép lượng hóa phổ dụng, chúng ta cần chú ý một số
quy tắc để đảm bảo biểu thức phép tính quan hệ thể hiện đúng yêu cầu truy vấn dữ
liệu. Xét ví dụ sau đây:
VÍ DỤ 5.18: Sử dụng phép lượng hóa phổ dụng.

Cho biết họ tên nhân viên tham gia tất cả dự án do đơn vị có mã số 5 phụ trách.
{e.EName | e∈EMPLOYEE ∧ (∀x)(¬(x∈PROJECT) ∨ ¬(x.dNum = 5) ∨
((∃w)(w∈WORKS_ON∧ w.ESSN=e.ESSN ∧ w.PNum=x.PNumber)))}
Chúng ta có thể chia nhỏ Q3 ra như sau:
Q3: { e.EName | e∈EMPLOYEE ∧ F’}

F’ = (∀x)( ¬(x ∈ PROJECT) ∨ F1)
F1 = ¬(x.dNum = 5) ∨ F2
F2=((∃w)(w∈WORKS_ON∧w.ESSN=e.ESSN∧w.PNum=x.PNumber))
Chúng ta muốn đảm bảo rằng nhân viên e được chọn làm việc cho tất cả dự án do
đơn vị số 5 phụ trách, và để lượng hóa phổ dụng có kết quả TRUE, thì biểu thức
luận lý trong nó phải đúng với mọi bộ liên quan. Chúng ta sử dụng một mẹo nhỏ
để loại bỏ ra khỏi phép lượng hóa phổ dụng những bộ không cần thiết bằng cách
cho biểu thức điều kiện luôn có giá trị TRUE đối với các bộ này.Trong truy vấn
(3), biểu thức ¬(x∈PROJECT) cho giá trị đúng với mọi bộ không thuộc quan hệ
PROJECT, chúng ta loại bỏ các bộ này ra khỏi biểu thức lượng hóa phổ dụng
đang xét. Tiếp tục, biểu thức ¬(x.dNum = 5) cho giá trị đúng với các bộ thuộc
PROJECT nhưng có giá trị khác 5 tại thuộc tính dNum. Chúng ta chỉ quan tâm tới
các bộ thuộc PROJECT và có giá trị tại thuộc tính dNum là 5. Do đó, chúng ta sẽ
loại bỏ các bộ thuộc PROJECT nhưng có giá trị khác 5 tại thuộc tính dNum. Đến
đây, chúng ta còn lại các bộ thuộc PROJECT và có giá trị tại thuộc tính dNum là
5. Và cuối cùng, chúng ta chọn ra các nhân viên tham gia vào tất cả các bộ
PROJECT còn giữ lại trong kết quả của biểu thức lượng hóa phổ dụng đang xét.

Tìm các nhân viên thỏa mãn điều kiện không có dự án nào của đơn vị số 5 mà
nhân viên này không tham gia.
{e.EName | e∈EMPLOYEE ∧ ¬(∃x)(x ∈ PROJECT ∧ x.dNum = 5 ∧
¬(∃w)(w∈WORKS_ON ∧ w.PNum = x.PNumber ∧ w.ESSN = e.ESSN))}

Liệt kê các trưởng đơn vị có thân nhân:
{e.EName | e∈EMPLOYEE ∧ (∃x)(x∈DEPARTMENT ∧
x.mgrSSN = e.ESSN) ∧ (∃p)(p∈DEPENDENT ∧ p.ESSN = e.ESSN)}

Cho biết tên các nhân viên không có thân nhân:
{e.Ename|e∈EMPLOYEE∧¬(∃x)(x∈DEPENDENT∧x.ESSN=e.ESSN)}
Chúng ta có thể viết lại công thức trên như sau:
{e.EName|e∈EMPLOYEE∧
(∀x)(¬(x∈DEPENDENT) ∨ e.ESSN ≠ x.ESSN)}

5.4.6 Biểu thức an toàn
Một khi chúng ta sử dụng các phép toán ∀ (với mọi), ∃ (tồn tại), và ¬ (phủ định)
trong biểu thức phép tính, chúng ta phải đảm bảo rằng biểu thức này cho ra kết
quả có ý nghĩa nào đó. Biểu thức an toàn trong phép tính quan hệ đảm bảo rằng
kết quả nhận được là một tập hợp có số phần tử là hữu hạn.
Chúng ta có thể định nghĩa biểu thức an toàn dựa trên miền giá trị của biểu thức
phép tính quan hệ trên bộ: là tập hợp tất cả các giá trị cố định trong công thức
cũng như các giá trị xuất hiện trong quan hệ tham gia công thức này. Một biểu
thức được gọi là an toàn nếu kết quả trả về nằm trong miền giá trị của nó.
VÍ DỤ 5.22: Biểu thức an toàn.

Biểu thức { t | ¬(t ∈ EMPLOYEE)} không an toàn bởi vì kết quả trả về là những
thực thể (bộ) không phải là nhân viên, và số lượng những thực thể như thế là nhiều
vô hạn.
Miền giá trị của biểu thức { t | ¬(t ∈ EMPLOYEE) } là tập hợp các giá trị thuộc
tính xuất hiện trong quan hệ EMPLOYEE (trong một bộ nào đó của quan hệ này),
trong khi kết quả trả về là tập hợp những bộ (gồm nhiều giá trị) không nằm trong
quan hệ EMPLOYEE. Do đó, biểu thức này gọi là không an toàn.


5.5 PHÉP TÍNH QUAN HỆ TRÊN MIỀN
Phép tính quan hệ có hai hình thức thể hiện. Một là phép tính quan hệ trên bộ mà
chúng ta đã nghiên cứu ở phần trên, trong đó biểu thức phép tính nhận đối số là
các biến bộ. Ở hình thức thể hiện thứ hai, biểu thức phép tính nhận đối số là các
biến miền giá trị, chính vì vậy, hình thức này có tên gọi là phép tính quan hệ trên
miền.
Khác với phép tính quan hệ trên bộ khi biến bộ đại diện cho tất cả các bộ trong
quan hệ, biến miền trong phép tính quan hệ trên miền đại diện cho tất cả các giá trị
trong miền giá trị tương ứng. Biểu thức phép tính quan hệ trên miền có dạng như
sau:
{x , x
1 2 ,..., x n P( x1 , x 2 ,..., x n , x n +1 ,..., x n + m )}
với x1, x2, …, xn, xn+1, …,xn+m là những biến bộ đại diện cho các miền giá trị (thuộc
tính) tương ứng. và P là biểu thức điều kiện của phép tính quan hệ trên miền. Kết
quả trả về của biểu thức này là quan hệ bậc n tạo bởi các biến miền x1, x2, …, xn.
Biểu thức điều kiện được xây dựng từ các công thức nguyên tố sau:
1) <x1,x2,…,xj> ∈ R là một công thức nguyên tố, với R là tên quan hệ, xi là
biến miền. Công thức này cho biết <x1,x2,…,xj> là một bộ của quan hệ
có tên là R. xi là giá trị tương ứng với thuộc tính thứ i trong bộ.
2) xiθxk là một công thức nguyên tố, với xi, xk là các biến miền, θ là toán tử
so sánh = < ≤ > ≥ ≠.
3) xiθc là một công thức nguyên tố, với xi là biến miền, c là giá trị hằng, θ
là toán tử so sánh = < ≤ > ≥ ≠.
Các công thức nguyên tố có chân trị, tức là kết quả trả về hoặc TRUE, hoặc
FALSE. Công thức (1) cho ra kết quả TRUE khi <x1,x2,…,xj> có giá trị tương ứng
với một bộ trong quan hệ R. Công thức (2), (3) cho ra kết quả là TRUE khi các
phép so sánh cho ra kết quả TRUE đối với từng giá trị của biến miền giá trị.

Cách thức xây dựng biểu thức điều kiện từ các công thức nguyên tố trong phép
tính quan hệ trên miền tương tự như đối với phép tính quan hệ trên bộ. Do đó,
chúng tôi không trình bày mà dành phần định nghĩa này cho đọc giả.
Tiếp theo, chúng tôi thực hiện một số câu truy vấn minh họa bằng phép tính quan
hệ trên miền.
VÍ DỤ 5.23: Phép tính quan hệ trên miền.

Cho biết ngày sinh và lương của nhân viên có tên là ‘Võ Việt Anh’
{ t3, t5 | (∃t2)(<t1,t2,t3,t4,t5,t6,t7,t8> ∈ EMPLOYEE ∧ t2=’Võ Việt Anh’)}
EMPLOYEE là quan hệ có 8 thuộc tính, trong đó mức lương là thuộc tính thứ 3,
và ngày sinh là thuộc tính thứ 5.


Cho biết tên và mức lương của các nhân viên làm việc trong phòng Nghiên cứu.
{t2,t4 | (∃t7)(∃u1)(∃u2)(<t1,t2,t3,t4,t5,t6,t7,t8>∈EMPLOYEE ∧
<u1,u2,u3,u4>∈DEPARTMENT ∧ u2=’Nghiên cứu’ ∧ t7=u1)}


Cho biết tên nhân viên không có thân nhân.
{t2 | (∃t1)(<t1,t2,t3,t4,t5,t6,t7,t8>∈EMPLOYEE ∧
¬(∃u1)(<u1,u2,u3,u4>∈DEPENDENT ∧ u1=t1))}


5.6 TÓM TẮT
Trong chương này chúng tôi trình bày hai ngôn ngữ hình thức của mô hình dữ liệu
quan hệ: đại số quan hệ và phép tính quan hệ. Cả hai ngôn ngữ này đều được sử
dụng để thực hiện các câu truy vấn dựa trên các quan hệ hiện có trong CSDL.
Đầu tiên, chúng tôi giới thiệu đại số quan hệ với các phép toán đi từ cơ bản đến
nâng cao kèm theo các ví dụ minh họa giúp người đọc hiểu rõ vai trò, cũng như
cách sử dụng các phép toán riêng lẻ, hoặc kết hợp chúng lại với nhau thành những
biểu thức đại số quan hệ phức tạp. Các phép toán đại số quan hệ có thể phân chia
thành hai nhóm, tùy theo số quan hệ tham gia trong đó. Chẳng hạn như phép toán
một ngôi bao gồm phép chọn, phép chiếu, và phép đổi tên. Phép toán hai ngôi bao
gồm các phép toán trên tập hợp, phép nhân chéo, phép kết, và phép kết tự nhiên.
Sau khi tìm hiểu các phép toán cơ bản, chúng ta tiếp tục tìm hiểu các phép toán
nâng cao với phép toán sắp xếp, phép toán gom nhóm, và các phép kết mở rộng.
Tất cả các phép toán này được gọi tên là tập đầy đủ các phép toán đại số quan hệ,
sử dụng chúng có thể hiện thực được mọi yêu cầu truy vấn trên dữ liệu quan hệ.
Tiếp theo chúng ta tìm hiểu một ngôn ngữ hình thức khác của mô hình dữ liệu
quan hệ, đó là phép tính quan hệ. Phép tính quan hệ được xây dựng trên nền tảng
lôgic vị từ, một nhánh của toán lôgic. Phép tính quan hệ được chia làm hai loại:
phép tính quan hệ trên bộ và phép tính quan hệ trên miền. Chúng tôi cũng minh
họa cách thức áp dụng các phép tính quan hệ để hiện thực các yêu cầu truy vấn
trên dữ liệu quan hệ.
Cuối cùng, chúng ta thực hiện phép so sánh giữa đại số quan hệ và phép tính quan
hệ. Nếu đại số quan hệ cho biết cách thức thực hiện câu truy vấn, thì phép tính
quan hệ lại tập trung vào việc xác định kết quả trả về là gì. Trong khi đại số quan
hệ cho phép thực hiện sắp xếp, gom nhóm, thì phép tính quan hệ định nghĩa lượng
hóa phổ dụng và lượng hóa tồn tại.

Hai loại ngôn ngữ hình thức nêu trên không hề mâu thuẫn nhau mà bổ sung lẫn
nhau tạo nền tảng cho việc xây dựng một ngôn ngữ dữ liệu được phát triển thành
chuẩn áp dụng cho mọi hệ quản trị cơ sở dữ liệu hiện nay. Đó là ngôn ngữ truy
vấn cấu trúc SQL.

C
CHHƯ
ƯƠƠN
NGG
6
THIẾT KẾ CƠ SỞ DỮ LIỆU
Mục tiêu
Chương này cung cấp cho người đọc kiến thức về quy trình thiết kế cơ sở dữ liệu
quan hệ. Quy trình này trải qua ba bước chính: đặc tả yêu cầu của người sử dụng,
thiết kế cơ sở dữ liệu ý niệm và thiết kế cơ sở dữ liệu luận lý. Kết quả cuối cùng
của quá trình này chính là một lược đồ cơ sở dữ liệu quan hệ đáp ứng đầy đủ các
yêu cầu về dữ liệu của người sử dụng.
Nội dung
Quy trình thiết kế cơ sở dữ liệu quan hệ.
Thiết kế cơ sở dữ liệu ý niệm.
Thiết kế cơ sở dữ liệu luận lý.
Emai: namth@buh.edu.vn 128

Giới thiệu
Như chúng ta đã nghiên cứu ở chương 3, hiện nay trên thị trường có nhiều công cụ
thiết kế cơ sở dữ liệu được xây dựng trên mô hình thực thể kết hợp và mô hình
thực thể kết hợp mở rộng. Các mô hình này còn được gọi là mô hình ý niệm của
dữ liệu. Mô hình ý niệm thì không thể hiện thực trên một hệ quản trị cơ sở dữ liệu
trên máy tính. Do đó, trong chương 4, chúng ta đã tìm hiểu mô hình dữ liệu quan
hệ, một mô hình luận lý của dữ liệu. Mô hình này được sử dụng rộng rãi trong
nhiều hệ quản trị cơ sở dữ liệu thương mại lẫn phi thương mại. Trong chương này,
chúng ta sẽ tiến hành nghiên cứu điểm tương đồng giữa hai loại mô hình thực thể
kết hợp và mô hình dữ liệu quan hệ. Đồng thời, chúng ta cũng sẽ nghiên cứu quy
trình tạo lược đồ cơ sở dữ liệu quan hệ từ mô hình thực thể kết hợp. Thực tế, các
chuyên viên thiết kế cơ sở dữ liệu dựa vào yêu cầu lưu trữ và xử lý dữ liệu của
khách hàng để xây dựng bản thiết kế cơ sở dữ liệu từ mức trừu tượng như mô hình
thực thể kết hợp tới mức thực thi như mô hình dữ liệu quan hệ.

6.1 CÁC GIAI ĐOẠN THIẾT KẾ CƠ SỞ DỮ LIỆU
6.1.1 Định nghĩa
Cơ sở dữ liệu được định nghĩa như là tập hợp các dữ liệu có cấu trúc, có liên quan
về mặt ý nghĩa với nhau được lưu trữ nhằm phục vụ đồng thời cho nhiều người,
với nhiều mục đích và khai thác khác nhau. Hoạt động thiết kế cơ sở dữ liệu được
thực hiện dựa trên bản đặc tả các yêu cầu của người sử dụng nhằm có thể xây
dựng được một cơ sở dữ liệu tốt với những đặc tính sau đây:
Tính không trùng lắp
Tính nhất quán dữ liệu
Tính dễ khai thác
Dễ cập nhật và nâng cấp
Hoạt động thiết kế cơ sở dữ liệu cũng như các hoạt động thiết kế khác phụ thuộc
rất nhiều vào quan điểm của người thiết kế. Do đó, với cùng một bản đặc tả yêu
cầu dữ liệu giống nhau, có thể có nhiều thiết kế cơ sở dữ liệu khác nhau. Trong
trường hợp này, chúng ta cần chọn lựa một cấu trúc cơ sở dữ liệu hiệu quả liên
quan đến các vấn đề khai thác trong tương lai, cụ thể như sau:
Thời gian thực hiện các yêu cầu truy xuất dữ liệu.
Thời gian sao lưu và phục hồi cơ sở dữ liệu khi có sự cố bất thường.
Chi phí hoạt động xây dựng, cài đặt và triển khai cơ sở dữ liệu.
Tính ổn định trong một thời gian dài, phù hợp với định hướng về chiến lược
và mục đích sử dụng cơ sở dữ liệu.
Quy trình thiết kế cơ sở dữ liệu là một quá trình gồm nhiều bước thực hiện kế tiếp
nhau, bắt đầu từ hoạt động phân tích yêu cầu của người sử dụng thông qua bản đặc
tả yêu cầu dữ liệu, xây dựng các bản thiết kế ý niệm, thiết kế luận lý, thiết kế vật
lý và kết thúc bằng hoạt động cài đặt và triển khai cơ sở dữ liệu. Chúng ta có thể
áp dụng các phương pháp phát triển hệ thống vào hoạt động thiết kế cơ sở dữ liệu,
mà cụ thể là hai phương pháp thác nước và phương pháp xoắn ốc.

6.1.2 Đặc tả yêu cầu dữ liệu của người sử dụng
Mục đích chính của hoạt động đặc tả yêu cầu của người sử dụng là xác định nhu
cầu của người sử dụng đối với dữ liệu được lưu trữ trong hệ thống. Hoạt động này
được diễn ra thông qua sự tiếp xúc trực tiếp hoặc gián tiếp giữa nhân viên thiết kế
cơ sở dữ liệu với các nhóm đối tượng người sử dụng khác nhau. Nhiệm vụ chủ yếu
của nhân viên thiết kế cơ sở dữ liệu trong giai đoạn này là:
Thu thập thông tin về dữ liệu và nhu cầu xử lý hoặc khai thác dữ liệu từ
phía người sử dụng, từ các tài liệu, chứng từ, biểu mẫu thống kê liên quan
đến cơ sở dữ liệu.
Tổng hợp, phân tích các dữ liệu, kiểm tra tính hợp lý của các nhu cầu xử lý
hoặc khai thác dữ liệu.
Kết thúc giai đoạn này nhân viên thiết kế phải cung cấp được bản đặc tả yêu cầu
dữ liệu của người sử dụng. Bản đặc tả thể hiện chi tiết tổ chức dữ liệu, các mối
liên hệ giữa các đối tượng dữ liệu, cũng như mục đích và giải pháp để thực hiện
các thao tác xử lý hoặc khai thác dữ liệu. Bản đặc tả được trình bày bằng ngôn ngữ
tự nhiên, ngắn gọn, dễ hiểu để người sử dụng có thể xem và đóng góp ý kiến.
6.1.3 Thiết kế cơ sở dữ liệu ý niệm

Dựa vào bản đặc tả yêu cầu dữ liệu được xây dựng ở giai đoạn trước, nhân viên
thiết kế xác định cấu trúc dữ liệu, mối liên hệ giữa các đối tượng được lưu trữ
trong cơ sở dữ liệu. Nhân viên thiết kế sử dụng các bộ công cụ hỗ trợ thiết kế để
mô hình hóa tổ chức của dữ liệu. Một bản thiết kế cơ sở dữ liệu ý niệm tốt phải thể
hiện đúng, đầy đủ các đối tượng dữ liệu, các ràng buộc về cấu trúc cũng như về
ngữ nghĩa của chúng.
Bản thiết kế cơ sở dữ liệu ý niệm là một bản thiết kế tổng thể, dựa trên nhiều bản
thiết kế nhỏ hơn được xây dựng trên cơ sở phân tích nhu cầu dữ liệu của từng
nhóm người sử dụng khác nhau trong hệ thống. Nhờ vậy mà bản thiết kế của

chúng ta có thể đảm bảo tất cả yêu cầu của mọi đối tượng người sử dụng trong hệ
thống được đáp ứng trong một thời gian dài.
6.1.4 Thiết kế cơ sở dữ liệu luận lý

Nếu bản thiết kế cơ sở dữ liệu ý niệm cung cấp cho chúng ta một cái nhìn chính
xác về thế giới thực được cơ sở dữ liệu phản ảnh trong hệ thống, thì bản thiết kế
cơ sở dữ liệu luận lý lại giúp giải quyết các vấn đề liên quan đến việc cài đặt và
triển khai cơ sở dữ liệu trên hệ thống máy tính. Cấu trúc luận lý của cơ sở dữ liệu
phải phù hợp với hệ thống sẽ kết nối và sử dụng cơ sở dữ liệu đó.
Nhân viên thiết kế cơ sở dữ liệu luận lý cần cân nhắc giữa việc loại bỏ mọi dư
thừa trong dữ liệu để tối ưu hóa dung lượng bộ nhớ sử dụng cho cơ sở dữ liệu, hay
là chấp nhận dư thừa trong dữ liệu nhưng nhờ đó lại tăng tốc độ xử lý các yêu cầu
dữ liệu có liên quan.
6.1.5 Thiết kế cơ sở dữ liệu vật lý

Trong giai đoạn này, nhân viên thiết kế cơ sở dữ liệu xây dựng một cấu trúc vật lý
cho cơ sở dữ liệu, đảm bảo cơ sở dữ liệu có thể tương thích với hệ thống máy tính
cũng như các ứng dụng có kết nối và truy xuất dữ liệu. Để làm được điều đó, nhân
viên thiết kế cơ sở dữ liệu cần thực hiện các công việc sau đây:
Lựa chọn hệ quản trị cơ sở dữ liệu, cấu hình phần cứng, giải pháp kết nối
nội mạng, liên mạng, …, phù hợp với độ phức tạp, phạm vi, chức năng của
các ứng dụng có kết nối với cơ sở dữ liệu.
Lựa chọn các giải pháp đảm bảo an toàn và bảo mật dữ liệu trong suốt thời
gian vận hành của hệ thống.
Thiết lập cấu hình cho hệ quản trị cơ sở dữ liệu đã chọn nhằm đáp ứng tốt
nhất nhu cầu vận hành, khai thác dữ liệu của người sử dụng.

Tóm lại, thiết kế cơ sở dữ liệu bao gồm ba hoạt động thiết kế, đó là thiết kế ý
niệm, thiết kế luận lý và thiết kế vật lý. Trong phạm vi giáo trình chúng tôi chỉ
trình bày chi tiết cho hai hoạt động thiết kế đầu tiên.
6.2 THIẾT KẾ CƠ SỞ DỮ LIỆU Ý NIỆM

Thiết kế cơ sở dữ liệu ý niệm được thực hiện sau bước đặc tả yêu cầu dữ liệu của
người sử dụng. Trong phạm vi giáo trình, chúng tôi sử dụng mô hình thực thể kết
hợp (mở rộng) để hỗ trợ trong việc biểu diễn quá trình thiết kế cơ sở dữ liệu ý
niệm.
Cơ sở dữ liệu ý niệm thực chất là tập hợp tất cả những khái niệm, ý niệm xuất hiện
trong thế giới thực mà cơ sở dữ liệu cần lưu trữ. Cơ sở dữ liệu ý niệm không được
cài đặt trên bất kỳ hệ quản trị cơ sở dữ liệu nào, nó chỉ sử dụng để chúng ta có thể
hình dung ra tổ chức của dữ liệu và mối liên quan giữa các dữ liệu này với nhau.
Chính vì vậy, mô hình thực thể kết hợp là một sự lựa chọn phù hợp.
6.2.1 Các bước thiết kế cơ sở dữ liệu ý niệm

Như chúng ta đã biết, mô hình thực thể kết hợp có ba thành phần cơ bản: các tập
thực thể, các thuộc tính, và các liên kết. Dựa vào các thành phần này, chúng ta có
thể xác định các bước cần thực hiện trong quá trình thiết kế cơ sở dữ liệu ý niệm
cho một hệ thống ứng dụng thực tế như sau:
Bước 1: Xác định yêu cầu về dữ liệu lưu trữ của hệ thống, phân tích các thành
phần dữ liệu của hệ thống. Bước này bao gồm ba nội dung:
(1.1) Xác định các tập thực thể, tức là các sự vật, sự việc, … cần được hệ
thống lưu trữ.
(1.2) Xác định các thuộc tính cho từng tập thực thể, mỗi thuộc tính là một đặc
trưng giúp xác định tập thực thể.
(1.3) Xác định các liên kết giữa các tập thực thể, các thuộc tính cho từng liên
kết. Liên kết thực chất là những ràng buộc về mặt cấu trúc của dữ liệu.

Bước 2: Mô hình hóa các yêu cầu về dữ liệu bằng các sơ đồ với các thành phần đã
được xác định trong bước 1. Mỗi yêu cầu được thể hiện bằng một sơ đồ đơn giản.
Bước 3: Tích hợp các sơ đồ đơn giản trong bước 2 thành một sơ đồ tổng thể về tổ
chức dữ liệu lưu trữ của hệ thống. Hoàn thiện bản thiết kế bằng cách bổ sung các
thông tin có liên qua: thuộc tính của liên kết, vai trò và số lượng của từng tập thực
thể tham gia trong liên kết.
Bước 4: Hoàn thiện bản thiết kế. Loại bỏ các tập thực thể, thuộc tính, hay liên kết
dư thừa trong bản thiết kế ở bước 3.
6.2.2 Ví dụ về thiết kế cơ sở dữ liệu ý niệm

Để minh họa cho quá trình thiết kế cơ sở dữ liệu ý niệm, chúng ta sử dụng ví dụ
mẫu được trình bày trong mục 2.2. Để thuận lợi cho việc theo dõi, chúng tôi giới
thiệu lại bản đặc tả dữ liệu cho ví dụ này như sau:
Công ty được tổ chức thành nhiều đơn vị với các thông tin bao gồm: tên
đơn vị, số hiệu đơn vị. Mỗi đơn vị có thể có nhiều văn phòng đại diện tại
những địa điểm khác nhau. Đơn vị được quản lý bởi một nhân viên giữ
chức vụ trưởng đơn vị. Hệ thống cũng yêu cầu phải duy trì thông tin về
ngày ký quyết định bổ nhiệm cho từng trưởng đơn vị.
Mỗi đơn vị điều hành nhiều dự án. Thông tin về dự án bao gồm: tên dự án,
số hiệu, và địa điểm thực hiện dự án.
Công ty duy trì thông tin về nhân viên bao gồm: họ và tên, mã số, mức
lương, giới tính, ngày sinh và ngày ký hợp đồng làm việc với công ty. Mỗi
nhân viên thuộc biên chế một đơn vị nhưng có thể tham gia nhiều dự án
khác nhau. Các dự án này không nhất thiết phải do cùng một đơn vị quản
lý. Công ty cũng theo dõi thời gian (tính bằng số giờ làm việc trong tuần)
tham gia từng dự án của mỗi nhân viên. Ngoài ra, mỗi nhân viên còn chịu
sự giám sát của một nhân viên khác.

Cuối cùng, công ty có chế độ bảo hiểm dành cho người thân của nhân viên.
Thông tin về người thân bao gồm tên, giới tính, ngày sinh và mối liên hệ
với nhân viên.
Quá trình thiết kế cơ sở dữ liệu ý niệm cho ví dụ này lần lượt diễn ra các bước như
sau:
Bước 1: Xác định yêu cầu về dữ liệu lưu trữ của hệ thống, phân tích các thành
phần dữ liệu của hệ thống:
(1.1) Xác định các tập thực thể. Với câu hỏi “hệ thống lưu trữ những sự vật,
sự việc gì?” chúng ta nhận thấy có bốn tập thực thể cần được biểu diễn
trong mô hình. Bốn tập thực thể đó là: Department (Đơn vị),
Employee (Nhân viên), Project (Dự án), và Dependent (Thân nhân).
(1.2) Xác định các thuộc tính. Với câu hỏi “với mỗi tập thể chúng ta có nhu
cầu muốn biết những gì? ” chúng ta có thể xác định các thuộc tính cho
từng tập thực thể. Cụ thể như sau:
Tên đơn vị DName
Số hiệu đơn vị DNumber
Các địa điểm DLocation
Dự án Project
Tên dự án PName
Số hiệu dự án PNumber
Địa điểm PLocation
Họ và tên EName
Mã số ESSN
Giới tính ESex
Mức lương ESalary
Ngày sinh EBirthdate

Ngày bắt đầu EStartdate
Tên DName
Giới tính DSex
Ngày sinh DBirthdate
Mối liên hệ DRelationship
(1.3) Xác định các liên kết. Với câu hỏi “giữa các tập thực thể này có mối
liên hệ gì không?Liên kết có đòi hỏi thông tin riêng không? ” chúng ta
có thể xác định liên kết giữa các tập thực thể, và các thuộc tính (nếu có)
của nó. Cụ thể như sau:
Quản lý Manage
Thời gian bổ nhiệm MgrStartdate
Điều hành Control
Dự án Project
Biên chế Works for
Thời gian bắt đầu làm việc EStartdate
Tham gia Works on
Dự án Project
Số giờ làm việc trong tuần Workhours
Giám sát Supervise

Phụ thuộc Has
Bước 2: Mô hình hóa các yêu cầu về dữ liệu bằng các sơ đồ. Các sơ đồ ứng với ví
dụ mẫu được minh họa trong hình sau đây.
Hình 6.1. Các tập thực thể trong ví dụ mẫu
Hình 6.2. Các kiểu liên kết trong ví dụ mẫu
Bước 3: Tích hợp các sơ đồ đơn giản trong bước 2 thành một sơ đồ tổng thể về tổ
chức dữ liệu lưu trữ của hệ thống.

Hình 6.3. Mô hình thực thể kết hợp của ví dụ mẫu
Bước 4: Hoàn thiện bản thiết kế. Tinh chỉnh hệ thống với các giả thuyết bổ sung
như sau:
Nhân viên trong công ty được phân chia làm nhiều nhóm khác nhau,
dựa vào nhiệm vụ mà từng nhân viên đảm nhận trong công ty. Chúng ta
có ba nhóm nhân viên: Nhân viên văn phòng (Secretary), Nhân viên kỹ
thuật (Engineer) và Nhân viên lái xe (Driver). Mỗi nhóm nhân viên
ngoài những đặc trưng chung, còn có các đặc trưng riêng.
Công ty duy trì thông tin về người thân đối với nhân viên trong nhóm
nhân viên kỹ thuật thay vì đối với toàn bộ nhân viên trong công ty.

Hình 6.4. Tinh chỉnh mô hình ở bước 3 với một số yêu cầu bổ sung
Tất cả các khái niệm có liên quan đến mô hình thực thể kết hợp và mô hình thực
thể kết hợp mở rộng đã được trình bày ở chương 2 và chương 3. Do đó, trong
chương này, chúng ta tập trung nghiên cứu quy trình thiết kế cơ sở dữ liệu luận lý
từ mô hình thực thể kết hợp (mở rộng).
6.3 THIẾT KẾ CƠ SỞ DỮ LIỆU LUẬN LÝ

6.3.1 Thiết kế cơ sở dữ liệu quan hệ từ mô hình thực thể kết hợp
Như đã tìm hiểu về quá trình xây dựng cơ sở dữ liệu cho ứng dụng, từ những yêu
cầu về dữ liệu cũng như về chức năng của ứng dụng, chúng ta cần xây dựng mô
hình mô phỏng chính xác cấu trúc dữ liệu cần được lưu trữ trong hệ thống. Mô
hình thực thể kết hợp (xem chương 2) và sự mở rộng của nó (xem chương 3) đáp
ứng rất tốt mục tiêu này. Tuy nhiên, đó là một mô hình có tính trừu tượng ở mức
cao, phản ánh đúng thế giới thực. Chính vì đây là mô hình có tính trừu tượng cao,
nên chúng ta không thể hiện thực được cơ sở dữ liệu trên máy tính dựa trên mô
hình này. Chúng ta cần chuyển đổi mô hình này sang một dạng khác tương đương
mà máy tính có thể hiểu được. Mô hình dữ liệu quan hệ là một mô hình như thế.
Chúng ta sẽ sử dụng cơ sở dữ liệu COMPANY để minh họa quy trình này. Hình
6.3 trên đây biểu diễn mô hình thực thể kết hợp (mở rộng) của cơ sở dữ liệu
COMPANY mà chúng ta cần phải chuyển sang mô hình dữ liệu quan hệ. Để thực
hiện việc này, chúng ta cần tuân thủ chặt chẽ các bước trong quy trình sau đây.
Quy trình chuyển đổi cơ sở dữ liệu quan hệ từ mô hình thực thể kết hợp:
Bước 1: Ánh xạ các kiểu thực thể thường
Quy tắc 1: Ánh xạ các kiểu thực thể thường. Với mỗi kiểu thực thể
thường E trong lược đồ E/R, chúng ta tạo một quan hệ R với tất cả các
thuộc tính của E.
Chú ý rằng nếu E có thuộc tính kết hợp, mỗi thành phần trong thuộc tính kết hợp
này trở thành một thuộc tính đơn trong R. Tiếp theo, chúng ta chọn một trong số
các khóa của E làm khóa chính của R. Các khóa còn lại trở thành khóa phụ trong
R. Nếu khóa được chọn trong E là thuộc tính kết hợp, thì tập hợp các thuộc tính
đơn tương ứng trong R cùng nhau tạo nên khóa chính của R.
VÍ DỤ 6.1: Ánh xạ kiểu thực thể thường sang quan hệ.

Đối với cơ sở dữ liệu COMPANY, chúng ta tạo các quan hệ EMPLOYEE,
DEPARTMENT, và PROJECT tương ứng với các kiểu thực thể cùng tên trong
hình 6.4. Khóa ngoại và các thuộc tính quan hệ (nếu có) chưa xuất hiện ở bước
này. Khóa chính của EMPLOYEE là ESSN, trong khi khóa chính của
DEPARTMENT và PROJECT lần lượt là DNumber và PNumber.

DEPARTMENT EMPLOYEE PROJECT
DNumber ESSN PNumber
DName EName PName
ESalary PLocation
ESex
EBirthdate
EStartdate
Hình 6.5. Ánh xạ kiểu thực thể thường sang quan hệ

Các quan hệ được tạo từ việc ánh xạ các kiểu thực thể còn được gọi là các quan hệ
thực thể vì mỗi bộ (hàng) tương ứng với một thực thể.
Bước 2: Ánh xạ các kiểu thực thể yếu

Quy tắc 2: Ánh xạ các kiểu thực thể yếu. Với mỗi kiểu thực thể yếu W
được xác định bởi (các) kiểu thực thể thường E trong lược đồ E/R, tạo một
quan hệ R chứa tất cả các thuộc tính đơn (hoặc các thành phần đơn của các
thuộc tính kết hợp) của W như là các thuộc tính của R.
Ngoài ra, chúng ta thêm vào R thuộc tính khóa chính của các quan hệ tương ứng
với các kiểu thực thể thường E xác định W. Các thuộc tính này trở thành các khóa
ngoại trong R. Khóa chính của quan hệ R là tổ hợp của các thuộc tính khóa ngoại
vừa mới thêm vào cùng với khóa bộ phận của tập thực thể yếu W (nếu có).
Trong trường hợp kiểu thực thể yếu E2 được xác định bởi kiểu thực thể E1, mà bản
thân E1 cũng là một kiểu thực thể yếu, E1 cần phải được ánh xạ trước, tiếp theo sau
mới đến lượt E2 được ánh xạ từ E1.
VÍ DỤ 6.2: Ánh xạ kiểu thực thể yếu sang quan hệ.

Trong cơ sở dữ liệu COMPANY, chúng ta tạo quan hệ DEPENDENT tương ứng
với kiểu thực thể yếu DEPENDENT. Chúng ta cũng bổ sung thuộc tính khóa
chính ESSN của quan hệ EMPLOYEE vào thành khóa ngoại của quan hệ

DEPENDENT. Khóa chính của quan hệ DEPENDENT là tổ hợp (SSN, Name) vì
Name là khóa riêng của kiểu thực thể yếu DEPENDENT.
DEPENDENT
DName
ESSN
DSex
DBirthdate
DRelationship
Hình 6.6. Ánh xạ kiểu thực thể yếu sang quan hệ

Bước 3: Ánh xạ các kiểu liên kết hai ngôi 1:1

Quy tắc 3: Ánh xạ các kiểu liên kết hai ngôi 1:1. Với mỗi kiểu liên kết R
hai ngôi 1:1 trong lược đồ E/R, chúng ta xác định các quan hệ S và T tương
ứng với các kiểu thực thể liên quan trong R và thực hiện một trong ba cách
sau đây: (1) hướng tiếp cận khóa ngoại, (2) hướng tiếp cận liên kết ghép
trộn, (3) hướng tiếp cận quan hệ liên kết. Hướng tiếp cận (1) thường được
sử dụng nhiều nhất, có hữu ích nhất mà không cần phải có điều kiện gì đi
kèm.
(1) Hướng tiếp cận khóa ngoại: Chọn một quan hệ – giả sử đó là S – và thêm
vào S thuộc tính khóa chính của T như là khóa ngoại. Tiếp theo, chúng ta
thêm tất cả các thuộc tính đơn (hoặc thành phần đơn của các thuộc tính kết
hợp) của kiểu liên kết R hai ngôi 1:1 như là thuộc tính của S.
VÍ DỤ 6.3: Ánh xạ kiểu liên kết hai ngôi một – một sang quan hệ.
Trong ví dụ COMPANY, chúng ta ánh xạ kiểu liên kết 1:1 có tên là MANAGES
trong hình 6.3 bằng cách chọn kiểu thực thể DEPARTMENT có vai trò như S bởi
vì mọi đơn vị đều có một trưởng đơn vị. Chúng ta thêm khóa chính của quan hệ
EMPLOYEE vào như là khóa ngoại của quan hệ DEPARTMENT, đồng thời đổi

tên thuộc tính này thành mgrSSN. Chúng ta cũng có thể bổ sung vào quan hệ
DEPARTMENT thuộc tính đơn Startdate của kiểu liên kết MANAGES và đổi tên
nó thành mgrStartdate.
EMPLOYEE DEPARTMENT
ESSN DNumber
EName DName
ESalary mgrSSN
ESex mgrStartdate
EBirthdate
EStartdate
Hình 6.6. Ánh xạ kiểu liên kết hai ngôi một – một sang quan hệ.

Chú ý rằng thay vì thêm khóa chính của quan hệ EMPLOYEE vào như là khóa
ngoại của quan hệ DEPARTMENT, chúng ta có thể làm ngược lại, tức là thêm
khóa chính của quan hệ DEPARTMENT vào như là khóa ngoại của quan hệ
EMPLOYEE. Tuy nhiên, quan hệ EMPLOYEE lúc này sẽ có nhiều giá trị null
tại thuộc tính khóa ngoại đó bởi vì không phải nhân viên nào cũng làm trưởng đơn
vị. Nếu chỉ có 10% nhân viên làm trưởng đơn vị, có nghĩa là có tới 90% giá trị tại
thuộc tính khóa ngoại sẽ có giá trị là NULL. Ngoài ra, chúng ta còn có thể thêm
khóa chính của quan hệ này trở thành khóa ngoại của quan hệ kia và ngược lại, tuy
nhiên giải pháp này làm cho cơ sở dữ liệu của chúng ta trở nên cồng kềnh, và có
nhiều giá trị NULL không cần thiết.
(2) Hướng tiếp cận quan hệ liên kết ghép trộn: Chúng ta có thể trộn hai kiểu
thực thể và liên kết của chúng vào thành một quan hệ duy nhất. Hướng
ngày phù hợp khi cả hai tập thực thể tham gia liên kết đều toàn vẹn, nghĩa
là mỗi thực thể của tập thực thể này liên kết với đúng một thực thể của tập
thực thể kia và ngược lại.
(3) Hướng tiếp cận quan hệ liên kết: Chúng ta tạo quan hệ thứ ba R để kết hợp
khóa chính của hai quan hệ S và T biểu diễn tương ứng cho các kiểu thực
thể kết hợp. Quan hệ R được gọi là quan hệ liên kết (thỉnh thoảng gọi là
bảng dò tìm) bởi vì mỗi bộ trong R biểu diễn cho một thực thể liên kết liên
quan đến một bộ trong S với một bộ trong T.
Bước 4: Ánh xạ các kiểu liên kết hai ngôi 1:N

Quy tắc 4: Ánh xạ các kiểu liên kết hai ngôi 1:N. Với mỗi cặp quan hệ S
và T biểu diễn tương ứng với hai kiểu thực thể ở phía 1 và N (nhiều) của
kiểu liên kết R hai ngôi 1:N, chúng ta thêm thuộc tính khóa chính của quan
hệ S vào thành khóa ngoại của quan hệ T.
Điều này hoàn toàn thực hiện được bởi vì mỗi thể hiện của quan hệ phía N (nhiều)
đều liên quan đến tối đa một thể hiện của quan hệ phía 1. Ngoài ra, chúng ta bổ
sung vào quan hệ T các thuộc tính đơn giản (hoặc các thành phần đơn giản của
thuộc tính kết hợp) của kiểu liên kết R.
VÍ DỤ 6.4: Ánh xạ kiểu liên kết hai ngôi một – nhiều sang quan hệ.
Trong cơ sở dữ liệu COMPANY, chúng ta ánh xạ các kiểu liên kết 1:N có tên
WORKS IN, CONTROLS, và SUPERVISES từ hình 6.3. Đối với WORKS IN,
chúng ta thêm thuộc tính khóa chính Number của DEPARTMENT vào
EMPLOYEE như là một khóa ngoại, đồng thời đặt tên thuộc tính này là DNum.
Với SUPERVISES, ta thêm khóa chính của EMPLOYEE vào thành khóa ngoại
của chính EMPLOYEE và đổi tên thuộc tính này thành supervisorSSN. Tương tự
như thế, đối với liên kết CONTROLS, ta thêm khóa chính của DEPARTMENT
vào PROJECT và đổi tên nó thành DNum.

DName EName PName
mgrSSN ESalary PLocation
mgrStartdate ESex DNum
EBirthdate
EStartdate
DNum
supervisorSSN
Hình 6.7. Ánh xạ kiểu liên kết hai ngôi một – nhiều sang quan hệ

Ngoài ra, chúng ta có thể sử dụng quan hệ liên kết để thể hiện mối liên kết hai
ngôi 1:N. Chúng ta tạo quan hệ R độc lập, với các thuộc tính của nó là khóa chính
của hai quan hệ S và T, thuộc tính khóa chính của S giữ vai trò là khóa chính trong
R. Phương án này chỉ phù hợp với trường hợp quan hệ S có ít bộ nhằm tránh
trường hợp trong R có nhiều giá trị NULL tại các thành phần khóa ngoại.
Bước 5: Ánh xạ kiểu liên kết hai ngôi N:M

Quy tắc 5: Ánh xạ kiểu liên kết hai ngôi N:M. Với mỗi kiểu liên kết R
hai ngôi N:M, chúng ta tạo quan hệ mới S để biểu diễn R, và thêm vào S
thuộc tính khóa chính của các quan hệ có liên quan đến kiểu liên kết R.
Từng thuộc tính này là khóa ngoại của S, nhưng chúng cùng nhau tạo nên

khóa chính của S. Tiếp theo, ta thêm tất cả các thuộc tính đơn (hoặc những
thành phần đơn của các thuộc tính kết hợp) vào thành thuộc tính của S.
VÍ DỤ 6.5: Ánh xạ kiểu liên kết hai ngôi nhiều – nhiều sang quan hệ.
Trong cơ sở dữ liệu COMPANY, chúng ta ánh xạ kiểu liên kết WORKS ON từ
hình 6.3 bằng cách tạo quan hệ mới có tên WORKSON. Chúng ta thêm khóa
chính của hai quan hệ PROJECT và EMPLOYEE (lần lượt là PNumber và
ESSN) vào thành các thuộc tính khóa ngoại của quan hệ WORKSON. Đồng thời,
chúng ta thêm vào quan hệ WORKSON một thuộc tính có tên workHours để biểu
diễn thuộc tính HOURS của kiểu liên kết WORKS ON. Khóa chính của quan hệ
WORKSON là kết hợp của hai thuộc tính PNumber và ESSN.
EMPLOYEE WORKSON PROJECT

ESSN ESSN PNumber
EName PNum PName
ESalary workHours PLocation
ESex DNum
EBirthdate
EStartdate
DNum
supervisorSSN
Hình 6.8. Ánh xạ kiểu liên kết hai ngôi nhiều – nhiều sang quan hệ.

Chú ý rằng chúng ta có thể ánh xạ các kiểu liên kết 1:1 và 1:N bằng cách tương tự
như đối với trường hợp N:M với một quan hệ liên kết mà chúng ta đã được tìm
hiểu ở phần trước. Cách ánh xạ này tỏ ra hữu ích trong trường hợp không có nhiều

thể hiện liên kết giữa các tập thực thể tham gia liên kết, các giá trị NULL ở các
thành phần thuộc tính khóa ngoại sẽ bị loại trừ. Đối với kiểu liên kết 1:N, khóa
chính của quan hệ liên kết chính là khóa ngoại tham chiếu tới kiểu thực thể bên N.
Đối với kiểu liên kết 1:1, cả hai khóa ngoại đều có thể được chọn là khóa chính
của quan hệ liên kết, miễn sao quan hệ mà nó tham chiếu tới không có giá trị
NULL tại thành phần khóa chính của bất kỳ thể hiện nào của quan hệ đó.
Bước 6: Ánh xạ các thuộc tính đa trị

Quy tắc 6: Ánh xạ các thuộc tính đa trị. Với mỗi thuộc tính đa trị A, tạo
một quan hệ R. Quan hệ R này chứa thuộc tính tương ứng với thuộc tính đa
trị A, cộng với thuộc tính khóa chính K của quan hệ tương ứng với kiểu
thực thể hay kiểu liên kết có thuộc tính đa trị A. Khóa chính của R là kết
hợp của A và K. Nếu thuộc tính đa trị A là thuộc tính kết hợp, chúng ta
thêm vào R tất cả các thành phần đơn của nó.
VÍ DỤ 6.6: Ánh xạ các thuộc tính đa trị.

Chúng ta tạo quan hệ DEPLOCATION với thuộc tính Location biểu diễn cho
thuộc tính đa trị Location của quan hệ DEPARTMENT, trong khi Number là
khóa ngoại, tham chiếu tới khóa chính của quan hệ DEPARTMENT. Khóa chính
của DEPLOCATION là kết hợp {DNumber, Location}. Một phòng ban có bao
nhiêu địa điểm thì sẽ có bấy nhiêu bộ tương ứng trong quan hệ DEPLOCATION.
DEPARTMENT DEPLOCATION
DNumber DNum
DName DLocation
mgrSSN
mgrStartdate
Hình 6.4. Ánh xạ các thuộc tính đa trị


Bước 7: Ánh xạ các kiểu liên kết nhiều ngôi
Quy tắc 7: Ánh xạ các kiểu liên kết nhiều ngôi. Với mỗi kiểu liên kết n –
ngôi R, với n > 2, chúng ta tạo một quan hệ mới S để biểu diễn R. Chúng ta
thêm khóa chính của tất cả các quan hệ tương ứng với các kiểu thực thể
tham gia kiểu liên kết nhiều ngôi này vào thành thuộc tính khóa ngoại của
quan hệ S. Đồng thời, chúng ta bổ sung vào S các thuộc tính đơn (hoặc các
thành phần đơn của các thuộc tính kết hợp) của kiểu liên kết R. Khóa chính
của quan hệ S thường là kết hợp của tất cả các khóa ngoại của nó.
VÍ DỤ 6.7: Ánh xạ kiểu liên kết nhiều ngôi.

Trong nhiều trường hợp, liên kết hai ngôi N:M giữa EMPLOYEE và PROJECT
được thay thế bằng một liên kết ba ngôi giữa EMPLOYEE, PROJECT, và
DEPARTMENT nhằm đáp ứng yêu cầu nhân viên thuộc phòng ban nào thì chỉ có
thể tham gia vào các dự án do phòng ban đó quản lý mà thôi. Khi đó, chúng ta tạo
quan hệ WORKSON với bốn thuộc tính lần lượt là khóa ngoại ESSN tham chiếu
tới khóa chính ESSN của EMPLOYEE, khóa ngoại PNum tham chiếu tới khóa
chính PNumber của PROJECT, khóa ngoại DNum tham chiếu tới khóa chính
DNumber của DEPARTMENT, và cuối cùng là thuộc tính workHours của kiểu
liên kết ba ngôi nói trên.

DEPARTMENT EMPLOYEE PROJECT WORKSON
DNumber ESSN PNumber ESSN
DName EName PName PNum
mgrSSN ESalary PLocation DNum
mgrStartdate ESex DNum workHours
EBirthdate
EStartdate
DNum
supervisorSSN
Hình 6.10. Ánh xạ kiểu liên kết nhiều ngôi sang quan hệ.

6.3.2 Sự tương đồng giữa mô hình thực thể kết hợp với mô hình dữ liệu
quan hệ
Qua các thao tác biến đổi đã thực hiện ở trên, chúng ta thấy rằng có một sự tương
đồng giữa mô hình thực thể kết hợp và mô hình dữ liệu quan hệ. Bảng 6.1 tóm tắt
sự tương đồng về cấu trúc và ràng buộc giữa hai mô hình này.
Một điểm cần phải chú ý trong mô hình dữ liệu quan hệ là các kiểu liên kết không
được hiện một cách tường minh như trong mô hình E/R, thay vào đó, các kiểu liên
kết được thể hiện bởi hai thuộc tính A và B, thuộc tính thứ nhất là khóa chính của
quan hệ S, thuộc tính thứ hai là khóa ngoại trong quan hệ T, cả hai thuộc tính này
có cùng miền giá trị. Hai bộ trong quan hệ S và T gọi là có liên quan với nhau, nếu
chúng có cùng giá trị đối với hai thuộc tính A và B. Bằng một phép kết bằng (hoặc
phép kết tự nhiên nếu hai thuộc tính kết có cùng tên) với S.A và T.B, chúng ta có
thể kết hợp tất cả các bộ có liên quan với nhau từ S và T. Đây chính là thể hiện của
kiểu liên kết giữa S và T. Đối với kiểu liên kết hai ngôi 1:1 hay 1:N, chúng ta chỉ
cần sử dụng một phép kết bằng, nhưng đối với kiểu liên kết hai ngôi N:M, chúng
ta cần phải sử dụng hai phép kết bằng, trong khi đối với kiểu liên kết N ngôi,
chúng ta cần tới N phép kết bằng để thể hiện nó.

VÍ DỤ 6.8: Nguyên tắc thực hiện phép kết giữa các quan hệ.
Để xác định quan hệ chứa các thuộc tính tên nhân viên (EName), tên dự án
(PName) và thời gian (workHours) mà mỗi nhân viên tham gia từng dự án, chúng
ta cần phải kết các bộ EMPLOYEE với các bộ PROJECT có liên quan thông
qua quan hệ WORKSON (hình 6.9). Do đó, chúng ta cần sử dụng phép kết bằng
quan hệ EMPLOYEE với quan hệ WORKSON, rồi kết quả thu được đem đi kết
bằng tiếp với quan hệ PROJECT. Khi kết nối nhiều quan hệ lại với nhau, chúng
ta cần chú ý đến các điều kiện kết mà thông thường liên quan đến một cặp thuộc
tính khóa chính – khóa ngoại. Nếu phép kết bằng với điều kiện kết không thể hiện
được mối liên kết khóa chính – khóa ngoại, kết quả nhận được thường không có
nhiều ý nghĩa.

BẢNG 6.1: Sự tương đồng giữa mô hình E/R và mô hình dữ liệu quan hệ
MÔ HÌNH THỰC THỂ KẾT HỢP MÔ HÌNH DỮ LIỆU QUAN HỆ

Kiểu thực thể Quan hệ thực thể
Kiểu liên kết 1:1 hay 1:N Khóa ngoại (quan hệ liên kết)
Kiểu liên kết N:M Quan hệ liên kết với hai khóa ngoại
Kiểu liên kết N–ngôi Quan hệ liên kết với N khóa ngoại
Thuộc tính đơn Thuộc tính
Thuộc tính đa trị Quan hệ và khóa ngoại
Tập giá trị Miền giá trị
Thuộc tính khóa Khóa chính (khóa phụ)
Điều thứ hai cần phải chú ý là mỗi thuộc tính đa trị trong mô hình E/R tương ứng
với một quan hệ trong mô hình dữ liệu quan hệ. Do mô hình dữ liệu quan hệ
không cho phép những kiểu dữ liệu phức tạp như danh sách hay tập hợp, do đó,
giá trị của thuộc tính đa trị phải được phân rã tương ứng với thuộc tính có kiểu dữ
liệu đơn giản.

VÍ DỤ 6.9: Phân rã thuộc tính đa trị thành quan hệ tương ứng.
Trong cơ sở dữ liệu mẫu COMPANY, phòng Phần mềm trong nước (ứng với
Number là 1) có 5 địa điểm, tương ứng với 5 bộ trong quan hệ DEPLOCATION.
Hình 6.11. Phân rã thuộc tính đa trị thành quan hệ.

6.3.3 Thiết kế cơ sở dữ liệu quan hệ từ mô hình thực thể kết hợp mở

rộng
6.3.3.1 Ánh xạ mối quan hệ chuyên biệt hóa và khái quát hóa giữa các
kiểu thực thể
Chúng ta có nhiều cách để hiện thức mối quan hệ giữa các lớp cha với các lớp con
theo hai hướng nhìn: chuyên biệt hóa và khái quát hóa. Lớp cha là khái quát hóa
của các lớp con, và ngược lại, mỗi lớp con là chuyên biệt hóa từ lớp cha. Từ quy
trình bảy bước chuyển đổi cơ sở dữ liệu quan hệ từ mô hình E/R, chúng ta bổ sung
thêm bước thứ 8 nhằm ánh xạ mối liên hệ chuyên biệt hóa giữa các kiểu thực thể
sang dữ liệu quan hệ.
Bước 8: Ánh xạ mối quan hệ chuyên biệt hóa và khái quát hóa
Giả định rằng chúng ta có m lớp con {S1, S2, …, Sm} và lớp cha tương ứng C, với
các thuộc tính của C là {k, a1, a2, …, an} với k là thuộc tính khóa chính của C.
Chúng ta có thể ánh xạ mối quan hệ nói trên sang mô hình dữ liệu quan hệ bằng
một trong bốn quy tắc sau đây:
Quy tắc 8A: Mỗi quan hệ ứng với một lớp. Chúng ta tạo quan hệ L cho lớp
C với các thuộc tính tương ứng là {k, a1, a2, …, an}, với k là khóa chính của
L. Tiếp theo, với mỗi lớp con Si, chúng ta tạo một quan hệ Li bao gồm các
thuộc tính của lớp Si cộng với thuộc tính khóa chính k của lớp C. Khóa
chính của Li cũng chính là khóa chính của L (tức là k). Quy tắc này áp dụng
cho mọi kiểu chuyên biệt hóa.
Quy tắc 8B: Mỗi lớp con tương ứng với một quan hệ. Với mỗi lớp con Si
chúng ta tạo một quan hệ Li bao gồm các thuộc tính của lớp Si cộng với các
thuộc tính của lớp C. Khóa chính của quan hệ Li là k. Quy tắc này chỉ áp
dụng cho kiểu chuyên biệt hóa toàn phần, nghĩa là mọi thực thể trong lớp
cha phải xuất hiện trong ít nhất một lớp con.
Quy tắc 8C: Sử dụng một quan hệ với một thuộc tính phân loại. Chúng ta
tạo duy nhất một quan hệ L bao gồm tất cả thuộc tính của các lớp C, S1, S2,
…, Sm cộng với một thuộc tính t. Khóa chính của quan hệ L này là k. Thuộc
tính t được gọi là thuộc tính phân loại nhằm xác định bộ đang xét là thực
thể của lớp con tương ứng nào. Quy tắc này chỉ áp dụng cho kiểu chuyên
hóa tách biệt, nghĩa là các lớp con không chồng chéo lên nhau, Ngoài ra áp
dụng quy tắc này có thể phát sinh nhiều giá trị NULL nếu các lớp con có
nhiều thuộc tính.
Quy tắc 8D: Sử dụng một quan hệ với nhiều thuộc tính phân loại. Chúng
ta tạo duy nhất một quan hệ L bao gồm tất cả thuộc tính của các lớp C, S1,
S2, …, Sm cộng với các thuộc tính phân loại {t1, t2, …, tm} ứng với m lớp
con. Khóa chính của quan hệ L này là k. Thuộc tính ti có kiểu Boolean, trả
về kết quả là TRUE nếu bộ đang xét ứng với một thực thể thuộc lớp con Si.
VÍ DỤ 6.10: Ánh xạ mối liên kết cha/con thông qua thuộc tính phân lớp.
Ánh xạ mối liên kết cha/con giữa các lớp SECRETARY, ENGINEER, và
DRIVER với EMPLOYEE thông qua thuộc tính phân lớp JobType

Hình 6.12. Các liên kết cha/con trong CSDL COMPANY
Quy tắc 8A: Các quan hệ được tạo tương ứng là

EMPLOYEE(ESSN, EName, ESalary, ESex, EBirthdate, EStartdate)
SECRETARY(ESSN, TypingSpeed)
DRIVER(ESSN, VehicleType)
ENGINEER(ESSN, EngType)
Quy tắc 8B: Các quan hệ được tạo tương ứng là
EMPLOYEE(ESSN, EName, ESalary, ESex, EBirthdate, EStartdate)
SECRETARY(ESSN, …, EStartdate , TypingSpeed)
DRIVER(ESSN, …, EStartdate, VehicleType)
ENGINEER(ESSN, …, EStartdate, EngType)
Quy tắc 8C: Một quan hệ duy nhất được tạo ra với lược đồ là
EMPLOYEE(ESSN, …, EStartdate, TypingSpeed, VehicleType,
EngType, JobType)
Quy tắc 8D: Một quan hệ duy nhất được tạo ra với lược đồ là
EMPLOYEE(ESSN, …, EStartdate, TypingSpeed, VehicleType,
EngType, Secretary, Service, Engineer)


6.3.3.2 Ánh xạ các lớp con chung
Lớp con dùng chung, như là lớp ENGINEERING_MANAGER trong hình 3.6, là
lớp con của nhiều lớp cha có cùng thuộc tính khóa. Mối liên hệ này còn được gọi
là đa thừa kế. Chúng ta có thể áp dụng một trong bốn quy tắc đã nêu ở mục 6.2.1
để ánh xạ lớp con chung vào trong mô hình dữ liệu quan hệ.
VÍ DỤ 6.11: Ánh xạ các lớp con chung.
Hình 6.13. Lớp con chung KEY_MAN trong mối liên hệ đa thừa kế.
Lớp con chung này có thể được biểu diễn bởi một quan hệ cùng tên, chứa các
thuộc tính của EMPLOYEE, ENGINEER và FULLTIME (mỗi thuộc tính trùng
nhau chỉ xuất hiện một lần) cùng với các thuộc tính riêng của nó như sau:
KEY_MAN (ESSN, …, EStartdate, EngType, Position)

Như vậy, với tất cả các quy tắc đã nêu ở trên, chúng ta có thể xây dựng một lược
đồ CSDL quan hệ từ mô hình thực thể kết hợp (mở rộng). Lược đồ CSDL ứng với
bài toán mẫu được trình bày ở mục 2.2 được trình bày trong hình vẽ sau đây.

WORKSON EMPLOYEE DEPARTMENT
ESSN ESSN DNumber
PNum EName DName
workHours ESalary mgrSSN
ESex mgrStartdate
EBirthdate
EStartdate
PROJECT
DNum
PNumber
supervisorSSN
PName DEPLOCATION
PLocation DNum
DNum DLocation
DEPENDENT
DName
ESSN
DSex
DBirthdate
DRelationship
Hình 6.14. Lược đồ cơ sở dữ liệu COMPANY ứng với mô hình ở hình 6.3.

DName EName PName
mgrSSN ESalary PLocation
mgrStartdate ESex DNum
EBirthdate
EStartdate
DEPLOCATION DNum WORKSON

DNum supervisorSSN ESSN
DLocation TypingSpeed PNum
VehicleType DNum
EngType workHours
DEPENDENT Qualification
DName Experienced
ESSN Fulltime KEYMAN

ESSN
DSex
EngType
DBirthdate
Position
DRelationship
Hình 6.15. Lược đồ cơ sở dữ liệu COMPANY ứng với mô hình ở hình 6.4.

6.4 TÓM TẮT
Một cơ sở dữ liệu tốt phải đáp ứng đầy đủ tất cả yêu cầu của người sử dụng thông
qua bản đặc tả dữ liệu. Để có thể phản ánh chính xác thế giới thực, cơ sở dữ liệu
cần phải được thiết kế một cách chi tiết và đúng đắn. Do đó, trong chương này
chúng ta tập trung nghiên cứu một quy trình thiết kế cơ sở dữ liệu từ bước đầu tiên
cho đến bước cuối cùng, khi một lược đồ cơ sở dữ liệu được cài đặt trong một hệ
quản trị cơ sở dữ liệu cụ thể.
Chúng ta đã tìm hiểu các bước thiết kế mô hình thực thể kết hợp (mở rộng) ở mức
trừu tượng cao từ bản đặc tả yêu cầu dữ liệu của người sử dụng. Sau đó, chúng ta
nghiên cứu quy trình gồm bảy bước để chuyển đổi mô hình thực thể kết hợp sang
lược đồ cơ sở dữ liệu. Cuối cùng, chúng ta hoàn chỉnh lược đồ cơ sở dữ liệu với
các tinh chỉnh phù hợp với các vấn đề có liên quan đến sự phân cấp của dữ liệu
(mô hình thực thể kết hợp mở rộng).
Tóm lại, kết thúc chương này, người đọc đã được trang bị đầy đủ kiến thức và sẵn
sàng thực hiện nhiệm vụ thiết kế cơ sở dữ liệu quan hệ ứng dụng cho các hệ thống
thông tin từ những bản đặc tả yêu cầu người sử dụng có sẵn.

C
CHHƯ
ƯƠƠN
NGG
7
NGÔN NGỮ TRUY VẤN
CÓ CẤU TRÚC
Mục tiêu
Chương này cung cấp cho người đọc các kiến thức từ cơ bản đến nâng cao về
ngôn ngữ dữ liệu phổ biến nhất trên thị trường hiện nay, ngôn ngữ được sử dụng
làm nền tảng cho mọi hệ quản trị cơ sở dữ liệu quan hệ. Đó là ngôn ngữ truy vấn
có cấu trúc.
Nội dung
Định nghĩa dữ liệu và các kiểu dữ liệu
Các ràng buộc cơ bản trong SQL
Các câu lệnh thay đổi lược đồ cơ sở dữ liệu
Các truy vấn cơ bản trong SQL
Các câu truy vấn phức tạp
Các lệnh cập nhật dữ liệu trong SQL

Giới thiệu
Ngày nay, người ta có thể khẳng định rằng một trong những nguyên nhân chính
dẫn đến sự thành công về mặt thương mại của các sản phẩm cơ sở dữ liệu quan hệ
đó là chúng được xây dựng trên nền tảng ngôn ngữ truy vấn có cấu trúc (Structure
Query Language, viết tắt là SQL). Với các tiêu chuẩn của SQL, người dùng không
phải lo ngại về vấn đề chuyển đổi ứng dụng từ các hệ thống cơ sở dữ liệu khác về
cơ sở dữ liệu quan hệ. Lý do đơn giản là vì cho đến nay mọi hệ thống cơ sở dữ liệu
đều được xây dựng trên các ngôn ngữ truy vấn được phát triển từ ngôn ngữ SQL
chuẩn. Một ứng dụng phát triển trên hệ cơ sở dữ liệu SQL Server của Microsoft,
nếu không sử dụng các chức năng đặc biệt chỉ có riêng ở sản phẩm này, đều có thể
dễ dàng chuyển đổi sang các hệ cơ sở dữ liệu khác, như là Oracle của Oracle
Corp., DB2 của IBM, …, và ngược lại. Một điều thuận lợi nữa là người dùng có
thể thực hiện các câu lệnh truy vấn trên nhiều hệ quản trị cơ sở dữ liệu quan hệ
(Relational Database Management System, viết tắt là RDBMS) khác nhau, mà
không cần phải thay đổi ngôn ngữ truy vấn, vì các RDBMS này đều hỗ trợ ngôn
ngữ SQL chuẩn.
Trong chương này, chúng tôi trình bày các đặc trưng chính của ngôn ngữ SQL
chuẩn được dùng trong các RDBMS thương mại hóa, vốn được xây dựng trên nền
tảng mô hình dữ liệu quan hệ. SQL được chính thức công nhận theo chuẩn ANSI(1)
và ISO(2) từ năm 1986. Trải qua nhiều phiên bản kế tiếp, SQL ngày càng hoàn
thiện, hỗ trợ nhiều chức năng giúp xây dựng và quản trị cơ sở dữ liệu một cách
nhanh chóng, hiệu quả, và an toàn.

7.1 ĐỊNH NGHĨA DỮ LIỆU VÀ CÁC KIỂU DỮ
LIỆU
SQL sử dụng các thuật ngữ bảng, hàng, và cột tương ứng với các thuật ngữ quan
hệ, bộ, và thuộc tính trong mô hình dữ liệu quan hệ. Để định nghĩa dữ liệu trong
SQL, chúng ta sử dụng lệnh CREATE. Lệnh này được dùng để định nghĩa lược đồ
quan hệ, miền giá trị, và nhiều cấu trúc lưu trữ khác. Trước khi đi vào chi tiết về
câu lệnh CREATE, chúng ta tìm hiểu các khái niệm về lược đồ và danh mục trong
SQL. Tiếp theo, chúng tôi thiệu cách thức tạo mới một đối tượng lưu trữ quan
trọng nhất trong cơ sở dữ liệu quan hệ, đó là bảng dữ liệu. Trong quá trình tạo
bảng, chúng ta phải xác định kiểu dữ liệu cho từng thuộc tính trong bảng. Các kiểu
dữ liệu cơ bản được SQL hỗ trợ sẽ được trình bày trong phần 7.1.3.
7.1.1 Khái niệm lược đồ và danh mục trong SQL

Các phiên bản trước đây của SQL không đề cập đến khái niệm lược đồ cơ sở dữ
liệu quan hệ, tất cả các bảng (quan hệ) đều được xem là một phần của lược đồ cơ
sở dữ liệu chung. Khái niệm lược đồ SQL được đề cập đến bắt đầu từ SQL2. Các
bảng dữ liệu phục vụ cho cùng một ứng dụng được gom chung trong một lược đồ
cơ sở dữ liệu. Lược đồ SQL được xác định bởi tên lược đồ, tài khoản tạo lược đồ,
và mô tả từng thành phần của lược đồ đó. Thành phần của lược đồ có thể là bảng
dữ liệu, ràng buộc toàn vẹn, khung nhìn view, miền giá trị, … Lược đồ SQL được
tạo bằng lệnh CREATE SCHEMA.
VÍ DỤ 7.1: Tạo lược đồ cơ sở dữ liệu bằng lệnh CREATE SCHEMA.

Để tạo lược đồ SQL có tên là COMPANY, với tài khoản tạo là SA, chúng ta sử
dụng câu lệnh như sau:
CREATE SCHEMA COMPANY AUTHORIZATION SA

Nói chung, không phải tất cả tài khoản sử dụng đều có quyền tạo lược đồ SQL, và
các thành phần của nó. Việc cấp quyền tạo lược đồ SQL, bảng, và các cấu trúc

khác do quản trị hệ thống (System Administrator, viết tắt là SA) hay quản trị cơ sở
dữ liệu (Database Administrator, viết tắt là DBA) thực hiện.
Ngoài khái niệm về lược đồ, SQL2 còn sử dụng khái niệm danh mục như là bộ
sưu tập các lược đồ cơ sở dữ liệu trong môi trường SQL. Danh mục SQL chứa
lược đồ SQL đặc biệt có tên INFORMATION_SCHEMA để lưu giữ thông tin về
các lược đồ có trong danh mục và tất cả mô tả có trong các lược đồ này. Các ràng
buộc toàn vẹn như là ràng buộc tham chiếu chỉ có thể được định nghĩa giữa các
bảng trong cùng một danh mục. Ngoài ra, một số thành phần nào đó trong lược đồ
này (ví dụ như định nghĩa miền giá trị) có thể được sử dụng lại trong lược đồ khác,
với điều kiện các lược đồ này nằm trong cùng một danh mục.
7.1.2 Lệnh tạo bảng CREATE TABLE trong SQL

Lệnh CREATE TABLE được dùng để khởi tạo quan hệ mới bằng cách xác định
tên bảng, liệt kê các thuộc tính, và định nghĩa các ràng buộc toàn vẹn trên bảng đó.
Đối với từng thuộc tính chúng ta cần phải xác định tên thuộc tính, kiểu giá trị ứng
với miền giá trị của thuộc tính đó, đồng thời cũng phải định nghĩa các ràng buộc
trên thuộc tính, ví dụ như ràng buộc giá trị mặc định DEFAULT hay ràng buộc
NOT NULL. Khóa chính, ràng buộc toàn vẹn thực thể, và ràng buộc toàn vẹn
tham chiếu có thể được xác định bên trong câu lệnh CREATE TABLE ngay sau
phần khai báo thuộc tính, hoặc chúng có thể được bổ sung vào sau khi hoàn tất câu
lệnh CREATE TABLE bằng cách sử dụng câu lệnh ALTER TABLE (xem 7.3).
Các quan hệ được định nghĩa bằng lệnh CREATE TABLE được gọi là các bảng
cơ sở (quan hệ cơ sở), nghĩa là quan hệ và các bộ của nó được tạo ra và lưu trữ vật
lý trong tệp tin dữ liệu của DBMS. Đối lập với quan hệ cơ sở là quan hệ ảo được
tạo thông qua câu lệnh CREATE VIEW, kết quả tạo ra và các dữ liệu của nó
không được lưu trữ vật lý trong DBMS. Trong SQL các thuộc tính của bảng cơ sở
được xem là có trật tự, ứng với trật tự khi định nghĩa các thuộc tính đó trong câu

lệnh CREATE TABLE. Ngược lại, trật tự của các hàng (các bộ) trong bảng dữ liệu
lại không được chú trọng đến.
CREATE TABLE DEPARTMENT( CREATE TABLE PROJECT(
DNumber int, PNumber int,
DName nvarchar(50), PName nvarchar(50),
mgrSSN decimal(18,0), PLocation nvarchar(50),
mgrStartdate datetime DNum int
) )
CREATE TABLE EMPLOYEE( CREATE TABLE WORKSON(

ESSN decimal(18, 0), ESSN decimal(18, 0),
EName nvarchar(50), PNum int,
ESalary decimal(18, 0), workHours int
ESex char(1), )
EBirthdate datetime,
EStartdate datetime, CREATE TABLE DEPENDENT(
DNum int, DName nvarchar(50),
supervisorSSN decimal(18, 0) ESSN decimal(18,0),
) DSex char(1),
DBirthdate datetime,
CREATE TABLE DEPLOCATION( DRelationship nvarchar(50)
DNum int, )
DLocation nvarchar(50)
)
Hình 7.1. Các câu lệnh định nghĩa lược đồ cơ sở dữ liệu COMPANY
7.1.3 Các kiểu dữ liệu và miền giá trị của thuộc tính
Các kiểu dữ liệu cơ bản được sử dụng trong SQL bao gồm kiểu dữ liệu số, kiểu dữ
liệu chuỗi ký tự, kiểu dữ liệu chuỗi bit, kiểu Boolean, kiểu dữ liệu ngày giờ. Cụ
thể như sau:
Kiểu dữ liệu số bao gồm các kiểu số nguyên với kích thước khác nhau
(INTEGER hay INT, và SMALLINT), các kiểu dữ liệu dấu chấm động
(FLOAT hay REAL, và DOUBLE PRECISION). Ngoài ra còn có các kiểu
số thập phân DECIMAL(i,j), với i số chữ số trong phần nguyên, và j là số
chữ số phần thập phân.
Kiểu dữ liệu chuỗi ký tự bao gồm các kiểu dữ liệu có chiều dài cố định như
là CHAR(n) hay CHARACTER(n), với n là số ký tự trong chuỗi. Ngoài ra,

chúng ta còn có thể sử dụng các kiểu dữ liệu có chiều dài thay đổi, ví dụ
VARCHAR(n), CHAR VARYING(n), CHARACTER VARYING(n), với
n là số ký tự tối đa trong chuỗi. Khi khai báo một giá trị chuỗi ký tự, chúng
ta phải đặt nó trong cặp nháy đơn ‘’, và chú ý phân biệt chữ hoa chữ
thường. Đối với kiểu chuỗi có chiều dài cố định là n, nếu chúng ta có chuỗi
chỉ bao gồm m ký tự (m < n), chúng ta thêm n – m ký tự khoảng trắng vào
bên phải chuỗi ký tự đó, và kết quả, chúng ta có chuỗi gồm đúng n ký tự.
Hai chuỗi ký tự có thể so sánh với nhau theo trật tự abc, cụ thể nếu chuỗi
str1 xuát hiện trước chuỗi str2 trong trật tự abc, thì chúng ta nói rằng chuỗi
str1 nhỏ hơn chuỗi str2. Ngoài ra, phép nối hai chuỗi || cũng được sử dụng
trong các kiểu dữ liệu chuỗi ký tự. Ví dụ, kết quả của phép nối ‘abc’ ||
‘XYZ’ là một chuỗi ‘abcXYZ’.
Các kiểu dữ liệu chuỗi bit cũng bao gồm kiểu dữ liệu có chiều dài cố định –
BIT(n), với n là số bit trong chuỗi – và kiểu dữ liệu có chiều dài thay đổi –
BIT VARYING(n), với n là số bit tối đa trong chuỗi. Giá trị mặc định của n
là 1. Chuỗi bit cũng được đặt trong cặp nháy đơn, nhưng trước đó là chữ B
để phân biệt với chuỗi ký tự thông thường, ví dụ B’10110101010’.
Kiểu dữ liệu Boolean với các giá trị TRUE và FALSE. Trong SQL, với sự
xuất hiện của giá trị NULL, chúng ta có ba giá trị luận lý thường dùng, đó
là TRUE, FALSE, và UNKNOWN. Chúng ta sẽ trình bày chi tiết kiểu dữ
liệu Boolean với ba giá trị cơ bản này ở phần 7.5.1.
Kiểu dữ liệu ngày giờ chỉ mới xuất hiện từ SQL2. Kiểu dữ liệu DATE có
ba thành phần YEAR, MONTH, và DAY trong định dạng YYYY–MM–
DD. Kiểu dữ liệu TIME cũng có ba thành phần là HOUR, MINUTE, và
SECOND trong định dạng HH:MM:SS. Chỉ những ngày giờ trong định
dạng hợp lệ mới được SQL chấp nhận. Phép so sánh nhỏ hơn < cũng được
sử dụng giữa hai giá trị ngày giờ. Giá trị ngày giờ được đặt trong cặp nháy
đơn, và để phân biệt với chuỗi ký tự hay chuỗi bit, chúng ta sử dụng chữ

DATE hay TIME đằng trước nó, ví dụ như DATE’2009–04–18’ hay
TIME’21:05:00’.
Trong khi định nghĩa các bảng dữ liệu bằng lệnh CREATE TABLE, chúng ta có
thể sẽ dùng đi dùng lại nhiều lần cùng một kiểu dữ liệu cho các thuộc tính ở các
bảng khác nhau. Để câu lệnh CREATE TABLE của chúng ta đơn giản và dễ hiểu
hơn, chúng ta định nghĩa sẵn một miền giá trị, và sử dụng miền giá trị này tại các
khai báo thuộc tính phù hợp.
VÍ DỤ 7.2: Định nghĩa miền giá trị bằng lệnh CREATE DOMAIN.
Chúng ta có thể định nghĩa miền giá trị SSN_TYPE như sau:
CREATE DOMAIN SSN_TYPE AS DECIMAL(18,0)
Tiếp theo, chúng ta sử dụng SSN_TYPE thay thế cho DECIMAL(18,0) trong hình
7.1 đối với các thuộc tính ESSN, supervisorSSN của EMPLOYEE, mgrSSN của
DEPARTMENT, ESSN của WORKSON, và ESSN trong DEPENDENT. Cụ thể
chúng ta có thể tạo bảng DEPARTMENT bằng câu lệnh sau đây:
CREATE TABLE DEPARTMENT(
DNumber int ,
DName nvarchar(50),
mgrSSN SSN_TYPE,
mgrStartdate datetime
)

7.2 CÁC RÀNG BUỘC CƠ BẢN TRONG SQL

Trong câu lệnh tạo bảng, ngoài việc liệt kê danh sách các thuộc tính kèm theo kiểu
dữ liệu – miền giá trị của chúng, chúng ta còn có thể khai báo các ràng buộc toàn
vẹn dữ liệu. Các ràng buộc loại này bao gồm ràng buộc khóa chính, ràng buộc
toàn vẹn tham chiếu, ràng buộc miền giá trị, ràng buộc NOT NULL, và ràng buộc
liên bộ trong một quan hệ.

7.2.1 Ràng buộc toàn vẹn NOT NULL và ràng buộc toàn vẹn miền giá
trị
Do SQL cho phép các thuộc tính có giá trị NULL, vì thế đôi khi chúng ta cần dùng
ràng buộc NOT NULL để xác thực rằng thuộc tính đó không được phép có giá trị
NULL. Bất kỳ thuộc tính nào, nếu có yêu cầu không được nhận giá trị rỗng, đều có
thể đặt là NOT NULL. Một thuộc tính, nếu là thành phần của khóa chính, thì mặc
nhiên là NOT NULL.
VÍ DỤ 7.3: Khai báo ràng buộc NOT NULL trong lệnh tạo bảng.
Câu lệnh tạo bảng DEPARTMENT với các ràng buộc toàn vẹn NOT NULL như
sau:
CREATE TABLE DEPARTMENT(
DNumber int NOT NULL,
DName nvarchar(50) NOT NULL,
mgrSSN decimal(18, 0),
mgrStartdate datetime
)
Với định nghĩa này, trong quá trình thêm phòng ban mới vào bảng, chúng ta bắt
buộc phải cung cấp giá trị tại các thuộc tính DNumber và DName.Trong trường
hợp một trong hai giá trị này là NULL, ràng buộc NOT NULL bị vi phạm, kết quả
là hệ quản trị CSDL sẽ thông báo lỗi và từ chối thực hiện thao tác này.

Hơn nữa, chúng ta còn có thể khai báo giá trị mặc định cho các thuộc tính bằng
cách sử dụng từ khóa DEFAULT <giá trị mặc định> trong định nghĩa thuộc tính.
Ví dụ 7.4 minh họa cách khai báo giá trị mặc định cho một thuộc tính trong câu
lệnh tạo bảng dữ liệu.
VÍ DỤ 7.4: Khai báo giá trị mặc định trong lệnh tạo bảng.
Giả sử trong lệnh tạo bảng EMPLOYEE , thuộc tính ESalary được cài đặt có giá
trị mặc định là 35,000 như câu lệnh sau đây:
CREATE TABLE EMPLOYEE(
ESSN decimal(18, 0),
EName nvarchar(50),
ESalary decimal(18, 0) DEFAULT 35000,
ESex char(1),
…
)
Với định nghĩa này, trong quá trình thêm nhân viên mới vào bảng, nếu chúng ta
không cung cấp giá trị cho thuộc tính ESalary , nhân viên này sẽ nhận giá trị lương
là 35,000, đúng như giá trị mặc định mà chúng ta khai báo ban đầu. Rõ ràng, nếu
thuộc tính không được khai báo giá trị mặc định một cách tường minh, thì giá trị
mặc định mà thuộc tính này nhận được là NULL (trong trường hợp không có ràng
buộc NOT NULL).

Một loại ràng buộc toàn vẹn khác liên quan đến miền giá trị của thuộc tính đó là
ràng buộc toàn vẹn miền giá trị sử dụng từ khóa CHECK theo sau khai báo thuộc
tính.
VÍ DỤ 7.5: Khai báo ràng buộc miền giá trị trong lệnh tạo bảng.
Để thể hiện ràng buộc miền giá trị đối với thuộc tính ESex trong bảng
EMPLOYEE chúng ta sử dụng câu lệnh tạo bảng như sau:
ESSN decimal(18, 0),
EName nvarchar(50),
ESalary decimal(18, 0),
ESex char(1) check (empSex in ('F','M')),
…
)
Trong trường hợp này, chúng ta quy ước ‘F’ là viết tắt của female tức là giới tính
nữ, còn ‘M’ là viết tắt của male tức là giới tính nam.


7.2.2 Khóa chính và ràng buộc toàn vẹn tham chiếu
Như đã trình bày ở chương trước, một quan hệ có thể có nhiều khóa, tập hợp các
thuộc tính dùng để phân biệt duy nhất từng thực thể trong quan hệ, trong số đó
chúng ta chọn ra một khóa và gọi là khóa chính, các khóa còn lại có tên gọi là
khóa duy nhất hay là khóa phụ.
Để định nghĩa khóa chính (phụ), chúng ta sử dụng mệnh đề PRIMARY KEY
(UNIQUE) trong câu lệnh định nghĩa cấu trúc bảng dữ liệu. Có hai cách để định
nghĩa khóa chính trong quan hệ:
Mệnh đề PRIMARY KEY (UNIQUE) đặt ngay sau thuộc tính khóa chính
của quan hệ.
Mệnh đề PRIMARY KEY (UNIQUE) đặt sau phần khai báo tất cả các
thuộc tính của quan hệ.
Ràng buộc toàn vẹn tham chiếu được thể hiện thông qua mệnh đề FOREIGN KEY
trong câu lệnh tạo bảng. Như đã trình bày ở mục 4.2.4, ràng buộc toàn vẹn tham
chiếu có thể bị vi phạm khi thực hiện các thao tác xử lý dữ liệu (thêm, xóa), hoặc
khi sửa các giá trị thuộc tính khóa chính, khóa ngoại. Khi một thao tác làm cho
ràng buộc toàn vẹn tham chiếu bị vi phạm, SQL mặc định sẽ hủy bỏ việc thực hiện
thao tác đó. Tuy nhiên, chúng ta có thể tự mình ghi nhận và có những hình thức xử
lý trong trường hợp ràng buộc bị vi phạm, bằng cách sử dụng mệnh đề
REFERENTIAL TRIGGERD ACTION. Các hình thức xử lý có thể là đưa về giá
trị NULL (SET NULL), xóa tất cả các bộ có liên quan (CASCADE), hoặc đưa về
giá trị mặc định (SET DEFAULT). Hình 6.6 và hình 6.7 dưới đây minh họa cho
việc khai báo khóa chính và khóa ngoại trong định nghĩa lược đồ cơ sở dữ liệu
COMPANY.
VÍ DỤ 7.6: Khai báo khóa chính, khóa phụ trong lệnh tạo bảng.
Các câu lệnh định nghĩa bảng dữ liệu cho COMPANY với các khai báo khóa
chính, khóa phụ cho từng bảng dữ liệu:

CREATE TABLE DEPARTMENT( CREATE TABLE PROJECT(
DNumber int PRIMARY KEY, PNumber int PRIMARY KEY,
DName nvarchar(50) UNIQUE, PName nvarchar(50) UNIQUE,
mgrSSN decimal(18,0), PLocation nvarchar(50),
mgrStartdate datetime DNum int
) )
CREATE TABLE EMPLOYEE( CREATE TABLE WORKSON(

ESSN decimal(18, 0) PRIMARY ESSN decimal(18, 0),
KEY, PNum int,
EName nvarchar(50), workHours int,
ESalary decimal(18, 0), PRIMARY KEY(ESSN, PNum)
… )
DNum int,
supervisorSSN decimal(18, 0) CREATE TABLE DEPENDENT(
) DName nvarchar(50),
ESSN decimal(18,0),
CREATE TABLE DEPLOCATION( …
DNum int, DRelationship nvarchar(50),
DLocation nvarchar(50), PRIMARY KEY(DName, ESSN)
PRIMARY KEY(DNum, DLocation) )
)

VÍ DỤ 7.7: Khai báo ràng buộc toàn vẹn tham chiếu trong lệnh tạo bảng.
Câu lệnh sau đây định nghĩa bảng PROJECT, trong đó có khai báo ràng buộc
toàn vẹn tham chiếu đến bảng DEPARTMENT kèm theo các hình thức xử lý mỗi
khi ràng buộc này bị vi phạm
CREATE TABLE PROJECT(
PNumber int PRIMARY KEY,
PName nvarchar(50) UNIQUE,
PLocation nvarchar(50),
DNum int REFERENCES DEPARTMENT(DNumber)
ON UPDATE CASCADE
ON DELETE SET NULL
)

7.2.3 Đặt tên cho các ràng buộc toàn vẹn
Mỗi một đối tượng trong DBMS đều có một tên gọi, dù là tường minh (do chúng
ta đặt), hay là không tường minh (DBMS tự động đặt). Và để có thể chủ động
trong việc quản lý các đối tượng do chúng ta khai báo và định nghĩa, chúng ta nên
đặt tên cho chúng một cách tường minh. Giả sử chúng ta định nghĩa một ràng buộc
toàn vẹn khóa phụ cho thuộc tính PName trong quan hệ PROJECT, và chúng ta
nhường quyền đặt tên ràng buộc này DBMS. Tuy nhiên, sau một thời gian hệ
thống hoạt động, nhận thấy ràng buộc toàn vẹn này không cần thiết, và chúng ta
muốn xóa nó đi. Làm thế nào để xóa một đối tượng ra khỏi hệ thống, nếu chúng ta
không biết đối tượng đó tên gọi là gì. Chính vì lý do đó, đối với những đối tượng
do chúng ta định nghĩa, chúng ta nên đặt tên tường minh cho chúng. Để đặt tên
cho ràng buộc toàn vẹn, chúng ta sử dụng từ khóa CONSTRAINT, và theo sau là
tên của ràng buộc toàn vẹn.
VÍ DỤ 7.8: Đặt tên cho ràng buộc toàn vẹn trong lệnh tạo bảng.
Câu lệnh sau đây định nghĩa bảng PROJECT, kèm theo khai báo ràng buộc toàn
vẹn khóa phụ trên thuộc tính PName:
CREATE TABLE PROJECT(
PNumber int PRIMARY KEY,
PName nvarchar(50),
PLocation nvarchar(50),
DNum int REFERENCES DEPARTMENT(DNumber)
ON UPDATE CASCADE
ON DELETE SET NULL,
CONSTRAINT UK_PName UNIQUE (PName)
)

7.2.4 Khai báo ràng buộc toàn vẹn trên bộ sử dụng CHECK
Ngoài ràng buộc khóa chính và ràng buộc toàn vẹn tham chiếu, trong bảng dữ liệu
còn có nhiều loại ràng buộc toàn vẹn khác. Các ràng buộc này được khai báo bởi

mệnh đề CHECK được đặt ở cuối câu lệnh CREATE TABLE. Các ràng buộc loại
này được gọi là ràng buộc trên bộ, bởi vì chúng được áp dụng cho từng bộ cụ thể,
và được kiểm tra mỗi khi thêm mới hay thay đổi một bộ.
VÍ DỤ 7.9: Khai báo ràng buộc miền giá trị sử dụng CHECK.
Trong quan hệ EMPLOYEE, thuộc tính EStartdate lưu trữ thông tin về thời điểm
bắt đầu làm việc chính thức của nhân viên, còn thuộc tính EBirthdate ngày sinh
của nhân viên. Rõ ràng để có thể làm việc tại công ty, nhân viên phải trên 18 tuổi
tính tại thời điểm bắt đầu làm việc. Câu lệnh định nghĩa bảng EMPLOYEE với
khai báo ràng buộc toàn vẹn nói trên được viết như sau:
ESSN decimal(18, 0) PRIMARY KEY,
EName nvarchar(50),
ESalary decimal(18, 0),
ESex char(1),
EBirthdate datetime,
EStartdate datetime,
supervisorSSN decimal(18, 0),
CHECK (year(EStartdate) - year(EBirthdate) >= 18)
)
Ở đây, chúng ta sử dụng hàm year() được định nghĩa sẵn trong hầu hết các hệ quản
trị CSDL để trả về giá trị năm của đối số truyền vào.

7.3 CÁC CÂU LỆNH THAY ĐỔI LƯỢC ĐỒ CƠ SỞ DỮ LIỆU

TRONG SQL
Trong mục này, chúng ta sẽ tìm hiểu các câu lệnh được dùng để định nghĩa lại
lược đồ cơ sở dữ liệu. Chúng ta có thể thêm, xóa hoặc sửa các bảng dữ liệu, các
thuộc tính, các ràng buộc toàn vẹn, và những thành phần khác trong cơ sở dữ liệu.

7.3.1 Lệnh DROP
Lệnh DROP được dùng để xóa các thành phần được đặt tên một cách tường minh
trong cơ sở dữ liệu, ví dụ như bảng dữ liệu, miền giá trị, hay ràng buộc toàn vẹn.
Thậm chí nếu cần, chúng ta còn có thể dùng lệnh DROP SCHEMA để xóa toàn bộ
lược đồ cơ sở dữ liệu ra khỏi hệ thống.
VÍ DỤ 7.10: Xóa lược đồ cơ sở dữ liệu bằng lệnh DROP SCHEMA.

Để xóa lược đồ cơ sở dữ liệu COMPANY và tất cả bảng dữ liệu, miền giá trị, và
các thành phần khác trong nó, chúng ta sử dụng câu lệnh sau:
DROP SCHEMA COMPANY

Trong trường hợp một quan hệ nào đó trong lược đồ dữ liệu COMPANY không
còn cần thiết nữa, chúng ta có thể xóa quan hệ này bằng cách dùng lệnh DROP
TABLE.
VÍ DỤ 7.11: Xóa quan hệ bằng lệnh DROP TABLE.

Nếu chúng ta không cần quan tâm đến thông tin về người thân của nhân viên,
chúng ta có thể xóa quan hệ DEPENDENT ra khỏi cơ sở dữ liệu COMPANY như
sau:
DROP TABLE DEPENDENT
Khi chúng ta thực hiện câu lệnh này, không chỉ toàn bộ dữ liệu trong bảng
DEPENDENT bị xóa, mà bản thân bảng này cũng bị xóa ra khỏi cơ sở dữ liệu.

7.3.2 Lệnh ALTER
Định nghĩa của bảng dữ liệu hay của những thành phần dữ liệu có tên khác của cơ
sở dữ liệu có thể được thay đổi bằng cách sử dụng lệnh ALTER. Đối với bảng dữ
liệu, chúng ta có thể sử dụng lệnh ALTER để thêm mới hoặc xóa cột (thuộc tính),
thay đổi định nghĩa cột, thêm hoặc xóa ràng buộc toàn vẹn.

VÍ DỤ 7.12: Thêm thuộc tính vào trong bảng bằng lệnh ALTER TABLE.
Để bổ sung thông tin về số điện thoại liên lạc của mỗi nhân viên, chúng ta dùng
lệnh sau đây:
ALTER TABLE EMPLOYEE ADD EPhone nvarchar(50)
Kết quả là bảng EMPLOYEE có thêm cột tên EPhone, và với mỗi hàng trong
bảng EMPLOYEE, giá trị tại thuộc tính EPhone là NULL. Tiếp theo, chúng ta
phải sử dụng lệnh UPDATE (xem mục 7.6) để cập nhật giá trị này cho từng hàng
trong bảng EMPLOYEE.

VÍ DỤ 7.13: Xóa thuộc tính ra khỏi bảng bằng lệnh ALTER TABLE.
Để xóa thuộc tính EPhone khỏi bảng EMPLOYEE, chúng ta sử dụng lệnh sau
đây:
ALTER TABLE EMPLOYEE DROP COLUMN EPhone

VÍ DỤ 7.14: Thêm ràng buộc mới vào trong bảng bằng lệnh ALTER TABLE.
Để tạo ràng buộc toàn vẹn mới trên bảng, chúng ta phải xóa ràng buộc cũ và thêm
ràng buộc mới vào quan hệ. Quá trình được thực hiện bởi hai câu lệnh SQL như
sau:
ALTER TABLE EMPLOYEE DROP CONSTRAINT FK_Emp_Dep
ALTER TABLE EMPLOYEE ADD CONSTRAINT FK_Emp_Dep
FOREIGN KEY (DNum)
REFERENCES DEPARTMENT (DNumber)

7.4 CÁC TRUY VẤN CƠ BẢN TRONG SQL

SQL hỗ trợ truy xuất thông tin từ cơ sở dữ liệu bằng câu lệnh SELECT. Câu lệnh
SELECT này không có liên quan gì tới phép toán chọn σ trong đại số quan hệ. Có
rất nhiều tùy chọn, cũng như cách sử dụng câu lệnh SELECT trong SQL, vì thế

trước tiên chúng ta sẽ tìm hiểu những thuộc tính cơ bản của nó, rồi sau đó sẽ đi sâu
nghiên cứu các câu truy vấn phức tạp sử dụng câu lệnh SELECT này.
Trước khi bắt đầu, chúng ta phải hiểu sự khác biệt cơ bản giữa SQL và mô hình dữ
liệu quan hệ được trình bày ở chương 4. SQL cho phép bảng dữ liệu (hay quan hệ)
có nhiều hàng (bộ) trùng nhau. Vì thế, bảng dữ liệu SQL không phải là tập hợp các
bộ, như khái niệm quan hệ trong mô hình dữ liệu quan hệ. Nhiều bảng dữ liệu
SQL được xem như là tập hợp các bộ không trùng nhau nếu như chúng ta khai báo
ràng buộc khóa chính đối với một (số) thuộc tính của bảng đó.
7.4.1 Cấu trúc SELECT – FROM – WHERE

Câu truy vấn trong SQL có thể rất phức tạp. Chúng ta sẽ bắt đầu với những câu
truy vấn đơn giản, sau đó sẽ từng bước tiếp cận tới các câu truy vấn phức tạp hơn.
Câu lệnh truy vấn đơn giản nhất có dạng SELEC–FROM–WHERE như sau:
SELECT <attribute list>
FROM <table list>
WHERE <condition>;
Trong đó
<attribute list> là tên các thuộc tính sẽ hiển thị trong phần kết quả của
câu truy vấn
<table list> là tên các bảng dữ liệu được sử dụng bởi câu truy vấn
<condition> là biểu thức điều kiện xác định các bộ được hiển thị trong
phần kết quả của câu truy vấn. Biểu thức điều kiện là chuỗi các phép so
sánh được kết hợp với nhau bởi các phép toán lôgic như AND, OR, và
NOT. Các phép so sánh có thể là =, <, <=, >, >=, <>. Chúng ta có thể so
sánh giá trị của hai thuộc tính với nhau, hay so sánh giá trị của một
thuộc tính với một giá trị hằng.
VÍ DỤ 7.15: Truy vấn dữ liệu bằng cấu trúc SELECT – FROM – WHERE.
Cho biết tên và mức lương của (các) nhân viên trong phòng có mã số là 1:
Q1: SELECT EName, ESalary
FROM EMPLOYEE
WHERE dNum=1
Câu truy vấn này chỉ liên quan tới một quan hệ là EMPLOYEE được liệt kê trong
mệnh đề FROM. Câu truy vấn chọn trong quan hệ EMPLOYEE các bộ thỏa mãn
điều kiện trong mệnh đề WHERE, sau đó chiếu kết quả nhận được trên các thuộc
tính EName và ESalary. Q0 tương tự với biểu thức đại số quan hệ sau đây, ngoại
trừ việc các bộ trùng nhau sẽ bị triệt tiêu:
Q1: πEName, ESalary σdNum = 1 (EMPLOYEE)
Câu truy vấn Q0 cũng cho kết quả tương tự với phép tính quan hệ sau đây, ngoại
trừ việc nó cho phép xuất hiện các bộ trùng nhau trong phần kết quả truy vấn:
Q1: {t.EName,t.ESalary | t∈EMPLOYEE AND t.dNum=1}
Ở đây, chúng ta có thể hiểu biến bộ t duyệt qua tất cả các bộ trong bảng
EMPLOYEE, và tính giá trị điều kiện trong mệnh đề WHERE. Chỉ những bộ cho
giá trị TRUE mới được hiển thị trong phần kết quả của câu truy vấn.

Qua ví dụ trên, chúng ta nhận thấy rằng câu truy vấn SQL đơn giản với một bảng
dữ liệu trong mệnh đề FROM rất giống với cặp phép toán chọn – chiếu (SELECT
– PROJECT) trong đại số quan hệ. Mệnh đề SELECT xác định các thuộc tính
chiếu, còn mệnh đề WHERE xác định điều kiện chọn. Đặc biệt, trong phần kết quả
của câu lệnh SQL cho phép các bộ trùng lặp nhau nếu không có ràng buộc toàn
vẹn khóa chính hay khóa duy nhất.
VÍ DỤ 7.16: Câu truy vấn sử dụng hai bảng trong mệnh đề FROM.
Cho biết mã số và tên của những dự án do phòng Phần mềm nước ngoài quản lý.
Q2: SELECT PNumber, PName
FROM PROJECT, DEPARTMENT
WHERE DName = N’Phòng Phần mềm nước ngoài ‘
AND DNumber = dNum
Truy vấn Q1 tương tự như chuỗi các phép toán đại số quan hệ SELECT–
PROJECT–JOIN. Trong mệnh đề WHERE của Q1, điều kiện DName = ‘Phòng
Phần mềm nước ngoài’ là điều kiện chọn, tương ứng với phép chọn σ trong đại số
quan hệ. Điều kiện DNumber = dNum là điều kiện kết, tương ứng với phép kết
JOIN trong đại số quan hệ

VÍ DỤ 7.17: Câu truy vấn sử dụng ba bảng trong mệnh đề FROM.
Với mỗi dự án tại ‘TP. Hồ Chí Minh’, liệt kê số hiệu dự án, số hiệu đơn vị quản lý
dự án, và tên, mức lương của trưởng đơn vị quản lý dự án.
Q3: SELECT p.PNumber, d.DNumber, e.EName, e.ESalary
FROM PROJECT p, DEPARTMENT d, EMPLOYEE e
WHERE p.DNum = d.DNumber
AND mgrSSN = ESSN
AND PLocation = N'TP. Hồ Chí Minh'
Điều kiện kết DNum = DNumber kết nối dự án với đơn vị quản lý nó, trong khi
điều kiện kết mgrSSN = ESSN kết nối đơn vị quản lý dự án với nhân viên quản lý
đơn vị đó.

7.4.2 Các thuộc tính trùng tên, bí danh
SQL cho phép các thuộc tính có thể có tên trùng nhau miễn là chúng thuộc về
những quan hệ khác nhau. Tuy nhiên, trong trường hợp này, nếu câu truy vấn sử
dụng hai hay nhiều thuộc tính trùng tên, chúng ta phải xác định tên quan hệ kèm
theo tên thuộc tính để tránh sự mập mờ. Chúng ta thực hiện việc này bằng cách
xác định tên quan hệ và tên thuộc tính theo mẫu <tên quan hệ>.<tên thuộc tính>.
Như vậy, tên quan hệ sẽ được lặp lại nhiều lần trong câu truy vấn. Để hạn chế việc
này, chúng ta có thể sử dụng bí danh (alias) hay biến bộ (tuple variable).
VÍ DỤ 7.18: Sử dụng bí danh trong câu truy vấn.

Với mỗi nhân viên, cho biết họ tên nhân viên và họ tên người quản lý trực tiếp của
nhân viên đó.
Q4: SELECT e.EName, s.Ename
FROM EMPLOYEE e, EMPLOYEE s
WHERE e.supervisorSSN = s.ESSN

Chú ý rằng, nếu muốn, chúng ta có thể sử dụng cơ chế đặt bí danh trong mọi câu
truy vấn để xác định biến bộ cho từng quan hệ trong mệnh đề WHERE để làm câu
truy vấn trở nên gọn gàng và dễ hiểu hơn.
7.4.3 Một số trường hợp đặc biệt

Chúng ta tìm hiểu hai trường hợp đặc biệt đối với SQL: câu truy vấn không có
mệnh đề WHERE, và phép chọn tất cả các thuộc tính. Câu truy vấn không có
mệnh đề WHERE là câu truy vấn không có điều kiện chọn, tất cả các bộ của quan
hệ xác định trong mệnh đề FROM đều xuất hiện trong kết quả của câu truy vấn.
Nếu có nhiều hơn một quan hệ trong mệnh đề FROM và không có mệnh đề
WHERE, thì câu truy vấn này là một phép nhân chéo, nghĩa là tất cả sự kết hợp có
thể có của hai quan hệ này đều xuất hiện trong phần kết quản của câu truy vấn. Ví
dụ sau đây minh họa cho truy vấn không có mệnh đề WHERE.
VÍ DỤ 7.19: Câu truy vấn không có mệnh đề WHERE.

Xét hai câu truy vấn không có mệnh đề WHERE.
Q5: SELECT ESSN
FROM EMPLOYEE
Q6: SELECT ESSN, DName
FROM EMPLOYEE, DEPARTMENT

Chúng ta có thể dễ dàng nhận thấy, trong câu truy vấn, nếu bỏ sót điều kiện chọn
và điều kiện kết, kết quả truy vấn có thể không chính xác, hoặc không có ý nghĩa.
Chẳng hạn trong Q6, nếu chúng ta có 100 nhân viên, và có 10 đơn vị. Kết quả
mong đợi là 100 bộ dữ liệu chứa thông tin về số hiệu nhân viên, và tên đơn vị mà
nhân viên đó làm việc. Nhưng theo Q6, kết quả trả về chứa 1000 bộ dữ liệu, nghĩa
là có tới 900 bộ dữ liệu dư thừa.

Ngoài ra, để truy xuất tất cả các giá trị thuộc tính của các bộ được chọn trong câu
truy vấn, chúng ta không cần phải liệt kê một cách cụ thể các thuộc tính đó. Thay
vào đó, chúng ta chỉ cần sử dụng ký hiệu hoa thị (*) với ý nghĩa tất cả các thuộc
tính.
VÍ DỤ 7.20: Hiển thị tất cả thông tin của các bảng trong mệnh đề FROM.
Tất cả thông tin về nhân viên làm việc trong đơn vị có mã số là 5.
Q7: SELECT *
FROM EMPLOYEE
WHERE dNum = 5
Tất cả thông tin về nhân viên và về đơn vị có tên Phòng Nghiên cứu mà nhân viên
đó công tác.
Q8: SELECT *
FROM EMPLOYEE, DEPARTMENT
WHERE DName=N’Phòng Nghiên cứu và phát triển’
AND dNum=DNumber

7.4.4 Khái niệm tập hợp trong SQL
Như chúng ta đã biết, SQL xử lý bảng không phải như là một tập hợp – mỗi phần
tử chỉ xuất hiện duy nhất một lần. Các bộ trùng lặp có thể xuất hiện nhiều lần
trong bảng, và trong kết quả của câu lệnh truy vấn. SQL không tự động triệt tiêu
các bộ trùng lặp trong kết quả của câu truy vấn vì những lý do sau:
Loại bỏ các bộ trùng lặp xuất hiện ngẫu nhiên là thao tác tốn kém. Một giải
pháp phù hợp là sắp xếp các bộ rồi mới loại bỏ các bộ trùng lặp.
Người dùng có thể quan tâm đến sự trùng lặp trong kết quả truy vấn.
Các bộ trùng lặp có ý nghĩa đặc biệt quan trọng khi thực hiện các hàm kết
hợp.
Với thuộc tính khóa, bảng trong SQL chính là một tập hợp, khi giá trị thuộc tính
khóa phải là duy nhất. Nếu chúng ta muốn loại bỏ các bộ trùng lặp khỏi kết quả

của câu truy vấn SQL, chúng ta sử dụng từ khóa DISTINCT trong mệnh đề
SELECT. Một cách tổng quát, câu truy vấn với SELECT DISTINCT sẽ loại bỏ
các bộ trùng lặp, trong khi câu truy vấn với SELECT ALL sẽ không loại bỏ các bộ
trùng lặp. Câu truy vấn SQL không có SELECT DISTINCT lẫn SELECT ALL sẽ
được hiểu như là với SELECT ALL.
VÍ DỤ 7.21: Dùng từ khóa DISTINCT để loại bỏ các bộ trùng nhau.

Xét hai truy vấn sau đây
Q11: SELECT ALL DLocation
FROM DEPLOCATION
Q12: SELECT DISTINCT DLocation
FROM DEPLOCATION
Dễ dàng nhận thấy, cả hai truy vấn đều liệt kê tên các địa điểm mà tại đó công ty
có văn phòng đại diện (của ít nhất một phòng ban nào đó). Điểm khác biệt chính ở
đây là, kết quả của truy vấn Q11 cho phép một địa điểm xuất hiện nhiều lần (ứng
với số văn phòng đại diện có mặt tại địa điểm đó), còn truy vấn Q12 chỉ cho phép
một địa điểm xuất hiện duy nhất một lần trong kết quả trả về.

SQL cho phép sử dụng trực tiếp các phép toán tập hợp của đại số quan hệ. Các
phép toán này bao gồm phép hội (UNION), phép trừ (EXCEPT), và phép giao
(INTERSECT). Kết quả trả về của các phép toán này là tập hợp các bộ, do đó các
bộ trùng lặp sẽ bị loại bỏ ra khỏi kết quả. Ngoài ra, các phép toán tập hợp chỉ áp
dụng đối với các quan hệ có tính khả hợp, do đó chúng ta phải đảm bảo các quan
hệ được áp dụng phải có các thuộc tính giống nhau, và trật tự xuất hiện của chúng
trong các quan hệ cũng phải giống nhau. Ví dụ 7.22 minh họa cho việc ứng dụng
trực tiếp các phép toán tập hợp của đại số quan hệ để giải quyết một số yêu cầu
truy vấn đặc thù.
VÍ DỤ 7.22: Câu truy vấn sử dụng phép toán hợp.

Cho biết danh sách các dự án có liên quan tới nhân viên có tên là ‘Võ Việt Anh’
với tư cách là trưởng đơn vị phụ trách, hoặc là nhân viên tham gia dự án.
Q13: (SELECT DISTINCT p.*
FROM PROJECT p, DEPARTMENT d, EMPLOYEE e
WHERE p.DNum=d.DNumber AND mgrSSN=ESSN
AND EName=N'Võ Việt Anh')
UNION
(SELECT DISTINCT p.*
FROM PROJECT p, WORKSON w, EMPLOYEE e
WHERE p.PNumber=w.PNum AND w.ESSN=e.ESSN
AND EName=N'Võ Việt Anh')
Câu truy vấn SELECT đầu tiên cho biết các dự án liên quan tới nhân viên có tên là
‘Anh’ với tư cách là trưởng đơn vị phụ trách dự án đó. Câu truy vấn thứ hai cho
kết quả là các dự án có nhân viên tên ‘Anh’ tham gia. Áp dụng phép hội UNION
với hai câu truy vấn trên, chúng ta được kết quả như mong đợi.

SQL cũng cho phép chúng ta thực hiện các phép toán tập hợp mà không tự động
loại bỏ các bộ trùng nhau bằng cách sử dụng từ khóa ALL ngay sau phép toán tập
hợp (UNION ALL, EXCEPT ALL, INTERSECT ALL). Trong trường hợp này,
mỗi bộ – dù trùng lặp hay không – đều được xem là một bộ riêng biệt.
7.4.5 Toán tử so sánh chuỗi và toán tử số học

Trong phần này, chúng ta sẽ thảo luận nhiều đặc trưng khác của SQL. Đặc trưng
đầu tiên cho phép thực hiện so sánh với từng phần của chuỗi ký tự bằng cách sử
dụng toán tử so sánh LIKE. Chuỗi ký tự được đặt trong cặp nháy đơn (‘’), ký hiệu
% thay thế cho một chuỗi ký tự có chiều dài bất kỳ (kể cả zero), ký hiệu _ đại diện
cho chuỗi có một ký tự bất kỳ.
VÍ DỤ 7.23: Câu truy vấn sử dụng toán tử so sánh chuỗi.

Liệt kê các nhân viên có họ Trần:
Q14: SELECT *

FROM EMPLOYEE
WHERE EName LIKE N‘Trần%’
Một điều cần chú ý là do có nhu cầu muốn sử dụng tiếng Việt trong dữ liệu, cho
nên chúng ta đã sử dụng các kiểu ký tự Unicode khi khai báo các lệnh tạo bảng.
Cũng ví thế, trong quá trình vận hành cơ sở dữ liệu, mọi dữ liệu có liên quan đến
chuỗi ký tự tiếng Việt đều phải đặt trong cặp ký tự N‘’ (N đại diện cho Unicode).

Nếu ký tự _ hay % xuất hiện trong chuỗi ký tự cần xử lý, chúng ta cần phải sử
dụng thêm toán tử \ ở đằng trước. Ví dụ, để SQL hiểu chuỗi ký tự ‘AB_CD%EF’,
chúng ta cần phải viết là ‘AB\_CD\%EF’.
Ngoài ra, câu truy vấn SQL còn cho phép chúng ta sử dụng các phép tính toán,
như cộng (+), trừ (-), nhân (*), và chia (/) với các giá trị số, hoặc các thuộc tính có
miền giá trị số học.
VÍ DỤ 7.24: Câu truy vấn sử dụng phép toán số học ở mệnh đề SELECT.
Liệt kê các nhân viên làm việc trong dự án ‘ProductC’ với mức lương tăng 10%.
Q15: SELECT EName, 1.1*ESalary AS INCREASED_SAL
FROM EMPLOYEE e, WORKSON w, PROJECT p
WHERE e.ESSN=w.ESSN AND w.PNum=p.PNumber
AND proName=’ProjectC’

Đối với các kiểu dữ liệu chuỗi, toán tử kết hợp || có thể được dùng để nối hai chuỗi
lại với nhau. Ngoài các toán tử nói trên, chúng ta còn có thể dùng phép toán
BETWEEN trong mệnh đề WHERE như trong ví dụ 7.25 sau đây.
VÍ DỤ 7.25: Sử dụng phép toán BETWEEN trong mệnh đề WHERE.

Liệt kê các nhân viên có mức lương từ $30,000 đến $80,000.
Q16: SELECT *
FROM EMPLOYEE

WHERE (ESalary BETWEEN 30000 AND 80000)

7.4.6 Sắp xếp kết quả truy vấn
SQL cho phép người sử dụng sắp xếp các bộ trong kết quả truy vấn theo giá trị của
một hay nhiều thuộc tính bằng mệnh đề ORDER BY. Chúng ta sử dụng từ khóa
ASC, hay DESC để thực hiện sắp xếp theo chiều tăng dần, hoặc giảm dần. Nếu
chúng ta không xác định kiểu sắp xếp, SQL tự hiểu là sắp xếp theo chiều tăng dần.
Ví dụ 7.26 minh họa kết quả của một câu truy vấn có sử dụng mệnh đề sắp xếp.
VÍ DỤ 7.26: Câu truy vấn sử dụng mệnh đề ORDER BY.

Liệt kê danh sách nhân viên trong phòng số 5 theo thứ tự giảm dần của lương.
FROM EMPLOYEE
WHERE DNum = 5
ORDER BY ESalary DESC

7.5 CÁC CÂU TRUY VẤN PHỨC TẠP

Trong phần trước, chúng ta đã tìm hiểu một số loại truy vấn SQL cơ bản. Tiếp
theo chúng ta sẽ làm quen với một số loại truy vấn phức tạp với mục đích phát huy
thế mạnh của ngôn ngữ này.
7.5.1 Các phép so sánh liên quan tới giá trị NULL
SQL có nhiều quy tắc để xử lý giá trị NULL. Giá trị NULL có các ý nghĩa sau đây:
Unknown value (giá trị chưa biết): mỗi người đều có ngày sinh, nhưng
chúng ta chưa biết ngày sinh của nhân viên Võ Việt Anh, vì thế bộ dữ liệu
của nhân viên này có giá trị NULL tại thuộc tính EBirthdate.

Unavailable or withheld value (giá trị không có hay giữ kín): Nhân viên có
điện thoại nhà, nhưng không muốn cung cấp, do vậy nó được giữ kín, và
thể hiện là NULL trong cơ sở dữ liệu.
Not applicable attribute (thuộc tính không dùng được): Thuộc tính
supervisorSSN phải để NULL, nếu nhân viên đó không có người quản lý
trực tiếp. Thuộc tính này không áp dụng được đối với nhân viên đó.
SQL thường sẽ không phân biệt giá trị NULL trong cơ sở dữ liệu có ý nghĩa gì
trong ba ý nghĩa nêu trên. Khi giá trị NULL xuất hiện trong phép so sánh, giá trị
trả về sẽ là UNKNOWN (có thể đúng, hoặc có thể sai). Chính vì vậy, kết quả của
một biểu thức luận lý trong SQL có thể là TRUE, FALSE, hay UNKNOWN. SQL
cho phép kiểm tra giá trị thuộc tính là NULL hay không bằng cách sử dụng toán tử
IS NULL, và IS NOT NULL.
VÍ DỤ 7.27: Câu truy vấn sử dụng giá trị NULL.

Liệt kê danh sách nhân viên không có lãnh đạo trực tiếp.
Q18: SELECT *
FROM EMPLOYEE
WHERE supervisorSSN IS NULL

7.5.2 Truy vấn lồng, các phép so sánh trên bộ và tập hợp
Nhiều câu truy vấn yêu cầu các giá trị có được sau khi thực hiện truy vấn từ cơ sở
dữ liệu tiếp tục được sử dụng trong mệnh đề so sánh. Những câu truy vấn như thế
này có tên gọi là truy vấn lồng, vì trong mệnh đề WHERE của câu truy vấn này
(câu truy vấn cha) có mệnh đề SELECT của câu truy vấn khác (câu truy vấn con).
Trong trường hợp tổng quát, câu truy vấn con sẽ trả về kết quả là một bảng được
xem như là tập hợp gồm nhiều bộ dữ liệu, vì thế, phép toán so sánh đi kèm với nó
là những phép toán so sánh một giá trị đơn (hoặc một bộ gồm nhiều giá trị đơn)
với một tập hợp nhiều giá trị đơn (hoặc nhiều bộ). Nếu câu truy vấn con trả về một
thuộc tính và một bộ duy nhất, kết quả này được xem như là một giá trị đơn.
Trong trường hợp này, thay vì dùng phép toán so sánh giá trị đơn với tập hợp
nhiều giá trị (IN, NOT IN, …), chúng ta có thể dùng toán tử so sánh một giá trị
với một giá trị khác (=, ≥, ≤, …).
VÍ DỤ 7.28: Sử dụng truy vấn lồng trong mệnh đề WHERE.

Cho biết danh sách các dự án có sự tham gia của nhân viên tên là ‘Lê Duy Anh’.
Q19: SELECT *
FROM PROJECT
WHERE PNumber IN
(SELECT w.PNum
FROM WORKSON w, EMPLOYEE e
WHERE w.ESSN=e. ESSN AND e.EName = N’Lê Duy Anh’)

Ngoài toán tử IN, chúng ta còn thể sử dụng nhiều toán tử khác để so sánh một giá
trị đơn v (thường là tên thuộc tính) với một tập hợp V gồm nhiều giá trị khác
(thường là một câu truy vấn lồng). Toán tử = ANY (hay = SOME) cho kết quả
TRUE nếu giá trị v bằng với ít nhất một giá trị trong tập hợp V (giống như định
nghĩa của toán tử IN). Nhiều phép so sánh khác cũng có thể kết hợp với từ khóa
ANY, và SOME như là >, >=, <, <=, và <>. Từ khóa ALL cũng có thể kết hợp với
các toán tử này. Ví dụ, mệnh đề điều kiện (v > ALL V) có giá trị là TRUE khi giá
trị v lớn hơn tất cả các giá trị trong tập hợp V.
VÍ DỤ 7.30: Sử dụng toán tử ALL trong mệnh đề WHERE.

Cho biết tên của các nhân viên có mức lương cao hơn tất cả các nhân viên trong
phòng số 5.
Q20: SELECT EName
FROM EMPLOYEE
WHERE ESalary >= ALL (SELECT ESalary

FROM EMPLOYEE
WHERE dNum = 5)

Một vấn đề cần phải chú ý khi thực hiện các câu truy vấn lồng, đó là trường hợp
các thuộc tính có tên giống nhau xuất hiện nhiều lần trong câu truy vấn lồng. Để
phân biệt chúng, chúng ta sử dụng các bí danh như đã đề cập ở các phần trước.
VÍ DỤ 7.31: Sử dụng bí danh trong câu truy vấn lồng.

Cho biết các nhân viên trùng tên trong công ty.
Q21: SELECT E.*
FROM EMPLOYEE E
WHERE E.ESSN NOT IN (SELECT ESSN
FROM EMPLOYEE
WHERE E.EName=EName
AND E.ESSN <> ESSN)
Trong trường hợp này chúng ta phải sử dụng E.EName để ám chỉ thuộc tính
EName của quan hệ EMPLOYEE trong câu truy vấn cha, bởi vì trong phạm vi
của câu truy vấn con, EMPLOYEE cũng có thuộc tính có tên là EName.

7.5.3 Câu truy vấn lồng tương quan
Mỗi khi điều kiện trong mệnh đề WHERE của câu truy vấn con tham chiếu với
các thuộc tính của quan hệ được khai báo trong câu truy vấn cha, hai câu truy vấn
này được gọi là có tương quan với nhau. Điều này có nghĩa là câu truy vấn con
được thực hiện ứng với từng bộ (hoặc tổ hợp của nhiều bộ) trong câu truy vấn cha.
Ví dụ trong câu truy vấn Q21, với mỗi bộ nhân viên E trong EMPLOYEE, tính
giá trị của câu truy vấn con – liệt kê các danh sách mã số nhân viên có cùng tên
với nhân viên E; nếu giá trị ESSN của bộ E không xuất hiện trong kết quả của câu
truy vấn con, thì chọn bộ nhân viên E đó đưa ra phần kết quả của câu truy vấn cha.

Trong nhiều trường hợp câu truy vấn lồng sử dụng toán tử so sánh = hoặc IN có
thể được thay thế bởi một câu truy vấn đơn.
VÍ DỤ 7.32: Truy vấn lồng có thể được thay thế bởi một truy vấn đơn.
Câu truy vấn Q21 có thể viết lại bằng truy vấn đơn như sau:
Q22: SELECT DISTINCT E.EName
FROM EMPLOYEE E1, EMPLOYEE E2
WHERE E1.ESSN<>E2.ESSN AND E1.EName=E2.EName

7.5.4 Hàm EXISTS trong SQL
Hàm EXISTS trong SQL được dùng để kiểm tra kết quả của câu truy vấn lồng
tương quan có rỗng hay không. Với Q là kết quả của một câu truy vấn,
EXISTS(Q) cho ra giá trị TRUE nếu Q chứa ít nhất một bộ, ngược lại sẽ cho ra giá
trị FALSE.
VÍ DỤ 7.32: Sử dụng EXISTS trong câu truy vấn lồng tương quan.
Câu truy vấn Q21 có thể viết lại với hàm EXISTS như sau:
Q23: SELECT E.*
FROM EMPLOYEE E
WHERE EXISTS (SELECT *
FROM EMPLOYEE
WHERE E.EName=EName
AND E.ESSN <> ESSN)
Trong Q23, câu truy vấn con tham chiếu tới các thuộc tính ESSN và EName của
quan hệ EMPLOYEE từ câu truy vấn cha. Chúng ta có thể nghĩ Q23 như sau:
Với mỗi bộ nhân viên E trong EMPLOYEE, tính toán tất cả các bộ trong quan hệ
EMPLOYEE thỏa mãn điều kiện trùng tên với E nhưng không phải E. Nếu tồn tại
ít nhất một bộ trong quan hệ EMPLOYEE thỏa mãn các điều kiện trên, thì nhân
viên E được chọn xuất hiện trong kết quả trả về của câu truy vấn cha.


VÍ DỤ 7.33: Sử dụng NOT EXISTS trong câu truy vấn lồng tương quan.
Cho biết tên các nhân viên chưa tham gia bất kỳ dự án nào của công ty.
Q24: SELECT EName
FROM EMPLOYEE E
WHERE NOT EXISTS (SELECT *
FROM WOKRSON
WHERE E.ESSN=ESSN)
Trong câu truy vấn Q24, câu truy vấn con trả về tất cả dự án có sự tham gia của
nhân viên E. Nếu kết quả trả về là rỗng, thì nhân viên E đó được coi là chưa tham
gia dự án nào cả.

7.5.5 Tập hợp tường minh và đổi tên các thuộc tính trong SQL
Chúng ta đã xem xét nhiều có truy vấn lồng trong mệnh đề WHERE. Tuy nhiên,
nhiều trường hợp, thay vì dùng câu truy vấn lồng, chúng ta có thể dùng tập hợp
gồm nhiều giá trị cụ thể được khai báo tường minh trong mệnh đề WHERE.
VÍ DỤ 7.34: Câu truy vấn với các giá trị cụ thể được khai báo tường minh.
Cho biết mã số nhân viên làm việc trong các dự án có mã số lần lượt 1, 2, và 3.
Q25: SELECT DISTINCT ESSN
FROM WORKSON
WHERE proNum IN (1,2,3)

Trong SQL, chúng ta có thể đổi tên các thuộc tính xuất hiện trong phần kết quả
của câu truy vấn bằng cách thêm từ khóa AS và tên mới mong muốn vào sau tên
thuộc tính muốn đổi tên. Từ khóa AS được dùng để khai báo bí danh cho cả thuộc
tính và quan hệ, được sử dụng trong mệnh đề SELECT và mệnh đề FROM.
VÍ DỤ 7.35: Đổi tên hiển thị của câu truy vấn.

Với mỗi nhân viên hãy hiển thị tên của người đó và tên của lãnh đạo trực tiếp của
họ.
Q26: SELECT E.EName AS ‘Tên nhân viên’,
S.EName AS ‘Tên lãnh đạo trực tiếp’
FROM EMPLOYEE AS E, EMPLOYEE AS S
WHERE E.supervisorSSN=S.ESSN;

7.5.6 Bảng kết trong SQL
Trong SQL, phép kết không chỉ thực hiện trong mệnh đề WHERE, mà còn thực
hiện trong mệnh đề FROM với các từ khóa OUTER JOIN, INNER JOIN, LEFT
JOIN, và RIGHT JOIN. Khái niệm bảng kết trong SQL cho phép người dùng thực
hiện việc kết nối giữa các bảng ngay trong mệnh đề FROM giúp tăng tốc độ xử lý
của câu truy vấn.
VÍ DỤ 7.36: Sử dụng phép kết trong câu truy vấn.

Hiển thị tên và mức lương của các nhân viên trong phòng ‘Nghiên cứu’.
FROM EMPLOYEE JOIN DEPARTMENT ON DNum=DNumber
WHERE DName=N’Phòng Nghiên cứu’
Trong mệnh đề FROM của Q27 có một bảng kết, là kết quả của phép kết nối các
thuộc tính của bảng EMPLOYEE với các thuộc tính của bảng DEPARTMENT,
mỗi bộ của bảng EMPLOYEE sẽ kết với các bộ của bảng DEPARTMENT sao
cho thỏa mãn điều kiện kết DNum = DNumber.

Kiểu kết mặc định là kiểu kết trong, khi với mọi bộ xuất hiện trong bảng kết là kết
quả của việc kết nối hai bộ trong các bảng tham gia phép kết đó. Ví dụ trong câu
truy vấn Q26, chỉ những nhân viên có người quản lý trực tiếp mới được xuất hiện
trong kết quả trả về; những nhân viên có giá trị NULL cho thuộc tính
supervisorSSN đều bị bỏ qua. Nếu câu truy vấn yêu cầu liệt kê mọi nhân viên và
tên người quản lý trực tiếp (nếu có), chúng ta phải sử dụng phép kết ngoài (xem
mục 5.4.3). Trong SQL, chúng ta hiện thực phép kết ngoài như ví dụ sau đây.
VÍ DỤ 7.37: Sử dụng phép kết ngoài trái trong câu truy vấn.
Với mỗi nhân viên hãy hiển thị tên của người đó và tên của lãnh đạo trực tiếp của
họ.
Q28: SELECT E.EName AS ‘Tên nhân viên’,
S.EName AS ‘Tên lãnh đạo trực tiếp’
FROM (EMPLOYEE E LEFT OUTER JOIN EMPLOYEE S
ON E.supervisorSSN=S.ESSN)

Các kiểu kết có thể được sử dụng bao gồm INNER JOIN (giống như JOIN), LEFT
OUTER JOIN, RIGHT OUTER JOIN, và FULL OUTER JOIN. Trong trường hợp
các thuộc tính kết có tên trùng nhau, chúng ta có thể thêm từ khóa NATURAL vào
trước các câu lệnh JOIN nói trên để chúng trở thành những câu lệnh kết tự nhiên.
Chú ý rằng bảng kết trong SQL là kết quả của phép kết hai hay nhiều bảng với
nhau. Điều này có nghĩa là kết quả của một phép kết lại tham gia trong một phép
kết khác.
VÍ DỤ 7.38: Câu truy vấn sử dụng nhiều phép kết xuất hiện liên tiếp nhau
Với mỗi dự án tại ‘TP. Hồ Chí Minh’, liệt kê số hiệu dự án, số hiệu đơn vị quản lý
dự án, và tên, ngày sinh của trưởng đơn vị quản lý dự án.
Q29: SELECT PNumber, DNumber, EName, EBirthdate
FROM ((PROJECT JOIN DEPARTMENT ON dNum=DNumber)
JOIN EMPLOYEE ON mgrSSN=ESSN)
WHERE PLocation = N’TP Hồ Chí Minh’

7.5.7 Các hàm kết hợp trong SQL

Trong chương trước, chúng ta đã tìm hiểu khái niệm về các hàm kết hợp được sử
dụng trong đại số quan hệ. SQL cho phép sử dụng thao tác gom nhóm, và các hàm
kết hợp được định nghĩa sẵn như là COUNT, SUM, MAX, MIN, và AVG. Hàm

COUNT cho biết số lượng các bộ hoặc các giá trị trả về trong câu truy vấn. Các
hàm SUM, MAX, MIN, và AVG được áp dụng cho tập hợp các giá trị số, kết quả
trả về tương ứng là tổng, giá trị lớn nhất, giá trị nhỏ nhất, giá trị trung bình của tập
hợp các giá trị số đó. Các hàm này được sử dụng trong mệnh đề SELECT hoặc
mệnh đề HAVING (sẽ được giới thiệu ở phần tiếp theo). Hàm MAX, MIN còn
được áp dụng đối với các giá trị không phải là số, nhưng thuộc miền giá trị có thứ
tự. Chúng ta xem xét các ví dụ sau đây để hiểu rõ hơn về các hàm kết hợp và cách
sử dụng chúng trong SQL.
VÍ DỤ 7.39: Câu truy vấn sử dụng hàm kết hợp.

Cho biết tổng lương, lương trung bình của nhân viên trong công ty.
Q30: SELECT SUM(ESalary), AVG(ESalary)
FROM EMPLOYEE

Cho biết tổng lương, mức lương cao nhất, mức lương thấp nhất, và của các nhân
viên tham gia dự án có mã số là 1.
Q31: SELECT SUM(E.ESalary), MAX(E.ESalary), MIN(E.ESalary)
FROM (EMPLOYEE E JOIN WORKSON W ON E.ESSN=W.ESSN)
WHERE W.PNUM = 1

Ngoài ra, chúng ta còn có thể sử dụng các hàm kết hợp trong câu truy vấn lồng
như là một điều kiện so sánh trong mệnh đề WHERE.

Liệt kê danh sách nhân viên tham gia ít nhất 5 dự án:
Q32: SELECT E.EName
FROM EMPLOYEE E
WHERE (SELECT COUNT(*)
FROM WORKSON
WHERE E.ESSN= ESSN) >=5

7.5.8 Phép gom nhóm với các mệnh đề GROUP BY và HAVING
Trong nhiều trường hợp, chúng ta muốn gom các bộ trong quan hệ thành từng
nhóm và thực hiện các hàm kết hợp trên từng nhóm đó, chẳng hạn, chúng ta muốn
biết mức lương trung bình của mỗi phòng ban trong công ty, hoặc số lượng nhân
viên tham gia từng dự án. Để giải quyết vấn đề này, chúng ta cần phải phân chia
quan hệ ra thành những nhóm riêng rẽ. Các bộ được phân chia vào cùng một nhóm
sẽ có giá trị giống nhau ở một số thuộc tính nào đó. Các thuộc tính này được gọi là
các thuộc tính gom nhóm. SQL cung cấp khả năng gom nhóm các bộ trong quan
hệ bằng cách sử dụng mệnh đề GROUP BY theo sau là các thuộc tính gom nhóm.
Chú ý rằng, trong mệnh đề SELECT của câu truy vấn có mệnh đề GROUP BY,
chúng ta chỉ được quyền truy xuất đến hoặc là các thuộc tính gom nhóm, hoặc là
các hàm kết hợp COUNT, MAX, MIN, SUM, AVG đã trình bày ở phần trên.
VÍ DỤ 7.42: Câu truy vấn với mệnh đề GROUP BY.

Với mỗi phòng ban hãy cho biết mã số phòng ban, số nhân viên thuộc quyền quản
lý của phòng ban đó, và mức lương trung bình của họ.
Q33: SELECT DNum, COUNT(*), AVG(ESalary)
FROM EMPLOYEE
GROUP BY DNum
Trong câu truy vấn Q34, các bộ EMPLOYEE được chia thành nhiều nhóm, các
bộ trong một nhóm có chung giá trị đối với thuộc tính phân nhóm DNum. Các hàm
kết hợp COUNT và AVG được thực hiện đối với từng nhóm.

Chú ý:
Mệnh đề SELECT chỉ bao gồm thuộc tính gom nhóm và các hàm kết hợp
được thực hiện cho từng nhóm.

Nếu thuộc tính gom nhóm cho phép giá trị NULL, các bộ có giá trị NULL
tại thuộc tính này sẽ được gom vào chung một nhóm.
VÍ DỤ 7.43: Mệnh đề gom nhóm với nhiều hơn một thuộc tính.
Với mỗi dự án, cho biết mã số dự án, tên dự án, số nhân viên tham gia dự án đó.
Q34: SELECT p. PNumber, p. PName, COUNT(*)
FROM PROJECT p, WORKSON w
WHERE p.PNumber = w.PNum
GROUP BY p. PNumber, p.Pname

Trong ví dụ trên, chúng ta thực hiện phép gom nhóm sau phép kết giữa hai quan
hệ PROJECT và WORKSON. Nói cách khác, chúng ta đã thực hiện phép gom
nhóm trên các bộ thỏa mãn điều kiện chọn cho trước. Trong trường hợp này, điều
kiện chọn cho trước là điều kiện kết giữa hai quan hệ nói trên. Sau khi thực hiện
phép gom nhóm, chúng ta tiếp tục thực hiện các hàm kết hợp trên tất cả các nhóm
được gom. Tuy nhiên, không phải lúc nào chúng ta cũng được yêu cầu phải thực
hiện các hàm kết hợp trên tất cả các nhóm nhận được sau khi thực hiện phép gom
nhóm.
VÍ DỤ 7.44: Câu truy vấn sử dụng mệnh đề HAVING theo sau GROUP BY.
Với mỗi dự án có nhiều hơn hai nhân viên tham gia, cho biết mã số dự án, tên dự
án, và số nhân viên tham gia dự án đó.
Q35: SELECT p.PNumber, p.PName, COUNT(*)
FROM PROJECT p, WORKSON w
WHERE p.PNumber = w.PNum
GROUP BY p.PNumber, p.PName
HAVING COUNT(*) > 2

7.5.9 Công thức chung của câu truy vấn SQL
Câu truy vấn trong SQL có thể bao gồm 6 mệnh đề, trong đó hai mệnh đề
SELECT và FROM là bắt buộc phải có. Các mệnh đề xuất hiện trong câu truy vấn
theo một trật tự nhất định.
SELECT <danh sách thuộc tính, hàm kết hợp>
FROM <danh sách quan hệ>
[WHERE <điều kiện trên bộ>]
[GROUP BY <các thuộc tính gom nhóm>]
[HAVING <điều kiện trên nhóm>]
[ORDER BY <các thuộc tính sắp xếp>]
Trình tự thực hiện câu truy vấn trong SQL như sau. Đầu tiên, mệnh đề FROM
được thực hiện, SQL tính tích Cartesian của các quan hệ được liệt kê trong mệnh
đề FROM. Sau đó, SQL chọn từ tích Cartesian nói trên các bộ thỏa mãn điều kiện
chọn trong mệnh đề WHERE. Các bộ thỏa mãn điều kiện chọn sẽ được gom thành
nhiều nhóm dựa trên các thuộc tính gom nhóm trong mệnh đề GROUP BY. Tuy
nhiên, chỉ những nhóm thỏa mãn điều kiện trong mệnh đề HAVING mới được
hiển thị như là kết quả của câu truy vấn. Trật tự hiển thị kết quả của câu truy vấn
phụ thuộc vào các thuộc tính sắp xếp trong mệnh đề ORDER BY. Cuối cùng, câu
truy vấn chỉ hiển thị các thuộc tính và kết quả thực hiện các hàm kết hợp được liệt
kê ở mệnh đề SELECT đối với những nhóm được chọn theo trật tự xác định.
7.6 CÁC LỆNH INSERT, DELETE, VÀ UPDATE

TRONG SQL
7.6.1 Lệnh INSERT
Lệnh INSERT dùng để thêm một bộ vào quan hệ. Chúng ta phải xác định tên quan
hệ và danh sách các giá trị tương ứng với bộ muốn thêm vào quan hệ. Các giá trị
này phải được liệt kê cùng trình tự với các thuộc tính tương ứng được xác định
trong câu lệnh tạo quan hệ.
Ngoài ra, lệnh INSERT còn cho phép người dùng xác định tường minh tên các
thuộc tính tương ứng với các giá trị được cung cấp trong lệnh INSERT. Điều này
rất hữu dụng nếu quan hệ có nhiều thuộc tính nhưng bộ mới chỉ nhận giá trị tại
một số ít thuộc tính nào đó mà thôi. Khi thêm bộ mới vào quan hệ, chúng ta phải
cung cấp giá trị cho các thuộc tính được khai báo là NOT NULL và không có giá
trị mặc định.
VÍ DỤ 7.45: Câu lệnh thêm mới một bộ vào quan hệ.

Câu lệnh sau đây được dùng để thêm một bộ vào quan hệ EMPLOYEE
U1: INSERT INTO EMPLOYEE
VALUES (‘30121050004’,N’Mai Duy An’, 30000, ‘F’,
’17/02/1968’, ‘30121050037’, 1, ‘15/06/2010’)

VÍ DỤ 7.46: Câu lệnh thêm mới một bộ vào quan hệ.
Câu lệnh sau đây được dùng để thêm một bộ vào quan hệ EMPLOYEE
U2: INSERT INTO EMPLOYEE (ESSN, EName, DNum)
VALUES (‘30121050004’, N‘Mai Duy An’,1)
Các thuộc tính không được thể hiện tường minh trong U2 sẽ nhận giá trị
DEFAULT hoặc NULL, và các giá trị được liệt kê đúng theo trật tự mà các thuộc
tính tương ứng xuất hiện trong câu lệnh INSERT.

Chú ý rằng thao tác thêm một bộ vào quan hệ có thể dẫn đến vi phạm ràng buộc
toàn vẹn tham chiếu. Ví dụ, khi thêm một bộ vào quan hệ EMPLOYEE với giá trị
tại thuộc tính DNum là 7, trong khi đó quan hệ DEPARTMENT không có bộ nào
có giá trị là 7 tại thuộc tính DNumber. Như chúng ta đã biết, giữa quan hệ
EMPLOYEE và quan hệ DEPARTMENT có một ràng buộc toàn vẹn tham chiếu
từ DNum của EMPLOYEE đến DNumber của DEPARTMENT. Như vậy, thao
tác thêm bộ mới nói trên đã vi phạm ràng buộc toàn vẹn tham chiếu này.

Ngoài ra, lệnh INSERT còn được sử dụng để thêm vào quan hệ nhiều bộ như là
kết quả của một câu truy vấn.
VÍ DỤ 7.47: Câu lệnh thêm mới nhiều bộ vào quan hệ.

Để tạo bảng tạm chứa tên, số lượng nhân viên, tổng lương của từng đơn vị, chúng
ta sử dụng hai câu lệnh U3A và U3B sau đây:
U3A: CREATE TABLE DEPTS_INFO (
DName VARCHAR(15),
EmpCounts INTEGER,
SalTotal INTEGER)
U3B: INSERT INTO DEPTS_INFO (DName, EmpCounts, SalTotal)
SELECT DName, COUNT(*), SUM(ESalary)
FROM (DEPARTMENT JOIN EMPLOYEE ON DNumber=DNum)
GROUP BY DName

7.6.2 Lệnh DELETE
Lệnh DELETE xóa một (số) bộ ra khỏi quan hệ. Với mệnh đề WHERE, lệnh
DELETE xóa ra khỏi quan hệ tất cả các bộ thỏa mãn điều kiện được xác định
trong mệnh đề WHERE. Trong trường hợp câu lệnh DELETE không có mệnh đề
WHERE đi kèm SQL sẽ xóa tất cả các bộ hiện có trong quan hệ, điều này đồng
nghĩa với việc quan hệ trở về trạng thái rỗng ban đầu. Mỗi lần được thực hiện,
lệnh DELETE chỉ tác động lên duy nhất một quan hệ. Tuy nhiên, việc thực hiện
lệnh DELETE trên quan hệ này có thể phát sinh lệnh DELETE trên quan hệ khác,
nếu giữa các quan hệ này có mối ràng buộc tham chiếu.
VÍ DỤ 7.48: Câu lệnh xóa một (số) bộ ra khỏi quan hệ.

Câu lệnh sau đây xóa các thân nhân của nhân viên có mã số ‘30121050180’
U4: DELETE FROM DEPENDENT
WHERE ESSN = ‘30121050180’


VÍ DỤ 7.49: Truy vấn lồng xuất hiện trong mệnh đề WHERE của câu lệnh
xóa một (số) bộ ra khỏi quan hệ.
Câu lệnh sau đây xóa tất cả thân nhân của các nhân viên trong phòng có mã số 1
U5: DELETE FROM DEPENDENT
WHERE ESSN IN (SELECT ESSN FROM EMPLOYEE WHERE DNum=1)

7.6.3 Lệnh UPDATE
Lệnh UPDATE được dùng để thay đổi giá trị thuộc tính của một hoặc nhiều bộ
được chọn. Tương tự như với lệnh DELETE, mệnh đề WHERE trong lệnh
UPDATE chọn từ một quan hệ các bộ cần được chỉnh sửa. Mệnh đề SET trong
lệnh UPDATE xác định các thuộc tính cần được chỉnh sửa và giá trị mới của
chúng.
VÍ DỤ 7.50: Câu lệnh cập nhật giá trị của một (số) bộ thỏa mãn điều kiện.
Để thay đổi địa điểm và đơn vị quản lý của dự án có mã số là 10 với các giá trị
mới lần lượt là ‘Hà Nội’ và 5, chúng ta sử dụng câu lệnh sau đây:
U5: UPDATE PROJECT
SET PLocation = N’Hà Nội’, DNum=5
WHERE PNumber = 10
Trong U5, chúng ta chỉ thay đổi giá trị của một bộ trong quan hệ PROJECT.
Lệnh UPDATE có thể thay đổi cùng lúc nhiều bộ, nếu các bộ này thỏa mãn điều
kiện trong mệnh đề WHERE.

VÍ DỤ 7.50: Truy vấn lồng xuất hiện trong mệnh đề WHERE của câu lệnh
cập nhật một (số) bộ trong quan hệ.
Để tăng lương cho mọi nhân viên của phòng Nghiên cứu lên 10% lương hiện tại,
chúng ta sử dụng lệnh UPDATE sau đây:
U6: UPDATE EMPLOYEE
SET ESalary = ESalary *1.1

WHERE DNum IN (SELECT DNumber
FROM DEPARTMENT
WHERE DName = N’Phòng Nghiên cứu’)
7.7 TÓM TẮT

Trong chương này chúng tôi tập trung trình bày các vấn đề có liên quan đến ngôn
ngữ truy vấn có cấu trúc SQL. Ngôn ngữ này được xem như là ngôn ngữ nền tảng
cho mọi hệ quản trị CSDL quan hệ. Chúng ta tiến hành nghiên cứu theo trình tự
như sau. Đầu tiên chúng ta định nghĩa các kiểu dữ liệu và các lệnh có liên quan
đến việc định nghĩa dữ liệu. Các lệnh này bao gồm lệnh tạo bảng (CREATE
TABLE), lệnh sửa lược đồ của bảng (ALTER TABLE), và lệnh xóa bảng (DROP
TABLE). Một chú ý cần phải ghi nhớ là xóa bảng tức là xóa thể hiện của bảng và
xóa cả lược đồ của bảng. Trong phần này, chúng ta cũng tìm hiểu một số ràng
buộc toàn vẹn dữ liệu cơ bản trong SQL, các ràng buộc này cần phải được khai
báo ngay trong lệnh tạo bảng, hoặc sau đó, trong các lệnh sửa lược đồ của bảng.
Tiếp theo, chúng ta nghiên cứu cách thức thực hiện các câu truy vấn dữ liệu với từ
khóa duy nhất SELECT. Chúng ta tiến hành từ câu truy vấn đơn giản tới các dạng
phức tạp như là cấu trúc lồng vào nhau, cấu trúc gom nhóm với việc sử dụng các
hàm kết hợp, cấu trúc kết trong và kết ngoài.
Cuối cùng, chúng ta tìm hiểu các lệnh xử lý dữ liệu (DML) như để hoàn chỉnh nội
dung kiến thức về ngôn ngữ truy vấn có cấu trúc. Với ba lệnh chèn, sửa, và xóa,
chúng ta có thể thay đổi nội dung của bảng dữ liệu bất kỳ lúc nào, miễn sao sự
thay đổi đó không gây ra vi phạm đối với các ràng buộc toàn vẹn có liên quan đã
được định nghĩa trước đó.

C
CHHƯ
ƯƠƠN
NGG
8
LÝ THUYẾT THIẾT KẾ
CƠ SỞ DỮ LIỆU QUAN HỆ
Mục tiêu
Chương này trang bị cho người đọc kiến thức về các tiêu chuẩn thiết kế CSDL
quan hệ, giúp người đọc khắc phục được những thiếu sót thường gặp trong quá
trình thiết kế CSDL, giảm thiểu rủi ro, kéo dài thời gian sử dụng của CSDL, đáp
ứng tốt nhu cầu thông tin của người sử dụng dựa trên CSDL được thiết kế.
Nội dung
Phụ thuộc hàm.
Hệ tiên đề các phụ thuộc hàm.
Một số vấn đề khi thiết kế cơ sở dữ liệu quan hệ.
Phân tách dữ liệu.
Các dạng chuẩn của mô hình dữ liệu quan hệ.
Các phương pháp chuẩn hóa cơ sở dữ liệu quan hệ.

Giới thiệu
Trong các chương trước, chúng ta đã nghiên cứu về mô hình dữ liệu quan hệ, các
bước tiến hành công việc xây dựng một cơ sở dữ liệu phù hợp với yêu cầu của ứng
dụng. Dựa vào yêu cầu của ứng dụng, chúng ta có thể bắt tay ngay vào việc thiết
kế lược đồ cơ sở dữ liệu thay vì chúng ta phải xây dựng một mô hình dữ liệu bậc
cao, ví dụ như mô hình thực thể kết hợp. Tuy nhiên, dù cách này hay cách kia,
chúng ta đều có thể mắc phải một số sai sót, chẳng hạn như định nghĩa dữ liệu lưu
trữ chưa hợp lý, bố trí quá nhiều thuộc tính vào trong một quan hệ, phân rã dữ liệu
vào quá nhiều quan hệ, dẫn đến việc dữ liệu bị phân thành nhiều mảnh nhỏ, gây
khó khăn trong việc truy xuất dữ liệu sau này …
Các vấn đề nêu trên đều có thể được giải quyết một cách triệt để, nếu chúng ta
tuân thủ theo một lý thuyết được phát triển riêng cho cơ sở dữ liệu quan hệ: lý
thuyết phụ thuộc hàm. Tuân thủ các nguyên tắc do lý thuyết này đề ra, chúng ta sẽ
xây dựng được một cơ sở dữ liệu tốt, hoạt động hiệu quả, đảm bảo các yêu cầu
truy xuất và cập nhật.

8.1 PHỤ THUỘC HÀM
Trong suốt quá trình xây dựng cơ sở dữ liệu, các lược đồ quan hệ cần được kiểm
tra kỹ lưỡng, và khi cần, chúng ta phải cải tiến chúng dựa trên một số nguyên lý
đơn giản. Nguyên lý thiết kế cơ sở dữ liệu yêu cầu chúng ta phải xác định các ràng
buộc cho từng quan hệ. Loại ràng buộc phổ biến nhất trong cơ sở dữ liệu quan hệ
chính là phụ thuộc hàm. Phụ thuộc hàm là cơ sở cho ý tưởng khóa trong quan hệ.
Việc chuẩn hóa dữ liệu được thực hiện dựa trên các khái niệm phụ thuộc hàm và
khóa của quan hệ.
8.1.1 Định nghĩa phụ thuộc hàm

Khái niệm phụ thuộc hàm f trên quan hệ R giữa hai tập hợp các thuộc tính A1, A2,
..., An và B1, B2, ..., Bm được phát biểu như sau:
Nếu hai bộ của quan hệ R có giá trị giống nhau tại các thuộc tính A1,
A2, ..., An, thì chúng cũng phải có giá trị giống nhau tại các thuộc tính
B1, B2, ..., Bm.
Phụ thuộc hàm f trên được ký hiệu là A1,A2,...,An → B1,B2,...,Bm, và đọc là A1, A2,
..., An xác định hàm B1, B2, ..., Bm.
Hình 8.1 diễn tả tác động của phụ thuộc hàm f đối với hai bộ t và u bất kỳ của
quan hệ R. Tuy nhiên, vị trí của các thuộc tính Ai, Bi là bất kỳ, chúng không nhất
thiết phải kế tiếp nhau, hoặc các thuộc tính Ai bắt buộc phải đứng trước các thuộc
tính Bi.
Hình 8.1. Ảnh hưởng của phụ thuộc hàm đối với hai bộ t, u bất kỳ.
Chúng ta có thể phát biểu lại định nghĩa phụ thuộc hàm f trên quan hệ R giữa hai
tập các thuộc tính X và Y như sau:
Cho R là quan hệ trên tập thuộc tính Ω, với X và Y là hai tập con (khác
rỗng) bất kỳ của Ω. Nói rằng X xác định Y, hay Y phụ thuộc hàm vào X,
ký hiệu X → Y, khi và chỉ khi ∀r,s ∈ R, nếu r[X] = s[X], thì r[Y] = s[Y].
Quan hệ R được gọi là thỏa mãn phụ thuộc hàm f, nếu f đúng với mọi thể hiện của
quan hệ R, và khi đó, chúng ta đã xác nhận một ràng buộc trên quan hệ này.
VÍ DỤ 8.1: Sự tồn tại của các phụ thuộc hàm trong quan hệ.
Xét quan hệ PROJECT1 với lược đồ như sau:
PROJECT1(PName, PLocation, DName, EName, workHours)
Quan hệ PROJECT1 bao gồm thông tin của cả ba quan hệ DEPARTMENT,
EMPLOYEE, và WORKSON. Dễ dàng thấy rằng trong quan hệ này tồn tại phụ
thuộc hàm PName → PLocation DName. Phụ thuộc hàm này nói rằng nếu hai bộ
có cùng giá trị tại thành phần PName thì chúng cũng có cùng giá trị tại các thành
phần PLocation và DName. Sự tồn tại của phụ thuộc hàm này hoàn toàn hợp lý, vì
chúng ta tin rằng một dự án không thể được thực hiện tại hai thành phố khác nhau,
cũng không thể chịu sự quản lý của hai đơn vị khác nhau. Trong khi đó, PName →
EName workHours lại không thể là phụ thuộc hàm trên PROJECT1, bởi vì một
dự án có thể có nhiều nhân viên tham gia với một khối lượng thời gian cụ thể.
Một thể hiện của quan hệ PROJECT1 được biểu diễn trong hình 8.2.

8.1.2 Khóa của quan hệ
Chúng ta nói tập hợp của một (hoặc nhiều) thuộc tính {A1, A2, ..., An} là khóa của
quan hệ R nếu thỏa mãn đồng thời hai điều kiện sau đây:
1) Các thuộc tính đó xác định tất cả các thuộc tính khác của quan hệ.
2) {A1, A2, ..., An} không có bất kỳ tập con khác rỗng nào có thể xác định tất
cả các thuộc tính khác của quan hệ. Khóa phải là nhỏ nhất.

Hình 8.2. Một thể hiện của quan hệ PROJECT1
VÍ DỤ 8.2: Khóa của quan hệ PROJECT1.

Chúng ta nhận thấy tập thuộc tính {PName, EName} là khóa của quan hệ
PROJECT1, cụ thể như sau:
Đầu tiên, chúng ta chỉ ra rằng tập thuộc tính này xác định phụ thuộc hàm tất
cả các thuộc tính còn lại. Quan hệ PROJECT1 ngoài phụ thuộc hàm (1)
PName → PLocation DName còn có phụ thuộc hàm (2) PName EName →
workHours (mỗi nhân viên khi tham gia một dự án với khối lượng thời gian
cụ thể). Xét hai bộ có giá trị bằng nhau tại các thuộc tính PName và Ename.
Theo (1) và (2), hai bộ này phải có giá trị bằng nhau tại PLocation, DName,
và workHours. Như vậy, {PName, EName} xác định phụ thuộc hàm các
thuộc tính còn lại của PROJECT1.
Tiếp theo, chúng ta phải chứng minh bản thân mỗi thuộc tính PName hay
EName không xác định hàm các thuộc tính khác của quan hệ PROJECT1.
Vì mỗi dự án có nhiều nhân viên tham gia, hay ngược lại, một nhân viên
tham gia nhiều dự án, cho nên PName không xác định phụ thuộc hàm
EName, và EName cũng không xác định phụ thuộc hàm PName. Từ đó suy
ra {PName, EName} là khóa của quan hệ PROJECT1


Trong thực tế, một quan hệ có thể có nhiều khóa. Vì thế, chúng ta cần phải chọn
một trong số đó làm khóa chính. Không có quy ước chính thức nào cho việc chọn
khóa chính, tuy nhiên người ta thường chọn khóa đơn giản nhất (ưu tiên thuộc
kiểu dữ liệu số nguyên) làm khóa chính.
8.1.3 Siêu khóa

Tập hợp các thuộc chính chứa khóa được gọi là siêu khóa. Mọi khóa đều là siêu
khóa, nhưng không phải siêu khóa nào cũng là khóa. Chúng ta nhận thấy rằng, mọi
siêu khóa đều thỏa mãn điều kiện đầu tiên trong định nghĩa về khóa, tức là siêu
khóa xác định tất cả các thuộc tính khác trong quan hệ. Tuy nhiên, siêu khóa
không thỏa mãn điều kiện thứ hai trong định nghĩa đó, khi siêu khóa chứa một tập
thuộc tính con và bản thân tập thuộc tính con này lại chính là khóa của quan hệ.
VÍ DỤ 8.3: Siêu khóa của quan hệ.

Trong quan hệ PROJECT1 ở ví dụ 8.2 có nhiều siêu khóa. Bản thân khóa
{PName, EName} là siêu khóa, và mọi tập thuộc tính chứa khóa này đều là siêu
khóa, ví dụ như là {PName, PLocation, EName} hay { PName, DName, EName,
workHours}.

8.2 HỆ TIÊN ĐỀ CÁC PHỤ THUỘC HÀM

Để đáp ứng các yêu cầu về ngữ nghĩa, các quan hệ trong cơ sở dữ liệu phải luôn
luôn thỏa mãn một số phụ thuộc hàm nhất định. Giả sử rằng quan hệ R thỏa mãn
một tập hợp các phụ thuộc hàm FD và chúng ta cần phải chứng minh được rằng R
cũng phải thỏa mãn một phụ thuộc hàm f nào đó khác. Chúng ta có thể chứng
minh điều này bằng cách suy luận từ những phụ thuộc hàm trong tập FD mà R đã
thỏa mãn.
Chúng ta bắt đầu với một ví dụ minh họa cách suy luận một phụ thuộc hàm từ các
phụ thuộc hàm cho trước.

VÍ DỤ 8.4: Một phụ thuộc hàm được dẫn xuất từ các phụ thuộc hàm khác.
Với quan hệ R(A,B,C) thỏa mãn các phụ thuộc hàm A→B, và B→C, chúng ta có
thể suy luận được rằng R cũng thỏa mãn phụ thuộc hàm A→C. Để chứng minh
A→C, chúng ta xét hai bộ bất kỳ của R, nếu chúng có giá trị giống nhau tại thuộc
tính A, thì chúng cũng phải có giá trị giống nhau tại thuộc tính C.
Gọi hai bộ có giá trị giống nhau tại thuộc tính A là (a, b1, c1), và (a, b2, c2). Do R
thỏa mãn phụ thuộc hàm A→B, và các bộ này trùng nhau tại A, cho nên chúng
cũng trùng nhau tại B, nghĩa là b1=b2=b. Tương tự, R thỏa mãn phụ thuộc hàm
B→C, hai bộ nói trên lại trùng nhau tại thuộc tính B, chúng cũng trùng nhau tại C,
nghĩa là c1=c2=c. Như vậy, nếu hai bộ đã cho trùng nhau tại A, chúng cũng sẽ
trùng nhau tại C, điều này đồng nghĩa với việc quan hệ R thỏa mãn phụ thuộc hàm
A→C.

Các phụ thuộc hàm thường được biểu diễn ở nhiều dạng khác nhau mà không ảnh
hưởng đến các quan hệ chịu sự tác động của chúng. Chúng ta định nghĩa:
Hai tập các phụ thuộc hàm S và T tương đương với nhau, nếu tập các quan
hệ thỏa mãn S cũng thỏa mãn T, và ngược lại.
Tập phụ thuộc hàm S được gọi là dẫn xuất từ tập phụ thuộc hàm T, nếu mọi
quan hệ thỏa mãn tất cả phụ thuộc hàm trong T cũng thỏa mãn tất cả phụ
thuộc hàm trong S.
Như vậy, hai tập hợp các phụ thuộc hàm S và T tương đương, khi và chỉ khi S dẫn
xuất từ T, và T dẫn xuất từ S.
Tiếp theo chúng ta sẽ tìm hiểu một số quy luật biến đổi liên quan tới phụ thuộc
hàm. Các quy luật này cho phép chúng ta thay thế tập hợp các phụ thuộc hàm này
bằng tập hợp các phụ thuộc hàm khác tương đương. Ngoài ra, chúng ta cũng làm
quen với thuật toán kiểm chứng một phụ thuộc hàm có được dẫn xuất từ một (số)
phụ thuộc hàm khác hay không.

Cho Ω = {A1, A2, ..., An} là tập (khác rỗng) các thuộc tính của R. Gọi F là tập hợp
các phụ thuộc hàm thỏa mãn quan hệ R trên các thuộc tính Ω. Ký hiệu Y: A → B ∈
F, với A, B ⊂ Ω là một phụ thuộc hàm của R.
8.2.1 Quy luật phân tách / kết hợp

Mặc dù không có quy định nào giới hạn số thuộc tính xuất hiện trong hai vế của
một phụ thuộc hàm, tuy nhiên, người ta có xu hướng sử dụng các phụ thuộc có
duy nhất một thuộc tính ở vế bên phải. Sở dĩ như vậy là do khi sử dụng các phụ
thuộc hàm hiện có để chứng minh sự tồn tại của một phụ thuộc hàm khác trong
quan hệ, việc chứng minh sẽ đơn giản hơn nhiều nếu chúng ta chỉ sử dụng các phụ
thuộc hàm với một thuộc tính ở vế phải.
Việc phân tách một phụ thuộc hàm thành nhiều phụ thuộc hàm khác tương đương
với phụ thuộc hàm ban đầu, hoặc việc kết hợp nhiều phụ thuộc hàm thành một phụ
thuộc hàm duy nhất tương đương là điều cần thiết, và được trình bày trong định
nghĩa sau đây.
Với phụ thuộc hàm f: A1A2...An → B1B2...Bm và tập phụ thuộc hàm f1: A1A2...An →
B1,…, fm: A1A2...An → Bm, chúng ta định nghĩa quá trình phân tách f thành f1, f2, …,
fm và kết hợp các phụ thuộc hàm f1, f2, …, fm thành f bằng hai quy luật sau đây:
Chúng ta có thể thay thế phụ thuộc hàm A1A2...An → B1B2...Bm bằng tập hợp
m phụ thuộc hàm A1A2...An → Bi, với i=1,2,...,m. Chúng ta gọi sự biến đổi
này là quy luật phân tách.
Chúng ta có thể thay thế tập hợp các phụ thuộc hàm A1A2...An → Bi, với
i=1,2,...,m, bằng một phụ thuộc hàm duy nhất A1A2...An → B1B2...Bm. Sự
biến đổi này được gọi là quy luật kết hợp.
VÍ DỤ 8.5: Quy luật phân tách/kết hợp các phụ thuộc hàm.
Tập phụ thuộc hàm của quan hệ PROJECT trong ví dụ 8.2:
PName → PLocation

PName → DName
tương đương với phụ thuộc hàm:
PName → PLocation DName
mà chúng ta đã nhắc đến.

Để chứng minh tính đúng đắn của quy luật phân tách, chúng ta chọn từ quan hệ R
hai bộ bất kỳ sao cho chúng có giá trị bằng nhau tại các thuộc tính A1, A2, ... , An.
Theo phụ thuộc hàm A1A2...An → B1B2...Bm, nếu hai bộ có giá trị bằng nhau tại các
thuộc tính A1, A2, ... , An, thì chúng cũng sẽ có giá trị bằng nhau tại các thuộc tính
B1, B2, ... ,Bm. Điều đó có nghĩa là nếu hai bộ có giá trị bằng nhau tại các thuộc tính
A1, A2, ... , An, thì chúng cũng có giá trị bằng nhau tại mỗi thuộc tính Bi, với
i=1,2,...,m. Như vậy, trên quan hệ R tồn tại các phụ thuộc hàm A1A2...An → Bi, với
i=1,2,...,m. Điều này đồng nghĩa với việc có thể thay thế phụ thuộc hàm A1A2...An
→ B1B2...Bm bằng m phụ thuộc hàm A1A2...An → Bi, với i=1,2,...,m (quy luật phân
tách).
Với quy luật kết hợp, chúng ta cũng chứng minh tương tự. Giả sử quan hệ R có hai
bộ có giá trị bằng nhau tại các thuộc tính A1, A2, ... , An, và tồn tại các phụ thuộc
hàm A1A2...An → Bi, với i=1,2,...,m. Do đó, hai bộ nói trên cũng có giá trị bằng
nhau lần lượt tại các thuộc tính B1, B2, ... ,Bm tương ứng với mỗi phụ thuộc hàm
nói trên. Như vậy trên quan hệ R tồn tại phụ thuộc hàm A1A2...An → B1B2...Bm, và
có thể thay thế m phụ thuộc hàm ban đầu bằng phụ thuộc hàm này (quy luật kết
hợp).
Chúng ta cần chú ý quy luật phân tách và kết hợp chỉ có ảnh hưởng đến vế phải
của các phụ thuộc hàm. Điều này có nghĩa là không có quy luật phân tách đối với
vế trái của phụ thuộc hàm, như ví dụ sau đây.

VÍ DỤ 8.6: Quy luật phân tách chỉ áp dụng đối vế phải của phụ thuộc hàm.
Xét quan hệ WORKSON1(EName, PName, hours) cho biết khoảng thời gian mà
mỗi nhân viên tham gia tính theo từng dự án. Rõ ràng trong quan hệ này tồn tại
phụ thuộc hàm:
EName PName → hours
Nếu chúng ta tách vế trái của phụ thuộc hàm này, kết quả nhận được
EName → hours
PName → hours
không phải là hai phụ thuộc hàm trên WORKSON1. Dễ dàng nhận thấy thuộc
tính EName không xác định phụ thuộc hàm thuộc tính hours, vì mỗi nhân viên có
thời gian tham gia mỗi dự án là khác nhau. Tương tự, thuộc tính PName cũng
không xác định phụ thuộc hàm thuộc tính hours, vì mỗi dự án có nhiều nhân viên
tham gia, mỗi nhân viên lại có thời gian tham gia dự án khác nhau.
Hình 8.3. Một thể hiện của quan hệ WORKSON1

8.2.2 Phụ thuộc hàm hiển nhiên

Một phụ thuộc hàm được gọi là hiển nhiên, nếu nó đúng đối với mọi thể hiện của
quan hệ mà không cần bất kỳ giả thiết nào khác. Ở đây, phụ thuộc hàm A1A2...An

→ B1B2...Bm được gọi là hiển nhiên, nếu {B1, B2, ..., Bm} ⊆ {A1, A2, ... , An}, nghĩa
là, phụ thuộc hàm hiển nhiên f có các thuộc tính bên vế phải là tập con của các
thuộc tính bên vế trái.
VÍ DỤ 8.7: Phụ thuộc hàm hiển nhiên.
Trong quan hệ PROJECT1 các phụ thuộc hàm sau đây là hiển nhiên:
PName → PName
PName EName → Pname

Mọi phụ thuộc hàm hiển nhiên luôn được tồn tại trong quan hệ, chúng ta được
quyền sử dụng chúng bất kỳ lúc nào mà không cần quan tâm đến việc chúng có
được khai báo một cách tường minh cho quan hệ hay không.
Từ khái niệm phụ thuộc hàm hiển nhiên, chúng ta có thể định nghĩa một dạng phụ
thuộc hàm không hiển nhiên, nhưng có thể suy diễn dễ dàng từ các phụ thuộc hàm
hiển nhiên bằng cách loại bỏ ra khỏi vế phải những thuộc tính xuất hiện trong vế
trái của phụ thuộc hàm đó:
Phụ thuộc hàm A1A2...An → B1B2...Bm tương đương với phụ thuộc hàm
A1A2...An → C1C2...Ck, với Ci ∈ {B1, B2, ..., Bm} \ {A1, A2, ... ,An}.
Chúng ta gọi phép biến đổi này là quy luật phụ thuộc hiển nhiên.
8.2.3 Bao đóng các thuộc tính

Trước khi nghiên cứu các quy luật khác, chúng ta làm quen với một nguyên lý mà
tất cả các quy luật phải tuân theo. Giả sử {A1, A2, ..., An} là tập hợp các thuộc tính,
và S là tập hợp các phụ thuộc hàm. Bao đóng của {A1, A2, ..., An} theo tập các phụ
thuộc hàm ℑ là các thuộc tính B sao cho mọi quan hệ thỏa mãn tất cả các phụ
thuộc hàm trong ℑ cũng thỏa mãn phụ thuộc hàm A1A2...An → B. Điều này có
nghĩa là, phụ thuộc hàm A1A2...An → B được dẫn xuất từ các phụ thuộc hàm trong
ℑ. Chúng ta ký hiệu bao đóng của tập hợp các thuộc tính A1A2...An là {A1, A2, ...,

An}+. Chú ý rằng A1A2...An luôn nằm trong {A1, A2, ..., An}+, bởi vì phụ thuộc hàm
A1A2...An → Ai là hiển nhiên với i=1,...,n.
Để tính bao đóng X của tập hợp A các thuộc tính, chúng ta bắt đầu từ tập hợp X =
A, và liên tục mở rộng tập hợp này bằng cách xem xét các phụ thuộc hàm trong ℑ.
Trong trường hợp phụ thuộc hàm Si có các thuộc tính ở vế trái nằm trong tập X, và
thuộc tính ở vế phải chưa xuất hiện trong X, thì chúng ta bổ sung thuộc tính này
vào tập X. Dĩ nhiên, quá trình này không thể diễn ra mãi mãi, và tập hợp X cuối
cùng chính là bao đóng của {A1, A2, ..., An}. Quá trình này được thể hiện chi tiết
thành thuật toán 8.1 dưới đây.
THUẬT TOÁN 8.1: Bao đóng của tập các thuộc tính.
Đầu vào: Tập các thuộc tính {A1, A2, ..., An} và tập các phụ thuộc hàm ℑ.
Đầu ra: Bao đóng {A1, A2, ..., An}+.
1. Phân tách các phụ thuộc hàm trong ℑ, sao cho mỗi phụ thuộc hàm trong ℑ
chỉ có một thuộc tính ở vế phải.
2. Gọi X là tập hợp bao đóng các thuộc tính. Tại thời điểm khởi tạo X = {A1,
A2, ..., An}.
3. Tìm một phụ thuộc hàm B1B2...Bm→C, sao cho tất cả B1, B2, ..., Bm đều nằm
trong X, nhưng C thì không. Thêm C vào tập X, và lặp lại bước 3.
Vì số phần tử trong X chỉ có thể tăng, và số thuộc tính của bất kỳ lược đồ
cơ sở dữ liệu nào cũng có giới hạn, cho nên sẽ xảy ra trường hợp không thể
thêm thuộc tính mới vào X, và thuật toán kết thúc.
Tập hợp X, sau khi không thể thêm thuộc tính mới vào, là bao đóng của tập thuộc
tính ban đầu.

Với thuật toán tính bao đóng của các thuộc tính, chúng ta có thể kiểm tra một phụ
thuộc hàm A1A2...An → B có được dẫn xuất từ tập phụ thuộc hàm ℑ hay không.
Đầu tiên, chúng ta tính {A1, A2, ..., An}+ theo các phụ thuộc hàm trong ℑ. Nếu B

xuất hiện trong {A1, A2, ..., An}+, thì A1A2...An → B dẫn xuất từ S, và nếu B không
có trong {A1, A2, ..., An}+, thì phụ thuộc hàm này không được dẫn xuất từ ℑ. Một
cách tổng quát, phụ thuộc hàm A1A2...An → B1B2...Bm dẫn xuất từ tập phụ thuộc
hàm ℑ, nếu và chỉ nếu tất cả B1, B2, ..., Bm đều nằm trong {A1, A2, ..., An}+. Hai ví
dụ sau đây trình bày cách thức áp dụng thuật toán 8.1 để tìm bao đóng của tập các
thuộc tính, và để chứng minh sự tồn tại của một phụ thuộc hàm trong một quan hệ
cụ thể nào đó.
VÍ DỤ 8.8: Áp dụng thuật toán tìm bao đóng các thuộc tính.
Xét quan hệ R(A,B,C,D,E,F) với các phụ thuộc hàm AB → C, BC → AD, D → E,
và CF → B. Tìm bao đóng của {A, B}.
Trước hết, chúng ta phân tách phụ thuộc hàm BC→AD thành hai phụ thuộc hàm
tương đương là BC→A và BC→D. Chúng ta bắt đầu thuật toán với X={A, B}:
Áp dụng phụ thuộc hàm AB → C, với A, B ∈ X, và C ∉ X, thêm C vào X.
Sau bước này, X={A, B, C}.
Áp dụng phụ thuộc hàm BC → A, và BC → D với B, C ∈ X. Do A ∈ X, và
D ∉ X, nên thêm D vào X. Đến đây, X={A, B, C, D}.
Áp dụng D → E với D ∈ X, và E ∉ X, thêm E vào X. Lúc này, X={A, B, C,
D, E}.
Tập hợp X={A, B, C, D, E} không thể tiếp tục thay đổi, do các phụ thuộc hàm
hoặc đã được áp dụng, hoặc không thể áp dụng, do không dẫn xuất được từ tập
hợp X. Vì vậy X+ = {A, B}+ = {A, B, C, D, E}.

VÍ DỤ 8.9: Áp dụng thuật toán 8.1 kiểm tra sự tồn tại của phụ thuộc hàm.
Xét quan hệ R và tập phụ thuộc hàm trong ví dụ 8.8. Để kiểm tra AB→D có được
dẫn xuất từ các phụ thuộc hàm này hay không, chúng ta tính bao đóng
{A,B}+={A,B,C,D,E}. Vì D∈{A, B}+, nên AB→D được dẫn xuất từ tập phụ thuộc
hàm ban đầu. Ngoài ra, để kiểm tra D→A có tồn tại hay không, chúng ta tính {D}+

từ tập phụ thuộc hàm cho trước, và kết quả nhận được là {D}+={D, E}. Từ đó,
chúng ta kết luận rằng không tồn tại phụ thuộc hàm D→A.
8.2.4 Quy luật bắc cầu

Liên quan đến khái niệm phụ thuộc hàm, quy luật bắc cầu cùng hai quy luật về sự
phân tách tạo nên tập luật đóng áp dụng đối với mọi phụ thuộc hàm trong quan hệ.
Quy luật bắc cầu cho phép kết nối hai phụ thuộc hàm, cụ thể như sau:
Nếu A1A2...An→B1B2...Bm và B1B2...Bm→C1C2...Ck là hai phụ thuộc hàm trên
quan hệ R, thì A1A2...An→C1C2...Ck cũng là phụ thuộc hàm trên R.
Để chứng minh quy luật bắc cầu, chúng ta cần tính bao đóng {A1, A2, ..., An}+, và
kiểm tra xem C1, C2, ..., Ck có nằm trong bao đóng này hay không. Phụ thuộc hàm
A1A2...An → B1B2...Bm cho chúng ta biết rằng B1, B2, ..., Bm nằm trong {A1, A2, ...,
An}+. Sau đó, chúng ta áp dụng phụ thuộc hàm B1B2...Bm → C1C2...Ck, và thêm C1,
C2, ..., Ck vào {A1, A2, ..., An}+. Vì tất cả Ci đều nằm trong {A1, A2, ..., An}+, nên
chúng ta kết luận rằng A1A2...An → C1C2...Ck đúng với mọi quan hệ thỏa mãn đồng
thời A1A2...An → B1B2...Bm và B1B2...Bm → C1C2...Ck.
VÍ DỤ 8.10: Quy luật bắc cầu.

Xét quan hệ PROJECT2 chứa thông tin về dự án và phòng ban quản lý dự án
(hình 8.4). Chúng ta dễ dàng nhận thấy sự tồn tại của hai phụ thuộc hàm sau đây:
(1) PNumber → DNum
(2) DNum → DName
Phụ thuộc hàm (1) cho biết một dự án chỉ do một đơn vị quản lý, trong khi phụ
thuộc hàm (2) cho biết mỗi mã đơn vị gắn liền với một tên đơn vị duy nhất.
Luật bắc cầu cho phép chúng ta kết hợp hai phụ thuộc hàm này thành một phụ
thuộc hàm khác:
(3) PNumber → DName
Phụ thuộc hàm này nói rằng mã dự án PNumber xác định DName của đơn vị quản
lý dự án đó.

Hình 8.4. Một thể hiện của quan hệ PROJECT2

8.2.5 Tập đóng của các phụ thuộc hàm

Đôi khi chúng ta cần phải xác định những phụ thuộc hàm nào được sử dụng để
biểu diễn tập đầy đủ các phụ thuộc hàm của một quan hệ. Cho trước một quan hệ
R, và tập phụ thuộc hàm S. Khi đó, mọi tập phụ thuộc hàm tương đương với S
được gọi là cơ sở đối với S. Cơ sở tối thiểu đối với một quan hệ là một cơ sở B
thỏa mãn ba điều kiện:
1) Tất cả phụ thuộc hàm trong B đều có một thuộc tính ở vế phải.
2) Nếu xóa bất kỳ phụ thuộc hàm nào ra khỏi B, kết quả thu được không còn
là cơ sở nữa.
3) Với bất kỳ phụ thuộc hàm f trong B, nếu xóa một (số) thuộc tính ra khỏi vế
trái của f, kết quả thu được không còn là cơ sở nữa.
Chú ý rằng, phụ thuộc hàm hiển nhiên không thể xuất hiện trong cơ sở tối thiểu, vì
nó có thể bị loại bỏ bởi điều kiện (2).
VÍ DỤ 8.11: Cơ sở tối thiểu của một tập các phụ thuộc hàm.
Xét quan hệ R(A, B, C) sao cho mỗi thuộc tính xác định hàm hai thuộc tính còn lại.
Do đó, tập phụ thuộc hàm đầy đủ của R bao gồm các phụ thuộc hàm không hiển
nhiên A→B, A→C, B→A, B→C, C→A, C→B, AB→C, AC→B, BC→A, và các
phụ thuộc hàm hiển nhiên A→A, B→B, và C→C.
Quan hệ R và tập phụ thuộc hàm của nó có nhiều cơ sở tối thiểu, hai trong số đó là
{ A → B, B → A, B → C, C → B} và { A → B, B → C, C → A }


8.2.6 Phép chiếu phụ thuộc hàm
Giả sử chúng ta có quan hệ R với tập phụ thuộc hàm S,và chúng ta thực hiện phép
chiếu R trên danh sách các thuộc tính L1 của R để thu được quan hệ R1 (R1=πL(R)).
Vấn đề đặt ra là, trên R1 có những phụ thuộc hàm nào?
Để xác định những phụ thuộc hàm tồn tại trên R1, chúng ta phải thực hiện chiếu
tập phụ thuộc hàm S. Kết quả của phép chiếu này là tập các phụ thuộc hàm:
Được dẫn xuất từ S, và
Chỉ chứa các thuộc tính của R1.
Quá trình này được thể hiện trong thuật toán 8.2 sau đây.
THUẬT TOÁN 8.2: Phép chiếu tập các phụ thuộc hàm.
Đầu vào: Quan hệ R, tập phụ thuộc hàm S trên R, và quan hệ R1=πL(R).
Đầu ra: Tập phụ thuộc hàm trên R1.
1. Cho T là tập phụ thuộc hàm cần tìm. Ban đầu, T nhận giá trị rỗng.
2. Với mỗi tập con các thuộc tính X của R1, tính X+. Quá trình tính toán này
được thực hiện dựa vào tập phụ thuộc hàm S, và có thể liên quan đến các
thuộc tính trong R nhưng không trong R1. Thêm vào T tất cả phụ thuộc hàm
không hiển nhiên X→A, với A vừa nằm trong X+, vừa nằm trong R1.
3. Lúc này T là cơ sở đối với R1, nhưng không phải là cơ sở tối thiểu. Chúng
ta có thể xây dựng cơ sở tối thiểu từ T như sau:
a. Nếu phụ thuộc hàm f trong T được dẫn xuất từ các phụ thuộc hàm
khác trong T, thì xóa f khỏi T.
b. Cho Y→B là một phụ thuộc hàm trong T, với Y gồm từ hai thuộc tính
trở lên (Y = ZA, A là thuộc tính đơn). Nếu Z → B dẫn xuất từ các phụ
thuộc hàm trong T (bao gồm cả Y→B), thì thay thế Y→B bằng Z→B.
Lặp lại hai bước trên đây cho đến khi nào T không thể thay đổi được nữa.


Chú ý, trong một quan hệ bất kỳ, tập các thuộc tính và tập các phụ thuộc hàm đều
là những tập hợp hữu hạn. Do đó, thuật toán 8.2 luôn có điểm dừng sau một số lần
thực hiện nhất định.
VÍ DỤ 8.12: Phép chiếu các phụ thuộc hàm.

Xét quan hệ R(A, B, C, D) với tập phụ thuộc hàm FD = {A→B, B→C, C→D}. Gọi
R1 là quan hệ kết quả của phép chiếu R lên các thuộc tính A, C, và D. Về lý thuyết,
để xác định tập phụ thuộc hàm cho R1, chúng ta cần phải tính bao đóng của tất cả
tám tập con của {A, C, D}. Tuy nhiên, chúng ta có thể bỏ qua một số trường hợp
đặc biệt sau đây:
Bao đóng của tập rỗng và tập tất cả các thuộc tính không thể phát sinh phụ
thuộc hàm không hiển nhiên.
Nếu bao đóng của một tập X nào đó là tập tất cả các thuộc tính, thì bao
đóng của mọi tập chứa X đều không thể phát sinh phụ thuộc hàm mới.
Do đó, chúng ta có thể bắt đầu với việc tính bao đóng của các tập gồm một thuộc
tính, và sau đó, nếu cần, chúng ta tính tiếp bao đóng của các tập gồm hai thuộc
tính, ba thuộc tính, và cứ thế. Với mỗi bao đóng của tập X, chúng ta xác nhận phụ
thuộc hàm X→E sao cho E thuộc X+, thuộc R1, nhưng không thuộc X.
Đầu tiên, {A}+ = {A, B, C, D}, vì thế hai phụ thuộc hàm A→C và A→D được duy
trì trong R1. Chú ý, A→B đúng trong R, nhưng không có vai trò gì đối với R1 vì B
không phải là thuộc tính của R1.
Việc tính toán được thực hiện với các tập thuộc tính khác. {C}+ = {C, D}, chúng
ta ghi nhận phụ thuộc hàm C→D cho R1. {D}+ = {D}, không có phụ thuộc hàm
mới cho R1. Chúng ta bắt đầu xét tới các tập hai thuộc tính của {A, C, D}. Do {A}+
chứa tất cả thuộc tính của R1, cho nên chúng ta không cần xét tiếp các tập thuộc
tính chứa {A}. Do đó, chỉ có duy nhất {C, D} là tập hai thuộc tính cần xét. {C,
D}+ = {C, D}, không có phụ thuộc hàm mới cho R1.

Như vậy, chúng ta đã xác định ba phụ thuộc hàm A→C, A→D, và C→D cho quan
hệ R1. Tuy nhiên, phụ thuộc hàm A→D là kết quả của phép bắc cầu từ hai phụ
thuộc hàm còn lại. Cuối cùng, cơ sở tối thiểu của R1 là A→C và C→D.

8.3 MỘT SỐ VẤN ĐỀ KHI THIẾT KẾ CƠ SỞ DỮ

LIỆU QUAN HỆ
Trong quá trình thiết kế CSDL, chúng ta thường xuyên phải đối mặt với những
vấn đề chỉ được phát sinh sau khi CSDL được triển khai một thời gian. Điều này
đặc biệt nghiêm trọng khi chúng ta cố gắng xây dựng những quan hệ với số lượng
lớn các thuộc tính. Trong phạm vi giáo trình, chúng tôi giới hạn các sai sót khi
thiết kế CSDL vào ba nhóm chính:
Dư thừa dữ liệu. Dữ liệu lặp đi lặp lại nhiều lần một cách không cần thiết.
Ví dụ như giá trị ProjectA, ProjectB, TP.Hà Nội, … trong quan hệ
PROJECT1 được trình bày ở hình 8.2.
Lỗi xung đột dữ liệu. Đôi khi chúng ta tiến hành cập nhật dữ liệu tại một bộ,
mà lại không tiến hành cập nhật trên các bộ có liên quan tới bộ đó. Kết quả
là tình trạng không đồng bộ xuất hiện, dẫn đến các xung đột về ý nghĩa của
dữ liệu được lưu trữ. Chẳng hạn như chúng ta muốn thay đổi địa điểm thực
hiện dự án ProjectA từ TP. Hà Nội sang thành TP. Hồ Chí Minh. Để thực
hiện điều đó, chúng ta cập nhật giá trị tương ứng tại thuộc tính PLocation
của bộ đầu tiên trong quan hệ PROJECT1 (hình 8.2). Ngoài ra, chúng ta
giữ nguyên giá trị của tất cả các bộ còn lại trong quan hệ PROJECT1. Rõ
ràng, xung đột dữ liệu đã xảy ra, cùng là dự án ProjectA nhưng lại có hai
địa điểm thực hiện.
Lỗi mất mát dữ liệu. Mỗi một giá trị khi xuất hiện trong CSDL luôn mang ý
nghĩa về sự tồn tại của nó trong thực tế mà CSDL đó phản ánh. Do vậy,
trong nhiều trường hợp chúng ta xóa một giá trị ra khỏi CSDL, giá trị bị
xóa trở nên không còn tồn tại trong CSDL, dẫn đến tình trạng người sử

dụng không có ý thức về sự tồn tại có giá trị đó trong thực tế. Ví dụ như
chúng ta xóa nhân viên có tên Vũ Thụy Hồng Anh ra khỏi danh sách nhân
viên tham gia dự án ProjectB. Điều này được thực hiện khi chúng ta xóa bộ
dữ liên có liên quan ra khỏi quan hệ PROJECT1 (hình 8.2). Rõ ràng, kết
quả của thao tác này là CSDL không còn có bất kỳ thông tin gì về nhân
viên Vũ Thụy Hồng Anh. Theo góc nhìn CSDL, nhân viên này coi như
không tồn tại cho dù thực tế vẫn là nhân viên của công ty. Đó chính là sự
mất mát thông tin.
Vấn đề đặt ra đối với các chuyên gia phân tích và thiết kế CSDL là làm thế nào để
xây dựng được CSDL phản ánh chính xác thực tế, đồng thời phải giải quyết ba vấn
đề cơ bản được nêu ở trên. Trong phần tiếp theo, chúng tôi trình bày một phương
pháp giúp thiết kế được một CSDL tốt: phép phân tách quan hệ.
8.4 PHÂN TÁCH QUAN HỆ

Mục tiêu của lý thuyết cơ sở dữ liệu là tính độc lập của dữ liệu. Cấu trúc lưu trữ
các hệ cơ sở dữ liệu phản ánh tính hiện thực, khách quan và toàn vẹn dữ liệu. Vì
vậy trong quá trình chuẩn hóa dữ liệu và tìm kiếm thông tin, cần thiết phải thực
hiện các phép tách lược đồ quan hệ chưa chuẩn hóa về tập các lược đồ quan hệ đã
được chuẩn hóa, sao cho quá trình phân tách không làm tổn thất thông tin, ý nghĩa
quan hệ gốc (chưa chuẩn hóa) được khôi phục nguyên vẹn từ phép kết nối tự nhiên
của các quan hệ sau khi phân tách (đã chuẩn hóa).
8.4.1 Các định nghĩa

Người ta gọi sự phân hoạch Ω = [S1, S2, …, Sk] là một phép phân tách của quan
hệ R(A1, A2, …, An), nếu phép phân hoạch này thỏa mãn đồng thời hai điều kiện:
Si ⊆ {A1, A2, …, An}
{A1, A2, …, An} = S1 ∪ S2 ∪ … ∪ Sk

Tiếp tục, kết quả của phép chiếu R trên tập thuộc tính Si được gọi là quan hệ chiếu
của R trên Si, và được ký hiệu lần lượt là Ri = πSi(R).
VÍ DỤ 8.13: Một phép phân tách quan hệ.

Chúng ta tiến hành phân tách quan hệ PROJECT1 trong hình 8.2 thành hai quan
hệ PROJECT2 và PROJECT3 như sau:
Quan hệ PROJECT2 gồm các thuộc tính PName, PLocation, và DName.
Quan hệ PROJECT3 gồm các thuộc tính PName, EName, và workHours.
Hình 8.5 biểu diễn kết quả của phép phân tách này.
PROJECT2 = πPName,PLocation,DName(PROJECT1) PROJECT3 = πPName,EName,workHours(PROJECT1)
Hình 8.5. Phép phân tách quan hệ PROJECT1

Phép phân tách Ω = [S1, S2, …, Sk] được gọi là phép phân tách – kết nối tự nhiên
của quan hệ R(A1, A2, …, An), nếu:
Ω=[S1,S2,…,Sk] là một phép phân tách của quan hệ R(A1, A2, …, An), và
Phép kết tự nhiên của các quan hệ chiếu cho kết quả là một quan hệ có các
thuộc tính A1, A2, …, An và πS1(R)⋈ πS2(R)⋈... ⋈πSk(R) ⊇ R
Phép phân tách Ω = [S1, S2, …, Sk] được gọi là phép phân tách không tổn thất
thông tin của quan hệ R(A1, A2, …, An), nếu:

Ω = [S1, S2, …, Sk] là một phép phân tách – kết nối tự nhiên của quan hệ
R(A1, A2, …, An), và
πS1(R)⋈ πS2(R)⋈... ⋈πSk(R) = R
VÍ DỤ 8.14: Phép phân tách không mất thông tin.

Chúng ta kết tự nhiên hai quan hệ PROJECT1, PROJECT2 (hình 8.5) và kết quả
nhận được chính bằng quan hệ PROJECT (hình 8.2). Do đó, phép phân tách quan
hệ PROJECT thành hai quan hệ PROJECT1 và PROJECT2 (ví dụ 8.13) là một
phép phân tách không tổn thất thông tin

VÍ DỤ 8.15: Phép phân tách mất thông tin.
Xét quan hệ R(A,B,C) gồm hai bộ lần lượt (1,2,3) và (4,2,5). Giả sử chúng ta phân
tách R thành R1(A,B) và R2(B,C).
R= A B C R1=πA,B(R)= A B R2=πB,C(R)= B C
1 2 3 1 2 2 3
4 2 5 4 2 2 5
Khi chúng ta thực hiện phép kết tự nhiên R1 với R2, kết quả nhận được là bốn bộ
thay vì hai bộ như quan hệ R ban đầu:
R3 = R1 ⋈R2 A B C
1 2 3
1 2 5
4 2 3
4 2 5
Từ đó, chúng ta kết luận rằng phép phân tách nêu trên tổn thất thông tin.

8.4.2 Thuật toán kiểm tra phân tách không tổn thất thông tin
Như đã trình bày ở trên, việc phân tách một quan hệ thành nhiều quan hệ chiếu có
thể dẫn đến khả năng tổn thất thông tin khi quan hệ ban đầu không được khôi phục
nguyên vẹn từ phép kết tự nhiên của các quan hệ chiếu nhận được.

Nói cách khác, chúng ta tiến hành phân tách quan hệ R với tập phụ thuộc hàm ℑ
thành các quan hệ R1, R2, ..., Rk với tập thuộc tính lần lượt là S1, S2, ..., Sk
(Ri=πSi(R)) và chúng ta muốn kiểm chứng rằng phép phân tách này không tổn thất
thông tin. Một số vấn đề cần chú ý khi phân tách và kiểm tra phép phân tách
không mất thông tin:
Kết tự nhiên có tính chất kết hợp và giao hoán. Do đó, chúng ta không quan
tâm đến trật tự thực hiện kết tự nhiên các quan hệ thành phần Ri. Với t là
một bộ của quan hệ R, khi chiếu t vào tập thuộc tính Si, thì bộ thu được phải
thuộc quan hệ Ri=πSi(R).
Nếu t là một bộ của quan hệ R, thì t chắc chắn xuất hiện trong phép kết
πS1(R)⋈ πS2(R)⋈... ⋈πSk(R).
πS1(R)⋈ πS2(R)⋈... ⋈πSk(R) = R với tập phụ thuộc hàm ℑ khi và chỉ khi
mọi bộ trong phép kết tự nhiên đều nằm trong R.
Sau đây, chúng tôi giới thiệu một phương pháp đơn giản để kiểm tra phân tách
không tổn thất thông tin. Phương pháp này sử dùng tập phụ thuộc hàm để kiểm tra
xem bộ t bất kỳ của πS1(R)⋈πS2(R)⋈... ⋈πSk(R) có thuộc R hay không. Nếu t là
một bộ trong πS1(R)⋈ πS2(R)⋈... ⋈πSk(R), thì trong R phải tồn tại các bộ t1, t2,..., tk
sao cho ti là kết quả của phép chiếu t trên tập thuộc tính Si. Chúng ta cũng biết
rằng ti giống t tại các thuộc tính của Si, đồng thời, ti không xác định giá trị tại các
thuộc tính khác của R – Si.
Để thực hiện thao tác kiểm tra tách không mất thông tin, chúng ta tạo một bảng
đối chiếu T. Giả sử quan hệ R có các thuộc tính A, B, C, ... và các thành phần của t
lần lượt là a, b, c, .... Với mỗi ti, chúng ta ký hiệu các thành phần của ti ứng với các
thuộc tính trong Si giống như t, các thành phần khác của ti được đánh dấu chỉ mục
duy nhất trong T. Nếu R có n thuộc tính, và phép phân tách tạo ra m quan hệ mới,
thì bảng đối chiếu T sẽ có đúng n cột và m hàng (không kể hàng tiêu đề chứa tên
các thuộc tính).

Mục đích của chúng ta là sử dụng tập phụ thuộc hàm ℑ để chứng minh nếu t là
một bộ bất kỳ của πS1(R)⋈πS2(R)⋈... ⋈πSk(R), thì t cũng thật sự nằm trong R. Để
thực hiện điều đó, chúng ta biến đổi bảng đối chiếu T đã lập ở trên bằng cách áp
dụng các phụ thuộc hàm A → B trong tập ℑ với ý nghĩa nếu hai hàng bất kỳ trong
T có giá trị bằng nhau tại A, thì chúng cũng sẽ có giá trị bằng nhau tại B.
VÍ DỤ 8.16: Kiểm chứng kiểm phân tách mất thông tin.

Xét quan hệ R(A,B,C,D) được phân tách ra thành ba quan hệ R1, R2, R3 với tập các
thuộc tính lần lượt là S1 = {A,D}, S2 = {A,C}, S3 = {B,C,D}. Phép phân tách này
được biểu diễn bằng bảng đối chiếu tableau như sau:
A B C D
a b1 c1 d
a b2 c d2
a3 b c d
Trong bảng đối chiếu, mỗi hàng tương ứng với một quan hệ có được sau khi phân
tách. Giá trị thành phần trong từng hàng tùy thuộc vào tập thuộc tính tương ứng
với quan hệ được đại diện bởi hàng đó. Hàng đầu tiên tương ứng với quan hệ có
tập thuộc tính là S1 gồm hai thuộc tính A và D. Do đó giá trị tại hai thuộc tính này
được biểu diễn bởi hai ký tự a và d (không có chỉ số). Trong khi đó, B và C không
nằm trong S1, giá trị tương ứng với các thuộc tính này được biểu diễn bởi b1 và c1
(có chỉ số). Với cách thể hiện này, chúng ta dễ dàng nhận thấy bộ (a,b1,c1,d) thuộc
R1 là kết quả của phép chiếu bộ (a,b,c,d) thuộc R vào tập thuộc tính S1={A,D}.
Cùng phép chiếu này, các thành phần B và C bị loại bỏ khỏi quan hệ R1, nên từ bộ
t1 của quan hệ R1, chúng ta không có bất kỳ thông tin gì về giá trị của hai thành
phần này trong bộ t thuộc quan hệ R đang xét.
Tương tự, hàng thứ hai có các giá trị không có chỉ số dưới tại các thuộc tính A và
C, đồng thời chỉ số dưới 2 được dùng cho các thuộc tính khác. Hàng thứ ba không
đánh dấu chỉ số dưới tại các thuộc tính B, C, và D, trong khi chỉ số dưới 4 được
dùng cho thuộc tính A.

Trong quá trình biến đổi này, nếu bắt gặp trường hợp bộ t xuất hiện trong bảng đối
chiếu tableau, chúng ta kết luận rằng bất kỳ bộ t nào trong phép kết các quan hệ Ri
đều thuộc quan hệ gốc R, tức phép phân tách này không bị mất thông tin. Ngược
lại, nếu đã sử dụng tất cả các phụ thuộc hàm trongℑ để biến đổi mà trong bảng
đối chiếu vẫn không xuất hiện bộ t, chúng ta kết luận ngay rằng phép phân tách
nói trên bị mất thông tin.

VÍ DỤ 8.17: Kiểm chứng kiểm phân tách mất thông tin.
Xét quan hệ R(A,B,C,D) được phân tách ra thành ba quan hệ R1, R2, R3 với tập các
thuộc tính lần lượt là S1 = {A,D}, S2 = {A,C}, S3 = {B,C,D}. Phép phân tách này bảo
toàn thông tin trên tập phụ thuộc hàm của R là ℑ ={A→B, B→ C, CD→A}. Để
chứng minh điều này, chúng ta cần lập bảng đối chiếu như trong ví dụ 8.19, và tìm
cách biến đổi bảng này sao xuất hiện bộ t = (a,b,c,d) trong bảng. Đầu tiên, chúng
ta có bảng đối chiếu như sau:
A B C D
a b1 c1 d
a b2 c d2
a3 b c d
Do hai hàng đầu tiên giống nhau ở giá trị thuộc tính A, nên sau khi áp dụng phụ
thuộc hàm A→B, chúng ta có b1 = b2.
A B C D
a b1 c1 d
a b1 c d2
a3 b c d
Tiếp theo, áp dụng phụ thuộc hàm B→C đối với hai bộ đầu tiên khi giá trị tại
thuộc tính B cùng là b1, kết quả nhận được là c1 = c.
A B C D
a b1 c d
a b1 c d2
a3 b c d
Cuối cùng, do hàng thứ nhất và hàng thứ ba có giá trị bằng nhau tại các thuộc tính
C và D, cho nên phụ thuộc hàm CD→A được áp dụng và a = a3.
A B C D
a b1 c d
a b1 c d2
a b c d
Như vậy, sau ba lần áp dụng phụ thuộc hàm, trong bảng đối chiếu xuất hiện bộ
t=(a,b,c,d). Với kết quả này, chúng ta đã chứng được rằng phép phân tách nói trên
không bị mất thông tin.

8.4.3 Phân tách và bảo toàn phụ thuộc hàm
Chúng ta tiến hành phân tách quan hệ R với tập phụ thuộc hàm ℑ thành các quan
hệ R1, R2, ..., Rk với tập thuộc tính lần lượt là S1, S2, ..., Sk (Ri=πSi(R)) và trên mỗi
quan hệ Ri này tồn tại một tập phụ thuộc hàm ℑi là kết quả của phép chiếu tập phụ
thuộc ℑ trên tập thuộc tính Si. Vấn đề đặt ra là liệu tập phụ thuộc hàm ban đầu ℑ
có được bảo toàn nguyên vẹn sau khi phân tách và kết tự nhiên các quan hệ chiếu
Ri với các tập phụ thuộc hàm ℑi đó hay không.
VÍ DỤ 8.18: Phép phân tách không bảo toàn phụ thuộc hàm.
Giả sử chúng ta có quan hệ PROJECT4(PName, DName, PLocation) cho biết tên
dự án, đơn vị thực hiện, và địa điểm thực hiện dự án.
Chúng ta có các phụ thuộc hàm: (1) PName → DName, (2) PLocation DName →
PName. Phụ thuộc hàm (1) cho biết mỗi dự án do một đơn vị thực hiện. Phụ thuộc
hàm (2) cho biết một đơn vị không thực hiện hai dự án tại cùng địa điểm.
Chúng ta tiến hành phân tách quan hệ PROJECT4 thành hai quan hệ với lược đồ
lần lượt là R1={PName, DName} và R2={PName, PLocation}. Phép phân tách này
phát sinh vấn đề đối với phụ thuộc hàm (2). R1 có duy nhất một phụ thuộc hàm là
PName → DName, trong khi R2 không có phụ thuộc hàm. Do đó, khi kết hai quan
hệ này lại với nhau, quan hệ nhận được không thỏa mãn phụ thuộc hàm (2)
PLocation DName → PName (xem hình 8.7).

Một thể hiện của R1 Một thể hiện của R2
PName DName PName PLocation
ERP1 IS Department ERP1 HCMC
(phụ thuộc hàm PName → DName) (không có phụ thuộc hàm)
Quan hệ gốc nhận được từ phép kết tự nhiên R1⋈R2
PName DName PLocation
ERP1 IS Department HCMC
Hình 8.7. Phép phân tách không bảo toàn phụ thuộc hàm.

8.5 CÁC DẠNG CHUẨN CỦA MÔ HÌNH DỮ LIỆU

QUAN HỆ
Như đã trình bày ở trên, trong quá trình triển khai, vận hành, và khai thác dữ liệu,
thông qua các thao tác thêm, xóa, sửa, chúng ta làm cho dữ liệu gặp phải những lỗi
dị thường, mà nguyên nhân chủ yếu là do sự lặp lại một số dữ liệu trong quan hệ.
Để đảm bảo vấn đề dư thừa dữ liệu không xảy ra, Codd đã đề ra một số dạng
chuẩn. Quá trình đưa cơ sở dữ liệu về dạng chuẩn được gọi là quá trình chuẩn hóa
cơ sở dữ liệu. Trong phần này, chúng ta sẽ tìm hiểu một số dạng chuẩn được sử
dụng phổ biến hiện nay.
8.5.1 Một số định nghĩa

Cho quan hệ R với tập phụ thuộc hàm F, A là một thuộc tính của R. Chúng ta nói
ràng A là thuộc tính khóa (prime) nếu A thuộc một khóa nào đó của R. Ngược lại,
A được gọi là thuộc tính không khóa.
Cho quan hệ R với tập phụ thuộc hàm F, X và Y là hai tập hợp các thuộc tính của
R. Phụ thuộc hàm X → Y được gọi là phụ thuộc hàm đầy đủ nếu xóa bất kỳ thuộc
tính nào ra khỏi X thì phụ thuộc hàm này không tồn tại nữa. Nói cách khác,
∀A∈X, (X – {A}) không xác định hàm Y.

Phụ thuộc hàm X → Y trong quan hệ R gọi là phụ thuộc hàm bắc cầu nếu tồn tại
một tập thuộc tính Z sao cho X xác định Z, Z xác định hàm Y, nhưng Z không xác
định hàm X.
8.5.2 Dạng chuẩn thứ nhất

Một quan hệ R được gọi là ở dạng chuẩn thứ nhất (1NF) khi và chỉ khi các thuộc
tính chỉ chứa các giá trị nguyên tố (giá trị không thể chia tách nhỏ hơn). Như vậy
một quan hệ có ít nhất một thuộc tính có thể nhận giá trị không nguyên tố được
gọi là quan hệ phi chuẩn. Tuy nhiên, chúng ta luôn có thể biến đổi quan hệ phi
chuẩn về dạng chuẩn thứ nhất mà không làm thay đổi dữ liệu chứa trong nó.
VÍ DỤ 8.19: Chuẩn hóa quan hệ phi chuẩn về dạng chuẩn thứ nhất.
Quan hệ phi chuẩn DEPARTMENT_0:
DNUMBER DNAME DLOCATION
1 Phòng Phần mềm trong nước TP. Cần Thơ
TP. Đà Nẵng
TP. Hà Nội
TP. Hồ Chí Minh
2 Phòng Phần mềm nước ngoài TP. Đà Nẵng
TP. Hà Nội
TP. Hải Phòng
Quan hệ ở dạng chuẩn một DEPARTMENT_1:

DNUMBER DNAME DLOCATION
1 Phòng Phần mềm trong nước TP. Cần Thơ
1 Phòng Phần mềm trong nước TP. Đà Nẵng
1 Phòng Phần mềm trong nước TP. Hà Nội
1 Phòng Phần mềm trong nước TP. Hồ Chí Minh
2 Phòng Phần mềm nước ngoài TP. Đà Nẵng
2 Phòng Phần mềm nước ngoài TP. Hà Nội
2 Phòng Phần mềm nước ngoài TP. Hải Phòng
Hình 8.8. Quan hệ DEPARTMENT trước và sau khi chuẩn hóa.


8.5.3 Dạng chuẩn thứ hai
Quan sát quan hệ DEPARTMENT_1 ở ví dụ 8.19, chúng ta nhận thấy rằng, mặc
dù quan hệ đã ở dạng chuẩn thứ nhất, nhưng dữ liệu lặp lại khá nhiều lần. Sự dư
thừa này chính là nguyên nhân dẫn đến các lỗi dị thường của dữ liệu. Dạng chuẩn
thứ hai sẽ giúp chúng ta khắc phục nhược điểm này.
Một quan hệ R được gọi là ở dạng chuẩn thứ hai (2NF) khi và chỉ khi nó ở dạng
chuẩn thứ nhất và mọi thuộc tính không khóa của R phụ thuộc hàm đầy đủ vào
khóa chính của nó.
Để nhận biết một quan hệ có ở dạng chuẩn hai hay không, chúng ta chỉ cần kiểm
tra xem quan hệ đó có phụ thuộc hàm nào vế phải là thuộc tính không khóa, còn
vế trái là tập con thực sự của khóa chính. Nếu tồn tại một phụ thuộc hàm như thế,
chúng ta kết luận ngay quan hệ đó không ở dạng chuẩn hai.
Một khi quan hệ không ở dạng chuẩn thứ hai, chúng ta có thể phân tách nó thành
nhiều quan hệ ở dạng chuẩn thứ hai sao cho các thuộc tính không khóa tương ứng
chỉ phụ thuộc hàm đầy đủ vào khóa chính của nó mà thôi. Nói cách khác, phép
phân tách quan hệ về dạng chuẩn thứ hai được thực hiện dựa trên tập các phụ
thuộc hàm hiện có của quan hệ.
VÍ DỤ 8.21: Chuẩn hóa quan hệ về dạng chuẩn thứ hai.

Xét quan hệ WORKSON_1 với các thuộc tính là ESSN, PNum, WorkHours,
EName, PName, PLocation. Dễ dàng nhận thấy trong quan hệ này có những phụ
thuộc hàm sau đây: ESSN, PNum → WorkHours (1), ESSN → EName (2), PNum
→ PName, PLocation (3). Khóa của quan hệ WORKSON_1 là {ESSN, PNum}.
Dễ dàng nhận thấy thuộc tính không khóa {EName} và {PName, PLocation} vi
phạm điều kiện dạng chuẩn thứ hai do chúng không phụ thuộc hàm đầy đủ vào
khóa chính { ESSN, PNum }. Do đó, quan hệ WORKSON_1 không ở dạng chuẩn
thứ hai. Phép phân tách dựa trên ba phụ thuộc hàm hiện có của quan hệ

WORKSON_1 cho chúng ta ba quan hệ ở dạng chuẩn hai lần lượt là W1(ESSN,
PNum, WorkHours), W2(ESSN, EName) và W3(PNum, PName, PLocation).

8.5.4 Dạng chuẩn thứ ba

Quan hệ R được gọi là ở dạng chuẩn thứ ba (3NF) khi và chỉ khi nó ở dạng
chuẩn thứ hai và mọi thuộc tính không khóa của nó đều không phụ thuộc bắc cầu
vào khóa chính.
Để nhận biết một quan hệ có ở dạng chuẩn thứ ba hay không, chúng ta có thể sử
dụng định nghĩa thứ hai về dạng chuẩn thứ ba như sau:
Quan hệ R được gọi là ở dạng chuẩn thứ ba (3NF) khi và chỉ khi mọi phụ thuộc
hàm không hiển nhiên A1A2...An →B1B2...Bm trong quan hệ R phải thỏa mãn một
trong hai điều kiện sau đây:
Tập các thuộc tính {A1, A2, ..., An} là siêu khóa,hoặc
Các thuộc tính Bk không nằm trong Ai đều là thành viên của một khóa
nào đó (không nhất thiết phải cùng một khóa).
VÍ DỤ 8.22: Quan hệ ở dạng chuẩn 3NF.

Xét ba quan hệ W1, W2, W3 ở ví dụ 8.21. Mỗi quan hệ chỉ có duy nhất một phụ
thuộc hàm, lần lượt là ESSN, PNum → WorkHours (1), ESSN → EName (2),
PNum → PName, PLocation (3). Từ đó, chúng ta thấy rằng khóa của W1 là
{ESSN, PNum}, khóa của W2 là {ESSN}, và khóa của W3 là {PNum}. Cả ba phụ
thuộc hàm nêu trên đều thỏa mãn điều kiện dạng chuẩn thứ ba. Do đó, W1, W2,
W3 lần lượt đều ở dạng chuẩn thứ ba.

VÍ DỤ 8.23: Quan hệ không ở dạng chuẩn 3NF.

Xét quan hệ PROJECT1 trong hình 8.2 . Như chúng ta đã biết, quan hệ
PROJECT1 có hai phụ thuộc hàm (1) PName → PLocation DName, (2) PName

EName → workHours và có khóa là cặp thuộc tính {PName, EName}. Phụ thuộc
hàm (1) vi phạm điều kiện 3NF khi mà vế trái (PName) không phải là siêu khóa,
và vế phải (cả PLocation lẫn DName) không là thành viên của khóa. Như vậy,
PROJECT1 không thuộc dạng chuẩn 3NF.

VÍ DỤ 8.24: Quan hệ ở dạng chuẩn 3NF.

Xét quan hệ PROJECT2 trong hình 8.5. Quan hệ này có phụ thuộc hàm (1)
PName → PLocation DName, và khóa là { PName }. Phụ thuộc hàm (1) thỏa mãn
điều kiện 3NF, do đó quan hệ PROJECT2 thuộc dạng chuẩn 3NF.

8.5.5 Dạng chuẩn Boyce – Codd

Quan hệ R được gọi là ở dạng chuẩn Boyce – Codd (BCNF) khi và chỉ khi với
mọi phụ thuộc hàm không hiển nhiên A1A2...An → B1B2...Bm trên R, {A1, A2, ...,
An} là siêu khóa của R.
Điều này có nghĩa là, một quan hệ thuộc dạng chuẩn BCNF khi và chỉ khi vế trái
của mọi phụ thuộc hàm không hiển nhiên trên quan hệ đó đều phải là siêu khóa.
Do siêu khóa chứa khóa, nên điều kiện BCNF còn có thể được phát biểu như sau:
Vế trái của mọi phụ thuộc hàm không hiển nhiên phải chứa khóa.
VÍ DỤ 8.25: Quan hệ không thuộc dạng chuẩn BCNF.

Xét quan hệ PROJECT1 trong hình 8.2. Quan hệ này có hai phụ thuộc hàm (1)
PName → PLocation DName, (2) PName EName → workHours và có khóa là cặp
thuộc tính {PName, EName}. Phụ thuộc hàm (1) đã vi phạm điều kiện BCNF khi
mà vế trái (thuộc tính PName) không phải là siêu khóa của quan hệ PROJECT1.
Như vậy, PROJECT1 không thuộc dạng chuẩn BCNF.

VÍ DỤ 8.26: Quan hệ thuộc dạng chuẩn BCNF.

Xét quan hệ PROJECT2 trong hình 8.5. Quan hệ này có phụ thuộc hàm (1)
PName → PLocation DName, và khóa là {PName}. Phụ thuộc hàm (1) thỏa mãn
điều kiện BCNF, do đó quan hệ PROJECT2 thuộc dạng chuẩn BCNF.

VÍ DỤ 8.27: Trường hợp đặc biệt của dạng chuẩn BCNF.
Có một trường hợp đặc biệt cần phải quan tâm khi kiểm tra một quan hệ có phải là
BCNF hay không. Chúng ta có thể chứng minh mọi lược đồ quan hệ R(A,B) đều
thuộc dạng chuẩn BCNF. Để làm điều đó, chúng ta cần chỉ ra rằng mọi phụ thuộc
hàm không hiển nhiên duy trì trong R đều thỏa mãn điều kiện BCNF. Xét các khả
năng sau đây:
R không có phụ thuộc hàm không hiển nhiên. R chắc chắn phải thỏa mãn
điều kiện BCNF vì chỉ có phụ thuộc hàm không hiển nhiên mới có thể vi
phạm điều kiện BCNF. Trong trường hợp này, {A,B} chính là khóa duy
nhất của R.
Phụ thuộc hàm A→B được duy trì trong R, nhưng B→A thì không. Thuộc
tính A xác định duy nhất các thuộc tính khác (thuộc tính B), nên {A} là
khóa, và mọi phụ thuộc hàm không hiển nhiên đều có A ở vế trái. Do đó,
điều kiện BCNF không bị vi phạm.
Phụ thuộc hàm B→A duy trì trong R, nhưng A→B thì không. Tương tự như
trường hợp trên, điều kiện BCNF không bị vi phạm.
Cả hai phụ thuộc hàm A→B và B→A đều được duy trì trong R. R có hai
khóa là {A} và {B}. Mọi phụ thuộc hàm đều có vế trái hoặc chứa A hoặc
chứa B, hoặc chứa cả hai. Do đó, điều kiện BCNF không bị vi phạm.
Bốn khả năng nêu trên là tất cả các khả năng có thể xảy ra đối với quan hệ R(A,B).
Trong mọi trường hợp, điều kiện BCNF đều không bị vi phạm. Do đó, quan hệ
R(A,B) luôn luôn thuộc dạng chuẩn BCNF.


8.6 CÁC PHƯƠNG PHÁP CHUẨN HÓA CƠ SỞ DỮ
LIỆU QUAN HỆ
Như đã trình bày ở phần trước, để giải quyết ba vấn đề cơ bản khi thiết kế CSDL
chúng ta nhất thiết phải phân tách quan hệ. Mục đích chính của hoạt động phân
tách quan hệ thành nhiều quan hệ khác là để giảm thiểu những lỗi dị thường gặp
phải trong quá trình thiết kế cơ sở dữ liệu. Đồng thời, chúng ta cũng mong muốn
phép phân tách phải đáp ứng hai yêu cầu quan trọng: không bị mất thông tin, và có
khả năng bảo toàn phụ thuộc hàm.
Tuy nhiên, chúng ta không thể tìm thấy một phép phân tách quan hệ nào thỏa mãn
cả ba tiêu chí này. Trong phạm vi giáo trình, chúng tôi giới thiệu hai phép phân
tách dựa trên các dạng chuẩn cơ sở dữ liệu phổ biến nhất hiện nay:
Phép phân tách dựa trên dạng chuẩn Boyce – Codd và
Phép phân tách dựa trên dạng chuẩn thứ ba.
8.6.1 Phân tách quan hệ về dạng chuẩn BCNF

Sau khi giới thiệu về dạng chuẩn BCNF, chúng tôi giới thiệu một phương pháp
phân tách quan hệ ra thành nhiều quan hệ khác, sao cho chúng đồng thời thỏa mãn
hai điều kiện sau đây:
Các quan hệ này ở dạng chuẩn BCNF.
Quan hệ gốc được khôi phục nguyên vẹn từ các quan hệ mới đạt được.
Ở phần 8.5.5 chúng ta đã chỉ ra rằng các quan hệ có hai thuộc tính luôn ở dạng
chuẩn BCNF. Tuy nhiên, nếu chúng ta phân tách mọi quan hệ ra thành những quan
hệ có hai thuộc tính, thì (1) thỏa mãn, nhưng (2) phần lớn bị vi phạm. Chúng ta lặp
lại ví dụ 8.15 để minh họa điều này.
VÍ DỤ 8.15: Phân tách quan hệ thành những quan hệ có hai thuộc tính.
Xét quan hệ R(A,B,C) gồm hai bộ lần lượt (1,2,3) và (4,2,5). Giả sử chúng ta phân
tách R thành R1(A,B) và R2(B,C).

R= A B C R1=πA,B(R)= A B R2=πB,C(R)= B C
1 2 3 1 2 2 3
4 2 5 4 2 2 5
Khi chúng ta thực hiện phép kết tự nhiên R1 với R2, kết quả nhận được là bốn bộ
thay vì hai bộ như quan hệ R ban đầu:
R3 = R1 ⋈R2 A B C
1 2 3
1 2 5
4 2 3
4 2 5
Từ đó, chúng ta kết luận rằng phép phân tách nêu trên tổn thất thông tin.

Chính vì việc không phải phép phân tách quan hệ ra thành nhiều quan hệ có hai
thuộc tính đều đảm bảo không tổn thất thông tin, cho nên chúng ta phải sử dụng
các phụ thuộc hàm vi phạm điều kiện BCNF để thực hiện việc phân tách. Phép
phân tách được thực hiện cho đến khi nào tất cả quan hệ thu được đều thỏa mãn
điều kiện BCNF. Phép phân tách sẽ kết thúc sau một số lần hữu hạn thực hiện, bởi
vì, một quan hệ sau khi phân tách sẽ cho ra hai quan hệ có số thuộc tính nhỏ hơn
số thuộc tính của quan hệ gốc. Trong trường hợp xấu nhất, tất cả các quan hệ thu
được đều chỉ có hai thuộc tính – hiển nhiên thỏa mãn điều kiện BCNF.
THUẬT TOÁN 8.3: Phân tách quan hệ về dạng chuẩn BCNF.

Đầu vào: Quan hệ R0 với tập phụ thuộc hàm S0
Đầu ra: Tập quan hệ Ri là kết quả của phép phân tách từ R0, tất cả Ri đều BCNF
Thực hiện: Đây là giải thuật đệ quy, các bước sau đây được thực hiện với quan hệ
R và tập phụ thuộc hàm S. Giá trị khởi tạo của R và S lần lượt là R0 và S0.
1. Kiểm tra xem R có thỏa mãn điều kiện BCNF hay không. Nếu thỏa mãn, thì
thuận toán kết thúc và kết quả trả về là R
2. Nếu R vi phạm điều kiện BCNF, chọn X→Y là phụ thuộc hàm vi phạm điều
kiện BCNF. Tính X+ bằng thuật toán 8.1. Gọi hai quan hệ R1, R2 là kết quả

của phép phân tách R theo phụ thuộc hàm X→Y. Tập thuộc tính của R1, R2
lần lượt là X+ và X∪R\X+.
3. Dùng thuật toán 8.2 để tính tập phụ thuộc hàm S1, S2 cho lần lượt R1, R2.
4. Gọi đệ quy thuật toán này để tiếp tục phân tách R1, R2 với tập phụ thuộc
hàm lần lượt là S1, S2.
Kết quả của hai phép phân tách ở bước 4 được hội lại với nhau để trở thành kết
quả trả về của thuật toán.

VÍ DỤ 8.28: Thuật toán phân tách quan hệ về dạng chuẩn BCNF.
Xét quan hệ PROJECT1 trong ví dụ 8.2. Trong ví dụ 8.25 chúng ta đã chỉ ra rằng
phụ thuộc hàm (1) PName → PLocation DName vi phạm điều kiện BCNF. Chúng
ta sẽ sử dụng phụ thuộc hàm này để phân tách quan hệ PROJECT1 thành:
Quan hệ PROJECT2 với tất cả các thuộc tính tham gia trong (1), bao gồm
PName, PLocation, và DName.
Quan hệ PROJECT3 với thuộc tính PName và các thuộc tính không tham
gia (1), bao gồm EName, và workHours.
Phép phân tách như thế này đã được nhắc đến trong ví dụ 8.13. Ở đó, chúng ta đã
chứng minh được PROJECT3 thuộc dạng chuẩn BCNF, do {PName, EName} là
khóa, và vế trái của mọi phụ thuộc hàm khác (nếu có) đều là siêu khóa. Trong ví
dụ 8.20, chúng ta cũng chỉ ra rằng PROJECT2 thuộc dạng chuẩn BCNF với khóa
gồm duy nhất một thuộc tính {PName}.

8.6.2 Đánh giá phép phân tách quan hệ về dạng chuẩn BCNF
8.6.2.1 Khôi phục thông tin sau khi phân tách quan hệ
Trong phần trước, chúng ta đã nhận định rằng các quan hệ gồm hai thuộc tính đều
ở dạng chuẩn BCNF. Chúng ta cũng đã chỉ ra rằng phép phân tách quan hệ R
thành những quan hệ Ri bất kỳ chỉ gồm hai thuộc tính thì dẫn đến trường hợp
không khôi phục lại được quan hệ R từ phép kết tự nhiên các quan hệ Ri.

Với phép phân tách quan hệ về dạng BCNF như trong thuật toán 8.3, các phụ
thuộc hàm vi phạm điều kiện BCNF được xử lý, quan hệ gốc R được phục hồi
nguyên trạng từ các quan hệ do thuật toán 8.3 tạo ra.
Để chứng minh điều này, chúng ta lấy ví dụ đối với quan hệ R(A,B,C) và phụ
thuộc hàm B → C vi phạm điều kiện BCNF, nghĩa là B không phải là khóa ngoại.
Phép phân tách dựa trên phụ thuộc hàm B → C sẽ tạo hai quan hệ với lược đồ
quan hệ tương ứng R1(A,B) và R2(B,C).
Gọi t là một bộ của R, ký hiệu t=(a,b,c), với a, b, c lần lượt là các thành phần của t
tương ứng với các thuộc tính A, B, và C. Do R1(A,B) = πA,B(R), nên trong R1 xuất
hiện bộ t1 = πA,B(t) = (a,b). Tương tự, do R1(B,C) = πB,C(R), nên trong R2 xuất hiện
bộ t2 = πB,C(t) = (b,c). Khi áp dụng phép kết tự nhiên cho hai bộ t1 và t2 (cùng giá
trị b tại thuộc tính B), chúng ta nhận được bộ t ban đầu. Như vậy, khi phân tách bất
kỳ bộ t nào thành hai bộ t1 và t2, chúng ta đều có thể nhận lại bộ t bằng phép kết tự
nhiên hai bộ t1 và t2.
Tuy nhiên, trong một số trường hợp phép kết tự nhiên trả về một bộ t mà chúng ta
không chắc chắn bộ t này có thực sự là một bộ của quan hệ R trước khi phân tách.
Ví dụ, có hai bộ trong quan hệ R, lần lượt là t=(a,b,c), và u=(d,b,e). Khi chiếu t
xuống R1(A,B), u xuống R2(B,C), chúng ta nhận hai bộ t1=(a,b), và u1=(b,e). Phép
kết tự nhiên giữa hai bộ này diễn trên thao giá trị b của thuộc tính B, và kết quả trả
về là bộ (a,b,e). Chúng ta không chắc rằng bộ (a, b, e) có thuộc R hay không.
Với giả định phụ thuộc hàm B →C đúng trên quan hệ R, chúng ta có thể khẳng
định rằng bộ (a,b,e) phải thuộc quan hệ R. Vì t và u có giá trị bằng nhau tại thuộc
tính B, cho nên chúng cũng có giá trị bằng nhau tại thuộc tính C (đồng nghĩa với
c=e). Vì vậy bộ (a,b,e) bằng với bộ (a,b,c).

Như vậy, với giả định A, B, C là ba thuộc tính đơn lẻ, chúng ta dễ dàng khôi phục
quan hệ R từ kết quả của thuật toán 8.3. Điều này cũng đúng với trường hợp A, B,
C là ba tập thuộc tính bất kỳ trong quan hệ R. Nghĩa là:
Nếu phụ thuộc hàm Y→Z được áp dụng cho quan hệ R, với tập thuộc tính là
X ∪ Y ∪ Z, thì R=πX∪Y(R) ⋈πY∪Z(R)
KẾT LUẬN:
Nếu chúng ta phân tách quan hệ R bằng thuật toán 8.3, thì quan hệ gốc R có
thể được khôi phục hoàn toàn bởi phép kết tự nhiên của các quan hệ Ri đạt
được từ thuật toán này.
8.6.2.2 Bảo toàn phụ thuộc hàm sau khi phân tách quan hệ
Trong nhiều trường hợp, chúng ta không thể phân tách một quan hệ bất kỳ thành
nhiều quan hệ BCNF đáp ứng đồng thời cả hai yêu cầu không tổn thất thông tin và
bảo toàn phụ thuộc hàm. Dưới đây là ví dụ 8.29 minh họa cho trường hợp mà
chúng ta phải chọn lựa giữa bảo toàn phụ thuộc hàm và BCNF.
VÍ DỤ 8.29: Phép phân tách không bảo toàn phụ thuộc hàm.
Lặp lại ví dụ 8.18 với quan hệ PROJECT4(PName, DName, PLocation) với các
phụ thuộc hàm: (1) PName→DName, và (2) PLocation DName → PName.
Vì quan hệ PROJECT4 có hai khóa là {PName, PLocation} và {PLocation,
DName} nên (1) vi phạm điều kiện BCNF. Do đó, thuật toán 8.3 thực hiện phép
phân tách PROJECT4 theo phụ thuộc hàm PName→DName. Phép phân tách này
cho ra hai quan hệ mới có lược đồ là (PName, DName) và (PName, PLocation)
với tập phụ thuộc hàm lần lượt là {PName→DName} và {PName, PLocation}.
Hình 8.7 minh họa số liệu cụ thể cho phép phân tách này. Rõ ràng sau khi phân
tách và kết tự nhiên các quan hệ nhận được, phụ thuộc hàm (2) không được duy
trì. Do đó, phép phân tách nói trên không bảo toàn được phụ thuộc hàm trong
PROJECT4.

Một thể hiện của R1 Một thể hiện của R2
PName DName PName PLocation
(phụ thuộc hàm PName → DName) (không có phụ thuộc hàm)
Quan hệ gốc nhận được từ phép kết tự nhiên R1⋈R2
PName DName PLocation
Hình 8.7. Phép phân tách không bảo toàn phụ thuộc hàm

8.6.3 Phân tách quan hệ về dạng chuẩn thứ ba

Để giải quyết vấn đề được nêu ở phần trước, chúng ta cần phải nới lỏng điều kiện
BCNF đối với một số lược đồ quan hệ không thể phân tách thành các quan hệ
BCNF trong khi vẫn bảo toàn các phụ thuộc hàm định nghĩa trên nó. Chúng ta
nhận thấy điều kiện 3NF có phần mở rộng hơn so với điều kiện BCNF khi mà
chấp nhận cả trường hợp các phụ thuộc hàm không hiển nhiên có vế trái không
phải là siêu khóa nhưng các thuộc tính ở vế phải lại là thành viên của khóa nào đó.
Trong mục này, chúng ta sẽ xây dựng một phương pháp phân tách quan hệ thành
các quan hệ 3NF trong khi vẫn đảm bảo tính bảo toàn phụ thuộc hàm và khả năng
khôi phục thông tin sau khi phân tách.
THUẬT TOÁN 8.4: Phân tách quan hệ về dạng chuẩn 3NF.

Đầu vào: Quan hệ R và tập phụ thuộc hàm ℑ trên R.
Đầu ra: Phân tách quan hệ R thành nhiều quan hệ dạng chuẩn 3NF. Phép phân
tách không làm tổn thất thông tin và bảo toàn phụ thuộc hàm.
Thực hiện:
1. Tìm cơ sở nhỏ nhất của F, gọi là G.

2. Với mỗi phụ thuộc hàm X → A trong G, sử dụng X A như là lược đồ của
một trong các quan hệ của phép phân tách.
Nếu trong các tập thuộc tính có được ở bước 2 không có siêu khóa của R, thì bổ
sung một quan hệ mà lược đồ của nó là khóa của R.

VÍ DỤ 8.30: Phân tách quan hệ về dạng chuẩn 3NF
Xét quan hệ R(A,B,C,D,E) với các phụ thuộc hàm F = {AB → C, C → B, A → D}.
Để bắt đầu, chúng ta phải xác định cơ sở nhỏ nhất của F. Dễ dàng nhận thấy rằng
tập phụ thuộc hàm F cho trước là cơ sở nhỏ nhất của chính nó với các lý do sau
đây:
Khi loại bỏ bất kỳ phụ thuộc hàm nào ra khỏi F, tập phụ thuộc hàm còn lại
không thể là cơ sở của F
Khi loại bỏ một thuộc tính ra khỏi vế trái của một phụ thuộc hàm bất kỳ
trong F, tập phụ thuộc hàm mới thu được không thể là cơ sở của F
Tiếp theo, từ từng phụ thuộc hàm trong cơ sở tối thiểu của F (trong trường hợp
này chính là F), chúng ta tạo một lược đồ quan hệ tương ứng. Như vậy chúng ta có
ba lược đồ quan hệ mới S1, S2, S3 với tập thuộc tính lần lượt là {A,B,C}, {B,C}, và
{A,D}. Do {B,C} là tập con của {A,B,C} nên chúng ta không cần quan tâm tới
quan hệ S2.
Cuối cùng, do hai quan hệ S1, S2 không chứa thuộc tính khóa của R, nên chúng ta
phải bổ sung một quan hệ với tập thuộc tính là khóa của quan hệ R vào trong phép
phân tách đã nêu. Do quan hệ R có hai khóa là {A,B,E} và {A,C,E}, chúng ta chọn
quan hệ S4 có tập thuộc tính là {A,B,E}. Như vậy, thuật toán 8.4 phân tách quan hệ
R ra thành ba quan hệ S1(A,B,C), S2(A,D), và S4(A,B,E).

8.6.4 Đánh giá phép phân tách quan hệ về dạng chuẩn 3NF
Để đánh giá thuật toán tách quan hệ về dạng chuẩn 3NF, chúng ta cần thể hiện ba
vấn đề qua phép phân tách này:

Không tổn thất thông tin: Bắt đầu từ quan hệ có tập thuộc tính K là siêu
khóa của R. Để tính bao đóng K+, chúng ta bắt đầu từ K, và tại mỗi bước,
chúng ta tìm một phụ thuộc hàm B1B2...Bm→C, sao cho các Bi thuộc K+ còn
C thì không. Tại đây, chúng ta thêm C vào tập K+ và lặp lại thao tác trên
cho đến khi không tìm thấy phụ thuộc hàm nào như thế nữa. Đồng thời, do
K là siêu khóa, nên K+ là tập hợp tất cả các thuộc tính của R. Trật tự thực
hiện các phụ thuộc hàm B1B2...Bm→C nói trên nếu đem áp dụng cho bảng
đối chiếu tableau, thì chúng ta sẽ nhận được một hàng mà mọi thành phần
đều không có chỉ số dưới. Điều này có nghĩa là, phép phân tách trên không
gây tổn thất thông tin.
Bảo toàn phụ thuộc hàm: Ứng với mỗi phụ thuộc hàm fi trong cơ sở tối
thiểu chúng ta đều tạo một quan hệ Ri với tập thuộc tính chính là các thuộc
tính xuất hiện trong fi . Do vậy, phụ thuộc hàm fi được bảo toàn bên trong
quan hệ Ri.
Dạng chuẩn thứ ba: Đối với quan hệ Rk mới tạo ứng với tập thuộc tính là
khóa K của R, mọi thuộc tính của quan hệ này đều là nguyên mẫu, do đó tất
cả phụ thuộc hàm (nếu có) trên Rk đều không vi phạm điều kiện 3NF. Đối
với các quan hệ xuất phát từ mỗi phụ thuộc hàm fi trong cơ sở tối thiểu,
chúng ta cần phải chứng minh rằng điều kiện 3NF chỉ có thể bị vi phạm khi
cơ sở ban đầu không phải là tối thiểu. Tuy nhiên, chứng minh này không
nằm trong phạm vi trình bày của giáo trình.
8.7 TÓM TẮT

Trong chương này chúng ta đã nghiên cứu các vấn đề liên quan đến việc thiết kế
cơ sở dữ liệu quan hệ bằng cách xây dựng các ràng buộc cho cơ sở dữ liệu. Chúng
ta định nghĩa phụ thuộc hàm như là ràng buộc phổ biến nhất trong quan hệ. Phụ
thuộc hàm là cơ sở để định nghĩa khóa cho quan hệ. Quá trình chuẩn hóa dữ liệu
được thực hiện dựa trên các khái niệm phụ thuộc hàm và khóa của quan hệ.

Trong phần tiếp theo, chúng ta tìm hiểu các quy luật biến đổi của phụ thuộc hàm.
Các quy luật này bao gồm quy luật phân tách, quy luật kết hợp, và quy luật bắc
cầu. Dựa trên các phụ thuộc hàm và các quy luật biến đổi của chúng, chúng ta xác
định bao đóng các thuộc tính, và tập đóng các phụ thuộc hàm. Từ các khái niệm
này, chúng ta dễ dàng trả lời câu hỏi một thuộc tính có được dẫn xuất từ một tập
các thuộc tính khác trong quan hệ hay không.
Chúng ta làm quen với một số vấn đề về lỗi dị thường trong quá trình thiết kế dữ
liệu. Để khắc phục các vấn đề này, chúng ta tiến hành phân tách quan hệ. Quá
trình phân tách được thực hiện phải tuân theo một số nguyên tắc, để có thể cho ra
những quan hệ đạt chuẩn. Trong chương này, chúng ta tập trung nghiên cứu hai
dạng chuẩn phổ biến nhất hiện nay, đó là dạng chuẩn Boyce – Codd (BCNF), và
dạng chuẩn thứ ba (3NF). Thuật toán phân tách quan hệ về dạng chuẩn BCNF áp
dụng đối với những quan hệ có phụ thuộc hàm vi phạm điều kiện BCNF, để trả về
một tập các quan hệ thỏa mãn điều kiện BCNF. Thuật toán này đảm bảo dữ liệu
được phục hồi nguyên vẹn sau khi phân tách. Tuy nhiên, các phụ thuộc hàm sau
khi phân tách sẽ không được bảo toàn. Với thuật toán phân tách quan hệ về dạng
chuẩn 3NF, không những thông tin được khôi phục hoàn toàn sau khi phân tách,
mà phép phân tách này còn duy trì các phụ thuộc hàm trên quan hệ ban đầu.

C
CHHƯ
ƯƠƠN
NGG
9
TỐI ƯU HÓA TRUY VẤN
Mục tiêu
Chương này cung cấp cho người đọc các kiến thức từ cơ bản tới chuyên sâu về
vấn đề tối ưu hóa câu truy vấn nhằm giúp họ có sự lựa chọn thích hợp khi xây
dựng các câu truy vấn đáp ứng các chiến lược khai thác dữ liệu khác nhau.
Nội dung
Tổng quan về tối ưu hóa truy vấn
Kỹ thuật tối ưu hóa truy vấn
Phương pháp khung nhìn

Giới thiệu
Các ngôn ngữ truy vấn bậc cao nói chung và ngôn ngữ truy vấn dữ liệu nói riêng
mặc dù biểu diễn rất dễ dàng, nhưng khi thực hiện trong máy tính lại mất rất nhiều
thời gian, thậm chí chiếm nhiều không gian bộ nhớ, bộ xử lý của máy tính. Do đó,
trước khi thực hiện các câu lệnh truy vấn dữ liệu, người ta có xu hướng biến đổi về
dạng khác, có thời gian thực hiện ngắn hơn hoặc chiếm ít không gian bộ nhớ hơn
nhưng cho ra cùng kết quả. Việc làm này được gọi là tối ưu hóa câu lệnh truy vấn.
Trong chương 8 chúng ta đã nghiên cứu vấn đề chuẩn hóa cơ sở dữ liệu về dạng
BCNF hay 3NF. Chuẩn hóa cơ sở dữ liệu là nhiệm vụ hàng đầu của nhân viên thiết
kế cơ sở dữ liệu. Tác dụng của việc chuẩn hóa là để giảm thiểu những sai sót trong
quá trình thiết kế dữ liệu, mà cụ thể đó là giảm sự trùng lặp dữ liệu, những vấn đề
khi chỉnh sửa hay xóa bỏ dữ liệu. Đó cũng chính là cách chúng ta tối ưu hóa cơ sở
dữ liệu về không gian lưu trữ.
Chúng ta xây dựng cơ sở dữ liệu nhằm mục đích để cung cấp những thông tin cần
thiết khi có yêu cầu. Các câu truy vấn được xây dựng để giải quyết vấn đề đó. Và
tất nhiên, chúng ta cũng có yêu cầu các câu truy vấn này phải được thực hiện trong
một thời gian ngắn nhất, mà vẫn cho ra kết quả chính xác. Xây dựng các câu truy
vấn hiệu quả cao chính là cách mà chúng ta tối ưu hóa cơ sở dữ liệu về tốc độ hay
thời gian xử lý. Do đó, tối ưu hóa câu truy vấn là một vấn đề đặc biệt quan trọng
đối với người sử dụng, khai thác cơ sở dữ liệu.

9.1 TỔNG QUAN VỀ TỐI ƯU HÓA TRUY VẤN
Thực tế, SQL là ngôn ngữ truy vấn được sử dụng rộng rãi trong hầu hết các hệ
quản trị cơ sở dữ liệu quan hệ. Câu truy vấn cơ sở dữ liệu trước hết được biên dịch
thành biểu thức đại số quan hệ tương đương – được biểu diễn ở dạng cây biểu thức
– và sau đây được tối ưu hóa. Trong nhiều trường hợp câu truy vấn SQL có cấu
trúc phức tạp, bao gồm nhiều câu truy vấn đơn kết hợp lại với nhau. Chúng ta sẽ
biểu diễn từng đoạn truy vấn đơn giản đó thành những biểu thức đại số quan hệ và
biến đổi chúng về dạng đơn giản hơn nhưng cho ra cùng kết quả. Câu truy vấn đơn
có thể bao gồm một phát biểu SELECT – FROM – WHERE, bao gồm cả mệnh đề
ORDER BY, GROUP BY và HAVING. Tuy nhiên, đối với câu truy vấn lồng, các
câu truy vấn cần phải được xử lý như những câu truy vấn đơn riêng rẽ. Ví dụ 9.1
minh họa cho một câu truy vấn lồng như thế.
VÍ DỤ 9.1: Biểu diễn câu truy vấn SQL bằng (các) biểu thức đại số quan hệ.
Xét câu truy vấn SQL sau đây trong cơ sở dữ liệu COMPANY:
Q1: SELECT EName
FROM EMPLOYEE
WHERE ESalary > ( SELECT MAX (ESalary)
FROM EMPLOYEE
WHERE DNum = 5)
Câu truy vấn lồng này được biểu diễn bằng hai câu truy vấn đơn như sau:
Q1a: SELECT MAX (ESalary)
FROM EMPLOYEE
WHERE DNum = 5
Q1b: SELECT EName
FROM EMPLOYEE
WHERE ESalary > C
Với C là kết quả trả về từ câu truy vấn Q1a.
Hai biểu thức đại số quan hệ tương đương với hai câu truy vấn này lần lượt là:
ℑMAX ESalary σDNum=5(EMPLOYEE))
(σ

πEName(σESalary>C(EMPLOYEE))

Tóm lại, một khi nói đến tối ưu hóa một câu truy vấn SQL, chúng ta tìm cách biểu
diễn câu truy vấn đó về dạng biểu thức đại số quan hệ. Sau đó chúng ta tiến hành
tối ưu hóa biểu thức đại số quan hệ này thông qua cây đại số quan hệ bằng các
phương pháp tối ưu hóa thích hợp để nhận được một biểu thức được đánh giá là
tốt hơn, nhưng cho ra cùng kết quả với biểu thức ban đầu. Cuối cùng, chúng ta
biểu diễn biểu thức này bằng một câu truy vấn SQL.
9.2 PHƯƠNG PHÁP ƯỚC LƯỢNG CÂY ĐẠI SỐ

QUAN HỆ
Như đã trình bày ở trên, để tối ưu hóa câu truy vấn, chúng ta tối ưu hóa biểu thức
đại số quan hệ tương ứng với câu truy vấn đó. Đồng thời, mỗi biểu thức đại số
quan hệ có thể biểu diễn được bởi một cây đại số quan hệ. Như vậy, chúng ta cần
phải tối ưu hóa cây đại số quan hệ.
Vấn đề đặt ra ở đây là dựa trên tiêu chuẩn nào để chúng ta xác định cây đại số
quan hệ hiện có đã tối ưu hay chưa. Nói cách khác, chúng ta cần phải ước lượng
chi phí thực hiện các phép tính trên cây đại số quan hệ để từ đó phát hiện ra được
những sự điều chỉnh cần thiết để tiết kiệm được chi phí thực hiện.
Chúng ta bắt đầu đánh giá cây biểu thức đại số quan hệ từ các phép toán ở mức
phấp nhất (tức là các biểu thức tại đáy của cây). Các phép toán này có đầu vào là
các quan hệ được lưu trữ vật lý trong cơ sở dữ liệu; đồng thời kết quả trả về của
chúng được lưu trữ trong các quan hệ tạm. Tiếp theo, chúng ta có thể sử dụng các
quan hệ tạm này làm đầu vào để thực hiện các phép toán ở mức trên tiếp theo
trong cây biểu thức. Bây giờ đầu vào của phép toán có thể là các quan hệ tạm hoặc
là các quan hệ được lưu trữ trong cơ sở dữ liệu. Chúng ta cứ tiếp tục như thế cho
đến khi đạt đến đỉnh của cây biểu thức.

Việc đánh giá cây biểu thức được thực hiện thông qua quá trình ước lượng chi phí
của từng phép toán chọn, chiếu và kết. Chi phí ở đây được hiểu là chi phí thực
hiện các phép toán trong biểu thức và chi phí lưu trữ quan hệ tạm lên đĩa cứng để
thực hiện các phép toán kế tiếp. Giả sử các bản ghi của quan hệ tạm được xếp vào
một vùng đệm (có kích thước là ff), và khi vùng đệm bị đầy thì chúng sẽ được ghi
lên đĩa. Khi đó chi phí của thao tác ghi lên đĩa tương đương với nf/ff, với nf là số
các bộ trong quan hệ tạm cần lưu trữ.
VÍ DỤ 9.2: Ước lượng chi phí thực hiện của một biểu thức đại số quan hệ.
Xét cây biểu thức đại số quan hệ sau đây:
Hình 9.1. Cây biểu thức đại số quan hệ.
Để ước lượng chi phí của thao tác ghi lên đĩa, chúng ta cần tính tới kích thước của
ba bảng tạm phát sinh trong quá trình thực hiện câu truy vấn. Đầu tiên đó là bảng
tạm T1 chứa kết quả của phép chọn trên DEPARTMENT. Kế tiếp khi thực hiện
phép kết tự nhiên giữa T1 với EMPLOYEE chúng ta có bảng tạm T2. Cuối cùng,
bảng tạm T3 được tạo để chứa kết quả của phép chiếu trên T2.

9.3 NGUYÊN TẮC TỐI ƯU HÓA BIỂU THỨC ĐẠI

SỐ QUAN HỆ
Trong các phép toán đại số quan hệ, phép nhân chéo và phép kết chi phí cao hơn
so với các phép toán khác. Điều này có thể giải thích như sau. Về cơ bản phép kết
là sự kết hợp giữa phép chọn từ kết quả của phép nhân chéo, mà trong chương 5
chúng ta đã tính toán kết quả của phép nhân chéo quan hệ R1 có n1 thuộc tính, m1

bộ với quan hệ R2 có n2 thuộc tính, m2 bộ là một quan hệ R3 có n1+n2 thuộc tính và
m1*m2 bộ. Quan hệ R3 được tạo ra bằng cách kết hợp từng bộ của R1 với từng bộ
của R2. Như vậy, phép nhân chéo không chỉ gây tốn kém thì không gian lưu trữ mà
còn rất mất thời gian.
Để cải thiện chi phí thực hiện cũng như chi phí lưu trữ, các nguyên tắc sau đây
giúp chúng ta tối ưu hóa câu truy vấn thông qua việc thay đổi trình tự thực hiện
các phép toán trong biểu thức đại số quan hệ tương đương:
Một cách khái quát, các nguyên tắc sau đây có thể giúp chúng ta tối ưu hóa câu
truy vấn thông qua việc thay đổi trình tự thực hiện các phép toán:
Ưu tiên thực hiện các phép toán một ngôi nhằm giới hạn khối lượng dữ liệu
trung gian được lưu trữ trong các bảng tạm, đồng thời cũng làm giảm chi
phí đọc và ghi bảng tạm vào đĩa cứng.
Hạn chế việc thực hiện các phép nhân chéo giữa hai quan hệ với tất cả các
thuộc tính của chúng. Hạn chế kích thước của các quan hệ tham gia phép
nhân chéo bằng phép chọn và phép chiếu.
Phép kết bằng kết nối các bộ giữa hai quan hệ có giá trị bằng nhau tại các
thuộc tính trùng tên. Do đó, chi phí thực hiện phép kết bằng sẽ thấp hơn
nhiều so với chi phí thực hiện phép nhân chéo.
Do phép chọn và phép chiếu có tính chất giao hoán và kết hợp, do đó chúng
ta có thể nhóm các phép chọn và phép chiếu liên tiếp thành một phép toán
duy nhất nhằm giảm khối lượng dữ liệu trung gian.
Xác định các thành phần bị lặp lại trong câu truy vấn. Trong trường hợp sự
lặp lại này khá thường xuyên, chúng ta nên lập câu truy vấn con để khai
thác khả năng tính toán và lưu trữ một lần nhưng sử dụng nhiều lần sau đó.

Tiền xử lý các bảng tham gia trong câu truy vấn nhằm giảm thiểu các sự kết
nối không cần thiết bằng cách sắp xếp, tạo chỉ mục, tạo khung nhìn thích
hợp, …
Đánh giá sơ bộ chi phí thực hiện câu truy vấn theo những trình tự thực hiện
khác nhau. Chi phí trong trường hợp này bao gồm: số phép toán thực hiện,
chi phí thời gian, không gian lưu trữ, …
9.4 KỸ THUẬT TỐI ƯU HÓA BIỂU THỨC ĐẠI SỐ

QUAN HỆ
Các nguyên tắc tối ưu hóa được trình bày ở trên đều có chung một đặc điểm là
biến đổi các biểu thức đại số về dạng có chi phí thực hiện thấp hơn. Sự biến đổi
này chỉ thực sự được chấp nhận khi các biểu thức đại số cho ra quan hệ kết quả
tương đương với nhau. Trong chương 4, chúng ta đã định nghĩa hai quan hệ tương
đương là hai quan hệ có cùng tập thuộc tính, và quan hệ này là kết quả của sự thay
đổi thứ tự các thuộc tính, hoặc thứ tự các bộ của quan hệ kia.
Khi thực hiện các phép toán trong biểu thức đại số quan hệ, chúng ta phải quan
tâm tới trình tự thực hiện các phép toán trong trường hợp không sử dụng dấu
ngoặc đơn. Các phép toán một ngôi có thứ tự ưu tiên cao hơn so với các phép toán
hai ngôi.
Tối ưu hóa thực chất là xác định trình tự thực hiện các phép toán trong biểu thức
đại số nhằm tiết kiệm chi phí thực hiện, không gian lưu trữ cũng như thời gian
thực hiện nhưng không làm thay đổi kết quả trả về. Ba phép toán được sử dụng
thường xuyên nhất trong biểu thức đại số là chọn, chiếu và kết. Phép chọn và phép
chiếu cho ra quan hệ kết quả có kích thước nhỏ hơn quan hệ ban đầu. Trong khi
đó, kết quả của phép chiếu là một quan hệ có kích thước lớn hơn rất nhiều so với
các quan hệ tham gia. Dựa trên các tính chất này, chúng ta xây dựng các kỹ thuật
tối ưu hóa và áp dụng chúng trong từng trường hợp cụ thể.

9.4.1. Các quy tắc biến đổi biểu thức đại số quan hệ
Để bắt đầu, chúng ta thống nhất các ký hiệu được sử dụng trong biểu thức đại số
quan hệ như sau:
F1, F2, … là các điều kiện
L1, L2, … là tập các thuộc tính
E1, E2, … là các biểu thức đại số quan hệ
σ là phép chọn
π là phép chiếu
× là phép nhân chéo
⋈F là phép kết có điều kiện
⋈ là phép kết tự nhiên
Quy tắc 1: Giao hoán phép kết và phép nhân chéo

Nếu E1 và E2 là hai biểu thức đại số quan hệ và F là điều kiện trên các thuộc
tính của E1 và E2:
(R1): E1 ⋈F E2 = E2 ⋈F E1
(R2): E1 ⋈ E2 = E2 ⋈ E1
(R3): E1 × E2 = E2 × E1
Hình 9.2. Biểu diễn quy tắc (1) bằng cây biểu thức.
Quy tắc 2: Kết hợp phép kết và phép nhân chéo

Nếu E1, E2 và E3 là các biểu thức đại số quan hệ, F1 là điều kiện trên các thuộc
tính của E1 và E2, F2 là điều kiện trên các thuộc tính của E2 và E3

(R4): (E1 ⋈F1 E2) ⋈F2 E3 = E1 ⋈F1 (E2 ⋈F2 E3)
(R5): (E1 ⋈ E2) ⋈ E3 = E1 ⋈ (E2 ⋈ E3)
(R6): (E1 × E2) × E3 = E1 × (E2 × E3)
Quy tắc 3: Thay thế nhiều phép chiếu liên tiếp bằng một phép chiếu duy nhất
Nếu E là biểu thức đại số quan hệ và L1, L2 là hai tập thuộc tính của E, L1 ⊆ L2
(R7): πL2(πL1(E)) = πL2(E)
Quy tắc 4: Thay thế nhiều phép chọn liên tiếp bằng một phép chọn duy nhất
Nếu E là biểu thức đại số quan hệ và F, F1, F2, …, Fn là các điều kiện trên tập
thuộc tính của E, F = F1 ∧ F2 ∧ … ∧ Fn
(R8): σF1(σF2(…σF1(E)…)) = σ F1 ∧ F2 ∧ … ∧ Fn (E) = σF(E)

Quy tắc 5: Giao hoán các phép chọn

Nếu E là biểu thức đại số quan hệ và F1, F2 là hai điều kiện trên tập thuộc tính
của E:
(R9): σF1(σF2(E)) = σF2(σF1(E))
Quy tắc 6: Giao hoán phép chọn và phép chiếu

Nếu E là biểu thức đại số quan hệ và F là điều kiện trên tập thuộc tính L của E:
(R10): πL(σF(E)) = σF(πL(E))
Nếu E là biểu thức đại số quan hệ, L1, L2 là hai tập thuộc tính của E (L2 ⊆ L1),
F là điều kiện trên tập thuộc tính L1
(R11): πL2(σF(E)) = πL2(σF(πL1(E)))

Quy tắc 7: Giao hoán phép chọn và phép nhân chéo
Nếu E1, E2 là hai biểu thức đại số quan hệ và F là điều kiện trên tập thuộc tính
L của E1:
(R12): σF(E1 × E2) = σF(E1) × E2
Nếu E1, E2 là hai biểu thức đại số quan hệ, F = F1 ∧ F2, với F1 là điều kiện trên
tập thuộc tính L1 của E1, F2 là điều kiện trên tập thuộc tính L2 của E2:
(R13): σF(E1 × E2) = σF1 ∧ F2(E1 × E2) = σF1(E1) × σF2(E2)
Quy tắc 8: Giao hoán phép chọn và phép hợp

Nếu E1, E2 là hai biểu thức đại số quan hệ có cùng lược đồ và F là điều kiện
trên các thuộc tính của hai biểu thức này:
(R14): σF(E1 ∪ E2) = σF(E1) ∪ σF(E2)
Quy tắc 9: Giao hoán phép chọn và phép trừ

Nếu E1, E2 là hai biểu thức đại số quan hệ có cùng lược đồ và F là điều kiện
trên các thuộc tính của hai biểu thức này:

(R15): σF(E1 – E2) = σF(E1) – σF(E2)
Quy tắc 10: Giao hoán phép chọn và phép kết tự nhiên
Nếu E1, E2 là hai biểu thức đại số quan hệ và F là điều kiện trên các thuộc tính
chung của hai biểu thức này:
(R16): σF(E1 ⋈ E2) = σF(E1) ⋈ σF(E2)
Quy tắc 11: Giao hoán phép chiếu và phép nhân chéo
Nếu E1, E2 là hai biểu thức đại số quan hệ, L1, L2 lần lượt là tập các thuộc tính
của E1 và E2:
(R17): πL1, L2(E1 × E2) = πL1(E1) × πL2(E2)
Quy tắc 12: Giao hoán phép chiếu và phép hợp

Nếu E1, E2 là hai biểu thức đại số quan hệ có cùng tập thuộc tính L:
(R18): πL(E1 ∪ E2) = πL(E1) ∪ πL(E2)

Quy tắc 13: kết hợp phép giao và phép hợp

Nếu E1, E2 và E3 là các biểu thức đại số quan hệ có tính khả hợp:
(R19): (E1 ∪ E2) ∪ E3= E1 ∪ (E2 ∪ E3)
9.4.2. Thuật toán tối ưu hóa biểu thức đại số quan hệ

Với mục tiêu tối ưu hóa biểu thức đại số quan hệ thông qua việc biến đổi biểu thức
này bằng cách áp dụng các quy tắc tối ưu hóa trình bày ở phần trên, chúng ta xây
dựng một trình tự để thực hiện các phép toán trong biểu thức. Trình tự này được
thể hiện chi tiết trong giải thuật 9.1 được trình bày dưới đây. Tuy nhiên, khi sử
dụng thuật toán này để tối ưu hóa biểu thức đại số quan hệ, chúng ta cần lưu ý một
số vấn đề sau đây:
Thuật toán tập trung chủ yếu vào nhiệm vụ làm giảm bớt khối lượng dữ liệu
trung gian chứ không giúp xác định trình tự thực hiện các phép kết.
Thuật toán cung cấp một phương án để chúng ta lựa chọn khi thực thi cây
truy vấn, đây chưa phải là phương án tốt nhất.
Các phép biến đổi còn có thể được thực hiện dựa trên tập hợp đầy đủ các
phép toán đại số quan hệ chứ không chỉ gói gọn vào các phép toán được
trình bày.

Tối ưu hóa biểu thức đại số quan hệ chỉ là một phần trong chiến lược tối ưu
hóa câu truy vấn, vì ngoài trình tự thực hiện các phép toán trong biểu thức,
chúng ta còn có thể tối ưu hóa câu truy vấn bằng các thao tác tiền xử lý dữ
liệu. Vấn đề này vượt ra khỏi phạm vi của giáo trình cho nên chúng tôi
không đi sâu vào chi tiết.
THUẬT TOÁN 9.1: Tối ưu hóa biểu thức đại số quan hệ.
Đầu vào: Biểu thức đại số quan hệ cần tối ưu (biểu diễn bởi cây biểu thức)
Đầu ra: Biểu thức đại số quan hệ tối ưu (biểu diễn bởi cây biểu thức)
Thuật toán:
Bước 1: Áp dụng quy tắc R4 tách phép chọn phức tạp thành một chuỗi các
phép chọn liên tiếp. Đối với mỗi phép chọn, tiếp tục áp dụng các quy tắc từ
R4 đến R11 nhằm đẩy các phép chọn xuống càng sâu càng tốt
Bước 2: Đối với mỗi phép chiếu, áp dụng các quy tắc R3, R6, R8, R12 để
chiếu quan hệ trên những thuộc tính cần sử dụng và đẩy các phép chiếu
xuống càng sâu càng tốt.
Bước 3: Tổ hợp phép nhân chéo với phép chọn thành phép kết có điều kiện
Bước 4: Nhận diện các cây con mà các phép toán của nó thực hiện theo
đường không rẽ nhánh và thực thi chúng.

Để minh họa cho việc áp dụng thuật toán tối ưu hóa biểu thức đại số quan hệ nói
trên, chúng ta lần lượt xét một ví dụ liên quan đến cơ sở dữ liệu COMPANY được
sử dụng trong giáo trình này.
VÍ DỤ 9.3: Tối ưu hóa biểu thức đại số quan hệ.

Xét biểu thức đại số quan hệ sau đây :
πEname, ESalary, supervisorSSN, DName (σDnumber = DNum(EMPLOYEE × DEPARTMENT))

Hình 9.15. Cây biểu thức cần được tối ưu hóa.
Áp dụng thuật toán 9.1 để tối ưu hóa biểu thức đại số quan hệ theo trình tự sau
đây:
Bước 1: Không áp dụng, vì không có các phép chọn liên tiếp.

Bước 2:
(1) Áp dụng quy tắc (4) để giao hoán phép chọn và phép chiếu:
Hình 9.16. Áp dụng quy tắc (4) để biến đổi cây biểu thức.
(2) Áp dụng quy tắc (12) để giao hoán phép chiếu và phép nhân chéo
Hình 9.17. Áp dụng quy tắc (12) để biến đổi cây biểu thức.
Bước 3: Kết hợp phép chọn và phép nhân chéo thành phép kết có điều kiện:

Hình 9.18. Kết hợp phép chọn và phép nhân chéo.
Bước 4: Thực thi các phép toán.

9.5 TỐI ƯU HÓA BẰNG KHUNG NHÌN

Như đã trình bày ở trên, câu truy vấn thực chất là một dãy các phép toán được
thực thi liên tiếp, quan hệ kết quả của phép toán trước là đầu vào của phép toán
sau. Các quan hệ kết quả này nói chung được lưu trữ trong không gian tạm và tự
động bị xóa đi sau khi biểu thức được thực thi. Đôi khi chúng ta có nhu cầu lưu trữ
toàn bộ dữ liệu và kết quả tính toán để sử dụng lại mỗi khi có nhu cầu. Khung nhìn
(view) là một công cụ tỏ ra rất hữu dụng trong những trường hợp như thế nếu
chúng ta sử dụng khung nhìn như là một công cụ lưu trữ quan hệ kết quả của câu
truy vấn. Ví dụ sau đây cho biết cách thức tạo khung nhìn View trong SQL.
VÍ DỤ 9.4: Tối ưu hóa bằng khung nhìn.

Tạo khung nhìn V1 lưu kết quả của câu truy vấn: Liệt kê số nhân viên, tổng số giờ
làm việc của mỗi dự án:
CREATE VIEW V1 AS
SELECT PNum, COUNT(*), SUM(workHours)
FROM WORKSON
GROUP BY PNum
Rõ ràng, khi có nhu cầu truy vấn liên quan đến số liệu thống kê cho từng dự án,
khung nhìn này giúp tiết kiệm chi phí cũng như thời gian thực hiện câu truy vấn.

Hình 9.19. Cây biểu thức của khung nhìn V1.

Sau khi khung nhìn được tạo ra, chúng ta có thể thực hiện các câu truy vấn có sử
dụng khung nhìn như là một quan hệ lưu trữ khác trong CSDL. Các bảng dữ liệu
xuất hiện trong lệnh tạo khung nhìn được gọi là bảng cơ sở của khung nhìn. Trong
phạm vi giáo trình, chúng ta không đi sâu vào nghiên cứu khung nhìn và các vấn
đề liên quan, chúng ta chỉ giới hạn vào việc định nghĩa và sử dụng khung nhìn như
là một công cụ hỗ trợ tối ưu hóa câu truy vấn.
Giả sử chúng ta có khung nhìn V được định nghĩa từ phép kết nối R ⋈ S. Chúng ta
có thể sử dụng khung nhìn V này để giảm chi phí thực hiện câu truy vấn R ⋈ S ⋈
T. Cụ thể, câu truy vấn này có thể được viết lại là R ⋈ T. Ví dụ sau đây minh họa
các sử dụng khung nhìn để tối ưu hóa câu truy vấn.
VÍ DỤ 9.5: Thực hiện câu truy vấn (biểu diễn bằng cây biểu thức).
Cho biết số nhân viên tham gia từng dự án do phòng số 1 quản lý.
Cách 1: Không sử dụng khung nhìn, cây biểu thức có dạng như hình 9.19.
Hình 9.20. Cây biểu thức tương ứng khi không sử dụng khung nhìn.
Cách 2: Sử dụng khung nhìn V1, cây biểu thức có dạng như hình 9.20.

Hình 9.21. Cây biểu thức tương ứng khi không sử dụng khung nhìn.
Rõ ràng, với việc sử dụng V1, chi phí thực hiện câu truy vấn đã giảm đi đáng kể.
Ghi chú: Chúng ta còn có thể biến đổi biểu thức này bằng cách áp dụng các quy
tắc được trình bày ở mục 9.3.

9.6 TÓM TẮT

Trong các hệ quản trị cơ sở dữ liệu hiện nay, đa người dùng là một đặc trưng quan
trọng không thể bỏ qua. Theo đó, tại một thời điểm, có thể có rất nhiều câu truy
vấn được thực thi trên cơ sở dữ liệu. Vấn đề đặt ra là làm thế nào để hệ quản trị cơ
sở dữ liệu đáp ứng các yêu cầu đó một cách nhanh nhất có thể. Một trong những
giải pháp được lựa chọn đó là tối ưu hóa câu truy vấn. Trong nhiều trường hợp,
người sử dụng chủ động thực hiện công việc tối ưu hóa này trước khi cài đặt câu
truy vấn và yêu cầu hệ quản trị cơ sở dữ liệu thực thi.
Để tối ưu hóa câu truy vấn chúng ta sử dụng biểu thức đại số quan hệ tương ứng
với câu truy vấn đó. Chúng ta dựa trên kích thước không gian lưu trữ tạm thời
trong quá trình thực thi phép toán để ước lượng chi phí của biểu thức đại số quan
hệ. Bản chất của quá trình tối ưu hóa là tìm cách biến đổi biểu thức hiện có để đạt
được một biểu thức khác cho kết quả tương tự nhưng có chi phí thấp hơn. Quá
trình tối ưu được sự hỗ trợ của hàng loạt các quy tắc biến đổi tương đương dựa
trên ba phép toán cơ bản: chọn, chiếu và nhân chéo.

Tiếp theo, chúng tôi giới thiệu một quá trình bốn bước nhằm tối ưu hóa một biểu
thức đại số quan hệ. Quá trình này thực chất là trình tự áp dụng các quy tắc biến
đổi tương đương đã nêu ở trên nhằm tạo ra một biểu thức có thể không đơn giản
hơn, nhưng chi phí thấp hơn so với biểu thức ban đầu.
Cuối cùng, vì câu truy vấn là một dãy tuần tự gồm nhiều phép toán, kết quả của
phép toán trước là đầu vào của phép toán sau, chúng ta có thể lưu trữ quan hệ kết
quả đó trong các khung nhìn khác nhau và sử dụng lại chúng mỗi khi cần thiết.
Việc sử dụng khung nhìn như thế không chỉ giúp rút ngắn thời gian thực hiện truy
vấn mà còn góp phần vào việc tối ưu hóa câu truy vấn.

CƠ SỞ DỮ LIỆU

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CƠ SỞ DỮ LIỆU

Uploaded by

Copyright:

Available Formats

TRƯỜNG ĐẠ

ẠI HỌC NGÂN HÀNG TP. HỒ CHÍ MINH

KHOA CÔNG NGH

NHÓM BIÊN SOẠN:

Tạ Thị Hoàng Mai

TP. Hồ Chí Minh, tháng 07 năm 2011

Hình 1.1. Mô hình hoạt động hệ thống hướng tệp tin.

1.2 HỆ THỐNG HƯỚNG CƠ SỞ DỮ LIỆU

1.4 HỆ QUẢN TRỊ CƠ SỞ DỮ LIỆU

Hình 1.2. Mô hình hoạt động của hệ thống hướng cơ sở dữ liệu.

a) Dựa trên mô hình dữ liệu

1.4.3 Các chức năng của một hệ quản trị cơ sở dữ liệu

1.5 NGƯỜI DÙNG CƠ SỞ DỮ LIỆU

1.5.2 Nhóm thiết kế cơ sở dữ liệu

1.5.5 Nhân viên bảo trì hệ thống

1.6 NGÔN NGỮ VÀ GIAO DIỆN NGÔN NGỮ DỮ

1.6.1 Ngôn ngữ định nghĩa dữ liệu

1.6.2 Ngôn ngữ thao tác dữ liệu

1.6.3 Ngôn ngữ điều khiển dữ liệu

1.7 TÓM TẮT

Các thành phần của mô hình thực thể kết hợp.

2.3 CÁC KHÁI NIỆM

VÍ DỤ 2.1: Miền giá trị của thuộc tính.

VÍ DỤ 2.2: Giá trị của thực thể.

VÍ DỤ 2.3: Thuộc tính đơn và thuộc tính tổ hợp.

VÍ DỤ 2.4: Thuộc tính đơn trị và thuộc tính đa trị

VÍ DỤ 2.5: Thuộc tính lưu trữ và thuộc tính dẫn xuất.

VÍ DỤ 2.6: Giá trị NULL.

VÍ DỤ 2.7: Tập thực thể trong cơ sở dữ liệu COMPANY.

2.3.1.6 Thuộc tính khóa

VÍ DỤ 2.8: Thuộc tính khóa của tập thực thể.

VÍ DỤ 2.12: Biểu diễn liên kết một – một.

VÍ DỤ 2.13: Biểu diễn liên kết một – nhiều.

VÍ DỤ 2.14: Biểu diễn liên kết nhiều – nhiều.

VÍ DỤ 2.15: Vai trò của thực thể trong liên kết.

VÍ DỤ 2.16: Thuộc tính của liên kết.

2.4 CÁC VẤN ĐỀ KHI THIẾT KẾ MÔ HÌNH THỰC

KÝ HIỆU Ý NGHĨA VÍ DỤ MINH HỌA

Tập thực thể

Tập thực thể yếu

Kiểu liên kết

Kiểu liên kết hỗ trợ

Thuộc tính khóa

Thuộc tính đa trị

Thuộc tính tổ hợp

Thuộc tính dẫn xuất

2.5 TÓM TẮT

Ngôn ngữ mô hình hóa hợp nhất.

3.2 CÁC KHÁI NIỆM TRONG MÔ HÌNH THỰC

3.2.3 Khái quát hóa

VÍ DỤ 3.6: Chuyên biệt hóa theo thuộc tính.

VÍ DỤ 3.7: Ràng buộc toàn phần và ràng buộc từng phần.

3.2.5 Cây phân cấp và lưới phân cấp

VÍ DỤ 3.8: Cây phân cấp và lưới phân cấp.

4.1.1 Các khái niệm

Lược đồ quan hệ R, thường được ký hiệu là R(A1,A2,…,An), trong đó R là tên quan

VÍ DỤ 4.1: Lược đồ quan hệ EMPLOYEE.

VÍ DỤ 4.2: Miền giá trị của thuộc tính.

4.1.1.4 Thể hiện quan hệ

VÍ DỤ 4.3: Thể hiện của quan hệ EMPLOYEE.

Hình 4.1. Một thể hiện của quan hệ EMPLOYEE

4.1.1.5 Lược đồ cơ sở dữ liệu quan hệ

4.1.1.6 Cơ sở dữ liệu mẫu

WORKSON EMPLOYEE DEPARTMENT