仍然困惑于识别与非识别关系
所以，我一直在阅读我的数据库devise中的识别关系和非识别关系，而对于我而言，一些答案似乎与我矛盾。 以下是我所看到的两个问题：
- 识别和非识别关系有什么区别？
- 麻烦决定识别或不识别关系
从每个问题的顶部答案看，我似乎得到了两个不同的想法是什么一个识别关系。
第一个问题的回答是，一个识别关系“描述了一个情况，即子表中的一行的存在取决于父表中的一行。 给出的一个例子是：“一个作者可以写很多书（一对多的关系），但是没有一个作者就不可能存在一本书。 这对我有意义。
但是，当我读到第二个问题的回答时，我感到困惑，因为它说：“如果一个孩子识别了他的父母，这是一个识别关系。 答案然后举例说明社会安全号码 （是识别一个人），但地址不是（因为很多人可以住在一个地址）。 对我来说，这听起来更像是主键和非主键之间的决定。
我自己的直觉（和其他网站的其他研究）指出了第一个问题，其答案是正确的。 然而，在我继续前进之前，我想validation一下，因为我正在努力理解数据库devise，所以我不想学习错误。 提前致谢。
识别关系的技术定义是孩子的外键是其主键的一部分。
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有一个确定的关系。
对YouTubevideo的评论与相应的video具有识别关系。 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，您仍然无法发表评论。 但是，这只是意味着video_id必须不是NULL。 对我来说，逻辑方面的确是关于确定关系的一点。
但是，识别关系也有一个物理方面。 这就是外键列是主键的一部分（主键不一定是一个组合键，它可以是一个单独的列，它既是评论的主键，也是video表的外键，但这意味着你可以只存储一个video评论）。
识别关系似乎只是为了实体关系图的重要性，这是在GUI数据build模工具。
“因为我不想学错了”。
韦尔，如果你真的这么说，那么你可以停止担心ER的术语和术语。 这是不准确的，困惑的，令人困惑的，根本没有得到普遍认可，而且大部分是不相关的。
ER是在一张纸上绘制的一串矩形和直线。 ER故意用作非正式build模的手段。 因此，这是数据库devise中宝贵的第一步，但也只是：第一步。
从来没有一个ER图能够接近D中正式写出的数据库devise的精确性，准确性和完整性。
识别/非识别关系是ERbuild模中的概念 – 如果一个关系是由作为引用表主键的一部分的外键表示的，则该关系是一个识别关系。 在关系build模方面，这通常是非常不重要的，因为关系模型和SQL数据库中的主键与ER模型中没有任何特殊的意义或function。
例如，假设您的表强制执行两个候选键A和B.假设A也是该表中的外键。 如果A被指定为“主要”密钥，则这样表示的关系被认为是“识别”，但是如果B是主要密钥则它是非识别的。 然而这个表格的forms，function和含义在每种情况下是相同的！ 这就是为什么我认为我不认为识别/非识别概念真的非常重要。
我认为只有识别和非识别关系的区别是关于外键的可空性。 如果一个FK不能为NULL，它所表示的关系就是识别（没有父节点的情况下，子节点不能存在），否则就不能识别。
这里的问题的一部分是术语混淆。 识别关系对于避免长连接path是有用的。
我所看到的最好的定义是“一个识别关系包括PK在父母身份中的PK，换句话说，孩子的PK包括父母的FK以及孩子的”实际“PK。
是的，与第一个去，但我不认为第二个与第一个相矛盾。 这只是制定了一点点混淆..
更新：
刚刚检查过 – 第二个问题的答案在一些假设中是错误的，书籍作者不一定是1：n关系，因为它可能是m：n。 在为此m：n关系创build交集表的关系数据库中，您可以find交集表和其他两个表之间的关系。
当需要定义父子关系时，识别关系给出了一对多的可选关系。此外，它给出了从子对父stream只有一个关系。因为父实体主键将是子实体主键的一部分，子实体实例将识别父实体实例，在图中用实线表示。
作为非标识关系将会有多对多的关系。对于子实体实例的存在，应该有父实体实例，但子实体中的每个实体实例可能与父实体的多个实体实例相关联，这就是为什么主键父实体很可能是子实体的外键，而子实体不会将父实体的主键作为主键，它将拥有自己的主键。 现实世界中不存在多对多的关系图。 所以需要解决
