数据模型资源手册阅读笔记

第一章 绪论

1.1 本书议题

　　许多组织在开发他们的数据模型或者数据仓库的时候，很少会去参考一些外部资料。要么雇佣一些有经验的顾问，要么让内部员工去开发系统设计中的这个关键部件。通常，市面上并没有针对性的参考资料，以供公司对他的数据模型或者数据仓库进行检验、或者从中寻找可选的数据库结构。

　　一个明显的结论是，通常有50%以上的（全局的或者逻辑的）数据模型都是由适用于多种组织机构的通用构件组成，有其他25%的数据是行业特殊的，平均起来，约有25%的企业数据模型是只有该企业才有的。

1.2 读者对象

　　数据管理员、数据建模人员、数据分析师、数据库设计人员、数据仓库管理员、数据仓库设计人员、普通数据管理员、企业数据 集成人员或者其他任何需要分析或者集成数据结构的人员。系统专业人员可以使用该书中包含的数据库构件以提高生产效率，并将其作为检查设计质量的参照点。

1.3 对通用数据模型的需求

　　自关系理论模型建立以来，数据建模已经成为用于数据库设计的一个标准方法。通过对一个组织机构的数据进行正确的建模，数据库设计人员可以消除数据冗余问题，而冗余是导致不准确信息和低效率系统出现的一个关键因素。

　　数据建模问题是众所周知和应用广泛的用于有效地进行数据库设计的方法。因此，为企业（本文中的企业指代需要开发模型和系统的组织机构）提供标准模板，使它们能对他们的数据模型进行优化和定制，而不需要从头做起，在这方面是有很大的需求的。

1.4 系统开发的全局方法

　　建立富有效率的一个最大挑战是集成。在企业内部，各个系统通常是在不同的时间段上各自独立的建立起来的，以满足不同的需求。企业要建立许多系统：合同管理系统、销售订单系统、项目管理系统、财务系统、预算系统、购买订单系统以及人力资源管理系统，这些都还只是一部分。

　　如果系统是以各自独立的形式建立的话，则需要为每一个系统建立独立的信息存储，这些系统中的多数都将使用有关企业、人、地理位置或者产品的共同信息。这就意味着，每一个独立的系统蒋建立和使用它自己的信息源。采用这种方法会带来一个巨大的问题，既要维护准确、又要及时更新新的信息，几乎是不可能的，因为同一类信息以冗余的方式存储在多个（子）系统之中。对于一个大型的组织机构来说，有关客户、员工、组织机构、产品和地理位置的信息存储在许多独立的系统中是非常常见的。

　　以没有集成数据结构的方式建立独立系统的另外一个缺点是企业（正在对模型和系统进行设计的组织）无法享受到以集成的方式查看数据的好处。

　　系统开发的另外一个有效途径是从企业的各个系统是互联的这个角度出发，建立一个企业范围的架构以使得各（子）系统能更有效地协同工作，能带来巨大的好处。这个架构的组成部分应该包括一个全局数据模型（即企业数据模型），这个模型能够协助企业维护他最有价值的资产：信息。因为可能每一个系统或者应用都使用类似的有关人员、机构、产品和地理位置的信息，因此共享的信息体系结构的价值是无法估量的。

　　信息行业认识到集成式设计的需要，从而促进了许多企业数据模型和企业数据仓库建模工作的展开。CASE（计算机辅助系统工程）工具，可以帮助建立模型的文档，但是并没有减少开发一个好的数据模型所需要的时间。

　　数据仓库，可以为经理们提供他们所需要的信息，而不需要企业数据模型建模所需要的时间和开销方法。企业现在直接从他们的操作型系统中抽取出他们所需要的各种不同的信息，以建立决策支持系统。

　　这种方法存在的唯一问题是同一个问题。首先，数据仓库中的所有信息都需要从几个不同、不一致的数据源中抽取出来。如果客户信息被保存在不同的地方，那么哪个系统代表了最准确的信息源呢？（数据不一致和时效性问题）

　　基于数据仓库原则，转换用的例行程序负责对数据进行一致性协调和清理。如果不同的部门针对不同的数据具有不同的需求，那么，每个部门或许都会以操作型系统为数据源建立它自己的抽取程序。一个部门可能会使用一种算法对信息进行转换；另一个部门则可能采用另一种算法。例如：如果两个部门都在抽取销售分析信息，一个部门或许会使用订单记录系统作为她的数据源，而另一个部门或许将他的发票系统作为它的数据源。高层管理可能从两个数据仓库中都查看了信息，然后发现了不一致的结果。这样就对信息产生了怀疑。在建立更多的数据片段以后，这种情形实际上会使得数据源很多这个问题变得更为复杂。

　　要建立一个可以提供良好的、准确的信息集成系统。最有效的方法是理解一个企业内部数据结构和关系是如何结合起来的，并且要理解如果才能以一种全局集成的方式看到数据。为了能建立有效的系统，有必要去理解数据的特性。通过建立通用的、可重用的数据结构，IS（信息服务）群体就可以的得到结果，并且向既能在事务处理环境也能在数据仓库环境中建立集成的结构迈进。

1.5 约定和标准

　　对标准模型的命名标准和图表的约定包括以下内容。分别有实体、子类、属性、关系、外键、物理模型和图示表格的相关说明。

1.5.1 实体

　　实体是一个重要概念，企业希望建立和存储的信息都是关于实体的信息。例如：订单表示一个实体，其中存储当事人之间购买货物的相关信息。一个句子中用实体的名字可以用于表示概念和业务规则。

　　实体的命名习惯是尽可能使用能很好反映所维护信息的意义的单数名词。如果实体代表的是一类信息，则在实体的名称前面加上后缀TYPE（类型），例如order type（销售和购买订单），而不是实际事物中的一个具体实例，例如一个订单（order #111000）。

　　一般数据模型在图表中包含了类型实体，这么做的目的是保证模型的完备性，并且用于表示属性值域或数据查询范围的存储处。如果企业需要维护某个实体中所包含的信息，则需要在数据模型中包含这个实体。

1.5.2 子类和超类

　　子类，是一类具有与更一般实体相同的特征的实体，具有共同的属性或者关系。例如：女孩子是女性的一个子类，法定组织和非正式组织是实体组织的子类等等。

　　在数据模型图中，子类表示在其它实体之中。子类间的共同属性和关系在实体之外表示，外部的实体类被称为超类。子类将继承父类的属性和关系。父类可能有很多层。如下图所示：

 

　　一个实体内的各个子类必须代表一个完整的分类集合（子类之和完全的覆盖父类），同时各个子类彼此之间必须是互不相交的。在许多情况下，数据模型中会包含一个其它......子类，用于表示实体的其他可能分类，采用这个模型的企业可能会对这个分类进行明确的定义。例如：非正式组织可能是家庭、个人、团队或者其它非正式组织。

　　有时，子类之间并不是非互斥的；换句话说，可以采用不同的方式将父类划分为不同的子类，这样对于同一个父类，可以得到多个不同的子类。实体需求可以以不同的方式进行子类划分。例如需求可能是源自一个客户（客户需求），或者代表企业内部的一个需求（内部需求）。同时，需求也可能是用于表示特定产品的需求（产品需求），或者用于表明需要做的工作（工作需求）。

1.5.3 属性

　　属性保存着关于一个实体的特定信息条，例如一个人的姓名，一个订单的订购日期。

　　属性可以是实体的唯一标识（主键），也可以是其他强制的或者任选的属性。

1.5.4 关系

　　关系定义了两个实体之间相互关联的方式。

　　1. 关系任选性

　　关系可以是任选的，也可以是强制的。从一个实体连向下一个实体的虚关系线条表示从那个实体到下个实体的关系是任选的，二连续线表明关系是强制的（对于每个实体的所有实例都必须具有这个关系）。例如，每个装运必须从一个而且只有一个邮政地址装运而来。这表明必须说明买个装运的邮政地址，以建立一个装运实例。当从另外一个方向看同一个关系的时候，这个关系却有任选性的一面：“每个邮政地址可以是一个或者多个装运的来源”。因此，有可能存在还没有用于装运的邮政地址。

　　2. 关系的基数

　　关系可以是一对一的、一对多或者多对多的。一般将这个称之为关系的基数。乌鸦脚型（一个三叉戟形状）表明了一个实例是否与另外一个实体中的多个实例相对应。例如，一个订单必须由一个或者多个订单条目构成，因为三叉线在订单条目那一端。关系的另一端也表明，“每个订单条目都必须是一个也只是一个订单的一部分”。一对一的关系中没有三叉线，多对多的关系则在两端都有三叉线。一对多关系也成为父-子关系。

　　如果在关系中加入术语“随时间变化”以表明该关系是否具有一对多关系。例如一个订单可能看上去只有一个订单状态；然而，如果需要具有状态历史，则每个订单必须在不停的时间上处于一个或者多个订单状态。

　　多数情况下，一对一关系可以通过规范化方式组合在一起，合到一个实体中去。多对多的关系可以分解成交叉实体。

　　3. 外键关系

　　外键定义为一个实体（或表）中出现的另外一个实体（或表）的主键。例如，订单实体中订单标识是实体订单条目的一部分。这个关系标识他是一个外键。任何一个一对多的关系都表明，在关系“一”的那端的实体的主键将被带到关系的“多”那一端的实体中。有时外键也可以作为实体的一个属性表示出来。

 

第二章 人与组织

　　最常见的业务信息需求是针对人和组织提出的一些问题，并且能针对这些问题给出准确的、可信赖的回答。几乎所有的业务应用堵要求记录有关人和组织的信息，如客户、供应商、子公司、雇员和承包商（加工商）等，这些信息在许多不同的系统中是冗余的。因此，确保客户联系方式等信息的一致和准确是非常困难的。有关人和组织的信息可能用于销售、市场、采购、订单处理、发票、项目管理和财务中。

2.1 组织

　　大多数数据模型将组织信息放在多个不同的实体中，这些实体被描述为完全独立的实体。例如，可能会有一个客户实体，一个供应商实体以及一个部门实体。企业中的每个应用都有他自己的需求，因此数据模型经常是以一个特定应用的需求为基础进行构造的。例如，在创建一个订单处理应用系统时，客户信息是至关重要的，因此数据模型建模人员为客户设置了一个独立的实体。与此类似，在创建一个采购应用系统时，供应商信息是至关重要的，于是数据模型中通常有一个供应商实体。对于人力资源系统来说，数据模型建模人员可能给出一个叫部门的、雇员在其中工作的实体。

　　问题在于，一个组织在不同环境中可能会扮演不同角色。例如，内部组织之间存在销售活动。资产管理科可能是产品销售科的一个供应商。资产管理科可能也同时是产品销售科的一个客户。在这种情况下，通常对每一个科都会有一个供应商记录和客户记录，当然还可能存在许多其它类型的记录。

2.2 人员

　　大多数数据模型将不同类型的组织表示为不同的实体。不同类型的人员例如雇员、客户、签约人、供应商联络员、客户联络员等表示为不同的实体。将这些信息放在不同实体中所产生的问题是，人也会有随着时间变化的任务和角色。多数系统都会记录冗余的关于人员的信息，因为，在人员的角色发生一次变化的时候，他们存储着一条记录。

　　另一个问题是一个人可能同时拥有几个不同的角色。例如：WY是一个有好几个分支机构的大公司。张三是运输科的雇员和经理。他还被看作是供应科的客户。与此同时，他还是出版科的供应商，后者需要他传递目录。因此，张三是一个科的雇员、另一个科的客户以及第三个科的供应商。不应该为张三存储三条具有冗余信息的记录，而应该只用一条记录。

　　为了解决问题，下图显示了一个存储特定人员信息的人员实体，该实体与人员的职务或角色无关。人员实体的属性用来描述人员，可能包括现名、曾用名、别名、性别、生日、身高、体重和其它在列的属性。

【欠图】

2.3 当事人

　　组织和人在许多方面是类似的。两者都具有一些共同特征来描述他们，如信用等级、地址、电话号码或者电子邮件地址。组织和人也可以扮演类似角色，如合同当事人、购买者、销售者、责任人和其它组织的成员。例如，在成员关系组织（如一个计算机用户小组）中，它所保存的公司用户信息好人员用户信息可能是类似的。联络员通常可以将组织和人员都视为联系方。一个销售订单的客户既可以是组织，也可以是人员。

　　如果人员和组织是以完全独立的实体形式进行建模的话，数据模型将变得更为复杂。每一个涉及到人员或者组织的合同、销售订单、成员关系或者事物都会需要两种关系：一个是关系到人员实体的，另一个是组织实体的。还有，这些关系是互斥的，因而还需要一个互斥弧。例如，销售订单可能是人员或者组织发出的，但是一个销售订单不可能在同一个时刻既由一个人员又由一个组织发出。

　　一个当事人的超类，可以拥有两个子类人员和组织。

　　当事人类别实体存储当事人可额能隶属的不同类别，可以通过使他对当事人进行分类。其中，组织类别有行业类别、规模类别和少数类别等子类型；人员类别有EEOC类别和收入类别等子类型。如果你希望建立更精确的模型，可以将组织类别和人员类别分别联系在一起。为了简化起见，他们都被看做与当事人联系在一起的当事人类别。

　　少数类别的实例包括“少数民族企业”、“8A企业”、或者妇女企业。行业类别可能包括“通信业”、“政府机构”或者“制造业”。规模类别可能是“小型”、“中型”、“大型”、“全国型”或者“全球性“，也可以通过所雇佣人员的数量来进行分类。对于人员，EEOC类别中可能包括诸如“非洲裔美国人”、“美国原住民”、“亚裔或太平洋各岛屿住民”、“西班牙裔”和“费西班牙裔白种人”等值。收入类别中可能包括反映人员年收入的值，如“低于20000元”、“20000 - 50000元”、“50000 - 210000”和“超过210000元“等值。

　　这些当事人的分类可用于确定是否对当事人实行特殊的业务政策，如根据当事人的类型实行特殊价位或者应用特别条款。将业务归入不同行业类型也是一种划分市场、明确市场目标的方法。因为当事人类型可能随时间变化，所以当事人实体中还包括起始日期和终止日期，使得这些变化可以被保存起来。

2.4 当事人角色

　　一个人员或者组织可能扮演任意数量的角色，如客户、供应商、雇员或者内部组织等。由于同一个当事人可能同时或者在不同时间扮演多个不同角色，所以就需要对每个角色的信息进行定义。当事人实体定义了当事人的本质特性，这些特性不会随时间变化而变化的。当事人类型蒋当事人划分为特定类别。当事人角色实体定义了当事人如何行为。换句话说，它定义了当事人在企业环境下扮演的角色。当事人的某些特定信息可能只适用于某一个特定角色。例如信用信息可能只适用于客户，因此他只是这个角色的关系或者属性。某些关系可能只适用于特定角色。例如，雇佣实体中的关系“开始日期”和“起始日期”只属于雇员这一角色。

　　这些角色是否只是当事人实体的子类型？例如，客户和供应商是否是当事人实体的子类型？或者，他们应该是当事人角色的子类型，以用来表示一个当事人可以同时是客户和供应商？

　　不管是用那种方式，重要的是应该认识到：除了当事人实体以外，这些角色如客户、供应商、雇员和内部组织也是需要被记录的实体。当事人可以使得企业一次性地记录有关人员和组织的一致信息。而当事人角色可以使得企业可以维护每个当事人在担当特定角色时的信息（属性和关系）。例如，不管一个当事人在企业中扮演多少角色（可能是客户、供应商和代理），他可能有许多不同的联系信息（家庭住址、办公室地址、家庭电话、手机号码等等）。对于客户这个当事人角色，并且只针对这个角色，存储信用等级信息可能就是最重要的。

　　既可以是人也可以是组织的通用角色是客户，客户是一个曾经从企业购买（付款客户）、装运（运达客户）或者使用（最终客户）产品（货物或者服务）的当事人。股东既可以是人又可以是组织，因此它既不是人员角色或者组织角色。潜在客户也是如此，他是被企业任务将会购买、装运或者使用它们产品的个人或者组织。

2.4.1 组织的角色

　　组织的角色包括分销渠道（如分销商和代理商）、竞争对手、合作伙伴、管理机构、住户、协会、供应商、各种组织单位（如上级组织、分公司、部门、分支机构、其它组织单位）以及内部组织（它表明一个组织究竟是企业的一部分还是外部组织）。

　　分销渠道是对企业的产品进行市场营销的组织。代理商在进行营销活动时不购买产品，分销商则通常在进行营销活动时首先购买这些产品，然后再销售。竞争对手拥有同本公司类似的产品，而且可以对其经营状况进行比较分析。合作伙伴被认为是同盟组织，同本公司建立了互惠互利的关系。管理机构是对企业行为进行管理和规范的组织。住户是居住在同一住址的人员的非正式组织，通常是一个家庭。这种信息有益于为个人产品建立客户统计数据。协会是在特定行业或者产业领域内提供服务（如网络和共享信息）的组织。供应商是可能或者正在向企业提供产品（货物或服务）的企业。组织单位是指这个组织的形式，它可以用来确认组织的不同部分，以及对组织的结构进行调整。这个角色可以进一步细分为各种子类：上级组织、分公司、部门、分支机构及其其他组织单位。上机组织角色表明该企业被另一个企业包含，而且上级组织部分或者全部地拥有这个企业。分支机构是企业内部致力于一个目标的组织的一部分。部门是企业内部致力于更具体目标的组织的一部分，有时属于企业的一个分支机构。其他组织单位用于表示特定行业的独有类型的组织。内部组织是数据模型所针对的哪个企业的内部组织。

2.4.2 通用性角色

　　本节中提到的子类型用于提供一个应用于大多数企业的通用子类型的列表。应当认识到，每个企业都可能对这个子类型列表进行修改以适应于自己的具体需求。因此，每个当事人角色使用且仅使用一个当事人角色类型进行描述。角色类型有一个描述属性存储角色类型的可能值，而当事人角色类型是角色类型的一个子类。角色可以可以通过声明的方式进行定义，如人员是一个“潜在客户”；角色也可以与特定事务联系在一起，如订购、协议、需求等等。

　　使用角色类型实体表示附加的角色类型，用于表示各种当事人在企业中所担任的角色。【订单角色类型、协议角色类型、需求角色类型以及用于许多其它多种类型事务的特定角色类型】

　　当事人角色类型的实例包括：雇员、联络员、客户、供应商、内部组织邓，以及更特殊的角色类型，例如“下单客户”、“付款客户”、“安装客户”、“客户联络员”、“供应商联络员”和其他所有没有在当事人角色中提到的角色。

　　为了全面的对当事人进行定义，一些当事人角色依赖于另一个当事人的上下文，而另一些角色可以依赖他们自己而存在。例如，上级组织对于识别那些拥有其他公司的公司是有用的。这个角色通常依赖于其他组织即分公司。因此，这些角色依赖于所拥有的当事人关系实例。一些当事人角色，诸如“公证人”或者“医生”是独立的，当事人可以拥有这些角色，甚至不需要具有一个关联的当事人关系。

　　每个当事人角色可能在在特定时间范围内有效，所以起始日期和终止日期属性是当事人角色的一部分。这些属性是任选的，许多角色的时间范围依赖于（也可以从当事人关系推导出来）当事人关系实体。

2.4.3 角色是否该在事物发生的时候定义

　　有人可能认为，在特定事务发生之前，企业并不真正了解当事人的角色。所以这个角色是导出的，也不是必需的。例如，如果将一个客户定义为一个曾经购买、装运或者使用企业产品的当事人，那么订单、发票、设备使用或装运实体将表明谁是客户。在这些实体与当事人实体之间的关系中，这种信息也是可以获取的。但是，在实际的使用过程中，能够标明特定当事人的角色是非常重要的。虽然企业没有任何潜在客户的事务信息，它还是可能将“X公司”标为潜在客户。同样，即使没有任何相关事务，企业也可能想将一个特定当事人标为客户。另外，即使这是一个技术上的考虑，企业实际上也想在不查找下相关事务的情况下了解谁是客户、谁是供应商、谁是雇员等等。关系独立的角色如“公证人”邓需要被表明角色，不必宇企业存储的事务信息相联系。

　　对是否在事务发生时定义角色的另一个争议是，在有些场合，企业可以在事务发生的时候对这些角色进行时实例化。在任何事务发生之前，角色不需要被实例化。例如，当一个当事人下订单后，可以为其建立一个作为客户的当事人角色的实例（企业可以将其纳入几个客户角色，例如付款客户、装运目标客户、最终用户客户），然后将订单连接到这些实例。

2.4.4 当事人角色的例子

　　大多数当事人拥有至少一个角色，因为它们是处于一些原因而被存储维护的，而且它们通常拥有一个以上的角色。有时，一个当事人连一个角色也没有也是有可能的。例如在维护人口普查数据时。

2.4.5 本文中的角色类型

　　当事人可能会扮演不同的角色。当事人的角色可能是通过“声明”的方式进行定义的，不涉及到任何事务。也可为数据模型中所涉及的任何类型的事务都定义角色。订购、装运、发票以及数据模型中出现的其它任何事务都可以有角色。

　　所有这些角色都有一个标准的结构，与某一个当事人相联系，是某一种角色类型，同某一个事务相联系。例如：每一个订单可以拥有当事人联系的特定订单角色类型的多个订单角色（取订单当事人、发订单当事人、付款当事人）。这些角色类型中的每一个（订单角色类型，当事人角色类型、发票角色了类型等等）都可以看成是角色类型的子类。，因而继承了角色类型的属性如角色类型标识和描述。当事人角色类型是角色类型的子类。

2.5 当事人关系

2.5.1 当事人关系示例

2.5.2 当事人关系信息

2.5.3 状态类型

2.6 当事人联络信息

　　人和组织可以通过多种不同的方式进行联络。例如，通过邮件、电话、传真（基本已经弃用）、手机等。本节建立的数据模型用以存储地址、电话号码以及其它任何用于与当事人进行联络沟通的联系机制。

　　大多数数据模型用不同的属性存储联络信息。例如：

1. 地址
2. 家庭电话、办公电话等等

　　上述这种方式存在两个主要问题。首先，不知道会有多少个联络方式和那些联络方式的类型是什么。如果有人有两三个家庭住址和家庭电话怎么办？如果出现了新的联系机制怎么办？实际上，如果数据库没有考虑到所有可能的情况，用户只能将这类信息加到“注释”或者“备注”栏里，而这会降低系统信息检索的效用。

　　用不同属性分别存储联络信息的第二个问题在于，每一个联络地址、电话或者字符串都可以有他自己的信息。例如，地址可能有方位说明，联系电话也可以有相关的信息（如谢绝推销或者备注最佳联系时间等）。如果不根据这些联系方式自己的特点建立模型，就可能产生大量冗余。例如，如果一个大公司的总部地址是作为一个属性进行存储的，数据库就可能会以不一致的方式多次存储其方位说明。

2.6.1 邮政地址信息

　　与人或者组织进行联系，既可以通过去造访他们的地址来实现，也可以通过向他们的邮政地址寄邮件来实现。在一个通用的获取邮政地址和地理信息的数据模型中。邮政地址实体保存了企业所使用的所有地址。以它为核心，当事人邮政地址说明邮政地址与当事人的关系。地理范围实体保存所有类型的包含型区域。例如：县、市、国家、邮政编码或者地区，并连回到邮政地址。此外，它还可以递归的连接到其他地理范围。

　　一个组织可能会有多个地址或位置。例如，一个零售商可能有几个不同地址的分店。此外，多个组织也可能回使用同一个邮政地址。例如，一个组织的子公司可能都使用同一个地址。不同的组织如果使用同一个大楼，也可能使用相同的地址。

　　人员和邮政地址之间的关系也是多对多的。一个具体的地址可能住着很多人，如在同一个办公楼工作的多个员工。而且，人们通常拥有多个地址：家庭住址、工作地址、度假地址等。因此，当事人和邮政地址之间是多对多的关系。

　　为了避免人和组织出现各自不同的关系，通过使用一个名为当事人邮政地址的交叉实体（有时称为关联实体或者交叉引用实体）在当事人和邮政地址之间建立起多对多关系。需要注意的是，当事人地址有起始日期和终止日期，这就允许我们对当事人额地址变化进行监控。

　　在上述的模型中，地址只被保存一次——这样就消除了数据冗余问题——而且还能在同多个当事人的关系中被多次使用。

　　为了造访一个当事人或者给其邮寄文件，邮政地址存储了多个属性已确认具体位置。属性地址1和地址2用两个文本行的方式来对一个地址进行描述。有些企业也可能需要用到更多行。方位属性为走哪条路、在哪里转弯以到达该地址提供了说明。如果数据模型中地址没有自己独立的实体的话，这种方位信息往往会在数据库中被重复存储许多次。

　　地理范围

2.6.2 当事人联系机制——电话号码和电子地址

　　联系机制实体保存了与当事人的联系机制。每一个联系机制都可以是与某个当事人联络的方法。交叉实体当事人联系机制表示哪个联系机制与哪个当事人相关联。联系机制类型保存了不同种类的联系机制的允许值。例如，电话、手机、邮箱以及指定的网络连接等。

　　可以将联系机制分为电话号码和邮箱地址等子类。电话号码包括所有通过电信行业进行联络的方式，例如电话、手机等等。邮箱地址则包括所有通过互联网或者其他电子邮件服务进行联络的方式。

　　联系机制类型实体显示了所有类型的联系机制的可能值。并且，需要提供一种加入新联系机制的方法。

　　当事人联系机制中的某些属性表明了该联系方式的使用方式。例如，免推广告。

2.6.3 当事人联系机制的扩展

　　如果联系机制是联系人员或者组织的方法，那么为什么不把邮政地址作为联系机制的一个子类包含进去呢？邮政地址只是联系某人的一个方法而已。在一个能够提供灵活的、可翻页列表的联络管理系统中——它能够显示当事人所有不同的联络方式：显示所有的电话号码、电子邮件地址和邮政地址等等，并可以按照用户的意图进行分组。这将极大的便于我们联系当事人，并允许我们灵活便利的获得联络信息。

　　将邮政地址用作联系机制的另一个优点是许多业务处理需要一个联系机制以完成事务，而这个联系机制可以是邮政地址、电话号码或电子邮件。例如，一个订单需要一个邮政地址或者电子邮件地址作为一个保证。

　　联系机制包括子类邮政地址、电话号码和电子邮件地址。由于每一个子类已经各自与当事人建立了多对多关系，因此联系机制与当事人之间也有一个多对多关系。

　　当事人联系机制也可以选择与当事人角色类型相关联，它表示每一种当事人的联系机制可能只是针对某一个特定角色。例如，某一组织仅当其角色为客户时才会提供地址信息，而当该组织作为其它角色出现时则未必如此。

　　联系机制之间可以相互关联，从而出现了递归实体联系机制链接。例如，拨打某个电话时，如果占线，则自动转到手机或者其它通信工具，也可以自动连接到电子邮件。在联系当事人时，知道这些信息非常重要。

2.6.4 联系机制的用途

　　每个当事人的每种联系机制可能有多个用途。例如，一个地址既可以用作邮政地址，也可以作为总部地址或者服务地址。及时邮寄地址、总部地址和服务地址可能是完全一样的，大多数系统也会分别为他们准备各自的记录。还有，像地址一样，其他联系机制也可能有多种用途。例如，有时业务人员的手机号码既是普通电话又是一个邮箱名称。

　　数据模型显示，每个当事人联系机制可以拥有一个或者多个当事人联系机制用途，它由联系机制用途类型进行描述。

　　由于不同联系机制的用途回随时间发生变化，所以用起始日期和终止日期来确定该用途的有效时间。联系机制用途类型包含所有可能使用的用途列表。

　　另一种建模方法是直接将联系机制用途类型关联到当事人联系机制，并将联系机制用途标识作为当事人联系机制实体中主键的一部分。这种简单的设计在多数情况下可能会导致冗余。例如，如果当事人的地址同时作为邮寄、总部和服务地址使用，当事人联系机制将会产生三个实例。每个实例拥有相同的当事人和联系机制的标识，但用途是不同的。所以，只与当事人和联系机制有关的信息，如免推销，就会被重置。换句话说，当事人联系机制有自己的意义，可能拥有独立于用途的属性或关系。考虑上述问题，模型使用两个不同的实体当事人联系机制和当事人联系机制用途。

2.7 设施与联系机制

　　联系机制可以与一个当事人相关联，如某人员的手机号码；也可以与一个人的物理位置相关联，如某个工厂的电话号码或者某个高楼的电话号码。由于这些物理设施并不是邮政地址或者当事人（即使它们与邮政地址或者当事人有关系），因此需要另一个实体对它们进行描述。联系机制实体保存联络一个当事人所需的标签或者标识符；设施则保存与物理结构有关的属性或者关系。

　　一个基本的记录物理设施信息的模型。设施的子类包括仓库、车间、大楼、楼层、办公室以及其它类型的设施类型。每一个设施可以由其它多个设施构成。例如，一个大楼可以由多个楼层，一个楼层有多个房间；如果具体系统中需要对楼层进行监控，大楼可以由多个楼层构成，每个楼层由多个房间构成。一个物理设施很重要的属性是平方面积。

　　每一个设施可能涉及到一个或者多个当事人，因此设施角色实体保存哪些当事人为那些设施扮演哪些设施角色类型的信息。例如，某些当事人可能使用设施、租用设施、出租设施或者拥有设施——设施角色类型正是存储这些可能值的实体。可以通过一个或者多个联系机制联络到每个设施，例如电话、传真、电子邮件、邮政地址等。设施可以拥有一个或多个联系机制，如可以拥有一个邮政地址和另一个地址。

　　在具体应用中，一个联系机制可以用于多个设施。例如，有时多个车间聚集在同一个地址，这是很可能出现的情况。这时，设施联系机制关联实体提供了一个在联系机制和设施间的多对多关系。

2.8 当事人通信事件

　　在许多应用系统中，监控当事人之间谁和谁在什么时候进行了联络或通信是非常重要的。例如，为了理解客户心理，销售和账户代表常常需要知道客户什么时候处于什么目的给谁打电话。联络或者通信可能以电话、私人推销会谈、电话会议、信件或者其他方式实现。

　　实体通信事件提供了当事人之间已经完成或者将要完成的不同通信事件的历史记录。

　　通信事件的定义是：当事人之间使用电话、会谈、视频会议等等联络方式进行的信息交换。通信事件可能发生在特定当事人关系中，也可能发生在多个当事人之间，所以使用通信事件角色来描述当事人的角色。对于涉及两个以上当事人的联络事件（如会议或者研讨会），通信事件角色可以定义当事人及其在事件中所扮演的角色（协调人、参与者、记录员等等）。

　　通信事件通常发生在当事人关系而不是通信事件角色的环境中，这是因为通信事件通常在关系中才有意义。两个当事人间可能会有多种关系。应该根据关系分别对通信事件进行监控。

　　通信事件主要可以通过两种方式进行分组：通信所使用的联系机制（电话、传真、信件、电子邮件、会面等）与通信目的（技术支持电话、售后追踪、客户服务电话、会议、研讨）。

　　一个通信事件有且只有一个通信机制类型；然而他可能会有多种通信事件目的。（问：反过来的情况回发生么？） 例如，某次会面既是客户服务支持呼叫，又要求传递一个附加文件。通信事件的子类包括：问询、技术支持呼叫、客户服务呼叫、见面、售后追踪、会议、研讨会、活动邀请以及表示其它类型的通信事件目的的通信目的类型。其他可能的意图包括“初始销售呼叫”、“维修服务呼叫”、“演示”、“销售午餐会谈”或者“电话推销”。其中描述属性可用于存储说明意图的额外信息，例如“这是一个很重要的销售电话，必须让客户回心转意”。

2.9 小结

　　大多数数据模型和数据库毫无必要的设计了人和组织的重复信息。导致的结果是，许多组织很难保存准确的信息。上述几个小节具体的说明了如何为人员、组织、当事人关系和、地址、联系机制和当事人之间的联络建立一个非常灵活和规范的数据模型。