在高层次的模型中，如何决策取决于有多少类共享公共属性，如果全都共享，移动它们，如果只有少数类共享，最好是不移动；在低层次的模型中，取决于目的，经常是不移动。
例如，在图5.5中，余额仍然留在类中，根据定义我们把其余的属性留在类中。
Figure 5.5: Completed account example.
完全与不完全分类结构
用不同的符号来标记类属父的类集合是否是完全的，图5.6表示不完全结构(也许还有没发现的其它类)。这里我们看到，EMPLOYEE 职员或者是顾问CONSULTANT或者是专职职员FULL-TIME-EMPLOYEE，类符号底部的单线表示也许还有其它没有包括的类。
Figure 5.6: Incomplete category structure.
图5.7表示一个完全结构，在这里职员EMPLOYEE要么是男职员MALE-EMPLOYEE，
23
要么是女职员FEMALE-EMPLOYEE。
Figure 5.7: Complete category structure.
图5.8显示完全与不完全类的结合，职员EMPLOYEE是FULL-TIME-EMPLOYEE 专职职员或顾问CONSULTANT。同时，也是男职员MALE-EMPLOYEE 或女职员FEMALE-EMPLOYEE。
Figure 5.8: Example with a combination of complete & incomplete structures.
图5.9继续扩展这个结构，在专职职员FULL-TIME-EMPLOYEE下增加类BENEFIT-ACCOUNT。
24
Figure 5.9: Example with many combinations of complete & incomplete structures.
何时形成概括分层结构
小结，形成概括分层结构有如下三个理由：
? 实体共享公共属性集，上面的例子就是这种情况。 ? 实体共享公共关系集，我们尚未探索这种，但是，当需要时，将引用于帐户结构中，
收集类实体已有的共有关系，把它们放入单个关系中。例如：如果我们发现每类帐户的结构都与许多消费者CUSTOMER关联，那么我就在帐户ACCOUNT级建立单个关系(到多个CUSTOMER)，从单个类中消除独立的关系。
? 如果业务需要，在模型中应展示实体的类（通常是为了交流或理解的目的），即使
类没有不同的属性、参加在不能区分其它类的关系中。记住模型的主要目的之一是有助于信息结构的交流，然而，小心不要做得过火，在详细的类结构网页中，全面公开模型意义。
更多属性
假定我们想在上述例子中增加消费者的名字，除了帐户编号之外，还想通过消费者的名字来查寻帐户，就要建立如下模型：
25
Figure 5.10: Entity with an inversion entry. 注意”customer-name”属性后面的(IE1)。
转置实体属性
转置入口表示访问数据的附加方法，是一个或一组用于访问数据的普通属性，但不能精确查找一个实例。如，上面的”customer-name”就是这样一个属性，通过”customer-name”可以得到０，１或多个帐户ACCOUNT（注意：也许有一个以上的约翰史密）。
有关标题: 倒转入口符号
导出属性
导出属性是来自其它属性的计算机项(如，合计)，并且不需要保存。如第６章将见到的，在模型中记录的导出属性是规范化错误，规范化的目标是保证只有一种方法来了解数据库中记录的每个事实。如果我们知道导出属性的值，也知道导出算法以及用于该算法的属性值，那么就有知道事实的两种方法（查找导出属性的值，或计算）。如果我们用两不同方法来获得答案，就有可能两个答案不同。
例如，假如我们记录了职员的”出生-日期birth-date ”和”年龄age”，并假设”年龄age”属性只能在当月末的维护工作改变。然后，当我们问, “某某职员多大?”的问题时，我们可以直接访问 “年龄”来获得答案，或我们可用 “今天的-日期”减”出生-日期”得出答案，如果我们用减法，那么将总是获得正确答案，如果 “年龄”最近尚未更新，它就会给我们一个错误答案，并且将总是存在着潜在的相矛盾答案。
在模型中记录导出数据有意义的情形是，计算数据的代价是昂贵的。虽然建模理论说绝不要包含导出数据 (我们主张你保守地这样做)，但当你必须打破规则时，至少记录导出属性的事实，同时陈述导出算法。
5.2 关系类型与基数
关系携带大量的信息，一些可以说是信息模型的心脏，在很大程度上，他们描述业务规则和参照完整性限制。
有关标题: 基数
关系类型细节：一对多，标识 一对多，非标识 递归关系
基数
26
关系有一个叫做基数的特性，定义了每个参与实体可以或必须有多少参加。基数语句表示父实体中有”多少”实例与子实体的”多少”实例连接。
图形中，在关系符号的点附近显示基数。
Figure 5.11: Cardinality notation.
在键-基本和完全-属性模型中，所有关系都是 “(零或)一”，任何多对多关系必须分成两个一对多关系。这些模型在第7章讨论。
关系类型细节：一对多，标识
在第２、３章中，我们见过许多标识关系，现看图3.8，电影 /电影-拷贝例子。图5.12重复的这个图，稍微有些不同。
Figure 5.12: One-to-many identifying relationship.
在这例子中，电影-拷贝不能被标识，除非电影的标识被知道( “电影-编号”)，由ERwin支持关系模型基本原则之一是：如果实体的实例不能被标识，那么实例就不存在。电影-拷贝是存在依赖电影。
基数所陈述意思是，关系上不带点的一端是确定的一部电影，电影-拷贝端(带点端)怎么样?
在我们的视频商店中，我们把电影-拷贝定义为原带的几个复制品中的一个，业务规则说电影必须有一非零(一个以上)的复制份数，简而言之，”available as”是一对一或多的关系。点附近的”P”符号说明了这个关系，在这个数据库中，电影没有拷贝不是合法的业务对象。
然而，假如我们要为不同的视频商店构造模型，且该商店对跟踪有不同政策，他们关心世界上的所有电影，甚至那些他们没有拷贝的电影。如此，他们的业务规则是对存在的电影（记录在信息系统中）不一定需要拷贝。
要记录这个业务规则, “P”被删除，变成一对零或多的关系。
(如你所了解的，通过标识关系贡献键给子实体对更直接的物理系统查寻是有利的，但还有许多不利之处，一些高级关系理论建议键的贡献不要以这种方式发生，相反，每个实体不仅仅由它拥有的主关键字来标识，而且系统的用户绝不会见到逻辑编号或代理键，该理论请见E. F. Codd and C. J. Date的评论)。
一对多，非标识
27