识别或非识别关系中的子表是哪一个？

Question

在识别和不识别表之间的关系的上下文中，MySQL的文档将表作为父表和子表引用了很多。

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

Answer 1

子表（AKA weak entity）是一个表，其主键属性 依赖 在另一个表上，因此子表标识< / em>或部分标识表中的行依赖于（父）。如果父表中没有相应的行，则子表中的行不能存在。

为了说明，让我们采用一个我们都熟悉的简单而完全相关的例子：家庭背景下的父母和孩子。我们可以用这样的表来模拟这种关系：

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

儿童要求父母才能存在（Parent_SSN 必须 引用现有SSN在Parents表中。

注意Parent_SSN, Name表中的复合主键（Children）。这意味着，Parent_SSN 和 Name的组合 唯一标识 。您不能仅基于Name字段查询单个子项，因为多个父项可能具有相同名称的子项。同样，您不能仅基于Parent_SSN字段查询单个孩子，因为父母一方可能有很多孩子。考虑到这一点，儿童被父母部分识别，因此 识别 关系。

但SSN也不能对孩子进行独特的鉴定吗？为什么是肯定的。让我们继续并调整我们的模型，包括：

在此版本的模型中，请注意我们已为SSN引入了Children字段。儿童的唯一身份现在由他们自己的内在和唯一SSN定义。他们的身份不再取决于Parents表格上的。虽然Parent_SSN字段仍然引用SSN表的Parents，但它没有参与孩子的唯一身份，因此父母有 与其子女的非身份识别 关系，现在这两个表都可以被视为“强大的”独立实体。

顺便说一句，这个版本的模型比第一个版本有一些优势：

• 一方父母现在可能有两个或多个具有相同名称的子女，而之前模型中的entity integrity约束则不允许这样做。
• 您可以允许Parent_SSN字段包含NULL来说明您拥有有关该孩子的数据的事件，但不知道他/她的父母是谁。

在上述两个模型中，Parents表被视为Children表的父表。但是，在第二个模型中的非标识关系中，Parents只是外键Parent_SSN上下文中的父表，因为Parent_SSN {/ 1}}表中的SSN上的引用/依赖，但不在定义子项的实际身份方面有任何作用。

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

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

在这里，我们有两个不识别的关系：一个员工在一个部门工作（Parents表中的DeptNo），一个部门由员工管理（Employee in ManagerSSN表格。哪一个是父表？ ......儿童桌？

这取决于背景 - 你在说什么外键关系？部门表将被视为Department表中DeptNo上下文中的父表，因为Employee 引用/依赖 DeptNo表。

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

Answer 2

没有严格的规则可以确定关系中表的作用。事实上，这就是关系模型的美感和创新：没有层次结构。

通常，如果从某个表到另一个表存在硬依赖关系，则子角色或父角色由表的语义决定。示例：在order，order_details关系中，很明显order是父，order_details是孩子。

在其他情况下，不清楚关系在关系中扮演什么角色。示例：orders和customers关系。如果您执行查询以使所有orders属于某个customer，则父级可能是customers，orders是子级。但是，您也可以执行查询以获取特定customers的所有货件信息（存储在order关系中），在这种情况下，您可能会认为order是父项customers。 {1}}是此查询中的子项。

正如我之前所说，当关系模型是在70年代后期发明的时候，其主要优势之一就是能够查找相关数据，而不管它们的依赖性。

Answer 3

提出了一个很好的定义here：

  

识别关系是指孩子中存在行的时间   table依赖于父表中的行。 （...）正式地说，“正确”   这样做的方法是使外键 [即。父母的主键] 的一部分   孩子的主要钥匙。