难以决定识别或非识别关系
我读过这个问题：识别和非识别之间有什么区别-识别关系？
但我仍然不太确定...... 我有的是三张桌子。
- 用户
- 对象
- 图片
用户可以拥有许多对象，并且还可以为每个对象发布许多图片。 我的直觉告诉我这是一种识别关系，因为我需要对象表中的 userID，并且需要图片表中的 objectID...
或者我错了？ 另一个主题中的解释仅限于数据库在编码后解释它的方式的理论解释，而不是对象在现实生活中如何连接。 在考虑如何构建数据库时，我对如何做出识别与非识别的决定感到有点困惑。
I've read this question: What's the difference between identifying and non-identifying relationships?
But I'm still not too sure...
What I have is three tables.
- Users
- Objects
- Pictures
A user can own many objects and can also post many pictures per individual object.
My gut feeling tells me this is an identifying relationship, because I'll need the userID in the objects table and I'll need the objectID in the pictures tables...
Or am I wrong? The explanations in the other topic limit themselves to the theoretical explanation of the way the database interprets it after it's already been coded, not how the objects are connected in real life. I'm kinda confused as to how to make the decision of identifying versus non-identifying when thinking about how I'm going to build the database.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
马赫迪，你的直觉是正确的。 这是一个重复的问题，这个投票的答案不正确或不完整。
看看这里最上面的两个答案：
识别非识别之间的区别
识别与非识别识别与身份无关。
只需问问自己，子记录可以在没有父记录的情况下存在吗？ 如果答案是肯定的，则它是非识别性的。
核心问题是子进程的主键是否包含父进程的外键。 在非标识关系中，子项的主键 (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，我读了回答你链接的，它确实与我的一致。 我同意他关于 SSN 的观点，并同意这是一个坏例子。 我会尝试想出另一个更清晰的例子。 然而，如果我们开始使用现实世界的类比来定义数据库关系，那么类比总是会失败。 SSN 是否识别一个人并不重要，重要的是您是否将其用作外键。
Mahdi, your instincts are correct. This is a duplicate question and this up-voted answer is not correct or complete.
Look at the top two answers here:
difference between identifying non-identifying
Identifying vs non-identifying has nothing to do with identity.
Simply ask yourself can the child record exist without the parent? If the answer is yes, the it is non-identifying.
The core issue whether the primary key of the child includes the foreign key of the parent. In the non-identifying relationship the child's primary key (PK) cannot include the foreign key (FK).
Ask yourself this question
If the child can exist without the parent, then the relationship is non-identifying. (Thank you MontrealDevOne for stating it more clearly)
One-to-one identifying relationship
Social security numbers fit nicely in to this category.Let's imagine for example that social security numbers cannot exist with out a person (perhaps they can in reality, but not in our database) The person_id would be the PK for the person table, including columns such as a name and address. (let's keep it simple). The social_security_number table would include the ssn column and the person_id column as a foreign key. Since this FK can be used as the PK for the social_security_number table it is an identifying relationship.One-to-one non-identifying relationship
At a large office complex you might have an office table that includes the room numbers by floor and building number with a PK, and a separate employee table. The employee table (child) has a FK which is the office_id column from the office table PK. While each employee has only one office and (for this example) every office only has one employee this is a non-identifying relationship since offices can exist without employees, and employees can change offices or work in the field.
One-to-many relationships
One-to-many relationships can be categorized easily by asking the same question.
Many-to-many relationships
Many-to-many relationships are always identifying relationships. This may seem counter intuitive, but bear with me. Take two tables libary and books, each library has many books, and a copy of each book exists in many libraries.
Here's what makes it and identifying relationship:
In order to implement this you need a linking table with two columns which are the primary keys of each table. Call them the library_id column and the ISBN column. This new linking table has no separate primary key, but wait! The foreign keys become a multi-column primary key for the linking table since duplicate records in the linking table would be meaningless. The links cannot exist with out the parents; therefore, this is an identifying relationship. I know, yuck right?
Most of the time the type of relationship does not matter.
All that said, usually you don't have to worry about which you have. Just assign the proper primary and foreign keys to each table and the relationship will discover itself.
EDIT: NicoleC, I read the answer you linked and it does agree with mine. I take his point about SSN, and agree that is a bad example. I'll try to think up another clearer example there. However if we start to use real-world analogies in defining a database relationship the analogies always break down. It matters not, whether an SSN identifies a person, it matters whether you used it as a foreign key.
这个解释在我看来完全错误。 您可以有：
假设您有下表：
客户、产品和反馈。 所有这些都基于cutomer表中存在的customer_id。 因此，根据 NickC 的定义，不应该存在任何类型的多对多识别关系，但是在我的示例中，您可以清楚地看到：只有当相关产品存在并且已被客户购买，因此客户、产品和反馈应具有识别性。你可以看看MySQL手册，解释如何也在 MySQL Workbench 上添加外键。
The explanation seems totally wrong to me. You can have:
Imagine you have the following tables:
customer,productsandfeedback. All of them are based on thecustomer_idwhich exists on thecutomertable. So, by NickC definition there shouldn't be exists any kind of Many-to-Many Identifying Relationships, however in my example, you can clearly see that: A Feedback can exists only if the relevant Product exists and has been bought by the Customer, so Customer, Products and Feedback should be Identifying.You can take a look at MySQL Manual, explaining how to add Foreign Keys on MySQL Workbench as well.
我认为更简单的可视化方法是问自己子记录是否可以在没有父记录的情况下存在。 例如，订单行项目需要存在订单标题。 因此，订单行项目必须将订单标头标识符作为其键的一部分，因此，这是标识关系的示例。
另一方面，电话号码可以在不属于个人的情况下存在，尽管一个人可能有多个电话号码。 在这种情况下，拥有电话号码的人是非关键或非识别关系，因为无论所有者是谁，电话号码都可以存在（因此，电话号码所有者可以为空，而在订单行项目示例中，订单头标识符不能为空。
I think that an easier way to visualize it is to ask yourself if the child record can exist without the parent. For example, an order line item requires an order header to exist. Thus, an order line item must have the order header identifier as part of its key and hence, this is an example of an identifying relationship.
On the other hand, telephone numbers can exist without ownership of a person, although a person may have several phone numbers. In this case, the person who owns the phone number is a non-key or non-identifying relationship since the phone numbers can exist irrespective of the owner person (hence, the phone number owner person can be null whereas in the order line item example, the order header identifier cannot be null.
两者听起来都像是在确定与我的关系。 如果您听说过术语“一对一”、“一对多”和“多对多”，那么一对关系是识别关系，并且< strong>多对多关系是非标识关系。
如果子项识别其父项，则这是一种识别关系。 在您提供的链接中，如果您有电话号码，您就知道它属于谁（它只属于一个）。
如果孩子无法识别其父母，则这是一种非识别关系。 在链接中，它提到了状态。 将状态视为表中代表情绪的一行。 “快乐”并不识别特定的人，而是许多人。
编辑：其他现实生活中的例子：
Both sound like identifying relationships to me. If you have heard the terms one-to-one or one-to-many, and many-to-many, one-to- relationships are identifying relationships, and many-to-many relationships are non-identifying relationships.
If the child identifies its parent, it is an identifying relationship. In the link you have given, if you have a phone number, you know who it belongs to (it only belongs to one).
If the child does not identify its parent, it is a non-identifying relationship. In the link, it mentions states. Think of a state as a row in a table representing mood. "Happy" doesn't identify a particular person, but many people.
Edit: Other real life examples: