设计全局ER模型 数据库系统原理（2007版） 课程代码4735 笔记

设计全局ER模型

根题目：采用ER模型的数据库概念设计步骤

摘自：数据库系统原理（2007版） 课程代码4735 P46页

1. 设计局部 ER 模型 * 确定局部结构范围 * 定义实体 * 定义联系 * 分配属性 

摘自：数据库系统原理（2007版） 课程代码4735 P48页

2.设计全局 ER 模型  所有局部 ER 模型都设计好后，接下来就是把它们综合成单一的全局概念结构。全局概念结构不仅要支持所有局部 ER 模型，而且必须合理地表示一个完整、一致的数据库概念结构（有的书上称此步工作为 “视图集成”， 这里的 “视图” 特指本书所说的局部概念结构）。  综合成全局 ER 模型的步骤如下：    * 确定公共实体类型。    * 合并局部 ER 模型。    * 消除冲突  (1) 确定公共实体类型  为了给多个局部ER模型的合并提供初始合并的基础，首先要确定各布局结构中的公共实体类型。  公共实体类型的确定并非一目了然。特别是当系统较大时，可能有很多局部模型，这些局部ER模型是由不同的设计人员确定的，因而对同一现实世界的对象可能给予不同的描述。有的作为实体类型，有的又作为联系类型或属性。即使都标识成实体类型，实体类型名和键也可能不同。在这一步中，我们仅根据实体类型名和键来认定公共实体类型。一般把同名实体类型作为公共实体类型的一类候选，把具有相同键的实体类型作为公告实体类型的另一类候选。  （2）合并局部 ER 模型  合并的顺序有时影响处理效率和结果。我们建议的合并原则是：首先进行两两合并；先合并那些现实世界中有联系的局部结构；合并从公共实体类型开始，最后再选择加入独立的局部结构。  进行二元合并是为了减少合并工作的复杂性。后两项原则是为了使合并结果的规模尽可能小。  （3）消除冲突  由于各类应用不同，不同的应用通常又由不同的设计人员设计局部 ER 模型，因此局部ER模型之间不可避免地会有不一致的地方，我们称之为冲突。通常，我们把冲突分为三种类型：  * 属性冲突，包括：属性域的冲突，即属性值的类型、取值范围或取值集合不同。例如，重量单位有的用公斤，有的用克。  * 结构冲突，包括：同一对象在不同应用中的不同抽象。如职工，在某个应用中为实体，而在另一应用中为属性。同一实体在不同局部 ER 图中属性组成不同，包括属性个数、次序。实体之间的联系再不同的局部 ER 图中呈现不同的类型。如， E1 与 E2 在某一应用中是多对多的联系，而再另一应用中是一对多的联系；在某一应用中 E1 与 E2 发生了联系，而在另一应用中， E1、E2 与 E3 三者之间有联系。  * 命名冲突，包括属性名、实体名、联系名之间的冲突。同名异义，即不同意义的对象具有相同的名字；异名同义，即同一意义的对象具有不同的名字。  属性冲突和命名冲突通常采用讨论、协商等行政手段解决，结构冲突则要认真分析后才能解决。  设计全局 ER 模型的目的不在于把若干局部 ER 模型形式上合并为一个 ER 模型，而在于消除冲突，使之成为能够被全系统中所有用户共同理解和接受的统一的概念模型。

为了加深映像，上面都是我摘抄的。可能有文字错误的疏漏，实属正常，如有发现万望指正。

理解

从局部设计出发，以实体类型为基准点，利用联系表关联实体之间的关系。利用属性表做实体类型的描述。在这之前，我们要确定会出现的实体类型，并对其公共实体命名做统一规定，以方便后面的局部到整体的合并流程。当局部设计到达一定阶段的时候，开始对局部 ER 模型进行两两合并。合并时，应先从关联实体入手，再对独立的类型进行合并。

---

于 2017年10月14日 19:25:43 最后更新