两个强大的实体之间存在着识别关系。非识别关系不一定是强实体和弱实体之间的关系。可能存在这样的情况：子实体本身具有主键，但其实体的存在可能取决于其父实体。

例如：卖家和一本书之间的关系，其中一本书正由卖家出售，卖家可能有自己的主键，但其实体仅在出售一本书时创建

基于Bill Karwin的参考

user287724的回答给出了以下书籍与作者关系的示例：

然而，一本书是由一位作者写的，而且作者可能已经写了多本书。但这本书需要作者来写，没有作者就不可能存在。因此，这本书和作者之间的关系是一种识别关系。

这是一个非常令人困惑的例子，绝对不是识别关系的有效例子。

是的，如果没有至少一位作者，一本书就无法写作，但这本书的作者（是外键）无法在图书表中识别这本书！

您可以从书本行中删除作者（FK），并且仍然可以通过其他字段（ISBN、ID等）来识别书本行，但不能识别书本的作者！！

我认为识别关系的一个有效示例是（产品表）和（特定产品详细信息表）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被视为FK引用products.ID表，同时也是printers_dedetails表中的PK，这是一种标识关系，因为printers表中的Product _ID（FK）正在标识子表中的行，我们无法从子表中删除product_id，因为我们无法再标识该行，因为我们丢失了它的主键

如果要将其分为两行：

识别关系是FK在当仍然引用父表

另一个例子可能是在某个国家/地区的进出口数据库中有3个表（进口-产品-国家）

导入表是具有这些字段的子表（product_id（FK）、country_id（FK）、导入数量、价格、导入单位、运输方式（空运、海运））我们可以使用（product_id，thecountryid`）来标识导入的每一行“如果它们都在同一年”，这里这两列可以一起组成子表（imports）中的主键，也可以引用父表。

拜托，我很高兴我终于理解了认同关系和非认同关系的概念，所以请不要告诉我，我对一个完全无效的例子的所有投票都错了

是的，从逻辑上讲，一本书没有作者是写不出来的，但是一本书如果没有作者是可以被识别的，事实上，它不能被识别为作者！

您可以从书本行中100%删除作者，并且仍然可以识别书本！。

对Daniel Dinnyes回答的补充：

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

但是，使用identifynig关系，可以为“ID”列显示两次相同的值，只要它具有不同的“otherColumn_ID”外键值，因为主键是两列的组合。

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

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

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

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

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

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

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

注意，身份依赖意味着存在依赖，但并非相反。每一个非NULL FK都意味着没有父级就不能存在子级，但这并不能使关系确定。

有关这方面的更多信息（以及一些示例），请参阅ERwin方法指南的“确定关系”部分。

补充：我意识到我参加聚会（非常）晚了，但我觉得其他答案要么不完全准确（用存在依赖而不是身份依赖来定义它），要么有些曲折。希望这个答案更清晰。。。

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

正如下面的链接中很好地解释的，识别关系有点像ER概念模型中的父实体的弱实体类型关系。用于数据建模的UML风格CAD不使用ER符号或概念，并且关系类型为：识别、非识别和非特定。

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

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

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