识别关系和非识别关系有什么区别？

标识关系是子表中的行的存在依赖于父表中的行。这可能会令人困惑，因为如今为子表创建伪键是一种常见的做法，但不将外键作为子表的父部分的主键。形式上，“正确”的做法是让外键成为子主键的一部分。但逻辑关系是，没有父母，孩子就无法存在。示例：一个人有一个或多个电话号码。如果他们只有一个电话号码，我们可以简单地将其存储在 Person 列中。由于我们希望支持多个电话号码，我们创建了第二个表 PhoneNumbers，其主键包括引用 Person 表的 person_id。我们可能会认为电话号码属于一个人，即使它们被建模为单独表格的属性。这是一个强有力的线索，表明这是一种识别关系（即使我们没有在 PhoneNumbers 的主键中真正包含 person_id）。

非标识关系是指父项的主键属性不能成为子项的主键属性。一个很好的例子是查找表，例如 Person.state 上的外键引用 States.state 的主键。 Person 是相对于州的子表。但是 Person 中的一行不是由它的 state 属性标识的。即状态不是Person 主键的一部分。非标识关系可以是可选的或强制的，这意味着外键列分别允许 NULL 或不允许 NULL。

另请参阅我对 Still Confused About Identifying vs. Non-Identifying Relationships 的回答

---

现实世界还有另一种解释：

一本书属于一个所有者，一个所有者可以拥有多本书。但是，这本书也可以在没有所有者的情况下存在，并且它的所有权可以从一个所有者变为另一个所有者。一本书和所有者之间的关系是一种非识别关系。

然而，一本书是由一个作者写的，而这个作者可能写了多本书。但是，这本书需要由作者撰写——没有作者，它就无法存在。因此，书与作者之间的关系是一种识别关系。

---

Bill's answer 是正确的，但令人震惊的是，在所有其他答案中，没有人指出最重要的方面。

人们一遍又一遍地说过，在识别关系中，没有父母，孩子就无法存在。 （例如 user287724）。这是真的，但完全没有抓住重点。外键为 non-null 就足够了。它不需要是主键的一部分。

所以这才是真正的原因：

识别关系的目的是外键永远不会改变，因为它是主键的一部分...therefore识别！！！

---

标识关系指定子对象不能在没有父对象的情况下存在

非标识关系指定对象之间的常规关联，1:1 或 1:n 基数。

非标识关系可以在不需要父级的情况下指定为可选的，或者在需要父级的情况下通过设置父表基数来指定为强制...

---

这是一个很好的描述：

两个实体之间的关系可以分类为“识别”或“非识别”。当父实体的主键包含在子实体的主键中时，存在标识关系。另一方面，当父实体的主键包含在子实体中但不作为子实体主键的一部分时，则存在非标识关系。此外，非识别关系可以进一步分类为“强制性”或“非强制性”。当子表中的值不能为空时，存在强制的非标识关系。另一方面，当子表中的值可以为空时，存在非强制性的非标识关系。

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 而言绝对不是一个有效的示例。

是的，如果没有至少一个 author，就无法编写 book，但 book 的 author（它是外键）是 NOT IDENTIFYING book 中的 book 6}表！

您可以从 book 行中删除 author (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

在此示例中，printers_details 表中的 Product_ID 被视为引用 products.id 表的 FK 并且 ALSO PK 在 printers_details 表中，这是一种识别关系，因为 {1 }(FK) 在打印机表 IS IDENTIFYING 子表中的行中，我们无法从子表中删除 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))
                      name

ITEM_LANG 和 ITEM 之间的关系是标识性的。在 ITEM_LANG 和 LANGUAGE 之间。

---

如果你认为删除父项时也应该删除子项，那么它是一种标识关系。

如果即使删除了父项，也应该保留子项，则它是非标识关系。

例如，我有一个包含学员、培训、文凭和培训课程的培训数据库：

受训者与培训课程有确定的关系

培训与培训课程具有识别关系

但受训者与文凭有非识别性关系

如果删除相关学员、培训或文凭之一，则仅应删除培训课程。

---

标识关系意味着子实体完全依赖于父实体的存在。

示例 帐户表人员表和人员帐户。人员帐户表仅通过帐户和人员表的存在来标识。

非标识关系是指子表不通过父表的存在来标识。

示例 作为 accountType 和 account.accountType 表的表不标识存在 account 表。

---

就像下面链接中很好解释的那样，识别关系有点像 ER 概念模型中与其父级的弱实体类型关系。用于数据建模的 UML 样式 CAD 不使用 ER 符号或概念，关系的种类是：识别、非识别和非特定。

标识关系是父/子关系，其中子实体是一种弱实体（即使在传统的 ER 模型中，它也称为标识关系），其自身属性没有真正的主键，因此无法由其自身唯一标识.在物理模型上，对子表的每次访问都将依赖于（包括语义上）父主键，父主键变成子主键的一部分或全部（也是外键），通常会产生复合键在孩子方面。子项本身的最终现有密钥只是伪密钥或部分密钥，不足以识别该类型实体或实体集的任何实例，没有父项的 PK。

非标识关系是完全独立实体集的普通关系（部分或全部），其实例不依赖于彼此的主键来唯一标识，尽管它们可能需要外键来实现部分或全部关系，但不是作为孩子的主键。孩子有自己的主键。父母同上。两者独立。根据关系的基数，一个的 PK 作为 FK 到另一个（N 侧），如果是部分的，可以为空，如果是全部，则不能为空。但是，在这样的关系中，FK 永远不会是孩子的 PK，就像识别关系一样。

http://docwiki.embarcadero.com/ERStudioDA/XE7/en/Creating_and_Editing_Relationships

---

从父级迁移到子级的属性是否有助于识别1 子级？

如果是：标识依赖存在，关系是标识的，子实体是“弱的”。

如果不是：标识依赖不存在，关系是非标识的，子实体“强”。

请注意，识别依赖意味着存在依赖，但反之则不然。每个非 NULL FK 都意味着没有父级的子级不能存在，但仅此一项并不能确定关系。

有关这方面的更多信息（以及一些示例），请查看 ERwin Methods Guide 的“识别关系”部分。

PS我意识到我参加聚会（非常）迟到了，但我觉得其他答案要么不完全准确（根据存在依赖而不是身份依赖来定义它），要么有点曲折。希望这个答案能提供更多的清晰度......

1 孩子的 FK 是孩子的 PRIMARY KEY 或（非 NULL）UNIQUE 约束的一部分。

---

一个很好的例子来自订单处理。来自客户的订单通常具有标识订单的订单号、每个订单出现一次的一些数据（例如订单日期和客户 ID）以及一系列行项目。每个行项目包含一个项目编号，用于标识订单中的行项目、订购的产品、该产品的数量、产品的价格和行项目的金额，可以通过将数量乘以价格。

标识行项目的编号仅在单个订单的上下文中标识它。每个订单中的第一个行项目是项目编号“1”。行项目的完整标识是项目编号及其所属的订单编号。

因此，订单和订单项之间的父子关系是一种识别关系。 ER 建模中一个密切相关的概念称为“子实体”，其中行项目是订单的子实体。通常，子实体与其从属的实体具有强制性的子-父标识关系。

在经典数据库设计中，LineItems 表的主键是 (OrderNumber, ItemNumber)。今天的一些设计师会给一个项目一个单独的 ItemID，作为主键，并由 DBMS 自动递增。在这种情况下，我推荐古典设计。

---

Daniel Dinnyes' answer 的补充：

在非标识关系中，您不能将相同的主键列（例如“ID”）两次具有相同的值。

但是，对于标识关系，您可以让“ID”列的相同值显示两次，只要它具有不同的“otherColumn_ID”外键值，因为主键是两列的组合。

请注意，FK 是否为“非空”并不重要！ ;-)

---

假设我们有这些表：

user
--------
id
name


comments
------------
comment_id
user_id
text

这两个表之间的关系将识别关系。因为，评论只能属于其所有者，不能属于其他用户。例如。每个用户都有自己的评论，当用户被删除时，该用户的评论也应该被删除。

---

识别关系存在于两个强实体之间。非识别关系可能并不总是强实体和弱实体之间的关系。可能存在子实体具有主键但其实体的存在可能取决于其父实体的情况。

例如：卖方与书籍之间的关系可能存在，其中卖方可能有自己的主键，但仅在出售书籍时才创建其实体

基于比尔·卡尔文的参考

---