拥有主键所需的外键有什么区别？答案

【问题标题】：What's the difference between having a required foreign key to a primary key?拥有主键所需的外键有什么区别？
【发布时间】：2019-09-21 00:54:12
【问题描述】：

我正在为赛车游戏开发数据库。在此图中，必须在赛道上进行比赛（因此必须在表格 Race 上引用 TrackID），并且我可能有一个赛道，其中发生了很多甚至没有比赛：

所以从 Race 到 Track 的最小基数应该是 1，将关系设置为 Identifying。但这也会使 Table Race 上的 TrackID 成为 PK。而且我不明白为什么我需要它。所以我想我宁愿把它作为一个“必需的”FK；除了不作为 PK 之外还有什么变化？将 TrackID 作为 Race 上的 FK，Microsoft Visio 会自动将该最小基数设置为 0，这让我摸不着头脑...

我是建模数据库的新手，这个问题可能很明显，但请帮助我理解这一点。

【问题讨论】：

我刚碰到这个：stackoverflow.com/questions/6095527/is-this-a-flaw?rq=1 所以...这是 visio 的缺陷吗？
请告诉我们您正在使用什么信息建模参考。为什么你认为你关心“差异”？ subrow value 当它出现在 PK 或 FK 列列表中时是 PK 或 FK。 PK & FK 列列表声明说明了可能出现的表值。我们声明它们以便 DBMS 强制执行它们。我们不需要他们查询。（某些声明集合强制执行其他声明，因此我们不需要声明。）您是什么意思“我不明白我为什么需要它”？ TrackId不是Race的PK。你对“识别”有误解。请参阅“识别”、PK 和 FK 的定义。
我只关心真的没有赛道就没有比赛；我说我不明白为什么我需要 TrackID 作为 PK，因为我不想在每次搜索比赛时都指定赛道。 TrackID 不是图片上 Race 的 PK，因为我是这样设置的，我将它设置为 req'd 列，即使它是必需的，从 Race 到 Track 的最小基数仍然为零，至少在概念上没有不能保证每场比赛都在赛道上进行（这就是我试图展示的）。这是为什么？这主要是让我感到困惑的地方。
这里有两个独立的问题：您想要什么设计以及如何将其融入您的工具。我正在解决您写基本术语的奇怪方式，并且可能误解/误解了它们。重新摔跤 Visio：有不同的方法来标记基数。我读过它本身就是IDEF1X（参见维基百科'E-R 模型'重新约束。） 数据库 是你想要的方式，即使图表不是？ Visio 可能不容易支持您使用的约定。这就是我要求你告诉我你的推理是什么的原因之一。阅读文档。 ...
为了澄清在 ER 模型中识别关系与强制角色，请参阅我对Is optionality (mandatory, optional) and participation (total, partial) are same?的回答

标签： database database-design foreign-keys visio erd

【解决方案1】：

有两种方法可以识别种族。您可以为每场比赛分配一个唯一的 RaceId，在这种情况下，RaceID 标识了比赛。这是几乎所有设计师都会采用的常见方式。这是我会走的路，没有任何理由不这样做。

还可以分配一个仅在单个赛道中唯一的 RaceID。也就是说，可能有两场 ID 为 123 的比赛，但一场在赛道 1 上，另一场在赛道 2 上。我想不出任何理由这样做，但可以这样做。在其他用例中，这种上下文依赖是有意义的，但不是这个用例。

在第一种情况下，即您所描绘的，TrackID 将是一个 FK，但不是 PK 的一个组件。它可以被限制为不为空，但这不会使其成为 PK 的一部分。

在第二种情况下，Race 表中的 TrackId 将像以前一样是 FK。但是 PK 现在将包括 RaceId 和 TrackId。这可能就是您所说的识别关系的意思。

我不会顺便说一下 Lap 表似乎以我描述的第二种情况的方式使用 LapId。很多比赛都有第 5 圈，但你必须知道 Lap Id 和 Race Id 才能知道你说的是哪一圈。

【讨论】：

【解决方案2】：

这是一个相当复杂的话题，并且已经在 SO before 上讨论过。

让我们抛开 Visio 所做的一切 - 许多 ERD 工具太聪明或有缺陷。

识别关系是指子项（种族）在没有父项（轨道）的情况下根本无法存在，并且子项的主键包括父项的主键。一个常见的例子是带有订单行（子）的订单（父）——订单行的主键可能是订单的主键和序列号的组合。当您删除订单时，您会删除所有订单行。孩子的外键是不可变的，并且是强制性的。

非标识关系是指子项可以在没有父项的情况下存在，或者父项密钥可能会更改的关系。

非识别关系可以是强制性的，也可以是可选的。说强制外键需要识别关系是错误的。

我相信在你的情况下，你有一个非识别关系 - 可以安排比赛，但随后改变赛道。我不相信“track_id”应该是不可变的；甚至可能是在赛道达成一致之前安排了比赛，因此这种关系可能是可选的。

【讨论】：

【解决方案3】：

赛道与比赛之间的关系是{1}：{0,n}，即每场比赛都在一个赛道上进行，每条赛道都有零到多场比赛。

轨道 ID 唯一标识轨道，因此构成此表的主键。
出于同样的原因，比赛的主键是比赛 ID。
另外在比赛表中有一个赛道ID，从而建立{0,1}:{0,n}关系。将此轨道 ID 设为不可为空，您将获得 {1}:{0,n}，这正是您想要的。

这不会使赛道 ID 成为比赛的主键或唯一键。离得很远。它在表中不是唯一的（因为可以在同一赛道上进行许多比赛）。

不过，我不知道 Microsoft Visio 如何实现可空性/不可空性来区分 {1}:{0,n} 和 {0,1}:{0,n} 关系。

【讨论】：