我读过这个问题：What's the difference between identifying and non-identifying relationships?
但我还是不太确定...... 我有三张桌子。
用户可以拥有许多对象，也可以为每个对象发布许多图片。 我的直觉告诉我这是一个识别关系，因为我需要在对象表中的userID，我需要在图片表中的objectID ......
或者我错了？另一个主题的解释仅限于数据库在已经编码后解释它的方式的理论解释，而不是对象在现实生活中如何连接。在考虑如何构建数据库时，我对如何做出识别与非识别的决定感到困惑。
答案 0 :(得分：54)
两者听起来都像是在与我建立关系。如果您听说过一对一或一对多，多对多，一对一关系这些术语识别关系，并且<强>多对多关系是非识别关系。
如果孩子识别其父母，则识别关系。在您提供的链接中，如果您有电话号码，您就知道它属于谁（它只属于一个）。
如果孩子没有识别其父母，那么这是一种非识别关系。在链接中，它提到了国家。将状态视为表示情绪的表中的行。 “快乐”并不是一个特定的人，而是很多人。
修改：其他现实生活中的例子：
答案 1 :(得分：9)
我认为更简单的可视化方法是问问自己，如果没有父母，儿童记录是否可以存在。例如，订单行项目需要存在订单标题。因此，订单行项目必须将订单标题标识符作为其密钥的一部分，因此，这是标识关系的示例。
另一方面，虽然一个人可能有多个电话号码，但电话号码可以在没有人的所有权的情况下存在。在这种情况下，拥有电话号码的人是非密钥或非识别关系，因为无论所有者是谁，电话号码都可以存在（因此，电话号码所有者人可以为零，而在订单行项目示例中，订单头标识符不能为空。
答案 2 :(得分：6)
NickC Said：一对一关系是识别关系，多对多关系是非识别关系
这个解释对我来说似乎完全没错。你可以：
想象一下，您有以下表：customer，products和feedback。所有这些都基于customer_id表中存在的cutomer。因此，通过 NickC 定义，不应存在任何类型的多对多识别关系，但在我的示例中，您可以清楚地看到：只有当相关产品已存在并已由客户购买，因此客户，产品和反馈应该是识别。
您可以查看MySQL Manual，解释如何在MySQL Workbench上添加外键。
答案 3 :(得分：3)
识别与非识别与身份无关。 简单地问自己，没有父母的孩子记录是否存在？如果答案是肯定的，那就是不识别。
核心是孩子的主键是否包含父键的外键。在非识别关系中，孩子的主键（PK）不能包含外键（FK）。
如果孩子可以在没有父母的情况下存在，那么这种关系是不可识别的。 （感谢MontrealDevOne更清楚地说明它）
社会保障号码非常适合此类别。让我们想象一下，例如社会安全号码不能存在于一个人身上（也许他们可以在现实中，但不能存在于我们的数据库中） person_id 将是人表的PK，包括名称和地址等列。 （让我们保持简单）。 social_security_number 表格中包含 ssn 列和 person_id 列作为外键。由于此FK可用作 social_security_number 表的PK，因此它是一种识别关系。
在大型办公大楼，您可能会有一个办公室表，其中包括按楼层排列的房间号码和包含PK的楼宇号码，以及单独的员工表格。员工表（子）具有FK，即 office 表PK中的 office_id 列。虽然每个员工只有一个办公室，并且（对于这个例子）每个办公室只有一个员工，但这是一个非识别关系，因为办公室可以在没有员工的情况下存在，员工可以在现场更换办公室或工作。
通过询问相同的问题，可以轻松地将一对多关系分类。
多对多关系总是能够识别关系。这可能看似违反直觉，但请耐心等待。选择两个表 libary 和 books ，每个库都有很多书，每本书的副本都存在于许多库中。
以下是制作和识别关系的原因： 为了实现这一点，您需要一个包含两列的链接表，这两列是每个表的主键。称他们为 library_id 列和 ISBN 列。这个新的链接表没有单独的主键，但是等等！外键成为链接表的多列主键，因为链接表中的重复记录将毫无意义。父母不能存在链接;因此，这是一种识别关系。我知道，对吗？
所有这一切，通常你不必担心你有哪些。只需为每个表分配正确的主键和外键，关系就会自行发现。
编辑：NicoleC，我读了您关联的answer，但我确实同意我的意见。我对SSN提出了自己的观点，并认为这是一个不好的例子。我会试着在那里想出另一个更清晰的例子。然而，如果我们开始在定义数据库关系时使用现实世界的类比，那么类比总会崩溃。重要的是，无论SSN是否识别某个人，您是否将其用作外键都很重要。