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

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

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 必须不为空。对我来说，逻辑方面是识别关系的真正重点。

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

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

---

“因为我不想学错东西”。

好吧，如果你真的是这个意思，那么你可以停止担心 ER 术语和术语。它是不精确的、混乱的、令人困惑的，根本不是普遍同意的，而且在大多数情况下是不相关的。

ER 是在一张纸上绘制的一堆矩形和直线。 ER 有意成为非正式建模的一种手段。因此，这是数据库设计中有价值的第一步，但也仅仅是：第一步。

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

---

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

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

---

我相信识别和非识别关系之间的唯一区别在于外键的可空性。如果 FK 不能为 NULL，则它所代表的关系是可识别的（没有父代就不能存在子代），否则它是不可识别的。

---

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

我见过的最好的定义是“识别关系包括子 PK 中作为父级的 PK。换句话说，子级的 PK 包括对父级的 FK 以及子级的“实际”PK。

---

是的，选择第一个，但我不认为第二个与第一个矛盾。只是表述有点混乱。。

更新：

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

---

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

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

---

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

一个现实世界的例子是识别人的长期挑战。一个人的独特身份可以（部分）由他们与生母和生父的关系来定义。当已知时，这些都是不可改变的事实。因此，亲生父母和孩子之间的关系是一种识别关系，因为它（不变地）有助于定义孩子的身份。

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

---