模拟每个音乐艺术家都是一个团体或独奏者的场景

Question

我必须为涉及音乐艺术家描述的业务环境设计实体关系图 (ERD) ，我将在下面详细说明。

场景描述

• 一个艺术家有一个名称，且必须要么一组 或一个独奏演员（但不能同时）。

• 一个小组由一名或多名独舞者组成，并有若干成员（应根据组成该组的独奏者人数计算）。

• 一个独奏演员可能是一个会员众多的群体或无的集团，并可以播放一个或多个仪器。

题

如何构建一个 ERD 来表示这种场景？我对它的“或”部分感到困惑。

Answer 1

您感到困惑的场景部分可以使用称为超类型-子类型¹结构的经典构造进行建模。

我将 (1) 介绍一些相关的初步想法，(2) 详细说明我将如何在概念级别描述正在考虑的业务上下文，以及 (3) 提供额外的相关材料——例如，通过 SQL 进行相应的逻辑级别表示-DDL 声明——如下。

介绍

当在给定的业务环境中存在一组实体类型时，就会出现这种性质的结构，其中超类型具有一个或多个属性（或属性），这些属性（或属性）由集群中的其余实体类型共享，即，亚型。反过来，每个子类型都有一组仅适用于自身的特定属性。

超类型-子类型集群可以有两种：

• 独家。当超实体类型的实例必须始终具有一个且只有一个子类型对应物时出现；因此，所讨论的潜在子类型出现是相互排斥的。这是与您的场景有关的类型。

  出现独占超类型-子类型的典型案例是一个组织和个人都被视为合法方的业务领域，就像本系列文章中讨论的情况一样。

• 非排他性。当一个超类型实例可以由多个子类型出现来补充时出现，每个子类型都被迫属于不同的类别。

  这些帖子中处理了这种超类型子类型的示例。

_{注意： 值得一提的是，超类型-子类型结构——作为概念特征的元素——不属于特定的数据管理理论框架，无论是关系的、网络的还是分层的——每个都提供特定的结构来表示概念元素——。}

_{还需要指出的是，虽然超类型-子类型集群与面向对象应用程序编程 (OOP) 的继承和多态有一定的相似性，但它们实际上是不同的设备，因为它们用于不同的目的。在数据库概念模型中——必须代表现实世界的方面——处理结构特征以描述信息需求，而在 OOP 多态性和继承中，除其他外，一个 (a) 草图和 (b) 实现计算和行为特征，绝对属于应用程序设计和编程的方面。}

_{除此之外，一个单独的OOP类-being应用程序组分- ，并没有必要必须“镜像”属于手头的数据库的概念层次的个体实体类型的结构。在这方面，应用程序员通常可以创建例如“组合”两个（或更多）不同概念级实体类型的所有属性的单个类，并且这样的类也可以包括计算属性。}

使用实体-关系构造来表示具有超类型-子类型结构的概念模型

您要求提供实体关系图（为简洁起见为 ERD），但是，尽管是一个非凡的建模平台，但最初的方法（由 Peter Pin-Shan Chen 博士^{2 介绍}）并没有提供足够的结构来表示此类场景以适当的数据库概念模型所需的精度进行讨论。

因此，有必要对上述方法进行一些扩展，这种情况导致开发了一种有助于创建增强型实体关系图(EERD)的方法，该方法自然地用新的表达特征丰富了初始图表技术. 准确地说，这些特征之一是描绘超类型-子类型结构的可能性。

建模您感兴趣的上下文

图 1 中显示的插图是一个 EERD（使用类似于 Ramez A. Elmasri 和 Shamkant B. Navathe ³提出的符号，他们将此类结构称为超类/子类），其中我对您描述的业务领域进行了建模，并考虑了所有规格。它也有 PDF 格式，可以从 Dropbox 下载。

正如您在上述图表中看到的，Group和SoloPerformer都显示为超实体类型的专有子Artist类型：

图表说明

为了开始对 EERD 的描述，重要的是要指出你的句子

• “一个艺术家必须要么一个组或一个SoloPerformer（但不是两者）”

与手头的超类型-子类型集群的不相交性和完整性方面有关。

不相交

不相交特征特别重要，因为正是在这里你提到的“或部分”发挥作用，因为 anArtist必须是一个子类型实例或另一个，我在 EERD 中通过小包含字母“d”的圆，一个接收不相交规则名称的结构。

当一个超类型可以由它的一个或多个可能的子类型补充时，这一点必须用一个小圆圈表示，上面有一个带有字母“o”的标签，这个符号称为重叠规则。

鉴别器属性

同样在这个超类型-子类型关联的不相交因素的范围内，值得密切关注Artist.Type属性，因为它在这种安排中执行了一个非常相关的任务：它充当子类型鉴别器。它这样命名因为它是分列的独家财产样亚型与一个特定实例Artist涉及到。

在非排他集群的情况下，不需要使用鉴别器属性，因为某个超类型可以有多个子类型作为补充（如上所述）。

总专业化规则和完备性

规定每个Artist必须始终有一个补充子类型实例的要求与该集群的完整性特征有关。这是通过总特化规则来描述的，通过连接 (a)Artist超类型和 (b) 不相交规则结构的双线符号来证明。

将团体与独奏者联系起来

评估句子

• “一个团体由一个或多个SoloPerformers 组成”

和

• “一个SoloPerformer可能是许多组的成员，也可能不属于任何组”，

人们可以认识到这两种亚型都涉及多对多(M:N) 关联（或关系），我用标记为 的菱形框表示Group-SoloPerformer。

如果在实现关系数据库作为基础表，该组件将是非常有用的派生（即进行计算），总Number的SoloPerformers构成一个具体的Group（那你指定的要求之一）。

独奏者与乐器之间的联系

规定

• “一位独奏者 [...] 可以演奏一种或多种乐器”

允许我们推断，同时，

• “乐器由零个、一个或多个 SoloPerformers 演奏”。

因此，这是 M:N 关联的另一个例子，我使用指定的菱形图形SoloPerformer-Instrument来曝光它。

附加材料

为了阐述超类型-子类型结构的范围，我将包含另外两个资源，即，

1. 图 2 中显示的 IDEF1X ⁴图表（您也可以从 Dropbox 下载它的 PDF 格式），它说明了此类图表关于相关业务领域的表达能力；和

2. 各自的说明性 DDL 逻辑结构，它举例说明了如何借助 SQL 数据库管理系统来管理所讨论的完整场景。

1. IDEF1X 表示

IDEF1X 信息建模技术当然提供了描绘超类型-子类型结构的能力，但有一个限制：它没有提供一种视觉机制来指示一个精确的簇是排他性的还是非排他性的（它的“本机”符号只能传达所有可能的重要子实体类型的完整或不完整识别）。幸运的是，我们可以使用信息工程 (IE) 符号来更准确地显示这一重要方面，同时利用 IDEF1X 标准的描述能力。

在这种技术中，您问题的主要特征被命名为“分类关系”，其中超类型被称为“通用实体”，而子类型被称为“类别实体”。但是，我将在这篇文章中继续使用术语超类型-子类型，因为 (1) 它被关系模型的创始人 Edgar Frank Codd 博士使用，(2) 它更广为人知，以及 (3) IE 表示法是使用而不是“原生”的。

外键和超类型-子类型集群

正如所证明的，IDEF1X 提供了进一步的优势：展示外键 (FK) 定义的方法，如果从业者要在关系数据库中表示超类型-子类型关联，这些元素是最重要的元素。

为了描绘这样一种关联的，父类型的PRIMARY KEY（PK）性质，即Artist.ArtistNumber，具有迁移到Group和SoloPerformer，虽然它已被分配了两个不同的角色名称^5,6，GroupNumber和SoloPerformerNumber分别用于强调的目的属性在每个子实体类型的上下文中传达的含义。

除了被表征为 PK 之外，Group.GroupNumber和SoloPerformer.SoloPerformerNumber属性同时被描述为引用Artist.ArtistNumber超类型 PK 属性的外键 (FK) 。

因此，由于每一个SoloPerformer和Group出现都依赖于一个确切的Artist实例，这些实体类型涉及到一个识别关联，该关联通过前面段落中描述的 PK 属性迁移过程生效。

外键和关联实体类型

IDEF1X 图也用于说明构成两个关联实体类型相关性的 PK 的 FK ，即，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;

以这种方式，通过非常相同的逻辑级设备，即关系或表（无论是基础的还是派生的），可以很容易地（以声明方式）操纵所有重要数据。显然，当关系数据库中表示的概念实体类型具有更多感兴趣的属性时，视图的使用更有效，但在当前场景中这是一种值得说明的可能性。

参考

_{¹ Codd, EF（1979 年 12 月）。扩展数据库关系模型以获取更多含义，数据库系统上的 ACM 事务，第 4 卷第 4 期（第 397-434 页）。纽约，纽约，美国。}

_{² Chen, PP（1976 年 3 月）。The Entity-Relationship Model—Toward a Unified View of Data , ACM Transactions on Database Systems - 特刊：国际超大型数据库会议论文：1975 年 9 月 22-24 日，马萨诸塞州弗雷明汉，第 1 卷第 1 期（pp . 9-36）。纽约，纽约，美国。}

_{³ Elmasri, R & Navathe, SB (2003)。数据库系统基础，第四版。Addison-Wesley Longman Publishing Co., Inc. 美国马萨诸塞州波士顿。}

_{⁴美国国家标准与技术研究院 [NIST]（1993 年 12 月）。信息建模的集成定义 (IDEF1X)，联邦信息处理标准出版物，第 184 卷。美国。}

_{⁵ Codd，英孚（1970 年 6 月）。数据的关系模型的大型共享数据库，ACM通讯，第13卷第6期（第377-387）。纽约，纽约，美国。}

_{⁶见参考文献⁴}