sql - 为什么主键的外键部分是标识关系？

Question

我试图理解一个概念，而不是修复一段不起作用的代码。

我将举一个 的一般示例表格 (父表)和一个 表单域 (子表)。 逻辑上 ，这将是一种识别关系，因为没有表单就不能存在表单字段。



这会让我觉得为了翻译逻辑 关系成技术关系，一个简单的NOT NULL对于 form_field 表中的 form_id 字段就足够了。 (请参阅上面屏幕截图的左侧部分。)

但是，当我使用 MySQL Workbench 添加识别关系时，form_id 不仅是 NOT NULL也是主键的一部分。 (见上面截图的右侧部分。)当我添加一个非识别关系时，NOT NULL仍然如此合乎逻辑地应用它实际上也是一种识别关系。

我想这让我有点困惑，以及直到现在我总是简单地使用 id 字段作为主键的事实。

所以我明白了逻辑 识别与非识别关系的概念，但我不明白 技术部分。

为什么呢，如 this answer状态，“使外键成为 child 主键部分的“正确”方法？

这些复合主键有什么好处？

Answer 1

Logically, this would be an identifying relationship, since a form field cannot exist without a form.

不，识别关系是识别，而不是存在。

X >= 1 的任何 X:Y 关系都保证左侧的存在，无论是否识别。在您的情况下，1:N 关系保证存在 form对于任何给定的 form_field .您可以使其具有识别性或非识别性，它仍然可以保证相同。

评论:

您可以通过制作 form_field.form_id 来建模识别关系。 key 的一部分。例如 form_field PK 可能看起来像:{form_id, label} ，顺便说一句，这对适当的 clustering 非常有益您的数据(InnoDB 表是 always clustered )。

刚刚PK:{id, form_id}将是不正确的，因为这个超键不是候选键(即它不是最小的 - 我们可以从中删除 form_id 并仍然保留唯一性)。

您可以通过制作 form_field.form_id 来模拟 0..1:N 关系。可以为 NULL(但随后您将无法对其进行识别 - 见下文)。

“识别关系”有两种定义:

严格定义 :将父键迁移到子主键1 的关系。

松散定义 :将父键迁移到子键的关系。

换句话说，松散定义也允许迁移到备用键(而不仅仅是主键)。

不过，大多数工具 2 似乎都使用了严格的定义，因此如果您将关系标记为标识，这将自动使迁移的属性成为子 PK 的一部分，并且所有 PK 属性都不能为 NULL。

1 那么它要么完全由迁移的属性组成，要么是迁移的属性和一些附加属性的组合。

2 ERwin 和 Visio 可以。我还没有使用 MySQL Workbench 进行建模，但您的描述似乎表明它的行为相同。