确定与非确定关系（再次！）

Question

所以，我读了一大堆这里计算器的答案，但我仍然感到困惑其整个概念。具体来说，我已经阅读了这篇文章（包括它引用的所有文章），但似乎无法找到对这个概念的牢固把握（或者可能是我对基数（n：m等）和身份之间的混淆）：

Still Confused About Identifying vs. Non-Identifying Relationships

我的问题是这样的：我知道，确定关系意味着子实体的主键必须包括它的外键，而事实恰恰相反非识别关系（难道这正确？）。现在，这对我来说似乎有点“前瞻性思维”？其中一条链接的评论中也有同样的说法。我怎样才能“退后一步”，并真正看到哪个关系是哪个身份的？

例如，我有两个难题：

1. job_title（母体，1）employee（儿童，1 .. *）。我是否认为，因为job_title是查找表，它必须是一个非识别关系？还是说，“一个员工不能没有工作标题就不能存在，因此它必须确定”？或者是定义该场景的关系？
2. employee到employee_equipment（桥接米之间实体：基数n）与equipment。现在，我了解到这必须是employee_equipment双方的一个确定关系。但是，如果员工不需要设备？能有一个可选的识别关系吗？

我想，我真的在寻找一种方式来识别身份的表应该属于无主/外键的思维，或任何真正技术对这一问题。

任何帮助将不胜感激！

Answer 1

你在思考选择性和身份之间的联系。直到整个事情对你来说更自然，最好认为它们是完全不相关的。

关于可选性，重要的是要记住可选性是定向的。要使用您的示例employee_equipment：当然，员工不需要设备。从employee到employee_equipment的一对多关系是可选的。同时，从相反的角度来看，这种关系是强制性的。除非有employee将它与之关联，否则您不能在employee_equipment中有记录。

身份与可选性无关，除了巧合识别关系从孩子到父母是强制性的。对于身份而言，是否也是父母对孩子强制要求的，既不存在也不存在。

是什么让一个关系鉴别是，你必须知道你是为了知道你在说什么孩子交谈什么父母约（以及一些其他的东西）。也就是说，孩子的主键必须包含父母的外键。

纯交点表（例如employee_equipment）是就是很好的例子。纯交集的主键是外键与两个父表的组合。请注意，有些人也可能会为这些表添加代理键。如果有多个候选键，从身份的角度来看并不重要。确定身份的重要之处在于外键是否是候选键的一部分，不管该键是否是主键。

另一个很好的例子就像数据库的元数据目录一样，其中一列由其所属的表标识，就像该表由其所在的模式标识一样，等等。知道名为NAME的列不会告诉您它是哪一列。知道它是CUSTOMER表中NAME列的帮助。 （您还必须知道CUSTOMER所在的模式，等等）。

Answer 2

乔尔提供了良好的answer（+1给他），让我提供想着确定关系时，您可以使用一个小的心理捷径......只是问自己：

我能做到唯一性只有与子实体的属性？

如果没有，你需要包括从父迁移到子键，使其独特的属性，那么你有一个确定的关系。这是关于识别依赖，而不是生存依赖！

您可能对this post感兴趣了解更多关于此主题的讨论。

---

和子实体是 “弱” 或 “依赖”。

尽管识别依赖性通常意味着存在依赖性。