代码改变世界

数据库设计 Step by Step (8)——视图集成

2011-07-09 16:05 知行思新 阅读(...) 评论(...) 编辑 收藏

引言:在前文(数据库设计Step by Step (7)——概念数据建模)最后的案例中,我们通过集成多个局部的实体关系(ER)模型最终得到了全局ER图。在现实项目中视图集成可能并不会那么容易。

俯瞰整个数据库生命周期(如下图所示)。在前面的内容中,我们已完成了“确定需求”和“数据模型”(图中以灰色标出),本小节我们将详细讨论“视图集成”(图中以红色标出)

DBLifeCycle

把基于不同用户视角的局部ER图集成为一个统一的、没有冗余的全局ER图在数据库设计流程中非常重要。单个局部ER图是通过分析用户需求进行概念数据建模得到的;全局ER图是通过对各个局部ER图进行分析,解决其中存在的视角和术语差异,最终进行组合得到的。

 

image

为什么会产生不一致的局部ER图

当不同的用户或用户组从各自的视角来看业务时就会产生各异的ER图。举例来说市场部趋向于把整个产品作为销售的基本单元,但工程部可能更关注组成产品的单个零件。另一个例子,一个用户可能关注项目的目标和产生的价值,而另一个用户则关心项目需要占用的资源和所涉及的人员。上述的这些差异造成了各个ER图之间不一致的关系和术语。ER图的不一致性会表现为:不同的泛化程度;不同的关系连通数(一对多、多对多等);不同用户视角定义的实体、属性或关系(相同的概念,不同的人使用了不同的名称与建模形式)。

举例来说,同一个现实场景(客户下订单,订购产品),从三个不同视角建模得到的ER图如下。

image(图1  把order看作实体)

image(图2  把order看作关系)

image(图3  把order看作属性)

图1中,Customer、Order、Product描述为实体,把“places”和“for-a”描述为关系。

图2中,“orders”定义为Customer和Product之间的关系。

图3中,“orders”关系被另一个关系“purchases”代替。“order-no”被作为关系“purchases”的一个属性。

同是订单(order),从不同视角出发在ER图中被表示为实体、关系、属性。

视图集成的步骤

局部ER图(概念数据模型)的集成一般有如下四个步骤。

  1. 集成策略选择
  2. 比较实体关系图
  3. 统一实体关系元素
  4. 合并、重构实体关系图

我们一一对这四个步骤进行讨论。

集成策略选择

通常的集成策略有:

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图包含超类实体与子类实体的层次组合,若超类实体中的属性已涵盖子类实体中的某些属性,则子类实体的这些属性可以去除。

 

image

了解目标

让我们看一下两张具有重叠数据的局部ER图。这两张ER图是对两组不同用户访谈后画出的。

图4是一张以报表为关注点的ER图,其中包含发布报表的部门、报表中的主题和报表提交的对象。

image(图4  关注报表)

图5的ER图以发布作为关注中心,把发布内容中的关键词建模为另一个实体。

image(图5  关注发布)

我们的目标是整合这两张ER图,并保证合成后的ER图语义完整、形式最简约且易理解。

集成步骤

首先,在两张局部ER图中寻找是否存在“同物异名”与“异物同名”现象。图4中的实体Topic-area与图5中的实体Keyword为“同物异名”,虽然两个实体的属性不完全相同,但两者属性是兼容的,可以进行统一化。对图5进行修改,可得到图6。

image(图6  Keyword换为Topic_area)

其次,再来看两张ER图之间的结构性冲突。图4中的实体Department与图5中的属性dept-name为类型冲突。解决该冲突的方法是保留强类型(实体Department),把属性dept-name移至实体Department中。解决该冲突,把ER图6转化为ER图7。

image(图7  属性dept-name转化为一个实体和一个属性)

比较变化后的各局部ER图,寻找之间的“共同之处”进行合并。 在真正合并之前必须确认这些“共同之处”的语义概念完全等同,这也保证了合并后语义的完整性。在ER图4与ER图7中有两个共同实体:Department和Topic-area,且语义一致。初步合并后的全局ER图如图8所示。

image(图8  初步合并图4和图7后的全局ER图)

图8中实体Publication和Report与实体Department和Topic-area之间的关系存在冗余。通过与用户的再次确认,了解到Publication是Report的泛化(报表只是发布材料中的一种),故不能简单的去除实体Publication及关系have和include来消除冗余,而可以引入泛化关系并去除冗余关系publish和contain。

图9展示了增加泛化关系后的ER图(Publication为超类型,Report为子类型)。

image(图9  加入泛化关系)

图10中实体Report与实体Department和Topic-area之间的冗余关系publish和contain被去除了。Report中的属性title也被去除了,因为该属性已经出现在其超类型实体Publication中了。

image(图10  去除冗余关系)

最终得到的ER图10达到了语义完整、最简约、易理解的目标。ER图集成是一个持续优化和评估的过程。需要注意的是“最简约”未必会最高效。如ER图10中去除的“publish”和“contain”关系,保留它们可能对性能有帮助。在后期的分析或测试过程中可根据需要重构ER图。

 

总结与参考

1. 不同的用户或用户组视角将产生不同的局部ER图

2. 局部ER图之间的冲突包括:命名冲突、类型冲突、依赖冲突、键冲突

3. 视图集成的目标是得到语义完整、形式简约且易于理解的全局ER图

4. 视图集成能进一步加强项目组对系统整体需求的理解与把握