当你熟习本章描述的模型方法后，应用它们来读难读的模型，发展出自己的风格。
N-ary关系
我们已经讨论的所有关系都是二元关系，关系线准确地连接两个实体。此外，我已可能把多对多关系转化为两个一对多关系。我们如何表示三个或更多实体间的关系呢？
我们以类似于联合实体的方法来处理它，关系线不连接三个 (或更多)实体，而是把 \关系表示为一套联合实体的二元关系，考虑图5.21所示业务规则。
这里我们看到合同表示了公司、产品、消费者中的三路关系。结构表示多个公司卖多产品给多个消费者。
４路、５路关系可以用类似的方法来构造。
然而，当你看这样的关系时，有一些业务问题要问，例如，\产品在出售之前必须由公司提供吗？\，不同公司的产品可以只签一个合同吗？, \我们需要记录消费者 \属于\哪一个公司吗?\，根据这些回答，结构可能会改变。
例如，如果对第一个问题的回答是\是\，第二回答是\不\，我们必须把结构改成图 5.22。
Figure 5.22: Altered model construct from 5.21.
注意到现在的 \三-路\关系，已被两个２路关系代替。通过对这些业务问题的提问，你会发现，将\关系分解成一系列的2路关系是恰当的，”真正”的３路关系在IDEF1X模型中是少见的，４路、５路就更罕见。
5.4 角色名与申明
角色名是给属性的多个新名称。在第4章，我们看到，命名的角色属性与基本属性有着
不同的定义，角色名想要描述属性扮演的角色（目的）( 4.5节)。角色名也带有连接由角色名表示的实体实例标识的申明。
33
Figure 5.23: Rolename example.
请看NEGOTIATION-ASSIST，我们看到\的两个不同角色\和 \，这说明\职员与 \谈判\职员是有区别的，由于涉及两类不同的职员，要求标识每个属性，角色可为我们实现这个。
如来自不同关系的两个外键具有相同的名字，就要检查结构，可能有规范化错误，第６章讲述了规范化基础。
5.5 存在与标识依赖
5.5.1 关系描述与插入、替换、删除 (IRD)规则
我们已经学习了关系的几个方面，了解了基数(参与关系的每一个实体有多少个实例)、阅读模型的动词短语。关系记录的更重要的方面是插入、替换、删除 (IRD)规则，下列各节不是 IDEF1X语言的正式部分。
34
Figure 5.24: IRD example.
本例中，PROJECT 与 PROJECT-EMPLOYEE是标识关系，PROJECT 的键是PROJECT-EMPLOYEE主键的一部分，根据基数规则，PROJECT-EMPLOYEE的每一个实例都有一个PROJECT实例与之对应，标识关系自然明确地记载了PROJECT-EMPLOYEE存在依赖于PROJECT。
如果我们删除PROJECT的实例会怎么样呢？
为什么，我们将也不得不全部删除PROJECT-EMPLOYEE中相应的实例？因为部分主键将会变成NULL，而这又是不允许的。
5.5.2 删除规则
如此我们有两种选择：或者删除PROJECT-EMPLOYEE中与已删除PROJECT实例对应的全部实例；或者只要具有不完全主键的PROJECT-EMPLOYEE中存在着对应于PROJECT的实例，就禁止删除PROJECＴ。这种与删除规则相关的情况叫级联cascade和限制restrict。被记录在模型中。
级联表示受PROJECT实例删除影响的所有PROJECT-EMPLOYEE实例也应被删除，限制表示只要在PROJECT-EMPLOYEE中有与PROJECT对应的实例存在，就不能删除PROJECT。
为什么我们要限制删除?原因之一是了解PROJECT-EMPLOYEE其它因素，如项目\项目启动日期，除了限制删除外，如果我们决定PROJECT-EMPLOYEE不存在或标识依赖于PROJECT，我们就可以通过在这两个实体间使用非标识依赖关系来改变参照完整限制。
Figure 5.25: Example with non-identifying relationship.
在这种情况下，IRD稍微有点不同，通过非标识关系贡献的外键允许为NULL（记得菱形吗？），这样对非标识关系我们有第三个选择，设置NULL。设置NULL表示，当PROJECT中的某个实例被删除时，PROJECT-EMPLOYEE中与这个实例对应的值设置为NULL，在前面的例子中，我们不级联删除，同时也不限制删除，而是设置为NULL。这种方法的优点是既保留了PROJECT-EMPLOYEE中的信息，又不严重破坏PROJECT-EMPLOYEE与
35
PROJECT的关系。
5.5.3 插入与替换规则
IRD规则记录业务规则的附加方法，决定使用级联或设置NULL，反映了维护历史信息的业务决策。
正如我们已经看到的，删除规则决定了表中的一行数据被删除时数据库的反映，插入和替换规则决定了当数据行被插入或改变时数据库的反映，插入和替换规则被明确地在模型中说明，它们通过关系类型本身来说明。
插入，只当所有引用的外键与引用表中已存在的数据行匹配时，一行数据才能被插入，除非关系明确地被说明为别的关系（如非标识关系）。在效果上，替换与插入应用现样的规则。
让我们看例子，在MOVIE / MOVIE-COPY电影/电影-拷贝图中，MOVIE-COPY保存有MOVIE相应的键，因此，我们不能在MOVIE-COPY中插入MOVIE中没有的电影。关系中的\也告诉我们，不能插入MOVIE电影之外的MOVIE-COPY电影-拷贝。
Figure 5.26: Example for insert and replace rules.
6 标准化
6.1 介绍
规范化的目标是保证只有一种了解 \事实\途径，规范模型的过程是删除所有模型结构中那些提供多种途径来了解相同事实的模型结构，另一个方面，是作为控制的方法，消除数据存储中的冗余。
规范化的目标的口号是：ONE FACT IN ONE PLACE! 为了规范化原理的基本了解，我们将使用一些有设计问题的例子，规范化是设计好数据库的一个重要组成部分。
6.2 普遍问题
36
6.2.1 重复数据组
图6.1中有些错误，你能看出来吗？
Figure 6.1: Employee entity.
实例表如下：
EMPLOYEE Emp-id emp-name emp-address children's-names E1 Tom Berkeley Jane E2 Don Berkeley Tom, Dick, Donna E3 Bob Princeton ------ E4 John New York Lisa E5 Carol Berkeley ------
Figure 6.2: EMPLOYEE instance table.
问题出在\。
在实体和属性的讨论中，我们说所有名称必须是单一的，明摆着问题是\我们需要记录多少个孩子的名字?\，\名字列要预留多少空间?\，\如果预留的空间超出了怎么办？\
这个设计违反了第一范式，第一范式是设计\外形\的基本定义，即数据的行和列组成一个在任何单元中没有嵌套结构的二维表格，数据库中每一个数据值必须是原子的，没有列表、重复元素或内部结构。
为了修正上面的设计，我们必须知道怎样删除孩子的名字列表。方法是把这个非一范式的实体转换成图6.3所示的结构，现在我们就孩子的名字表示为单个的实体了。(根据职员物理记录结构，就可以决定分配空间的问题，如为没有孩子的职员浪费空间问题，相反，也能决定给那些有孩子的职员分配多少空间)。
Figure 6.3: Altered model construct from Figure 6.1.
EMPLOYEE
37