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

引言：在前文（数据库设计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. 视图集成能进一步加强项目组对系统整体需求的理解与把握

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！