为什么识别关系中的主键的外键部分？

Question

我正在尝试理解一个概念，而不是修复一段无效的代码。

我将采用表单（父表）和表单字段（子表）的一般示例。 逻辑，这将是一种识别关系，因为没有表单时，表单字段不能存在。

这会让我认为，为了将逻辑关系转换为技术关系，form_field表格中的form_id字段的简单NOT NULL就够了（参见上面屏幕截图的左侧部分。）

但是，当我使用MySQL Workbench添加标识关系时，form_id不仅是NOT NULL，还是主键的一部分。 （请参阅上面屏幕截图的右侧部分。）当我添加一个非标识关系时，NOT NULL仍然应用，所以逻辑上它实际上也是一个识别关系。

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

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

为什么，正如this answer所述，“正确”的方式使外键成为孩子主键的一部分？

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

Answer 1

  

逻辑上，这将是一种识别关系，因为没有表单就不能存在表单字段。

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

任何X：Y关系，其中X＆gt; = 1保证左侧存在，无论是否识别。在您的情况下，1：N关系保证form对于任何给定的form_field都存在。你可以使它识别或不识别，它仍然保证相同。

说明：

• 您可以通过使form_field.form_id成为密钥的一部分来建立识别关系。例如form_field PK可能看起来像：{form_id, label}，BTW对于正确的clustering数据非常有用（InnoDB表格为always clustered）。
• 只是制作一个PK：{id, form_id}是不正确的，因为这个超级键不是候选键（即它不是最小的 - 我们可以从中删除form_id并保持唯一性。） / LI>
• 您可以通过使form_field.form_id无效来建模0..1：N关系（但之后您也无法识别它 - 请参阅下文）。

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

• 严格定义：将父密钥迁移到子主键 ¹ 的关系。
• 松散定义：将父密钥迁移到子密钥的关系。

换句话说，松散的定义允许迁移到备用键（而不仅仅是主键）。

大多数工具 ² 似乎使用严格定义，因此如果您将关系标记为标识，那么将自动使迁移属性成为子PK的一部分，并且没有任何PK属性可以是NULL。

---

¹ 然后，它或者完全由迁移的属性组成，或者是迁移的属性和一些其他属性的组合。

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

Answer 2

识别关系应该是主键包括外键属性的关系。这就是为什么当你指定一个关系时，识别发布的外键被认为是主键的一部分。

“识别”关系与非识别关系之间的区别纯粹是信息性的或图解性的如果相同的关键约束和可空性约束适用于每种情况。该概念类似于指定“主要”键的结果。如果一个表有多个候选键，那么所有其他东西都是相同的，从逻辑角度看哪个键被指定为主键 - 形式，功能和（推测）表的商业含义是相同的。

但是，在您的示例中，两个表中的键不相同。在第一种情况下，ID在form_field表中是唯一的，而在第二种情况下，它显然不是。我希望这不是你想要的。