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

Question

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

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

Answer 1

子表(AKA 弱实体)是一个表,其主键属性依赖于另一个表,因此子表由其依赖(父)的表中的行标识或部分标识.如果父表中没有相应的行,则子表中的行不能存在.

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

在上面的模型中,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表,它在没有参与的独特身份的孩子,因此家长有非识别他们的孩子的关系,现在这两个表可以被认为是"强"的独立实体.

另外,这个版本的模型比第一个版本有一些优势:

• 一个父亲现在可能有两个或多个具有相同名称的子女,而之前模型中的实体完整性约束不允许这样做.
• 您可以允许该Parent_SSN字段包含NULL以说明您拥有有关该子项的数据的事件,但不知道他/她的父母是谁.

在上述两种模型中,该Parents表都被视为表的父Children表.然而,在非识别像第二个模型的关系,Parents仅仅是外键的背景下,父表Parent_SSN,因为Parent_SSN 引用/依赖于SSN在Parents表中,但并没有在定义儿童的实际身份的任何部分.

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

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

在这里,我们有两个不识别的关系:一个员工在一个部门工作(DeptNo在Employee表中),一个部门由一个员工管理(ManagerSSN在Department表中).哪一个是父表？......儿童桌？

这取决于背景 - 你在谈论哪个外键关系？部门表将被视为在上下文中的父表DeptNo的Employee表,因为DeptNo被引用/依赖于Department表.

然而,Employee表将被视为在上下文中的父表ManagerSSN的Department表,因为ManagerSSN被引用/依赖于Employee表.

Answer 2

没有严格的规则来确定表在关系中的角色。事实上，这就是关系模型的美妙之处和创新之处：没有层次结构。

通常，如果某个表与另一个表之间存在硬依赖关系，则子角色或父角色由表的语义确定。示例：在order,order_details关系中，很明显 是order父级，order_details是子级。

在其他情况下，并不清楚关系在关系中扮演什么角色。示例：orders和customers关系。如果您执行查询来获取orders属于某个特定对象的所有内容customer，那么父对象可能是customers且orders都是子对象。但您也可以执行查询来获取customers特定 的所有发货信息（以关系形式存储）order，在这种情况下，您可能会认为在该查询中order是父项，而customers是子项。

正如我之前所说，当关系模型在 70 年代末发明时，它相对于主导范式之一（分层数据模型）的主要好处之一是能够查找相关数据，而不管它们的依赖性如何。