我必須為涉及音樂藝術家描繪的業務環境設計一個實體關係圖 (ERD) ，我將在下面詳細說明。

場景描述

• Artist有一個Name ，並且必須是Group或 Solo Performer（但不能同時是兩者）。
• 一個團體由一名或多名獨奏演員組成，並有一定數量的成員（應根據組成該團體的**獨奏演員人數計算）。
• 獨奏者可能是多個團體的成員，也可能是任何團體的成員，並且可能會演奏一種或多種樂器。

題

如何建構一個 ERD 來表示這種情況？我對它的“或”部分感到困惑。

您混淆的場景部分可以使用稱為超類型 - 子類型1結構的經典構造建模。

我將 (1) 介紹一些相關的初步想法，(2) 詳細說明我將如何描述 - 在概念層面 - 正在考慮的業務環境，以及 (3) 提供其他相關材料 - 例如，通過 SQL 的相應邏輯級別表示-DDL 聲明——如下。

介紹

當在給定的業務環境中存在一個實體類型集群時，就會出現這種性質的結構，其中超類型具有一個或多個屬性（或屬性），這些屬性（或屬性）由集群中的其餘實體類型共享，即,亞型。反過來，每個子類型都有一組僅適用於自身的特定屬性。

超型-亞型群可以有兩種：

• 獨家。當超實體類型的實例必須始終具有一個且只有一個子類型對應物時出現；因此，所討論的潛在亞型出現是相互排斥的。這是與您的方案有關的那種。

出現排他性超類型-子類型的典型案例是一個組織和個人都被視為法律方的業務領域，就像本系列文章中討論的情況一樣。

• 非排他性的。當一個超類型實例可以由多個子類型實例補充時出現，每個子類型實例都必須屬於不同的類別。

這些文章中處理了這種超類型-子類型的範例。

注意：值得一提的是，超類型-子類型結構——作為概念特徵的元素——不屬於特定的數據管理理論框架，無論是關係、網路還是層次結構——每個都提供特定的結構來表示概念元素——。

還需要指出的是，儘管超類型-子類型集群與物件導向應用程序程式 (OOP)繼承和多態性有一定的相似之處，但它們實際上是不同的設備，因為它們服務於不同的目的。在必須代表現實世界方面的數據庫概念模型中，一個處理結構特徵以描述資訊需求，而在 OOP 多態性和繼承中，除其他外，一個 (a) 草圖和 (b) 實現計算和行為特徵，絕對屬於應用程序設計和程式的方面。

除此之外，單個 OOP類（作為應用程序組件）不一定必須“鏡像”屬於手頭數據庫概念級別的單個實體類型的結構。在這方面，應用程序員通常可以創建例如一個“組合”兩個（或更多）不同概念級實體類型的所有屬性的單個類，並且這樣的類也可以包括計算屬性。

使用實體關係構造來表示具有超類型-子類型結構的概念模型

您要求提供實體關係圖（簡稱 ERD），但儘管是一個非凡的建模平台，但由 Peter Pin-Shan Chen 博士介紹的原始方法2並未提供足夠的構造來表示此類場景以適當的數據庫概念模型所需的精度進行討論。

因此，有必要對上述方法進行一些擴展，這種情況導致開發一種方法，該方法有助於創建增強的實體關係圖(EERD)，自然地，用新的表達特徵豐富了初始繪圖技術. 準確地說，這些特徵之一是描述超型-亞型結構的可能性。

建模您感興趣的上下文

圖 1所示的插圖是一個 EERD（使用類似於 Ramez A. Elmasri 和 Shamkant B. Navathe 3提出的符號，他們將此類結構稱為超類/子類），我在其中建模了您描述的業務領域，考慮了所有規格。它還以 PDF 格式提供，可從 Dropbox 下載。

正如您在上述圖表中所見，兩者Group和SoloPerformer都顯示為超實體類型的專有子Artist類型：

圖表說明

為了開始對 EERD 的描述，重要的是要指出你的句子

• “藝術家必須是團體或獨奏者（但不能同時是兩者）”

與手頭的超型-亞型集群的不相交性和完整性方面有關。

脫節

不相交特性特別重要，因為它就是你提到的“或部分”發揮作用的地方，因為 anArtist必須是一個子類型實例或另一個，我在 EERD 中通過 small包含字母“d”的圓圈，這是一個接收不相交規則名稱的結構。

當一個超類型可以由一個或多個可能的子類型補充時，這一點必須用一個小圓圈來表示，該圓圈帶有一個帶有字母“o”的標籤，這個符號稱為重疊規則。

鑑別器屬性

同樣在這種超類型 - 子類型關聯的不相交因素的範圍內，值得密切關注該Artist.Type屬性，因為它在這種安排中執行了一項非常相關的任務：它充當子類型鑑別器。它以這種方式命名，因為它是指出與特定實例相關的子類型的專有類型Artist的屬性。

在非排他群的情況下，不需要使用鑑別器屬性，因為某個超類型可以有多個子類型作為補充（如上所述）。

總專業化規則和完整性

規定每個Artist必須始終有一個補充子類型實例的要求與該集群的完整性特性有關。這是通過一個總的專業化規則Artist來描述的，通過連接（a）超類型和（b）不相交規則結構的雙線符號來證明。

將團體與獨奏者聯繫起來

評估句子

• “一個組由一個或多個SoloPerformers 組成”

和

• “一個SoloPerformer可能是許多組的成員，也可能不是任何組的成員”，

人們可以認識到這兩種子類型都涉及多對多(M:N) 關聯（或關係），我用標記為 的菱形框表示Group-SoloPerformer。

如果在關係數據庫中作為基表實現，則此組件對於**導出（即執行計算）構成具體（您指定的要求之一Number）的總數非常有用。SoloPerformers``Group

獨奏者與樂器之間的關聯

規定

• “在 SoloPerformer$$ … $$可以演奏一種或多種樂器”

允許我們推斷，同時，

• “一種樂器由零個、一個或多個 SoloPerformers 演奏”。

因此，這是 M:N 關聯的另一個範例，我使用指定的菱形圖形SoloPerformer-Instrument來展示它。

附加材料

為了闡述超類型-子類型結構的範圍，我將包含另外兩個資源，即

1. 圖 2中顯示的 IDEF1X 4圖表（您也可以從 Dropbox 以 PDF 格式下載它），說明此類圖表對所討論的業務領域的表達能力；和
2. 各自的說明性 DDL 邏輯結構，舉例說明瞭如何借助 SQL 數據庫管理系統來管理正在討論的整個場景。

1.IDEF1X表示

IDEF1X 資訊建模技術當然提供了描繪超類型-子類型結構的能力，但有一個限制：它沒有提供一種視覺機制來指示一個精確的集群是排他的還是非排他的（它的“本機”符號只能交流所有可能的重要性子實體類型的完整或不完整辨識）。幸運的是，可以使用資訊工程 (IE) 符號來更準確地顯示這一最重要的方面，同時利用 IDEF1X 標準的描述能力。

在這種技術中，您的問題的主要特徵被命名為“分類關係”，其中超類型稱為“通用實體”，子類型接收“類別實體”的名稱。但是，我將在這篇文章中繼續使用術語超類型 - 子類型，因為（1）它被關係模型的創始人 Edgar Frank Codd 博士使用，（2）它更廣為人知，（3）IE 表示法是使用而不是“本機”。

外鍵和超類型-子類型集群

正如所展示的，IDEF1X 提供了進一步的優勢：展示外鍵 (FK) 定義的方法，如果從業者要在**關係數據庫中表示超類型-子類型關聯，則這些元素是最重要的元素。

為了描述這種關聯，超類型的主鍵（PK）屬性，即Artist.ArtistNumber，必須遷移到Group和SoloPerformer，儘管它已被分配了兩個不同的角色名稱5 、 6GroupNumber和，SoloPerformerNumber以強調的目的屬性在每個子實體類型的上下文中傳達的含義。

除了被描述為 PK 之外，Group.GroupNumber和SoloPerformer.SoloPerformerNumber屬性同時被描述為引用Artist.ArtistNumber超類型 PK 屬性的外鍵 (FK)。

因此，由於每個事件都依賴於具體實例的存在SoloPerformer，因此這些實體類型涉及辨識關聯，該關聯通過前面段落中描述的 PK 屬性遷移過程生效。Group``Artist

外鍵和關聯實體類型

IDEF1X 圖也用於說明 FK 組成兩個關聯實體類型相關性的 PK，即GroupMember和SoloPerformerInstrument; 第一個連接兩個子類型，第二個連接一個子類型和一個獨立的實體類型，即Instrument.

2. 說明性 SQL-DDL 邏輯聲明

如前所述，超類型-子類型結構是一種表達某些特定於業務領域的關於資訊需求的概念化的手段，而這些概念化又可以通過必須對應於特定結構提供的不同結構在數據庫中表示。理論範式（無論是關係的、網路的還是分層的），然後是設計者使用的數據庫管理系統。

關係範式的多個優點之一是它允許以其自然結構表示資訊，並且關係理論中提出的系統最流行的近似是各種 SQL 數據庫管理系統。

因此，最後，這裡有一些範例 DDL 語句——包括 (a)基表模式以及 (b)一些相關的約束——它們在抽象的邏輯級別上代表了上面處理的概念建模練習：

--
--
CREATE TABLE Artist ( -- Stands for the supertype.
   ArtistNumber    INT      NOT NULL,
   Name            CHAR(30) NOT NULL,
   Type            CHAR(1)  NOT NULL, -- Holds the discriminator values.
   CreatedDateTime DATETIME NOT NULL,
   --
   CONSTRAINT Artist_PK      PRIMARY KEY (ArtistNumber),
   CONSTRAINT Artist_AK      UNIQUE      (Name), -- ALTERNATE KEY.
   CONSTRAINT Artist_Type_CK CHECK       (Type IN ('G', 'S')) -- Enforces retaining either ‘G’, for ‘Group’, or ‘S’, for ‘SoloPerformer’, only.
);

CREATE TABLE MyGroup ( -- Represents one subtype.
   GroupNumber   INT  NOT NULL, -- To be constrained as PK and FK simultaneously.
   FormationDate DATE NOT NULL,
   --
   CONSTRAINT MyGroup_PK         PRIMARY KEY (GroupNumber),
   CONSTRAINT MyGroupToArtist_FK FOREIGN KEY (GroupNumber)
       REFERENCES Artist (ArtistNumber)  
);

CREATE TABLE SoloPerformer ( -- Denotes the other subtype.
   SoloPerformerNumber INT  NOT NULL, -- To be constrained as PK and FK simultaneously.
   BirthDate           DATE NOT NULL,
   --
   CONSTRAINT SoloPerformer_PK               PRIMARY KEY (SoloPerformerNumber),
   CONSTRAINT SoloPerformerNumberToArtist_FK FOREIGN KEY (SoloPerformerNumber)
       REFERENCES Artist (ArtistNumber)  
);

CREATE TABLE GroupMember ( -- Stands for a M:N association involving the two subtypes.
   MemberNumber INT  NOT NULL,
   GroupNumber  INT  NOT NULL,
   JoinedDate   DATE NOT NULL,
   --
   CONSTRAINT GroupMember_PK                PRIMARY KEY (MemberNumber, GroupNumber), -- Composite PK.
   CONSTRAINT GroupMemberToSoloPerformer_FK FOREIGN KEY (MemberNumber)
       REFERENCES SoloPerformer (SoloPerformerNumber),
   CONSTRAINT GroupMemberToMyGroup_FK       FOREIGN KEY (GroupNumber)
       REFERENCES MyGroup       (GroupNumber)  
);

CREATE TABLE Instrument ( -- Represents an independent entity type.
   InstrumentNumber INT      NOT NULL,
   Name             CHAR(30) NOT NULL,
   --
   CONSTRAINT Instrument_PK PRIMARY KEY (InstrumentNumber),
   CONSTRAINT Instrument_AK UNIQUE      (Name) -- ALTERNATE KEY.  
);

CREATE TABLE SoloPerformerInstrument ( -- Denotes another M:N association, in this case between a subtype and an independent entity type.
   SoloPerformerNumber INT  NOT NULL,
   InstrumentNumber    INT  NOT NULL,
   CreatedDate         DATE NOT NULL,
   --
   CONSTRAINT SoloPerformerInstrument_PK                PRIMARY KEY (SoloPerformerNumber, InstrumentNumber), -- Composite PK.
   CONSTRAINT SoloPerformerInstrumentToSoloPerformer_FK FOREIGN KEY (SoloPerformerNumber)
       REFERENCES SoloPerformer (SoloPerformerNumber),
   CONSTRAINT SoloPerformerInstrumentToInstrument_FK    FOREIGN KEY (InstrumentNumber)
       REFERENCES Instrument    (InstrumentNumber)  
);
--
--

數據完整性和一致性注意事項

與之前解釋的所有內容一致，設計者必須保證每個“超類型”行始終由其隨附的“子類型”對應物補充，並且反過來，確保所述“子類型”行與值兼容包含在超類型“鑑別器”列中。

以聲明方式強制執行上述情況（正如關係框架所建議的那樣）是非常實用和優雅的，但是，遺憾的是，沒有一個主要的 SQL 平台提供了合適的機制來執行此操作（據我所知）。因此，使用ACID TRANSACTIONS非常方便，以便在數據庫中始終滿足這些條件（其他選擇是使用 TRIGGERS，但它們往往會使事情變得不整潔）。

數據派生注意事項

關係模型的主要方面之一是它將數據派生視為數據管理中的最重要因素。因此，它有助於創建 (a)基本關係——或SQL 中的基本表，如上面的 DDL 語句所示——和 (b)派生關係—— SQL 中的派生表，即那些由 SELECT 操作的 dint 聲明的表，可能是固定為進一步利用的觀點——。

因此，可以聲明一個收集“完整”組數據點的視圖：

CREATE VIEW FullGroup AS
   SELECT G.GroupNumber,
          A.Name,
          A.CreatedDateTime,
          G.FormationDate
        FROM Artist A
        JOIN MyGroup G 
          ON G.GroupNumber = A.ArtistNumber;

以及結合“完整” SoloPerformer資訊的其他視圖：

CREATE VIEW FullSoloPerformer AS
   SELECT SP.SoloPerformerNumber,
           A.Name,
           A.CreatedDateTime,
          SP.BirthDate
        FROM Artist A
        JOIN SoloPerformer SP 
          ON SP.SoloPerformerNumber = A.ArtistNumber;

以這種方式，很容易通過相同的邏輯級設備（即關係或表（無論是基礎的還是派生的））以聲明方式操作所有重要數據。顯然，當關係數據庫中表示的概念實體類型具有更多感興趣的屬性時，視圖的使用會更有效，但在目前場景中值得說明這種可能性。

---

參考

1 Codd, EF（1979 年 12 月）。擴展數據庫關係模型以擷取更多含義，數據庫系統上的 ACM 事務，第 4 卷第 4 期（第 397-434 頁）。紐約，紐約，美國。

2 Chen, PP（1976 年 3 月）。實體關係模型——邁向統一的數據視圖，數據庫*系統上的 ACM 事務 - 特刊：超大型數據庫國際會議論文：1975 年 9 月 22 日至 24 日，馬薩諸塞州弗雷明漢，*第 1 卷第 1 期（pp . 9-36). 紐約，紐約，美國。

3 Elmasri, R & Navathe, SB (2003)。數據庫系統基礎，第四版。Addison-Wesley Longman Publishing Co., Inc. 美國馬薩諸塞州波士頓。

4美國國家標準與技術研究院$$ NIST $$（1993 年 12 月）。資訊建模的集成定義 (IDEF1X)，聯邦資訊處理標准出版物，第 184 卷。美國。

5 Codd, EF（1970 年 6 月）。大型共享數據庫的數據關係模型， ACM通信，第 13 卷第 6 期（第 377-387 頁）。紐約，紐約，美國。

6見參考文獻4

MDCCL的答案很吸引人，很有教育意義，而且大概是正確的（儘管高於我的工資等級）。

相比之下，我重新解釋了這個問題，並回到了最簡單的解決方案的基礎上。也許我在作弊，並沒有真正回答這個問題……但無論如何。

我在閱讀和重新閱讀問題時感到困惑。當看到“藝術家”這個詞時，我一直在想個別的人。但不，它的意思是“藝術品牌標籤”，就像一張音樂專輯有一個標題和一個“藝術家”，無論藝術家是像Johnny Cash這樣的個人還是像The Cure這樣的團體。

讓我們以現在被稱為王子的藝術家為例。他出版的專輯如下：

• 王子
• 王子與革命
• 太子與新發電
• [自定義符號]

所有這四個都是“藝術家”的實例。特別是，在他的樂隊The Revolution但沒有在New Power Generation中的兩位女性 Wendy Melvoin 和 Lisa Coleman 離開後以Wendy & Lisa品牌繼續她們的職業生涯。

因此，我們將與Wendy 和 Lisa一起擁有另一個“藝術家”實例，而 Melvoin 和 Coleman 個人將分別是表演者，但不是“藝術家”。這些單獨的女性將被分配為兩個“藝術家”（（1）王子與革命，（2）溫迪和麗莎）的表演者。

下圖笨拙地嘗試以緊湊的方式顯示此範例數據。我們展示了屬於兩個不同樂隊（藝術家）的兩個帶下劃線的女性（表演者）。我們展示了斜體字，Prince，屬於四個樂隊（藝術家），但不屬於最後一個樂隊（藝術家）。

如果這描述了業務領域，那麼我會提出下表設計（和 ERD）。

基本上我們有一對多對多關係：

• 藝術家（無論是獨奏還是樂隊）是指派的一個或多個表演者。表演者可以是一個或多個“藝術家”/樂隊的成員。
• 表演者可以演奏一種或多種樂器。每個樂器可以有許多演奏者被列為能夠演奏它。

至於“Group”和“SoloPerformer”：

• “獨奏”只是任何“藝術家”，只分配了一個“表演者”。
  （成員資格表中只有一個子記錄將該藝術家的 ID 分配為外鍵。）
• “組”是指分配了多個“表演者”的任何“藝術家”。
  （成員資格表中的兩個或多個子記錄將該藝術家的 ID 分配為外鍵。）

如果業務邏輯的一部分是區分 Artist 項目是 Solo 還是 Group，我們可以在 SQL 中對只有一行 Membership 表的 Artist 行和有多個行的 Artist 行執行查詢。但實際上，通過以下方式非規範化這些資訊可能是有意義的：

• 在 Artist 表上添加“Solo/Group”布爾值，然後……
• 在應用程序中強制執行此單/多成員資格。

如果問題的目標是在數據庫結構（或 ERD）中強制執行這種 Solo 與 Group 的區別，那麼我失敗了。但無論哪種方式，我希望這個答案可能會被證明是有趣和有用的。

引用自：https://dba.stackexchange.com/questions/92065