Mô Hình Dữ Liệu E-R: Các Vấn Đề Cần Quan Tâm Khi Thiết Kế

Chuyên khảo phân tích Mo hinh e r 2, đánh giá các khía cạnh quan trọng, đề xuất hướng nghiên cứu tiếp theo., phục vụ nghiên cứu và ứng dụng thực tiễn

• Trường học: Trường Đại Học
• Chuyên ngành: Công Nghệ Thông Tin
• Đề tài: Mô Hình Dữ Liệu E-R: Thiết Kế và Ảnh Hưởng
• Loại tài liệu: bài luận
• Năm xuất bản: 2023
• Địa điểm: Hà Nội

Mục lục chi tiết

• 1. CÁC MÔ HÌNH DỮ LIỆU
• 1.1. Giới thiệu
• 1.2. Quá trình thiết kế một CSDL
• 1.3. Mô hình thực thể liên kết E-R
• 1.4. Một số vấn đề cần quan tâm khi thiết kế mô hình E-R
• 1.5. Mô hình dữ liệu quan hệ
• 1.6. Ánh xạ mô hình thực thể liên kết sang mô hình quan hệ
• 2. MỘT SỐ VẤN ĐỀ CẦN QUAN TÂM KHI THIẾT KẾ MÔ HÌNH E-R
• 3. ẢNH HƢỞNG CỦA ÁNH XẠ LỰC LƢỢNG LIÊN KẾT LÊN CÁC KHÓA
• 3.1. Cấu trúc của khóa chính cho tập các quan hệ phụ thuộc vào việc ánh xạ lực lượng liên kết
• 3.2. Lược đồ dữ liệu của hai tập thực thể CUSTOMER và ACCOUNT
• 3.3. Xem xét lần nộp tiền cuối cùng (last deposit) vào một tài khoản cụ thể
• 3.4. Trường hợp một khách hàng chỉ được phép nộp tiền vào một tài khoản duy nhất
• 3.5. Lược đồ dữ liệu của hai tập thực thể CUSTOMER và ACCOUNT trong trường hợp M:1
• 3.6. Trường hợp quan hệ depositor là M:1 từ ACCOUNT tới CUSTOMER
• 3.7. Khóa chính của quan hệ depositor trong trường hợp M:1 từ ACCOUNT tới CUSTOMER
• 4. ĐẶT VỊ TRÍ CHO CÁC THUỘC TÍNH CỦA QUAN HỆ
• 4.1. Thuộc tính của tập quan hệ dạng 1:1 hoặc 1:M thường được đặt vào trong các tập thực thể tham gia liên kết
• 4.2. Thuộc tính access-date có thể được đặt liên quan tới thực thể ACCOUNT mà không làm tổn thất thông tin
• 4.3. Trường hợp một tài khoản được làm chủ bởi nhiều nhất một khách hàng và một khách hàng chỉ có thể sở hữu duy nhất một tài khoản
• 4.4. Thuộc tính access-date được lưu trữ với tập CUSTOMER hoặc ACCOUNT
• 4.5. Trường hợp quan hệ depositor có ràng buộc N:N
• 4.6. Lưu trữ ngày truy nhập cuối cùng của một khách hàng cụ thể tới một tài khoản cụ thể
• 5. TẬP THỰC THỂ HAY CÁC THUỘC TÍNH
• 5.1. Xét một tập thực thể: EMPLOYEE(emp-name, telephone-number, age)
• 5.2. Trường hợp máy điện thoại được coi là một thực thể
• 5.3. Trường hợp mỗi nhân viên có một số điện thoại hoặc nhiều điện thoại
• 6. TẬP THỰC THỂ HAY TẬP QUAN HỆ
• 6.1. Ví dụ ngân hàng mô hình hóa khoản vay như một thực thể (LOAN)
• 6.2. Mô hình hóa khoản vay như một mối quan hệ giữa khách hàng và chi nhánh
• 6.3. Vấn đề phát sinh khi dùng lặp lại các giá trị trong mô hình hóa khoản vay
• 7. TẬP THỰC THỂ MẠNH HAY TẬP THỰC THỂ YẾU
• 7.1. Tập thực thể không đủ các thuộc tính để hình thành khóa chính gọi là tập thực thể yếu
• 7.2. Tập thực thể yếu phải liên hệ với tập thực thể xác định
• 7.3. Mối quan hệ xác định là quan hệ M:1 từ tập thực thể yếu tới tập xác định
• 7.4. Phương thức phân biệt các thực thể trong tập thực thể yếu
• 7.5. Khóa chính của tập thực thể yếu được cấu thành bởi khóa chính của tập thực thể xác định và thuộc tính phân biệt
• 8. CỤ THỂ HÓA (Specialization)
• 8.1. Cụ thể hóa là quá trình thiết kế các phân nhóm trong một tập thực thể
• 8.2. Ví dụ phân chia tập thực thể người thành STUDENT và INSTRUCTOR
• 9. TỔNG QUÁT HÓA (Generalization)
• 9.1. Tổng quát hóa là nhiều tập thực thể đồng bộ vào một tập thực thể ở mức cao hơn
• 9.2. Ví dụ tổng quát hóa tập thực thể STUDENT và INSTRUCTOR thành PERSON
• 10. CỤ THỂ HÓA VÀ TỔNG QUÁT HÓA
• 10.1. Cụ thể hóa và tổng quát hóa là hai khái niệm ngược và có thể hoán đổi cho nhau
• 10.2. Sự khác nhau của hai cách tiếp cận cụ thể hóa và tổng quát hóa
• 11. KẾ THỪA THUỘC TÍNH
• 11.1. Tập thực thể mức thấp hơn kế thừa các thuộc tính từ tập thực thể mức cao hơn
• 11.2. Cây phân cấp các tập thực thể
• 12. CÁC RÀNG BUỘC TỔNG QUÁT HÓA (CỤ THỂ HÓA)
• 12.1. Ràng buộc thứ nhất: Xác định thực thể thành viên của tập thực thể mức thấp hơn
• 12.2. Ràng buộc thứ hai: Thực thể có thể thuộc nhiều tập thực thể mức thấp hơn hay không
• 12.3. Ràng buộc thứ ba: Tính toàn bộ của tổng quát hóa/cụ thể hóa
• 13. VÍ DỤ ERD VỚI CÁC RÀNG BUỘC
• 13.1. Ví dụ tổng quát hóa toàn bộ và có giao nhau
• 14. KẾT HỢP
• 14.1. Hạn chế của mô hình E-R: không thể biểu diễn các mối quan hệ trong các mối quan hệ
• 14.2. Ví dụ quan hệ ba ngôi works-on giữa EMPLOYEE, BRANCH và JOB
• 14.3. Quản lý công việc được thực hiện bởi nhân viên tại chi nhánh
• 14.4. Lý do không thể hiện mối quan hệ hai ngôi giữa MANAGER và EMPLOYEE
• 14.5. Nhận xét về việc kết hợp các tập quan hệ works-on và manages
• 14.6. Biến MANAGER thành thuộc tính đa trị của quan hệ works-on
• 14.7. Cách tốt nhất để mô hình hóa là sử dụng kết hợp (tích hợp)
• 15. QUAN HỆ NHIỀU NGÔI
• 15.1. Quan hệ nhiều ngôi có thể chuyển thành tập các quan hệ hai ngôi dạng nhiều-một
• 15.2. Ví dụ mô hình E-R với quan hệ nhiều ngôi
• 15.3. Chuyển quan hệ nhiều ngôi thành tập các quan hệ hai ngôi
• 16. SƠ ĐỒ E-R VỚI CÁC CHỈ THỊ VAI TRÒ
• 16.1. Vai trò trong lược đồ E-R được biểu diễn bằng nhãn trên các đường kết nối
• 16.2. Vai trò có thể xác định cho các mối quan hệ đệ quy, nhị phân và không nhị phân
• 17. NGÔN NGỮ UML (Unified Modeling Language)
• 17.1. Một số thành phần của UML
• 18. SỰ TƯƠNG ỨNG GIỮA SƠ ĐỒ E-R VÀ SƠ ĐỒ LỚP UML
• 18.1. Các tập thực thể và thuộc tính trong sơ đồ E-R và sơ đồ lớp UML
• 19. SỰ TƯƠNG ỨNG GIỮA SƠ ĐỒ E-R VÀ SƠ ĐỒ LỚP UML (Cont.)
• 19.1. Các quan hệ role1, role2 trong sơ đồ E-R và sơ đồ lớp UML

Tóm tắt

I. Tổng Quan Về Mô Hình Dữ Liệu E R Thiết Kế và Ảnh Hưởng

Mô hình dữ liệu E-R (Entity-Relationship) là một công cụ quan trọng trong thiết kế cơ sở dữ liệu. Nó giúp mô tả các thực thể và mối quan hệ giữa chúng. Việc hiểu rõ mô hình E-R là cần thiết để xây dựng một cơ sở dữ liệu hiệu quả và dễ quản lý. Mô hình này không chỉ giúp lập kế hoạch cho cơ sở dữ liệu mà còn ảnh hưởng đến hiệu suất và khả năng mở rộng của hệ thống.

1.1. Mô Hình E R Là Gì

Mô hình E-R là một phương pháp biểu diễn các thực thể và mối quan hệ giữa chúng trong cơ sở dữ liệu. Nó giúp người thiết kế hình dung cấu trúc dữ liệu một cách trực quan.

1.2. Lợi Ích Của Mô Hình E R Trong Thiết Kế CSDL

Mô hình E-R giúp giảm thiểu sự trùng lặp dữ liệu, cải thiện tính toàn vẹn và dễ dàng trong việc bảo trì cơ sở dữ liệu. Nó cũng hỗ trợ việc chuyển đổi sang mô hình quan hệ.

II. Các Vấn Đề Cần Quan Tâm Khi Thiết Kế Mô Hình E R

Thiết kế mô hình E-R không phải là một nhiệm vụ đơn giản. Có nhiều vấn đề cần xem xét để đảm bảo rằng mô hình được xây dựng chính xác và hiệu quả. Những vấn đề này bao gồm việc xác định các thực thể, thuộc tính và mối quan hệ giữa chúng.

2.1. Xác Định Các Thực Thể và Thuộc Tính

Việc xác định các thực thể và thuộc tính là bước đầu tiên trong thiết kế mô hình E-R. Các thực thể cần phải được phân loại rõ ràng để tránh nhầm lẫn.

2.2. Mối Quan Hệ Giữa Các Thực Thể

Mối quan hệ giữa các thực thể cần được xác định rõ ràng để đảm bảo tính chính xác của mô hình. Điều này bao gồm việc xác định loại mối quan hệ (1:1, 1:N, N:M).

III. Phương Pháp Thiết Kế Mô Hình E R Hiệu Quả

Có nhiều phương pháp để thiết kế mô hình E-R hiệu quả. Những phương pháp này giúp tối ưu hóa cấu trúc dữ liệu và đảm bảo rằng cơ sở dữ liệu hoạt động tốt trong thực tế.

3.1. Sử Dụng Công Cụ Hỗ Trợ Thiết Kế

Các công cụ thiết kế mô hình E-R như ERDPlus hay Lucidchart có thể giúp người dùng tạo ra các sơ đồ một cách dễ dàng và trực quan.

3.2. Kiểm Tra và Tinh Chỉnh Mô Hình

Sau khi thiết kế, việc kiểm tra và tinh chỉnh mô hình là rất quan trọng. Điều này giúp phát hiện và sửa chữa các lỗi trước khi triển khai.

IV. Ứng Dụng Thực Tiễn Của Mô Hình E R Trong CSDL

Mô hình E-R được ứng dụng rộng rãi trong nhiều lĩnh vực khác nhau, từ ngân hàng đến thương mại điện tử. Việc áp dụng mô hình này giúp cải thiện hiệu suất và khả năng quản lý dữ liệu.

4.1. Mô Hình E R Trong Ngân Hàng

Trong ngành ngân hàng, mô hình E-R giúp quản lý thông tin khách hàng, tài khoản và giao dịch một cách hiệu quả.

4.2. Mô Hình E R Trong Thương Mại Điện Tử

Mô hình E-R hỗ trợ việc quản lý sản phẩm, đơn hàng và khách hàng trong các hệ thống thương mại điện tử, giúp tối ưu hóa quy trình kinh doanh.

V. Kết Luận Về Mô Hình Dữ Liệu E R và Tương Lai

Mô hình dữ liệu E-R là một công cụ mạnh mẽ trong thiết kế cơ sở dữ liệu. Với sự phát triển của công nghệ, mô hình này sẽ tiếp tục được cải tiến và áp dụng rộng rãi hơn trong tương lai.

5.1. Xu Hướng Phát Triển Mô Hình E R

Các xu hướng mới trong thiết kế cơ sở dữ liệu như NoSQL và Big Data đang ảnh hưởng đến cách thức sử dụng mô hình E-R.

5.2. Tương Lai Của Mô Hình E R

Mô hình E-R sẽ tiếp tục đóng vai trò quan trọng trong việc thiết kế cơ sở dữ liệu, đặc biệt trong bối cảnh dữ liệu ngày càng phức tạp.

Trích đoạn nội dung tài liệu

CÁC MÔ HÌNH DỮ LIỆU (Phần 2) 1 CÁC MÔ HÌNH DỮ LIỆU  Giới thiệu  Quá trình thiết kế một CSDL  Mô hình thực thể liên kết E-R  Một số vấn đề cần quan tâm khi thiết kế mô hình E-R  Mô hình dữ liệu quan hệ  Ánh xạ mô hình thực thể liên kết sang mô hình quan hệ 2 MỘT SỐ VẤN ĐỀ CẦN QUAN TÂM KHI THIẾT KẾ MÔ HÌNH E-R 3 ẢNH HƢỞNG CỦA ÁNH XẠ LỰC LƢỢNG LIÊN KẾT LÊN CÁC KHÓA  Cấu trúc của khóa chính cho tập các quan hệ phụ thuộc vào việc ánh xạ lực lượng liên kết. Xét lược đồ E-R sau: CUSTOMER depositor ACCOUNT access date => Lược đồ này thể hiện một quan hệ M-M cho quan hệ depositor với thuộc tính access-date liên quan tới tập quan hệ giữa hai thực thể CUSTOMER và ACCOUNT. Khóa chính của quan hệ này sẽ bao gồm hợp của các khóa chính của hai tập thực thể CUSTOMER và ACCOUNT. 4 ẢNH HƢỞNG CỦA ÁNH XẠ LỰC LƢỢNG LIÊN KẾT LÊN CÁC KHÓA (Cont.)  Để rõ hơn, xét lược đồ dữ liệu của hai tập thực thể: CUSTOMER (customer-id, customer-name, address, city) ACCOUNT (account-number, balance)  Quan hệ M-M giữa hai tập thực thể CUSTOMER và ACCOUNT nghĩa là: một khách hàng có thể có nhiều tài khoản, và tương tự một tài khoản có thể được quản lý bởi nhiều khách hàng.

 Phép hợp các khóa chính của cả hai tập thực thể CUSTOMER và ACCOUNT sẽ xác định duy nhất một quan hệ giữa hai thực thể trong CUSTOMER và ACCOUNT. 5 ẢNH HƢỞNG CỦA ÁNH XẠ LỰC LƢỢNG LIÊN KẾT LÊN CÁC KHÓA (Cont.)  Để nhìn thấy lần nộp tiền cuối cùng (last deposit) vào một tài khoản cụ thể nào đó, cần xác định người nộp tiền vì với mỗi tài khoản có thể có một số người nộp tiền vào.  Lược đồ cho mối quan hệ depositor như sau: Depositor (customer-id, account-number, access-date). 6 ẢNH HƢỞNG CỦA ÁNH XẠ LỰC LƢỢNG LIÊN KẾT LÊN CÁC KHÓA (Cont.)  Xét trường hợp một khách hàng chỉ được phép nộp tiền vào một tài khoản duy nhất.

=> quan hệ depositor là M:1 từ CUSTOMER tới ACCOUNT: CUSTOMER depositor ACCOUNT access date => Khóa chính của quan hệ depositor sẽ chỉ bao gồm khóa chính của tập thực thể CUSTOMER. 7 ẢNH HƢỞNG CỦA ÁNH XẠ LỰC LƢỢNG LIÊN KẾT LÊN CÁC KHÓA (Cont.)  Để rõ hơn, xét lược đồ dữ liệu của hai tập thực thể: CUSTOMER (customer-id, customer-name, address, city) ACCOUNT (account-number, balance)  Quan hệ M:1 nghĩa là một khách hàng chỉ có duy nhất một tài khoản. Như vậy, việc chỉ ra số tài khoản đó là không cần thiết.  Khóa chính của quan hệ depositor chỉ đơn giản là khóa chính của thực thể CUSTOMER.

Một khách hàng xác định chỉ có thể thực hiện một lần nộp tiền gần nhất tới tài khoản duy nhất họ có thể truy nhập.  Lược đồ của tập các quan hệ depositor như sau: Depositor (customer-id, access-date) 8 ẢNH HƢỞNG CỦA ÁNH XẠ LỰC LƢỢNG LIÊN KẾT LÊN CÁC KHÓA (Cont.)  Xét trường hợp quan hệ depositor là M:1 từ ACCOUNT tới CUSTOMER, nghĩa là: mỗi tài khoản được làm chủ bởi nhiều nhất là một khách hàng nhưng mỗi khách hàng có thể có nhiều hơn một tài khoản. CUSTOMER depositor ACCOUNT access date 9 ẢNH HƢỞNG CỦA ÁNH XẠ LỰC LƢỢNG LIÊN KẾT LÊN CÁC KHÓA (Cont.) => Trong trường hợp này, khóa chính của quan hệ depositor chỉ đơn giản bao gồm khóa chính của thực thể ACCOUNT vì chỉ có thể có nhiều nhất một lần nộp tiền gần nhất tới một tài khoản nào đó xác định, và chỉ có nhiều nhất một khách hàng có thể thực hiện việc nộp tiền. Không cần xác định khách hàng nào đã thực hiện nộp tiền vì chỉ có thể có một và chỉ một khách hàng có khả năng nộp tiền vào một tài khoản xác định.

 Lược đồ cho mối quan hệ depositor như sau: Depositor (account-number, access-date) 10 ĐẶT VỊ TRÍ CHO CÁC THUỘC TÍNH CỦA QUAN HỆ  Các thuộc tính của một tập quan hệ dạng 1:1 hoặc 1:M thường được đặt vào trong các tập thực thể tham gia liên kết, hơn là được đặt vào bản thân tập các mối quan hệ đó.  Ví dụ, với quan hệ depositor: CUSTOMER depositor ACCOUNT access date 11 ĐẶT VỊ TRÍ CHO CÁC THUỘC TÍNH CỦA QUAN HỆ (Cont.)  Thuộc tính access-date có thể được đặt liên quan tới thực thể ACCOUNT mà không làm tổn thất thông tin: CUSTOMER depositor ACCOUNT access date => Vì một tài khoản cụ thể thuộc sở hữu bởi nhiều nhất là một khách hàng, và tài khoản đó có thể có nhiều nhất một access- date. 12 ĐẶT VỊ TRÍ CHO CÁC THUỘC TÍNH CỦA QUAN HỆ (Cont.)  Xét trường hợp: một tài khoản được làm chủ bởi nhiều nhất một khách hàng và một khách hàng chỉ có thể sở hữu duy nhất một tài khoản. CUSTOMER depositor ACCOUNT access date => Thuộc tính access-date có thể gắn vào hoặc thực thể CUSTOMER hoặc tập thực thể ACCOUNT mà không làm tổn thất thông tin.

13 ĐẶT VỊ TRÍ CHO CÁC THUỘC TÍNH CỦA QUAN HỆ (Cont.)  Nếu thuộc tính access-date được lưu trữ với tập CUSTOMER thì nó phải tham chiếu tới lần truy nhập cuối cùng của khách hàng tới tài khoản duy nhất mà họ có. CUSTOMER depositor ACCOUNT access date  Nếu thuộc tính access-date được lưu trữ trong thực thể ACCOUNT thì nó sẽ tham chiếu tới lần truy nhập cuối cùng tới tài khoản bởi người khách hàng duy nhất sở hữu nó. CUSTOMER depositor ACCOUNT access date 14 ĐẶT VỊ TRÍ CHO CÁC THUỘC TÍNH CỦA QUAN HỆ (Cont.)  Xét trường hợp: quan hệ depositor có ràng buộc N:N CUSTOMER depositor ACCOUNT access date => Việc gắn thuộc tính access-date với bất kỳ tập thực thể tham gia nào cũng không mô hình hóa được tình huống này mà không làm tổn thất thông tin. 15 ĐẶT VỊ TRÍ CHO CÁC THUỘC TÍNH CỦA QUAN HỆ (Cont.)  Nếu cần lưu trữ ngày truy nhập cuối cùng của một khách hàng cụ thể tới một tài khoản cụ thể thì thuộc tính access-date nhất thiết phải là một thuộc tính của tập quan hệ depositor, chứ không thể là thuộc tính của bất kỳ tập thực thể tham gia nào.

• Nếu access-date là một thuộc tính của ACCOUNT thì không thể xác định được khách hàng nào đã thực hiện việc chuyển tiền vào tài khoản đó. • Còn nếu access-date là một thuộc tính của CUSTOMER, thì cũng không thể xác định được tài khoản nào khách hàng đã truy nhập vào lần cuối. 16 TẬP THỰC THỂ HAY CÁC THUỘC TÍNH  Xét một tập thực thể: EMPLOYEE(emp-name, telephone-number, age)  Nếu máy điện thoại telephone có thể được coi là một thực thể (với các thuộc tính telephone-number, location, manufacturer, serial-num,. Thực thể EMPLOYEE phải được định nghĩa lại như sau: EMPLOYEE (emp-name, age).

Sau đó phải tạo ra một tập thực thể mới: TELEPHONE (telephone-number, location, manufacturer, serial- num,. Và phải tạo ra một tập các mối quan hệ để xác định mối liên hệ giữa các nhân viên và các máy điện thoại mà họ sở hữu: EMP-PHONE(emp-name, telephone-number, age, location, manufacturer, serial-num,. 17 TẬP THỰC THỂ HAY CÁC THUỘC TÍNH (Cont.)  Trong trường hợp mỗi nhân viên có một số điện thoại => coi máy điện thoại như một thuộc tính telephone-number.  Trong trường hợp các nhân viên có thể sở hữu nhiều điện thoại => coi máy điện thoại như một thực thể (không xét đến trường hợp thuộc tính là đa trị).

=> Sự phân biệt 2 vai trò thực thể và thuộc tính phụ thuộc vào cấu trúc ngữ cảnh trong thế giới thực cần mô hình hóa dữ liệu và dựa vào ngữ nghĩa liên quan đến các thuộc tính trong bài toán cụ thể. 18 TẬP THỰC THỂ HAY TẬP QUAN HỆ  Xét ví dụ ngân hàng: đã mô hình hóa khoản vay như một thực thể (LOAN). => Cách khác: có thể mô hình hóa khoản vay như một mối quan hệ giữa khách khàng (CUSTOMER) và các chi nhánh (BRANCHES) của ngân hàng với loan-number và amount là các thuộc tính mô tả. 19 TẬP THỰC THỂ HAY TẬP QUAN HỆ (Cont.)  Việc mô hình hóa theo cách trên không thuận lợi trong tình huống nhiều khách hàng cùng sở hữu chung một khoản vay.

=> Cần định nghĩa các mối quan hệ riêng cho từng người sở hữu khoản vay chung. Sau đó, dùng lại tất cả các giá trị cho các thuộc tính loan-number và amount trong mỗi quan hệ này (hiển nhiên, các quan hệ phải có cùng giá trị cho các thuộc tính mô tả).  Có 2 vấn đề phát sinh khi dùng lặp lại các giá trị: 1. Dữ liệu được lưu trữ ở nhiều nơi.

Việc cập nhật dữ liệu làm tăng khả năng không nhất quán dữ liệu. 20 TẬP THỰC THỂ MẠNH HAY TẬP THỰC THỂ YẾU  Tập thực thể không đủ các thuộc tính để hình thành một khóa chính gọi là tập thực thể yếu. Tập thực thể có khóa chính được gọi là tập thực thể mạnh.  Ví dụ: Xét tập thực thể trả tiền: PAYMENT(payment-number, payment date, payment amount).

=> Mã số trả tiền (payment-number) thường là các số liên tiếp, bắt đầu từ 1 và được sinh ra riêng rẽ cho mỗi khoản nợ. Do đó, mặc dù mỗi thực thể PAYMENT là khác nhau, việc trả tiền cho các khoản nợ khác nhau có thể có cùng mã số payment-number. => tập PAYMENT không có khóa chính và chỉ là một tập thực thể yếu. 21 TẬP THỰC THỂ MẠNH HAY TẬP THỰC THỂ YẾU (Cont.)  Để một tập thực thể yếu có ý nghĩa, nó phải liên hệ với một tập thực thể khác, được gọi là tập thực thể xác định hay tập thực thể sở hữu.

 Mối quan hệ giữa tập thực thể yếu với tập thực thể xác định được gọi là mối quan hệ xác định.  Mối quan hệ xác định là quan hệ M:1 từ tập thực thể yếu tới tập xác định và sự tham gia của tập thực thể yếu trong quan hệ là đầy đủ. 22 TẬP THỰC THỂ MẠNH HAY TẬP THỰC THỂ YẾU (Cont.)  Mặc dù tập thực thể yếu không có khóa chính, nhưng có một phương thức để phân biệt tất cả các thực thể trong tập thực thể yếu phụ thuộc vào một thực thể mạnh cụ thể. => Tập các thuộc tính của một thực thể yếu cho phép phân biệt các thực thể được gọi là thuộc tính phân biệt (hay khóa bán phần).

Ví dụ: Thuộc tính phân biệt của tập thực thể yếu PAYMENT là payment-number, vì với mỗi khoản nợ, một mã số trả tiền sẽ xác định duy nhất một lần trả tiền riêng biệt cho khoản nợ này. 23 TẬP THỰC THỂ MẠNH HAY TẬP THỰC THỂ YẾU (Cont.)  Khóa chính của một tập thực thể yếu được cấu thành bởi khóa chính của tập thực thể xác định và thuộc tính phân biệt của tập thực thể yếu.