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

Question 1

因此，我一直在阅读数据库设计中的识别关系与非识别关系，关于SO的许多答案似乎与我矛盾。这是我正在查看的两个问题：

查看每个问题的最高答案，我似乎对确定的关系有两种不同的想法。

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

但是，当我读到对第二个问题的回答时，我很困惑，因为它说：“如果孩子确定了其父母，那是一种确定的关系。” 然后答案继续给出示例，例如社会安全号码（用于识别一个人），但没有地址（因为许多人可以住在一个地址上）。对我来说，这听起来更像是在主键和非主键之间做出决定的情况。

我自己的直觉（以及在其他站点上的其他研究）指出第一个问题及其答案是正确的。但是，我想在继续前进之前先进行验证，因为在努力理解数据库设计时，我不想学习任何错误。提前致谢。

Question 2

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

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必须为非NULL。对我而言，逻辑方面确实是确定关系的关键。

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

识别关系似乎仅对于实体关系图来说很重要，而这在GUI数据建模工具中会出现。

Question 3

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

Welll，如果您真的是那样，那么您就不必担心ER术语和术语。它是不精确的，混乱的，令人困惑的，完全没有被普遍接受，并且在很大程度上是无关紧要的。

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

ER图绝不会接近用D正式写成的数据库设计的准确性，准确性和完整性。

Question 4

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

例如，假设您的表强制使用两个候选键A和B。假设A也是该表中的外键。如果将A指定为“主”键，则这样表示的关系被视为“标识”，但是如果B是主键，则该关系不确定。然而，表格的形式，功能和含义在每种情况下都是相同的！这就是为什么我认为识别/非识别概念不是非常重要的原因。

Question 5

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

Question 6

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

我见过的最好的定义是“一种确定的关系包括在孩子PK中作为父母的PK。换句话说，孩子的PK包括对父母的FK以及孩子的“实际” PK。

Question 7

是的，请选择第一个，但我不认为第二个与第一个相矛盾。只是有些混乱而已。

更新：

刚刚检查过-第二个问题的答案在某些假设中是错误的，。书作者不一定是1：n关系，因为它可能是m：n。在为该m：n关系创建相交表的关系数据库中，您将获得相交表与其他两个表之间的标识关系。

Question 8

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

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

Question 9

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

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

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