对Daniel Dinnyes回答的补充：

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

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

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

假设我们有这些桌子：

user
--------
id
name


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

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

这里有一个很好的描述：

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

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

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

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

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

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

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

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

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

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

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

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

如果您认为在删除父项时应删除子项，则这是一种识别关系。

如果即使父项已删除，子项仍应保留，则它是一个不可识别的关系。

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

学员与培训课程有明确的关系培训与培训课程有明确的关系但学员与文凭的关系并不明确

如果删除了相关的学员、培训或文凭，则只应删除培训课程。