Tải bản đầy đủ (.pdf) (19 trang)

Tổng quan về thiết kế cơ sở dữ liệu

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (840.27 KB, 19 trang )

HỌC VIỆN CƠNG NGHỆ BƯU CHÍNH VIỄN THƠNG
KHOA VIỄN THƠNG 1

BÀI TẬP LỚN
CƠ SỞ DỮ LIỆU
Giảng viên:
Nhóm:
Thành viên:

TS. Vũ Thị Thúy Hà
03
Phạm Thùy Trang – B19DCVT406
Đào Ngọc Thủy – B19DCVT400
Vũ Thị Hương Vi – B19DCVT428
Trần Ngọc Minh – B19DCVT259

Hà Nội - 2022


MỤC LỤC
LỜI MỞ ĐẦU ....................................................................................................... 2
2.1 Tổng quan về thiết kế cơ sở dữ liệu ............................................................ 3
2.1.1 Giới hạn mô hình.................................................................................. 3
2.2: Các thực thể, thuộc tính và tập thực thể ..................................................... 5
2.3 Mối quan hệ và tập quan hệ ........................................................................ 6
2.4 Các tính năng bổ sung của chế độ ER ......................................................... 9
2.4.1 Các khóa ràng buộc .............................................................................. 9
2.4.2 Các ràng buộc khi tham gia................................................................ 11
2.4.3 Thực thể yếu ....................................................................................... 12
2.4.4 Cấu trúc phân cấp lớp......................................................................... 14
2.4.5 Tổng hợp ............................................................................................ 16


LỜI CẢM ƠN ..................................................................................................... 18

1


LỜI MỞ ĐẦU
Mơ hình dữ liệu mối quan hệ thực thể (ER) cho phép chúng ta mô tả dữ liệu liên quan
đến một doanh nghiệp trong thế giới thực dưới dạng các đối tượng và mối quan hệ của
chúng và được sử dụng rộng rãi để phát triển thiết kế cơ sở dữ liệu ban đầu. Trong
chương này, chúng tôi giới thiệu mơ hình ER và thảo luận về cách các tính năng của nó
cho phép ta mơ hình hóa nhiều loại dữ liệu một cách trung thực.
Mơ hình ER quan trọng chủ yếu đối với vai trị của nó trong thiết kế cơ sở dữ liệu. Nó
cung cấp các khái niệm hữu ích cho phép ta chuyển từ mơ tả khơng chính thức về những
gì người dùng muốn từ cơ sở dữ liệu của họ sang mô tả chi tiết và chính xác hơn, có thể
được triển khai trong DBMS. Chúng tôi bắt đầu với tổng quan về thiết kế cơ sở dữ liệu
trong Phần 2.1 để thức đẩy cuộc thảo luận của ta về mơ hình ER. Trong bối cảnh lớn
hơn của quá trình thiết kế tổng thể, mơ hình ER được sử dụng trong một giai đoạn được
gọi là thiết kế cơ sở dữ liệu khái niệm. Sau đó, chúng tơi giới thiệu mơ hình ER trong
các Phần 2.2, 2.3 và 2.4.
Chúng tôi lưu ý rằng nhiều biến thể của sơ đồ ER đang được sử dụng và khơng có tiêu
chuẩn nào được chấp nhận rộng rãi. Phần trình bày trong chương này là đại diện cho ta
các mơ hình ER và bao gồm một loạt các tính năng phổ biến nhất.

2


2.1 Tổng quan về thiết kế cơ sở dữ liệu
Quá trình thiết kế cơ sở dữ liệu có thể được chia thành sáu bước. Mơ hình ER phù hợp
nhất với ba bước đầu tiên:
1. Phân tích nhu cầu: Bước đầu tiên trong việc thiết kế một ứng dụng cơ sở dữ liệu

là hiểu dữ liệu nào sẽ được lưu trữ trong cơ sở dữ liệu, những ứng dụng nào phải
được xây dựng trên đó và những hoạt động nào thường xuyên nhất và tùy thuộc
vào các yêu cầu về hiệu suất. Nói cách khác, chúng ta phải tìm ra những gì người
dùng muốn từ cơ sở dữ liệu.
Cơng cụ thiết kế cơ sở dữ liệu: Các công cụ thiết kế có sẵn từ các nhà cung cấp
RDBMS cũng như các nhà cung cấp bên thứ ba. Đặc biệt, Sybase và Oracle có
các bộ cơng cụ thiết kế và phân tích toàn diện. Xem URL sau để biết chi tiết về
các công cụ của Sybase: .
Phần tiếp theo cung cấp thông tin chi tiết về các công cụ của Oracle:
/>Đây thường là một q trình thơng thường bao gồm các cuộc thảo luận với các
nhóm người dùng, nghiên cứu về mơi trường hoạt động hiện tại và cách nó dự
kiến sẽ thay đổi, phân tích bất kỳ tài liệu có sẵn nào về các ứng dụng hiện có mà
cơ sở dữ liệu dự kiến sẽ được thay thế hoặc bổ sung, v.v. Một số phương pháp
luận đã được đưa ra để tổ chức và trình bày thơng tin thu thập được trong bước
này và một số công cụ tự động đã được phát triển để hỗ trợ quá trình này.
2. Thiết kế cơ sở dữ liệu khái niệm: Thông tin thu thập được trong bước phân tích
nhu cầu được sử dụng để phát triển mô tả cấp cao về dữ liệu được lưu trữ trong
cơ sở dữ liệu, cùng với các ràng buộc được biết để giữ dữ liệu này. Bước này
thường được thực hiện bằng cách sử dụng mô hình ER, hoặc một mơ hình dữ liệu
mức cao tương tự và được thảo luận trong phần còn lại của chương này.
3. Thiết kế cơ sở dữ liệu logic: Chúng ta phải chọn một DBMS để thực hiện thiết
kế cơ sở dữ liệu của mình và chuyển thiết kế cơ sở dữ liệu khái niệm thành một
lược đồ cơ sở dữ liệu trong mơ hình dữ liệu của DBMS đã chọn. Chúng ta sẽ chỉ
xem xét các quan hệ DBMS và do đó, nhiệm vụ trong bước thiết kế logic là
chuyển đổi một lược đồ ER thành một lược đồ cơ sở dữ liệu quan hệ. Chúng ta
thảo luận chi tiết về bước này trong Chương 3; kết quả là một lược đồ khái niệm,
đôi khi được gọi là lược đồ logic, trong mơ hình dữ liệu quan hệ.
2.1.1 Giới hạn mơ hình
Mơ hình ER đơi khi được coi là một cách tiếp cận hoàn chỉnh để thiết kế một lược đồ
cơ sở dữ liệu logic. Điều này khơng chính xác vì biểu đồ ER chỉ là một mơ tả gần đúng

của dữ liệu, được xây dựng thông qua đánh giá rất chủ quan về thông tin thu thập được
trong q trình phân tích nhu cầu. Một phân tích cẩn thận hơn thường có thể tinh chỉnh

3


lược đồ logic thu được ở cuối Bước 3. Khi chúng ta có một lược đồ logic tốt, chúng ta
phải xem xét các tiêu chí hiệu suất và thiết kế lược đồ vật lý. Cuối cùng, chúng tôi phải
giải quyết các vấn đề bảo mật và đảm bảo rằng người dùng có thể truy cập vào dữ liệu
họ cần, nhưng không phải dữ liệu mà chúng ta muốn giấu họ. Ba bước còn lại của thiết
kế cơ sở dữ liệu được mô tả ngắn gọn dưới đây:
4. Tinh chỉnh lược đồ: Bước thứ tư trong thiết kế cơ sở dữ liệu là phân tích tập hợp
các mối quan hệ trong lược đồ cơ sở dữ liệu quan hệ của chúng ta để xác định
các vấn đề tiềm ẩn và tinh chỉnh nó. Trái ngược với các bước phân tích u cầu
và thiết kế khái niệm, về cơ bản là chủ quan, việc tinh chỉnh giản đồ có thể được
hướng dẫn bởi một số lý thuyết dễ hiểu và vững chắc. Chúng ta thảo luận về lý
thuyết bình thường hóa các mối quan hệ - tái cấu trúc chung để đảm bảo một số
thuộc tính mong muốn - trong Chương 15.
5. Thiết kế cơ sở dữ liệu vật lý: Trong bước này, chúng ta phải xem xét khối lượng
công việc dự kiến điển hình mà cơ sở dữ liệu của chúng ta phải hỗ trợ và tinh
chỉnh thêm thiết kế cơ sở dữ liệu để đảm bảo rằng nó đáp ứng các tiêu chí hiệu
suất mong muốn. Bước này có thể chỉ liên quan đến việc xây dựng các chỉ mục
trên một số bảng và phân cụm một số bảng hoặc nó có thể liên quan đến việc thiết
kế lại đáng kể các phần của lược đồ cơ sở dữ liệu thu được từ các bước thiết kế
trước đó. Chúng ta thảo luận về thiết kế vật lý và điều chỉnh cơ sở dữ liệu trong
Chương 16.
6. Thiết kế bảo mật: Trong bước này, chúng ta xác định các nhóm người dùng khác
nhau và các vai trò khác nhau của nhiều người dùng khác nhau (ví dụ: nhóm phát
triển cho một sản phẩm, đại diện hỗ trợ khách hàng, giám đốc sản phẩm). Đối
với mỗi vai trị và nhóm người dùng, chúng ta phải xác định các phần của cơ sở

dữ liệu mà họ có thể truy cập và các phần của cơ sở dữ liệu mà họ không được
phép truy cập, đồng thời thực hiện các bước để đảm bảo rằng họ chỉ có thể truy
cập vào các phần cần thiết. DBMS cung cấp một số cơ chế để hỗ trợ trong bước
này và chúng ta sẽ thảo luận về vấn đề này trong Chương 17.
Nói chung, việc phân chia quy trình thiết kế thành các bước của chúng ta nên được coi
là sự phân loại các loại bước liên quan đến thiết kế. Thực tế, mặc dù chúng ta có thể bắt
đầu với quy trình sáu bước được nêu ở đây, nhưng một thiết kế cơ sở dữ liệu hồn chỉnh
có thể sẽ u cầu một giai đoạn điều chỉnh tiếp theo, trong đó tất cả sáu loại bước thiết
kế được xen kẽ và lặp lại cho đến khi thiết kế đạt yêu cầu. Hơn nữa, chúng tôi đã bỏ qua
các bước quan trọng của việc thực hiện thiết kế cơ sở dữ liệu và thiết kế và triển khai
các lớp ứng dụng chạy trên DBMS. Tất nhiên, trong thực tế, các bước bổ sung này có
thể dẫn đến việc suy nghĩ lại về thiết kế cơ sở dữ liệu cơ bản.
Các khái niệm và kỹ thuật làm nền tảng cho một DBMS quan hệ rõ ràng là hữu ích cho
những người muốn triển khai hoặc duy trì phần bên trong của một hệ thống cơ sở dữ

4


liệu. Tuy nhiên, điều quan trọng là phải nhận ra rằng những người dùng nghiêm túc và
DBA cũng phải biết cách hoạt động của DBMS. Sự hiểu biết tốt về nội bộ của hệ thống
cơ sở dữ liệu là điều cần thiết đối với người dùng muốn tận dụng đầy đủ lợi thế của
DBMS và thiết kế một cơ sở dữ liệu tốt; điều này đặc biệt đúng với thiết kế vật lý và
điều chỉnh cơ sở dữ liệu.

2.2: Các thực thể, thuộc tính và tập thực thể
Thực thể là một đối tượng trong thế giới thực có thể phân biệt được với các đối tượng
khác, ví dụ như sau: đồ chơi Green Dragonzord, bộ phận đồ chơi, người quản lý bộ phận
đồ chơi, địa chỉ nhà của người quản lý bộ phận đồ chơi. Nó thường hữu ích để xác định
một tập hợp các thực thể tương tự. Một tập hợp như vậy được gọi là một tập thực thể.
Lưu ý rằng các tập thực thể không cần phải rời rạc; tập hợp nhân viên bộ phận đồ chơi

và tập thể nhân viên bộ phận thiết bị đều có thể chứa nhân viên John Doe (người làm
việc ở cả hai bộ phận). Chúng ta cũng có thể xác định một tập thực thể được gọi là nhân
viên chứa cả nhóm nhân viên của bộ phận đồ chơi và thiết bị.
Một thực thể được mô tả bằng cách sử dụng một tập hợp các thuộc tính. Tất cả các thực
thể trong một tập thực thể nhất định có các thuộc tính giống nhau. Lựa chọn các thuộc
tính phản ánh mức độ chi tiết đại diện cho thông tin về các thực thể. Ví dụ: tập thực thể
nhân viên có thể sử dụng tên, số an sinh xã hội (ssn) và bãi đậu xe (lot) làm thuộc tính.
Trong trường hợp này, chúng ta sẽ lưu trữ tên, số an sinh xã hội và số bãi đỗ xe cho mỗi
nhân viên. Tuy nhiên, chúng ta sẽ không lưu trữ, chẳng hạn như địa chỉ của người lao
động (hoặc giới tính hoặc tuổi tác).
Đối với mỗi thuộc tính được liên kết với một tập thực thể, chúng ta phải xác định một
miền các giá trị có thể có. Ví dụ: miền được liên kết với tên thuộc tính của Nhân viên
có thể là tập hợp các chuỗi 20 ký tự. Một ví dụ khác, nếu công ty xếp hạng nhân viên
theo thang điểm từ 1 đến 10 và lưu trữ xếp hạng trong một trường được gọi là xếp hạng,
miền bao gồm các số nguyên từ 1 đến 10. Hơn nữa, đối với mỗi tập thực thể, chúng ta
chọn một khóa. Khóa là một tập hợp tối thiểu các thuộc tính có giá trị nhận dạng duy
nhất một thực thể trong tập hợp. Có thể có nhiều hơn một khóa ứng viên, chúng ta chỉ
định một trong số khóa là khóa chính. Bây giờ, chúng ta sẽ giả định rằng mỗi tập thực
thể chứa ít nhất một tập hợp các thuộc tính xác định duy nhất một thực thể trong tập
thực thể; nghĩa là, tập hợp các thuộc tính chứa một khóa. Chúng ta sẽ xem xét lại điểm
này trong Phần 2.4.3.
Tập thực thể nhân viên với các thuộc tính ssn, name và lot được thể hiện trong Hình 1.
Tập hợp thực thể được biểu thị bằng hình chữ nhật và thuộc tính được biểu thị bằng hình
bầu dục. Mỗi thuộc tính trong khóa chính đều được gạch chân. Thơng tin miền có thể
được liệt kê cùng với tên thuộc tính, nhưng ta bỏ qua điều này để giữ cho các số liệu
gọn gàng. Chìa khóa là ssn.

5



Hình 1: Tập thực thể nhân viên

2.3 Mối quan hệ và tập quan hệ
Mối quan hệ là sự liên kết giữa hai hoặc nhiều thực thể. Ví dụ, chúng ta có thể có mối
quan hệ là Atishoo làm việc trong khoa dược. Giống như các thực thể, chúng ta có thể
muốn thu thập một tập hợp các mối quan hệ tương tự thành một tập quan hệ.
(Để tránh nhầm lẫn, chúng tơi sẽ giả định rằng tên thuộc tính khơng lặp lại trên các tập
thực thể. Đây không phải là một hạn chế thực sự vì chúng ta ln có thể sử dụng tên tập
hợp thực thể để giải quyết những điều không rõ ràng nếu giống nhau tên thuộc tính được
sử dụng trong nhiều tập thực thể.)

Hình 2.1 Tập thực thể Nhân viên
Một tập quan hệ có thể được coi là một tập hợp n-bộ:
e1,…,en|e1E1,…,enEn
Mỗi n-bộ biểu thị một mối quan hệ liên quan đến n thực thể từ e1 đến en, trong đó thực
thể ei nằm trong tập thực thể Ei. Trong Hình 2.2, chúng ta chỉ ra tập quan hệ Làm_việc,

6


trong đó mỗi mối quan hệ chỉ ra một bộ phận mà nhân viên làm việc. Lưu ý rằng một số
tập quan hệ có thể liên quan đến các tập thực thể giống nhau. Ví dụ, chúng ta có một tập
quan hệ Quản Lí liên quan đến Nhân Viên và Phịng Ban.

Hình 2.2 Tập quan hệ Làm_việc
Một mối quan hệ cũng có thể có các thuộc tính mơ tả. Các thuộc tính mơ tả được sử
dụng để ghi lại thơng tin về mối quan hệ, chứ không phải về bất kỳ một thực thể tham
gia nào; ví dụ, chúng ta có thể muốn ghi lại rằng Atishoo làm việc trong khoa dược kể
từ tháng 1 năm 1991. Thông tin này được ghi lại trong Hình 2.2 bằng cách thêm một
thuộc tính, kể_từ_khi, vào Làm Việc. Một mối quan hệ phải được xác định duy nhất bởi

các thực thể tham gia, khơng tham chiếu đến các thuộc tính mơ tả. Ví dụ, trong tập quan
hệ Làm Việc, mỗi mối quan hệ Làm việc phải được xác định duy nhất bằng sự kết hợp
của Nhân viên ssn và Phịng bandid. Do đó, đối với một cặp nhân viên-bộ phận nhất
định, chúng ta khơng thể có nhiều hơn một giá trị kể từ được liên kết.
Sự thể hiện của tập quan hệ là một tập hợp các mối quan hệ. Một cách trực quan, một
sự thể hiện có thể được coi như là "ảnh chụp nhanh" mối quan hệ tại một thời điểm nào
đó. Một thể hiện của tập hợp quan hệ Làm Việc được thể hiện trong Hình 2.3. Mỗi thực
thể Nhân viên được ký hiệu bằng ssn, và mỗi thực thể Phịng ban được ký hiệu bằng
did.

Mơ hình Mối quan hệ-Thực thể
Giá trị kể_từ_khi được hiển thị bên cạnh mỗi mối quan hệ. (Các nhận xét ‘nhiều - nhiều’
và ‘tổng số tham gia’ trong hình sẽ được thảo luận sau, khi chúng ta thảo luận về các
ràng buộc toàn vẹn.)

7


Hình 2.3 Một ví dụ về các hoạt động trong mối quan hệ
Một ví dụ khác về sơ đồ ER, giả sử rằng mỗi bộ phận có văn phịng ở một số địa điểm
và chúng ta muốn ghi lại các vị trí mà mỗi nhân viên làm việc. Mối quan hệ này là bậc
ba vì chúng ta phải ghi lại mối liên kết giữa một nhân viên, một bộ phận và một vị trí.
Biểu đồ ER cho biến thể này của Làm Việc, mà chúng tôi gọi là Làm Việc 2, được thể
hiện trong Hình 2.4.

Hình 2.4 Tập hợp mối quan hệ bậc ba
Các tập thực thể tham gia vào một tập quan hệ không cần phải khác biệt; đôi khi một
mối quan hệ có thể liên quan đến hai thực thể trong cùng một tập thực thể. Ví dụ, hãy
xem xét tập quan hệ Báo Cáo được trình bày trong Hình 2.5. Vì nhân viên báo cáo cho
các nhân viên khác nên mọi mối quan hệ trong Báo Cáo đều có dạng (emp1, emp2),

trong đó cả emp1 và emp2 đều là các thực thể trong Nhân viên. Tuy nhiên, chúng đóng
các vai trị khác nhau: emp1 báo cáo cho nhân viên quản lý emp2, được phản ánh trong
các chỉ số vai trò người giám sát và cấp dưới trong Hình 2.5. Nếu một tập thực thể đóng
nhiều hơn một vai trò, chỉ báo vai trò được nối với một tên thuộc tính từ tập thực thể sẽ
cung cấp cho chúng ta một tên duy nhất cho mỗi thuộc tính trong tập hợp quan hệ. Ví

8


dụ: tập hợp quan hệ Báo Cáo có các thuộc tính tương ứng với ssn của người giám sát và
ssn của cấp dưới, và tên của các thuộc tính này là Người giám sát ssn và Cấp dưới ssn.

Hình 2.5 Tập quan hệ Báo Cáo

2.4 Các tính năng bổ sung của chế độ ER
Bây giờ chúng ta xem xét một số cấu trúc trong mơ hình ER cho phép chúng ta mơ tả
một số thuộc tính tinh tế của dữ liệu. Biểu hiện của mơ hình ER là một lý do lớn cho
việc sử dụng rộng rãi của nó.
2.4.1 Các khóa ràng buộc
Xem xét mối quan hệ “Việc Làm” được thể hiện trong hình 2.2. Một nhân viên có thể
làm việc trong nhiều phịng ban, và một phịng ban có thể có nhiều nhân viên, như được
minh họa trong ví dụ “Việc Làm” trong hình 2.3. Nhân viên 231-31-5368 đã làm việc
trong Cục 51 từ ngày 3/3/93 và Cục 56 từ ngày 2/2/92. Cục 51 có hai nhân viên.
Bây giờ hãy xem xét mối quan hệ khác được thiết lập gọi là “Người quản lý giữa Nhân
viên và Phòng Ban” tổ chức thực thế sao cho mỗi phịng ban có nhiều nhất một người
quản lý, mặc dù một nhân viên được phép quản lý nhiều hơn một bộ phận. Hạn chế mà
mỗi phịng ban có nhiều nhất một người quản lý là một ví dụ về khóa ràng buộc, và nó
ngụ ý rằng mỗi thực thể Phịng ban xuất hiện trong nhiều nhất một mối quan hệ Người
quản lý trong bất kỳ trường hợp Người quản lý nào được phép. Hạn chế này được chỉ ra
trong sơ đồ ER của Hình 2.6 bằng cách sử dụng một mũi tên từ Bộ phận đến Người quản

lý. Một cách trực quan, mũi tên cho biết rằng đối với một thực thể Phòng ban, chúng ta
có thể xác định duy nhất mối quan hệ Người quản lý mà nó xuất hiện.

9


Hình 2.6 Khóa ràng buộc đối với người quản lý
Một ví dụ về tập quan hệ “Người quản lý” được thể hiện trong hình 2.7. Trong khí đó
đây cũng là một ví dụ tiềm năng cho tập quan hệ “Việc Làm”, ví dụ “Việc Làm” ở hình
2.3 vi phạm ràng buộc chính đối với tập “Người quản lý”.

Hình 2.7 Một ví dụ về Tập quan hệ người quản lý
Một tập quan hệ như “Người quản lý” đôi khi được cho là một đến nhiều (one-tomany), để chỉ ra rằng một nhân viên có thể được liên kết với nhiều phịng ban (với tư
cách là người quản lý), trong khi mỗi phịng ban có thể được liên kết với nhiều nhất một
nhân viên với tư cách là người quản lý của nó. . Ngược lại, tập quan hệ “Việc Làm”,
trong đó một nhân viên được phép làm việc trong một số phịng ban và một phịng ban
được phép có một số nhân viên, được cho là nhiều-đến-nhiều (many-to-many).
Nếu chúng ta thêm hạn chế rằng mỗi nhân viên có thể quản lý nhiều nhất một bộ phận
vào tập quan hệ “Người quản lý”, điều này được chỉ ra bằng cách thêm một mũi tên từ
“Nhân viên” đến “Người quản lý” trong Hình 2.6, chúng ta có một tập quan hệ một dến
một (one-to-one).

10


Khóa ràng buộc đối với quan hệ bậc ba
Chúng ta có thể mở rộng quy ước này - và khái niệm khóa ràng buộc cơ bản - thành các
tập quan hệ liên quan đến ba hoặc nhiều tập thực thể: Nếu một tập thực thể E có khóa
ràng buộc trong tập quan hệ R, thì mỗi thực thể trong một biểu hiện của E sẽ xuất hiện
trong nhiều nhất một mối quan hệ trong (một thể hiện tương ứng của) R. Để chỉ ra một

khóa ràng buộc đối với tập thực thể E trong tập quan hệ R, chúng ta vẽ một mũi tên từ
E đến R.
Trong hình 2.8, chúng tôi chỉ ra một mối quan hệ bậc ba với các ràng buộc chính. Mỗi
nhân viên làm việc ở nhiều nhất một phòng ban và tại một địa điểm. Một ví dụ của tập
quan hệ “Việc Làm 3”được thể hiện trong Hình 2.9. Lưu ý rằng mỗi phịng ban có thể
được liên kết với một số nhân viên và vị trí, và mỗi vị trí có thể được liên kết với một
số phòng ban và nhân viên; tuy nhiên, mỗi nhân viên được liên kết với một phòng ban
và vị trí đơn lẻ.

Hình 2.8 Một tập quan hệ bậc ba với các khóa ràng buộc

2.4.2 Các ràng buộc khi tham gia
Khóa ràng buộc đối với “Người quản lý” cho chúng ta biết rằng một phịng ban có nhiều
nhất một người quản lý. Một câu hỏi tự nhiên cần đặt ra là liệu mọi phịng ban đều có
một người quản lý. Hãy để chúng tơi nói rằng mọi phịng ban bắt buộc phải có một người
quản lý. Yêu cầu này là một ví dụ về một ràng buộc khi tham gia; sự tham gia của tổ
chức thực thể các Phòng ban trong tập quan hệ “Người quản lý” được cho là tồn bộ.
Một sự tham gia khơng phải là tổng số được cho là được một phần. Ví dụ, sự tham gia
của thực thể tập “Nhân viên” trong “Người quản lý” là một phần, vì khơng phải mọi
nhân viên đều có thể quản lý một bộ phận.

11


Hình 2.9 Một ví dụ về Việc Làm 3
Xem xét lại tập quan hệ “Việc Làm 3”, điều tự nhiên để nghĩ rằng là mỗi nhân viên làm
việc trong ít nhất một phịng ban và mỗi phịng ban có ít nhất một nhân viên. Điều này
có nghĩa là sự tham gia của cả “Nhân Viên” và “Phòng Ban” trong “Việc Làm” là tồn
bộ. Biểu đồ ER trong Hình 2.10 cho thấy cả “Người quản lý” và “Việc làm” trong các
tập quan hệ và tất cả các ràng buộc đã cho. Nếu sự tham gia của một tập thực thể trong

một tập mối quan hệ là tổng thể, cả hai được nối với nhau bằng một đường dày; độc lập,
sự hiện diện của một mũi tên chỉ ra một hạn chế chính. Các trường hợp của “Việc Làm”
và “Người Quản Lý” thể hiện trong Hình 2.3 và 2.7 thỏa mãn tất cả các ràng buộc trong
Hình 2.10.

2.4.3 Thực thể yếu
Cho đến nay, chúng tơi đã giả định rằng các thuộc tính được liên kết với một tập thực
thể bao gồm một chìa khóa. Giả định này khơng phải lúc nào cũng đúng. Ví dụ, giả sử
rằng nhân viên có thể mua các chính sách bảo hiểm để trang trải cho những người phụ
thuộc họ. Chúng tôi muốn ghi lại thông tin về các chính sách, bao gồm cả đối tượng
được điều chỉnh bởi từng chính sách, những thơng tin này thực sự là mối quan tâm duy
nhất của chúng tôi đối với những người phụ thuộc của một nhân viên. Nếu một nhân
viên nghỉ việc, bất kỳ chính sách nào thuộc sở hữu của nhân viên bị chấm dứt và chúng
tôi muốn xóa tất cả các chính sách liên quan và thông tin người phụ thuộc từ cơ sở dữ
liệu.

12


Chúng tơi có thể chọn chỉ xác định một người phụ thuộc bằng tên trong tình huống này,
vì điều hợp lý là những người phụ thuộc của một nhân viên nhất định có các tên khác
nhau. Như vậy các thuộc tính của tập thực thể “Người Phụ Thuộc” có thể là pname và
tuổi. Thuộc tính name khơng xác định duy nhất một người phụ thuộc. Hãy nhớ lại rằng
chìa khóa cho “Nhân Viên” là ssn; do chúng ta có thể có hai nhân viên được gọi là
Smethurst, và mỗi người có thể có một con trai tên là Joe.

Hình 2.10 Người Quản Lý và Việc Làm
Người phụ thuộc là một ví dụ về một tập thực thể yếu. Một thực thể yếu có thể được xác
định duy nhất chỉ bằng cách xem xét một số thuộc tính của nó cùng với khóa chính của
một thực thể khác, được gọi là chủ sở hữu định danh.

Các hạn chế sau phải có:
▪ Tập thực thể chủ sở hữu và tập thực thể yếu phải tham gia vào tập quan hệ mộtđến-nhiều (một thực thể chủ sở hữu được liên kết với một hoặc nhiều thực thể
yếu, nhưng mỗi thực thể yếu có một chủ sở hữu duy nhất). Tập hợp mối quan hệ
này được gọi là tập quan hệ xác định của tập thực thể yếu.
▪ Tập thực thể yếu phải tham gia tồn bộ vào tập quan hệ xác định.
Ví dụ, một thực thể “Người phụ thuộc” chỉ có thể được xác định duy nhất nếu chúng ta
lấy khóa của chủ sở hữu thực thể “Nhân viên” và pname của thực thể “Người phụ thuộc”.
Bộ thuộc tính của một tập thực thể yếu xác định duy nhất một thực thể yếu cho một chủ
sở hữu thực thể nhất định được gọi là khóa một phần của tập thực thể yếu. Trong ví dụ
của chúng ta, pname là khóa một phần cho “Người phụ thuộc”.

13


Tập thực thể yếu “Người phụ thuộc” và quan hệ của nó với “Nhân viên” được thể hiện
trong Hình 2.11. Tổng số sự tham gia của “Người phụ thuộc” vào “Chính sách” được
thể hiện bằng cách liên kết chúng với đường kẻ tối. Mũi tên từ “Người phụ thuộc” đến
“Chính sách” chỉ ra rằng mỗi thực thể “Người phụ thuộc” xuất hiện trong nhiều nhất là
một (thực sự, chính xác là một, vì ràng buộc tham gia) với quan hệ “Chính sách”. Để
nhấn mạnh thực tế rằng “Người phụ thuộc” là một thực thể yếu và “Chính sách” là quan
hệ xác định của nó, chúng ta vẽ cả hai bằng những đường kẻ tối. Để chỉ ra pname đó là
một khóa một phần cho “Người phụ thuộc”, chúng tơi gạch dưới nó bằng cách sử dụng
một đường nét đứt. Đây có nghĩa là có thể có hai phụ thuộc có cùng giá trị pname.

Hình 2.11 Tập thực thể yếu

2.4.4 Cấu trúc phân cấp lớp
Đôi khi việc phân loại các thực thể trong một tập thực thể thành các lớp con là điều tự
nhiên. Ví dụ, chúng ta có thể muốn nói về một tập thực thể “Giờ Làm_Nhân_Viên” và
“Hợp Đồng Nhân Viên” tập thực thể để phân biệt cơ sở mà họ được thanh tốn. Chúng

ta có thể có các thuộc tính giờ làm việc và lương theo giờ được xác định cho “Giờ Làm
Nhân Viên” và một thuộc tính id hợp đồng được định nghĩa cho “Hợp Đồng Nhân Viên”.
Chúng tôi muốn ngữ nghĩa rằng mọi thực thể trong một trong những tập này cũng là
một thực thể “Nhân viên”, và như vậy phải có tất cả các thuộc tính của “Nhân viên”
được xác định. Do đó, các thuộc tính được xác định cho một thực thể “Giờ Làm Nhân
Viên” là các thuộc tính dành cho “Nhân viên” cộng với “Giờ Làm Nhân Viên”. Chúng
ta nói rằng các thuộc tính cho tập thực thể “Nhân viên” được kế thừa bởi tập thực thể
“Giờ Làm Nhân Viên” và ISA “Giờ Làm Nhân Viên” đó (đọc là 1) “Nhân viên”. Ngồi
ra - và ngược lại với phân cấp lớp trong các ngơn ngữ lập trình như C ++ - có một ràng
buộc đối với các truy vấn đối với các phiên bản của các tập thực thể này: Một truy vấn
yêu cầu tất cả thực thể “Nhân viên” cũng phải xem xét tất cả các thực thể “Giờ Làm
Nhân Viên” và “Hợp Đồng Nhân Viên”. Hình 2.12 minh họa phân cấp lớp.
Tập thực thể “Nhân viên” cũng có thể được phân loại theo một tiêu chí khác. Ví dụ,
chúng tơi có thể xác định một nhóm nhỏ các nhân viên là “Nhân Viên Cấp Cao”. Chúng
ta có thể sửa đổi Hình 2.12 để phản ánh sự thay đổi này bằng cách thêm một nút ISA
thứ hai làm nút con của “Nhân viên” và tạo “Nhân Viên Cấp Cao” là một phần tử con

14


của nút này. Mỗi tập thực thể này có thể được phân loại thêm, tạo hệ thống phân cấp
ISA đa cấp.
Hệ thống phân cấp lớp có thể được xem theo một trong hai cách:

Hình 2.12 Cấu trúc phân cấp lớp






“Nhân viên” được chuyển hóa thành các lớp con. Chuyên hóa là quá trình xác
định các tập con của một tập thực thể (lớp cha) có chung một số phân biệt đặc
điểm. Thông thường, lớp cha được định nghĩa trước, các lớp con được định nghĩa
tiếp theo, sau đó các thuộc tính và tập hợp quan hệ dành riêng cho lớp con sẽ
được thêm vào.
“Giờ Làm Nhân Viên” và “Hợp Đồng Nhân Viên” được nhân viên khái quát.
Như một ví dụ khác, hai tập thực thể “Thuyền máy” và “Ơ tơ” có thể được khái
quát thành một thực thể “Phương_ Tiện_Cơ_Giới”. Khái quát bao gồm việc xác
định một số đặc điểm chung của một tập các tập thực thể và tạo một tập thực thể
mới có chứa các thực thể sở hữu những đặc điểm chung này. Thông thường, các
lớp con được xác định trước, lớp cha được xác định tiếp theo và bất kỳ tập hợp
quan hệ nào liên quan đến lớp cha sau đó được định nghĩa.

Chúng ta có thể chỉ định hai loại ràng buộc liên quan đến phân cấp ISA, đó là chồng
chéo và bao gồm các ràng buộc. Các ràng buộc chồng chéo xác định xem hai lớp con
có được phép chứa cùng một thực thể. Ví dụ, Atishoo có thể vừa là thực thể
“Giờ_Làm_Nhân_Viên” và thực thể “Hợp_Đồng_Nhân_Viên” khơng? Theo trực giác,
khơng. Anh ta có thể vừa là một thực thể “Hợp_Đồng_Nhân_Viên” và thực thể
“Nhân_Viên_Cấp_Cao” khơng? Theo trực giác, có. Chúng tơi biểu thị điều này bằng
cách viết “Hợp_Đồng_Nhân_Viên CHỒNG CHÉO Nhân_Viên_Cấp_Cao”. Trong
trường hợp không có tuyên bố như vậy, chúng ta giả định theo mặc định, các tập thực
thể bị ràng buộc khơng có chồng chéo.

15


Các ràng buộc bao gồm xác định xem các thực thể trong các lớp con có chung hay
khơng bao gồm tất cả các thực thể trong lớp cha. Ví dụ, mọi thực thể “Nhân viên” có
thuộc về một trong các lớp con của nó? Theo trực giác, khơng. Mọi thực thể
“Phương_Tiện_Cơ_Giới” phải là thực thể “Thuyền máy” hay thực thể “Ơ tơ”? Theo

trực giác, có; một thuộc tính đặc trưng của phân cấp khái quát là mọi ví dụ của lớp cha
là một thể hiện của một lớp con. Chúng ta biểu thị điều này bằng cách viết “Thuyền_Máy
VÀ Ơtơ BAO GỒM TRONG Phương_Tiện_Cơ_Giới”. Trong trường hợp khơng có
tun bố như vậy, chúng tơi giả định rằng khơng có ràng buộc bao gồm; chúng ta có thể
có các phương tiện cơ giới khơng phải là thuyền máy hay ơ tơ.
Có hai lý do cơ bản để xác định các lớp con (bằng cách chun hóa hoặc khái qt):
1. Chúng tơi có thể muốn thêm các thuộc tính mơ tả chỉ có ý nghĩa đối với các
thực thể trong một lớp con. Ví dụ, lương theo giờ khơng có ý nghĩa đối với
thực thể “Hợp_Đồng_Nhân_Viên”, mà việc trả lương được xác định bởi một
hợp đồng cá nhân.
2. Chúng tơi có thể muốn xác định tập hợp các thực thể tham gia vào một số mối
quan hệ. Ví dụ, chúng tơi có thể muốn xác định quan hệ “Người quản lý” để
các tập thực thể tham gia là các “Ban Phòng” và “Nhân_Viên_Cấp_Cao”, để
đảm bảo rằng chỉ nhân viên cấp cao có thể là nhà quản lý. Một ví dụ khác,
“Thuyền máy” và “Ơ tơ” có thể có các thuộc tính mơ tả khác nhau (giả sử,
trọng tải và số lượng cửa), nhưng là các thực thể “Phương_Tiện_Cơ_Giới”,
chúng phải được cấp phép. Thơng tin cấp phép có thể được nắm bắt bởi quan
hệ “Cấp_Phép_Để” giữa “Phương_Tiện_Cơ_Giới” và một tập thực thể được
gọi là “Chủ sở hữu”.
2.4.5 Tổng hợp
Như chúng ta đã định nghĩa cho đến nay, một tập quan hệ là một liên kết giữa các tập
thực thể. Đôi khi chúng ta phải mơ hình hóa mối quan hệ giữa một tập các thực thể và
các quan hệ. Giả sử rằng chúng ta có một tập thực thể được gọi là “Dự án” và mỗi thực
thể “Dự án” được tài trợ bởi một hoặc nhiều phòng ban. Tập quan hệ “Nhà tài trợ” nắm
bắt thơng tin này. Một phịng ban tài trợ cho một dự án có thể chỉ định nhân viên để
giám sát việc tài trợ. Về mặt trực quan, “Người giám sát” phải là một mối quan hệ được
thiết lập liên kết quan hệ “Nhà tài trợ” (thay vì thực thể “Dự án” hoặc “Phòng ban”) với
một thực thể “Nhân viên”. Tuy nhiên, chúng ta đã xác định các quan hệ để liên kết hai
hoặc nhiều thực thể.
Để xác định một tập quan hệ chẳng hạn như “Người giám sát”, chúng tơi giới thiệu một

tính năng mới của Mơ hình ER, được gọi là tổng hợp. Tổng hợp cho phép chúng ta chỉ
ra rằng một tập quan hệ (được xác định thông qua một hộp gạch ngang) tham gia vào
một tập quan hệ khác. Điều đó là được minh họa trong Hình 2.13, với một hộp gạch
ngang xung quanh “Nhà tài trợ” (và sự tham gia của các tập thực thể) được sử dụng để

16


biểu thị sự tổng hợp. Điều này cho phép chúng ta coi “Nhà tài trợ” là một tập thực thể
nhằm mục đích xác định tập quan hệ “Người giám sát”.
Khi nào chúng ta nên sử dụng tổng hợp? Một cách trực quan, chúng ta sử dụng nó khi
cần thể hiện mối quan hệ giữa các mối quan hệ. Nhưng liệu chúng ta không thể thể hiện
các mối quan hệ liên quan đến các mối quan hệ mà không sử dụng tổng hợp? Trong ví
dụ của chúng tơi, tại sao khơng đặt “Nhà tài trợ” trở thành mối quan hệ bậc ba? Câu trả
lời là thực sự có hai mối quan hệ riêng biệt, “Nhà tài trợ” và “Người giám sát”, mỗi
người có thể có các thuộc tính riêng. Ví dụ, quan hệ “Người giám sát” có một thuộc tính
cho đến khi ghi lại ngày cho đến khi nhân viên được chỉ định làm người giám sát tài trợ.
So sánh thuộc tính này với thuộc tính kể từ khi của “Nhà tài trợ”, là ngày tài trợ có hiệu
lực. Việc sử dụng tổng hợp so với quan hệ bậc ba cũng có thể được hướng dẫn bởi tính
tồn vẹn nhất định các ràng buộc, như được giải thích trong Phần 2.5.4.

Hình 2.13 Tổng hợp

17


LỜI CẢM ƠN
Đầu tiên, chúng em xin gửi lời cảm ơn chân thành đến Học viện Cơng nghệ Bưu chính
Viễn thông đã đưa môn học Cơ sở dữ liệu vào chương trình giảng dạy. Đặc biệt, chúng
em xin gửi lời cảm ơn sâu sắc đến giảng viên bộ môn - Cô Vũ Thị Thúy Hà đã dạy dỗ,

truyền đạt những kiến thức quý báu cho chúng em trong suốt thời gian học tập vừa qua.
Trong thời gian tham gia lớp học Cơ sở dữ liệu của cô, chúng em đã có thêm cho mình
nhiều kiến thức bổ ích, tinh thần học tập hiệu quả, nghiêm túc. Đây chắc chắn sẽ là
những kiến thức quý báu, là hành trang để chúng em có thể vững bước sau này. Bộ mơn
Cơ sở dữ liệu là môn học quan trọng, vô cùng bổ ích và có tính thực tế cao. Đảm bảo
cung cấp đủ kiến thức, gắn liền với nhu cầu thực tiễn của sinh viên. Tuy nhiên, do vốn
kiến thức còn nhiều hạn chế và khả năng tiếp thu thực tế còn nhiều bỡ ngỡ. Mặc dù
chúng em đã cố gắng hết sức nhưng chắc chắn bài tập lớn khó có thể tránh khỏi những
thiếu sót và nhiều chỗ cịn chưa chính xác, kính mong cơ xem xét và góp ý để bài tập
lớn của chúng em được hồn thiện hơn.

Nhóm thực hiện
Nhóm 3

18



×