database - 数据建模:父类(super class)型/子类型

Question

寻找找出建模以下需求的正确方法。

有3种类型的“派对”要关注，粉丝，乐队和BandMember。

BandMember将始终与Band关联，并且还可以是任何Band的粉丝。

粉丝，乐队和乐队成员之间有共同的属性，但是这3个中的每一个也将具有自己的独特属性。

粉丝可以是任何乐队的粉丝，也可以完全不粉丝

这只是一个较大想法的一小部分，但在扩展模型时却造成了混乱。我认为它必须是图2或其他选项，因为我看不到BandMember如何与第一个模型中的Band关联。

感谢您的投入。

Answer 1

警告

首先要注意一些限制。所有使用或存储的数据都需要一起考虑/建模。例如。无论如何，您都已经发现“在扩展模型时造成混乱”。在我这方面，由于不知道Parties(子类型)与其他实体之间的关系，因此无法提供完全正确的答案(不会改变)。

由于您要分两批提供数据，因此答案将分两批提供，而第二批将需要更改第一个模型。不用抱怨，只是事先给您建议，因为如果我先查看所有数据，就可以避免这种情况。

真的很高兴您认识到(a)对数据建模和(b)进行概念，逻辑和物理科学(已记录30多年)的需求。那正是我所做的。您无法想象正式流程节省的时间和精力。

但是，我在SO的答案中并没有遇到这个问题，因为它是一个“问答”网站，所以我必须在提问者级别回答。 (我比其他人更充分地回答了问题，甚至引起了负面评论!)。请放心，我要经历正式的程序。
。

必须提到的是，实体关系建模是业界巨头E F Codd和P Chen的工作。方法论基于他们的工作，由R Brown在1980年代完成。 IDEF1X于1993年成为NIST标准。当我回答数据建模问题时，我没有提供我写过的一本书的个人方法，而是站在巨人的肩膀上。

我坚持E F Codd和C J Date的关系模型

(？)C J Date和F Pascal完全标准化的原则

D McGoveran和C J Date撰写的《正交设计原理》。

建模数据

是的，此处的Supertype-Subtype结构正确。不幸的是，它并不常见，因此不为人们普遍理解。

另外，即使在实现子类型的地方，也只能以非常有限的方式实现它们。子类型具有更改父类型的角色的作用。确实，这种实现的正确性非常罕见，我在任何地方都没有看到过(当然，学术期刊和我自己的客户数据库实现除外)。

要点是，它看起来可能很“复杂”，但事实并非如此，它实际上非常简单。

这是Ken Downs和Chris Behrens将建模的简单性(高度可扩展)与未建模的实现(不正确且不可扩展)相混淆的原因，这是由于矮人(例如Martin Fowler)建议的简化方法。我知道人们依附并会捍卫他们所知道的一切，但无论有多有限，都不会构成犯罪。

注意，每个子类型本身也是一个完全有效的实体(当到达该阶段时，它是物理上的表)，并且可以独立存在。

用于较低级别或事务或功能表，这些表与这些子类型有关系，诀窍是使用正确的子类型(角色)。常见的错误是他们使用Party，然后使用子类型或角色的含义，并且丢失了正确的引用完整性。

单独地，所有RoleName都从Party派生，但这不是使用Party而不是正确的Role的有效理由。

在这里，您对数据非常了解，但是(没有人教过这一点，并且)您对角色和子类型感到困惑。

BandMember和Fan不是Parties。它们是Persons，第一个(而Person是Party，第二个)

为了使这些要点更加清楚，在此概念级别，我们需要使用实体和标识符(而非属性)，而不仅仅是实体。因此，我也提供了这一点。

看来您有ERwin(最好的!)；它使您可以非常方便地在该级别查看单个模型。即使在此抽象级别，也要在实体中实现标识符。

障碍

在介绍模型之前，请先指出这些问题，因为您似乎对学习IDEF1X(对关系数据库建模的标准方法)非常感兴趣，以期将来简化模型。因此，SO或任何网站都不是进行正式的交互式教育的理想工具，但我们会尽力而为。

在模型(1)中，Band不能独立(方角):因为它被标识为依赖Party；它是Party的子类型；并且具有相同的标识符

缺少的基数非常重要。放入它实际上将有助于解决模型。我对IDEF1X(圆圈)与IEEE(圆角)并不感到困惑，但是我总是随手放入它们，并随着模型的进行不断进行更改。

您的模型没有显示Band由一对多Members组成。等等。
。
尽管编程可以逐步进行(一旦定义稳定)，但是建模则不能。例如。您不能为实体建模，而不能为关系建模；关系而不是基数。这就是为什么它们是一门不同的科学，程序员没有成为好的建模者的原因，反之亦然。
。

在此阶段，规则也非常重要。实际上，建模就是对规则进行建模。因此，更正或修改规则是建模过程的一部分。

粉丝可以是任何乐队的粉丝，或者根本不合理。如果Person根本不存在，则它们是公众的成员，并且与Band没有任何关系。普通的Person。

Fan与至少一个Band有关系。实际上，与Band有关系就是将Person移出该领域并导致存储Fan详细信息或特定的频带扇形详细信息的原因。

如果存在诸如Fan with no Band这样的实体(即，您要存储其详细信息，根据我的模型与Fan分开存储)，请提出建议，我将更改模型(纸张很便宜!)。

动词短语在此阶段也很重要；不小于我上面关于规则和基数的观点，它是建模过程的一部分，并且随着模型的进行需要进行更改/调制。您不会相信正确使用动词短语的重要性。将它们放进去很可能有助于您弄清子类型与角色。这是每个Data Modeller都知道的定义。

实体是

模型中的名词

关系是动词，在名词

之间发生的动作

动词短语定义了这些动作(这就是为什么它们被准确地称为动词短语的原因，这不是一个好笑的名字)。

如 IDEF1X表示法文档中所述，对于关联表，将“动词短语”“直通”通过它们读到关联另一侧的父级。

Person是一对多的Bands，因此是Member

Band由一对多People组成，它们是Members

Person支持Band，这使它们成为Fan(不仅仅是在Person表中有一行的Fan)

Band取决于People，谁是Fans

提出最短，最有意义的动词短语；不使用简单的单词(避免使用“包含”)对建模人员来说是一个挑战。请随意改善我提供的动词短语。
▶Party Entity Relation◀

不熟悉关系数据库建模标准的读者可能会发现
▶IDEF1X Notation◀有用。

注意

我所做的就是解决子类型；角色；如上所述的关系基数。

当您评估第二笔付款或交易实体时，子类型与角色的相关性将更加清晰(如您所说，此处仅标识实体)。

标识符。值得说明，不仅是为了阐明模型，还因为它是使用的IDEF1X标识符及其部署功能的一个很好的例子。您已经在模型中表明您了解(实线)，我只是提供完整的说明。

Person和Band是Party的子类型。它们也是Party的角色。因此，我们从该点开始向下使用PersonId和BandId，而不是PartyId(即使它是PartyId)。

当Person扮演Member的角色时，我们使用MemberId(即PersonId，即PartyId)。

当Person扮演Fan的角色时，我们使用FanId(即PersonId，即PartyId)。

假设您要列出Fans的Band，而查询以Fan为中心。如果在每个表上都有这些Id代理键，则将被迫加入Person，然后加入Party。但是，有了关系标识符，您可以直接转到Party:

SELECT Name FROM Party WHERE PartyId = FanId

并跳过中间的表格。是的，事实是，规范化关系数据库需要更少的联接，更少的资源(处理，缓存，磁盘I / O)，这就是它们表现出如此出色的原因之一。神话没有科学依据。
请评估并提出具体问题。