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

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

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

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

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

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

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

比尔的回答是正确的，但令人震惊的是，在所有其他答案中，没有人指出最重要的方面。

人们一再强调，在一种确定的关系中，没有父母，孩子是不可能存在的。（例如用户287724）。这是真的，但完全没有抓住重点。外键为非空就足够了。它不需要是主键的一部分。

因此，真正的原因是：

识别关系的目的是，外键永远不会更改，因为它是主键的一部分。。。因此识别！！！

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

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

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

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

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

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

非标识关系意味着父表的存在不标识子表。

示例accountType和account.accountType表未标识为存在科目表。

假设我们有这些桌子：

user
--------
id
name


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

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