识别和非识别关系之间有什么区别？
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了识别和非识别关系之间有什么区别？相关的知识，希望对你有一定的参考价值。
我无法完全掌握差异。你能描述这两个概念并使用现实世界的例子吗？
- 标识关系是指子表中存在的行取决于父表中的行。这可能会令人困惑，因为现在通常的做法是为子表创建伪代码，但不要将外键设置为子代主键的父部分。在形式上，这样做的“正确”方法是使外键成为孩子主键的一部分。但逻辑关系是，没有父母，孩子就不能存在。
示例：
Person有一个或多个电话号码。如果他们只有一个电话号码，我们可以简单地将它存储在Person列中。由于我们想要支持多个电话号码，我们制作了第二个表PhoneNumbers，其主键包括引用person_id表的Person。 我们可能会将电话号码视为属于某个人，即使它们被建模为单独表格的属性。这是一个强有力的线索，这是一种识别关系（即使我们没有在person_id的主键中包含PhoneNumbers）。 - 非标识关系是指父级的主键属性不能成为子级的主键属性。一个很好的例子是查找表，例如引用
Person.state主键的States.state上的外键。Person是关于States的儿童桌。但Person中的一行未被其state属性识别。即state不是Person主键的一部分。 非标识关系可以是可选的或强制的，这意味着外键列分别允许NULL或不允许NULL。
另见我对Still Confused About Identifying vs. Non-Identifying Relationships的回答
迁移从父级到子级的属性是否有助于识别孩子？
- 如果是：识别依赖存在，关系识别，子实体“弱”。
- 如果不是：识别依赖不存在，关系是非识别的，子实体“强”。
请注意，识别依赖意味着存在依赖性，而不是相反。每个非NULL FK意味着没有父项就不能存在子项，但仅此一项不会使关系识别。
有关此内容的更多信息（以及一些示例），请查看ERwin Methods Guide的“识别关系”部分。
附：我意识到我（非常）迟到了派对，但我觉得其他答案要么不完全准确（用存在依赖而不是识别依赖来定义），要么有些蜿蜒。希望这个答案提供更清晰......
1子级的FK是子级PRIMARY KEY或（非NULL）UNIQUE约束的一部分。
订单处理就是一个很好的例子。来自客户的订单通常具有标识订单的订单号，每个订单发生一次的一些数据，例如订单日期和客户ID，以及一系列订单项。每个订单项都包含一个项目编号，用于标识订单中的订单项，订购的产品，产品的数量，产品的价格以及订单项的金额，可以通过将数量乘以价钱。
标识订单项的数字仅在单个订单的上下文中标识它。每个订单中的第一个订单项是商品编号“1”。订单项的完整标识是商品编号以及作为其一部分的订单编号。
因此，订单和订单项之间的父子关系是一种识别关系。 ER建模中一个密切相关的概念是名称“subentity”，其中订单项是订单的子实体。通常，子实体与其从属的实体具有强制的子父级身份关系。
在经典数据库设计中，LineItems表的主键是（OrderNumber，ItemNumber）。今天的一些设计师会给项目一个单独的ItemID作为主键，并由DBMS自动增加。在这种情况下，我推荐经典设计。
如下面的链接中所解释的那样，识别关系有点像ER概念模型中与其父类的弱实体类型关系。用于数据建模的UML样式CAD不使用ER符号或概念，并且关系的类型是：识别，非识别和非特定。
识别那些是父/子的关系，其中孩子是弱实体（即使在传统的ER模型中称为识别关系），其自身属性没有真正的主键，因此无法通过其自身唯一识别。在物理模型上对子表的每次访问都将依赖于（包括语义上）父级主键，该主键变为子主键的一部分或全部（也是外键），通常会导致复合键在孩子身边。子项本身的最终现有键只是伪键或部分键，不足以在没有父级PK的情况下识别该类型的实体或实体集的任何实例。
非标识关系是完全独立的实体集的普通关系（部分或全部），其实例不依赖于彼此的主键被唯一标识，尽管它们可能需要外键用于部分或全部关系，但不是作为孩子的主要钥匙。孩子有自己的主键。父母同意。都是独立的。根据关系的基数，一个的PK作为FK到另一个（N侧），如果是部分，则可以为null，如果是total，则必须不为空。但是，在这种关系中，FK永远不会成为孩子的PK，就像识别关系的情况一样。
http://docwiki.embarcadero.com/ERStudioDA/XE7/en/Creating_and_Editing_Relationships
假设我们有这些表格：
user
--------
id
name
comments
------------
comment_id
user_id
text
这两个表之间的关系将确定关系。因为，评论只能属于其所有者，而不属于其他用户。例如。每个用户都有自己的评论，当用户被删除时，也应该删除该用户的评论。
识别关系在两个强实体之间。非识别关系可能并不总是强实体和弱实体之间的关系。可能存在子项本身具有主键但其实体的存在可能依赖于其父实体的情况。
例如：卖方和卖方出售图书的书籍之间的关系可能存在，卖方可能拥有自己的主要钥匙但其实体仅在出售书籍时创建。
参考基于Bill Karwin
现实世界还有另一种解释：
一本书属于一个所有者，一个所有者可以拥有多本书。但是，这本书也可以在没有所有者的情况下存在，并且它的所有权可以从一个所有者变为另一个。书与所有者之间的关系是一种非识别关系。
然而，一本书是由作者撰写的，作者本可以写多本书。但是，这本书需要由作者撰写 - 没有作者就不可能存在。因此，书与作者之间的关系是一种识别关系。
标识关系指定在没有父对象的情况下子对象不能存在
非标识关系指定对象之间的常规关联，1：1或1：n基数。
如果父级不是必需的，则可以将非标识关系指定为可选，或者通过设置父表基数，在需要父级的情况下将非标识关系指定为必需关系...
Bill's answer是正确的，但令人震惊的是，在所有其他答案中，没有人指出最重要的方面。
一遍又一遍地说，如果没有父母，孩子就不能存在并确定关系。 （例如user287724）。这是事实，但完全忽略了这一点。只要外键足够非空，就可以实现这一点。它不需要是主键的一部分。
所以这是真正的原因：
识别关系的目的是外键永远不会改变，因为它是主键的一部分... therefore识别！
这是一个很好的描述：
两个实体之间的关系可以被分类为“识别”或“非识别”。当父实体的主键包含在子实体的主键中时，存在标识关系。另一方面，当父实体的主键包含在子实体中但不作为子实体的主键的一部分时，存在非标识关系。此外，非识别关系可以进一步分类为“强制性”或“非强制性”。当子表中的值不能为空时，存在强制的非标识关系。另一方面，当子表中的值可以为null时，存在非强制性非标识关系。
http://www.sqlteam.com/article/database-design-and-modeling-fundamentals
这是一个识别关系的简单示例：
Parent
------
ID (PK)
Name
Child
-----
ID (PK)
ParentID (PK, FK to Parent.ID) -- notice PK
Name
这是一个相应的非识别关系：
Parent
------
ID (PK)
Name
Child
-----
ID (PK)
ParentID (FK to Parent.ID) -- notice no PK
Name
user287724's answer给出了以下书籍和作者关系的例子：
然而，一本书是由作者撰写的，作者可以写出多本书。但这本书需要由作者撰写，如果没有作者，就不能存在。因此，书与作者之间的关系是一种识别关系。
这是一个非常令人困惑的例子，绝对不是identifying relationship的有效例子。
是的，没有至少一个book就不能写author，但author的book（它的外键）不能识别book表中的books！
您可以从author行中删除book（FK），仍然可以通过其他字段（ISBN，ID等等）识别书籍行，但不是本书的作者！
我认为identifying relationship的有效例子是（产品表）和（特定产品详细信息表）之间的关系1:1
products table
+------+---------------+-------+--------+
|id(PK)|Name |type |amount |
+------+---------------+-------+--------+
|0 |hp-laser-510 |printer|1000 |
+------+---------------+-------+--------+
|1 |viewsonic-10 |screen |900 |
+------+---------------+-------+--------+
|2 |canon-laser-100|printer|200 |
+------+---------------+-------+--------+
printers_details table
+--------------+------------+---------+---------+------+
|Product_ID(FK)|manufacturer|cartridge|color |papers|
+--------------+------------+---------+---------+------+
|0 |hp |CE210 |BLACK |300 |
+--------------+------------+---------+---------+------+
|2 |canon |MKJ5 |COLOR |900 |
+--------------+------------+---------+---------+------+
* please note this is not real data
在这个例子中，Product_ID表中的printers_details被认为是QK引用products.id表，而ALSO是printers_details表中的PK，这是一种识别关系，因为打印机表中的Product_ID（FK）正在识别子表内的行，我们无法从子表中删除product_id，因为我们无法识别该行，因为我们丢失了它的主键
如果你想把它分成两行：
标识关系是子表中的FK被视为子表中的PK（或标识符）同时仍引用父表时的关系
另一个例子可能是某些国家/地区数据库的导入和导出中有3个表（导入 - 产品 - 国家/地区）
import表是具有这些字段的孩子（product_id（FK），country_id（FK），进口金额，价格，进口单位，运输方式（空运，海运））
we may use the (product_id, thecountry_id`）识别导入的每一行“如果它们都在同一年”，这两个列可以组合子表中的主键（导入）并引用父表。
我很高兴我终于理解了identifying relationship和non identifying relationship的概念，所以请不要告诉我，对于一个完全无效的例子，我所有这些投票都错了
是的，逻辑上一本书没有作者就无法写出，但是一本书可以在没有作者的情况下被识别，实际上它无法与作者一致认同！
您可以100％从书行中删除作者，仍然可以识别该书！
非识别关系
非识别关系意味着孩子与父母有关，但可以由自己识别。
PERSON ACCOUNT
====== =======
pk(id) pk(id)
name fk(person_id)
balance
ACCOUNT和PERSON之间的关系是不可识别的。
确定关系
识别关系意味着父母需要为孩子提供身份。由于父母，孩子完全存在。
这意味着外键也是主键。
ITEM LANGUAGE ITEM_LANG
==== ======== =========
pk(id) pk(id) pk(fk(item_id))
name name pk(fk(lang_id))
以上是关于识别和非识别关系之间有什么区别？的主要内容，如果未能解决你的问题，请参考以下文章