Database 数据建模：超类型/子类型

正在寻找建立以下需求模型的正确方法

有三种类型的“派对”需要关注，一个粉丝、一个乐队和一个乐队成员

该乐队成员将始终与乐队关联，也可以是任何乐队的粉丝

扇子、乐队和乐队成员之间有共同的属性，但这三者都有各自独特的属性

风扇可以是任何波段的风扇，也可以根本不是

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

我感谢你的任何意见

---

我认为这比你想象的要简单。您有两个对象-Band和Person，它们可以以两种不同的方式连接，可以作为风扇或成员。下面是一个没有外键或任何东西的quickie db脚本：

CREATE TABLE [dbo].[XREFBandMembers](
    [MemberID] [int] NOT NULL,
    [BandId] [int] NOT NULL,
 CONSTRAINT [PK_XREFBandMembers] PRIMARY KEY CLUSTERED 
(
    [MemberID] ASC,
    [BandId] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]
GO

CREATE TABLE [dbo].[XREFBandFans](
    [FanId] [int] NOT NULL,
    [BandId] [int] NOT NULL,
 CONSTRAINT [PK_XREFBandFans] PRIMARY KEY CLUSTERED 
(
    [FanId] ASC,
    [BandId] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

CREATE TABLE [dbo].[People](
    [Id] [int] IDENTITY(1,1) NOT NULL,
    [Name] [nvarchar](100) NOT NULL,
 CONSTRAINT [PK_People] PRIMARY KEY CLUSTERED 
(
    [Id] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

CREATE TABLE [dbo].[Bands](
    [Id] [int] IDENTITY(1,1) NOT NULL,
    [Name] [nvarchar](50) NOT NULL,
 CONSTRAINT [PK_Bands] PRIMARY KEY CLUSTERED 
(
    [Id] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]
GO

---

对于特定于关系的属性，您可以将它们放在外部参照表中，例如，FanClubMembershipNumber放在XREFBandFans中。

注意事项

首先，要了解这些限制，需要注意几个问题。所有正在使用或存储的数据需要一起考虑/建模。你已经在你的“在扩展模型时制造混乱”中发现了这一点。就我而言，由于不知道

各方

（子类型）与其他实体的关系，我无法提供完全正确的答案（这不会改变）

由于您提供的数据分为两部分，因此答案将分为两部分，第二部分将要求更改第一个模型。不是抱怨，只是事先通知你，因为如果我事先看到所有数据，这是可以避免的

你能理解（a）数据建模和（b）经历概念、逻辑和物理科学（记录超过30年）的需要，这真是太棒了。这正是我所做的。你无法想象正式流程所节省的时间和精力

• 然而，在我的回答中并没有出现这种情况，因为这是一个“问答”网站，我必须在提问者的层面上回答。（我比其他人更全面地回答问题，即使这样，也会引起负面评论！）。请放心，我已经完成了正式的程序。
  .

必须提到的是，实体关系建模是行业巨头E F Codd和p Chen的工作。该方法基于他们的工作，由R布朗在20世纪80年代完成。IDEF1X于1993年成为NIST标准。当我回答数据建模问题时，我不是在提供我写过一本书的一些个人方法，我站在巨人的肩膀上

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

• （？）cj-Date&F-Pascal完全归一化原理

• D McGoveran和C J Date的正交设计原理

建模数据

是的，这里的超类型子类型结构是正确的。不幸的是，它并不常见，因此也不被普遍理解

另外，即使在实现子类型的情况下，它们也是以非常有限的方式实现的。子类型具有改变超类型的角色的效果。这方面的正确实现确实非常罕见，我在任何地方都没有见过（当然除了学术期刊和我自己为客户提供的数据库实现）

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

这就是Ken Downs和Chris Behrens将建模的简单性（高度可扩展）与未建模的实现（不正确且不可扩展）混淆的地方，这是因为Martin Fowler等矮人建议的简单化方法。无意冒犯，我理解人们对他们所知道的东西是依附的，并且会为之辩护，尽管这可能是有限的

• 请注意，每个子类型本身也是一个完全有效的实体（当我们到达该阶段时，物理中的表），并且可以独立存在

• 对于与这些子类型相关的较低级别或事务或函数表，诀窍是使用正确的子类型（角色）。常见的错误是他们使用了

  参与方

  ，然后子类型或角色的含义就丢失了，正确的引用完整性也就丢失了

• 另外，所有角色名称均源自

  参与方

  ，但这不是使用

  参与方

  而不是正确角色的有效理由

• 在这里，您非常了解数据，但是（没有人教您这一点）您混淆了角色和子类型

• 乐队成员

  和

  粉丝

  不是

  双方

  。他们首先是

  人

  （

  人

  是

  一方

  ，其次）

为了使这些要点更加清晰，在这个概念层面上，我们需要使用实体和标识符（不是属性），而不仅仅是实体。因此，我也提供了这一点

• 看来你有欧文（最好的！）；它允许您非常方便地在该级别查看单个模型。即使在这个抽象级别，也要在实体中实现标识符

障碍物

我在介绍模型之前指出了这些，因为您似乎对学习IDEF1X非常感兴趣，IDEF1X是关系数据库建模的标准方法，目的是在将来简化您的模型。所以，无论是什么网站，都不是正规互动教育的好媒介，但我们会尽全力

在模型（1）中，

波段

不能是独立的（方角）：因为它

SELECT Name FROM Party WHERE PartyId = FanId