现代数据库设计：E-R模型优化

在设计E-R模型时，首先必须根据需求分析确认实体集、联系集和属性。如果一个企业（单位）有许多部门，就会有各种业务应用的需求说明来自对它们的调查和分析。这里只介绍E-R模型的设计方法。

在设计E-R模型时需要遵循以下三条原则。

第一，相对原则。当某一对象在进行抽象的过程中，需要对其进行解释与理解，这些解释与理解最终形成的就是对象的实体、对象的属性、对象的联系等内容，而对象抽象的过程就是建模的过程。需要注意的是，分析属性与联系的本质能够发现，其也为实体。由此可见，不同的对象其抽象的结果不同，同一个对象在不同的情境中其抽象的结果也有所不同。

第二，一致原则。在建立系统的过程中存在许多的子系统，这些子系统被称作业务系统。当同一个对象在不同的业务系统进行抽象时，要保证其最终的抽象结果是一致的。

第三，简单原则。在设计E-R模型时，要对其进行简化，因此，现实世界中凡是能够看成属性的事物，就要将其当作属性进行处理。实际上，实体与属性之间并没有一个明确的界限。如果想要将实体看作属性，只需要满足以下两个条件中的其中一个即可：第一，从某种意义上来讲，属性是不能被分裂的一种数据项，并且属性不需要再用其他的内容对其进行描述；第二，在E-R模型中，所有被指定的联系都是实体集之间的联系，不存在其他的相关联系，同样的，属性也不能与其他的实体集之间存在联系。

举个例子来说，如果将职工看作一个实体集，在该实体集中存在许多属性，包括姓名、工号及性别等。如果想要添加工资的相关内容，就要判断其是属性还是实体集，其判断的方式就是上述的两个条件。若不需要对工资再做更深的描述，就可以将其看作一个属性；若需要将工资细分为基本工作、补贴以及奖罚金等，则工资只能作为实体集存在。

再如，表示仓库与货物之间的联系时，如果想要将仓库当作货物的属性，就要保证某一种货物只在某一个仓库中进行存放；如果在这个过程中，仓库还和其他的事物存在联系，如一个仓库由几名职工进行保管，那么仓库就只能作为实体集存在。

在设计E-R模型时，若设计的对象为大型的企业或规模较大的单位，其设计的方法需要先进行局部设计，再进行整体设计，最后对模型进行优化。

下面以企业职工管理系统为例，说明E-R模型的一般设计过程。

在企业职工管理系统中，需要涉及的功能如下：

（1）人事处对职工的档案和部门进行管理，包括职工的基本情况、部门的基本情况，以及各种职称、职务的管理。

（2）财务处管理职工的工资情况。

（3）科研处管理项目、职工参加项目的情况。

具体的设计步骤如下。

（一）确定局部应用范围，设计局部E-R模型

1.确定局部E-R模型的设计

按部门划分不同的应用范围，即分为三个子模块：人事管理、工资管理和项目管理。下面以人事管理为例，说明设计局部E-R模型的一般过程。

2.确认实体集

在人事管理中，需要对职工、部门、职称及职务进行管理，所以实体集有职工、部门、职称及职务。

3.确认实体集之间的联系集

需要判断所有实体集之间是否存在联系。

职工与部门的联系为n∶1，职工与职称及职务的联系为m∶n，因为多名职工可有同一种职称或职务，而一名职工既可有职称，又可有职务。例如，某职工具有高级职称（高工），同时又是处级干部。

部门与职称及职务之间没有联系。

4.确认实体集的属性(www.xing528.com)

职工：职工号、姓名、性别、年龄。

部门：部门号、名称、电话。

职称及职务：代号、名称、津贴、住房面积。

5.确认联系集的属性

职工与部门的联系没有单独的属性，职工与职称及职务的联系有单独的属性——职称或职务的任职日期。

（二）集成局部E-R模型，初步形成全局E-R模型

全局E-R模型是通过集成所有的局部E-R模型形成的。通常情况下，设计局部E-R模型的人员都是不同的，他们的设计思路不同，并且不同的局部其具体应用也是不同的。这就导致每个局部的E-R模型都存在不相同的点，通常称这些点为冲突。在集成局部E-R模型时，最先要做的就是消除冲突。在各局部E-R模型中存在的主要冲突有以下三种。

1.命名冲突

命名冲突包括两种：一种为同名异义，指的是在不同的局部E-R模型中存在名称相同的对象，但表示的意义却不同；另一种为同义异名，指的是在不同的局部E-R模型中，存在意义相同的对象，却拥有各自的名称。这类冲突包括实体集名之间的冲突、联系集名之间的冲突、属性名之间的冲突等。例如，对于实体集职工来说，人事部门称之为职工来说，科研部门可能称之为科研人员。

命名冲突必须通过各部门一起讨论，协商解决。

2.属性冲突

属性冲突包括属性值类型、取值范围、取值单位的冲突。例如，职工号在一个局部E-R模型中定义为整数，在另一个E-R模型中定义为字符串。有些属性采用不同的度量单位，也属于属性冲突。

3.结构冲突

结构冲突包括两种：一种为在不同的应用中，同一个对象所拥有的抽象是不同的；另一种为在不同的应用中，同一个实体所拥有的属性不完全相同，包括属性的排列次序及属性的个数。举个例子来说，工资在人事部门中属于职工的属性，但是在财务部门中属于一个实体集。在不同的局部应用中，有时也会出现联系集不同的情况，即实体集之间的联系不同。

对这类冲突的处理，需要先对需求进行分析。依据分析的结果并结合全局情境，再对冲突的不同进行调整。发生冲突的部分可以是属性，可以是实体集，也可以是联系。

在集成局部E-R模型时，将其合并成统一的、全系统的模型，合并成能够得到用户理解与认可的模型，是整个合并过程中最关键的内容。

在人事管理E-R模型中，工资作为职工的属性，而在工资管理E-R模型中，工资是实体集；在项目管理E-R模型中，职务是职工的属性，而在人事管理中，职务是一个实体集。在该例中，将工资和职务均调整为实体集。

在集成全局E-R模型时，一般采用两两集成方法，即先将具有相同实体集的两个E-R模型以该相同实体集为基准进行集成，如果还有相同实体集的E-R模型，再次集成，直到所有具有相同实体集的局部E-R模型都被集成，最后得到初步的全局E-R模型。

（三）消除冗余，优化全局E-R模型

优质的全局E-R模型不仅能够对用户的功能需求进行反映，还要满足下面三个条件：第一，模型中要有尽量少的实体联系；第二，模型中的实体集要有尽量少的属性；第三，模型中的实体集之间没有多余无用的联系。

通常在合并的过程中，为了减少实体集的数量，有时会对实体集进行合并，并且合并的通常为具有相同码的实体集或相互之间存在1∶1联系的实体集。

有些实体集的属性可能是冗余数据。所谓冗余数据，是指重复存在或可由基本数据导出的数据。工资中的实发工资可由其他几项工资计算得到，属于冗余数据。冗余数据一方面浪费存储空间，另一方面又会破坏数据的完整性。例如某职工因为某种原因增加了基本工资，用户除了修改基本工资一项外，还必须同时修改实发工资，否则数据就会前后不一致。

但并不是所有的冗余数据都必须消除。有时为了提高效率，不得不以冗余数据为代价。例如，财务处频频地对每个职工的实发工资进行计算和统计，会影响工作效率。在这种情况下，可以让此冗余数据存在，但必须有数据的相关说明，并作为数据模型的完整性约束条件。