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 ...
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.
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ể 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ự.
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 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:
Tập thực thể Employees
Mỗi n-tupe biểu thị một mối liên kết bao gồm n thực thể từ e1 tới en, trong đó thực thể ei thuộc tập thực thể Ei. 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.
Kiểu quan hệ Work_In
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 minh họa của kiểu liên kết Works_In
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.
Kiểu liên kết bậc 3
Kiểu liên kết Reports_To
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.
Ràng buộc khóa trên Manages
Minh họa của kiểu liên kết 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.
Một minh họa của Works_In3
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.
Manages và Works_In
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
Kiểu thực thể yếu
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.
Hệ thống phân cấp
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.
Khối kết hợp
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
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.
Kiểu liên kết Works_In4
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.
Thực thể hay liên kết
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.
Policies được xem như một kiểu thực thể
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 lại kiểu thực thể Policies
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
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.
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ạ
