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

Jas*_*Cav 74 database database-design relational-database identifying-relationship

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

  1. 识别和识别关系之间的区别是什么
  2. 确定识别或不识别关系的麻烦

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

第一个问题的响应表明,标识关系"描述了子表中行的存在取决于父表中的行的情况." 给出的一个例子是,"作者可以写很多书(1对n的关系),但没有作者就不能存在书." 这对我来说很有意义.

然而,当我阅读对问题二的回答时,我感到困惑,因为它说,"如果一个孩子识别其父母,那就是一种识别关系." 然后答案继续给出一些例子,例如社会安全号码(识别一个人),但地址不是(因为许多人可以住在一个地址).对我来说,这听起来更像是主键和非主键之间的决定.

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

Bil*_*win 148

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

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)
);
Run Code Online (Sandbox Code Playgroud)

看到? 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)
);
Run Code Online (Sandbox Code Playgroud)

可能很难理解这一点,因为现在使用串行代理键而不是复合主键是如此常见的做法:

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)
);
Run Code Online (Sandbox Code Playgroud)

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

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


来自@Niels的评论:

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

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

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

识别关系似乎仅仅是为了实体关系图表,并且这在GUI数据建模工具中出现.

  • 因此,如果我们使用代理键而不是复合主键,则使用识别关系或非识别关系之间没有显着差异? (2认同)

Erw*_*out 19

"因为我不想学错."

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

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

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

  • 因此,如果我正确地阅读您的回答,ER建模只是帮助概念化数据库的工具(类似于UML建模是用于概念化软件系统的工具).虽然每个工具都很有帮助,但它确实附带了警告,它们有自己的语法和问题,可能会进一步增加混乱.我没想过这个方面.谢谢. (7认同)
  • D是符合"数据库,类型和关系模型"和/或"第三宣言"中规定的所有语言的系列. (3认同)
  • 从语法上讲,这种表达“任何数据库约束”的形式上精确的方法将非常接近“数据库专业人员的应用数学”中使用的数据库设计规范语言/语法。它(不可避免地)看起来与更传统的方法(例如ERD,甚至是Halpin ORM)的约束规范技术完全不同(后者对约束规范的支持比ERD更为完善)。 (2认同)

nvo*_*gel 11

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

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


小智 9

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


gna*_*son 7

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

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

  • 用于"识别关系对于避免长连接路径有用"的+1.如果你详细说明这一点会很棒. (3认同)