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

Question

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

我将采用表单(父表)和表单字段(子表)的一般示例.从逻辑上讲,这将是一种识别关系,因为没有表单就不能存在表单字段.

这将使我认为,为了将逻辑关系转换为技术关系,NOT NULLform_field表中的form_id字段的简单就足够了.(参见上面屏幕截图的左侧部分.)

但是,当我使用MySQL Workbench添加标识关系时,form_id不仅NOT NULL是主键的一部分,而且也是主键的一部分.(请参阅上面屏幕截图的右侧部分.)当我添加一个非识别关系时,NOT NULL仍然按逻辑方式应用它实际上也是一个识别关系.

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

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

为什么它,正如这个答案所说的那样,"正确"的方式使外键成为孩子主键的一部分？

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

Answer 1

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

不,识别关系是关于识别,而不是存在.

X> = 1的任何X:Y关系都保证左侧存在,无论是否识别.在您的情况下,1:N关系保证form任何给定的存在form_field.你可以使它识别或不识别,它仍然保证相同.

备注:

• 您可以通过制作form_field.form_id密钥的一部分来建立识别关系.例如,form_fieldPK可能看起来像:{form_id, label}BTW对于正确聚类数据非常有用(InnoDB表总是聚集在一起).
• 只是制作一个PK:{id, form_id}是不正确的,因为这个超级密钥不是候选密钥(即它不是最小的 - 我们可以form_id从中删除并仍保留唯一性).
• 你可以通过使form_field.form_idNULL能够建模0..1:N关系(但是你也不能让它识别出来 - 见下文).

"识别关系"有两种定义:

• 严格定义:将父键迁移到子主键^1的关系.
• 松散定义:将父密钥迁移到子密钥的关系.

换句话说,松散定义允许迁移到备用密钥(而不仅仅是主要密钥).

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

¹然后,它既可以完全由迁移的属性组成,也可以是迁移的属性和一些其他属性的组合.

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