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

我将介绍一个表单(父表)和表单域(子表)的一般示例.逻辑上,这将是一个识别关系,因为一个表单域不能存在没有一个表单.

这将使我认为为了将逻辑关系转换为技术关系,form_field表中的form_id字段的简单NOT NULL就足够了. (见上图左边的截图)

然而,当我使用MySQL Workbench添加一个识别关系时,form_id不仅不是NULL,也是主键的一部分. (见上面右侧部分截图)
当我添加一个非识别关系时,NOT NULL仍然在逻辑上应用,它实际上也是一个识别关系.

我想这有点让我困惑,以及到现在为止,我总是只用id字段作为主键.

所以我理解识别与非识别关系的逻辑概念,但我不明白技术部分.为什么呢,就像this answer所说的,“把小孩主要关键部分的”正确的“方式呢？这些复合主键的好处是什么？

解决方法

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

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

任何X：Y关系,其中X> = 1保证了左侧的存在,无论是否识别.在你的情况下,1：N关系保证任何给定form_field的形式存在.您可以使其识别或不识别,并且仍然可以保证相同.

备注：

>您将通过将form_field.form_id作为键的一部分来建模识别关系.例如,form_field PK可能看起来像：{form_id,label},其中BTW对于您的数据的适当clustering(InnoDB表为always clustered)将是非常有益的.
>只要做一个PK：{id,form_id}就不正确了,因为这个超级键不是一个候选键(也就是说它不是最小的 – 我们可以从中删除form_id并且仍然保留唯一性).
>您将通过使form_field.form_id为空(可以使您无法将其识别为 – 见下文)来建模0..1：N关系.

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

>严格定义：将父密钥迁移到子主键1中的关系.
>宽松的定义：将父键迁移到子键的关系.

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

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

1然后完全由迁移的属性组成,或者是迁移的属性和一些其他属性的组合.

2 ERwin和Visio做.我还没有使用MySQL Workbench进行建模,但是你的描述似乎表明它的行为是一样的.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!