数据建模:超类型/子类型

Question

想要找出模拟以下要求的正确方法.

1. 有三种类型的"派对",一个是Fan,一个乐队和一个BandMember.
2. BandMember将始终与乐队相关联,也可以是任何乐队的粉丝.
3. Fan,Band和BandMember之间有共同的属性,但这3个中的每一个也都有自己独特的属性.
4. Fan可以是任何Band的粉丝,也可以不是

这只是更大思想的一小部分,但它在扩展模型时产生了混乱.我相信它必须是图2或其他一些选项,因为我没有看到BandMember如何与第一个模型中的Band相关联.

我很感激任何意见.

Answer 1

警告

1. 首先要了解一些限制因素.所有正在使用或存储的数据都需要一起考虑/建模.例如.无论如何,你已经发现了"在扩展模型中造成混乱".从我这边,不知道Parties(子类型)如何与其他实体相关,限制我提供一个完全正确的答案(不会改变).

   由于您提供两档数据,因此答案将分为两档,第二档将需要更改第一档.不是抱怨,只是事先通知你,因为如果我事先看到所有数据就可以避免这种情况.

2. 非常了解您需要(a)对数据进行建模,以及(b)经历概念,逻辑和物理的科学(记录超过30年).这正是我所做的.你无法想象正式过程所节省的时间和精力.

   • 但是,我在SO的答案中没有提到这一点,因为它是一个"问答"网站,我必须在提问者的层面回答.(我比其他人更充分地回答问题,即便如此,也会引起负面评论!).请放心,我会通过正式的序列.
     .

3. 必须提到的是,实体关系建模是业内巨头的作品,EF Codd和P Chen.方法论是基于他们的工作,并由R Brown在20世纪80年代完成.IDEF1X于1993年成为NIST标准.当我回答数据建模问题时,我并没有提供一些我写过书的个人方法,我站在巨人的肩膀上.

   • 我坚持EF Codd和CJ Date的关系模型

   • (？)CJ Date&F Pascal的完全归一化原理

   • D McGoveran与CJ Date的正交设计原理.

建模数据

1. 是的,Supertype-Subtype结构在这里是正确的.不幸的是,它并不常见,因此不常理解.

2. 另外,即使在实施Subtypes的情况下,它们也以非常有限的方式实现.子类型具有更改超类型角色的效果.正确的实现是非常罕见的,我没有在任何地方看到这一点(当然除了学术期刊和我自己的客户数据库实现).

3. 重点是,这可能看起来"复杂",但事实并非如此,实际上非常简单.

   这是Ken Downs和Chris Behrens将模型化的简单性(高度可扩展性)与未建模的实现(不正确和不可扩展)混淆的地方,因为像Martin Fowler这样的矮人建议的简单方法.没有冒犯,我知道人们依附于并将会捍卫他们所知道的东西,无论这种情况有多么有限.

   • 请注意,每个Subtype本身也是一个完全有效的实体(物理中的表,当我们到达那个阶段时),并且可以独立存在.

   • 对于与这些子类型具有关系的较低级别或事务或函数表,诀窍是使用正确的子类型(角色).常见的错误是他们使用Party,然后失去了Subtype或Role的含义以及正确的参照完整性.

   • 单独的所有RoleNames都是从中派生出来的Party,但这不是使用Party而不是正确Role 的正当理由.

   • 在这里你可以很好地理解数据,但是(没有人教过你这个)你已经混淆了角色和子类型.

   • BandMember而Fan不是Parties.他们是Persons第一个(并且Person是Party第二个)

4. 为了清楚地说明这些要点,在这个概念层面,我们需要使用实体和标识符(而不是属性),而不仅仅是实体.因此我也提供了这一点.

   • 看来你有ERwin(最棒!); 它允许您非常方便地查看该级别的单个模型.即使在这个抽象层面,也要在实体中实现标识符.

障碍

我在介绍模型之前指出了这些,因为您似乎对学习关系数据库建模的标准方法IDEF1X非常感兴趣,以期在将来简化模型.SO或任何网站,不是正式互动教育的良好媒介,但我们会尽力而为.

1. 在模型(1)中,Band不能是独立的(方角):因为它被识别为依赖于Party; 它是一个子类型Party; 它具有相同的标识符.

2. 缺少基数是至关重要的.将它放入其中将实际上有助于解决模型.我不是因为IDEF1X(圆圈)和IEEE(乌鸦脚)而讨厌,但我总是把它们放进去,并随着模型的进展不断改变它们.

   • 您的模型并未显示a Band由一对多组成 Members.等等.
     .
     虽然编程可以逐步进行(一旦定义稳定),但建模不会.例如.你不能模仿实体而不是关系; 关系但不是基数.这就是为什么他们是不同的科学,程序员不会成为好的模型,反之亦然.
     .

3. 在这个阶段,规则也非常重要.事实上,建模是对规则进行建模.因此,修改或调整规则是建模过程的一部分.

   • 风扇可以是任何乐队的粉丝,或者根本不是合理的.如果a Person根本不是,那么他们就是一般公众的成员,他们与任何人没有任何关系Band.一个平凡的Person.

   • A Fan与至少一个有关系Band.实际上,与a建立关系Band就是Person从这个领域中获取并导致存储Fan细节或特定的扇形扇区细节.

   • 如果有这样的实体Fan with no Band(即你存储的细节,Fan根据我的模型分开),请告知,我将更改模型(纸张便宜!).

4. 动词短语在这个阶段也很重要; 不仅仅是我的观点和上面的规则和基数,它是建模过程的一部分,并且随着模型的进展需要改变/调制.你不会相信让动词短语成为正确的重要性.把它们放进去可能会帮助你澄清Subtypes vs Roles.这是每个数据建模者都明白的定义.

   • 实体是模型中的名词

   • 关系是动词,名词之间发生的动作

   • 动词短语定义了这些动作(这就是为什么它们被准确地称为动词短语,它不是一个有趣的名字).

   如IDEF1X表示法文档中所述,对于关联表,将"通过"它们的动词短语读取到关联另一侧的父级.

   • A Person生成一对多Bands,因此是一个Member

   • A Band由一对多组成People,谁是Members

   • 一个Person光顾a Band,使他们成为一个Fan(不仅仅是一个Person人在Fan桌子上有一排)

   • A Band取决于People谁Fans

   提出最短,最有意义的动词短语; 不使用简单化的词语("包括"应该避免"),对于建模者来说是一个挑战.随意改进我提供的动词短语.

▶党派实体关系◀

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

注意

我所做的只是解决子类型; 角色; 如上所述,关系的基数.

1. 当您评估第二次付款或交易实体时,子类型与角色的相关性将更加明确(如您所述,此处我们只有识别实体).

2. 标识符.这值得说明,不仅是为了澄清模型,还因为它是使用IDEF1X标识符的一个很好的例子,以及它们部署的功能.你已经在你的模型中表明你明白了(实线),我只是给它完整的治疗.

   • Person并且Band是.的子类型Party.他们也是角色Party.因此我们使用PersonId并BandId从那一点向下,而不是PartyId(即使它是PartyId).

   • 当a Person扮演角色时Member,我们使用MemberId(即PersonId,是PartyId).

   • 当a Person扮演角色时Fan,我们使用FanId(即PersonId,是PartyId).

   假设您列出了Fansa Band,您的查询集中在Fan.如果您Id在每张桌子上都有这些代理键,您将被迫加入Person,然后加入Party.但是使用关系标识符,您可以直接进入Party:

   SELECT Name FROM Party WHERE PartyId = FanId
   

   并跳过中间的表格.是的,事实是,规范化关系数据库需要更少的连接,更少的资源(处理,缓存,磁盘I/O),这就是它们执行得更好的一个原因.神话没有科学依据.

请评估并询问具体问题.