mysql - 标识关系或非标识关系中的哪个子表？

Question

在识别表和非识别表之间的关系的上下文中，MySQL的文档在很大程度上将表称为父表和子表。

如何确定哪个表是父表，哪个表是子表？

Answer 1

子表(A.K.A. weak entity)是一个表，其主键属性依赖依赖于另一个表，因此子表由其依赖的表(父表)中的行标识或部分标识。子表中的行如果没有其父表中的相应行，则不能存在。

为了说明这一点，让我们举一个我们都熟悉的简单且完全相关的示例:家庭中的 parent 和 child 。我们可以使用如下表来建立这种关系的模型:

在上面的模型中，Parents表中的每一行都是，由SSN唯一标识。 SSN是每个父级的固有且唯一的属性，因此它是独立的或“强”的实体，因为它不依赖于另一个表来定义其标识。

但是，子级需要父级才能存在(Parent_SSN 必须对SSN表中现有Parents的引用)。

注意Parent_SSN, Name表中的复合主键(Children)。这意味着子项通过Parent_SSN 和 Name的唯一标识。您不能仅根据Name字段来查询单个 child ，因为多个 parent 可能有同名 child 。同样，您不能仅根据Parent_SSN字段查询单个 child ，因为一个 parent 可能有很多 child 。考虑到这一点， child 由 parent 部分识别，因此标识了关系。

但是，SSN也不能唯一标识 child 吗？当然可以，为什么。让我们继续进行调整，以包括以下模型:

在此版本的模型中，请注意，我们为SSN引入了Children字段。现在， child 的唯一身份由他们自己的固有和唯一SSN定义。它们的身份不再取决于Parents表上的。尽管Parent_SSN字段仍引用SSN表的Parents，但它没有 child 的唯一身份，因此 parent 与 child 之间具有非标识关系，两个表现在都可以视为“强”独立的实体。

顺便说一句，此版本的模型比第一个模型具有一些优点:

现在，一个父级可能有两个或多个同名子级，而先前模型中的entity integrity约束则不允许这样做。

您可以允许Parent_SSN字段包含NULL，以解决您拥有有关 child 的数据但不知道其 parent 是谁的事件的情况。

在上述两个模型中， Parents表都被视为 Children表的父表。但是，在类似于第二个模型的 非识别关系中， Parents只是外键 Parent_SSN上下文中的父表，因为 Parent_SSN引用/取决于 SSN表中的 Parents，但在定义 child 的实际身份。

为了说明为什么在确定哪些表是父/子表时上下文很重要，请考虑以下涉及循环依赖的示例:

在此示例中，员工和部门由他们自己的属性唯一标识，并且不会从其他表中派生其身份的任何部分。

在这里，我们有两个非身份识别的关系:一个员工在一个部门工作(在 DeptNo表中为 Employee)，而一个部门由员工管理(在 ManagerSSN表中为 Department)。父表是哪一个？ ... child table ？

这取决于上下文-您在谈论哪个外键关系？在 DeptNo表的 Employee上下文中，Department表将被视为父表，因为 DeptNo是引用/依赖于 Department表。

但是，在 ManagerSSN表的 Department上下文中，Employee表将被视为父表，因为 ManagerSSN是引用/依赖于 Employee表。