我无法完全掌握这些差异。你能描述这两个概念并使用现实世界的例子吗？
【问题讨论】：
标签： database database-design data-modeling identifying-relationship
标识关系是指子表中的行的存在依赖于父表中的行。这可能会让人感到困惑，因为如今为子表创建伪键是一种常见的做法，但不将外键设置为子表主键的父部分。形式上，“正确”的做法是让外键成为子主键的一部分。但逻辑关系是，没有父母，孩子就无法存在。
示例：Person 有一个或多个电话号码。如果他们只有一个电话号码，我们可以简单地将其存储在Person 的列中。由于我们要支持多个电话号码，我们创建了第二个表PhoneNumbers，其主键包括引用Person 表的person_id。
我们可能会认为电话号码属于某个人，即使它们被建模为单独表格的属性。这是一个强有力的线索，表明这是一种识别关系（即使我们没有在 PhoneNumbers 的主键中真正包含 person_id）。
非标识关系是指父级的主键属性不得成为子级的主键属性。一个很好的例子是查找表，例如Person.state 上的外键引用States.state 的主键。 Person 是相对于 States 的子表。但是Person 中的一行不是由其state 属性标识的。 IE。 state 不是 Person 的主键的一部分。
非标识关系可以是optional或mandatory，这意味着外键列分别允许NULL或不允许NULL。
另见我对Still Confused About Identifying vs. Non-Identifying Relationships的回复
【讨论】：
Beds 表以获取特定建筑物中的所有床位，而无需进行 any 连接。
user_id 本身应该是主键，updated_by 不是多列主键的一部分。
现实世界还有另一种解释：
一本书属于一个所有者，一个所有者可以拥有多本书。但是，这本书也可以在没有所有者的情况下存在，并且它的所有权可以从一个所有者变为另一个所有者。图书与所有者之间的关系是一种非识别关系。
然而，一本书是由一个作者写的，而这个作者可能写了多本书。但是，这本书需要由作者撰写——没有作者，它就无法存在。因此，书与作者之间的关系是一种识别关系。
【讨论】：
PK(Book.id, Book.person_id).
the Identifying relationship 的有效示例！！！是的，没有作者就不能写一本书，但是，books 表中的作者字段是 NOT IDENTIFYING 书行！！！
Bill's answer 是正确的， 但是震惊地看到在所有其他答案中没有人指出最重要的方面。
人们一遍又一遍地说过，在识别关系中，没有父母，孩子就无法生存。 （例如user287724）。这是真的，但完全没有抓住重点。外键为 non-null 就足够了。它不需要是主键的一部分。
这才是真正的原因：
识别关系的目的是外键永远不会改变，因为它是主键的一部分...therefore正在识别！！！
【讨论】：
标识关系指定子对象不能 没有父对象而存在
非标识关系指定常规关联 对象之间，1:1 或 1:n 基数。
在没有父级的情况下，可以将非标识关系指定为可选的 在需要父母的情况下，通过设置 父表基数...
【讨论】：
House 有 Walls。你把房子拆了，你就没有墙了。但一堵墙只属于一所房子。所以做强关系是行不通的：PK(Wall.id, House.id) 将允许您将同一面墙插入到另一个房子的模型中。
House_Wall 表的原因是为了识别房屋内的墙。是识别关系。 House_Wall 表类似于PK(House.id, wall_number), FK(Wall.id)。 wall_number 是房屋中的一个序列，如果没有 House.id，它就不是唯一的。如果你想像PK(Wall.id, House.id) 那样建模并且Wall.id 必须是唯一的，那么将Wall 表中的House.id 作为FK 就足够了。它只是试图为不同的事物建模。
这是一个很好的描述：
两个实体之间的关系可分为“识别”或“非识别”。当父实体的主键包含在子实体的主键中时，存在标识关系。另一方面，当父实体的主键包含在子实体中但不作为子实体主键的一部分时，则存在非标识关系。此外，非识别关系可以进一步分类为“强制性”或“非强制性”。当子表中的值不能为空时，存在强制的非标识关系。另一方面，当子表中的值可以为空时，存在非强制性的非标识关系。
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（它的外键）是不能识别book在books 表中！
您可以从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 和 printers_details 表中的 ALSO PK，这是一种识别关系，因为打印机表中的Product_ID(FK) IS IDENTIFYING 子表中的行，我们无法从子表中删除product_id，因为我们无法再识别该行因为我们丢失了它的主键
如果你想把它放在 2 行中：
识别关系是当 FK 在 子表被视为子表中的 PK（或标识符），而 仍然引用父表
另一个示例可能是当您在某个国家/地区数据库的导入和导出中有 3 个表（进口 - 产品 - 国家）时
import 表是具有这些字段的子表（product_id(FK)、country_id(FK)、进口量、价格、进口单位、运输方式（ air, sea) )
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 之间也是如此。
【讨论】：
如果认为在删除父项的同时也要删除子项，那么这是一种识别关系。
如果即使删除了父项也应该保留子项，则它是非标识关系。
例如，我有一个包含受训者、培训、文凭和培训课程的培训数据库：
如果删除相关学员、培训或文凭之一，则仅应删除培训课程。
【讨论】：
就像下面链接中很好解释的那样，识别关系有点像 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 的“识别关系”部分。
附：我意识到我参加聚会（非常）迟到了，但我觉得其他答案要么不完全准确（根据存在依赖而不是身份依赖来定义它），要么有点曲折。希望这个答案能提供更多的清晰度......
1 孩子的 FK 是孩子的 PRIMARY KEY 或（非 NULL）UNIQUE 约束的一部分。
【讨论】：
标识关系是指子实体完全依赖于父实体的存在。
示例一个账户表person表和personAccount。person账户表只通过account和person表的存在来标识。
非标识关系是指子表不通过父表的存在来标识。
示例作为 accountType 和 account.accountType 表的表不被标识为 account 表的存在。
【讨论】：
订单处理就是一个很好的例子。来自客户的订单通常具有标识订单的订单号、每个订单出现一次的一些数据（例如订单日期和客户 ID）以及一系列行项目。每个行项目包含一个项目编号，用于标识订单中的行项目、订购的产品、该产品的数量、产品的价格和行项目的金额，可以通过将数量乘以价格。
标识订单项的编号仅在单个订单的上下文中标识它。每个订单中的第一个行项目是项目编号“1”。行项目的完整标识是项目编号及其所属的订单编号。
因此，订单和订单项之间的父子关系是一种识别关系。 ER 建模中一个密切相关的概念称为“子实体”，其中行项目是订单的子实体。通常，子实体与其从属实体具有强制性的子-父标识关系。
在经典数据库设计中，LineItems 表的主键是 (OrderNumber, ItemNumber)。今天的一些设计师会给一个项目一个单独的 ItemID，作为主键，并由 DBMS 自动递增。在这种情况下，我推荐古典设计。
【讨论】：
在非标识关系中，您不能有两次具有相同值的相同主键列（比如“ID”）。
但是，通过标识关系，您可以让相同的值在“ID”列中显示两次，只要它具有不同的“otherColumn_ID”外键值，因为主key 是两列的组合。
请注意，FK 是否为“非空”并不重要！ ;-)
【讨论】：
假设我们有这些表：
user
--------
id
name
comments
------------
comment_id
user_id
text
这两个表之间的关系将识别关系。因为，cmets 只能属于它的所有者，不能属于其他用户。例如。每个用户都有自己的评论，当用户被删除时，该用户的cmet也应该被删除。
【讨论】：
识别关系是两个强实体之间的关系。非识别关系可能并不总是强实体和弱实体之间的关系。可能存在子实体具有主键但其实体的存在可能取决于其父实体的情况。
例如：卖家与书籍之间的关系可能存在，其中卖家可能有自己的主键，但只有在出售书籍时才会创建其实体
参考比尔·卡尔文
【讨论】：