Chương 3: Mô hình hóa bằng mô hình thực thể - mối quan hệ (ER)

Nội dung bài viết

Mô hình hóa khái niệm là một giai đoạn rất quan trọng trong việc thiết kế một ứng dụng cơ sở dữ liệu thành công. Thông thường, thuật ngữ ứng dụng cơ sở dữ liệu đề cập đến một cơ sở dữ liệu cụ thể và các chương trình liên quan thực hiện các truy vấn và cập nhật cơ sở dữ liệu. Ví dụ, một ứng dụng cơ sở dữ liệu NGÂN HÀNG theo dõi tài khoản khách hàng sẽ bao gồm các chương trình thực hiện cập nhật cơ sở dữ liệu tương ứng với tiền gửi và rút tiền của khách hàng. Các chương trình này sẽ cung cấp giao diện người dùng với đồ họa thân thiện với người dùng (GUI) sử dụng các biểu mẫu và menu cho người dùng cuối của ứng dụng — họ có thể là khách hàng của ngân hàng hoặc giao dịch viên ngân hàng trong ví dụ này. Ngoài ra, hiện nay việc cung cấp giao diện các chương trình này cho khách hàng của BANK thông qua thiết bị di động sử dụng ứng dụng di động đã trở nên phổ biến. Do đó, một phần chính của ứng dụng cơ sở dữ liệu sẽ yêu cầu thiết kế, triển khai và thử nghiệm các chương trình ứng dụng này. Theo truyền thống, thiết kế và thử nghiệm các chương trình ứng dụng được coi là một phần của quy trình phát triển phần mềm hơn là thiết kế cơ sở dữ liệu. Trong nhiều công cụ thiết kế phần mềm, phương pháp luận thiết kế cơ sở dữ liệu và phương pháp luận kỹ thuật phần mềm được kết hợp chặt chẽ với nhau vì các hoạt động này có liên quan chặt chẽ với nhau. 

Trong chương này, chúng ta thực hiện theo cách tiếp cận truyền thống là tập trung vào các cấu trúc cơ sở dữ liệu và các ràng buộc trong quá trình thiết kế cơ sở dữ liệu ở mức khái niệm. Việc thiết kế các chương trình ứng dụng thường được đề cập trong các bài về kỹ thuật phần mềm. Chúng ta trình bày các khái niệm mô hình hóa của mô hình mối quan hệ-thực thể (ER), đây là một mô hình dữ liệu khái niệm cấp cao phổ biến. Mô hình này và các biến thể của nó thường được sử dụng cho thiết kế khái niệm của các ứng dụng cơ sở dữ liệu và nhiều công cụ thiết kế cơ sở dữ liệu sử dụng các khái niệm của nó. Chúng ta mô tả các khái niệm cấu trúc dữ liệu cơ bản và các kết cấu của mô hình ER và thảo luận về việc sử dụng chúng trong việc thiết kế các lược đồ khái niệm cho các ứng dụng cơ sở dữ liệu. Chúng ta cũng trình bày ký hiệu sơ đồ liên quan đến mô hình ER, được gọi là sơ đồ ER. 

Các phương pháp lập mô hình đối tượng như Ngôn ngữ mô hình hóa (UML) đang ngày càng trở nên phổ biến trong cả thiết kế cơ sở dữ liệu và phần mềm. Các phương pháp luận này vượt ra ngoài thiết kế cơ sở dữ liệu để chỉ định thiết kế chi tiết của các mô-đun phần mềm và tương tác của chúng bằng cách sử dụng các loại sơ đồ khác nhau. Một phần quan trọng của các phương pháp luận này — cụ thể là sơ đồ lớp — có nhiều cách tương tự như sơ đồ ER. Trong biểu đồ lớp, các hoạt động trên các đối tượng được chỉ định, ngoài việc chỉ định cấu trúc lược đồ cơ sở dữ liệu. Các phép toán có thể được sử dụng để xác định các yêu cầu chức năng trong quá trình thiết kế cơ sở dữ liệu. 

1. Sử dụng mô hình dữ liệu khái niệm cấp cao để thiết kế cơ sở dữ liệu

Hình 3.1 cho thấy một cái nhìn tổng quan đơn giản hóa của quá trình thiết kế cơ sở dữ liệu. Bước đầu tiên được hiển thị là thu thập và phân tích yêu cầu. Trong bước này, các nhà thiết kế cơ sở dữ liệu phỏng vấn những người dùng cơ sở dữ liệu tiềm năng để hiểu và ghi lại các yêu cầu dữ liệu của họ. Kết quả của bước này là một tập hợp các yêu cầu của người dùng được viết ngắn gọn. Các yêu cầu này phải được quy định trong biểu mẫu càng chi tiết và đầy đủ càng tốt. Song song với việc xác định các yêu cầu dữ liệu, rất hữu ích khi chỉ định các yêu cầu chức năng đã biết của ứng dụng. Chúng bao gồm các hoạt động (hoặc giao dịch) do người dùng xác định sẽ được áp dụng cho cơ sở dữ liệu, bao gồm cả truy xuất và cập nhật. Trong thiết kế phần mềm, người ta thường sử dụng khái niệm luồng dữ liệu (data flow), lưu đồ, use case và các kỹ thuật khác để xác định các yêu cầu chức năng. Chúng ta sẽ không thảo luận về bất kỳ kỹ thuật nào ở đây; chúng thường được mô tả chi tiết trong các tài liệu liên quan về kỹ thuật phần mềm. 

Khi các yêu cầu đã được thu thập và phân tích, bước tiếp theo là tạo một lược đồ khái niệm cho cơ sở dữ liệu, sử dụng mô hình dữ liệu khái niệm mức cao. Bước này được gọi là thiết kế khái niệm. Lược đồ khái niệm là một mô tả ngắn gọn về các yêu cầu dữ liệu của người dùng và bao gồm các mô tả chi tiết về các loại thực thể, các mối quan hệ và các ràng buộc; những điều này được thể hiện bằng cách sử dụng các khái niệm được cung cấp bởi mô hình dữ liệu cấp cao. Bởi vì những khái niệm này không đề cập quá chi tiết, chúng thường dễ hiểu hơn và có thể được sử dụng để giao tiếp với người dùng không hiểu nhiều về kỹ thuật. Lược đồ khái niệm cấp cao cũng có thể được sử dụng làm tài liệu tham khảo để đảm bảo rằng tất cả các yêu cầu dữ liệu của người dùng đều được đáp ứng và các yêu cầu đó không xung đột. Cách tiếp cận này cho phép các nhà thiết kế cơ sở dữ liệu tập trung vào việc xác định các thuộc tính của dữ liệu mà không cần quan tâm đến chi tiết lưu trữ và triển khai, điều này giúp dễ dàng hơn trong việc tạo ra một thiết kế cơ sở dữ liệu liên thông tốt. 

Trong hoặc sau khi thiết kế lược đồ khái niệm, các hoạt động của mô hình dữ liệu cơ bản có thể được sử dụng để chỉ định các truy vấn người dùng cấp cao và các hoạt động được xác định trong quá trình phân tích chức năng. Điều này cũng phục vụ để xác nhận rằng lược đồ khái niệm đáp ứng tất cả các yêu cầu chức năng đã xác định. Các sửa đổi đối với lược đồ khái niệm có thể được đưa ra nếu một số yêu cầu chức năng không thể được chỉ định bằng cách sử dụng lược đồ ban đầu. 

Bước tiếp theo trong thiết kế cơ sở dữ liệu là triển khai thực tế cơ sở dữ liệu, sử dụng DBMS thương. Hầu hết các DBMS hiện tại sử dụng mô hình dữ liệu triển khai — chẳng hạn như mô hình quan hệ (SQL) — vì vậy lược đồ khái niệm được chuyển đổi từ mô hình dữ liệu cấp cao thành mô hình dữ liệu triển khai. Bước này được gọi là thiết kế logic hoặc ánh xạ mô hình dữ liệu; kết quả của nó là một lược đồ cơ sở dữ liệu trong mô hình dữ liệu triển khai của DBMS. Ánh xạ mô hình dữ liệu thường được tự động hóa hoặc bán tự động hóa trong các công cụ thiết kế cơ sở dữ liệu. 

Bước cuối cùng là giai đoạn thiết kế vật lý, trong đó các cấu trúc lưu trữ nội bộ, tổ chức tệp, chỉ mục, đường dẫn truy cập và các tham số thiết kế vật lý cho tệp cơ sở dữ liệu được chỉ định. Song song với các hoạt động này, các ứng dụng lập trình được thiết kế và triển khai dưới dạng các giao dịch cơ sở dữ liệu tương ứng

2. Một ứng dụng cơ sở dữ liệu mẫu

Trong phần này, chúng ta mô tả một ứng dụng cơ sở dữ liệu mẫu, được gọi là COMPANY, dùng để minh họa các khái niệm mô hình ER cơ bản và việc sử dụng chúng trong thiết kế lược đồ. Chúng ta liệt kê các yêu cầu dữ liệu cho cơ sở dữ liệu ở đây, sau đó tạo lược đồ khái niệm của nó từng bước khi chúng ta giới thiệu các khái niệm mô hình hóa của mô hình ER. Cơ sở dữ liệu COMPANY theo dõi các nhân viên, phòng ban và dự án của công ty. Giả sử rằng sau giai đoạn thu thập và phân tích yêu cầu, các nhà thiết kế cơ sở dữ liệu cung cấp mô tả sau đây về thế giới nhỏ — bộ phận của công ty sẽ được đại diện trong cơ sở dữ liệu 

• Công ty được tổ chức thành các phòng ban. Mỗi bộ phận có một tên riêng, một số duy nhất và một nhân viên cụ thể quản lý việc vận hành. Chúng tôi theo dõi ngày bắt đầu khi nhân viên đó bắt đầu quản lý bộ phận. Một bộ phận có thể có một số địa điểm. 

• Một bộ phận kiểm soát một số dự án, mỗi dự án có một tên riêng, một số duy nhất và một vị trí duy nhất 

• Cơ sở dữ liệu sẽ lưu trữ tên, số định danh, địa chỉ, mức lương, giới tính (giới tính) và ngày sinh của mỗi nhân viên. Một nhân viên được chỉ định vào một bộ phận, nhưng có thể làm việc trong một số dự án, mà không nhất thiết phải được kiểm soát bởi cùng một bộ phận. Cần phải theo dõi số giờ thuê mỗi tuần mà một nhân viên làm việc trong mỗi dự án, cũng như người giám sát trực tiếp của mỗi nhân viên (là một nhân viên khác). 

• Cơ sở dữ liệu sẽ theo dõi những người phụ thuộc của từng nhân viên cho các mục đích bảo đảm, bao gồm tên, giới tính, ngày sinh và mối quan hệ của từng người phụ thuộc với nhân viên 

Hình 3.2 cho thấy cách lược đồ cho ứng dụng cơ sở dữ liệu này có thể được hiển thị bằng ký hiệu đồ họa được gọi là sơ đồ ER. Hình này sẽ được giải thích dần dần khi các khái niệm về mô hình ER được trình bày. Chúng ta mô tả quy trình từng bước để lấy được giản đồ này từ các yêu cầu đã nêu — và giải thích ký hiệu sơ đồ ER — khi chúng ta giới thiệu các khái niệm về mô hình ER  

3. Các loại thực thể, tập thực thể, thuộc tính và khóa

Mô hình ER mô tả dữ liệu dưới dạng thực thể, mối quan hệ và thuộc tính. 

3.1 Thực thể và thuộc tính 

Mô hình ER mô tả dữ liệu dưới dạng thực thể, Thực thể và Thuộc tính của Chúng. Khái niệm cơ bản mà mô hình ER đại diện là một thực thể, là một sự vật hoặc đối tượng trong thế giới thực với sự tồn tại độc lập. Một thực thể có thể là một đối tượng có tồn tại vật chất (ví dụ: một cụ thể cho mỗi con trai, xe hơi, ngôi nhà hoặc nhân viên) hoặc nó có thể là một đối tượng có tồn tại khái niệm (ví dụ: một công ty, một công việc hoặc một trường đại học khóa học). Mỗi thực thể có các thuộc tính — các thuộc tính cụ thể mô tả nó. Ví dụ: thực thể NHÂN VIÊN có thể được mô tả bằng tên, tuổi, địa chỉ, mức lương và công việc của nhân viên. Một mối quan hệ thực thể cụ thể và các thuộc tính sẽ có giá trị cho mỗi thuộc tính của nó. Các giá trị thuộc tính mô tả mỗi thực thể trở thành một phần chính của dữ liệu được lưu trữ trong cơ sở dữ liệu. 

Hình 3.3 cho thấy hai thực thể và giá trị của các thuộc tính của chúng. Thực thể EMPLOYEE e1 có bốn thuộc tính: Tên, Địa chỉ, Tuổi và Số điện thoại nhà; giá trị của chúng lần lượt là ‘John Smith,’ ‘2311 Kirby, Houston, Texas 77001’, ‘55’ và ‘713-749-2630’. Thực thể COMPANY c1 có ba thuộc tính: Tên, Trụ sở chính và Chủ tịch; giá trị của chúng lần lượt là ‘Sunco Oil’, ‘Houston’ và ‘John Smith’ 

Một số loại thuộc tính xuất hiện trong mô hình ER:  thuộc tính đơn, đơn giá trị, đa giá trị, dẫn xuất. Đầu tiên, chúng ta xác định các loại thuộc tính này và minh họa việc sử dụng chúng qua các ví dụ. Sau đó, chúng ta thảo luận về khái niệm giá trị NULL cho một thuộc tính. 

Thuộc tính phức hợp. Các thuộc tính tổng hợp có thể được chia thành các phần con nhỏ hơn, đại diện cho các thuộc tính cơ bản hơn với ý nghĩa sâu sắc. Ví dụ: thuộc tính Address của thực thể EMPLOYEE được hiển thị trong Hình 3.3 có thể được chia nhỏ thành Street_address, City, State và Zip, với các giá trị ‘2311 Kirby’, ‘Houston’, ‘Texas’ và ‘77001’. Các thuộc tính không chia hết được gọi là các thuộc tính đơn giản hoặc nguyên tử. Các thuộc tính tổng hợp có thể tạo thành một hệ thống phân cấp; ví dụ, Street_address có thể được chia nhỏ hơn nữa thành ba thuộc tính thành phần đơn giản: Number, Street và Apartment_number, như trong Hình 3.4. Giá trị của một thuộc tính hỗn hợp là sự ghép nối các giá trị của các thuộc tính đơn giản thành phần của nó 

Thuộc tính tổng hợp rất hữu ích cho các tình huống mô hình trong đó người dùng đôi khi đề cập đến thuộc tính kết hợp như một đơn vị nhưng những lúc khác lại đề cập cụ thể đến các thành phần của nó. Nếu thuộc tính tổng hợp chỉ được tham chiếu tổng thể, thì không cần phải chia nhỏ nó thành các thuộc tính thành phần. Ví dụ: nếu không cần tham chiếu đến các thành phần riêng lẻ của một địa chỉ (Mã Zip, đường phố, v.v.), thì toàn bộ địa chỉ có thể được chỉ định là một thuộc tính đơn giản 

Thuộc tính đa trị. Hầu hết các thuộc tính có một giá trị duy nhất cho một thực thể cụ thể; các thuộc tính như vậy được gọi là giá trị đơn. Ví dụ: Tuổi là một thuộc tính có giá trị duy nhất của một người. Trong một số trường hợp, một thuộc tính có thể có một bộ giá trị cho cùng một thực thể, chẳng hạn như thuộc tính Colors cho ô tô hoặc thuộc tính College_degrees cho một người. Ô tô có một màu có một giá trị duy nhất, trong khi ô tô hai tông màu có hai giá trị màu. Tương tự, một người có thể không có bất kỳ bằng đại học nào, người khác có thể có một, và người thứ ba có thể có hai hoặc nhiều bằng cấp; do đó, những người khác nhau có thể có số lượng giá trị khác nhau cho thuộc tính College_degrees. Các thuộc tính như vậy được gọi là đa giá trị. Thuộc tính nhiều giá trị có thể có giới hạn thấp hơn và giới hạn trên để hạn chế số lượng giá trị được phép cho từng thực thể riêng lẻ. Ví dụ: thuộc tính Màu sắc của ô tô có thể bị hạn chế có từ một đến hai giá trị, nếu chúng tôi giả định rằng ô tô có thể có tối đa hai màu 

Thuộc tính dẫn xuất. Trong một số trường hợp, hai (hoặc nhiều) giá trị thuộc tính có liên quan với nhau — ví dụ: thuộc tính Tuổi và Ngày sinh của một người. Đối với một thực thể người cụ thể, giá trị của Tuổi có thể được xác định từ ngày hiện tại (hôm nay) và giá trị của Ngày sinh của người đó. Do đó, thuộc tính Age được gọi là thuộc tính có nguồn gốc và được cho là có thể dẫn xuất từ thuộc tính Birth_date, được gọi là thuộc tính được lưu trữ. Một số giá trị thuộc tính có thể được bắt nguồn từ các thực thể có liên quan; ví dụ: thuộc tính Number_of_employees của một thực thể DEPARTMENT có thể được lấy bằng cách đếm số lượng nhân viên liên quan đến (làm việc cho) bộ phận đó 

Giá trị NULL. Trong một số trường hợp, một thực thể cụ thể có thể không có giá trị áp dụng cho một thuộc tính. Ví dụ: thuộc tính Apartment_number của một địa chỉ chỉ áp dụng cho các địa chỉ nằm trong các tòa nhà chung cư chứ không áp dụng cho các loại nhà ở khác, chẳng hạn như nhà cho một gia đình. Tương tự, thuộc tính College_degrees chỉ áp dụng cho những người có bằng đại học. Đối với những tình huống như vậy, một giá trị đặc biệt được gọi là NULL được tạo. Địa chỉ của một ngôi nhà dành cho một gia đình sẽ có NULL cho thuộc tính Apartment_number và một người không có bằng đại học sẽ có NULL cho College_degrees. NULL cũng có thể được sử dụng nếu chúng ta không biết giá trị của một thuộc tính cho một thực thể cụ thể — ví dụ, nếu chúng ta không biết số điện thoại nhà của ‘John ​​Smith’ trong Hình 3.3. Ý nghĩa của kiểu NULL trước đây không được áp dụng, trong khi ý nghĩa của kiểu sau là không xác định. Danh mục chưa biết của NULL có thể được phân loại thêm thành hai trường hợp. Trường hợp đầu tiên phát sinh khi biết rằng giá trị thuộc tính tồn tại nhưng bị thiếu — ví dụ: nếu thuộc tính Chiều cao của một người được liệt kê là NULL. Trường hợp thứ hai phát sinh khi không biết giá trị thuộc tính có tồn tại hay không — ví dụ: nếu thuộc tính Home_phone của một người là NULL. 

Thuộc tính phức hợp. Lưu ý rằng, nói chung, các thuộc tính tổng hợp và nhiều giá trị có thể được lồng vào nhau một cách tùy ý. Chúng ta có thể biểu diễn lồng tùy ý bằng cách nhóm các thành phần của thuộc tính hỗn hợp giữa các dấu ngoặc đơn () và phân tách các thành phần bằng dấu phẩy và bằng cách hiển thị các thuộc tính nhiều giá trị giữa các dấu ngoặc nhọn {}. Các thuộc tính như vậy được gọi là thuộc tính phức hợp. Ví dụ, nếu một người có thể có nhiều nơi cư trú và mỗi nơi cư trú có thể có một địa chỉ duy nhất và nhiều điện thoại, một thuộc tính Address_phone cho một người có thể được chỉ định như trong Hình 3.5. Cả Điện thoại và Địa chỉ đều là các thuộc tính tổng hợp. 

3.2 Các loại đối tượng, nhóm đối tượng, khóa và miền giá trị

Loại thực thể và Nhóm thực thể. Cơ sở dữ liệu thường chứa các nhóm thực thể giống nhau. Ví dụ, một công ty sử dụng hàng trăm nhân viên có thể muốn lưu trữ thông tin tương tự liên quan đến từng nhân viên. Các thực thể nhân viên này chia sẻ các thuộc tính giống nhau, nhưng mỗi thực thể có (các) giá trị riêng cho từng thuộc tính. Một loại thực thể xác định một tập hợp (hoặc một tập hợp) các thực thể có các thuộc tính giống nhau. Mỗi loại thực thể trong cơ sở dữ liệu được mô tả bằng tên và thuộc tính của nó. Hình 3.6 cho thấy hai loại thực thể: NHÂN VIÊN và CÔNG TY, và danh sách một số thuộc tính cho mỗi loại. Một số thực thể riêng lẻ của mỗi loại cũng được minh họa, cùng với các giá trị thuộc tính của chúng. Tập hợp tất cả các thực thể của một loại thực thể cụ thể trong cơ sở dữ liệu tại bất kỳ thời điểm nào được gọi là tập thực thể hoặc tập hợp thực thể; tập thực thể thường được đề cập đến bằng cách sử dụng cùng tên với loại thực thể, mặc dù chúng là hai khái niệm riêng biệt. Ví dụ: EMPLOYEE đề cập đến cả một loại thực thể cũng như tập hợp hiện tại của tất cả các thực thể nhân viên trong cơ sở dữ liệu. Giờ đây, việc đặt các tên riêng biệt cho loại thực thể và tập hợp thực thể trở nên phổ biến hơn; ví dụ trong các mô hình dữ liệu quan hệ đối tượng và đối tượng 

Một kiểu thực thể được biểu diễn trong sơ đồ ER (xem Hình 3.2) dưới dạng một hộp hình chữ nhật bao quanh tên kiểu thực thể. Tên thuộc tính được đặt trong hình bầu dục và được gắn với loại thực thể của chúng bằng các đường thẳng. Các thuộc tính tổng hợp được gắn với các thuộc tính thành phần của chúng bằng các đường thẳng. Các thuộc tính nhiều giá trị được hiển thị trong hình bầu dục kép. Hình 3.7 (a) cho thấy một loại thực thể CAR trong ký hiệu này 

Một loại thực thể mô tả lược đồ hoặc số nguyên cho một tập hợp các thực thể có cùng cấu trúc. Tập hợp các thực thể của một loại thực thể cụ thể được nhóm lại thành một tập thực thể, còn được gọi là phần mở rộng của loại thực thể 

Các thuộc tính chính của một thực thể. Một ràng buộc quan trọng đối với các thực thể của một kiểu thực thể là ràng buộc về khóa hoặc tính duy nhất trên các thuộc tính. Một loại thực thể thường có một hoặc nhiều thuộc tính có giá trị khác nhau đối với từng thực thể riêng lẻ trong tập thực thể. Một thuộc tính như vậy được gọi là thuộc tính khóa và các giá trị của nó có thể được sử dụng để xác định từng thực thể duy nhất. Ví dụ, thuộc tính Name là một khóa của kiểu thực thể COMPANY trong Hình 3.6 vì không có hai công ty nào được phép có cùng tên. Đối với loại thực thể PERSON, thuộc tính khóa điển hình là Ssn (Số an sinh xã hội). Đôi khi một số thuộc tính cùng nhau tạo thành một khóa, có nghĩa là sự kết hợp của các giá trị thuộc tính phải khác biệt đối với mỗi thực thể. Nếu một tập hợp các thuộc tính sở hữu thuộc tính này, thì cách thích hợp để thể hiện điều này trong mô hình ER mà chúng tôi mô tả ở đây là xác định một thuộc tính tổng hợp và chỉ định nó làm thuộc tính khóa của loại thực thể. Lưu ý rằng một khóa tổng hợp như vậy phải là tối thiểu; nghĩa là, tất cả các thuộc tính thành phần phải được đưa vào thuộc tính tổng hợp để có thuộc tính duy nhất. Các thuộc tính thừa không được bao gồm trong một khóa. Trong ký hiệu sơ đồ ER, mỗi thuộc tính khóa có tên được gạch dưới bên trong hình bầu dục, như minh họa trong Hình 3.7 (a) 

Chỉ định rằng một thuộc tính là khóa của một loại thực thể có nghĩa là thuộc tính duy nhất trước đó phải giữ cho mọi tập thực thể của loại thực thể. Do đó, nó là một ràng buộc cấm bất kỳ hai thực thể nào có cùng giá trị cho thuộc tính khóa cùng một lúc. Nó không phải là tài sản của một tập thực thể cụ thể; đúng hơn, nó là một ràng buộc đối với bất kỳ tập thực thể nào của loại thực thể tại bất kỳ thời điểm nào. Ràng buộc chính này (và các ràng buộc khác mà chúng ta sẽ thảo luận sau) có nguồn gốc từ các ràng buộc của miniworld mà cơ sở dữ liệu đại diện 

Một số loại thực thể có nhiều hơn một thuộc tính khóa. Ví dụ, mỗi thuộc tính Vehicle_id và Registration  của loại thực thể CAR (Hình 3.7) là một khóa theo đúng nghĩa của nó. Thuộc tính Registration là một ví dụ về khóa tổng hợp được hình thành từ hai thuộc tính thành phần đơn giản, State và Number, cả hai đều không phải là khóa riêng của nó. Một loại thực thể cũng có thể không có khóa, trong trường hợp đó nó được gọi là một loại thực thể yếu 

Trong ký hiệu sơ đồ của chúng ta, nếu hai thuộc tính được gạch dưới riêng biệt, thì mỗi thuộc tính là một khóa của riêng nó. Không giống như mô hình quan hệ, không có khái niệm về khóa chính trong mô hình ER mà chúng ta trình bày ở đây; khóa chính sẽ được chọn trong quá trình ánh xạ tới một lược đồ quan hệ 

Tập giá trị (Miền) của các thuộc tính. Mỗi thuộc tính đơn giản của một loại thực thể được liên kết với một tập giá trị (hoặc miền giá trị), chỉ định tập giá trị có thể được gán cho thuộc tính đó cho từng thực thể riêng lẻ. Trong Hình 3.6, nếu phạm vi độ tuổi cho phép của nhân viên là từ 16 đến 70, chúng ta có thể chỉ định tập giá trị của thuộc tính Tuổi của EMPLOYEE là tập các số nguyên từ 16 đến 70. Tương tự, chúng ta có thể chỉ định tập giá trị đối với thuộc tính Name là tập hợp các chuỗi ký tự chữ cái được phân tách bằng ký tự trống, v.v. Các tập giá trị thường không được hiển thị trong sơ đồ ER cơ bản và tương tự như các kiểu dữ liệu cơ bản có sẵn trong hầu hết các ngôn ngữ lập trình, chẳng hạn như số nguyên, chuỗi, Boolean, float, kiểu liệt kê, dải con, v.v. Tuy nhiên, kiểu dữ liệu của các thuộc tính có thể được chỉ định trong sơ đồ lớp UML và trong các ký hiệu sơ đồ khác được sử dụng trong các công cụ thiết kế cơ sở dữ liệu. Các kiểu dữ liệu bổ sung để đại diện cho các kiểu cơ sở dữ liệu phổ biến, chẳng hạn như ngày, giờ và các khái niệm khác, cũng được sử dụng. 

Về mặt toán học, một thuộc tính A của tập thực thể E có tập giá trị là V có thể được định nghĩa là một hàm từ E đến tập lũy thừa P (V) của V: A: E → P (V) 

Chúng ta gọi giá trị của thuộc tính A cho thực thể e là A (e). Định nghĩa trước đây bao gồm cả thuộc tính đơn giá trị và nhiều giá trị, cũng như NULL. Giá trị NULL được đại diện bởi tập hợp trống. Đối với các thuộc tính đơn giá trị, A (e) bị hạn chế là một tập đơn lẻ cho mỗi thực thể e trong E, trong khi không có hạn chế đối với các thuộc tính nhiều giá trị. Đối với thuộc tính tổng hợp A, tập giá trị V là tập lũy thừa của tích Descartes của P (V1), P (V2) ,. . . , P (Vn), trong đó V1, V2 ,. . . , Vn là các tập giá trị của các thuộc tính thành phần đơn giản tạo thành A 

V = P(P(V1) × P(V2) × . . . × P(Vn)) 

Bộ giá trị cung cấp tất cả các giá trị có thể có. Thông thường chỉ có một số lượng nhỏ các giá trị này tồn tại trong cơ sở dữ liệu tại một thời điểm cụ thể. Những giá trị đó đại diện cho dữ liệu từ trạng thái hiện tại của miniworld và tương ứng với dữ liệu khi nó thực sự tồn tại trong miniworld. 

3.3 Thiết kế khái niệm ban đầu của Cơ sở dữ liệu COMPANY 

Bây giờ chúng ta có thể xác định các loại thực thể cho cơ sở dữ liệu COMPANY, dựa trên các yêu cầu được mô tả trong Phần 3.2. Sau khi xác định một số loại thực thể và các thuộc tính của chúng ở đây, chúng tôi tinh chỉnh thiết kế của mình trong Phần 3.4 sau khi chúng tôi giới thiệu khái niệm về mối quan hệ. Theo các yêu cầu được liệt kê trong Phần 3.2, chúng tôi có thể xác định bốn loại thực thể — một loại tương ứng với mỗi mục trong số bốn mục trong đặc điểm kỹ thuật 

• Một loại thực thể DEPARTMENT với các thuộc tính Tên, Số, Vị trí, Người quản lý và Người quản lý ngày_tháng. Vị trí là thuộc tính đa giá trị duy nhất. Chúng tôi có thể chỉ định rằng cả Tên và Số đều là thuộc tính khóa (riêng biệt) vì mỗi thuộc tính được chỉ định là duy nhất 

• Một loại thực thể DỰ ÁN với các thuộc tính Tên, Số, Vị trí và Bộ phận điều khiển. Cả Tên và Số đều là các thuộc tính khóa (riêng biệt). 

• Loại thực thể NHÂN VIÊN với các thuộc tính Tên, Ssn, Giới tính, Địa chỉ, Mức lương, Ngày sinh, Phòng ban và Người giám sát. Cả Tên và Địa chỉ đều có thể là các thuộc tính tổng hợp; tuy nhiên, điều này không được chỉ định trong các yêu cầu. Chúng tôi phải quay lại với người dùng để xem liệu có bất kỳ người nào trong số họ sẽ tham chiếu đến các thành phần riêng lẻ của Tên — First_name, Middle_initial, Last_name — hoặc Address hay không. Trong ví dụ của chúng tôi, Tên được mô hình hóa dưới dạng thuộc tính tổng hợp, trong khi Địa chỉ thì không, có lẽ là sau khi tham khảo ý kiến của người dùng 

• Loại thực thể DEPENDENT với các thuộc tính Nhân viên, Tên_người phụ thuộc, Giới tính, Ngày sinh và Mối quan hệ (với nhân viên) 

4. Các loại quan hệ, tập hợp quan hệ, vai trò và ràng buộc cấu trúc 

Trong Hình 3.8 có một số mối quan hệ ngầm giữa các loại thực thể khác nhau. Trên thực tế, bất cứ khi nào một thuộc tính của một loại thực thể này tham chiếu đến một loại thực thể khác, thì mối quan hệ nào đó sẽ tồn tại. Ví dụ, thuộc tính Manager of DEPARTMENT đề cập đến một nhân viên quản lý bộ phận; thuộc tính Control_department of PROJECT đề cập đến bộ phận kiểm soát dự án; thuộc tính Người giám sát của NHÂN VIÊN đề cập đến một nhân viên khác (người giám sát nhân viên này); thuộc tính Department of EMPLOYEE đề cập đến bộ phận mà nhân viên đó làm việc; và như thế. Trong mô hình ER, các tham chiếu này không được biểu diễn dưới dạng các thuộc tính mà là các mối quan hệ. Lược đồ cơ sở dữ liệu COMPANY ban đầu từ Hình 3.8 sẽ được tinh chỉnh trong Phần 3.6 để biểu diễn các mối quan hệ một cách rõ ràng. Trong thiết kế ban đầu của các loại thực thể, các mối quan hệ thường được ghi lại dưới dạng các thuộc tính. Khi thiết kế được tinh chỉnh, các thuộc tính này được chuyển đổi thành các mối quan hệ giữa các loại thực thể. 

4.1 Các loại quan hệ, tập hợp quan hệ và thể hiện

Một kiểu quan hệ R trong số n kiểu thực thể E1, E2 ,. . . , En định nghĩa một tập hợp các liên kết — hoặc một tập mối quan hệ — giữa các thực thể từ các kiểu thực thể này. Tương tự như trường hợp của kiểu thực thể và tập thực thể, kiểu quan hệ và tập quan hệ quan hệ tương ứng của nó thường được gọi chung bằng tên, R. Về mặt toán học, tập quan hệ R là tập hợp các thể hiện quan hệ ri, trong đó mỗi ri liên kết với n thực thể riêng lẻ (e1, e2,.., en), và mỗi thực thể ej trong ri là một thành viên của tập thực thể Ej, 1 ≤ j ≤ n. Do đó, một tập hợp quan hệ là một quan hệ toán học trên E1, E2 ,. . . , En; cách khác, nó có thể được định nghĩa như một tập con của tích Descartes của các tập thực thể E1 × E2 ×. . . × En. Mỗi loại thực thể E1, E2 ,. . . , En được cho là tham gia vào kiểu quan hệ R; tương tự, mỗi thực thể riêng lẻ e1, e2 ,. . . , en được cho là tham gia vào cá thể quan hệ ri = (e1, e2,..., en) 

Một cách không chính thức, mỗi cá thể quan hệ ri trong R là một liên kết của các thực thể, trong đó liên kết bao gồm chính xác một thực thể từ mỗi loại thực thể tham gia. Mỗi cá thể mối quan hệ như vậy ri đại diện cho thực tế rằng các thực thể tham gia vào ri có liên quan theo một cách nào đó trong tình huống miniworld tương ứng. Ví dụ: hãy xem xét kiểu quan hệ WORKS_FOR giữa hai loại thực thể 

Một cách đơn giản, mỗi cá thể quan hệ ri trong R là một liên kết của các thực thể, trong đó liên kết bao gồm chính xác một thực thể từ mỗi loại thực thể tham gia. Mỗi cá thể mối quan hệ như vậy ri đại diện cho thực tế rằng các thực thể tham gia vào ri có liên quan theo một cách nào đó trong tình huống miniworld tương ứng. Ví dụ: hãy xem xét loại quan hệ WORKS_FOR giữa hai loại thực thể EMPLOYEE và DEPARTMENT, liên kết mỗi nhân viên với bộ phận mà nhân viên đó làm việc. Mỗi cá thể mối quan hệ trong tập hợp quan hệ WORKS_FOR liên kết một thực thể NHÂN VIÊN và một thực thể BỘ PHẬN. Hình 3.9 minh họa ví dụ này, trong đó mỗi cá thể mối quan hệ ri được hiển thị kết nối với các thực thể NHÂN VIÊN và BỘ PHẬN tham gia vào ri. Trong thế giới nhỏ được đại diện bởi Hình 3.9, các nhân viên e1, e3 và e6 làm việc cho bộ phận d1; các nhân viên e2 và e4 làm việc cho bộ phận d2; và các nhân viên e5 và e7 làm việc cho bộ phận d3. 

Trong sơ đồ ER, các kiểu quan hệ được hiển thị dưới dạng các hộp hình thoi, được nối bằng các đường thẳng với các hộp hình chữ nhật đại diện cho các kiểu thực thể tham gia. Tên mối quan hệ được hiển thị trong hộp hình thoi (xem Hình 3.2) 

4.2 Bậc của mối liên kết, vai trò trong mối liên kế và quan hệ đệ quy

Bậc của mối liên kết. Mức độ của một kiểu quan hệ là số lượng các kiểu thực thể tham gia. Do đó, mối quan hệ WORKS_FOR ở mức độ hai. Loại mối quan hệ của bậc hai được gọi là nhị phân và một trong bậc ba được gọi là bậc ba. Một ví dụ về mối quan hệ bậc ba là SUPPLY, được hiển thị trong Hình 3.10, trong đó mỗi cá thể mối quan hệ ri liên kết ba thực thể — một nhà cung cấp s, một phần p và một dự án j — bất cứ khi nào s cung cấp phần p cho dự án j. Các mối quan hệ nói chung có thể ở bất kỳ mức độ nào, nhưng những mối quan hệ phổ biến nhất là mối quan hệ nhị phân. Các mối quan hệ cấp cao hơn thường phức tạp hơn các mối quan hệ nhị phân; chúng tôi mô tả đặc điểm của chúng thêm trong phần sau 

Mối quan hệ dưới dạng thuộc tính. Đôi khi thuận tiện khi nghĩ về kiểu quan hệ nhị phân về mặt thuộc tính, như chúng ta đã thảo luận trong phần trước. Xem xét kiểu quan hệ WORKS_FOR trong Hình 3.9. Người ta có thể nghĩ về một thuộc tính được gọi là Phòng của loại thực thể NHÂN VIÊN, trong đó giá trị của Phòng cho mỗi thực thể NHÂN VIÊN là (tham chiếu đến) thực thể DEPARTMENT mà nhân viên đó làm việc. Do đó, giá trị được đặt cho thuộc tính Department này là tập hợp của tất cả các thực thể DEPARTMENT, là tập thực thể DEPARTMENT. Đây là những gì chúng ta đã làm trong Hình 3.8 khi chúng ta chỉ định thiết kế ban đầu của kiểu thực thể EMPLOYEE cho cơ sở dữ liệu COMPANY. Tuy nhiên, khi chúng ta coi mối quan hệ nhị phân như một thuộc tính, chúng ta luôn có hai lựa chọn hoặc hai quan điểm. Trong ví dụ này, quan điểm thay thế là nghĩ về một thuộc tính đa giá trị Các nhân viên của loại thực thể DEPARTMENT có giá trị cho mỗi thực thể DEPARTMENT là tập hợp các thực thể NHÂN VIÊN làm việc cho bộ phận đó. Tập giá trị của thuộc tính Nhân viên này là tập hợp của tập thực thể NHÂN VIÊN. Một trong hai thuộc tính này — Bộ phận NHÂN VIÊN hoặc Nhân viên của Bộ phận - có thể đại diện cho kiểu quan hệ WORKS_FOR. Nếu cả hai đều được đại diện, chúng là nghịch đảo của nhau 

Tên vai trò và mối quan hệ đệ quy. Mỗi loại thực thể tham gia vào một kiểu quan hệ đóng một vai trò cụ thể trong mối quan hệ. Tên vai trò biểu thị vai trò mà một thực thể tham gia từ loại thực thể đóng trong mỗi trường hợp mối quan hệ và nó giúp giải thích ý nghĩa của mối quan hệ. Ví dụ: trong kiểu quan hệ WORKS_FOR, NHÂN VIÊN đóng vai trò là người lao động hoặc BỘ PHẬN LAO ĐỘNG đóng vai trò của bộ phận hoặc người sử dụng lao động 

Về mặt kỹ thuật, tên vai trò không cần thiết trong các loại mối quan hệ mà tất cả các loại thực thể tham gia đều khác biệt, vì mỗi tên loại thực thể tham gia có thể được sử dụng làm tên vai trò. Tuy nhiên, trong một số trường hợp, cùng một kiểu thực thể tham gia nhiều lần vào một kiểu quan hệ với các vai trò khác nhau. Trong những trường hợp như vậy, tên vai trò trở nên cần thiết để phân biệt ý nghĩa của vai trò mà mỗi thực thể tham gia thực hiện. Các kiểu quan hệ như vậy được gọi là quan hệ đệ quy hoặc quan hệ tự tham chiếu. Hình 3.11 cho thấy một ví dụ. Kiểu quan hệ GIÁM SÁT liên quan một nhân viên với một người giám sát, trong đó cả hai thực thể nhân viên và giám sát đều là thành viên của cùng một tập hợp thực thể NHÂN VIÊN. Do đó, loại thực thể NHÂN VIÊN tham gia hai lần vào VIỆC GIÁM SÁT: một lần với vai trò giám sát (hoặc sếp) và một lần trong vai trò giám sát (hoặc cấp dưới). Mỗi trường hợp quan hệ ri trong SUPERVISION liên kết hai thực thể nhân viên khác nhau ej và ek, một trong số đó đóng vai trò giám sát và một bên đóng vai trò giám sát. Trong Hình 3.11, các dòng được đánh dấu ‘1’ thể hiện vai trò người giám sát và những dòng được đánh dấu ‘2’ thể hiện vai trò người được giám sát; do đó, e1 giám sát e2 và e3, e4 giám sát e6 và e7, và e5 giám sát e1 và e4. Trong ví dụ này, mỗi cá thể mối quan hệ phải được kết nối với hai dòng, một dòng được đánh dấu bằng ‘1’ (người giám sát) và dòng kia với ‘2’ (người giám sát).

4.3 Ràng buộc quan hệ

Các kiểu quan hệ thường có những ràng buộc nhất định hạn chế các tổ hợp có thể có của các thực thể có thể tham gia vào tập quan hệ tương ứng. Những ràng buộc này được xác định từ tình huống miniworld mà các mối quan hệ phản đối. Ví dụ, trong Hình 3.9, nếu công ty có quy định rằng mỗi nhân viên phải làm việc cho chính xác một bộ phận, và chúng ta muốn mô tả vấn đề này trong lược đồ. Chúng ta có thể phân biệt hai loại ràng buộc quan hệ chính: lượng số và sự tham gia. 

Lượng số cho các mối quan hệ. Lượng số cho mối quan hệ chỉ định số lượng trường hợp quan hệ tối đa mà một thực thể có thể tham gia. Ví dụ: trong kiểu quan hệ WORKS_FOR, DEPARTMENT: EMPLOYEE có lượng số 1: N, nghĩa là mỗi bộ phận có thể liên quan đến (nghĩa là sử dụng) bất kỳ số lượng nhân viên nào (N), nhưng một nhân viên có thể liên quan đến (làm việc cho) nhiều nhất một bộ phận (1). Điều này có nghĩa là đối với kiểu quan hệ WORKS_FOR cụ thể này, một thực thể bộ phận cụ thể có thể liên quan đến bất kỳ số lượng nhân viên nào (N cho biết không có số lượng tối đa). Mặt khác, một nhân viên có thể liên quan đến tối đa một bộ phận. Lượng số có thể có cho các kiểu quan hệ là 1: 1, 1: N, N: 1 và M: N 

Một ví dụ về mối quan hệ 1: 1 là MANAGES (Hình 3.12), quan hệ này liên quan một thực thể bộ phận với nhân viên quản lý bộ phận đó. Điều này đại diện cho các ràng buộc của miniworld mà — tại bất kỳ thời điểm nào — một nhân viên có thể quản lý nhiều nhất một bộ phận và một bộ phận có thể có nhiều nhất một người quản lý. Kiểu quan hệ liên kết WORKS_ON (Hình 3.13) có tỷ lệ cơ bản M: N, vì quy tắc thế giới nhỏ là một nhân viên có thể làm việc trên một số dự án và một dự án có thể có nhiều nhân viên. 

Lượng số cho các mối quan hệ được biểu diễn trên biểu đồ ER bằng cách hiển thị 1, M và N trên các khối hình thoi như trong Hình 3.2. Lưu ý rằng trong ký hiệu này, chúng ta có thể không chỉ định tối đa (N) hoặc tối đa một (1) ngang bằng. Một ký hiệu thay thế cho phép người thiết kế chỉ định một số lượng tối đa cụ thể khi tham gia, chẳng hạn như 4 hoặc 5. 

Ràng buộc về sự tham gia. Ràng buộc tham gia xác định liệu sự tồn tại của một thực thể có phụ thuộc vào việc nó có liên quan đến một thực thể khác thông qua kiểu quan hệ hay không. Ràng buộc này chỉ định số lượng cá thể quan hệ tối thiểu mà mỗi thực thể có thể tham gia và một số thời điểm được gọi là ràng buộc số lượng tối thiểu. Có hai loại ràng buộc tham gia — toàn bộ và một phần — mà chúng tôi minh họa bằng ví dụ. Nếu chính sách của công ty quy định rằng mọi nhân viên phải làm việc cho một bộ phận, thì thực thể nhân viên chỉ có thể tồn tại nếu nó tham gia vào ít nhất một cá thể mối quan hệ WORKS_FOR (Hình 3.9). Do đó, sự tham gia của EMPLOYEE trong WORKS_FOR được gọi là sự tham gia tổng thể, có nghĩa là mọi thực thể trong tổng số các thực thể nhân viên phải liên quan đến một thực thể bộ phận thông qua WORKS_FOR. Tổng số tham gia còn được gọi là sự phụ thuộc tồn tại. Trong Hình 3.12, chúng tôi không mong đợi mọi nhân viên quản lý một bộ phận, do đó, sự tham gia của NHÂN VIÊN trong kiểu quan hệ QUẢN LÝ là một phần, có nghĩa là một số hoặc một phần của tập hợp các thực thể nhân viên có liên quan đến một số thực thể bộ phận thông qua QUẢN LÝ, nhưng không nhất thiết tất cả. Chúng ta sẽ đề cập đến lượng số và các ràng buộc tham gia, được kết hợp với nhau, như là các ràng buộc cấu trúc của một kiểu quan hệ. 

Trong sơ đồ ER, lượng số (hoặc ràng buộc về sự tham gia) được hiển thị dưới dạng một đường kép kết nối loại thực thể tham gia với mối quan hệ, trong khi sự phân chia từng phần được biểu thị bằng một nét liền duy nhất (xem Hình 3.2). Lưu ý rằng trong ký hiệu này, chúng ta có thể chỉ định không có tối thiểu (tham gia một phần) hoặc tối thiểu là một (tham gia toàn bộ). Một ký hiệu thay thế cho phép nhà thiết kế chỉ định một số tối thiểu cụ thể về việc tham gia vào mối quan hệ, chẳng hạn như 4 hoặc 5. 

4.4 Thuộc tính của loại liên kết

Các kiểu quan hệ cũng có thể có các thuộc tính, tương tự như các thuộc tính của các kiểu thực thể. Ví dụ, để ghi lại số giờ mỗi tuần mà một nhân viên cụ thể làm việc trong một dự án cụ thể, chúng ta có thể đưa vào thuộc tính Hours cho kiểu quan hệ WORKS_ON trong Hình 3.13. Một ví dụ khác là bao gồm ngày mà người quản lý bắt đầu quản lý một bộ phận thông qua thuộc tính Start_date cho kiểu quan hệ MANAGES trong Hình 3.12. 

Lưu ý rằng các thuộc tính của kiểu quan hệ 1: 1 hoặc 1: N có thể được chuyển sang một trong các kiểu thực thể tham gia. Ví dụ: thuộc tính Start_date cho mối quan hệ MANAGES có thể là một thuộc tính của EMPLOYEE (manager) hoặc DEPARTMENT, mặc dù về mặt khái niệm thì thuộc tính MANAGES. Điều này là do MANAGES là mối quan hệ 1: 1, vì vậy mọi bộ phận hoặc thực thể nhân viên tham gia vào nhiều nhất một trường hợp mối quan hệ. Do đó, giá trị của thuộc tính Start_date có thể được xác định riêng biệt bởi thực thể bộ phận tham gia hoặc thực thể nhân viên (người quản lý) tham gia 

Đối với kiểu quan hệ 1: N, thuộc tính mối quan hệ chỉ có thể được di chuyển sang kiểu thực thể ở phía N của mối quan hệ. Ví dụ, trong Hình 3.9, nếu quan hệ WORKS_FOR cũng có thuộc tính Start_date cho biết khi nào một nhân viên bắt đầu làm việc cho một bộ phận, thì thuộc tính này có thể được đưa vào như một thuộc tính của EMPLOYEE. Điều này là do mỗi nhân viên làm việc cho nhiều nhất một bộ phận và do đó tham gia vào nhiều nhất một trường hợp mối quan hệ trong WORKS_FOR, nhưng một bộ phận có thể có nhiều nhân viên, mỗi nhân viên có ngày bắt đầu khác nhau. Trong cả hai kiểu quan hệ 1: 1 và 1: N, quyết định đặt thuộc tính mối quan hệ — như thuộc tính kiểu quan hệ hoặc là thuộc tính của kiểu thực thể tham gia — được xác định một cách chủ quan bởi người thiết kế lược đồ. 

Đối với kiểu quan hệ M: N (nhiều-nhiều), một số thuộc tính có thể được xác định bởi sự kết hợp của các thực thể tham gia trong một cá thể mối quan hệ, chứ không phải bởi bất kỳ thực thể đơn lẻ nào. Các thuộc tính đó phải được chỉ định là thuộc tính mối quan hệ. Một ví dụ là thuộc tính Hours của mối quan hệ M: N WORKS_ON (Hình 3.13); số giờ mỗi tuần mà một nhân viên hiện đang làm việc trong một dự án được xác định bởi sự kết hợp giữa nhân viên và dự án chứ không phải một tổ chức riêng biệt 

5. Thực thể yếu

Các loại thực thể không có các thuộc tính chính của riêng chúng được gọi là các loại thực thể yếu. Ngược lại, các loại thực thể thông thường có thuộc tính khóa — bao gồm tất cả các nội dung đã thảo luận từ trước đến nay — được gọi là các loại thực thể mạnh. Các thực thể thuộc loại thực thể yếu được xác định bằng cách có liên quan đến các thực thể cụ thể từ một loại thực thể khác bằng một trong các giá trị thuộc tính của chúng. Chúng tôi gọi loại thực thể khác này là loại thực thể nhận dạng hoặc chủ sở hữu, và chúng tôi gọi loại mối quan hệ liên quan đến loại thực thể yếu với chủ sở hữu của nó là mối quan hệ xác định của loại thực thể yếu. Một loại thực thể yếu luôn có một ràng buộc tham gia toàn bộ ( sự phụ thuộc tồn tại) đối với mối quan hệ xác định của nó vì không thể xác định được một thực thể yếu kém nếu không có một thực thể chủ sở hữu. Tuy nhiên, không phải mọi sự phụ thuộc tồn tại đều dẫn đến một kiểu thực thể yếu. Ví dụ: một thực thể DRIVER_LICENSE không thể tồn tại trừ khi nó có liên quan đến một thực thể PERSON, tuy nhiên vì nó có khóa riêng (License_number) và do đó không phải là một thực thể yếu. 

Hãy xem xét loại thực thể DEPENDENT, liên quan đến EMPLOYEE, được sử dụng để theo dõi những người phụ thuộc của từng nhân viên thông qua mối quan hệ 1: N (Hình 3.2). Trong ví dụ của chúng tôi, các thuộc tính của DEPENDENT là Tên (tên của người phụ thuộc), Ngày sinh, Giới tính và Mối quan hệ (với nhân viên). Tình cờ, hai người phụ thuộc của hai nhân viên khác nhau có thể có các giá trị giống nhau về Tên, Ngày sinh, Giới tính và Mối quan hệ, nhưng chúng vẫn là các thực thể riêng biệt. Họ chỉ được xác định là các thực thể riêng biệt sau khi xác định thực thể nhân viên cụ thể mà mỗi người phụ thuộc có liên quan. Mỗi thực thể nhân viên được cho là sở hữu các thực thể DEPENDENT có liên quan đến nó. 

Loại thực thể yếu thường có một khóa một phần, đây là thuộc tính có thể xác định duy nhất các thực thể yếu có liên quan đến cùng một thực thể chủ sở hữu. Trong ví dụ của chúng tôi, nếu chúng tôi giả định rằng không có hai người phụ thuộc nào của cùng một nhân viên có cùng tên, thì thuộc tính Name of DEPENDENT là khóa một phần. Trong trường hợp xấu nhất, một thuộc tính tổng hợp của tất cả các thuộc tính của thực thể yếu sẽ là khóa một phần. 

Trong sơ đồ ER, các kiểu thực thể yếu và mối quan hệ nhận dạng của nó sẽ được thay bằng các hình chữ nhật hai nét và hình thoi thể hiện cho cái mối quan hệ (xem Hình 3.2). Thuộc tính khóa một phần được gạch dưới bằng dấu gạch ngang hoặc dấu chấm 

Các loại thực thể yếu đôi khi có thể được biểu diễn dưới dạng các thuộc tính phức tạp (hỗn hợp, đa tỷ lệ). Trong ví dụ trước, chúng ta có thể chỉ định thuộc tính Phụ thuộc nhiều giá trị cho EMPLOYEE, là thuộc tính tổng hợp nhiều giá trị với các thuộc tính thành phần Tên, Ngày sinh, Giới tính và Mối quan hệ. Việc lựa chọn cách sử dụng biểu diễn nào là do người thiết kế cơ sở dữ liệu thực hiện. Một tiêu chí có thể được sử dụng là chọn đại diện cho loại thực thể yếu nếu loại thực thể yếu tham gia độc lập trong các loại quan hệ khác với loại quan hệ xác định của nó. 

Nói chung, có thể xác định bất kỳ số lượng cấp độ nào của các loại thực thể yếu; một loại thực thể chủ sở hữu bản thân nó có thể là một loại thực thể yếu. Ngoài ra, một loại thực thể yếu có thể có nhiều hơn một loại thực thể xác định và một loại quan hệ nhận dạng ở mức độ cao hơn hai.

6. Tinh chỉnh thiết kế database cho ví dụ

Bây giờ chúng ta có thể tinh chỉnh thiết kế cơ sở dữ liệu trong Hình 3.8 bằng cách thay đổi các thuộc tính đại diện cho các mối quan hệ thành các kiểu quan hệ. Lượng số và ràng buộc tham gia của mỗi loại quan hệ được xác định từ các yêu cầu được liệt kê trong phần trước. Nếu lượng số hoặc sự phụ thuộc không thể được xác định từ các yêu cầu, người thiết kế phải hỏi thêm người dùng để xác định các ràng buộc cấu trúc này 

Trong ví dụ của chúng tôi, chúng tôi chỉ định các kiểu quan hệ sau: 

• MANAGE, là kiểu quan hệ 1: 1 (một đối một) giữa EMPLOYEE và DEPARTMENT. Sự tham gia của EMPLOYEE là một phần. Sự tham gia của DEPARTMENT không rõ ràng so với các yêu cầu. Chúng tôi đặt câu hỏi cho người dùng, họ nói rằng một bộ phận luôn phải có người quản lý, điều này ngụ ý rằng Thuộc tính Start_date được chỉ định cho loại mối quan hệ này. 

• WORKS_FOR, kiểu quan hệ 1: N (một-nhiều) giữa DEPARTMENT và EMPLOYEE. 

• CONTROL, kiểu quan hệ 1: N giữa DEPARTMENT và PROJECT. Sự tham gia của DỰ ÁN là toàn bộ, trong khi sự tham gia của DEPARTMENT được xác định chỉ là một phần, sau khi tham khảo ý kiến của người dùng cho thấy rằng một số bộ phận có thể không kiểm soát dự án nào. 

• SUPERVISION,, một kiểu quan hệ 1: N giữa EMPLOYEE (trong vai trò người quản lý) và EMPLOYEE (trong vai trò người cấp dưới). Cả hai sự tham gia được xác định là một phần, sau khi người dùng chỉ ra rằng không phải mọi nhân viên đều là giám sát và không phải mọi nhân viên đều có giám sát. 

• WORKS_ON, được xác định là kiểu quan hệ M: N (nhiều-nhiều) với thuộc tính Hours, sau khi người dùng cho biết rằng một dự án có thể có nhiều nhân viên làm việc trên đó và ngược lại một nhân viên có thể tham gia trong nhiều dự án 

• DEPENDENTS_OF, kiểu quan hệ 1: N giữa EMPLOYEE và DEPENDENT, cũng là mối quan hệ xác định cho kiểu thực thể yếu DEPENDENT. Sự tham gia của EMPLOYEE là một phần, trong khi sự tham gia của DEPENDENT là toàn bộ (1 người nhân viên có nhiều người phụ thuộc, nhưng 1 người phụ thuộc chỉ phụ thuộc vào 1 nhân viên – liên quan nghiệp vụ giảm trừ gia cảnh) 

Sau khi chỉ định sáu kiểu quan hệ trước đó, chúng tôi loại bỏ khỏi các kiểu thực thể trong Hình 3.8 tất cả các thuộc tính đã được tinh chỉnh thành các mối quan hệ. Chúng bao gồm Người quản lý và Người quản lý Manager_start_date từ DEPARTMENT; Controlling_department từ PROJECT; Department, Supervisor, và Works_on từ EMPLOYEE; và Employee từ DEPENDENT. Điều quan trọng là phải có ít dư thừa nhất có thể khi chúng ta thiết kế lược đồ khái niệm của cơ sở dữ liệu 

7. Sơ đồ ER, Quy ước đặt tên và Vấn đề thiết kế 

7.1 Tóm tắt ký hiệu cho sơ đồ ER 

Hình 3.9 đến 3.13 minh họa các ví dụ về sự tham gia của các kiểu thực thể trong các kiểu quan hệ bằng cách hiển thị các tập thực thể và tập quan hệ (hoặc phần mở rộng) của chúng — các cá thể thực thể riêng lẻ trong một tập thực thể và các cá thể quan hệ riêng lẻ trong một tập quan hệ. Điều này hữu ích hơn trong thiết kế cơ sở dữ liệu vì một lược đồ cơ sở dữ liệu hiếm khi thay đổi, trong khi nội dung của các tập thực thể có thể thay đổi thường xuyên. Ngoài ra, lược đồ rõ ràng là dễ hiển thị hơn, vì nó nhỏ hơn nhiều. 

Hình 3.2 hiển thị lược đồ cơ sở dữ liệu ER của CÔNG TY dưới dạng biểu đồ ER. Bây giờ chúng ta xem xét ký hiệu sơ đồ ER đầy đủ. Các loại thực thể thông thường (thực thể mạnh) như EMPLOYEE, DEPARTMENT và PROJECT được hiển thị trong các hộp hình chữ nhật. Các loại quan hệ như WORKS_FOR, MANAGES, CONTROLS và WORKS_ON được hiển thị trong các khối hình thoi gắn với các loại thực thể tham gia bằng các đường thẳng. Các thuộc tính được hiển thị dưới dạng hình bầu dục và mỗi thuộc tính được gắn bằng một đường thẳng với kiểu thực thể hoặc kiểu quan hệ của nó. Các thuộc tính thành phần của thuộc tính phức hợp được gắn vào hình bầu dục đại diện cho thuộc tính tổng hợp, như được minh họa bằng thuộc tính Name của EMPLOYEE. Các thuộc tính đa giá trị được hiển thị trong hình bầu dục kép, như được minh họa bởi thuộc tính Locations của DEPARTMENT. Các thuộc tính định danh có gạch chân tên của chúng. Các thuộc tính dẫn xuất được hiển thị trong các hình bầu dục chấm chấm, như được minh họa bởi thuộc tính Number_of_employees của DEPARTMENT 

Trong Hình 3.2, lượng số của mỗi kiểu quan hệ bậc 2 được xác định bằng cách gắn 1, M hoặc N trên mỗi cạnh tham gia. Lượng số của DEPARTMENT: EMPLOYEE trong MANAGES là 1: 1, trong khi tỷ lệ này là 1: N cho DEPARTMENT: EMPLOYEE trong WORKS_FOR và M: N cho WORKS_ON. Ràng buộc cụ thể được chỉ định bởi một dòng duy nhất cho sự tham gia một phần và bằng dòng đôi cho sự tham gia toàn bộ (sự phụ thuộc vào sự tồn tại) 

Trong Hình 3.2, chúng tôi hiển thị các tên vai trò cho kiểu quan hệ SUPERVISION vì cùng một kiểu thực thể NHÂN VIÊN đóng hai vai trò riêng biệt trong mối quan hệ đó. Lưu ý rằng tỷ lệ cơ bản là 1: N từ người giám sát đến nhân viên vì mỗi nhân viên trong vai trò giám sát có nhiều nhất một người giám sát trực tiếp, trong khi một nhân viên trong vai trò giám sát có thể giám sát một hoặc nhiều nhân viên cũng có thể không quản lý nhân viên nào 

Hình 3.14 tóm tắt các quy ước cho sơ đồ ER. Điều quan trọng cần lưu ý là có nhiều ký hiệu sơ đồ thay thế khác 

7.2 Đặt tên thích hợp cho lược đồ

Khi thiết kế một lược đồ cơ sở dữ liệu, việc lựa chọn tên cho các kiểu thực thể, thuộc tính, kiểu quan hệ và vai trò không phải lúc nào cũng đơn giản. Người ta nên chọn những cái tên truyền đạt càng nhiều ý nghĩa càng tốt cho các cấu trúc khác nhau trong lược đồ. Chúng tôi chọn sử dụng tên số ít cho các loại thực thể, thay vì tên số nhiều, vì tên loại thực thể áp dụng cho mỗi thực thể cá biệt thuộc loại thực thể đó. Trong sơ đồ ER của chúng tôi, chúng tôi sẽ sử dụng ý tưởng rằng tên kiểu thực thể và kiểu quan hệ được viết hoa, tên thuộc tính có chữ cái đầu tiên được viết hoa và tên vai trò là chữ thường. Chúng tôi đã sử dụng quy ước này trong Hình 3.2. 

Như một thông lệ chung, với một mô tả tường thuật về các yêu cầu cơ sở dữ liệu, các danh từ xuất hiện trong câu tường thuật có xu hướng làm phát sinh tên loại thực thể và các động từ có xu hướng chỉ ra tên của các loại quan hệ. Tên thuộc tính thường phát sinh từ các danh từ bổ sung mô tả các danh từ tương ứng với các loại thực thể. 

Một xem xét đặt tên khác liên quan đến việc chọn các tên quan hệ bậc để làm cho biểu đồ ER của lược đồ có thể đọc được từ trái sang phải và từ trên xuống dưới. Nhìn chung, chúng tôi đã tuân theo hướng dẫn này trong Hình 3.2. Để giải thích thêm về quy ước đặt tên này, chúng ta có một ngoại lệ đối với quy ước trong Hình 3.2 — kiểu quan hệ DEPENDENTS_OF, đọc từ dưới lên trên. Khi mô tả mối quan hệ này, chúng ta có thể nói rằng các thực thể DEPENDENT (loại thực thể dưới cùng) là DEPENDENTS_OF (tên mối quan hệ) một EMPLOYEE (loại thực thể trên cùng). Để thay đổi điều này thành đọc từ trên xuống dưới, chúng tôi có thể đổi tên kiểu quan hệ thành HAS_DEPENDENTS, sau đó sẽ đọc như sau: Thực thể EMPLOYEE (loại thực thể trên cùng) HAS_DEPENDENTS (tên quan hệ) thuộc loại DEPENDENT (loại thực thể dưới cùng). Lưu ý rằng vấn đề này phát sinh vì mỗi mối quan hệ bậc hai có thể được mô tả bắt đầu từ một trong hai loại thực thể tham gia, như đã thảo luận ở phần trên 

7.3 Lựa chọn thiết kế cho thiết kế khái niệm ER 

Đôi khi rất khó để quyết định liệu một khái niệm cụ thể trong thế giới nhỏ có nên được mô hình hóa như một loại thực thể, một thuộc tính hay một loại mối quan hệ hay không. Trong phần này, chúng tôi đưa ra một số hướng dẫn ngắn gọn về việc nên chọn cấu trúc nào trong các tình huống cụ thể.  

Nói chung, quá trình thiết kế lược đồ nên được coi là một quá trình tinh chỉnh lặp đi lặp lại, trong đó một thiết kế ban đầu được tạo và sau đó được tinh chỉnh lặp đi lặp lại cho đến khi đạt được thiết kế phù hợp nhất. Một số sàng lọc thường được sử dụng bao gồm:  

• Trước tiên, một khái niệm có thể được mô hình hóa dưới dạng một thuộc tính và sau đó được tinh chỉnh thành một mối quan hệ tương đối bởi vì nó được xác định rằng thuộc tính là một tham chiếu đến một loại thực thể khác. Thường có trường hợp một cặp thuộc tính nghịch đảo của nhau được tinh chỉnh thành một mối quan hệ. Chúng ta đã thảo luận chi tiết về loại sàng lọc này trong Phần 3.6. Điều quan trọng cần lưu ý là trong ký hiệu của chúng ta, khi một thuộc tính được thay thế bằng một mối quan hệ, thì bản thân thuộc tính đó nên được xóa khỏi kiểu thực thể để tránh trùng lặp và dư thừa 

• Tương tự, một thuộc tính tồn tại trong một số loại thực thể có thể được nâng cao hoặc thăng cấp thành một loại thực thể độc lập. Ví dụ, giả sử rằng mỗi loại thực thể trong cơ sở dữ liệu ĐẠI HỌC, chẳng hạn như SINH VIÊN, GIÁO VIÊN HƯỚNG DẪN và KHÓA HỌC, có một Phòng thuộc tính trong thiết kế ban đầu; sau đó, nhà thiết kế có thể chọn tạo một loại thực thể KHOA với một thuộc tính duy nhất Dept_name và liên hệ nó với ba loại thực thể (SINH VIÊN, GIÁO VIÊN HƯỚNG DẪN, và KHÓA HỌC) thông qua các mối quan hệ tương đối thích hợp. Các thuộc tính / mối quan hệ khác của KHOA có thể được khám phá sau này. 

• Có thể áp dụng cải tiến ngược đối với trường hợp trước — ví dụ: nếu một loại thực thể KHOA tồn tại trong thiết kế ban đầu với một thuộc tính Dept_name duy nhất và chỉ liên quan đến một loại thực thể khác, SINH VIÊN. Trong trường hợp này, KHOA có thể bị giảm hoặc giáng cấp thành thuộc tính SINH VIÊN. 

7.4 Ký hiệu thay thế cho sơ đồ ER 

Có nhiều ký hiệu thay thế cho sơ đồ ER, chúng ta có thể dùng ký hiệu của Ngôn ngữ mô hình hóa hợp nhất (UML) 

Trong phần này, chúng tôi mô tả một ký hiệu ER thay thế để chỉ định các ràng buộc cấu trúc trên các mối quan hệ, thay thế lượng số tham gia (1: 1, 1: N, M: N) và ký hiệu dòng đơn / đôi cho các ràng buộc tham gia. Kí hiệu này liên quan đến việc liên kết một cặp số nguyên (tối thiểu, tối đa) với mỗi sự tham gia của một loại thực thể E trong một kiểu quan hệ R, trong đó 0 ≤ min ≤ max và max ≥ 1. Các con số có nghĩa là đối với mỗi thực thể e trong E, e phải tham gia vào ít nhất các trường hợp quan hệ tối thiểu và tối đa trong R tại bất kỳ thời điểm nào. Trong phương pháp này, min = 0 có nghĩa là tham gia một phần, trong khi min> 0 có nghĩa là tham gia toàn bộ. 

Hình 3.15 hiển thị lược đồ cơ sở dữ liệu COMPANY sử dụng ký hiệu (tối thiểu, tối đa). Thông thường, người ta sử dụng tỷ lệ thẻ số / dòng đơn / dòng kép hoặc ký hiệu (tối thiểu, tối đa). Ký hiệu (min, max) chính xác hơn và chúng ta có thể sử dụng nó để chỉ định một số ràng buộc cấu trúc cho các loại quan hệ ở mức độ cao hơn. Tuy nhiên, nó không đủ để xác định một số ràng buộc chính đối với mối quan hệ ở cấp độ cao hơn 

8. Ví dụ về ký hiệu khác - Sơ đồ UML

Phương pháp luận UML đang được sử dụng rộng rãi trong thiết kế phần mềm và có nhiều dạng biểu đồ cho các mục đích thiết kế phần mềm khác nhau. Chúng tôi chỉ trình bày ngắn gọn những điều cơ bản của biểu đồ lớp UML ở đây và so sánh chúng với biểu đồ ER. Theo một số cách, biểu đồ lớp có thể được coi là một ký hiệu thay thế cho biểu đồ ER. Ký hiệu và khái niệm UML bổ sung được trình bày trong Phần 8.6. Hình 3.16 cho thấy cách lược đồ cơ sở dữ liệu COMPANY ER trong Hình 3.15 có thể được hiển thị bằng cách sử dụng ký hiệu sơ đồ lớp UML. Các kiểu thực thể trong Hình 3.15 được mô hình hóa thành các lớp trong Hình 3.16. Một thực thể trong ER tương ứng với một đối tượng trong UML.  

Trong sơ đồ lớp UML, một lớp (tương tự như kiểu thực thể trong ER) được hiển thị dưới dạng hộp (xem Hình 3.16) bao gồm ba phần: Phần trên cùng là tên lớp (tương tự như tên kiểu thực thể); phần giữa bao gồm các thuộc tính; và phần cuối cùng bao gồm các hoạt động có thể được áp dụng cho các đối tượng riêng lẻ (tương tự như các thực thể riêng lẻ trong một tập thực thể) của lớp. Các hoạt động không được chỉ định trong sơ đồ ER. Xem xét lớp EMPLOYEE trong Hình 3.16. Các thuộc tính của nó là Tên, Ssn, Ngày tháng, Giới tính, Địa chỉ và Mức lương. Người thiết kế có thể tùy chọn chỉ định miền (hoặc kiểu dữ liệu) của một thuộc tính nếu muốn, bằng cách đặt dấu hai chấm (:) theo sau là tên miền hoặc mô tả, như được minh họa bởi các thuộc tính Name, Sex và Bdate của EMPLOYEE trong Hình 3.16. Thuộc tính tổng hợp được mô hình hóa dưới dạng miền có cấu trúc, như được minh họa bằng thuộc tính Tên của EMPLOYEE. Một thuộc tính ued đa trị thường sẽ được mô hình hóa thành một lớp riêng biệt, như được minh họa bởi lớp LOCATION trong Hình 3.16 

Các kiểu quan hệ được gọi là liên kết trong thuật ngữ UML và các thể hiện quan hệ được gọi là liên kết. Một liên kết bậc hai (kiểu quan hệ bậc 2) được thay bằng một đường kết nối các lớp tham gia (kiểu thực thể) và có thể tùy chọn cùng tên. Thuộc tính mối quan hệ, được gọi là thuộc tính liên kết, được đặt trong một hộp được kết nối với đường liên kết bằng một đường đứt nét. Ký hiệu (min, max) được mô tả trong phần trước được sử dụng để xác định các ràng buộc quan hệ, được gọi là phép nhân trong thuật ngữ UML. Số nhân được chỉ định ở dạng min..max và dấu hoa thị (*) cho biết không có giới hạn tối đa về sự tham gia.Trong UML, một dấu hoa thị đơn cho biết nhiều 0 .. * và một dấu 1 biểu thị nhiều 1..1. Một kiểu quan hệ đệ quy được gọi là liên kết phản xạ trong UML và các tên vai trò - giống như các phép nhân - được đặt ở các đầu đối diện của một liên kết khi so sánh với cách đặt các tên vai trò trong Hình 3.15 

Trong UML, có hai kiểu quan hệ: liên kết và tập hợp. Tập hợp (Aggregation) có nghĩa là đại diện cho mối quan hệ giữa các thực thể mà không ai sở hữu ai. Trong Hình 3.16, chúng ta đã mô hình hóa các vị trí của một bộ phận và một vị trí duy nhất của một dự án dưới dạng tập hợp. Tuy nhiên, tập hợp và liên kết (association) không có các đặc tính khác nhau nhiều (về lý thuyết có thể khác nhau về vòng đời), và việc lựa chọn loại quan hệ nào để sử dụng tập hợp hoặc liên kết thường sẽ hay  có hiện tượng chủ quan. Trong mô hình ER, cả hai đều được biểu diễn dưới dạng các mối quan hệ. 

UML cũng phân biệt giữa các liên kết đơn hướng và hai chiều (hoặc tổng hợp). Trong trường hợp đơn hướng, đường kết nối các lớp được phát bằng một mũi tên để chỉ ra rằng chỉ cần một hướng để truy cập các đối tượng liên quan. Nếu không có mũi tên nào được hiển thị, trường hợp hai chiều được giả định, đây là trường hợp mặc định. Ví dụ: nếu chúng ta luôn mong đợi truy cập trình quản lý của một người khởi hành bắt đầu từ đối tượng DEPARTMENT, chúng ta sẽ vẽ đại diện dòng liên kết gửi lại liên kết MANAGES bằng một mũi tên từ DEPARTMENT đến EMPLOYEE. Ngoài ra, các trường hợp mối quan hệ có thể được chỉ định để được đặt hàng. Ví dụ: chúng tôi có thể chỉ định rằng các đối tượng nhân viên liên quan đến mỗi lần khởi hành thông qua liên kết WORKS_FOR (mối quan hệ) phải được sắp xếp theo giá trị thuộc tính Start_date của chúng. Tên liên kết (mối quan hệ) là tùy chọn trong UML và các thuộc tính mối quan hệ được hiển thị trong một hộp được đính kèm với đường đứt nét với dòng biểu thị sự kết hợp / tổng hợp (xem Ngày bắt đầu và Giờ trong Hình 3.16) 

UML cũng phân biệt giữa các liên kết đơn hướng và hai chiều (hoặc tổng hợp). Trong trường hợp đơn hướng, đường kết nối các lớp được thể bằng một mũi tên để chỉ ra rằng chỉ cần một hướng để truy cập các đối tượng liên quan. Nếu không có mũi tên nào được hiển thị có thể ngầm hiểu đây là liên kết hai chiều , đây là trường hợp mặc định. Ví dụ: nếu chúng ta muốn thể hiện nọi dung “một nhân viên có thể là người quản lý của một bộ phận” bắt đầu từ đối tượng DEPARTMENT, chúng ta sẽ vẽ đại diện dòng liên kết MANAGES bằng một mũi tên từ DEPARTMENT đến EMPLOYEE. Ngoài ra, các trường hợp mối quan hệ có thể được chỉ định để được đặt hàng. Ví dụ: chúng tôi có thể chỉ định rằng các đối tượng nhân viên liên quan đến mỗi DEPARTMENT thông qua liên kết WORKS_FOR (mối quan hệ) phải được sắp xếp theo giá trị thuộc tính Start_date của chúng. Tên liên kết (mối quan hệ) là tùy chọn trong UML và các thuộc tính mối quan hệ được hiển thị trong một hình chữ nhật được đính kèm với đường đứt nét (xem thuộc tính Start_date và Hour trong Hình 3.16) 

Các hoạt động được đưa ra trong mỗi lớp được bắt nguồn từ các yêu cầu chức năng của ứng dụng, như chúng ta đã thảo luận trong Phần 3.1. Nhìn chung, chỉ định tên hoạt động ban đầu cho các phép toán logic dự kiến sẽ được áp dụng cho các đối tượng riêng lẻ của một lớp là đủ, như thể hiện trong Hình 3.16. Khi thiết kế được tinh chỉnh, nhiều chi tiết hơn được thêm vào, chẳng hạn như các loại đối số chính xác (tham số) cho mỗi hoạt động, cộng với mô tả chức năng của từng hoạt động. UML có các mô tả chức năng và biểu đồ trình tự để chỉ định một số chi tiết hoạt động, nhưng chúng nằm ngoài phạm vi thảo luận trong bài này 

9. Các liên kết bậc cao

9.1 Lựa chọn giữa mối liên kết bậc hai và bậc ba (hoặc cao hơn) 

Ký hiệu sơ đồ ER cho kiểu quan hệ bậc ba được thể hiện trong Hình 3.17 (a), biểu đồ này hiển thị lược đồ cho kiểu quan hệ SUPPLY được hiển thị trong Hình 3.10. Nhớ lại rằng tập hợp quan hệ của SUPPLY là một tập hợp các thể hiện quan hệ tương đối (s, j, p), trong đó ý nghĩa là s là SUPPLIER hiện đang cung cấp PART p cho PROJECT j. Nói chung, kiểu quan hệ R bậc n sẽ có n cạnh trong biểu đồ ER, một cạnh nối R với mỗi kiểu thực thể tham gia 

Hình 3.17 (b) cho thấy một sơ đồ ER cho ba kiểu quan hệ bậc hai CAN_SUPPLY, USES và SUPPLIES. Nói chung, kiểu quan hệ bậc ba đại diện cho thông tin khác với kiểu quan hệ nhị phân. Hãy xem xét ba kiểu quan hệ nhị phân CAN_SUPPLY, USES và SUPPLIES. Giả sử rằng CAN_SUPPLY, giữa SUPPLIER và PART, bao gồm một thể hiện (s, p) bất cứ khi nào nhà cung cấp s có thể cung cấp các chi tiết p (cho bất kỳ dự án nào); USES, giữa PROJECT và PART, bao gồm một thể hiện (j, p) bất cứ khi nào dự án j sử dụng chi tiết p; và SUPPLIES, giữa SUPPLIER và PROJECT, bao gồm (các) thể hiện bất cứ khi nào nhà cung cấp cung cấp một số chi tiết cho dự án j. Sự tồn tại của ba trường hợp quan hệ (s, p), (j, p) và (s, j) trong CAN_SUPPLY, USES và SUPPLIES, tương ứng, không ngụ ý một cách rõ ràng rằng một trường hợp (s, j, p) tồn tại trong mối quan hệ bậc ba SUPPLIES, vì nghĩa khác nhau. Thường rất khó để quyết định xem một mối quan hệ cụ thể có nên được biểu diễn dưới dạng một kiểu quan hệ bậc n hay nên được chia nhỏ thành một số kiểu quan hệ có bậc nhỏ hơn. Người thiết kế phải đưa ra quyết định này dựa trên ngữ nghĩa hoặc ý nghĩa của tình huống cụ thể được trình bày. Giải pháp điển hình là bao gồm mối quan hệ bậc ba cộng với một hoặc nhiều mối quan hệ bậc 2, nếu chúng đại diện cho các ý nghĩa khác nhau và nếu tất cả đều được ứng dụng cần. 

Một số công cụ thiết kế cơ sở dữ liệu dựa trên các biến thể của mô hình ER chỉ cho phép các mối quan hệ nhị phân. Trong trường hợp này, mối quan hệ bậc ba như SUPPLY phải được thể hiện dưới dạng một loại thực thể yếu, không có khóa một phần và có ba mối quan hệ xác định. Ba loại thực thể tham gia SUPPLIER, PART và PROJECT cùng là các loại thực thể chủ sở hữu (xem Hình 3.17 (c)). Do đó, một thực thể trong loại thực thể yếu SUPPLY trong Hình 3.17 (c) được xác định bằng sự kết hợp của ba thực thể chủ sở hữu của nó từ SUPPLIER, PART và PROJECT. 

Cũng có thể biểu diễn mối quan hệ bậc ba như một kiểu thực thể thông thường bằng cách đưa vào một khóa thay thế. Trong ví dụ này, thuộc tính khóa Supply_id có thể được sử dụng cho loại thực thể SUPPLIES, chuyển đổi nó thành một loại thực thể thông thường. Ba mối quan hệ N: 1 liên quan SUPPLIES với mỗi loại trong số ba loại thực thể tham gia. 

Một ví dụ khác được thể hiện trong Hình 3.18. Kiểu quan hệ bậc ba OFFERS đại diện cho thông tin về các giảng viên cung cấp các khóa học trong các học kỳ cụ thể; do đó nó bao gồm một cá thể quan hệ (i, s, c) bất cứ khi nào INSTRUCTOR i cung cấp COURSE c trong SEMESTER s. Ba kiểu quan hệ bậc hai được hiển thị trong Hình 3.18 có ý nghĩa sau: CAN_TEACH liên quan đến một khóa học với giáo viên hướng dẫn có thể dạy khóa học đó, TAUGHT_DURING liên quan đến một học kỳ với những giảng viên đã dạy một số khóa học trong học kỳ đó và OFFERED_DURING liên quan đến một học kỳ với các khóa học được cung cấp trong học kỳ đó bởi bất kỳ giảng viên nào. Các mối quan hệ này đại diện cho các thông tin khác nhau, nhưng các ràng buộc nhất định nên giữ giữa các mối quan hệ. Ví dụ: một cá thể quan hệ (i, s, c) không được tồn tại trong OFFERS trừ khi một (i, s) tồn tại trong TAUGHT_DURING, một (s, c) tồn tại trong OFFERED_DURING và một cá thể (i, c) tồn tại trong CAN_TEACH. Tuy nhiên, điều ngược lại không phải lúc nào cũng đúng; chúng ta có thể có các trường hợp (i, s), (s, c) và (i, c) trong ba kiểu quan hệ bậc 2 mà không có trường hợp nào tương ứng (i, s, c) trong OFFERS. Lưu ý rằng trong ví dụ này, dựa trên ý nghĩa của các mối quan hệ, chúng ta có thể suy ra các trường hợp của TAUGHT_DURING và OFFERED_DURING từ các trường hợp trong OFFERS, nhưng chúng tôi không thể suy ra các trường hợp của CAN_TEACH; do đó, TAUGHT_DURING và OFFERED_DURING là dư thừa và có thể bị loại bỏ 

Mặc dù nói chung, ba mối quan hệ nhị phân không thể thay thế một mối quan hệ bậc ba, nhưng chúng có thể làm như vậy dưới những ràng buộc bổ sung nhất định. Trong ví dụ của chúng tôi, nếu mối quan hệ CAN_TEACH là 1: 1 (một người hướng dẫn chỉ có thể dạy một khóa học và một khóa học chỉ có thể được dạy bởi một người hướng dẫn), thì mối quan hệ bậc ba OFFERS có thể được bỏ qua vì nó có thể được suy ra từ ba mối quan hệ nhị phân CAN_TEACH, TAUGHT_DURING và OFFERED_DURING. Người thiết kế lược đồ phải phân tích ý nghĩa của từng tình huống cụ thể để quyết định kiểu quan hệ nhị phân và bậc ba nào là cần thiết. 

Lưu ý rằng có thể có một kiểu thực thể yếu với kiểu mối quan hệ xác định bậc ba (hoặc bậc n). Trong trường hợp này, loại thực thể yếu có thể có một số loại thực thể chủ sở hữu. Một ví dụ được thể hiện trong Hình 3.19. Ví dụ này cho thấy một phần của cơ sở dữ liệu theo dõi các ứng viên phỏng vấn xin việc tại các công ty khác nhau, có thể là một phần của cơ sở dữ liệu của cơ quan tuyển dụng. Trong các yêu cầu, một can didate có thể có nhiều cuộc phỏng vấn với cùng một công ty (ví dụ: với các phòng ban khác nhau của công ty hoặc vào các ngày riêng biệt), nhưng một lời mời làm việc được đưa ra dựa trên một trong các cuộc phỏng vấn. Ở đây, INTERVIEW được thể hiện như một thực thể yếu với hai chủ sở hữu là CANDIDATE và COMPANY, và với khóa một phần Dept_date. Thực thể INTERVIEW được xác định duy nhất bởi một ứng viên, một công ty và quốc gia chung của ngày và bộ phận phỏng vấn. 

9.2 Ràng buộc trong liên kết bậc cao 

Có hai ký hiệu để chỉ định các ràng buộc cấu trúc trên các mối quan hệ bậc n và chúng chỉ định các ràng buộc khác nhau. Do đó, cả hai đều nên được sử dụng nếu cần thiết phải xác định đầy đủ các ràng buộc cấu trúc đối với quan hệ quan hệ bậc ba hoặc bậc cao hơn. Ký hiệu đầu tiên dựa trên ký hiệu lượng số của các mối quan hệ bậc hai được hiển thị trong Hình 3.2. Ở đây, 1, M hoặc N được xác định trên mỗi quan hệ cùng tham gia (cả ký hiệu M và N tượng trưng cho nhiều hoặc bất kỳ số nào) .15 Hãy để chúng tôi minh họa ràng buộc này bằng cách sử dụng mối quan hệ CUNG trong Hình 3.17. 

Nhớ lại rằng tập hợp quan hệ SUPPLIES là một tập hợp các thể hiện quan hệ (s, j, p), trong đó s là SUPPLIERS j là PROJECT và p là PART. Giả sử rằng tồn tại ràng buộc rằng đối với một tổ hợp bộ phận dự án cụ thể, chỉ một nhà cung cấp sẽ được sử dụng (chỉ một nhà cung cấp cung cấp một bộ phận cụ thể cho một dự án cụ thể). Trong trường hợp này, chúng tôi đặt 1 vào sự tham gia của SUPPLIERS và M, N vào sự tham gia của PROJECT, PART trong Hình 3.17. Điều này xác định ràng buộc rằng một tổ hợp (j, p) cụ thể có thể xuất hiện nhiều nhất một lần trong tập hợp quan hệ vì mỗi tổ hợp (PROJECT, PART) như vậy xác định duy nhất một nhà cung cấp. Do đó, bất kỳ cá thể quan hệ nào (s, j, p) được xác định duy nhất trong mối quan hệ được thiết lập bởi tổ hợp (j, p) của nó, điều này làm cho (j, p) trở thành một khóa cho tập hợp quan hệ. Trong ký hiệu này, các tham gia có số 1 được chỉ định trên chúng không bắt buộc phải là một phần của khóa nhận dạng cho tập hợp quan hệ. Nếu cả ba thành phần là M hoặc N, thì khóa sẽ là sự kết hợp của cả ba thành phần tham gia. 

Ký hiệu thứ hai dựa trên ký hiệu (min, max) được hiển thị trong Hình 3.15 cho các mối quan hệ bậc hai . Một ký hiệu dạng (tối thiểu, tối đa) trên một sự tham gia ở đây chỉ định rằng mỗi thực thể có liên quan đến ít nhất các trường hợp quan hệ tối thiểu và tối đa trong tập hợp quan hệ tương đối. Các ràng buộc này không liên quan đến việc xác định khóa của một mối quan hệ bậc n, trong đó n > 2, nhưng chỉ định một loại ràng buộc khác đặt ra các hạn chế về số lượng trường hợp quan hệ mà mỗi thực thể có thể tham gia. 

10. Một ví dụ khác về cơ sở dữ liệu UNIVERSITY

Bây giờ chúng tôi trình bày một ví dụ khác, cơ sở dữ liệu UNIVERSITY, để minh họa các khái niệm mô hình ER. Giả sử rằng cần có một cơ sở dữ liệu để theo dõi việc đăng ký học của học sinh trong các lớp học và điểm cuối cùng của học sinh. Sau khi phân tích các nghiệp vụ liên quan và nhu cầu của người dùng, các yêu cầu đối với cơ sở dữ liệu này được xác định như sau (để ngắn gọn, chúng tôi hiển thị tên loại thực thể đã chọn và tên thuộc tính cho lược đồ khái niệm trong dấu ngoặc đơn khi chúng tôi mô tả các yêu cầu; các quan hệ được hiển thị trong lược đồ ER 

• Trường đại học được tổ chức thành các trường cao đẳng (COLLEGE), và mỗi trường cao đẳng có một tên riêng (CName), văn phòng chính (COffice) và điện thoại (CPhone), và một giảng viên cụ thể là hiệu trưởng của trường. Mỗi trường đại học quản lý một số khoa học thuật (DEPT). Mỗi khoa có một tên riêng (DName), một mã số duy nhất (DCode), một văn phòng chính (DOffice) và điện thoại (DPhone), và một giảng viên cụ thể chủ trì khoa. Chúng tôi theo dõi ngày bắt đầu (CStartDate) khi giảng viên bắt đầu quản lý khoa 

• Một khoa cung cấp một số khóa học (COURSE), mỗi khóa học có một tên khóa học duy nhất (CoName), một mã số duy nhất (CCode), một cấp độ khóa học (Cấp độ: cái này có thể được mã hóa là 1 cho trình độ sinh viên năm nhất, 2 cho năm thứ hai , 3 cho cơ sở, 4 cho cao cấp, 5 cho trình độ MS và 6 cho trình độ Tiến sĩ), số tín chỉ khóa học (CREDITS), và mô tả khóa học (CDesc). Cơ sở dữ liệu cũng theo dõi các giáo viên hướng dẫn (INSTRUCTOR); và mỗi người hướng dẫn có một mã định danh iden duy nhất (Id), tên (IName), văn phòng (IOffice), điện thoại (IPhone), và cấp bậc (Rank); ngoài ra, mỗi người hướng dẫn làm việc cho một khoa giáo dục chính 

• Cơ sở dữ liệu sẽ lưu giữ dữ liệu học sinh (STUDENT) và lưu trữ tên của mỗi học sinh (SName, bao gồm tên (FName), tên đệm (MName), họ (LName)), mã định học sinh (Sid, duy nhất cho mỗi học sinh), địa chỉ (Addr), điện thoại (Phone), chuyên ngành (Major), và ngày sinh (DoB). Một học sinh được chỉ định cho một khoa học chính. Cần phải theo dõi điểm của học sinh trong mỗi phần mà học sinh đã hoàn thành. 

• Các khóa học được cung cấp dưới dạng các học phần (SECTION). Mỗi học phần liên quan đến một khóa học và một người hướng dẫn duy nhất và có một mã định danh phần duy nhất (SecId). Một học phần cũng có số phần (SecNo: phần này được mã hóa là 1, 2, 3, ... cho nhiều phần được cung cấp trong cùng học kỳ / năm), học kỳ (Sem), năm (Năm), lớp học (CRoom: điều này được mã hóa dưới dạng sự kết hợp của mã tòa nhà (Bldg) và số phòng (RoomNo) trong tòa nhà) và ngày / giờ (Thời gian ngày: ví dụ: 'MWF 9 giờ sáng - 9 giờ 50 sáng' hoặc '3 giờ 30 phút chiều-5 giờ 20 phút' '.— bị giới hạn ở các giá trị ngày / giờ chỉ được phép). (Lưu ý: Cơ sở dữ liệu sẽ theo dõi tất cả các học phần được cung cấp trong vài năm qua, ngoài các học phần hiện tại. SecId là duy nhất cho tất cả các học phần, không chỉ các học phần cho một học kỳ cụ thể.) Cơ sở dữ liệu theo dõi các học sinh trong mỗi học phần và điểm được ghi lại khi có sẵn (đây là mối quan hệ nhiều-nhiều giữa học sinh và các học phần). Một học phần phải có ít nhất năm sinh viên 

11. Tóm tắt

Bài viết khá dài nên mình sẽ tóm tắt các ý chính trong phần này như bên dưới:

• Các khái niệm liên quan đến mô hình ER. Mô hình thực thể - liên kết (ER model) chính là sự trừu tượng hóa thế giới thực ở mức ý niệm. Nó mô tả việc tổ chức dữ liệu trong một hệ thống CSDL
• Các thành phần trong mô hình ER ( thực thể, thuộc tính, vai trò, mối quan hệ, cấp bậc và lượng số của mối quan hệ, ràng buộc quan hệ,....)
• Các ký hiệu khác để mô hình hóa - UML và các ví dụ

Chúc bạn đọc vui vẻ!