Chương 4 1 - Mô hình hoá thực tế hệ (ER)

lOMoAR cPSD| 45148588 Chương 4 :
Mô hình hóa thực thể quan hệ(ER)
Sau khi hoàn thành chương này, bạn sẽ có khả năng:
• Xác định các đặc điểm chính của các thành phần mối quan hệ thực thể.
• Mô tả cách mà các mối quan hệ giữa các thực thể được định nghĩa, tinh chỉnh và
tíchhợp vào quy trình thiết kế cơ sở dữ liệu.
• Hiểu cách các thành phần của ERD ảnh hưởng đến thiết kế và triển khai cơ sở dữ liệu.
• Nhận thức rằng thiết kế cơ sở dữ liệu thực tế thường đòi hỏi sự điều hòa của các mục tiêu xung đột. Xem trước
Chương này mở rộng phạm vi của khía cạnh mô hình dữ liệu trong thiết kế cơ sở dữ
liệu. Mô hình dữ liệu là bước đầu tiên trong hành trình thiết kế cơ sở dữ liệu, đóng vai
trò như một cái cầu giữa các đối tượng trong thế giới thực và mô hình cơ sở dữ liệu
được triển khai trên máy tính. Do đó, không thể phủ nhận tầm quan trọng của các chi
tiết mô hình dữ liệu, được biểu diễn đồ họa thông qua các biểu đồ mối quan hệ thực thể (ERDs).
Hầu hết các khái niệm và định nghĩa cơ bản được sử dụng trong mô hình quan hệ thực
thể (ERM) đã được giới thiệu trong Chương 2, Mô hình dữ liệu. Ví dụ, các thành
phần cơ bản của thực thể và mối quan hệ cũng như cách biểu diễn của chúng đã trở
nên quen thuộc với bạn. Chương này đi sâu hơn nữa, phân tích việc biểu đồ hóa đồ
họa của mối quan hệ giữa các thực thể và chỉ ra cách những biểu đồ đó giúp bạn tóm
tắt lượng dữ liệu phong phú cần thiết để triển khai một thiết kế thành công. Cuối
cùng, chương minh họa cách mục tiêu xung đột có thể là một thách thức trong thiết kế
cơ sở dữ liệu và có thể đòi hỏi sự nhượng bộ trong thiết kế. lOMoAR cPSD| 45148588
141 Phần 2 Khái niệm Thết kế Ghi chú
Bởi vì cuốn sách này thường tập trung vào mô hình quan hệ, bạn có thể muốn kết luận rằng ERM chỉ là
một công cụ quan hệ. Trên thực tế, các mô hình khái niệm như ERM có thể được sử dụng để hiểu và thiết
kế các yêu cầu dữ liệu của một tổ chức. Do đó, ERM độc lập với loại cơ sở dữ liệu. Các mô hình khái
niệm được sử dụng trong thiết kế cơ sở dữ liệu khái niệm, trong khi các mô hình quan hệ được sử dụng
trong thiết kế logic của cơ sở dữ liệu. Tuy nhiên, vì bạn đã quen thuộc với mô hình quan hệ từ chương
trước nên mô hình quan hệ được sử dụng rộng rãi trong chương này để giải thích các cấu trúc ER và cách
chúng được sử dụng để phát triển các thiết kế cơ sở dữ liệu.
4-1 Mô hình thực thể quan hệ
Nhớ lại từ Chương 2, Mô hình dữ liệu và Chương 3, Mô hình cơ sở dữ liệu
quan hệ, rằng mô hình mối quan hệ thực thể (ERM) tạo thành cơ sở của ERD.
ERD đại diện cho cơ sở dữ liệu khái niệm được xem bởi người dùng cuối.
ERD mô tả các thành phần chính của cơ sở dữ liệu: thực thể, thuộc tính và mối
quan hệ. Bởi vì một thực thể đại diện cho một đối tượng trong thế giới thực,
các từ thực thể và đối tượng thường được sử dụng thay thế cho nhau. Do đó,
các thực thể (đối tượng) của thiết kế cơ sở dữ liệu Tiny College được phát triển
trong chương này bao gồm sinh viên, lớp học, giáo viên và lớp học. Thứ tự mà
các thành phần ERD được đề cập trong chương được quyết định bởi cách các
công cụ mô hình hóa được sử dụng để phát triển ERD có thể tạo cơ sở cho việc
thiết kế và triển khai cơ sở dữ liệu thành công. Trong Chương 2, bạn cũng đã
tìm hiểu về các ký hiệu khác nhau được sử dụng với ERD — ký hiệu Chen ban
đầu và các ký hiệu Crow's Foot và UML mới hơn. Hai ký hiệu đầu tiên được
sử dụng ở đầu chương này để giới thiệu một số khái niệm mô hình hóa ER cơ
bản. Một số khái niệm mô hình hóa cơ sở dữ liệu khái niệm chỉ có thể được thể
hiện bằng cách sử dụng ký hiệu Chen. Tuy nhiên, vì trọng tâm là thiết kế và
triển khai cơ sở dữ liệu, các ký hiệu sơ đồ lớp Crow's Foot và UML được sử
dụng cho ví dụ sơ đồ ER cuối cùng của Tiny College. Do nhấn mạnh vào việc
thực hiện, ký hiệu Crow's Foot chỉ có thể đại diện cho những gì có thể được
thực hiện. Nói cách khác:
• Ký hiệu Chen ủng hộ mô hình khái niệm.
• Ký hiệu Crow's Foot ủng hộ cách tiếp cận theo định hướng thực hiện hơn.
• Ký hiệu UML có thể được sử dụng cho cả mô hình khái niệm và triển khai. 4-1a Thực thể
Một thực thể là một đối tượng đáng quan tâm đối với người dùng cuối. Trong
Chương 2, bạn đã học rằng, ở cấp độ mô hình ER, một thực thể thực sự đề
cập đến tập hợp thực thể và không phải đến một trường hợp thực thể đơn lẻ.
Nói cách khác, một thực thể trong ERM tương ứng với một bảng—không
phải một hàng—trong môi trường quan hệ. ERM đề cập đến một hàng của lOMoAR cPSD| 45148588
bảng như là một thực thể hoặc một trường hợp thực thể. Trong biểu tượng
Chen, Crow's Foot, và UML, một thực thể được biểu diễn bằng một hình chữ
nhật chứa tên của thực thể. Tên thực thể, một danh từ, thường được viết hoa
toàn bộ. 4-1b Thuộc tính
Thuộc tính là đặc điểm của các thực thể. Ví dụ: thực thể STUDENT bao gồm
các thuộc tính STU_LNAME, STU_FNAME và STU_INITIAL, trong số
nhiều thuộc tính khác. Trong ký hiệu Chen ban đầu, các thuộc tính được biểu
diễn bằng hình bầu dục và được kết nối với hình chữ nhật thực thể bằng một
đường thẳng. Mỗi hình bầu dục chứa tên của thuộc tính mà nó đại diện. Trong
ký hiệu Crow's Foot, các thuộc tính được viết trong hộp thuộc tính bên dưới
hình chữ nhật thực thể. (Xem Hình 4.1.) Bởi vì đại diện Chen tiêu tốn nhiều
không gian hơn, các nhà cung cấp phần mềm đã áp dụng màn hình thuộc tính Crow's Foot
HÌNH 4.1 CÁC THUỘC TÍNH CỦA THỰC THỂ SINH VIÊN: CHEN VÀ CROW’S FOOT Chen Crow’s Foot Model Model STU_INITIAL STU_FNAME STU_EMAIL STUDENT STU_LNAME STU_PHONE
Thuộc tính bắt buộc và không bắt buộc Thuộc tính bắt buộc là thuộc
tính phải có giá trị; Nói cách khác, nó không thể bị bỏ trống. Như
thể hiện trong Hình 4.1, hai thuộc tính in đậm trong ký hiệu Crow's
Foot chỉ ra rằng việc nhập dữ liệu sẽ được yêu cầu. STU_LNAME
và STU_FNAME yêu cầu nhập dữ liệu vì tất cả học sinh đều được
giả định có họ và tên. Tuy nhiên, sinh viên có thể không có tên đệm
và có lẽ họ chưa có số điện thoại và địa chỉ email. Do đó, các thuộc
tính đó không được in đậm trong hộp thực thể. Thuộc tính tùy chọn
là thuộc tính không yêu cầu giá trị; Do đó, nó có thể bị bỏ trống.
Thuộc tính tên miền có một miền. Miền là tập hợp các giá trị có thể
có cho một thuộc tính nhất định. Ví dụ: miền cho thuộc tính điểm
trung bình (GPA) được viết (0,4) vì giá trị GPA thấp nhất có thể là 0
và giá trị cao nhất có thể là 4. Miền cho thuộc tính giới tính chỉ bao
gồm hai khả năng: M hoặc F (hoặc một số mã tương đương khác).
Miền cho thuộc tính ngày thuê của công ty bao gồm tất cả các ngày
phù hợp với một phạm vi (ví dụ: ngày bắt đầu công ty đến ngày hiện tại).
Các thuộc tính có thể chia sẻ miền. Ví dụ: địa chỉ sinh viên và địa
chỉ giáo sư chia sẻ cùng một miền của tất cả các địa chỉ có thể. Trên
thực tế, từ điển dữ liệu có thể cho phép một thuộc tính mới khai báo
kế thừa các đặc điểm của một thuộc tính hiện có nếu cùng một tên lOMoAR cPSD| 45148588
thuộc tính được sử dụng. Ví dụ: mỗi thực thể PROFESSOR và
STUDENT có thể có một thuộc tính có tên ADDRESS và do đó có thể chia sẻ một miền.
Mã định danh (Khóa chính) ERM sử dụng mã định danh—một hoặc
nhiều thuộc tính xác định duy nhất từng thể hiện thực thể. Trong
mô hình quan hệ, các thực thể được ánh xạ tới các bảng và mã định
danh thực thể được ánh xạ làm khóa chính (PK) của bảng. Số nhận
dạng được gạch chân trong ERD. Các thuộc tính chính cũng được
gạch chân trong một ký hiệu viết tắt thường được sử dụng cho cấu
trúc bảng, được gọi là lược đồ quan hệ, sử dụng định dạng sau: TÊN
BẢNG (KEY_ATTRIBUTE 1, THUỘC TÍNH 2, THUỘC TÍNH 3,
... THUỘC TÍNH K) Ví dụ: một thực thể CAR có thể được đại diện
bởi CAR (CAR_VIN, MOD_CODE, CAR_YEAR CAR_COLOR)
Mỗi chiếc xe được xác định bằng một số nhận dạng xe duy nhất hoặc CAR_VIN.
Mã định danh tổng hợp Lý tưởng nhất là giá trị nhận dạng thực thể
chỉ bao gồm một thuộc tính duy nhất. Ví dụ, bảng trong Hình 4.2
sử dụng một khóa chính thuộc tính đơn có tênCLASS_CODE. Tuy
nhiên, có thể sử dụng mã định danh tổng hợp, khóa chính bao gồm
nhiều thuộc tính. Ví dụ: quản trị viên cơ sở dữ liệu Tiny College có
thể quyết định xác định từng trường hợp thực thể CLASS (sự xuất
hiện) bằng cách sử dụng khóa chính tổng hợp của CRS_CODE và
CLASS_SECTION thay vì sử dụng CLASS_
CODE. Một trong hai cách tiếp cận xác định duy nhất từng trường hợp thực
thể. Với cấu trúc của bảng CLASS được hiển thị trong Hình 4.2,
CLASS_CODE là khóa chính và sự kết hợp của CRS_CODE và
CLASS_SECTION là một khóa ứng cử viên thích hợp. Nếu thuộc tính
CLASS_ CODE bị xóa khỏi thực thể CLASS, khóa ứng viên (CRS_CODE và
CLASS_SECTION) sẽ trở thành khóa chính tổng hợp được chấp nhận
HÌNH 4.2 BẢNG LỚP (THỰC THỂ) THÀNH PHẦN VÀ NỘI DUNG Database name: Ch04_TinyCollege
Khóa chính tổ hợp Trong mô hình ER, một khóa bao gồm nhiều hơn một thuộc
tính. Thuộc tính tổ hợpGhi chú lOMoAR cPSD| 45148588
Một thuộc tính có thể Hãy nhớ rằng Chương 3 đã tạo ra sự khác biệt thường được chấp nhận giữa COURSE và CLASS.
Một CLASS tạo được chia nhỏ hơn nữa thành một thời gian và địa điểm cụ thể của một COURSE. Một CLASS được xác định
bởi phần mô tả COURSE, thời để tạo ra các thuộc tính gian và địa điểm hoặc phần của nó. Hãy xem xét một giáo sư dạy Cơ
sở dữ liệu I, Phần 2; Cơ sở dữ liệu I, Phần 5; Cơ bổ sung. Ví dụ: một số sở dữ liệu I, Phần 8; và Bảng tính II, Phần 6. Giáo sư
dạy hai COURSE (Cơ sở dữ liệu I và Bảng tính II), nhưng có bốn điện thoại như 615-898-
lớp. Thông thường, các đề xuất COURSE được in trong danh mục COURSE, trong khi các đề xuất CLASS được in 2368 có thể được chia
thành mã vùng (615), số trong lịch học
cho mỗi học kỳ. trao đổi (898) và mã bốn
chữ số (2368). So sánh Nếu CLASS_CODE trong Hình 4.2 được sử dụng làm khóa chính, với thuộc tính đơn giản.
thực thể CLASS có thể được biểu diễn dưới dạng viết tắt như sau:
CLASS (CLASS_CODE, CRS_CODE, CLASS_SECTION, CLASS_TIME, ROOM_CODE, PROF_NUM)
Mặt khác, nếu CLASS_CODE bị xóa và khóa chính tổng hợp là sự
kết hợp của CRS_CODE và CLASS_SECTION, thực thể CLASS
có thể được trình bày như sau:
CLASS ( CRS_CODE , CLASS_SECTION , CLASS_TIME, ROOM_CODE, PROF_NUM)
Lưu ý rằng cả hai thuộc tính chính đều được gạch chân trong ký hiệu thực thể.
Thuộc tính tổng hợp và đơn giản Thuộc tính được phân loại là đơn
giản hoặc tổng hợp. Thuộc tính tổng hợp, không nên nhầm lẫn với
khóa tổng hợp, là một thuộc tính có thể được chia nhỏ hơn nữa để
mang lại các thuộc tính bổ sung. Ví dụ: thuộc tính ADDRESS có thể
được chia nhỏ thành đường phố, thành phố, tiểu bang và mã zip.
Tương tự, thuộc tính PHONE_ NUMBER có thể được chia thành
mã vùng và số trao đổi. Một thuộc tính đơn giản là một thuộc tính
không thể được chia nhỏ. Ví dụ: tuổi tác, giới tính và tình trạng hôn
nhân sẽ được phân loại là các thuộc tính đơn giản. Để tạo điều kiện
thuận lợi cho các truy vấn chi tiết, bạn nên thay đổi các thuộc tính
tổng hợp thành một loạt các thuộc tính đơn giản. Người thiết kế cơ
sở dữ liệu phải luôn chú ý đến các thuộc tính tổng hợp. Các quy tắc
kinh doanh thường sử dụng các thuộc tính tổng hợp để đơn giản hóa
các chính sách và người dùng thường mô tả các thực thể trong môi
trường của họ bằng các thuộc tính tổng hợp. Ví dụ: người dùng tại
Tiny College có thể cần biết tên, địa chỉ và số điện thoại của sinh
viên. Nhà thiết kế phải nhận ra rằng đây là các thuộc tính tổng hợp
và xác định cách chính xác để phân hủy hỗn hợp thành các thuộc tính đơn giản. lOMoAR cPSD| 45148588
Thuộc tính có giá trị đơn Thuộc tính đơn giá trị là một thuộc tính chỉ có thể có một giá trị
duy nhất. Ví dụ: một người chỉ có thể có một số An sinh Xã hội và một bộ phận được sản
xuất chỉ có thể có một số sê-ri. Hãy nhớ rằng thuộc tính một giá trị đơn không nhất thiết
phải là một thuộc tính đơn giản. Ví dụ: số sê-ri của một bộ phận (chẳng hạn như SE-08-
02-189935) là một giá trị đơn, nhưng nó là một thuộc tính tổng hợp vì nó có thể được chia
thành khu vực sản xuất bộ phận (SE), nhà máy trong khu vực đó (08), Thuộc tính đơn
sự thay đổi trong nhà máy (02) và số bộ phận (189935).
giản Một thuộc tính
Thuộc tính đa giá trị Thuộc tính đa giá trị là các thuộc tính có thể có không thể chia nhỏ thành các thành phần
nhiều giá trị. Ví dụ, một người có thể có nhiều bằng đại học và một hộ có ý nghĩa. So sánh
gia đình có thể có nhiều điện thoại khác nhau, mỗi điện thoại có số với thuộc tính tổng
riêng. Tương tự, màu sắc của một chiếc xe có thể được chia thành nhiều hợp.
màu cho nóc, thân xe và trang trí. Trong Chen ERM, các thuộc tính đa Thuộc tính đơn
giá trị được hiển thị bằng một đường kép kết nối thuộc tính với thực giá
thể. Ký hiệu Crow's Foot không xác định các thuộc tính đa giá trị. ERD trị Một thuộc tính chỉ
trong Hình 4.3 chứa tất cả các thành phần được giới thiệu cho đến nay; có thể có một giá trị.
lưu ý rằng CAR_VIN là khóa chính và CAR_COLOR là thuộc tính đa Thuộc tính đa trị
giá trị của thực thể CAR. Một thuộc tính có
118 Phần 2: Các Khái Niệm Thiết Kế thể có nhiều giá trị
Triển Khai Các Thuộc Tính Đa Giá Trị Mặc dù mô hình khái niệm có cho một lần xuất
hiện thực thể. Ví dụ:
thể xử lý các mối quan hệ M:N và các thuộc tính đa giá trị, nhưng bạn thuộc tính EMP_
không nên triển khai chúng trong RDBMS. Hãy nhớ từ Chương 3 DEGREE có thể lưu trữ chuỗi “BBA,
rằng trong bảng quan hệ, mỗi giao điểm cột và hàng đại diện cho một MBA, PHD” để chỉ
giá trị dữ liệu duy nhất. Vì vậy, nếu các thuộc tính đa giá trị tồn tại, ra ba mức độ khác nhau được giữ.
HÌNH 4.3 MỘT THUỘC TÍNH ĐA GIÁ TRỊ TRONG MỘT THỰC THỂ Chen Crow’s Foot Model Model MOD_CODE CAR_YEAR CAR_VIN CAR CAR_COLOR Ghi chú
Trong các mô hình ERD Hì nh 4.3, khóa ngoi ca th c th C AR (FK) đã đ c n hp l à MOD_CODE. Thuc tí nh này đã đ c th êm vào thc t h theo cá
ch th công. Trên thc t, vic s dng hp lý ph n mm mô hình hóa c s d liu s t đn g to ra FK k hi mi quan h đ c x ác đnh . Ngoài ra, phn m m s g n nhãn FK thích h p và ghi chi tit t rin khai ca FK vào
t đin d liu. (Bn có t h xem cách hot đn g ca
tính năng này trong Ph lc A, Th it k C s d liu v i Visio Pro fess iona l: H n g dn, ti www.cengagebrain.com.)
người thiết kế phải quyết định một trong hai hành động có thể thực hiện: lOMoAR cPSD| 45148588
1. Trong thực thể gốc, tạo ra một số thuộc tính mới, mỗi thuộc tính cho
một thành phần của thuộc tính đa giá trị gốc. Ví dụ, thuộc tính
CAR_COLOR của thực thể CAR có thể được phân chia để tạo ra các thuộc tính mới
CAR_TOPCOLOR, CAR_BODYCOLOR, và CAR_TRIMCOLOR, sau đó
được gán cho thực thể CAR. (Xem Hình 4.4.) FIGURE 4.4 Chen Crow’s Foot Model Model CAR_YEAR MOD_CODE CAR_TOPCOLOR CAR_VIN CAR CAR_TRIMCOLOR CAR_BODYCOLOR
Mặc dù giải pháp này dường như hoạt động, việc áp dụng nó có thể
dẫn đến các vấn đề cấu trúc lớn trong bảng. Nó chỉ được chấp nhận
nếu mỗi trường hợp sẽ có cùng số lượng giá trị cho thuộc tính đa giá
trị, và không có trường hợp nào sẽ bao giờ có nhiều giá trị hơn. Tuy
nhiên, ngay cả trong trường hợp này, đó là một rủi ro khi những thay
đổi mới trong môi trường có thể tạo ra tình huống mà một trường hợp
sẽ có nhiều giá trị hơn trước. Ví dụ, nếu các thành phần màu sắc bổ
sung — như một màu sắc logo — được thêm vào cho một số xe hơi,
cấu trúc bảng phải được sửa đổi để chứa phần màu sắc mới. Trong
trường hợp đó, các xe không có các phần màu sắc đó sẽ tạo ra giá trị
null cho các thành phần không tồn tại, hoặc các mục màu sắc cho các
phần đó được nhập vào là N/A để chỉ "không áp dụng." (Giải pháp
trong Hình 4.4 là phân chia một thuộc tính đa giá trị thành các thuộc
tính mới, nhưng hãy tưởng tượng những vấn đề mà loại giải pháp này
sẽ gây ra nếu nó được áp dụng vào một thực thể nhân viên chứa các
bằng cấp và chứng chỉ của nhân viên. Nếu một số nhân viên có 10
bằng cấp và chứng chỉ trong khi phần lớn không có hoặc ít hơn, số
lượng thuộc tính bằng cấp/chứng chỉ sẽ là 10, và hầu hết các giá trị
thuộc tính đó sẽ là null đối với hầu hết các nhân viên.) Tóm lại, mặc
dù bạn đã thấy giải pháp 1 được áp dụng, nó không phải lúc nào cũng được chấp nhận.
2. Tạo một thực thể mới được tạo thành từ các thành phần của thuộc
tính đa giá trị gốc. Thực thể mới này cho phép người thiết kế xác định màu lOMoAR cPSD| 45148588
sắc cho các phần khác nhau của xe hơi (xem Bảng 4.1). Sau đó, thực thể
CAR_COLOR mới này được liên kết với thực thể CAR gốc trong một mối quan hệ 1:M.
Sử dụng phương pháp được minh họa trong Bảng 4.1, bạn còn nhận
được một lợi ích phụ: bạn có thể gán bất kỳ màu sắc nào cần thiết mà
không cần phải thay đổi cấu trúc bảng. Mô hình ERM được hiển thị
trong Hình 4.5 phản ánh các thành phần được liệt kê trong Bảng 4.1.
Đây là cách ưu tiên để xử lý các thuộc tính đa giá trị. Tạo một thực thể
mới trong một mối quan hệ 1:M với thực thể gốc mang lại một số lợi
ích: đó là một giải pháp linh hoạt, mở rộng hơn, và tương thích với mô hình quan hệ!
Chương 4 Mô hình quan hệ thực thể (ER)119
CÁC THÀNH PHẦN CỦA THUỘC TÍNH ĐA GIÁ TRỊ HÌNH
PHẦN 4.5 MỘT TẬP HỢP THỰC T HỂ MỚI ĐƯỢC TẠO THÀNH PHẦN MÀU
CỦA THUỘC TÍNH ĐA GIÁ TRỊ Top Trắng Body Xanh Trim Vàng I nterior Xanh Ghi chú
Nếu bạn đã quen với việc nhìn vào các biểu đồ quan hệ như những biểu đồ được tạo ra bởi Microsoft Access, bạn
mong đợi thấy đường kết nối trong biểu đồ quan hệ vẽ từ PK đến FK. Tuy nhiên, quy ước của biểu đồ quan hệ
không nhất thiết phản ánh trong ERD. Trong một ERD, sự chú ý được đặt vào các thực thể và các mối quan hệ giữa
chúng, thay vì cách những mối quan hệ đó được gắn liền đồ họa. Trong một ERD phức tạp bao gồm cả các thực thể
được đặt ngang và dọc, việc đặt các đường quan hệ chủ yếu được quyết định bởi quyết định của nhà thiết kế để cải
thiện tính đọc hiểu của thiết kế. (Hãy nhớ rằng ERD được sử dụng cho việc truyền thông giữa các nhà thiết kế và người dùng cuối.)
Thuộc tính Dẫn Xuất Cuối cùng, một thuộc tính dẫn xuất là một
thuộc tính mà giá trị được tính toán (dẫn xuất) từ các thuộc tính
khác. Thuộc tính dẫn xuất không cần được lưu trữ vật lý trong cơ
sở dữ liệu; thay vào đó, nó có thể được tính toán bằng cách sử
dụng một thuật toán. Ví dụ, tuổi của một nhân viên, EMP_AGE,
có thể được tính bằng cách tính giá trị số nguyên của sự khác biệt
giữa ngày hiện tại và EMP_DOB. Nếu bạn sử dụng Microsoft
Access, bạn sẽ sử dụng công thức INT((DATE() -
EMP_DOB)/365). Trong Microsoft SQL Server, bạn sẽ sử dụng
DATEDIFF("DAY", EMB_DOB, GETDATE())/365, trong đó bên trong thực thể và lOMoAR cPSD| 45148588
DATEDIFF là một hàm tính toán sự khác biệt giữa các ngày. Nếu
bạn sử dụng Oracle, bạn sẽ sử dụng TRUNC((SYSDATE - EMP_DOB)/365,0).
Tương tự, tổng chi phí của một đơn đặt hàng có thể được tính
bằng cách nhân số lượng đặt hàng với giá trị đơn vị. Hoặc, tốc
độ trung bình ước tính có thể được tính bằng cách chia khoảng
cách chuyến đi cho thời gian dành trên đường. Một thuộc tính
dẫn xuất được chỉ ra trong ký hiệu Chen bằng một đường nét đứt
nối thuộc tính và thực thể. (Xem Hình 4.6.) Ký hiệu Crow's
Thuộc tính dẫn xuất
Một thuộc tính không tồn tại về mặt vật lý
Foot không có phương pháp để phân biệt thuộc tính dẫn xuất từ các thuộc tính khác.
Thuộc tính dẫn xuất đôi khi được gọi là thuộc tính tính toán.
Việc tính toán một thuộc tính dẫn xuất có thể đơn giản như cộng
hai giá trị thuộc tính nằm trên cùng một hàng, hoặc nó có thể là
kết quả của việc tổng hợp tổng các giá trị nằm trên nhiều hàng
của bảng (từ cùng một bảng hoặc từ một bảng khác). Quyết định
lưu trữ các thuộc tính dẫn xuất trong bảng cơ sở dữ liệu phụ
thuộc vào yêu cầu xử lý và các ràng buộc được đặt trên một ứng
dụng cụ thể. Người thiết kế nên có thể cân nhắc thiết kế phù hợp
với các ràng buộc như vậy. Bảng 4.2 hiển thị các ưu điểm và
nhược điểm của việc lưu trữ (hoặc không lưu trữ) các thuộc tính
dẫn xuất trong cơ sở dữ liệu.
ƯU VÀ NHƯỢC ĐIỂM CỦA VIỆC LƯU TRỮ CÁC THUỘC TÍNH DẪN XUẤT
THUỘC TÍNH DẪN XUẤT LƯU TRỮ KHÔNG LƯU TRỮ Ưu điểm
Tiết kiệm chu kỳ xử lý CPU
Tiết kiệm không gian lưu trữ
Tiết kiệm thời gian truy cập dữ liệu
Tính toán luôn mang lại giá trị hiện tại
Giá trị dữ liệu có sẵn
Có thể được sử dụng để theo dõi dữ liệu lịch sử Nhược điểm
Yêu cầu bảo trì liên tục để đảm bảo giá trị dẫn
Sử dụng nhiều chu kỳ xử lý của CPU
xuất là hiện tại, đặc biệt nếu bất kỳ giá trị nào
Tăng thời gian truy cập dữ liệu
được sử dụng trong phép tính thay đổi
Thêm độ phức tạp mã hóa vào các truy vấn lOMoAR cPSD| 45148588
HÌNH 4.6 MÔ TẢ MỘT THUỘC TÍNH DẪN XUẤT Chen Crow’s Foot Model Model EMP_FNAME EMP_INITIAL EMP_LNAME EMP_DOB EMP_NUM EMPLOYEE EMP_AGE Bảng 4.2 Việc Ghi chú
Các hệ thống quản lý cơ sở dữ liệu hiện đại cung cấp các định nghĩa kiểu dữ liệu mới để hỗ trợ dữ liệu tính toán hoặc phân
tính toán. Ví dụ, trong MS Access, bạn có thể sử dụng kiểu dữ liệu Calculated. SQL Server, Oracle và MySQL cũng hỗ loại
trợ việc định nghĩa các thuộc tính dẫn xuất hoặc tính toán. Mối 4-1c Mối quan hệ
Quan Hệ là khó khăn khi bạn
Nhớ lại từ Chương 2 rằng một mối quan hệ là sự liên kết giữa chỉ biết một bên của Mối Quan
các thực thể. Các Thực Thể tham gia vào một Mối Quan Hệ còn Hệ. Ví dụ, nếu bạn chỉ ra rằng:
được gọi là các Bên Tham Gia, và mỗi Mối Quan Hệ được xác
định bằng một Tên mô tả Mối Quan Hệ. Tên của Mối Quan Hệ - Một DIVISION được quản lý
là một Động Từ tính Chủ Động hoặc Bị Động; ví dụ, một bởi một EMPLOYEE.
STU_DENT tham gia một CLASS, một PROFESSOR giảng Nội dung trực tuyến
Bởi vì việc định nghĩa cnn thận các quy tắc
dạy một CLASS, một DEPARTMENT thuê một PROFESSOR , nghiệp vụ đầy đủ và chính xác là rất quan
một DIVISION được quản lý bởi một EMPLOYEE, và một trọng để thiết kế cơ sở dữ liệu tốt, nên nguồn
gốc của chúng được xem xét chi tiết trong Phụ
AIRCRAFT được lái bởi một CREW. Mối Quan Hệ giữa các lục B, Phòng thí nghiệm Đại học: Thiết kế
Khái niệm. Các kỹ năng lập mô hình mà bạn
Thực Thể luôn hoạt động ở cả hai hướng. Để xác định Mối Quan đang học trong chương này được áp dụng
trong việc phát triển một thiết kế cơ sở dữ liệu
Hệ giữa các Thực Thể có Tên là CUSTOMER và
thực trong Phụ lục B. Thiết kế ban đầu được
trình bày trong Phụ lục B sau đó được sửa đổi
DIVISION , bạn sẽ chỉ ra rằng:
trong Phụ lục C, The University Lab: C onc
eptu al D Xác minh esign, Thiết kế logic và Triển khai.
- Một CUSTOMER có thể tạo ra nhiều DIVISION . (Cả hai phụ lục đều có tại www.cengagebrain.com.)
- Mỗi DIVISION được tạo ra bởi một CUSTOMER .
Bởi vì bạn biết cả hai hướng của Mối Quan Hệ giữa
CUSTOMER và DIVISION , dễ dàng nhận thấy rằng Mối Quan
Hệ này có thể được phân loại là 1:M.
Bạn không biết Mối Quan Hệ là 1:1 hay 1:M. Do đó, bạn nên đặt
câu hỏi "Một nhân viên có thể quản lý nhiều bộ phận không?" lOMoAR cPSD| 45148588
Nếu câu trả lời là có, Mối Quan Hệ là 1:M, và phần thứ hai của
Mối Quan Hệ được viết như sau:
- Một EMPLOYEE có thể quản lý nhiều DIVISION .
Nếu một nhân viên không thể quản lý hơn một bộ phận, Mối
Quan Hệ là 1:1, và phần thứ hai của Mối Quan Hệ được viết như sau: DIVISION
- Một EMPLOYEE có thể quản lý chỉ một BỘ PHẬN.
4-1d Kết nối và tính cơ bản Connectivity và Cardinality
Bạn đã học trong Chương 2 rằng mối quan hệ giữa các thực thể có thể được
phân loại là một-một, một- nhiều, hoặc nhiều-nhiều. Bạn cũng đã học cách mối
quan hệ như vậy được mô tả trong các biểu đồ của Chen và Crow's Foot. Thuật
ngữ "connectivity" được sử dụng để mô tả phân loại mối quan hệ.
HÌNH 4.7 LIÊN KẾT VÀ LỰC LƯỢNG TRONG MỘT ERD
Cardinality biểu thị số lượng tối thiểu và tối đa của các thực thể liên quan đến
một trường hợp của thực thể tương ứng. Trong ERD, cardinality được chỉ định
bằng cách đặt các số thích hợp bên cạnh các thực thể, sử dụng định dạng (x, y).
Giá trị đầu tiên đại diện cho số lượng tối thiểu của các thực thể liên quan, trong
khi giá trị thứ hai đại diện cho số lượng tối đa của các thực thể liên quan.
Nhiều nhà thiết kế cơ sở dữ liệu sử dụng ký hiệu Crow's Foot không mô tả cụ
thể các cardinality trên biểu đồ ER vì các giới hạn cụ thể mô tả bởi cardinality
không thể được triển khai trực tiếp thông qua thiết kế cơ sở dữ liệu. Tương
ứng, một số công cụ mô hình Crow's Foot ER không in ra phạm vi cardinality
số học trên biểu đồ; thay vào đó, bạn có thể thêm nó như là văn bản nếu bạn
muốn hiển thị nó. Khi các cardinality cụ thể không được bao gồm trên biểu đồ
trong ký hiệu Crow's Foot, cardinality được ngụ ý thông qua việc sử dụng các lOMoAR cPSD| 45148588
biểu tượng được hiển thị trong Hình 4.7, mô tả sự kết nối và sự tham gia (sẽ
được thảo luận sau). Phạm vi cardinality số học đã được thêm bằng cách sử
dụng công cụ vẽ văn bản của Microsoft Visio. cấu trúc cơ sở dữ liệu.Biết số lần
xuất hiện thực thể tối thiểu và tối đa là rất hữu ích ở cấp độ phần mềm ứng
dụng. Ví dụ: Tiny College có thể muốn đảm bảo rằng một lớp học không được
dạy trừ khi có ít nhất 10 học sinh ghi danh. Tương tự, nếu lớp học chỉ có thể
chứa 30 học sinh, phần mềm ứng dụng sẽ sử dụng số lượng đó để hạn chế đăng
ký vào lớp. Tuy nhiên, hãy nhớ rằng DBMS không thể xử lý các việc triển khai
các số liệu chính ở cấp độ bảng—khả năng đó được cung cấp bởi phần mềm
ứng dụng hoặc bằng trigger. Bạn sẽ học cách tạo và thực thi trigger trong Chương 8, SQL nâng cao.
Khi bạn xem xét sơ đồ Crow's Foot trong Hình 4.7, hãy nhớ rằng số lần xuất
hiện của ô tô thể hiện số lần xuất hiện trong thực thể liên quan. Ví dụ, số lượng
số (1,4) bên cạnh thực thể CLASS trong mối quan hệ “PROFESSOR dạy
CLASS” chỉ ra rằng mỗi giáo sư dạy tối đa bốn lớp, có nghĩa là giá trị khóa
chính của bảng PRO FESSOR xuất hiện ít nhất một lần và không quá bốn lần
như giá trị khóa ngoại trong bảng CLASS. Nếu số lượng đã được viết là (1,N),
thì có sẽ không có giới hạn trên đối với số lớp mà một giáo sư có thể dạy.
Tương tự, các số lượng (1,1) bên cạnh thực thể PROFESSOR chỉ ra rằng mỗi
lớp được dạy bởi một và chỉ có một giáo sư. Nghĩa là, mỗi lần xuất hiện của
thực thể LỚP được liên kết với một và chỉ có một thực thể xuất hiện trong
PROFESSOR.Sự kết nối và các yếu tố chính được thiết lập bằng các tuyên bố
ngắn gọn được gọi là quy tắc kinh doanh, được giới thiệu trong Chương 2.
Những quy tắc như vậy, bắt nguồn từ một quy tắc chính xác và chính xác.mô tả
chi tiết về môi trường dữ liệu của tổ chức, đồng thời thiết lập ERM thực thể,
thuộc tính, mối quan hệ, kết nối, số lượng và các ràng buộc. Bởi vì quy tắc
kinh doanh xác định các thành phần của ERM, đảm bảo rằng tất cả các hoạt
động kinh doanh phù hợp các quy tắc được xác định là một phần quan trọng
trong công việc của người thiết kế cơ sở dữ liệu.. Ghi chú
Vị trí của các lực lượng trong sơ đồ ER là một vấn đề quy ước. Ký hiệu Chen đặt các yếu tố
chính ở phía bên của thực thể liên quan. Sơ đồ Crow's Foot và UML đặt các lực lượng bên cạnh
thực thể mà chúng áp dụng. lOMoAR cPSD| 45148588
4-1e Sự phụ thuộc vào sự tồn tại lOMoAR cPSD| 45148588
Phụ thuộc vào sự tồn tại Một thuộc 琀 nh của
một thực thể mà sự tồn
tại của nó phụ thuộc vào
một hoặc nhiều thực thể khác. Trong một môi
trường như vậy, bảng độc
lập với sự tồn tại phải
được tạo và tải trước vì khóa phụ thuộc vào sự tồn tại không thể tham
chiếu một bảng chưa tồn Tại.
Tồn tại độc lập Thuộc 琀 nh của một
thực thể có thể tồn tại ngoài một hoặc nhiều
thực thể liên quan. Một
bảng như vậy phải được
tạo trước khi tham chiếu
đến một bảng phụ thuộc vào sự tồn tại. Thực thể mạnh
Một thực thể độc lập với
sự tồn tại, nghĩa là nó có lOMoAR cPSD| 45148588
thể tồn tại tách biệt với
Một thực thể được gọi là phụ thuộc vào sự tồn tại nếu nó chỉ có thể tồn
tất cả các thực thể liên tại trong cơ sở dữ liệu khi nó được liên kết với một thực thể liên quan khác.
quan của nó. Thực thể
thông thường Xem Theo các thuật ngữ triển khai, một thực thể được coi là phụ thuộc vào sự tồn thực thể mạnh.
tại nếu nó có một khóa ngoại bắt buộc - tức là, một thuộc tính khóa ngoại
không thể là null. Ví dụ, nếu một nhân viên muốn khai báo một hoặc nhiều
người phụ thuộc cho mục đích giữ lại thuế, mối quan hệ "EMPOYEE khai
báo người DEPENDENT" sẽ phù hợp. Trong trường hợp đó, thực thể
DEPENDENT rõ ràng phụ thuộc vào thực thể NHÂN VIÊN vì không thể có
phụ thuộc tồn tại mà không có EMPLOYEE trong cơ sở dữ liệu.
Nếu một thực thể có thể tồn tại riêng biệt khỏi tất cả các thực thể liên
quan của nó, thì nó là tồn tại độc lập, và nó được gọi là một thực thể mạnh
mẽ hoặc thực thể thông thường. Ví dụ, giả sử Tập đoàn XYZ sử dụng các bộ
phận để sản xuất sản phnm của mình. Hơn nữa, giả sử rằng một số các bộ
phận đó được sản xuất trong nhà và các bộ phận khác được mua từ các nhà
cung cấp. Trong tình huống đó, hoàn toàn có thể cho một PART tồn tại độc
lập khỏi một VENDOR trong mối quan hệ "PARTđược cung cấp bởi
VENDOR" vì ít nhất một số bộ phận không được cung cấp bởi một nhà cung
cấp. Do đó, PARTlà tồn tại độc lập từ VENDOR. Ghi chú
Khái niệm về sức mạnh của mối quan hệ không phải là một phần của ERM ban đầu. Thay vào đó, khái niệm này
áp dụng trực tiếp cho sơ đồ Crow’s Foot. Bởi vì biểu đồ Crow’s Foot được sử dụng rộng rãi để thiết kế cơ sở dữ
liệu quan hệ, điều quan trọng là phải hiểu sức mạnh của mối quan hệ vì nó ảnh hưởng đến việc triển khai cơ sở dữ
liệu. Ký hiệu Chen ERD được định hướng theo mô hình khái niệm và do đó không phân biệt giữa các mối quan hệ yếu và mạnh.
4-1f Sức mạnh mối quan hệ
Khái niệm về mức độ mạnh của mối quan hệ dựa trên cách khóa
chính của một thực thể liên quan được xác định. Để triển khai một
mối quan hệ, khóa chính của một thực thể (thực thể cha, thường ở
"một" phía của mối quan hệ một-nhiều) xuất hiện như một khóa
ngoại trong thực thể liên quan (thực thể con, phần lớn là thực thể ở
"nhiều" phía của mối quan hệ một-nhiều). Đôi khi, khóa ngoại cũng
là một thành phần của khóa chính trong thực thể liên quan. Ví dụ,
trong Hình 4.5, khóa chính của thực thể CAR (CAR_VIN) xuất hiện
như một thành phần của khóa chính và là một khóa ngoại trong thực
thể CAR_COLOR. Trong phần này, bạn sẽ tìm hiểu cách các quyết lOMoAR cPSD| 45148588
định về mức độ mạnh của mối quan hệ ảnh hưởng đến việc sắp xếp
khóa chính trong thiết kế cơ sở dữ liệu.
Mối Quan Hệ Yếu (Không Xác Định) Một mối quan hệ yếu, còn
được gọi là mối quan hệ không xác định, tồn tại nếu khóa chính của
thực thể liên quan không chứa một thành phần của khóa chính của
thực thể cha. Mặc định, mối quan hệ được thiết lập bằng cách có
khóa chính của thực thể cha xuất hiện như một khóa ngoại (FK) trên
thực thể liên quan (còn được gọi là thực thể con). Ví dụ, giả sử mối
quan hệ 1:M giữa COURSE và CLASS được xác định như sau: COURSE (CRS_CODE, DEPT_CODE, CRS_DESCRIPTION, CRS_CREDIT) CLASS (CLASS_CODE, CRS_CODE, CLASS_SECTION,
CLASS_TIME, ROOM_CODE, PROF_NUM)
Trong ví dụ này, khóa chính của CLASS không thừa kế một thành phần
của khóa chính từ thực thể COURSE. Trong trường hợp này, một lOMoAR cPSD| 45148588
mối quan hệ yếu tồn tại giữa COURSE và CLASS vì CRS_CODE
(khóa chính của thực thể cha) chỉ là một khóa ngo0lại trong thực thể CLASS.
Hình 4.8 cho thấy cách ký hiệu Crow's Foot mô tả một mối quan hệ yếu Mối quan hệ yếu
bằng cách đặt một đường mối quan hệ đứt nối giữa các thực thể. Các bảng (không xác định)
được hiển thị dưới biểu đồ ERD minh họa cách triển khai một mối quan Mối quan hệ trong hệ như vậy. đó khóa chính của thực thể liên quan thực hiện không chứa thành phần khóa chính của thực thể mẹ. Mối quan hệ mạnh (xác định) Một mối quan hệ xảy ra khi hai thực thể phụ thuộc vào sự tồn tại; từ quan điểm thiết kế cơ sở dữ liệu, mối quan hệ này tồn tại bất cứ khi nào khóa chính của thực thể liên quan chứa khóa chính của thực thể mẹ.
HÌNH 4.8 MỐI QUAN HỆ YẾU (KHÔNG XÁC ĐỊNH) GIỮA KHÓA HỌC VÀ LỚP HỌC Table name: Database name: COURSE Ch04_TinyCollege Table name: CLASS
Downloaded by 562003 Linhlao (linhlao562003@gmail.com)
Mối Quan Hệ Mạnh (Xác Định) Mối quan hệ mạnh (xác định) tồn tại khi
khóa chính của thực thể liên quan chứa một thành phần của khóa chính
của thực thể cha. Ví dụ, giả sử mối quan hệ 1:M giữa COURSE và
CLASS được xác định như sau:
COURSE (CRS_CODE, DEPT_CODE, CRS_DESCRIPTION, CRS_CREDIT) CLASS (CRS_CODE, CLASS_SECTION,
CLASS_TIME, ROOM_CODE, PROF_NUM)
Trong trường hợp này, khóa chính của CLASS được tạo thành từ
CRS_CODE và CLASS_SECTION. Do đó, một mối quan hệ mạnh tồn
tại giữa COURSE và CLASS vì CRS_CODE (khóa chính của thực thể
cha) là một thành phần của khóa chính trong thực thể CLASS. Nói cách
khác, khóa chính của CLASS đã thừa kế một thành phần của khóa chính
124 Phần 2 Khái niệm thiết kế
component từ thực thể COURSE. (Lưu ý rằng
CRS_CODE trong CLASS cũng là FK đến thực thể COURSE.)
Ký hiệu Crow's Foot mô tả mối quan hệ mạnh (xác định) bằng một đường đậm
giữa các thực thể, như được thể hiện trong Hình 4.9. lOMoAR cPSD| 45148588
Khi bạn xem xét Hình 4.9, bạn có thể tự hỏi biểu tượng O bên cạnh thực thể
CLASS ý nghĩa gì. Bạn sẽ khám phá ý nghĩa của cardinality này trong Phần 4- 1h, Tham Gia Mối Quan Hệ.
Downloaded by 562003 Linhlao (linhlao562003@gmail.com) lOMoAR cPSD| 45148588
Downloaded by 562003 Linhlao (linhlao562003@gmail.com)
Tóm lại, việc mối quan hệ giữa COURSE và CLASS là mạnh hay yếu phụ thuộc
vào cách khóa chính của thực thể CLASS được xác định. Hãy nhớ rằng bản chất
của mối quan hệ thường được xác định bởi người thiết kế cơ sở dữ liệu, người
phải sử dụng sự đánh giá chuyên nghiệp để xác định loại mối quan hệ và mức
độ mạnh mạnh nhất phù hợp với giao dịch cơ sở dữ liệu, hiệu suất và yêu cầu
thông tin. Điều này sẽ được nhấn mạnh chi tiết!