Question

所以，我一直在阅读我的数据库设计中的识别与非识别关系，并且关于SO的一些答案似乎与我相矛盾。以下是我要看的两个问题：

What's the Difference Between Identifying and Non-Identifying Relationships
Trouble Deciding on Identifying or Non-Identifying Relationship

从每个问题的最佳答案看，我似乎对识别关系有两种不同的看法。

第一个问题的回答是，识别关系“描述了子表中行的存在取决于父表中的行的情况。”给出的一个例子是，“作者可以写很多书（1对n的关系），但没有作者就不能存在书。”这对我来说很有意义。

然而，当我读到对问题二的回答时，我感到困惑，因为它说，“如果孩子识别其父母，那就是一种识别关系。”然后答案继续给出例如Social Security Number（识别一个人），但地址不是（因为许多人可以住在一个地址）。对我来说，这听起来更像是主键和非主键之间的决定。

我自己的直觉（以及对其他网站的其他研究）指出第一个问题及其反应是正确的。但是，在我继续前进之前，我想验证，因为我不想学习错误，因为我正在努力理解数据库设计。提前谢谢。

Answer 1

识别关系的技术定义是孩子的外键是其主键的一部分。

CREATE TABLE AuthoredBook (
  author_id INT NOT NULL,
  book_id INT NOT NULL,
  PRIMARY KEY (author_id, book_id),
  FOREIGN KEY (author_id) REFERENCES Authors(author_id),
  FOREIGN KEY (book_id) REFERENCES Books(book_id)
);

请参阅？ book_id是外键，但它也是主键中的一列。因此，此表与引用的表Books具有标识关系。同样，它与Authors具有识别关系。

对YouTube视频的评论与相应视频具有识别关系。 video_id 应成为Comments表主键的一部分。

CREATE TABLE Comments (
  video_id INT NOT NULL,
  user_id INT NOT NULL,
  comment_dt DATETIME NOT NULL,
  PRIMARY KEY (video_id, user_id, comment_dt),
  FOREIGN KEY (video_id) REFERENCES Videos(video_id),
  FOREIGN KEY (user_id) REFERENCES Users(user_id)
);

可能很难理解这一点，因为现在通常只使用串行代理键而不是复合主键：

CREATE TABLE Comments (
  comment_id SERIAL PRIMARY KEY,
  video_id INT NOT NULL,
  user_id INT NOT NULL,
  comment_dt DATETIME NOT NULL,
  FOREIGN KEY (video_id) REFERENCES Videos(video_id),
  FOREIGN KEY (user_id) REFERENCES Users(user_id)
);

这可能会模糊表格具有识别关系的情况。

我不认为SSN代表了一种识别关系。有些人存在，但没有SSN。其他人可以申请获得新的SSN。所以SSN实际上只是一个属性，而不是该人主键的一部分。

来自@Niels的评论：

因此，如果我们使用代理键而不是复合主键，则使用识别关系或非识别关系之间没有显着差异吗？

我猜是这样的。我不愿意说是，因为我们没有通过使用代理键更改表之间的逻辑关系。也就是说，如果不引用现有视频，您仍然无法发表评论。但这只是意味着video_id必须是NOT NULL。对我而言，逻辑方面确实是关于识别关系的重点。

但也有识别关系的物理方面。这就是外键列是主键的一部分（主键不一定是复合键，它可以是单个列，它既是Comments的主键，也是Videos表的外键。，但这意味着你每个视频只能存储一个评论。）

仅仅为了实体关系图表而识别关系似乎很重要，这在GUI数据建模工具中出现。

Answer 2

“因为我不想学错”。

韦尔，如果你的意思是，那么你可以不再担心ER术语和术语。它是不精确，混乱，令人困惑的，根本没有达成共识，而且大部分都是无关紧要的。

ER是在一张纸上绘制的一堆矩形和直线。 ER故意用于非正式建模。因此，它是数据库设计中有价值的第一步，但它也只是：第一步。

ER图表永远不会接近D中正式写出的数据库设计的准确性，准确性和完整性。

Answer 3

识别/非识别关系是ER建模中的概念 - 如果关系是由作为引用表主键一部分的外键表示的关系，则该关系是识别关系。这在关系建模术语中通常非常不重要，因为关系模型和SQL数据库中的主键没有像在ER模型中那样具有任何特殊意义或功能。

例如，假设您的表强制执行两个候选键A和B.假设A也是该表中的外键。如果A被指定为“主要”密钥，则由此表示的关系被认为是“识别”，但如果B是主要密钥则不识别。然而，表格的形式，功能和含义在每种情况下都是相同的！这就是为什么在我看来我不认为识别/非识别概念真的非常重要。

Answer 4

我认为识别和非识别关系之间的区别仅在于外键的可空性。如果FK不能为NULL，则它表示的关系是识别（没有父项的子项不存在），否则它不是标识。

Answer 5

这里的部分问题是术语的混淆。识别关系对于避免长连接路径很有用。

我所看到的最佳定义是“识别关系包括孩子PK中父母的PK。换句话说，孩子的PK包括父母的FK以及”实际“的PK孩子。

Answer 6

是的，和第一个一起去，但我不认为第二个与第一个相矛盾。它的制定有点令人困惑......

更新：

刚检查 - 第二个问题的答案在某些假设中是错误的，...书籍作者不一定是1：n关系，因为它可能是m：n。在为这个m：n关系创建交集表的关系数据库中，您可以识别交集表与其他2个表之间的关系..

Answer 7

当我们必须定义父对子关系时，识别关系会给出一对多的可选关系。此外，它只给出一个从子到父流的一个关系。因为父实体主键将是主键的一部分。子实体，子实体实例将标识父实体instance.it在er图中用实线表示。

其中非识别关系会有多对多的关系。对于子实体实例的存在，应该有父实体实例，但子实体中的每个实体实例都可能与父实体的许多实体实例相关。这就是为什么父实体的主键很好是子实体的外键，但子实体不会将父实体主键作为其主键。它将拥有自己的主键。现实世界中不存在多对多的关系。所以需要解决

Answer 8

确定性关系的确是ERD概念，因为这是概念建模的领域，为我们对“话语宇宙”的理解建模。这是一种父子关系，因此我们对以下事实进行建模：每个子对象的身份（至少部分）由父对象的身份建立/确定。因此，它是强制性的并且是不变的。

一个真实的例子是长期存在的人们识别挑战。一个人的独特身份可以（部分地）由他们与其亲生父母的关系来定义。众所周知，这些都是不变的事实。因此，亲生父母与孩子之间的关系是一种确定性关系，因为它（肯定地）有助于定义孩子的身份。

正是这些品质以及关系dbms构造的使用导致子级PK为复合键，该组合键通过FK包括父级PK。作为PK，孩子的身份是强制性且不可变的（不能更改）。PK中的“更改”实际上是在实例化一个新对象。因此，PK必须不能更改。 PK的不变性也应受到约束。数据库约束可用于实现PK的质量。

仍然困惑于识别与非识别关系

8 个答案: