非标识关系贡献父实体的键给子实体，但是，由定义知，一些 (或所有)键不变成子实体的键，意思是子不标识依赖于父，允许这样的情形，关系中”多”端的实体没有”父”而可能存在，即它不是存在依赖。
从子实体看，如果关系是强制mandatory的，那么子存在依赖于父。如果可选，那么子既不存在也不标识依赖于关系 (虽然它也许依赖于其他关系)。ERwin用菱形为表示可选的情况，菱形只存在于非标识关系中(因为标识关系贡献主关键字，而主关键字部分不能为NULL)。带菱形的非标识关系是”零或一对多”的关系。这儿有个简单例子。
图5.13，属性 “passenger-id”变成SEAT座位的外键属性，它不标识座位，它标识占用座位的乘客，因为没有乘客座位仍然存在，关系是可选的，应使用菱形符号。
Figure 5.13: One-to-many, non identifying relationship. 我们已经定义，在一次飞行中乘客可占零或一个座位。
座位可以空 (不被任何乘客占有)，当座位空时，”passenger-id”属性将是空 (NULL)。 由业务政策知道，这是允许发生的 (因为航空公司不能迫使乘客填满每次飞行的每个座位)，从子实体看，关系是可选的，关系父端的菱形就意味着这个。除菱形以外，非标识关系的基数符号与标识关系的相同。
递归关系
实体能参加递归关系 (也称 “捕鱼钩”)，同一个实体既是父也是子，任何递归关系必须是非标识的。
图5.14所示情形，公司被给看作是 “parent of”其他公司，和所有非-标识关系一样，父实体把键带入到子实体的数据区。
Figure 5.14: Example of a recursive relationship.
但是，注意发生的两件事件，第一，出现在数据区的键名字已被改变，而不是简单的”company-id”，而是”parent-id.company-id”，属性”parent-id” 是”company-id”的角色名。
属性不能以相同名字在同一个实体中出现两次，在规范化中这是错误的 (见第6章)。规范化的基本原则之一是如果两件东西有相同的名字，他们就是同一件东西。
公司的标识符”company-id”与”父的”公司标识符不是相同东西。它未被规定相同，虽然它来自相同域，但它将有不同的值 (它指不同公司)。定义和范例例子表将有帮助。
28
company-id: 公司的唯一标识符 parent-id: 上级公司的”company-id”，不是所有公司都有上级公司。
让读者来完善这些定义，如，概念\父”意味着?所有者?已启动的公司，倒闭的公司？更多的定义见第4章。
这儿有范例例子表格：
COMPANY company-id parent-id company-name C1 NULL Big Monster Company C2 C1 Smaller Monster Company C3 C1 Other Smaller Company C4 C2 Big Subsidiary C5 C2 Small Subsidiary C6 NULL Independent Company
Figure 5.15: Sample instance table for COMPANY.
从范例实例表中我们看到”Big Monster Company” 是”Smaller Monster Company\和 \Smaller Company.\的父。依次，\Monster Company,\是 \Subsidiary\和 \Subsidiary.\的父，\Company\不是其它公司的父，自己也无父，\Monster Company\也无父。
Figure 5.16: Company hierarchy.
当公司没有父时，前一框图中显示的菱形符号表示外来的键可以为NULL。递归关系也是可选的（菱形），或强迫的 (无菱形)。
为什么递归关系叫 \捕鱼钩\
5.3 多对多关系
考虑下列框图，第３章见过的，第４章中讨论定义的例子。 有关标题:
把多对多变成一对多关系 读多对多关系 N-ary关系
把多对多变成一对多关系
29
图 5.17显示人与地址之间的多对多关系，而且，它似乎说关系在两个方向标识。
Figure 5.17: Many-to-many relationship.
倘若我们简单地试着说那人 <使用>许多地址，地址 <被使用于>许多人，从概念上的观看，这没有错误。的确，在关系模型图(ERD)中允许出现，不用担心键。
多对多关系 (实线两端都是圆点)被称为不确定关系。
换言之，这种关系没有意义，如果我们对图5.13应用迄今为止已学到的有关标识关系，我们将发现人的键必须是地址的键的一部分，地址的键必须是人的键一部分。但是，地址由他们自己的键来标识，人也同样。成了死循环!
在正式标准中，IDEF1X不象其它一些模型语言，强调所有关系是二元的。如，他们确定地连接两个实体，这并不意味着三、四或 \个关系不需要，就只有这些情形被用来与其它结构充分地寻址------关联的实体。
无论如何，我们仍然需要记录多对多关系，如图3.10，让我们再一次更详细地看它。 我们已加叫地址-使用的联合实体，并把多对多关系转换成了两个一对多。
人的键 (\与地址的键(address-id)都移动到联合实体，这些不是唯一的地址-使用的属性，注意第三部分, \
Figure 5.18: Associative entity.
多对多关系时常隐藏意思，在图 5.17中，我们看到，人们使用许多地址，但我们不能看到他们是如何使用的，在完整结构的图 5.18中，我们能看到 \如何使用\，属性 \将告诉我们，为什么这个属性在键区域，而不在数据区？
再次，除非我们问业务规则，否则我们不能知道。如果每个人只能用一个地址于一个目的，那么\可放在数据区。但是，假定一个人用以多种用途来使用同一个地址时(如，邮寄地址、住宅地址)，如果\不在键区域，就不能记录信息，实例表有助于理解。
ADDRESS address-id address-detail A1 Princeton
30
A2 A3 A4 A5 New Brunswick Berkeley 1 Berkeley 2 New York City
PERSON person-id person-name P1 Ben P2 Margaret P3 Tom P4 John P5 Leon
ADDRESS-USAGE person-id address-id usage-type P1 A1 business P1 A2 residence P1 A2 mailing P2 A1 business P3 A1 business P3 A3 residence P3 A3 mailing P3 A4 mailing P4 A5 residence
Figure 5.19: Sample instance table for ADDRESS-USAGE.
为了讨论我们如此定义：
PERSON: 要记录的那些人 ADDRESS: 人们保持联系的地方 ADDRESS-USAGE: 记录地址用途
use-start-date 01 Jun 88 15 Sep 86 15 Sep 86 01 Jan 89 01 Feb 89 15 May 75 01 Jun 75 01 Mar 89 30 Sep 87
从例子中我们看到，Ben使用两个地址，普林斯顿和New Brunswick，他以两个不同的用途使用New Brunswick，即住址和邮件地址。汤姆与Berkeley情形相似。
如果 \不是地址-使用的主键的一部分，那么使用地址New Brunswick的Ben (P1/A2)就只有一个实例，那将意味着只有一个New Brunswick被记录，它是住址还是邮件地址？
你将时常查看实例例子表，以免设计不正确的模型结构，积极推荐使用实例来检验结构。
读多对多关系
让我们回到个人地址用途的例子（图5.18），要是读这个关系，我们会在此遇到麻烦。 对于模型者是个困难的选择，它们有两种方法来构造动词短语，要读图5.18 是困难的，除非通过关联实体来读到另一边实体的关系。如果你通过ADDRESS-USAGE来读，那么你能提出合理的语句：“An ADDRESS
有另一种格式，它相当正确，但更麻烦点。模型结构相同，但动词短语不同，以一种稍微不同的方式来读模型，如图5.20所示。
31
Figure 5.20:
如何读它？
\ \
注意，短语动词变得相当的长，按照我们的标准模式从父实体直接读到子实体。
当结构相当简单时，无论选择哪种格式记录多对多的动词短语都不困难。然而，当结构变得更复杂时，记录这种动词短语就更困难，有时候关联实体的一边与它自身关联，它们表
Figure 5.21: Three-way relationship. 示了另一种多对多的关系。
32