对每个音乐艺术家都是乐队或独奏演员的场景进行建模
Answers:
可以用经典结构（称为supertype-subtype 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提出的那些符号3谁是指这样的结构为，超/亚类）其中I建模的业务域你描述考虑所有规格。也可以从Dropbox下载PDF形式提供。
如您在前面的图中所看到的，Group和SoloPerformer都显示为超实体类型的互斥子Artist类型：
图表说明
为了开始对EERD进行描述，请务必指出您的句子
- “一个艺术家必须要么一个组或一个SoloPerformer（但不是两者）”
与手头上超型-亚型簇的不相交和完整性有关。
脱节
脱节功能特别重要，因为在这里您提到的“或部分”就在其中发挥作用，因为an Artist必须是一个子类型实例或另一个，我在EERD中通过小实例指定包含字母“ d”的圆，该结构接收不相交规则的名称。
当超类型可以由一个或多个其可能的亚类型补充时，这一点必须由一个小圆圈来表示，该小圆圈持有带有字母“ o”的标签，该符号称为重叠规则。
鉴别属性
同样在此超型-亚型关联的不相交因子的范围内，值得密切注意该Artist.Type属性，因为它在这种安排中执行了非常相关的任务：它充当亚型区分符。它这样命名因为它是分列的独家财产样亚型与一个特定实例Artist涉及到。
在非排他性簇的情况下，不需要使用鉴别属性，因为某些超类型可以具有多个子类型作为补码（如上所示）。
总体专业化规则和完备性
规定每个人Artist必须始终拥有一个补充子类型实例的要求与该集群的完成特性有关。这是通过总专业化规则来描绘的，该规则通过将（a）Artist超型与（b）不相交规则构造连接起来的双线符号来说明。
将组与独奏演员联系起来
评价句子
- “一组由一个或多个SoloPerformers组成 ”
和
- “ SoloPerformer可以是多个组的成员，也可以不是任何组的成员 ”，
可以识别出这两个亚型都涉及到多对多（M：N）关联（或关系），我用标记为的菱形框表示该关联Group-SoloPerformer。
如果在实现关系数据库作为基础表，该组件将是非常有用的派生（即进行计算），总Number的SoloPerformers构成一个具体的Group（那你指定的要求之一）。
独奏演员与乐器之间的联系
规定
- “ SoloPerformer […]可以演奏一种或多种乐器”
允许我们同时推断
- “一种乐器由零个或一个或多个SoloPerformers演奏”。
因此，这是M：N关联的另一个示例，我使用指定的菱形图形将SoloPerformer-Instrument其暴露出来。
附加材料
为了阐明超类型子类型结构的范围，我将包括另外两个资源，即
图2中显示的IDEF1X 4图表（您也可以从Dropbox下载PDF格式的PDF），该图说明了此类图表在涉及业务领域方面的表现力；和
相应的说明性DDL逻辑结构，举例说明了如何利用SQL数据库管理系统来管理所讨论的完整方案。
1. IDEF1X表示
IDEF1X信息建模技术当然具有描绘超型-亚型结构的能力，但有一个局限性：它没有提供一种视觉机制来指示精确的簇是排他性还是非排他性（它的“本机”符号只能交流对所有可能的重要子实体类型的完整或不完整标识）。幸运的是，在利用IDEF1X标准的描述功能的同时，可以采用信息工程（IE）表示法更准确地显示这一至关重要的方面。
在这种技术中，您问题的主要特征是“分类关系”，其中超类型称为“通用实体”，而子类型则称为“类别实体”。但是，在本文中，我将继续使用术语“ 超型-亚型”，因为（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的FKS 缔实体类型的相关性，即，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平台提供适当的机制来做到这一点。因此，使用酸交易以使这些条件始终在数据库中得到满足是非常方便的（另一种选择是利用TRIGGERS，但它们会使事情变得不整洁）。
数据推导注意事项
关系模型的主要方面之一是它将数据派生视为数据管理中的最重要因素。相应地，它有助于创建（a）基本关系-或SQL中的基本表，如上面的DDL语句所示- 和（b）派生关系-SQL中的派生表，即由SELECT操作的声明所声明的那些固定为进一步开发的视图。
因此，可以声明一个收集“完整” 组数据点的视图：
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 EF科德（1979年12月）。扩展数据库关系模型以获取更多含义，《数据库系统上的ACM事务》，第4卷，第4期（第397-434页）。美国纽约州纽约市。
2 Chen，PP（1976年3月）。实体关系模型走向数据的统一视图，ACM交易数据库系统-特刊：论文从国际会议上非常大的数据基地：9月22-24日，1975年，马萨诸塞州弗雷明汉，第1卷第1期（第9-36）。美国纽约州纽约市。
3 Elmasri，R＆Navathe，SB（2003）。数据库系统基础，第四版。美国马萨诸塞州波士顿，Addison-Wesley Longman出版有限公司。
4美国国家标准技术研究所[NIST]（1993年12月）。信息建模的集成定义（IDEF1X），联邦信息处理标准出版物，第184卷。美国。
5 EF哥德（1970年6月）。数据的关系模型的大型共享数据库，ACM通讯，第13卷第6期（第377-387）。美国纽约州纽约市。
6参见参考文献4
MDCCL 的答案令人着迷，具有教育意义，并且大概是正确的（尽管高于我的薪水等级）。
相反，我重新解释了“问题”，并回到了最简单的解决方案的基础知识。也许我是在作弊，没有真正回答问题……但是无论如何，这还是可行的。
在阅读和重新阅读问题时，我感到困惑。当看到“艺术家”一词时，我一直在思考个人。但是，不，它的意思是“艺术品牌标记”，就像音乐唱片专辑具有标题和“艺术家”一样，无论艺术家是像Johnny Cash这样的个人还是像The Cure这样的团体。
让我们以现在被称为王子的艺术家为例。他的发行专辑为：
- 王子
- 王子与革命
- 王子与新能源发电
- [ 自定义符号 ]
所有这四个都是“艺术家”的实例。尤其是，有两名女性，温迪·梅尔沃因（Wendy Melvoin）和丽莎·科尔曼（Lisa Coleman），在他的乐队《革命》中，但在《新动力一代》中则没有，她们离开后以温迪＆丽莎品牌继续他们的职业生涯。
因此，我们将与Wendy＆Lisa一起讨论“艺术家”的另一个例子，而个人Melvoin和Coleman分别是表演者，而不是“艺术家”。这些女性个体将被分配为两位“艺术家”的表演者（（1）《王子与革命》，（2）温迪和丽莎。
下图是笨拙的尝试，以紧凑的方式显示此示例数据。我们展示了属于两个不同乐队（艺术家）的两个带下划线的女人（表演者）。并且我们显示斜体的人Prince属于四个乐队（Artists），但不属于最后一个乐队（Artist）。
如果这描述了业务领域，那么我将提出以下表格设计（和ERD）。
基本上，我们有一对多对多关系：
- 一个艺术家（无论是独奏还是乐队）被分配了一个或多个表演者。和表演者可以是一个的成员或多个“艺术家” /频带。
- 表演者可以演奏一种或多种乐器。每个乐器可以列出许多可以演奏的演奏者。
至于“组”和“ SoloPerformer”：
- “独奏”只是分配了一个“表演者”的任何“艺术家”。
（“成员资格”表中只有一个子记录将该艺术家的ID分配为外键。） - “组”是指分配了多个“表演者”的任何“艺术家”。
（“成员资格”表中的两个或更多子记录已将“艺术家的ID”分配为外键。）
如果业务逻辑的一部分是要区分“独奏”与“组”的“艺术家”项目，则我们可以在SQL中对仅具有一行成员资格表的艺术家行和具有多个“成员资格”表的艺术家行执行查询。但实际上，可以通过以下方法对信息进行非规范化处理：
- 在Artist表上添加“ Solo / Group”布尔值，然后…
- 在应用程序中强制执行这种单一/多重成员资格。
如果问题的目标是在数据库结构（或ERD）中强制执行这种“独奏”与“组”区分，那么我就失败了。但是无论哪种方式，我都希望这个答案可能证明有趣和有用。
MDCCL的答案很好地总结了EERD级别上描述的超类/子类或泛化/专业化背后的概念。
该答案旨在基于带有已定义列的已定义表，指出何时有必要将EERD转变为关系设计的三种设计模式或技术。
这是三个：
- 单类继承
- 类表继承
- 共享主键
前两种是替代方案，一种适用于几乎所有数据都与超类有关的简单情况。第二个比较复杂，但是当许多数据与几个子类有关时可能会更好。“继承”一词用于表示设计提供了与对象模型中的继承相同的表达能力。
共享主键是一种技术，子类表中的条目可以通过“继承”超类表中相应条目的标识来获取标识。
在SO中，有三个带有这些名称的标签。每个标签下的“信息”选项卡提供了描述，标签下有很多问题。
也有很多网站介绍了这些技术。我推荐Martin Fowler的那些。我喜欢他介绍的方式。这是几个网页：