Chương 9: Thiết kế cơ sở dữ liệu quan hệ bằng ánh xạ ER và EER-to-Relational

Nội dung bài viết

Chương này thảo luận cách thiết kế lược đồ cơ sở dữ liệu quan hệ dựa trên thiết kế lược đồ khái niệm. Hình 3.1 trình bày một cái nhìn cấp cao về quá trình thiết kế cơ sở dữ liệu. Trong chương này, chúng tôi tập trung vào bước thiết kế cơ sở dữ liệu logic của thiết kế cơ sở dữ liệu, còn được gọi là ánh xạ mô hình dữ liệu. Chúng tôi trình bày các thủ tục để tạo một lược đồ quan hệ từ một lược đồ mối quan hệ thực thể (ER) hoặc một lược đồ ER nâng cao (EER). Phần thảo luận của chúng ta liên quan đến cấu trúc của các mô hình ER và EER, được trình bày trong Chương 3 và 4, với cấu trúc của mô hình quan hệ, được trình bày trong Chương 5 đến Chương 8. Nhiều công cụ công nghệ phần mềm hỗ trợ máy tính (CASE) dựa trên ER hoặc Các mô hình EER hoặc các mô hình tương tự khác, như chúng ta đã thảo luận trong Chương 3 và 4. Nhiều công cụ sử dụng sơ đồ ER hoặc EER hoặc các biến thể để phát triển lược đồ bằng đồ họa và thu thập thông tin về các loại dữ liệu và ràng buộc, sau đó chuyển đổi lược đồ ER/EER tự động vào một lược đồ cơ sở dữ liệu quan hệ trong DDL của một DBMS quan hệ cụ thể. Các công cụ thiết kế sử dụng các thuật toán tương tự như các thuật toán được trình bày trong chương này.

Chúng tôi phác thảo một thuật toán gồm bảy bước trong Phần 9.1 để chuyển đổi các cấu trúc mô hình ER cơ bản—các loại thực thể (mạnh và yếu), các mối quan hệ nhị phân (với các ràng buộc cấu trúc khác nhau), các mối quan hệ n-ary và các thuộc tính (đơn giản, tổng hợp và đa trị) —vào quan hệ. Sau đó, trong Phần 9.2, chúng tôi tiếp tục thuật toán ánh xạ bằng cách mô tả cách ánh xạ các cấu trúc mô hình EER—sự chuyên biệt hóa/khái quát hóa và các kiểu kết hợp (phân loại)—vào các mối quan hệ.

1.  Thiết kế cơ sở dữ liệu quan hệ bằng ánh xạ ER-to-relational

1.1 Thuật toán ánh xạ ER sang quan hệ

Trong phần này, chúng tôi mô tả các bước của thuật toán để ánh xạ ER sang quan hệ. Chúng tôi sử dụng ví dụ cơ sở dữ liệu COMPANY để minh họa quy trình ánh xạ. Lược đồ COMPANY ER được hiển thị lại trong Hình 9.1 và lược đồ cơ sở dữ liệu quan hệ COMPANY tương ứng được hiển thị trong Hình 9.2 để minh họa các bước ánh xạ. Chúng tôi giả định rằng việc ánh xạ sẽ tạo ra các bảng với các thuộc tính đơn giá trị đơn giản. Các ràng buộc mô hình quan hệ được xác định trong Chương 5, bao gồm khóa chính, khóa duy nhất (nếu có) và ràng buộc toàn vẹn tham chiếu trên các quan hệ, cũng sẽ được chỉ định trong kết quả ánh xạ

Bước 1: Ánh xạ các loại thực thể thông thường. Đối với mỗi loại thực thể thông thường (mạnh) E trong lược đồ ER, hãy tạo một mối quan hệ R bao gồm tất cả các thuộc tính đơn giản của E. Chỉ bao gồm các thuộc tính thành phần đơn giản của thuộc tính tổng hợp. Chọn một trong các thuộc tính khóa của E làm khóa chính cho R. Nếu khóa được chọn của E là khóa tổng hợp, thì tập hợp các thuộc tính đơn tạo thành nó sẽ cùng nhau tạo thành khóa chính của R

Nếu nhiều khóa được xác định cho E trong quá trình thiết kế khái niệm, thì thông tin mô tả các thuộc tính tạo thành mỗi khóa bổ sung được lưu giữ để chỉ định các khóa bổ sung (duy nhất) của quan hệ R. Kiến thức về khóa cũng được lưu giữ cho mục đích lập chỉ mục và các mục đích khác. các loại phân tích.

Trong ví dụ của chúng ta, chúng ta tạo các quan hệ EMPLOYEE, DEPARTMENT và PROJECT trong Hình 9.2 để tương ứng với các loại thực thể thông thường EMPLOYEE, DEPARTMENT và PROJECT từ Hình 9.1. Khóa ngoại và các thuộc tính quan hệ, nếu có, chưa được đưa vào; chúng sẽ được thêm vào trong các bước tiếp theo. Chúng bao gồm các thuộc tính Super_ssn và Dno của EMPLOYEE, Mgr_ssn và Mgr_start_date của DEPARTMENT và Dnum của PROJECT. Trong ví dụ của chúng tôi, chúng tôi chọn Ssn, Dnumber và Pnumber làm khóa chính cho các quan hệ EMPLOYEE, DEPARTMENT và PROJECT tương ứng. Hiểu rằng Dname của DEPARTMENT và Pname của PROJECT là các khóa duy nhất được lưu giữ để có thể sử dụng sau này trong thiết kế.

Các quan hệ được tạo ra từ ánh xạ của các loại thực thể đôi khi được gọi là quan hệ thực thể vì mỗi bộ đại diện cho một thể hiện thực thể. Kết quả sau bước ánh xạ này được thể hiện trong Hình 9.3(a).

Bước 2: Ánh xạ các loại thực thể yếu. Đối với mỗi loại thực thể yếu W trong lược đồ ER với loại thực thể chủ sở hữu E, hãy tạo một mối quan hệ R và bao gồm tất cả các thuộc tính đơn giản (hoặc các thành phần đơn giản của thuộc tính tổng hợp) của W dưới dạng thuộc tính của R. Ngoài ra, bao gồm dưới dạng thuộc tính khóa ngoại của R , (các) thuộc tính khóa chính của (các) quan hệ tương ứng với (các) loại thực thể chủ sở hữu; điều này đảm nhiệm việc ánh xạ loại mối quan hệ xác định của W. Khóa chính của R là tổ hợp của (các) khóa chính của (các) chủ sở hữu và khóa bộ phận của loại thực thể yếu W, nếu có. Nếu có một loại thực thể yếu E2 có chủ sở hữu cũng là một loại thực thể yếu E1, thì E1 phải được ánh xạ trước E2 để xác định khóa chính của nó trước.

Trong ví dụ của chúng tôi, chúng tôi tạo mối quan hệ DEPENDENT trong bước này để tương ứng với loại thực thể yếu DEPENDENT (xem Hình 9.3(b)). Chúng tôi bao gồm khóa chính Ssn của quan hệ EMPLOYEE—tương ứng với loại thực thể chủ sở hữu—như một thuộc tính khóa ngoại của DEPENDENT; chúng tôi đổi tên nó thành Essn, mặc dù điều này là không cần thiết. Khóa chính của quan hệ DEPENDENT là tổ hợp {Essn, Dependent_name}, vì Dependent_name (cũng được đổi tên từ Name trong Hình 9.1) là khóa bộ phận của DEPENDENT

Người ta thường chọn tùy chọn lan truyền (CASCADE) cho hành động được cập nhật tham chiếu trên khóa ngoại trong mối quan hệ tương ứng với loại thực thể yếu do thực thể yếu có sự tồn tại phụ thuộc vào thực thể chủ sở hữu của nó. Điều này có thể được sử dụng cho cả ON UPDATE và ON DELETE.

Bước 3: Ánh xạ các kiểu quan hệ nhị phân 1:1. Đối với mỗi kiểu quan hệ nhị phân 1:1 R trong lược đồ ER, hãy xác định các quan hệ S và T tương ứng với các kiểu thực thể tham gia vào R. Có ba cách tiếp cận khả thi: (1) cách tiếp cận khóa ngoại, (2) cách hợp nhất cách tiếp cận mối quan hệ, và (3) cách tiếp cận tham khảo chéo. Cách tiếp cận đầu tiên là hữu ích nhất và nên được tuân theo trừ khi có các điều kiện đặc biệt, như chúng tôi thảo luận dưới đây.

• Cách tiếp cận khóa ngoại: Chọn một trong các mối quan hệ—chẳng hạn như S—và bao gồm khóa ngoại trong S khóa chính của T. Tốt hơn là chọn một loại thực thể có toàn bộ tham gia vào R với vai trò của S. Bao gồm tất cả các thuộc tính đơn giản (hoặc các thành phần đơn giản của các thuộc tính tổng hợp) của kiểu quan hệ 1:1 R là các thuộc tính của S

Trong ví dụ của chúng tôi, chúng tôi ánh xạ loại mối quan hệ 1:1 MANAGES từ Hình 9.1 bằng cách chọn loại thực thể tham gia DEPARTMENT để phục vụ trong vai trò của S vì sự tham gia của nó trong loại mối quan hệ MANAGES là toàn bộ (mỗi bộ phận có một người quản lý). Chúng tôi bao gồm khóa chính của quan hệ EMPLOYEE làm khóa ngoại trong quan hệ DEPARTMENT và đổi tên nó thành Mgr_ssn. Chúng ta cũng bao gồm thuộc tính đơn giản Start_date của kiểu quan hệ MANAGES trong quan hệ DEPARTMENT và đổi tên thành Mgr_start_date (xem Hình 9.2 ).

Lưu ý rằng có thể bao gồm khóa chính của S làm khóa ngoại trong T thay thế. Trong ví dụ của chúng ta, điều này có nghĩa là có một thuộc tính khóa ngoại, chẳng hạn như Department_managed trong quan hệ EMPLOYEE, nhưng nó sẽ có giá trị NULL cho các bộ dữ liệu nhân viên không quản lý một phòng ban. Đây sẽ là một lựa chọn tồi, vì nếu chỉ có 2% nhân viên quản lý một bộ phận, thì 98% khóa ngoại sẽ là NULL trong trường hợp này. Một khả năng khác là có các khóa ngoại trong cả hai quan hệ S và T một cách dư thừa, nhưng điều này tạo ra sự dư thừa và phát sinh khó khăn đối với việc duy trì tính nhất quán.

• Phương pháp tiếp cận mối quan hệ hợp nhất: Một ánh xạ thay thế của loại mối quan hệ 1:1 là hợp nhất hai loại thực thể và mối quan hệ thành một mối quan hệ duy nhất. Điều này có thể xảy ra khi cả hai lần tham gia đều là tổng, vì điều này chỉ ra rằng hai bảng sẽ có cùng số lượng bộ giá trị giống nhau tại mọi thời điểm.
• Cách tiếp cận tham chiếu chéo hay quan hệ liên kết: Phương án thứ ba là thiết lập quan hệ thứ ba R nhằm mục đích tham chiếu chéo các khóa chính của hai quan hệ S và T đại diện cho các loại thực thể. Như chúng ta sẽ thấy, cách tiếp cận này là cần thiết cho các mối quan hệ nhị phân M:N. Quan hệ R được gọi là quan hệ quan hệ (hoặc đôi khi là bảng tra cứu) vì mỗi bộ trong R đại diện cho một thể hiện quan hệ liên kết một bộ từ S với một bộ từ T. Mối quan hệ R sẽ bao gồm các thuộc tính khóa chính của S và T như khóa ngoại cho S và T. Khóa chính của R sẽ là một trong hai khóa ngoại và khóa ngoại khác sẽ là khóa duy nhất của R. Hạn chế là có một quan hệ phụ và yêu cầu thêm các thao tác nối khi kết hợp các quan hệ có liên quan bộ dữ liệu từ các bảng

Bước 4: Ánh xạ các kiểu quan hệ nhị phân 1:N. Có hai cách tiếp cận khả thi: (1) cách tiếp cận khóa ngoại và (2) cách tiếp cận tham chiếu chéo hoặc quan hệ quan hệ. Cách tiếp cận đầu tiên thường được ưa thích hơn vì nó làm giảm số lượng bảng

• Phương pháp khóa ngoại: Đối với mỗi loại mối quan hệ R 1:N nhị phân thông thường, hãy xác định mối quan hệ S đại diện cho loại thực thể tham gia ở phía N của loại mối quan hệ. Bao gồm khóa ngoại trong S khóa chính của quan hệ T đại diện cho loại thực thể khác tham gia vào R; chúng tôi làm điều này vì mỗi phiên bản thực thể ở phía N có liên quan đến tối đa một phiên bản thực thể ở phía 1 của loại mối quan hệ. Bao gồm bất kỳ thuộc tính đơn giản nào (hoặc các thành phần đơn giản của thuộc tính tổng hợp) của loại mối quan hệ 1:N làm thuộc tính của S.

Để áp dụng cách tiếp cận này cho ví dụ của chúng tôi, chúng tôi ánh xạ các loại mối quan hệ 1:N WORKS_FOR, CONTROLS và SUPERVISION từ Hình 9.1. Đối với WORKS_FOR, chúng tôi bao gồm khóa chính Dnumber của quan hệ DEPARTMENT làm khóa ngoại trong quan hệ EMPLOYEE và gọi nó là Dno. Đối với SUPERVISION, chúng tôi bao gồm khóa chính của quan hệ EMPLOYEE làm khóa ngoại trong chính quan hệ EMPLOYEE—vì quan hệ là đệ quy—và gọi nó là Super_ssn. Mối quan hệ CONTROLS được ánh xạ tới thuộc tính khóa ngoại Dnum của PROJECT, thuộc tính này tham chiếu đến khóa chính Dnumber của mối quan hệ DEPARTMENT. Các khóa ngoại này được thể hiện trong Hình 9.2.

• Cách tiếp cận quan hệ mối quan hệ: Một cách tiếp cận khác là sử dụng tùy chọn quan hệ mối quan hệ (tham chiếu chéo) như trong tùy chọn thứ ba cho các mối quan hệ nhị phân 1:1. Ta tạo một quan hệ riêng R có thuộc tính là khóa chính của S và T, thuộc tính này cũng sẽ là khóa ngoại của S và T. Khóa chính của R giống như khóa chính của S. Có thể sử dụng tùy chọn này nếu ít các bộ trong S tham gia vào mối quan hệ để tránh các giá trị NULL quá nhiều trong khóa ngoại

Bước 5: Ánh xạ các kiểu quan hệ M:N nhị phân. Trong mô hình quan hệ truyền thống không có thuộc tính đa trị, tùy chọn duy nhất cho các mối quan hệ M:N là tùy chọn quan hệ (tham chiếu chéo). Đối với mỗi kiểu quan hệ M:N nhị phân R, hãy tạo một mối quan hệ S mới để biểu diễn R. Bao gồm các thuộc tính khóa ngoại trong S các khóa chính của quan hệ đại diện cho các loại thực thể tham gia; sự kết hợp của chúng sẽ tạo thành khóa chính của S. Cũng bao gồm bất kỳ thuộc tính đơn giản nào của kiểu quan hệ M:N (hoặc các thành phần đơn giản của các thuộc tính phức hợp) làm thuộc tính của S. Lưu ý rằng chúng ta không thể biểu diễn kiểu quan hệ M:N bởi một đối tượng ngoại lai duy nhất. thuộc tính khóa trong một trong các mối quan hệ tham gia (như chúng ta đã làm đối với các loại mối quan hệ 1:1 hoặc 1:N) do tỷ lệ số lượng M:N; chúng ta phải tạo một quan hệ riêng biệt S.

Trong ví dụ của chúng tôi, chúng tôi ánh xạ các loại mối quan hệ M:N WORKS_ON từ Hình 9.1 bằng cách tạo mối quan hệ WORKS_ON trong Hình 9.2. Chúng tôi bao gồm các khóa chính của quan hệ DỰ ÁN và NHÂN VIÊN làm khóa ngoại trong WORKS_ON và đổi tên chúng theo thứ tự là Pno và Essn (không bắt buộc phải đổi tên; đó là lựa chọn thiết kế). Chúng tôi cũng bao gồm thuộc tính Giờ trong WORKS_ON để biểu thị thuộc tính Giờ của loại mối quan hệ. Khóa chính của quan hệ WORKS_ON là tổ hợp của các thuộc tính khóa ngoại {Essn, Pno}. Mối quan hệ quan hệ này được thể hiện trong Hình 9.3(c).

Tùy chọn cập nhật (CASCADE) cho hành động được xử lý tham chiếu (xem Phần 4.2) phải được chỉ định trên các khóa ngoại trong mối quan hệ tương ứng với mối quan hệ R, vì mỗi thể hiện mối quan hệ có sự tồn tại phụ thuộc vào từng thực thể mà nó liên quan. Điều này có thể được sử dụng cho cả ON UPDATE và ON DELETE.

Mặc dù chúng ta có thể ánh xạ mối quan hệ 1:1 hoặc 1:N theo cách tương tự như mối quan hệ M:N bằng cách sử dụng phương pháp tham chiếu chéo (mối quan hệ mối quan hệ), như chúng ta đã thảo luận trước đó, điều này chỉ được khuyến nghị khi tồn tại một vài trường hợp mối quan hệ, theo thứ tự để tránh các giá trị NULL trong khóa ngoại. Trong trường hợp này, khóa chính của quan hệ quan hệ sẽ chỉ là một trong các khóa ngoại tham chiếu các quan hệ thực thể tham gia. Đối với mối quan hệ 1:N, khóa chính của mối quan hệ mối quan hệ sẽ là khóa ngoại tham chiếu đến mối quan hệ thực thể ở phía N. Đối với mối quan hệ 1:1, một trong hai khóa ngoại có thể được sử dụng làm khóa chính của mối quan hệ

Bước 6: Ánh xạ các thuộc tính đa giá trị. Đối với mỗi thuộc tính đa trị A, hãy tạo một mối quan hệ R mới. Mối quan hệ R này sẽ bao gồm một thuộc tính tương ứng với A, cộng với thuộc tính khóa chính K—như một khóa ngoại trong R—của mối quan hệ đại diện cho kiểu thực thể hoặc kiểu mối quan hệ có A như một thuộc tính đa giá trị. Khóa chính của R là tổ hợp của A và K. Nếu thuộc tính đa trị là hỗn hợp, chúng ta bao gồm các thành phần đơn giản của nó

Trong ví dụ của chúng ta, chúng ta tạo một quan hệ DEPT_LOCATIONS (xem Hình 9.3(d)). Thuộc tính Dlocation đại diện cho thuộc tính đa giá trị LOCATIONS của DEPARTMENT, trong khi Dnumber—là khóa ngoại—đại diện cho khóa chính của quan hệ DEPARTMENT. Khóa chính của DEPT_LOCATIONS là sự kết hợp của {Dnumber, Dlocation}. Một bộ dữ liệu riêng biệt sẽ tồn tại trong DEPT_LOCATIONS cho mỗi vị trí mà một bộ phận có. Điều quan trọng cần lưu ý là trong các phiên bản gần đây hơn của mô hình quan hệ cho phép các kiểu dữ liệu mảng, thuộc tính đa trị có thể được ánh xạ tới một thuộc tính mảng thay vì yêu cầu một bảng riêng.

Tùy chọn cập nhật (CASCADE) cho hành động cập nhật tham chiếu phải được chỉ định trên khóa ngoại trong quan hệ R tương ứng với thuộc tính đa giá trị cho cả ON UPDATE và ON DELETE. Chúng ta cũng nên lưu ý rằng khóa của R khi ánh xạ một thuộc tính tổng hợp, đa trị yêu cầu một số phân tích về ý nghĩa của các thuộc tính thành phần. Trong một số trường hợp, khi thuộc tính đa trị là phức hợp thì chỉ một số thuộc tính thành phần được yêu cầu là thuộc tính khóa của R; các thuộc tính này tương tự như một phần khóa của loại thực thể yếu tương ứng với thuộc tính đa trị

Hình 9.2 hiển thị lược đồ cơ sở dữ liệu quan hệ COMPANY thu được từ bước 1 đến bước 6 và Hình 5.6 hiển thị trạng thái cơ sở dữ liệu mẫu. Lưu ý rằng chúng ta chưa thảo luận về ánh xạ của các kiểu quan hệ n-ary (n > 2) bởi vì không tồn tại trong Hình 9.1; chúng được ánh xạ theo cách tương tự với các loại mối quan hệ M:N bằng cách bao gồm bước bổ sung sau trong thuật toán ánh xạ

Bước 7: Ánh xạ các kiểu quan hệ N-ary. Ta sử dụng tùy chọn quan hệ từ. Đối với mỗi loại mối quan hệ n-ary R, trong đó n > 2, tạo một mối quan hệ mới S để đại diện cho R. Bao gồm các thuộc tính khóa ngoại trong S các khóa chính của các mối quan hệ đại diện cho các loại thực thể tham gia. Ngoài ra, bao gồm bất kỳ thuộc tính đơn giản nào của loại mối quan hệ n-ary (hoặc các thành phần đơn giản của thuộc tính hỗn hợp) làm thuộc tính của S. Khóa chính của S thường là tổ hợp của tất cả các khóa ngoại tham chiếu đến các mối quan hệ đại diện cho các loại thực thể tham gia. Tuy nhiên, nếu các ràng buộc về lực lượng đối với bất kỳ loại thực thể E nào tham gia vào R là 1, thì khóa chính của S không được bao gồm thuộc tính khóa ngoại tham chiếu đến quan hệ E′ tương ứng với E.

Xem xét loại mối quan hệ ba bên SUPPLY trong Hình 3.17, mối quan hệ này liên kết SUPPLY s, PART p và PROJECT j bất cứ khi nào s hiện đang cung cấp p cho j; điều này có thể được ánh xạ tới quan hệ CUNG CẤP được hiển thị trong Hình 9.4, có khóa chính là sự kết hợp của ba khóa ngoại {Sname, Part_no, Proj_name}.

1.2 Thảo luận và tóm tắt về ánh xạ cho mô hình ER

Một trong những điểm chính cần lưu ý trong lược đồ quan hệ, trái ngược với lược đồ ER, là các kiểu quan hệ không được biểu diễn rõ ràng; thay vào đó, chúng được biểu diễn bằng hai thuộc tính A và B, một là khóa chính và một là khóa ngoại (trên cùng một miền) bao gồm trong hai quan hệ S và T. Hai bộ trong S và T có quan hệ với nhau khi chúng có cùng giá trị cho A và B. Bằng cách sử dụng thao tác EQUI JOIN (hoặc NATURAL JOIN nếu hai thuộc tính nối có cùng tên) trên S.A và T.B, chúng ta có thể kết hợp tất cả các cặp bộ giá trị liên quan từ S và T và cụ thể hóa mối quan hệ. Khi có liên quan đến kiểu quan hệ nhị phân 1:1 hoặc 1:N và sử dụng ánh xạ khóa ngoại, thì thường cần một thao tác nối đơn. Khi sử dụng cách tiếp cận quan hệ quan hệ, chẳng hạn như đối với loại quan hệ nhị phân M:N, cần có hai thao tác nối, trong khi đối với các loại quan hệ n-ary, cần có n phép nối để cụ thể hóa đầy đủ các thể hiện của quan hệ.

Ví dụ, để hình thành một mối quan hệ bao gồm tên nhân viên, tên dự án và số giờ mà nhân viên đó làm việc trong từng dự án, chúng ta cần kết nối từng bộ EMPLOYEE với các bộ PROJECT có liên quan thông qua quan hệ WORKS_ON trong Hình 9.2. Do đó, chúng ta phải áp dụng thao tác EQUI JOIN cho quan hệ EMPLOYEE và WORKS_ON với điều kiện nối EMPLOYEE.Ssn = WORKS_ON.Essn, sau đó áp dụng thao tác THIẾT BỊ khác cho quan hệ kết quả và mối quan hệ PROJECT với điều kiện nối WORKS_ON.Pno = PROJECT.Pnumber . Nói chung, khi cần duyệt qua nhiều mối quan hệ, nhiều thao tác nối phải được chỉ định. Người dùng phải luôn nhận thức được các thuộc tính khóa ngoại để sử dụng chúng một cách chính xác trong việc kết hợp các bộ dữ liệu liên quan từ hai hoặc nhiều quan hệ. Điều này đôi khi được coi là một nhược điểm của mô hình dữ liệu quan hệ vì sự tương ứng của khóa ngoại/khóa chính không phải lúc nào cũng rõ ràng khi kiểm tra các lược đồ quan hệ. Nếu một EQUI JOIN được thực hiện giữa các thuộc tính của hai mối quan hệ không đại diện cho mối quan hệ khóa ngoại/khóa chính, thì kết quả thường có thể vô nghĩa và có thể dẫn đến dữ liệu giả. Ví dụ: người đọc có thể thử JOIN các quan hệ PROJECT và DEPT_LOCATIONS với điều kiện Dlocation = Plocation và kiểm tra kết quả.

Trong lược đồ quan hệ, chúng ta tạo một quan hệ riêng cho từng thuộc tính đa trị. Đối với một thực thể cụ thể có một tập hợp các giá trị cho thuộc tính đa giá trị, giá trị thuộc tính khóa của thực thể được lặp lại một lần cho mỗi giá trị của thuộc tính nhiều giá trị trong một bộ riêng biệt vì mô hình quan hệ cơ bản không cho phép nhiều giá trị (một danh sách hoặc một tập hợp các giá trị) cho một thuộc tính trong một bộ giá trị. Ví dụ, vì bộ phận 5 có ba vị trí, nên tồn tại ba bộ trong quan hệ DEPT_LOCATIONS trong Hình 3.6; mỗi bộ chỉ định một trong các vị trí. Trong ví dụ của chúng tôi, chúng tôi áp dụng EQUIJOIN cho DEPT_LOCATIONS và DEPARTMENT trên thuộc tính Dnumber để nhận giá trị của tất cả các vị trí cùng với các thuộc tính DEPARTMENT khác. Trong quan hệ kết quả, các giá trị của các thuộc tính DEPARTMENT khác được lặp lại trong các bộ dữ liệu riêng biệt cho mọi vị trí mà một bộ phận có

Đại số quan hệ cơ bản không có phép toán NEST hoặc COMPRESS sẽ tạo ra một tập các bộ có dạng {, , } từ quan hệ DEPT_LOCATIONS trong Hình 3.6. Đây là một nhược điểm nghiêm trọng của phiên bản phẳng hoặc chuẩn hóa cơ bản của mô hình quan hệ. Mô hình dữ liệu đối tượng và các hệ thống quan hệ đối tượng cho phép các thuộc tính đa giá trị bằng cách sử dụng kiểu mảng cho thuộc tính.

2.  Ánh xạ các cấu trúc mô hình EER sang mô hình quan hệ

Trong phần này, chúng tôi thảo luận về ánh xạ cấu trúc mô hình EER tới các mối quan hệ bằng cách mở rộng thuật toán ánh xạ ER tới quan hệ đã được trình bày trong Phần 9.1.1.

2.1 Ánh xạ chuyên môn hóa hoặc tổng quát hóa

Có một số tùy chọn để ánh xạ một số lớp con cùng nhau tạo thành một chuyên môn hóa (hoặc cách khác, được tổng quát hóa thành một lớp cha), chẳng hạn như các lớp con {SECRETARY, TECHNICIAN, ENGINEER} của EMPLOYEE trong Hình 4.4. Hai tùy chọn chính là ánh xạ toàn bộ chuyên môn vào một bảng hoặc ánh xạ nó vào nhiều bảng. Trong mỗi tùy chọn là các biến thể phụ thuộc vào các ràng buộc của chuyên môn hóa/khái quát hóa.

Chúng ta có thể thêm một bước nữa vào thuật toán ánh xạ ER sang quan hệ từ Phần 9.1.1, có bảy bước, để xử lý ánh xạ chuyên môn hóa. Bước 8, tiếp theo, đưa ra các tùy chọn phổ biến nhất; ánh xạ khác cũng có thể. Chúng tôi thảo luận về các điều kiện theo đó mỗi tùy chọn nên được sử dụng. Chúng tôi sử dụng Attrs(R) để biểu thị các thuộc tính của quan hệ R và PK(R) để biểu thị khóa chính của R. Đầu tiên, chúng tôi mô tả chính thức ánh xạ, sau đó chúng tôi minh họa nó bằng các ví dụ.

Bước 8: Tùy chọn Mapping Specialization hoặc Generalization. Chuyển đổi mỗi chuyên biệt hóa có m lớp con {S1, S2, …, Sm} và siêu lớp (tổng quát hóa) C, trong đó các thuộc tính của C là {k, a1, …, an} và k là khóa (chính), thành các lược đồ quan hệ sử dụng một trong các tùy chọn sau:

• Tùy chọn 8A: Nhiều quan hệ—lớp cha và lớp con. Tạo quan hệ L cho C với các thuộc tính Attrs(L) = {k, a1, … , an} và PK(L) = k. Tạo một quan hệ Li cho mỗi lớp con Si, 1 ≤ i ≤ m, với các thuộc tính Attrs(Li) = {k} ∪ {các thuộc tính của Si} và PK(Li) = k. Tùy chọn này hoạt động cho bất kỳ chuyên môn nào (toàn bộ hoặc một phần, rời rạc hoặc chồng chéo)
• Tùy chọn 8B: Nhiều quan hệ—chỉ quan hệ lớp con. Tạo một quan hệ Li cho mỗi lớp con Si, 1 ≤ I ≤ m, với các thuộc tính Attrs(Li) = {các thuộc tính của Si} ∪ {k, a1, …, an} và PK(Li) = k. Tùy chọn này chỉ hoạt động đối với chuyên môn hóa có các lớp con là toàn bộ (mọi thực thể trong lớp cha phải thuộc về (ít nhất) một trong các lớp con). Ngoài ra, nó chỉ được khuyến nghị nếu chuyên môn hóa có ràng buộc về tính rời rạc. Nếu chuyên môn hóa chồng chéo, cùng một thực thể có thể được sao chép trong một số mối quan hệ.
• Tùy chọn 8C: Quan hệ đơn với một thuộc tính loại. Tạo một quan hệ đơn L với các thuộc tính Attrs(L) = {k, a1, …, an} ∪ {các thuộc tính của S1} ∪ … ∪ {các thuộc tính của Sm} ∪ {t} và PK(L) = k. Thuộc tính t được gọi là thuộc tính loại (hoặc phân biệt) có giá trị cho biết lớp con mà mỗi bộ thuộc về nếu có. Tùy chọn này chỉ hoạt động đối với chuyên môn hóa có các lớp con rời rạc và có khả năng tạo ra nhiều giá trị NULL nếu có nhiều thuộc tính (cục bộ) cụ thể tồn tại trong các lớp con.
• Tùy chọn 8D: Quan hệ đơn với nhiều thuộc tính kiểu. Tạo một lược đồ quan hệ đơn L với các thuộc tính Attrs(L) = {k, a1, …, an} ∪ {các thuộc tính của S1} ∪ … ∪ {các thuộc tính của Sm} ∪ {t1, t2, …, tm} và PK(L ) = k. Mỗi ti, 1 ≤ i ≤ m, là một thuộc tính kiểu Boolean cho biết một bộ có thuộc lớp con Si hay không. Tùy chọn này được sử dụng cho chuyên môn hóa có các lớp con chồng chéo (nhưng cũng sẽ hoạt động đối với chuyên môn hóa rời rạc).

Tùy chọn 8A và 8B là tùy chọn nhiều quan hệ, trong khi tùy chọn 8C và 8D là tùy chọn quan hệ đơn. Tùy chọn 8A tạo một quan hệ L cho lớp cha C và các thuộc tính của nó, cộng với một quan hệ Li cho mỗi lớp con Si; mỗi Li bao gồm các thuộc tính (cục bộ) cụ thể của Si, cộng với khóa chính của siêu lớp C, được truyền tới Li và trở thành khóa chính của nó. Nó cũng trở thành khóa ngoại đối với quan hệ siêu lớp. Thao tác THIẾT BỊ trên khóa chính giữa bất kỳ Li và L nào tạo ra tất cả các thuộc tính cụ thể và kế thừa của các thực thể trong Si. Tùy chọn này được minh họa trong Hình 9.5(a) cho lược đồ EER trong Hình 4.4. Tùy chọn 8A phù hợp với mọi ràng buộc về chuyên môn hóa: rời rạc hoặc chồng chéo, toàn bộ hoặc một phần. Lưu ý rằng sự ràng buộc

Π_<k>(Li) ⊆ π_<k>(L)

phải giữ cho mỗi Li. Điều này chỉ định một khóa ngoại từ mỗi Li đến L.

Trong tùy chọn 8B, hoạt động EQUI JOIN giữa mỗi lớp con và lớp cha được tích hợp vào lược đồ và mối quan hệ lớp cha L được loại bỏ, như được minh họa trong Hình 9.5(b) cho chuyên môn hóa EER trong Hình 4.3(b). Tùy chọn này chỉ hoạt động tốt khi cả ràng buộc riêng biệt và ràng buộc toàn bộ đều đúng. Nếu chuyên môn hóa không hoàn toàn, một thực thể không thuộc về bất kỳ phân lớp Si nào sẽ bị mất. Nếu chuyên môn hóa không rời rạc, một thực thể thuộc nhiều hơn một lớp con sẽ có các thuộc tính kế thừa của nó từ lớp cha C được lưu trữ dự phòng trong nhiều hơn một bảng Li . Với tùy chọn 8B, không có mối quan hệ nào chứa tất cả các thực thể trong lớp cha C; do đó, chúng ta phải áp dụng thao tác OUTER UNION (hoặc FULL OUTER JOIN) (xem Phần 6.4) cho các quan hệ Li để truy xuất tất cả các thực thể trong C. Kết quả của phép hợp ngoài sẽ tương tự như các quan hệ theo các tùy chọn 8C và 8D ngoại trừ rằng các trường loại sẽ bị thiếu. Bất cứ khi nào chúng ta tìm kiếm một thực thể tùy ý trong C, chúng ta phải tìm kiếm tất cả m quan hệ Li

Tùy chọn 8C và 8D tạo một quan hệ duy nhất để biểu diễn lớp cha C và tất cả các lớp con của nó. Một thực thể không thuộc về một số lớp con sẽ có giá trị NULL cho các thuộc tính (cục bộ) cụ thể của các lớp con này. Các tùy chọn này không được khuyến nghị nếu nhiều thuộc tính cụ thể được xác định cho các lớp con. Tuy nhiên, nếu có ít thuộc tính lớp con cục bộ tồn tại, thì các ánh xạ này thích hợp hơn so với các tùy chọn 8A và 8B vì chúng loại bỏ nhu cầu chỉ định các thao tác JOIN; do đó, chúng có thể mang lại triển khai hiệu quả hơn cho các truy vấn.

Tùy chọn 8C được sử dụng để xử lý các lớp con rời rạc bằng cách bao gồm một thuộc tính loại (hoặc hình ảnh hoặc phân biệt) t để chỉ ra mỗi bộ thuộc về lớp con nào trong số m lớp con; do đó, tập xác định của t có thể là {1, 2, …, m}. Nếu chuyên môn hóa là một phần, t có thể có các giá trị NULL trong các bộ không thuộc về bất kỳ lớp con nào. Nếu chuyên môn hóa được xác định theo thuộc tính, thì thuộc tính đó tự phục vụ cho mục đích của t và t là không cần thiết; tùy chọn này được minh họa trong Hình 9.5(c) cho chuyên môn hóa EER trong Hình 4.4.

Tùy chọn 8D được thiết kế để xử lý các lớp con chồng chéo bằng cách bao gồm m trường loại Boolean (hoặc cờ), một trường cho mỗi lớp con. Nó cũng có thể được sử dụng cho các lớp con rời rạc. Mỗi trường loại ti có thể có một miền {yes, no}, trong đó giá trị yes chỉ ra rằng bộ là thành viên của lớp con Si. Nếu chúng tôi sử dụng tùy chọn này cho chuyên môn hóa EER trong Hình 4.4, thì chúng tôi sẽ bao gồm ba thuộc tính loại—Is_a_secretary, Is_a_engineer và Is_a_technician—thay vì thuộc tính Job_type trong Hình 9.5(c). Hình 9.5(d) thể hiện ánh xạ chuyên môn hóa từ Hình 4.5 sử dụng tùy chọn 8D.

Đối với mạng hoặc phân cấp chuyên môn hóa (hoặc tổng quát hóa) đa cấp, chúng ta không phải tuân theo cùng một tùy chọn ánh xạ cho tất cả các chuyên môn hóa. Thay vào đó, chúng ta có thể sử dụng một tùy chọn ánh xạ cho một phần của cấu trúc phân cấp hoặc mạng và các tùy chọn khác cho các phần khác. Hình 9.6 cho thấy một khả năng ánh xạ vào các mối quan hệ đối với mạng EER trong Hình 4.6. Ở đây, chúng tôi đã sử dụng tùy chọn 8A cho PERSON/{EMPLOYEE, STUDENT, ALUMNUS} và tùy chọn 8C cho EMPLOYEE/{NHÂN VIÊN, GIẢNG VIÊN, SINH VIÊN} bằng cách bao gồm thuộc tính loại Employee_type. Sau đó, chúng tôi đã sử dụng tùy chọn một bảng 8D cho STUDENT_ASSISTANT/{RESEARCH_ASSISTANT, TEACHING_ASSISTANT} bằng cách bao gồm các thuộc tính loại Ta_flag và Ra_flag trong EMPLOYEE. Chúng tôi cũng đã sử dụng tùy chọn 8D cho STUDENT/STUDENT_ASSISTANT bằng cách bao gồm các thuộc tính loại Student_assist_flag trong STUDENT và cho STUDENT/{GRADUATE_STUDENT, UNDERGRADUATE_STUDENT} bằng cách bao gồm các thuộc tính loại Grad_flag và Undergrad_flag trong STUDENT. Trong Hình 9.6, tất cả các thuộc tính có tên kết thúc bằng type hoặc flag là các trường phân loại

2.2 Ánh xạ các lớp con được chia sẻ (đa kế thừa)

Một lớp con dùng chung, chẳng hạn như ENGINEERING_MANAGER trong Hình 4.6, là một lớp con của một số lớp cha, biểu thị tính đa kế thừa. Tất cả các lớp này phải có cùng một thuộc tính khóa; nếu không, lớp con dùng chung sẽ được mô hình hóa như một danh mục (kiểu hợp nhất) như chúng ta đã thảo luận trong Phần 4.4. Chúng ta có thể áp dụng bất kỳ tùy chọn nào đã thảo luận trong bước 8 cho một lớp con dùng chung, tuân theo các hạn chế đã thảo luận trong bước 8 của thuật toán ánh xạ. Trong Hình 9.6, tùy chọn 8C và 8D được sử dụng cho lớp con dùng chung STUDENT_ASSISTANT. Tùy chọn 8C được sử dụng trong quan hệ EMPLOYEE (thuộc tính Employee_type) và tùy chọn 8D được sử dụng trong quan hệ STUDENT (thuộc tính Student_assist_flag)

2.3 Ánh xạ các danh mục (kiểu union)

Chúng tôi thêm một bước nữa vào quy trình ánh xạ—bước 9—để xử lý các danh mục. Một danh mục (hoặc loại kết hợp) là một lớp con của sự kết hợp của hai hoặc nhiều lớp cha có thể có các khóa khác nhau vì chúng có thể thuộc các loại thực thể khác nhau (xem Phần 4.4). Một ví dụ là danh mục CHỦ SỞ HỮU được hiển thị trong Hình 4.8, đây là tập hợp con của sự kết hợp của ba loại thực thể PERSON, BANK, và COMPANY Danh mục khác trong hình đó, REGISTERED_VEHICLE, có hai lớp cha có cùng thuộc tính khóa.

Bước 9: Ánh xạ danh mục (kiểu union). Để ánh xạ một danh mục mà các siêu lớp xác định có các khóa khác nhau, thông thường sẽ chỉ định một thuộc tính khóa mới, được gọi là khóa thay thế, khi tạo một quan hệ tương ứng với kiểu kết hợp. Các khóa của các lớp xác định là khác nhau, vì vậy chúng ta không thể sử dụng riêng bất kỳ khóa nào trong số chúng để xác định tất cả các thực thể trong quan hệ. Trong ví dụ của chúng ta ở Hình 4.8, chúng ta tạo một quan hệ OWNER để tương ứng với loại OWNER, như được minh họa trong Hình 9.7, và bao gồm bất kỳ thuộc tính nào của loại trong quan hệ này. Khóa chính của quan hệ OWNER là khóa thay thế mà chúng tôi gọi là Owner_id. Chúng tôi cũng bao gồm thuộc tính khóa thay thế Owner_id làm khóa ngoại trong mỗi quan hệ tương ứng với một lớp cha của danh mục, để chỉ định sự tương ứng về giá trị giữa khóa thay thế và khóa gốc của mỗi lớp cha. Lưu ý rằng nếu một thực thể PERSON (hoặc BANK hoặc COMPANY) cụ thể không phải là thành viên của OWNER, thì nó sẽ có giá trị NULL cho thuộc tính Owner_id của nó trong bộ tương ứng của nó trong quan hệ PERSON (hoặc BANK hoặc COMPANY) và nó sẽ không có một bộ trong quan hệ OWNER. Bạn cũng nên thêm thuộc tính loại (không được hiển thị trong Hình 9.7) vào quan hệ OWNER để chỉ ra loại thực thể cụ thể mà mỗi bộ thuộc về (PERSON hoặc BANK hoặc COMPANY).

Đối với một danh mục mà các lớp cha có cùng khóa, chẳng hạn như VEHICLE trong Hình 4.8, thì không cần khóa thay thế. Ánh xạ của danh mục REGISTERED_VEHICLE, minh họa cho trường hợp này, cũng được thể hiện trong Hình 9.7

3.  Tóm tắt

Trong Phần 9.1, chúng ta đã chỉ ra cách thiết kế lược đồ khái niệm trong mô hình ER có thể được ánh xạ tới lược đồ cơ sở dữ liệu quan hệ. Một thuật toán để ánh xạ ER sang quan hệ đã được đưa ra và minh họa bằng các ví dụ từ cơ sở dữ liệu COMPANY. Bảng 9.1 tóm tắt sự tương ứng giữa ER và các cấu trúc và ràng buộc của mô hình quan hệ. Tiếp theo, chúng tôi đã thêm các bước bổ sung vào thuật toán thuật toán trong Phần 9.2 để ánh xạ các cấu trúc từ mô hình EER sang mô hình quan hệ. Các thuật toán tương tự được tích hợp vào các công cụ thiết kế cơ sở dữ liệu đồ họa để tự động tạo ra một lược đồ quan hệ từ một thiết kế lược đồ khái niệm.