数据库设计 Step by Step (8)——视图集成
2011-07-09 16:05 知行思新 阅读(11466) 评论(11) 编辑 收藏 举报引言：在前文（数据库设计Step by Step (7)——概念数据建模）最后的案例中，我们通过集成多个局部的实体关系（ER）模型最终得到了全局ER图。在现实项目中视图集成可能并不会那么容易。
俯瞰整个数据库生命周期（如下图所示）。在前面的内容中，我们已完成了“确定需求”和“数据模型”（图中以灰色标出），本小节我们将详细讨论“视图集成”（图中以红色标出）
把基于不同用户视角的局部ER图集成为一个统一的、没有冗余的全局ER图在数据库设计流程中非常重要。单个局部ER图是通过分析用户需求进行概念数据建模得到的；全局ER图是通过对各个局部ER图进行分析，解决其中存在的视角和术语差异，最终进行组合得到的。
为什么会产生不一致的局部ER图
当不同的用户或用户组从各自的视角来看业务时就会产生各异的ER图。举例来说市场部趋向于把整个产品作为销售的基本单元，但工程部可能更关注组成产品的单个零件。另一个例子，一个用户可能关注项目的目标和产生的价值，而另一个用户则关心项目需要占用的资源和所涉及的人员。上述的这些差异造成了各个ER图之间不一致的关系和术语。ER图的不一致性会表现为：不同的泛化程度；不同的关系连通数（一对多、多对多等）；不同用户视角定义的实体、属性或关系（相同的概念，不同的人使用了不同的名称与建模形式）。
举例来说，同一个现实场景（客户下订单，订购产品），从三个不同视角建模得到的ER图如下。
（图1 把order看作实体）
（图2 把order看作关系）
（图3 把order看作属性）
图1中，Customer、Order、Product描述为实体，把“places”和“for-a”描述为关系。
图2中，“orders”定义为Customer和Product之间的关系。
图3中，“orders”关系被另一个关系“purchases”代替。“order-no”被作为关系“purchases”的一个属性。
同是订单（order），从不同视角出发在ER图中被表示为实体、关系、属性。
视图集成的步骤
局部ER图（概念数据模型）的集成一般有如下四个步骤。
- 集成策略选择
- 比较实体关系图
- 统一实体关系元素
- 合并、重构实体关系图
我们一一对这四个步骤进行讨论。
集成策略选择
通常的集成策略有：
1.每次集成2个局部ER图。
2.每次集成n个局部ER图（n大于2且小于等于总ER图数）。
相对来说第一种集成策略每次所涉及的实体、关系数量较少，也更容易掌控。
比较实体关系图
设计者需要仔细观察不同ER图中的对应实体，发现其中因视角不同而存在的冲突。
命名上的冲突包括“同物异名”和“异物同名”。“同物异名”是指同一个概念使用了不同的名称，可以通过检视数据字典（命名及其描述对应表）来发现。“异物同名”是指对不同的概念使用了相同的名称，需要通过检视不同ER图中相同的名称来发现。
结构性冲突的表现形式更多。类型冲突包括使用不同的构造方式建模同一概念。以图1、2、3为例，order这一概念可以建模为一个实体，一个关系或一个属性。依赖冲突是指类似或相同的关系在不同的局部ER图中被建模成不同的连通数。解决这种冲突的一种方法是使用最一般的连通数约束，如多对多。若这样做会造成语义上的错误，则说明两种关系概念不同不能合并，应进行改名并让每个关系保持各自的连通数。键冲突是指在不同的局部ER图中，同一概念的实体被分配了不同的键。举例来说，当一名员工的全名、员工号、员工身份证号在不同的局部ER图中被作为员工的键时，就出现了键冲突。
统一实体关系元素
基本目标是解决各局部ER图中的冲突，使这些元素一致化，为最终的ER图集成做准备。要解决各局部ER图之间的冲突通常需要设计开发人员与用户进行积极的沟通，了解、分析、理解冲突元素的真实语义。
我们可能需要对某些ER图中的实体及键属性进行改名。各局部ER图中被建模为实体、关系或属性的同一概念需要统一转化为三种形式之一。
集成具有相同的度、角色和连通数属性的关系相对较为容易，但集成上述特征不同的关系就较为困难。若同一关系在不同局部ER图中表现形式不一致，则必须进行统一。如：某一关系在一局部ER图中为泛化层次关系，在另一局部ER图中为排他性或（exclusive OR）关系，这种情况必须统一。
合并、重构实体关系图
合成和重构局部ER图，最终得到完整、最简约和可理解的全局ER图。
完整是要求在全局ER图中所有组件的语义完整。
最简约是要求去除全局ER图中的冗余。冗余的概念包括：重叠的实体、多余的语义关系等。例如“社会车辆”和“私家车”可能是重叠的两个实体；教授与学生之间的“指导”和“建议”关系可能代表了同一种活动，需要进一步确定是否存在冗余。
可理解要求全局ER图能被整个项目组成员和最终用户理解。
在进行ER图集成过程中，我们可以首先将相同概念的组件进行集成，之后对获得的初步全局ER图进行重构以使其满足上述三方面的要求。举例来说，集成后的ER图包含超类实体与子类实体的层次组合，若超类实体中的属性已涵盖子类实体中的某些属性，则子类实体的这些属性可以去除。
了解目标
让我们看一下两张具有重叠数据的局部ER图。这两张ER图是对两组不同用户访谈后画出的。
图4是一张以报表为关注点的ER图，其中包含发布报表的部门、报表中的主题和报表提交的对象。
（图4 关注报表）
图5的ER图以发布作为关注中心，把发布内容中的关键词建模为另一个实体。
（图5 关注发布）
我们的目标是整合这两张ER图，并保证合成后的ER图语义完整、形式最简约且易理解。
集成步骤
首先，在两张局部ER图中寻找是否存在“同物异名”与“异物同名”现象。图4中的实体Topic-area与图5中的实体Keyword为“同物异名”，虽然两个实体的属性不完全相同，但两者属性是兼容的，可以进行统一化。对图5进行修改，可得到图6。
（图6 Keyword换为Topic_area）
其次，再来看两张ER图之间的结构性冲突。图4中的实体Department与图5中的属性dept-name为类型冲突。解决该冲突的方法是保留强类型（实体Department），把属性dept-name移至实体Department中。解决该冲突，把ER图6转化为ER图7。
（图7 属性dept-name转化为一个实体和一个属性）
比较变化后的各局部ER图，寻找之间的“共同之处”进行合并。 在真正合并之前必须确认这些“共同之处”的语义概念完全等同，这也保证了合并后语义的完整性。在ER图4与ER图7中有两个共同实体：Department和Topic-area，且语义一致。初步合并后的全局ER图如图8所示。
（图8 初步合并图4和图7后的全局ER图）
图8中实体Publication和Report与实体Department和Topic-area之间的关系存在冗余。通过与用户的再次确认，了解到Publication是Report的泛化（报表只是发布材料中的一种），故不能简单的去除实体Publication及关系have和include来消除冗余，而可以引入泛化关系并去除冗余关系publish和contain。
图9展示了增加泛化关系后的ER图（Publication为超类型，Report为子类型）。
（图9 加入泛化关系）
图10中实体Report与实体Department和Topic-area之间的冗余关系publish和contain被去除了。Report中的属性title也被去除了，因为该属性已经出现在其超类型实体Publication中了。
（图10 去除冗余关系）
最终得到的ER图10达到了语义完整、最简约、易理解的目标。ER图集成是一个持续优化和评估的过程。需要注意的是“最简约”未必会最高效。如ER图10中去除的“publish”和“contain”关系，保留它们可能对性能有帮助。在后期的分析或测试过程中可根据需要重构ER图。
1. 不同的用户或用户组视角将产生不同的局部ER图
2. 局部ER图之间的冲突包括：命名冲突、类型冲突、依赖冲突、键冲突
3. 视图集成的目标是得到语义完整、形式简约且易于理解的全局ER图
4. 视图集成能进一步加强项目组对系统整体需求的理解与把握
