仍然困惑于确定与不确定的关系

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

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的重新评论:

所以,如果我们使用代理键而不是复合主键,那么在使用标识关系和非标识关系之间没有显著的区别?

我想是这样。我很犹豫是否同意,因为我们没有改变 符合逻辑的 通过使用代理键在表之间建立关系。也就是说,在不引用现有视频的情况下,您仍然无法发表评论。但这只意味着视频ID不能为空。对我来说,逻辑的方面是确定关系的关键。

但也有一个确定关系的物理方面。这就是外键列是主键的一部分(主键不一定是复合键,它可以是单个列,它既是注释的主键,也是视频表的外键,但这意味着每个视频只能存储一个注释)。

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

“因为我不想学错事”。

好吧,如果你真的是这么想的话,那你就别再担心这个词了。这是不精确的,混乱的,混乱的,完全没有达成一致意见,而且在很大程度上是不相关的。

ER是一张纸上画的一束长方形和直线。ER是有意为 非正式的 建模。因此,它是数据库设计中一个有价值的第一步,但也是第一步。

ER图决不能接近D中正式编写的数据库设计的精确性、准确性和完整性。

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

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

我认为标识关系和非标识关系之间的唯一区别在于外键的空性。如果fk不能为空,则它表示的关系正在标识(没有父级子级不能存在),否则它是不标识的。

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

我所看到的最好的定义是“识别关系包括子pk中父级的pk”。换句话说,子对象的pk包括父对象的fk以及子对象的“实际”pk。

是的,跟第一个走,但我认为第二个和第一个不矛盾。只是有点混乱……

更新:

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

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

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

识别关系实际上是一个ERD概念,因为这是概念建模的领域,模拟了我们对“话语宇宙”的理解。它是一种父子关系,通过这种关系,我们可以对每个子对象的标识(至少部分)由父对象的标识建立/确定的事实进行建模。因此,它是强制性的,不可变的。

一个现实世界的例子是识别人的长期挑战。一个人的独特身份可以(部分地)通过他们与生父母的关系来定义。如果知道,这些都是不变的事实。因此,亲生父母与子女之间的关系是一种识别关系,因为它有助于(不变地)定义子女的身份。

正是这些特性和关系DBMS结构的使用导致子级的pk成为一个复合键,通过fk,它包括父级的pk。作为一个pk,子对象的标识是强制的和不可变的(它不能更改)。pk中的“更改”实际上是实例化一个新对象。因此,不能更改pk。pk的不变性也应该受到约束。可以使用db约束来实现pks的质量。