3

所以，我已经在 stackoverflow 上阅读了很多答案，但我仍然对其整个概念感到困惑。具体来说，我已经阅读了这篇文章（包括它引用的所有文章），但似乎无法很好地掌握这个概念（或者可能是我在基数（n:m 等）和身份之间的混淆):

仍然对识别与非识别关系感到困惑

我的问题是：我知道识别关系意​​味着子实体的主键必须包含其外键，而非识别关系则相反（这是正确的吗？）。现在，这对我来说似乎有点太“前瞻性”了？在其中一个链接的其中一条评论中也说了同样的话。我怎样才能“退后一步”并真正看到哪些关系属于哪个身份？

例如，我有两个困境：

  1. job_title（父母，1）到employee（孩子，1..*）。我的想法是否正确，因为 job_title 是一个查找表，它必须是一个非识别关系？或者说“没有职称就不能存在员工，因此它必须是识别”会更准确吗？或者是定义该场景的关系？
  2. employeeto employee_equipment（m:n 基数之间的桥接实体） to equipment。现在，我读到这必须是employee_equipment 双方的识别关系。但是，如果员工不需要设备怎么办？可以有一个可选的识别关系吗？

我想我真的在寻找一种方法来确定应该属于哪些身份表，而不考虑主键/外键，或者任何与此相关的真正技术性的东西。

任何帮助将非常感激！

4

2 回答 2

5

你过度思考了选择性和身份之间的联系。在整个事情对您来说更自然之前，最好将它们视为完全不相关的。

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

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

使关系识别的原因是，您必须知道您在说什么父母（以及其他一些事情）才能知道您在说什么孩子。也就是说，子项的主键必须包含父项的外键。

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

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

于 2013-03-16T00:40:34.277 回答
3

乔尔提供了一个很好的答案（给他+1），让我提供一个小的心理捷径，您可以在考虑识别关系时使用它......问问自己：

我可以仅使用子实体的属性来实现唯一性吗？

如果不是，并且您需要包含从父键迁移到子键中的属性以使其唯一，那么您就有一个标识关系1。这是关于识别依赖，而不是存在依赖2！

您可能会对这篇文章感兴趣，以了解有关该主题的更多思考。

1并且子实体是“弱的”或“依赖的”。

2虽然认同依赖通常意味着存在依赖。

于 2013-03-16T11:35:48.737 回答