Sql 为什么外键在标识关系中是主键的一部分？

我试图理解一个概念，而不是修复一段行不通的代码

我将以表单（父表）和表单字段（子表）为例逻辑上，这将是一种标识关系，因为没有表单，表单字段就不可能存在

这会使我认为，为了将逻辑关系转换为技术关系，表单字段表中表单id字段的简单

notnull

就足够了。（请参见上面屏幕截图的左侧部分。）

然而，当我使用MySQL Workbench添加一个标识关系时，form_id不仅是

非NULL

，而且是主键的一部分。（请参见上面屏幕截图的右部分。）当我添加一个非标识关系时，

notnull

仍然被应用，因此在逻辑上它实际上也是一个标识关系

我想这让我有点困惑，而且直到现在我一直只是简单地使用id字段作为主键

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

为什么它会像前面所说的那样，成为孩子主键中外键的“正确”方式

---

这些复合主键的好处是什么？

识别关系应该是主键包含外键属性的关系。这就是为什么当您将关系指定为标识已发布的外键时，会将其视为主键的一部分

如果在每种情况下应用相同的键约束和可空性约束，则“标识”关系和非标识关系之间的区别纯粹是信息性的或图解性的。该概念类似于指定“主键”的结果。如果一个表有多个候选键，那么所有其他条件都相同，从逻辑角度看，哪个键被指定为主键并不重要——表的形式、功能和（大概）业务含义是相同的

但是，在您的示例中，两个表中的键不相同。在第一种情况下，ID在form_字段表中是唯一的，而在第二种情况下，ID显然不是唯一的。我想那不是你想要的

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

不，认同关系是关于认同，而不是存在

任何X:Y关系，其中X>=1保证左侧的存在，无论是否识别。在您的例子中，1:N关系保证任何给定的

form_字段

都存在

form

。你可以把它定为可识别的或不可识别的，但它仍然保证相同

备注:

• 您可以通过将

  form\u字段.form\u id

  作为键的一部分来建模标识关系。例如，

  form\u field

  PK可能看起来像：

  {form\u id，label}

  ，顺便说一句，这对正确使用数据非常有益（InnoDB表是可用的）
• 仅仅做一个PK:

  {id，form_id}

  是不正确的，因为这个超级键不是候选键（也就是说，它不是最小值-我们可以从中删除

  form_id

  ，并且仍然保留唯一性）
• 您可以通过将

  form\u字段.form\u id

  NULL设置为可识别的，来建立一个0..1:N关系的模型（但这样您就无法将其也设置为可识别的，请参见下文）

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

• 严格定义：将父键迁移到子主键1的关系
• 松散定义：将父键迁移到子键的关系

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

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

---

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

---

2欧文和Visio公司。我还没有使用MySQL Workbench进行建模，但您的描述似乎表明它的行为是相同的。

除非字段ID按表单编号，否则我认为在PK中包含它们没有任何意义。因此，如果我理解正确的话：-这个想法是主键由两列或更多列组成。-其中一个是父表的外键-另一个是在共享父表外键的所有记录中唯一的列，但（可能）不是在表的所有记录中唯一的列-所有这些都只是自动递增ID列的一种替代方法。@NicNLD我想您得到了它，除非存在自然键，严格来说，它不是代理键的“替代品”——如果每个表单的标签都需要是唯一的，那么在任何情况下都必须创建一个键

{form_id，label}

。唯一的问题是你是否也会制作一个代理键

id

。@NicNLD“我必须制作一个键{form_id，label}，以确保一个表单中没有两个重复的标签，对吗？”正确。链接答案中的一句话：“识别关系是指子表中的行取决于父表中的行。”不正确。同样的保证也可以通过非标识关系实现（正如我已经提到的）。@NicNLD让我引述一下：“在关系术语中，依赖外键属性唯一性的子实体称为依赖关系