TÀI LIỆU

Giới thiệu thiết kế cơ sở dữ liệu

Mô hình ER cho phép chúng ta biểu diễn dữ liệu trong thế giới thực bằng các đối tượng và mối quan hệ giữa chúng, và nó được sử dụng rộng rãi như là bước đầu tiên trong thiết kế cơ sở dữ liệu. Trong chương này, chúng tôi giới thiệu mô hình ER và bàn luận tại sao chúng được sử dụng rộng rãi.

Chúng tôi bắt đầu phần tổng quan về thiết kế cơ sở dữ liệu trong phần 1 để làm rõ mục tiêu bàn luận của chúng tôi về mô hình ER. Trong sơ đồ lớn của quá trình thiết kế tổng quan, mô hình ER được sử dụng trong giai đoạn gọi là thiết kế cơ sở dữ liệu mức khái niệm. Sau đó, phần 2, 3 và 4 sẽ giới thiệu về mô hình ER. Phần 5 sẽ bàn đến những vấn đề thiết kế cơ sở dữ liệu trong mô hình ER. Chúng tôi bàn tóm tắt về thiết kế cơ sở dữ liệu mức khái niệm cho các ứng dụng lớn trong phần 6. Phần 7 biểu diễn tổng quan về UML, phương pháp mô hình hóa và thiết kế tổng quát hơn mô hình ER.

Phần 8 giới thiệu một bài toán thực tế sẽ được nghiên cứu như một ví dụ xuyên suốt cuốn sách này. Đây là ví dụ về thiết kế cơ sở dữ liệu cho một cửa hàng Internet. Chúng tôi minh họa hai bước đầu tiên (bao gồm phân tích và thiết kế khái niệm) trong phần 8. Những chương cuối cùng sẽ mở rộng ví dụ này để trình bày những bước còn lại trong quá trình thiết kế.

Chúng ta ghi nhớ rằng có rất nhiều mô hình ER hiện nay đang được sử dụng, và không có chuẩn nào thắng thế. Những trình bày trong chương này là những miêu tả về mô hình ER phổ biến, bao gồm tập hợp những đặc tính phổ dụng nhất.

Thiết kế cơ sở dữ liệu và lược đồ ER

Quá trình thiết kế cơ sở dữ liệu có thể được chia thành sáu bước. Mô hình ER liên quan chặt chẽ tới ba bước đầu tiên.

Phân tích yêu cầu: Bước đầu tiên trong thiết kế ứng dụng cơ sở dữ liệu là phải hiểu được những dữ liệu nào cần lưu trữ trong cơ sở dữ liệu, những ứng dụng nào phải được xây dựng đầu tiên và những thao tác nào được sử dụng. Nói cách khác, chúng ta phải chỉ ra những gì người sử dụng muốn đối với cơ sở dữ liệu. Quá trình này chúng ta cần phải bàn luận với nhóm người dùng, nghiên cứu thực trạng và ghi nhận những mong muốn của người sử dụng, phân tích những văn bản có thể và những ứng dụng đang tồn tại của hệ thống để có thể xây dựng ứng dụng thay thế tốt hơn. Một số phương pháp luận đã được đề xuất để tổ chức và biểu diễn những thông tin tập hợp được, và một vài công cụ tự động đã được phát triển để hỗ trợ quá trình này.

Các công cụ thiết kế cơ sở dữ liệu: Công cụ thiết kế được các nhà phát triển RDBMS cung cấp. Ví dụ, chi tiết về công cụ thiết kế và phân tích của Sysbase được chỉ ra trong liên kết sau:

http://www.sybase.com/products/application tools

Chi tiết về những công cụ của Oracle được chỉ ra trong liên kết sau:

http://www.oracle.com/tools
Thiết kế cơ sở dữ liệu mức khái niệm: Những thông tin thu thập được trong bước phân tích yêu cầu được sử dụng để xây dựng phần biểu diễn dữ liệu trong cơ sở dữ liệu ở mức cao dựa vào những ràng buộc chúng ta đã biết về dữ liệu. Bước này được thực hiện sử dụng mô hình ER, hoặc mô hình dữ liệu mức cao tương đương, và nó sẽ được bàn tới trong chương này. Mô hình ER là một trong một số những mô hình mức cao, còn gọi là mô hình ngữ nghĩa. Mục đích của bước này là tạo ra cái nhìn đơn giản về dữ liệu để người sử dụng và người thiết kế dễ dàng hiểu được. Điều này giúp cho tất cả các đối tượng liên quan dễ dàng hiểu nhau trong quá trình thiết kế, kể cả những người không có hiểu biết nền tảng về công nghệ thông tin. Ở thời điểm này, người thiết kế phải có đủ thông tin để có thể xây dựng mô hình dữ liệu dựa vào hệ thống cơ sở dữ liệu thương mại (thực tế, đó là mô hình quan hệ).
Thiết kế cơ sở dữ liệu logic: Chúng ta phải lựa chọn DBMS để thực hiện những thiết kế cơ sở dữ liệu của chúng ta, và chuyển thiết kế cơ sở dữ liệu khái niệm vào lược đồ cơ sở dữ liệu tương ứng trong mô hình dữ liệu của DBMS. Chúng tôi sẽ chỉ đề cập đến các DBMS quan hệ, và vì thế, công việc trong bước thiết kế cơ sở dữ liệu logic là chuyển từ lược đồ ER sang lược đồ cơ sở dữ liệu quan hệ. Chúng tôi sẽ bàn chi tiết trong chương 3, kết quả thu được cuối cùng là lược đồ khái niệm, đôi khi gọi là lược đồ logic trong mô hình dữ liệu quan hệ.

Phía sau của thiết kế ER

Lược đồ ER chỉ là biểu diễn tương đối của dữ liệu, được xây dựng dựa trên đánh giá chủ quan trong quá trình thu thập dữ liệu ở bước phân tích yêu cầu. Nhiều phân tích cẩn thận hơn được xem xét trong lược đồ logic ở cuối bước 3. Khi chúng ta có lược đồ logic tốt, chúng ta phải xem xét điều kiện thực hiện và thiết kế lược đồ vật lý. Cuối cùng, chúng ta phải cụ thể hóa những vấn đề về bảo mật và đảm bảo rằng những người sử dụng có thể truy cập thấy thông tin mà họ cần. Ba bước thiết kế cơ sở dữ liệu còn lại được trình bày tóm tắt trong phần sau:

Tinh chỉnh lược đồ: Bước thứ 4 của thiết kế là phân tích tập hợp các quan hệ trong lược đồ cơ sở dữ liệu quan hệ để xác định các vấn đề cần thiết và xem xét lại nó. Ngược lại với bước phân tích yêu cầu và thiết kế khái niệm, nơi tập trung chủ yếu vào các đối tượng, thì bước này chúng ta phải thực hiện việc tinh chỉnh lược đồ bằng những hướng dẫn nặng về lý thuyết hơn. Chúng ta sẽ bàn đến các dạng chuẩn của quan hệ và tìm hiểu sâu sắc hơn trong chương 19.
Thiết kế cơ sở dữ liệu vật lý: Trong bước này chúng ta phải xem xét khối lượng công việc mà cơ sở dữ liệu của chúng ta phải hỗ trợ và xem xét lại thiết kế cơ sở dữ liệu để đảm bảo rằng nó thỏa mãn các điều kiện thực thi. Bước này có thể bao gồm việc xây dựng các chỉ số trên một số bảng và phân cụm một số bảng, hoặc có thể bao gồm việc thiết kế lại đáng kể các phần trong lược đồ cơ sở dữ liệu đạt được từ các bước thiết kế trước. Chúng tôi sẽ trình bày về thiết kế cơ sở dữ liệu vật lý và điều chỉnh cơ sở dữ liệu trong chương 20.
Thiết kế ứng dụng và bảo mật: Bất kỳ dự án phần mềm nào phát triển trên DBMS cũng phải xem xét những khía cạnh của ứng dụng phía trước, và dựa trên cơ sở dữ liệu đã tồn tại trước đó. Phương pháp thiết kế như UML (phần 7) cố gắng để cụ thể hóa vòng tròn thiết kế và phát triển phần mềm khép kín. Tóm lại, chúng ta phải xác định các thực thể (ví dụ: người dùng, nhóm người dùng, phòng/ban) và các quá trình cần thực hiện trong ứng dụng. Chúng ta phải biểu diễn các vai trò của mỗi thực thể trong tất cả các quá trình xử lý. Với mỗi vai trò (role), chúng ta phải xác định các phần của cơ sở dữ liệu được phép hoặc không được truy cập, và chúng ta phải đảm bảo rằng chúng chỉ được truy cập vào các phần cần thiết. DBMS cung cấp một vài cơ chế để hỗ trợ bước này, và chương 21 sẽ trình bày về vấn đề này.

Trong giai đoạn thực hiện này, chúng ta phải sử dụng ngôn ngữ lập trình để viết chương trình cho mỗi phần việc trong ứng dụng (ví dụ: Java), sử dụng DBMS để truy cập dữ liệu. Chương 6 và 7 sẽ trình bày phần phát triển ứng dụng.

Tóm lại, việc chia thành 6 bước nên được xem như việc phân lớp quá trình thiết kế. Quá trình này có thể diễn ra tuần tự hoặc vòng tròn, lặp đi lặp lại.

Thực thể, thuộc tính và kiểu thực thể

Thực thể là tập đối tượng trong thế giới thực giúp ta phân biệt với các đối tượng khác. Ví dụ: đồ chơi (của Green Dragonzord), văn phòng, người quản lý của văn phòng, địa chỉ nhà của người quản lý của văn phòng. Người ta thường xác định một tập các thực thể tương đương nhau. Tập hợp này được gọi là kiểu thực thể. Ghi nhớ rằng tập các thực thể không cần được tách rời nhau; tập hợp những nhân viên làm việc trong văn phòng và tập hợp những nhân viên trong phòng thiết bị có thể đều nằm trong tập hợp các nhân viên của công ty. Chúng ta có thể định nghĩa kiểu thực thể này là Employees chứa toàn bộ nhân viên trong cả hai phòng.

Một thực thể được biểu diễn bằng một tập các thuộc tính. Tất cả các thực thể trong cùng một kiểu phải có cùng tập thuộc tính. Những lựa chọn của chúng ta về tập thuộc tính phản ánh mức chi tiết về dữ liệu mà chúng ta mong muốn được biểu diễn trong thực thể. Ví dụ, kiểu thực thể Employees có thể có các thuộc tính: Tên (Name), Số bảo hiểm xã hội (social security number -ssn). Trong trường hợp này, cơ sở dữ liệu lưu trữ thông tin về tên, số bảo hiểm xã hội của các nhân viên. Tuy nhiên, chúng ta sẽ không lưu trữ được địa chỉ của nhân viên (hoặc giới tính, tuổi).

Với mỗi thuộc tính trong kiểu thực thể, chúng ta phải xác định miền giá trị của nó. Ví dụ, miền giá trị của thuộc tính Name trong kiểu thực thể Employees có thể có kiểu dữ liệu là xâu ký tự, chiều dài tối đa 20 ký tự.

Để tránh nhầm lẫn, chúng ta giả sử rằng tên các thuộc tính của cùng kiểu thực thể không trùng nhau.

Một ví dụ khác, nếu trong công ty có sự xếp hạng nhân viên từ 1 đến 10 thì cơ sở dữ liệu phải có một thuộc tính để lưu thông tin này, có thể là thuộc tính rating và miền giá trị của nó sẽ là 1 đến 10. Thêm vào đó, với mỗi kiểu thực thể, chúng ta cần lựa chọn thuộc tính khóa cho nó. Khóa là tập tối thiểu các thuộc tính trong kiểu thực thể có khả năng xác định duy nhất một thực thể (Hay nói cách khác, khóa phải có khả năng phân biệt được thực thể này với thực thể khác). Có thể có nhiều hơn một khóa dự tuyển; chúng ta sẽ lựa chọn một trong số các khóa dự tuyển để làm khóa chính. Từ bây giờ chúng ta sẽ giả sử rằng, mỗi kiểu thực thể chứa ít nhất một tập các thuộc tính để xác định duy nhất một thực thể trong kiểu thực thể đó; gọi là tập thuộc tính khóa. Chúng ta sẽ xem xét vấn đề này trong phần 4.3.

Kiểu thực thể Employees có các thuộc tính ssn, name, và rất nhiều các thuộc tính khác được chỉ ra trong hình 1. Một kiểu thực thể được biểu diễn bằng một hình chữ nhật, một thuộc tính được biểu diễn bằng một hình bầu dục. Thuộc tính có gạch chân ở dưới là thuộc tính khóa. Trong hình 1, thuộc tính khóa là ssn.

Liên kết và kiểu liên kết

Liên kết là mối quan hệ giữa hai hoặc nhiều thực thể. Ví dụ, chúng ta có thể có liên kết Attishoo làm việc trong văn phòng dược. Với nhiều thực thể cùng kiểu, chúng ta có tập các liên kết tương đương nhau tạo thành kiểu liên kết. Một kiểu liên kết có thể được xem như một tập của n- tupes:

\{(e_{1}, . . ., e_{n}) ∣ e_{1} \in E_{1}, . . ., e_{n} \in E_{n}\}

Mỗi n-tupe biểu thị một mối liên kết bao gồm n thực thể từ e₁ tới e_n, trong đó thực thể e_i thuộc tập thực thể E_i. Trong Hình 2 chúng ta chỉ ra kiểu liên kết Works_In, trong đó mỗi liên kết chỉ ra một department mà một nhân viên làm việc.

Một liên kết có thể có các thuộc tính mô tả. Thuộc tính mô tả được sử dụng để ghi lại những thông tin về mối liên kết, những thông tin này không nên để ở những thực thể thành phần tham gia trong mối liên kết. Ví dụ, chúng ta muốn ghi lại thời gian bắt đầu làm việc của Attishoo ở văn phòng dược từ tháng 1 năm 1991. Thông tin này được minh họa trong hình 2 bằng việc thêm vào một thuộc tính since trong mối liên kết Works_In. Trong kiểu liên kết Works_In, ví dụ, mỗi liên kết Works_In phải được xác định duy nhất bằng việc kết hợp ssn của thực thể Employee với did của thực thể Department. Vì thế, với mỗi cặp employee-department, chúng ta không thể có nhiều hơn một giá trị since.

Một minh họa của một kiểu liên kết là một tập các liên kết. Một minh họa có thể được xem như một 'snapshot' của một kiểu liên kết ở một thời điểm nào đó. Một minh họa của kiểu liên kết Works_In được chỉ ra trong hình 3. Mỗi thực thể Employee được đại diện bằng thuộc tính ssn của nó, và mỗi thực thể Department được đại diện bằng thuộc tính did. Giá trị của thuộc tính since được chỉ ra bên trong mỗi liên kết. Những chú thích 'many-to-many' (nhiều-nhiều) và 'total participation' (lực lượng tham gia toàn bộ) sẽ được trình bày chi tiết trong phần sau, khi chúng tôi bàn về những ràng buộc toàn vẹn.

Một ví dụ khác của lược đồ ER, giả sử rằng mỗi Department có một vài vị trí khác nhau và chúng ta muốn ghi lại vị trí văn phòng của từng nhân viên làm việc. Mối liên kết này là mối liên kết bậc 3 vì chúng ta phải ghi lại mối liên quan giữa Employee, Department và Location. Kiểu liên kết Works_In được biến thể thành kiểu liên kết Work_In2, lược đồ ER chỉ ra trong Hình 4.

Các kiểu thực thể tham gia trong một kiểu liên kết không nhất thiết phải là hai kiểu thực thể khác nhau; đôi khi tồn tại kiểu liên kết giữa hai thực thể cùng kiểu. Ví dụ, xem xét mối liên kết Reports_To được chỉ ra trong hình 5. Vì những nhân viên có thể báo cáo tới những nhân viên khác, nên tất cả các liên kết trong Reports_To ở dạng (emp1, emp2), nơi mà cả hai thực thể emp1 và emp2 đều là thực thể của Employees. Tuy nhiên, chúng đóng vai trò khác nhau: emp1 báo cáo tới người quản lý là emp2, điều này phản ánh vai trò của người quản lý (supervisor) và nhân viên dưới quyền (subordinate), hình 5. Nếu một kiểu thực thể có nhiều hơn một vai trò, thì vai trò này được thể hiện trong thuộc tính định danh. Ví dụ, mối liên kết Reports_To có những thuộc tính liên quan tới ssn của người quản lý và ssn của nhân viên cấp dưới và tên của các thuộc tính này là supervisor_ssn và subordinate_ssn.

Những đặc trưng khác của mô hình ER

Chúng ta xem xét một số các thành phần khác của mô hình ER để có thể biểu diễn được các đặc điểm đặc biệt của dữ liệu. Khả năng biểu diễn tốt của mô hình ER là lý do chính khiến nó được sử dụng rộng rãi.

Ràng buộc khóa

Xem xét mối liên kết Works_In trong hình 2. Một nhân viên có thể làm việc trong nhiều phòng, và một phòng có thể có nhiều nhân viên làm việc. Nhân viên 231-31-5368 đang làm việc cho phòng 51 từ 3/3/93 và phòng 56 từ 2/2/92. Phòng 51 có 2 nhân viên.

Bây giờ, chúng ta xem xét một kiểu liên kết khác gọi là Manages (quản lý) giữa hai kiểu thực thể Employees và Departments với nguyên tắc quản lý là mỗi một phòng có nhiều nhất một người quản lý và một nhân viên có thể quản lý nhiều hơn một phòng. Sự giới hạn mỗi phòng có nhiều nhất một người quản lý là một ví dụ về ràng buộc khóa, và nó ngụ ý rằng mỗi thực thể Department xuất hiện ít nhất một mối liên kết Manages trong bất kỳ minh họa nào của Manages. Giới hạn này được chỉ ra trong lược đồ ER của hình 6 thông qua mũi tên từ Departments tới Manages. Theo hình vẽ, gốc mũi tên đặt ở thực thể Departments, có nghĩa là có duy nhất một liên kết giữa thực thể Departments với Manages.

Kiểu liên kết như Manages đôi khi được gọi là kiểu liên kết một-nhiều (one-to-many), để chỉ ra rằng một Employee có thể kết hợp với nhiều Departments (tùy thuộc vào khả năng của người quản lý), ngược lại, mỗi Department chỉ có thể kết hợp với một Employees như là người quản lý của nó. Ngược lại, kiểu liên kết Works_In, mỗi Employee được phép làm việc cho một số Departments và một Department có thể có nhiều Employees làm việc, được gọi là kiểu liên kết nhiều-nhiều.

Nếu ta thêm một giới hạn với mối liên kết Manages là: mỗi nhân viên có thể quản lý nhiều nhất một phòng, thì trong hình 6 mô hình sẽ phải thêm vào mỗi mũi tên từ Employees tới Manages . Kiểu liên kết này trở thành kiểu liên kết 1-1.

Ràng buộc khóa trên kiểu liên kết bậc 3

Chúng ta có thể mở rộng quy định này với những kiểu liên kết bậc 3, gồm ba kiểu thực thể trở lên: Nếu kiểu thực thể E có ràng buộc khóa trên kiểu liên kết R, mỗi thực thể trong minh họa của E xuất hiện trong ít nhất một liên kết của R. Để xác định ràng buộc khóa trên kiểu thực thể E trong kiểu liên kết R, chúng ta vẽ một mũi tên từ E đến R.

Trong hình 8 chúng ta chỉ ra kiểu liên kết bậc 3 với những ràng buộc khóa. Mỗi nhân viên làm việc trong nhiều nhất một phòng và chỉ ở một địa điểm duy nhất. Hình 9 minh họa kiểu liên kết Works_In3. Ghi nhớ rằng mỗi một Department có thể liên kết với một số Employees và Locations, và mỗi Location có thể liên kết với một vài Departments và Employees; tuy nhiên, mỗi Employee chỉ liên kết với duy nhất một Department và Location.

Mối liên kết bậc 3 cùng với ràng buộc khóa

Các ràng buộc về lực lượng tham gia liên kết

Ràng buộc khóa trên Manages cho chúng ta biết rằng một Department có nhiều nhất một người quản lý. Một câu hỏi tự nhiên là có phải tất cả các Department đều phải có một người quản lý không. Chúng ta cứ giả sử rằng tất cả các Department đều yêu cầu có một người quản lý thì sự tham gia của kiểu thực thể Departments trong kiểu liên kết Manages được gọi là toàn bộ (total). Sự tham gia không toàn bộ được gọi là bộ phận (partial). Ví dụ, sự tham gia của kiểu thực thể Employees trong kiểu liên kết Manages là tham gia bộ phận, vì không phải Employees nào cũng làm quản lý của Department.

Xem xét kiểu liên kết Works_In, điều mong muốn tự nhiên là mỗi Employee làm việc trong ít nhất một Department và mỗi Department có ít nhất một Employee. Điều đó có nghĩa rằng lực lượng của cả hai kiểu thực thể Employees và Departments tham gia trong kiểu liên kết Works_In là toàn bộ. Lược đồ ER trong Hình 10 chỉ ra cả hai kiểu liên kết Manages và Works_In và những ràng buộc của nó. Nếu sự tham gia của kiểu thực thể trong kiểu liên kết là toàn bộ, cả hai đường nối đều là đường đậm; không lệ thuộc vào biểu diễn của đường mũi tên như đối với ràng buộc khóa. Minh họa của Works_In và Manages được chỉ ra trong hình 3 và 7 đều thỏa mãn những ràng buộc trong Hình 10.

Thực thể yếu

Ở phần trên, chúng ta đã giả sử rằng tất cả các thực thể đều có một tập thuộc tính đóng vai trò là khóa. Giả sử này không phải luôn đúng. Ví dụ, giả sử rằng một nhân viên muốn mua bảo hiểm cho những người phụ thuộc vào họ. Chúng ta mong muốn ghi lại những thông tin liên quan đến bảo hiểm, bao gồm những ai là người phụ thuộc vào nhân viên đó. Thông tin này chỉ liên quan đến một nhân viên cụ thể. Nếu nhân viên đó hoàn thành bảo hiểm, thì chúng ta cũng muốn những thông tin về những người liên quan cũng bị xóa khỏi cơ sở dữ liệu. Trong trường hợp này, chúng ta xác định người phụ thuộc dựa vào tên của họ, vì chúng ta suy nghĩ rằng những người phụ thuộc vào một nhân viên nào đó sẽ không có tên trùng nhau. Vì thế, những thuộc tính của kiểu thực thể Dependents (Người phụ thuộc) có thể gồm pname và age. Thuộc tính pname không xác định một người phụ thuộc duy nhất trong kiểu thực thể Dependents vì có thể có hai người phụ thuộc vào hai nhân viên khác nhau có tên trùng nhau.

Dependents là một ví dụ về kiểu thực thể yếu.Một thực thể yếu có thể được xác định duy nhất chỉ khi khóa chính của nó được tạo ra bằng sự kết hợp một vài thuộc tính của nó với thuộc tính khóa chính của kiểu thực thể chủ.

Một số giới hạn cần biết:

Kiểu thực thể chủ và kiểu thực thể yếu phải tham gia trong kiểu liên kết một-nhiều (một thực thể chủ được tham gia cùng với một hoặc nhiều thực thể yếu, nhưng mỗi thực thể yếu chỉ có một thực thể làm chủ nó). Kiểu liên kết này được gọi là kiểu liên kết định danh (identifying relationship set) của kiểu thực thể yếu.
Kiểu thực thể yếu phải có lực lượng tham gia toàn bộ vào trong kiểu liên kết định danh.

Ví dụ, một thực thể Dependents có thể được xác định duy nhất chỉ khi chúng ta kết hợp thuộc tính pname với thuộc tính khóa của kiểu thực thể Employees. Tập thuộc tính xác định của kiểu thực thể yếu được gọi là khóa thành phần (partial key). Trong ví dụ của chúng ta, thuộc tính pname là khóa thành phần của Dependents.

Kiểu thực thể yếu Dependents và liên kết của nó với Employees được chỉ ra trong hình 11. Sự tham gia toàn bộ của Dependents trong Policy

Policy có thể được hiểu là Mối quan hệ (cha, mẹ, con cái…) giữa nhân viên và những người phụ thuộc vào họ. Thuộc tính cost của liên kết Policy trong Hình 11 dùng để lưu lại khoản tiền được khấu trừ tương ứng với từng mối quan hệ (trong tính thuế thu nhập).

được chỉ ra bằng đường nối đậm giữa chúng. Mũi tên từ Dependents tới Policy chỉ ra rằng chính xác một thực thể Dependents xuất hiện trong ít nhất một mối liên kết Policy. Để chỉ ra Dependents là thực thể yếu và Policy là kiểu liên kết định danh, chúng tôi vẽ cả hai với đường nét đậm. Để chỉ ra pname là khóa thành phần của Dependents, chúng ta gạch đường nét đứt dưới thuộc tính đó.

Hệ thống phân cấp

Đôi khi, trong tự nhiên chúng ta cần phân lớp các thực thể trong một kiểu thực thể vào các lớp con. Ví dụ, chúng ta muốn nói về kiểu thực thể Hourly_Emps (nhân viên làm việc theo giờ) và kiểu thực thể Contract_Emps (nhân viên hợp đồng) để phân biệt về hình thức thanh toán lương cho hai kiểu nhân viên này. Chúng ta có lẽ có các thuộc tính hours_worked và hourly_wage để xác định cho thực thể Hourly_Emps và thuộc tính contractid cho thực thể Contract_Emps.

Chúng ta muốn tất cả các thực thể này đều thuộc về kiểu thực thể Employees, và chúng phải có tất cả các thuộc tính của Employees. Vì thế, những thuộc tính được xác định trong thực thể Hourly_Emps là những thuộc tính của kiểu thực thể Employees cộng với Hourly Emps. Chúng ta nói rằng những thuộc tính của kiểu thực thể Hourly_Emps được kế thừa từ các thuộc tính của Employees, và Hourly_Emps ISA Employees. Hình 12 minh họa hệ thống phân cấp này.

Kiểu thực thể Employees có lẽ được phân cấp sử dụng các điều kiện khác nhau. Ví dụ, chúng ta có thể có một tập các nhân viên như Senior_Emps. Chúng ta có thể sửa Hình 12 để phản ánh những thay đổi bằng việc thêm vào một nút ISA thứ 2 như nút con của Employees và Senior Emps là con của nút này. Mỗi kiểu thực thể có thể được xa hơn, tạo ra một hệ cây ISA đa cấp.

Hệ thống phân cấp được biểu diễn bằng một trong hai cách:

Employees được chia vào trong các lớp con. Chuyên biệt hoá là quá trình xác định các tập con của một kiểu thực thể lớp cha (superclass)- kiểu thực thể có một số các đặc tính phân biệt giữa thực thể này với thực thể khác. Thông thường, kiểu thực thể lớp cha được định nghĩa trước, tiếp theo định nghĩa các kiểu thực thể con, sau đó xác định các thuộc tính của các kiểu thực thể lớp con và kiểu liên kết của nó với kiểu thực thể lớp cha.
Hourly_Emps và Contract_Emps được tổng quát hoá thành Employees. Một ví dụ khác, hai kiểu thực thể Motorboats và Cars có thể được tổng quát thành kiểu thực thể Motor Vehicles. Tổng quát hoá thực hiện việc xác định một số đặc tính chung của tập các thực thể con và tạo ra thực thể mới xử lý các đặc tính chung này. Thông thường, những kiểu thực thể lớp con được định nghĩa trước, lớp cha được định nghĩa sau, sau đó các kiểu liên kết được xác định.

Chúng ta có thể xác định hai kiểu của ràng buộc phản chiếu trong mô hình ISA, tên là ràng buộc Overlap và Covering. Ràng buộc Overlapxác định có hay không hai lớp con được phép nằm trong cùng một thực thể. Ví dụ, Attishoo có thể thuộc cả về thực thể Hourly_Emps và Contract_Emps không? Bằng trực giác là không. Anh ấy có thể thuộc cả về thực thể Hourly_Emps và Contract_Emps không? Bằng trực giác là có. Chúng ta biểu diễn điều này bằng việc viết 'Contract_Emps OVERLAPS Senior Emps'. Nếu không có ghi chú này, chúng ta mặc định rằng kiểu thực thể không có ràng buộc Overlap.

Ràng buộc covering xác định có hoặc không một lớp cha chứa tất cả các thực thể trong các lớp con. Ví dụ, tất cả các thực thể Empolyees thuộc về một lớp cha của nó? Bằng trực giác là không. Tất cả các thực thể Motor_Vehicles phải thuộc về thực thể Motorboats hoặc thực thể Cars? Bằng trực giác là có; đặc tính đặc trưng của những hệ thống tổng quát hóa là tất cả những mô tả của lớp cha là mô tả của lớp con. Chúng ta biểu diễn bằng việc viết 'Motorboats AND Cars COVER Motor_Vehicles.' Trong trường hợp không có chú thích này, chúng ta mặc định rằng kiểu thực thể không có ràng buộc covering; chúng ta có thể có những Motor Verhicles không phải là Motorboats, cũng không là Cars.

Có hai lý do chính cho việc xác định lớp con (bằng chuyên biệt hóa hoặc tổng quát hóa):

Chúng ta muốn thêm những thuộc tính biểu diễn vào các thực thể trong lớp con. Ví dụ, thuộc tính hourly wages không cần thiết cho thực thể Contract_Emps, vì lương của đối tượng này được xác định thông qua hợp đồng cá nhân.
Chúng ta muốn chỉ ra tập các thực thể tham gia trong một vài liên kết. Ví dụ, chúng ta có thể muốn xác định kiểu liên kết Manages giữa Senior_Emps và Departments để đảm bảo rằng chỉ có có những Senior Employees (nhân viên cao cấp) mới có thể là người quản lý.

Khối kết hợp

Như chúng ta đã định nghĩa ở trên, một kiểu liên kết sẽ được tạo thành giữa hai kiểu thực thể. Nhưng đôi khi, chúng ta phải mô hình hóa một liên kết giữa tập hợp các thực thể và các kiểu liên kết (relationships). Giả sử rằng chúng ta có kiểu thực thể là Projects và mỗi một Project được tài trợ bằng một hoặc nhiều Departments. Kiểu quan hệ Sponsors (Tài trợ) biểu diễn thông tin này. Một Department tài trợ một Project, Department này có thể cử nhân viên để quản lý (monitor) việc tài trợ. Như thế, Monitors nên là kiểu liên kết giữa Sponsors (tốt hơn là Projects hoặc Departments) với Employees.

Tuy nhiên, như chúng ta đã định nghĩa thì kiểu liên kết được tạo thành giữa hai hoặc nhiều kiểu thực thể. Vì thế, để định nghĩa kiểu liên kết như là Monitors, chúng tôi giới thiệu một khả năng mới của mô hình ER, gọi là Khối kết hợp. Khối kết hợp cho phép chúng ta minh họa một kiểu liên kết (chỉ ra bằng hộp nét đứt) kết nối với một kiểu liên kết khác. Minh họa trong Hình 13, hộp nét đứt xung quanh Sponsors (và các kiểu thực thể thành phần) sử dụng để biểu diễn Khối kết hợp. Điều này cho phép chúng ta xem Sponsors như một kiểu thực thể tham gia trong kiểu liên kết Monitors.

Khi nào chúng ta nên sử dụng Khối kết hợp? Như ta đã phân tích, chúng ta sử dụng nó khi chúng ta cần biểu diễn một mối liên kết giữa các mối liên kết. Nhưng với những kiến thức chúng ta đã học, chúng ta không thể biểu diễn được điều này nếu không sử dụng Khối kết hợp. Tuy nhiên, các bạn có thể đặt ra câu hỏi, tại sao trong ví dụ trên, chúng ta không biến Sponsors thành kiểu liên kết bậc ba?

Bởi vì, ở đây là hai kiểu liên kết bậc hai khác nhau, Sponsors và Monitors, mỗi kiểu liên kết có thuộc tính riêng của nó. Theo như minh họa, mối liên kết Monitors có một thuộc tính là Until để ghi lại ngày mà một nhân viên được cử là quản lý sự tài trợ. So sánh thuộc tính này với thuộc tính Since của Sponsors, là ngày bắt đầu mà Department tài trợ cho Project. Sử dụng Khối kết hợp hay sử dụng kiểu liên kết bậc ba được cân nhắc bằng việc xem xét các ràng buộc tham chiếu của dữ liệu, giải thích trong 5.4.

Thiết kế cơ sở dữ liệu mức khái niệm bằng mô hình ER

Quá trình xây dựng lược đồ ER phải thực hiện một số lựa chọn sau:

Một khái niệm nào đó nên được mô hình hóa như một thực thể hay là một thuộc tính?
Một khái niệm nào đó nên được mô hình hóa như một thực thể hay là một liên kết?
Có những kiểu liên kết nào và các kiểu thực thể tham gia trong kiểu quan hệ đó? Chúng ta nên sử dụng kiểu liên kết bậc hai hay bậc ba?
Có nên sử dụng khối kết hợp hay không?

Chúng ta sẽ bàn những vấn đề này trong phần tiếp theo.

Thực thể hay thuộc tính

Trong khi xác định các thuộc tính của kiểu thực thể, nên tìm hiểu rõ ràng một đặc trưng dữ liệu nào đó nên là một thuộc tính hay là một kiểu thực thể. Ví dụ, chúng ta đề cập đến việc thêm thông tin về địa chỉ vào kiểu thực thể Employees. Lựa chọn đầu tiên là ta thêm một thuộc tính address. Lựa chọn này là thích hợp nếu chúng ta chỉ cần ghi lại một địa chỉ ứng với một nhân viên, và coi rằng toàn bộ địa chỉ là một xâu ký tự. Lựa chọn thứ hai là tạo ra một kiểu thực thể có tên Address, để ghi lại địa chỉ của nhân viên chúng ta sử dụng một liên kết giữa Employees và Address (ví dụ là Has_address). Lựa chọn này phức tạp hơn nhưng là cần thiết trong hai trường hợp:

Chúng ta phải ghi lại nhiều hơn một địa chỉ ứng với một nhân viên.
Chúng ta muốn ghi lại cấu trúc của địa chỉ trong lược đồ ER. Ví dụ, chúng ta muốn chia địa chỉ rõ ràng thành: city (thành phố), nước (Country), và Zip_code (mã bưu chính), và thông tin về đường phố. Với cách thể hiện Address như là một kiểu thực thể và các thuộc tính của nó, chúng ta có thể truy vấn thông tin về tất cả các địa chỉ của một nhân viên nào đó.

Một ví dụ khác về mô hình hóa một khái niệm bằng một kiểu thực thể thay vì một thuộc tính được đề cập trong kiểu liên kết (gọi là Works_In2) trong Hình 14.

Kiểu liên kết Works_In2 khác với kiểu liên kết Works_In trong Hình 2 chỉ là thuộc tính since được thay bằng hai thuộc tính from và to. Trong trường hợp này, hai thuộc tính trên sẽ ghi lại toàn bộ quá trình một nhân viên làm việc cho một phòng nào đó. Bây giờ, chúng ta giả sử rằng một nhân viên có thể làm việc cho một phòng ở nhiều quãng thời gian khác nhau.

Khả năng này được biểu diễn trong lược đồ ER. Vấn đề ở đây là chúng ta muốn ghi lại một số giá trị để biểu diễn thuộc tính của mỗi thể hiện của liên kết Works_In2. (Trường hợp này tương tự với việc muốn ghi lại một vài địa chỉ ứng với một nhân viên). Chúng ta có thể thực hiện điều này bằng việc sử dụng một kiểu thực thể là Duration, với các thuộc tính là from và to, như trong Hình 15.

Trong một số phiên bản của mô hình ER, một thuộc tính nào đó có thể mang nhiều hơn một giá trị (còn gọi là thuộc tính đa trị). Với phiên bản này, chúng ta có thể xem Duration như là một thuộc tính đa trị của Work_In thay vì nó phải là một kiểu thực thể kết nối với kiểu liên kết Works_In như trên. Cách làm này có lẽ trực quan hơn là ta mô hình hóa Duration như một kiểu thực thể. Tuy nhiên, khi đặt những giá trị của thuộc tính này vào mô hình quan hệ - mô hình không hỗ trợ thuộc tính có nhiều giá trị, thì cuối cùng lược đồ quan hệ của mô hình quan hệ cũng tương tự như là chúng ta xem Duration như một kiểu thực thể.

Thực thể hay liên kết

Xem xét một kiểu liên kết là Manages trong Hình 6. Giả sử rằng mỗi một người quản lý của Department được cung cấp một khoản tài chính (dbugget), như chỉ ra trong Hình 16 (kiểu liên kết Manages được đổi tên thành Manages2).

Ở đó có nhiều nhất một Employee quản lý một Department, nhưng một Employee lại có thể quản lý nhiều Departments, chúng ta lưu lại ngày bắt đầu làm quản lý và khoản tài chính của mỗi cặp người quản lý- phòng (manager-department). Cách tiếp cận này là tự nhiên nếu chúng ta giả sử rằng một người quản lý chỉ nhận một khoản tài chính ứng với phòng người ấy quản lý.

Nhưng điều gì sẽ xảy ra nếu chúng ta coi dbudget là tổng số tiền quản lý của một người đối với tất cả các Department mà người đó quản lý? Trong trường hợp này, mỗi liên kết Manages2 ứng với một nhân viên làm quản lý sẽ có cùng giá trị trong trường dbudget, dẫn tới lưu trữ dư thừa cùng một thông tin. Vấn đề khác gặp phải nếu thiết kế như thế này đó là nó dẫn tới sự sai lạc; nó chỉ ra một Budget (khoản tài chính) kết nối với một liên kết, trong khi khoản tài chính này liên quan thực sự đến một người quản lý.

Chúng ta có thể giải quyết vấn đề này bằng việc giới thiệu một kiểu thực thể mới gọi là Managers (có thể đặt sau Emloyees trong hệ thống ISA, để chỉ ra người quản lý cũng là một nhân viên). Thuộc tính since và dbudget biểu diễn một thực thể Manager như dự định. Tuy nhiên, trong khi tất cả người quản lý chỉ có một giá trị dbudget, nhưng lại có thể có nhiều giá trị của ngày bắt đầu làm quản lý (since) ứng với mỗi Department. Trong trường hợp này, dbudget là thuộc tính của Managers, nhưng since lại là thuộc tính của kiểu liên kết giữa Managers với Departments.

Biểu diễn tự nhiên thiếu chính xác của mô hình ER có thể dẫn đến khó khăn trong việc nhận ra những thực thể cơ bản, và chúng ta có thể sử dụng các thuộc tính gắn vào kiểu liên kết thay vì sử dụng những kiểu thực thể. Tóm lại, những lỗi trên sẽ dẫn đến lưu trữ dư thừa cùng một thông tin và từ đó nảy sinh nhiều vấn đề. Chúng ta sẽ bàn đến dư thừa thông tin và những vấn đề liên quan trong chương 19, và trình bày một công nghệ gọi là Chuẩn hóa (Nomalization) để loại trừ dư thừa trong các bảng chứa dữ liệu.

Liên kết bậc hai hay bậc ba

Xem xét sơ đồ ER trong Hình 17. Nó mô hình hóa trường hợp một Employee có thể có một vài Policies và mỗi Policy có thể thuộc về một số Employees, và mỗi Dependent có thể có một số Policies.

Giả sử rằng, chúng ta có một số yêu cầu sau:

Bất kỳ một Policy nào cũng không thể được hai hoặc nhiều hơn Employees cùng sở hữu.
Policy nào cũng phải có Employees nào đó làm chủ.
Dependents là kiểu thực thể yếu, và mỗi một thực thể Dependent được xác định duy nhất bằng thuộc tính pname kết hợp với thuộc tính policyid của thực thể Policy.

Yêu cầu đầu tiên đề nghị rằng chúng ta phải thiết đặt một ràng buộc khóa lên trên Policies trong liên kết với Covers, nhưng ràng buộc này không yêu cầu rằng một Policy có thể ảnh hưởng chỉ tới một Dependent. Yêu cầu thứ hai đề nghị chúng ta thiết đặt ràng buộc tham gia toàn bộ lên Policies. Giải pháp này có thể chấp nhận nếu mỗi Policy ảnh hưởng tới ít nhất một Dependent. Yêu cầu thứ ba bắt buộc chúng ta sử dụng đến kiểu liên kết định danh.

Nếu bỏ qua yêu cầu thứ ba ở trên, cách tốt nhất để mô hình hóa trường hợp này là sử dụng hai kiểu liên kết bậc hai, chỉ ra trong Hình 18.

Ví dụ này có hai kiểu liên kết bao gồm liên quan đến Policies, và chúng ta cố gắng sử dụng một kiểu liên kết bậc ba (Hình 17) là không phù hợp. Tuy nhiên, có những trường hợp ở đó một mối liên kết vốn đã liên quan đến nhiều hơn hai thực thể. Chúng ta đã nhìn thấy ví dụ trong Hình 4 và 15.

Như là một ví dụ điển hình của mối liên kết bậc ba, kiểu thực thể Parts (Sản phẩm), Suppliers (Nhà cung cấp), và Departments (Phòng) và kiểu liên kết Contracts (Hợp đồng) cùng với thuộc tính biểu diễn qty gắn với Contracts. Một hợp đồng xác định rằng một Nhà cung cấp sẽ cung cấp (một số lượng) Sản phẩm cho Phòng. Liên kết này không thể biểu diễn bằng một tập các liên kết bậc hai (không sử dụng Khối kết hợp). Với kiểu liên kết bậc hai, chúng ta có thể chỉ ra rằng một Nhà cung cấp 'có thể cung cấp' đích xác một số Sản phẩm nào đó; một Phòng 'cần được cung cấp' đích xác một số Sản phẩm nào đó; một Phòng 'giao dịch trực tiếp' với đích xác một Nhà cung cấp nào đó. Tuy nhiên, không kết hợp những kiểu liên kết bậc hai này để biểu diễn một hợp đồng, vì ít nhất hai lý do:

Chúng ta không thể biểu diễn được mối liên kết đồng thời giữa ba kiểu thực thể này. Thực tế rằng, một nhà cung cấp (S) có thể cung cấp sản phẩm (P), một Phòng cần một số sản phẩm (P), và Phòng (D) sẽ mua từ nhà cung cấp (S) những sản phẩm mà S cung cấp.
Chúng ta không thể biểu diễn thuộc tính Qty một cách rõ ràng.

Khối kết hợp hay Kiểu liên kết bậc ba

Như chúng ta đã ghi chú trong Phần 4.5, lựa chọn giữa sử dụng Khối liên kết hay là kiểu liên kết bậc ba được xác định chủ yếu dựa vào tình trạng của liên kết giữa một kiểu liên kết với một kiểu thực thể. Lựa chọn này có thể cũng được định hướng bằng các ràng buộc tham chiếu chúng ta đang muốn biểu diễn. Ví dụ, xem xét lược đồ ER chỉ ra trong Hình 13. Theo lược đồ này, một Project có thể được tài trợ bằng bất kỳ Departments nào, một Department có thể tài trợ cho một hoặc nhiều Projects, và mỗi tài trợ (sponsorship) được một hoặc nhiều Employees điều hành. Nếu chúng ta không cần ghi lại thuộc tính until của Monitors, thì chúng ta có thể sử dụng kiểu liên kết bậc ba như Sponsors2 trong Hình 19.

Xem xét ràng buộc: mỗi tài trợ của một Department cho một Project được điều hành bằng nhiều nhất một nhân viên. Chúng ta thấy, chúng ta không thể biểu diễn được ràng buộc này nếu chỉ sử dụng kiểu liên kết Sponsor2. Trong khi đó, ràng buộc này lại có thể dễ dàng biểu diễn bằng việc vẽ một mũi tên từ Khối liên kết Sponsors tới kiểu liên kết Monitors như hình 13. Vì thế, khả năng biểu diễn các ràng buộc là một lý do nữa để sử dụng Khối kết hợp hay là kiểu liên kết bậc ba.

Sử dụng liên kết bậc ba thay vì Khối kết hợp

Thiết kế khái niệm cho các hệ thống lớn

Chúng ta đã tập trung trình bày những cấu trúc có thể trong mô hình ER để biểu diễn các khái niệm của ứng dụng và các mối liên kết giữa các khái niệm đó. Quá trình thiết kế cơ sở dữ liệu mức khái niệm bao gồm nhiều công đoạn, không đơn thuần là việc sử dụng lược đồ ER để biểu diễn các phần nhỏ của ứng dụng. Trong các hệ thống lớn, có nhiều người cùng tham gia thiết kế và viết chương trình ứng dụng. Sử dụng mô hình dữ liệu mức cao (mức ngữ nghĩa) như lược đồ ER cho thiết kế khái niệm giúp cho những người thiết kế và những người sử dụng sau này có thể dễ dàng hiểu nhau và hiểu dữ liệu.

Khía cạnh quan trọng của quá trình thiết kế là phương pháp luận sử dụng Thiết kế vòng tròn để đảm bảo rằng người thiết kế tiếp nhận được tất cả các yêu cầu cần thiết của người sử dụng. Cách tiếp cận thông thường là những yêu cầu của các nhóm người sử dụng được xem xét, bất kỳ những yêu cầu đối lập nhau được tìm hiểu và một tập hợp các yêu cầu duy nhất được đưa ra ở cuối của quá trình phân tích yêu cầu. Đưa ra được một tập hợp các yêu cầu duy nhất này là một công việc khó, nhưng nó cho phép quá trình thiết kế khái niệm và xây dựng lược đồ logic có thể bao quát được tất cả dữ liệu và ứng dụng trong hệ thống.

Một cách tiếp cận khác là xây dựng các lược đồ khái niệm riêng rẽ cho từng nhóm người dùng và sau đó tích hợp những lược đồ con này lại. Để tích hợp nhiều lược đồ con, chúng ta phải xây dựng mối quan hệ tương quan giữa các thực thể, kiểu liên kết và các thuộc tính và chúng ta phải giải quyết hàng loạt các vấn đề xung đột (ví dụ, xung đột về tên, miền dữ liệu không tương ứng, khác nhau giữa các đơn vị đo sử dụng). Công việc này là khó cho người đứng đầu. Trong một số trường hợp, việc tích hợp là không thể tránh khỏi, ví dụ, khi một tổ chức được hợp nhất vào một tổ chức khác, những cơ sở dữ liệu đang tồn tại phải được tích hợp.

UML

Có rất nhiều cách tiếp cận để thiết kế hệ thống phần mềm end-to-end, bao gồm tất cả các bước từ xác định yêu cầu đến bước cuối cùng để hoàn thành ứng dụng, bao gồm luồng tiến trình, giao diện người dùng, và rất nhiều khía cạnh của hệ thống phần mềm để có được cơ sở dữ liệu tốt. Trong phần này, chúng ta trình bày tóm tắt về cách tiếp cận đang trở nên phổ biến, gọi là cách tiếp cận UML.

UML, giống như mô hình ER, có một đặc trưng đáng chú ý là cấu trúc của nó có thể vẽ như những lược đồ. Nó chứa đựng một phổ rộng hơn của quá trình thiết kế phần mềm hơn là mô hình ER.

Mô hình hóa nghiệp vụ (Bussiness Modeling): Đích của quá trình này là biểu diễn các quy tắc nghiệp vụ trong quá trình phát triển ứng dụng phần mềm.
Mô hình hóa hệ thống (System Modeling): Những hiểu biết về quá trình nghiệp vụ được sử dụng để xác định các yêu cầu cho phần ứng dụng. Một phần của tập hợp yêu cầu là yêu cầu của cơ sở dữ liệu.
Mô hình hóa cơ sở dữ liệu khái niệm (Conceptual Database Modeling): Bước này giúp tạo ra lược đồ ER cho cơ sở dữ liệu. Với mục đích này, UML cung cấp nhiều cấu trúc song song với các cấu trúc của mô hình ER.
Mô hình hóa cơ sở dữ liệu vật lý (Physical Database Modeling): UML cũng cung cấp cách biểu diễn bằng hình tượng cho quá trình thiết kế cơ sở dữ liệu vật lý, như tạo ra các không gian bảng và các chỉ số (Chúng ta sẽ bàn về thiết kế cơ sở dữ liệu vật lý trong những chương sau, nhưng sẽ không đề cập đến cấu trúc UML).

Có rất nhiều loại của lược đồ trong UML. Lược đồ Use case (Trường hợp sử dụng) biểu diễn các hành động hệ thống thực hiện để phản hồi các yêu cầu của người dùng, và những người tham gia trong những hành động này. Những lược đồ này cũng xác định chức năng mở rộng mà người dùng mong muốn hệ thống hỗ trợ.

Lược đồ Activity (Hoạt động) chỉ ra một luồng các hoạt động trong quá trình nghiệp vụ. Lược đồ Statechart biểu diễn các hoạt động bên trong giữa các đối tượng hệ thống. Những lược đồ sử dụng trong mô hình nghiệp vụ và mô hình hệ thống sẽ biểu diễn những chức năng bên trong thực hiện như thế nào, bao gồm những quy tắc nghiệp vụ và các tiến trình của hệ thống.

Lược đồ Class (Lớp) tương tự như lược đồ ER, mặc dù chúng chủ yếu đề cập để mô hình hóa các thực thể ứng dụng (các thành phần quan trọng của chương trình) và mối quan hệ logic giữa các thực thể đó.

Cả kiểu thực thể và kiểu liên kết có thể được biểu diễn như các lớp trong UML, cùng với các ràng buộc khóa, kiểu thực thể yếu, và hệ thống phân cấp. Khái niệm liên kết được sử dụng khác một chút trong UML, và những liên kết trong UML đều là bậc hai. Điều này đôi khi dẫn đến nhầm lẫn nếu kiểu liên kết trong lược đồ ER có ba hoặc nhiều hơn các kiểu thực thể được biểu diễn trực tiếp trong UML. Nhầm lẫn này không xuất hiện nếu chúng ta hiểu rằng tất cả các kiểu liên kết (theo cách hiểu trong mô hình ER) được biểu diễn như là các lớp trong UML; liên kết UML bậc hai chỉ tập trung biểu diễn những liên kết giữa các kiểu thực thể và các kiểu liên kết trong lược đồ ER.

Kiểu liên kết cùng với các ràng buộc khóa thường được các lược đồ UML bỏ qua và kiểu liên kết được chỉ ra bằng các liên kết trực tiếp giữa các kiểu thực thể. Ví dụ, xem xét Hình 6, biểu diễn UML của lược đồ ER này sẽ có một lớp cho Employees, một lớp cho Departments và kiểu liên kết Manages được chỉ ra bằng liên kết giữa hai lớp này. Liên kết này có thể được gắn nhãn với tên và các thông tin khác để chỉ ra rằng một Phòng có thể có duy nhất một người quản lý.

Như chúng ta sẽ nhìn thấy trong chương 3, các lược đồ ER được chuyển vào mô hình quan hệ bằng cách ánh xạ mỗi kiểu thực thể vào một bảng và mỗi kiểu liên kết vào một bảng. Xa hơn nữa, chúng ta sẽ xem phần 3.5.3, bảng tương ứng với kiểu liên kết một-nhiều được bỏ qua và thêm vào một số thông tin về kiểu liên kết này vào một bảng liên quan trong liên kết. Vì thế, lược đồ Lớp liên quan chặt chẽ đến các bảng được tạo ra bằng việc ánh xạ lược đồ ER.

Thực vậy, tất cả các lớp trong lược đồ lớp UML được ánh xạ vào một bảng trong lược đồ cơ sở dữ liệu UML liên quan. Lược đồ database (Cơ sở dữ liệu) của UML chỉ ra các lớp được biểu diễn như thế nào trong cơ sở dữ liệu và những chi tiết về cấu trúc của cơ sở dữ liệu như là các ràng buộc tham chiếu và các chỉ số. Liên kết (UML's 'relationships') giữa các lớp UML dẫn đến hàng loạt các ràng buộc tham chiếu giữa các bảng liên quan. Rất nhiều chi tiết trong mô hình quan hệ (ví dụ: khung nhìn (Views), khóa ngoại (foreign keys), những trường cho phép rỗng (null-allowed fields)) và những lựa chọn khi thiết kế vật lý (ví dụ, các trường được chọn làm chỉ số) có thể được mô hình hoá trong lược đồ cơ sở dữ liệu UML.

Các thành phần của lược đồ UML mô tả những khía cạnh lưu trữ của cơ sở dữ liệu, như những khônggian bảng (tablespaces) và phân vùng cơ sở dữ liệu (database partitions), cũng như là các giao diện để ứng dụng truy cập cơ sở dữ liệu. Cuối cùng, lược đồ Deployment (triển khai) chỉ ra những khía cạnh phần cứng của hệ thống.

Mục đích của chúng tôi trong quyển sách này là tập trung vào lưu trữ dữ liệu trong cơ sở dữ liệu và các vấn đề thiết kế liên quan. Cuối cùng, chúng ta thảo luận một cách nhìn về các bước phải thực hiện khi thiết kế và phát triển phần mềm. Thêm vào đó, những thảo luận về UML, những trình bày trong phần này được sử dụng để giải quyết các vấn đề gặp phải khi thiết kế hệ thống lớn. Chúng tôi hy vọng rằng điều này sẽ giúp người đọc hứng thú trong những phần trình bày về thiết kế phần mềm và những bàn luận về những vấn đề khác để hoàn thành thiết kế tổng quan.

Trường hợp nghiên cứu: Cửa hàng Internet

Chúng tôi giới thiệu một minh hoạ, trường hợp nghiên cứu này sẽ được làm ví dụ trong toàn bộ cuốn sách. Công ty DBDudes, là một hãng tư vấn cơ sở dữ liệu nổi tiếng, đã được mời đến để giúp đỡ công ty B&N để thiết kế và thực thi cơ sở dữ liệu của công ty này. B&N là một kho sách lớn, đặc biệt là các sách về đua ngựa, và họ quyết định đưa những quyển sách này lên mạng. Công ty DBDudes đầu tiên xác định rằng B&N sẵn sàng trả kinh phí cho họ, sau đó lập lịch cho bữa ăn trưa - B&N phải thanh toán, tiếp đến là thực hiện phân tích các yêu cầu.

Phân tích các yêu cầu

Người chủ của B&N, không giống rất nhiều người cần cơ sở dữ liệu, có suy nghĩ rất rộng về những điều anh ấy muốn và viết trong một bản yêu cầu ngắn gọn:

"Tôi muốn những khách hàng của tôi có thể xem được danh mục các quyển sách và đặt mua chúng trên Internet. Hiện nay, tôi nhận những đơn đặt hàng bằng điện thoại. Tôi có các khách hàng là các tập thể, họ gọi điện cho tôi và cung cấp số ISBN của quyển sách và số lượng; họ thường thanh toán bằng thẻ tín dụng. Sau đó, tôi chuẩn bị những quyển sách họ đặt. Nếu tôi không có đủ số lượng sách trong kho, tôi đề nghị nhà xuất bản bổ sung và hoãn trả hàng cho khách cho tới khi tôi có đủ số lượng; Tôi muốn chuyển các hoá đơn của cùng một khách hàng một lần. Danh mục bao gồm tất cả các quyển sách mà tôi bán. Với mỗi quyển sách, danh mục có chứa thông tin về: số ISBN, tiêu đề, tác giả, giá bìa, giá bán, năm xuất bản. Hầu hết khách hàng của tôi là những khách quen, tôi muốn ghi lại thông tin về tên, địa chỉ của họ. Những khách mới phải gọi trước cho tôi và đăng ký một tài khoản trước khi họ muốn sử dụng website của tôi.

Trên website mới, khách hàng được xác định bằng một định danh duy nhất. Sau đó, họ có thể duyệt danh mục sách và đặt mua chúng trực tuyến."

Hãng tư vấn DBDudes nhanh chóng thu thập yêu cầu và trở lại văn phòng để phân tích những thông tin này.

Thiết kế khái niệm

Trong bước thiết kế khái niệm, DBDudes xây dựng biểu diễn mức cao của dữ liệu bằng những thuật ngữ của mô hình ER. Thiết kế đầu tiên này được chỉ ra trong Hình 20. Những quyển sách và khách hàng được mô hình hoá như là các thực thể và liên kết với nhau thông qua kiểu liên kết Orders (Đặt hàng). Với mỗi đơn đặt hàng, những thuộc tính sau được lưu trữ: Quantity (Số lượng), Order date (Ngày đặt hàng), và Ship Date (Ngày chuyển hàng); nếu Ship Date bằng giá trị rỗng (Null), có nghĩa là cho đến nay, đơn đặt hàng này vẫn chưa được chuyển.

Đến thời điểm này, DBDudes tiến hành xem xét lại các thiết kế bên trong và có một số câu hỏi đặt ra. Để bảo đảm được các ý kiến, chúng ta sẽ coi thiết kế của người đứng đầu nhóm thiết kế như là Dule 1 và người kiểm tra lại như là Dule 2.

Dule 2: Điều gì xảy ra nếu một khách hành đặt hai hoá đơn cho cùng một quyển sách trong cùng một ngày?

Dule 1: Hoá đơn đầu tiên được tiếp nhận bằng cách tạo ra một liên kết Orders mới và hoá đơn thứ hai được tiếp nhận bằng cách cập nhật giá trị cho thuộc tính Quatity trong liên kết này.

Dule 2: Điều gì xảy ra nếu một khách hàng đặt hai hoá đơn cho hai quyển sách khác nhau trong một ngày?

Dule 1: Không vấn đề. Mỗi trường hợp của liên kết Orders thiết lập một mối liên kết giữa khách hàng và một quyển sách khác (sẽ có hai liên kết Orders sinh ra trong trường hợp này- mỗi quyển sách khác nhau ứng với một liên kết khác nhau).

Dule 2: Ah, điều gì xảy ra nếu một khách hàng đặt hai hoá đơn cho cùng một quyển sách trong hai ngày khác nhau?

Dule 1: Chúng ta có thể sử dụng thuộc tính Order Date của liên kết Orders để phân biệt hai hoá đơn.

Dule 2: Oh. Không được. Hai thuộc tính khoá của hai kiểu thực thể Customers và Books được kết hợp thành tập thuộc tính khoá của kiểu liên kết Orders. Vì thế, với thiết kế này không cho phép một khách hàng đặt nhiều hoá đơn cho cùng một quyển sách, cho dù là các ngày khác nhau.

Dule 1: Ah, bạn đúng. B&N có lẽ không quan tâm đến, chúng tôi sẽ xem lại.

DBDudes quyết định thực hiện giai đoạn thiết kế tiếp theo, thiết kế cơ sở dữ liệu logic; chúng ta sẽ tiếp tục trong phần 3.8.

Câu hỏi tổng kết

Câu trả lời của các câu hỏi tổng kết có thể được tìm thấy trong các phần sau:

Các bước chính trong thiết kế cơ sở dữ liệu. Mục đích của từng bước là gì? Bước nào chủ yếu sử dụng mô hình ER? (Phần 1)
Định nghĩa các thuật ngữ: thực thể, kiểu thực thể, thuộc tính, khóa. (Phần 2)
Định nghĩa các thuật ngữ: liên kết, kiểu liên kết, thuộc tính mô tả. (Phần 3)
Định nghĩa các loại ràng buộc và ví dụ của từng loại: ràng buộc khóa, ràng buộc tham gia. Thực thể yếu là gì? Hệ thống phân cấp là gì? Khối kết hợp là gì? Cung cấp một ví dụ ứng với mỗi khái niệm này. (Phần 4)
Những hướng dẫn nào bạn sẽ sử dụng cho các lựa chọn khi thiết kế lược đồ ER: Sử dụng thuộc tính hay kiểu thực thể, kiểu thực thể hay kiểu liên kết, kiểu liên kết bậc hai, bậc ba, hay khối kết hợp. (Phần 5)
Vì sao việc thiết kế cơ sở dữ liệu cho các hệ thống lớn lại rất khó? (Phần 6)
UML là gì? Làm thế nào để thiết kế cơ sở dữ liệu được đặt thích hợp vào thiết kế tổng thể của hệ thống phần mềm dữ liệu tập trung (data-intensive software system)? UML liên quan tới lược đồ ER như thế nào? (Phần 7)

Bài tập

Giải thích tóm tắt các thuật ngữ sau: thuộc tính, miền xác định, thực thể, liên kết, kiểu thực thể, kiểu liên kết, liên kết một-nhiều, liên kết nhiều-nhiều, ràng buộc tham gia, ràng buộc Overlap, ràng buộc Covering, kiểu thực thể yếu, khối kết hợp.

Giải thích các khái niệm:

Thuộc tính – là tính chất hoặc biểu diễn của một thực thể. Một thực thể Employee có thể có các thuộc tính biểu diễn tên, lương… của nhân viên.
Miều giá trị – là tập các giá trị có thể có của một thuộc tính.
Thực thể – một đối tượng trong thế giới thực được phân biệt với các đối tượng khác.
Liên kết – là mối liên quan giữa hai hay nhiều thực thể.
Kiểu thực thể – là tập các thực thể tương đương nhau, ví dụ các nhân viên trong cùng công ty.
Kiểu liên kết – là tập các liên kết tương đương nhau.
Liên kết một-nhiều – ràng buộc khóa chỉ ra rằng một thực thể có thể có liên kết với nhiều thực thể khác. Một ví dụ về liên kết một-nhiều là: một nhân viên chỉ làm việc cho một phòng, và một phòng có nhiều nhân viên làm việc.
Liên kết nhiều-nhiều – ràng buộc khóa chỉ ra rằng nhiều thực thể có thể liên kết với nhiều thực thể khác. Ví dụ về liên kết nhiều-nhiều là nhân viên và sở thích của họ: một nhân viên có thể có nhiều sở thích và một sở thích có thể được nhiều nhân viên thích.
Ràng buộc tham gia – một ràng buộc tham gia chỉ ra số lượng các thực thể tham gia vào trong một liên kết. Ví dụ, tất cả các thực thể phòng có một thực thể quản lý. Các ràng buộc tham dự có thể là toàn bộ hoặc bộ phận. Ràng buộc tham gia toàn bộ nói rằng tất cả các phòng có một quản lý. Ràng buộc tham gia bộ phận nói rằng không phải tất cả các nhân viên đều là quản lý.
Ràng buộc Overlap – trong phân cấp ISA, một ràng buộc overlap chỉ ra rằng có hay không hai lớp con được phép nằm trong cùng một thực thể.
Ràng buộc Covering – trong phân cấp ISA, ràng buộc covering chỉ ra rằng có hay không một lớp cha chứa tất cả các thực thể trong lớp con. Ví dụ, kiểu thực thể Employees có hai lớp con là HourlyEmployee và SalaryEmployee, không tồn tại một thực thể Employee nào không thuộc một trong hai lớp con trên.
Kiểu thực thể yếu – một thực thể không thể được xác định nếu không chỉ ra thuộc tính đóng vai trò là khóa chính của thực thể chủ của nó. Ví dụ: thực thể người phụ thuộc- phụ thuộc vào thực thể nhân viên.

Khối kết hợp – đặc tính của mô hình ER cho phép một kiểu liên kết được tham gia vào một kiểu liên kết khác. Điều này chỉ ra trong lược đồ ER bằng cách vẽ một hình chữ nhật gạch nét đứt bao quanh khối kết hợp

Cơ sở dữ liệu của một trường đại học có chứa thông tin về các giáo sư (định danh bằng số bảo hiểm xã hội, ssn) và các khóa học (định danh bằng courseid). Các giáo sư dạy các khóa học; được liên kết với nhau bằng kiểu liên kết Teaches. Với mỗi trường hợp, vẽ lược đồ ER để biểu diễn (giả sử rằng không có những ràng buộc khác).

Nhiều giáo sư có thể dạy cùng một khóa học trong một vài học kỳ, và chúng phải được ghi lại.
Nhiều giáo sư có thể dạy cùng một khóa học trong một vài học kỳ, và chỉ có khóa học gần đây nhất phải ghi lại. (Giả sử điều kiện này áp dụng cho tất cả các yêu cầu tiếp theo.)
Tất cả các giáo sư phải dạy một vài khóa học.
Tất cả giáo sư chỉ dạy duy nhất một khóa học (không nhiều hơn, không ít hơn).
Tất cả giáo sư chỉ dạy duy nhất một khóa học (không nhiều hơn, không ít hơn), và tất cả khóa học phải được vài giáo sư dạy.
Bây giờ giả sử rằng, các khóa học có thể được một nhóm giáo sư cùng tham gia dạy, nhưng không có giáo sư nào trong nhóm có thể dạy toàn bộ khoá học. Để mô hình hoá trường hợp này, bạn có thể bổ sung thêm kiểu liên kết và kiểu thực thể nếu cần thiết.

Trả lời: Dành cho độc giả.

Xem xét các thông tin sau về cơ sở dữ liệu của một trường đại học:

Giáo sư có có các thông tin sau: số bảo hiểm xã hội, tên, tuổi, chức danh và một lĩnh vực nghiên cứu đặc biệt.
Dự án có mã số dự án, tên người bảo trợ, ngày bắt đầu, ngày kết thúc và ngân sách dự thảo.
Sinh viên sau đại học có thông tin về số bảo hiểm xã hội, tên, tuổi, và chương trình học (thạc sỹ hay nghiên cứu sinh).
Mỗi dự án được một giáo sư quản lý (đứng đầu dự án).
Mỗi dự án được một hoặc nhiều giáo sư tham gia làm việc (cộng tác viên).
Một giáo sư có thể quản lý hoặc cộng tác trong nhiều dự án.
Mỗi một dự án được một hoặc nhiều sinh viên sau đại học làm việc (những người hỗ trợ nghiên cứu của dự án).
Khi những sinh viên sau đại học làm việc cho một dự án, giáo sư phải quản lý công việc họ làm trong dự án đó. Sinh viên sau đại học có thể làm việc cho nhiều dự án, ứng với mỗi một dự án họ có một giáo sư quản lý riêng.
Các bộ môn có thông tin về mã số, tên, trụ sở chính.
Các bộ môn có một giáo sư đứng đầu điều hành.
Các giáo sư có thể làm việc trong một hoặc nhiều bộ môn và ứng với mỗi bộ môn lưu lại phần trăm thời gian họ làm việc ở đó.
Sinh viên sau đại học chỉ thuộc về một bộ môn quản lý, nơi họ đang theo học.
Mỗi sinh viên sau đại học có nhiều sinh viên lớp trên hỗ trợ (cố vấn), khuyên họ nên theo học những môn học nào.

Thiết kế và vẽ lược đồ ER để biểu diễn các thông tin này. Chỉ sử dụng thành phần cơ bản của mô hình ER, đó là thực thể, kiểu liên kết và thuộc tính. Chỉ ra ràng buộc khóa và các ràng buộc tham gia.

Câu trả lời nằm trong Hình 21

Một công ty cần lưu trữ thông tin về nhân viên (định danh bằng số bảo hiểm xã hội, và có các thuộc tính khác là lương và số điện thoại); Phòng (định danh bằng mã số phòng, và có một số thuộc tính khác là tên phòng và ngân quỹ); và con của các nhân viên (có các thuộc tính tên và tuổi). Các nhân viên có thể làm việc trong nhiều phòng; mỗi phòng được một nhân viên quản lý; mỗi đứa con phải được định danh duy nhất ứng với một cha/mẹ (giả sử rằng chỉ có một người, hoặc cha hoặc mẹ làm việc cho công ty). Khi nhân viên chuyển đi, chúng ta sẽ không quan tâm đến những thông tin về những đứa con của họ.

Vẽ lược đồ ER để biểu diễn các thông tin này.

Trả lời: Dành cho độc giả.

Notown Records (hãng băng đĩa) quyết định lưu trữ thông tin về những nhạc sỹ thực hiện các album tại đây. Công ty có lựa chọn thông minh là thuê bạn là một người thiết kế cơ sở dữ liệu (với mức phí tư vấn thông thường là 2500$/ngày).

Mỗi nhạc sỹ ghi băng ở Notown có lưu thông tin về số bảo hiểm xã hội, địa chỉ, số điện thoại. Những nhạc sỹ nghèo thường có chung nhau một địa chỉ và không có địa chỉ nào có nhiều hơn một số điện thoại.
Mỗi nhạc cụ được sử dụng trong các bài hát ghi ở Notown có tên (ví dụ, ghi ta, nhạc cụ điện tử, sáo) và nốt nhạc (ví dụ, C, B-flat, E-flat).
Mỗi album được ghi ở Notown có thông tin về tên, ngày xuất bản, định dạng (ví dụ, CD hoặc MC), và mã số định danh album.
Mỗi bài hát ghi ở Notown có tiêu đề và tác giả.
Mỗi nhạc sỹ có thể chơi một số nhạc cụ, và một nhạc cụ có thể được nhiều nhạc sỹ chơi.
Mỗi album có một số bài hát, nhưng không có bài hát nào xuất hiện trong nhiều hơn một album.
Một bài hát có thể được thực hiện bằng nhiều nhạc sỹ, và một nhạc sỹ có thể thực hiện một số bài hát.
Mỗi album có chính xác một nhạc sỹ là người sản xuất. Một nhạc sỹ có thể là người sản xuất của nhiều album.

Thiết kế lược đồ khái niệm cho công ty Notown và vẽ lược đồ ER. Những thông tin biểu diễn cơ sở dữ liệu của Notown phía trên phải được mô hình hóa. Xác định tất cả các ràng buộc khóa và ràng buộc thành phần. Chỉ ra các ràng buộc mà bạn không thể biểu diễn trong lược đồ ER và giải thích tóm tắt vì sao bạn không thể biểu diễn chúng.

Trả lời:Câu trả lời nằm trong Hình sau

Bộ môn khoa học máy tính thường xuyên nghe phi công phàn nàn với nhà chức trách của sân bay thành phố Dane về sự tổ chức nghèo nàn ở sân bay. Vì thế, những nhà chức trách đã quyết định sử dụng DBMS để tổ chức tất cả các thông tin liên quan ở sân bay và bạn đã được thuê để thiết kế cơ sở dữ liệu. Công việc đầu tiên của bạn là tổ chức thông tin về tất cả các máy bay được sử dụng ở sân bay. Các thông tin liên quan bao gồm:

Tất cả các máy bay có mã số đăng ký, và mỗi máy bay thuộc một loại nhất định.
Sân bay có một số loại máy bay, mỗi loại được định danh bằng mã số loại (ví dụ, DC-10) và có thông tin về trọng tải và khả năng chở khách hàng.
Có một số các kỹ sư làm việc ở sân bay. Bạn cần lưu lại tên, số bảo hiểm xã hội, địa chỉ, số điện thoại, lương của từng người.
Mỗi kỹ sư là một chuyên gia trên một hoặc nhiều loại máy bay, và ý kiến chuyên môn của anh/cô ấy có ý nghĩa quyết định. Thông tin về những kỹ sư này cần được ghi lại.
Những nhân viên kiểm soát phải có kiểm tra y tế định kỳ. Với mỗi nhân viên kiểm soát, bạn phải ghi lại ngày kiểm tra y tế gần đây nhất.
Mỗi nhân viên sân bay (bao gồm cả kỹ sư) phải thuộc về một tổ chức nào đó. Bạn phải lưu lại mã số của mỗi nhân viên trong tổ chức. Bạn có thể giả sử rằng mỗi nhân viên có mã số bảo hiểm xã hội khác nhau.
Mỗi sân bay có một số kiểm tra được thực hiện để đảm bảo rằng tất cả các máy bay vẫn hoạt động tốt. Mỗi kiểm tra có mã số FAA (Federal Aviation Administration), tên, và điểm cao nhất có thể.
FAA yêu cầu sân bay giữ lại lịch sử của mỗi lần kiểm tra đối với từng máy bay. Với mỗi lần kiểm tra, thông tin cần lưu lại là: ngày kiểm tra, số lượng giờ mà kỹ sư đã dùng để kiểm tra và điểm mà máy bay đó nhận được.

Vẽ lược đồ ER cho cơ sở dữ liệu về sân bay, chỉ ra tất cả các thuộc tính của kiểu thực thể và kiểu quan hệ, xác định khoá và các ràng buộc tham gia cho mỗi kiểu quan hệ. Xác định những ràng buộc overlap và covering nếu có.
Những kiểm tra FAA thông thường trên máy bay phải được thực hiện bằng kỹ sư- chuyên gia về loại máy bay đó. Ràng buộc này được biểu diễn như thế nào trong lược đồ ER? Nếu không thể biểu diễn ràng buộc này, giải thích tóm tắt tại sao.

Trả lời: Dành cho độc giả.

Thiết kế cơ sở dữ liệu cho một công ty kinh doanh dược phẩm. Tham khảo những thông tin sau:

Bệnh nhân được xác định bằng SSN và lưu lại tên, địa chỉ, tuổi của bệnh nhân.
Bác sỹ được xác định bằng SSN. Mỗi bác sỹ lưu lại tên, chuyên môn, số năm kinh nghiệm.
Mỗi công ty dược được xác định bằng tên và có số điện thoại. Với mỗi loại thuốc, tên và công thức phải được ghi lại. Mỗi loại thuốc được bán bởi một công ty dược và tên của loại thuốc của một công ty phải khác nhau. Nếu một công ty dược bị xoá, bạn không cần lưu lại thông tin về các loại thuốc của công ty đó nữa.
Mỗi cửa hàng thuốc có tên, địa chỉ và số điện thoại.
Mỗi bệnh nhân có một bác sỹ điều trị chính. Tất cả các bác sỹ đều có ít nhất một bệnh nhân.
Mỗi cửa hàng bán một vài loại thuốc và có giá cho mỗi loại. Mỗi loại thuốc có thể được bán ở một vài cửa hàng thuốc và giá bán có thể khác nhau.
Bác sỹ kê đơn thuốc cho các các bệnh nhân. Bác sỹ có thể kê đơn một hoặc nhiều loại thuốc cho các bệnh nhân khác nhau, và một bệnh nhân có thể nhận các đơn thuốc từ một vài bác sỹ. Mỗi đơn thuốc có ngày và số lượng của từng loại thuốc. Bạn có thể giả sử rằng một bác sỹ kê cùng một loại thuốc cho cùng một bệnh nhân nhiều hơn một lần, trong trường hợp này bạn chỉ cần lưu lại lần kê đơn cuối cùng.
Công ty kinh doanh dược phẩm có hợp đồng dài hạn với các cửa hàng. Một công ty có thể hợp đồng với nhiều cửa hàng, và một cửa hàng có thể hợp đồng với nhiều công ty. Với mỗi hợp đồng, bạn cần lưu lại ngày bắt đầu, ngày cuối cùng và văn bản của hợp đồng.
Các cửa hàng cử một người quản lý cho mỗi hợp đồng. Mỗi hợp đồng phải luôn có người quản lý, người quản lý có thể thay đổi trong suốt thời gian duy trì hợp đồng.

Xây dựng lược đồ ER biểu diễn những thông tin trên.
Thay đổi thiết kế của bạn như thế nào để mỗi loại thuốc phải được bán bằng một giá ở tất cả các cửa hàng.
Thay đổi thiết kế như thế nào nếu thay đổi yêu cầu như sau: Nếu một bác sỹ kê đơn cùng một loại thuốc cho cùng một bệnh nhân nhiều lần, những lần này đều cần ghi lại.

Trả lời

Nếu thuốc được bán một giá cố định chúng ta có thể thêm thuộc tính price vào kiểu thực thể Drug và bỏ price ở kiểu liên kết Sell.
Thông tin ngày tháng (date) có thể không còn được mô hình hóa như một thuộc tính của Prescription. Chúng ta phải tạo ra một thực thể mới gọi là Prescription date và xem Prescription là một kiểu liên kết 4-đường, tức là được bổ sung thêm một đường tới kiểu thực thể này.

Bạn muốn xây dựng một cơ sở dữ liệu, ArtBase, để lưu lại thông tin về những tác phẩm nghệ thuật trong những triển lãm. Triển lãm chứa thông tin về các nghệ sỹ, bao gồm tên (xác định duy nhất), ngày sinh, tuổi và phong cách nghệ thuật của họ. Với mỗi tác phẩm, bạn cần lưu lại thông tin về: nghệ sỹ, năm hoàn thành, tên tác phẩm (xác định duy nhất), loại nghệ thuật (tranh vẽ, tranh đá, tượng, ảnh…), và giá. Các tác phẩm cũng được phân loại thành các nhóm, ví dụ, chân dung, cuộc sống hàng ngày, trường phái Picasso, tác phẩm của thế kỷ 19; mỗi tác phẩm cũng có thể thuộc về nhiều nhóm. Mỗi nhóm xác định bằng tên của nhóm. Cuối cùng, triển lãm cần lưu lại thông tin về các khách hàng. Với mỗi khách hàng, triển lãm lưu lại thông tin về tên, địa chỉ, tổng số tiền họ đã sử dụng trong một triển lãm (rất quan trọng), và những nghệ sỹ và loại tác phẩm họ thích.

Vẽ lược đồ ER cho cơ sở dữ liệu này.

Trả lời: Dành cho độc giả.

Trả lời những câu hỏi sau:

Giải thích tóm tắt những thuật ngữ sau: UML, lược đồ trường hợp sử dụng, lược đồ lớp, lược đồ cơ sở dữ liệu, lược đồ thành phần, và lược đồ phát triển.
Giải thích mối quan hệ giữa lược đồ ER và UML.

Trả lời: Chưa thực hiện

TÀI LIỆU THAM KHẢO

Một số quyển sách cung cấp những hướng dẫn tốt để thiết kế khái niệm; bao gồm [63] (nó cũng chứa tổng quan về các công cụ thiết kế cơ sở dữ liệu thương mại) và [730].

Mô hình ER đã được Chen đề xuất [172], và những mở rộng đã được đề xuất trong một số bài báo. Tổng quát hóa và khối kết hợp được giới thiệu trong [693]. [390, 589] trình bày tốt về mô hình cơ sở dữ liệu ngữ nghĩa.

[731] trình bày về cách thức thiết kế bằng cách phát triển lược đồ ER và sau đó ánh xạ nó sang mô hình quan hệ. Markowitz đề cập đến ràng buộc tham chiếu trong mô hình ER để ánh xạ quan hệ và bàn về những hỗ trợ do một số hệ thống thương mại cung cấp trong [513, 514].

Mô hình ER được trình bày trong hàng loath các bài báo, như [698].

Trang chủ của OMG (www.omg.org) trình bày về UML và các chuẩn mô hình liên quan. Một số lượng lớn sách trình bày về UML; ví dụ [105, 278, 640] và có một hội thảo hàng năm liên quan đến những lợi ích của UML đó là hội thảo quốc tế về UML.

Khung nhìn được trình bày trong một số bài báo, bao gồm [97, 139, 184, 244, 535, 551, 550, 685, 697, 748].

TẢI VỀ

TÁI SỬ DỤNG

NỘI DUNG CÙNG TÁC GIẢ