标识关系指定子对象不能不存在父对象

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

如果父级不是，则可以将非标识关系指定为可选关系通过设置父表基数。。。

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

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

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

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

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

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

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

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

标识关系指定子对象不能不存在父对象

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

如果父级不是，则可以将非标识关系指定为可选关系通过设置父表基数。。。

对Daniel Dinnyes回答的补充：

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

但是，使用identifynig关系，可以为“ID”列显示两次相同的值，只要它具有不同的“otherColumn_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