1.4.3 E-R模型的设计流程
复杂的数据库系统一般按照自底向上的设计策略，分模块进行设计。E-R模型的设计流程是先设计局部应用的局部E-R模型，然后把所有局部E-R模型合并为完整的数据库系统的全局E-R模型，最后把全局E-R模型优化为基本E-R模型，如图1-24所示。
图1-23 超类与子类示例
图1-24 E-R模型设计流程图
1. 局部E-R模型设计
局部E-R模型设计的工作内容是基于对局部应用的需求分析结果，运用分类、聚集、概括等数据抽象方法，把一个局部应用抽象为实体、属性、标识实体的关键属性，并确定实体之间的联系及联系的类型。
局部E-R模型设计的难点是把现实世界的对象抽象为实体还是属性。实体和属性是相对而言的，往往要根据实际情况进行必要的调整。基本的判断依据有三个。一是属性要足够简单，复合属性需要升级为实体，或直接被其子属性替代。二是简化E-R模型的处理，现实世界中的事物凡能够作为属性对待的，应尽量作为属性。如果一个实体只有一个属性，则应该降级为属性。三是属性是对实体组成部分的描述，是实体的一部分，不允许属性与其他实体发生联系。例如，校园卡对于商户的经营管理而言是属性，他们只关注校园卡的卡号。但对于学生而言，除了卡号，还有卡的密码、余额等属性需要关注，校园卡应该抽象为包含多个属性的实体。
例1-1 如图1-25a）所示，局部E-R模型中的工资是职工的属性，工资构成包含岗位工资、薪级工资、绩效工资和津贴补贴四部分。这种设计方法是否合适？
不合适。因为工资不仅是派生属性，而且是包括四个子项的复合属性。处理方法有两种：一是用岗位工资、薪级工资、绩效工资、津贴补贴替代工资属性，如图1-25b）所示；二是把工资作为实体，如图1-25c）所示。
图1-25 局部E-R模型设计示例
2. 全局E-R模型设计
将局部E-R模型合并为全局E-R模型，首先要识别各局部E-R模型中的公共实体，然后从公共实体开始进行两两合并，直到所有有关联的局部E-R模型合并为一个整体，最后加入独立的局部E-R模型后得到全局E-R模型。
对于较大的数据库系统，局部E-R模型很多，而且现实世界的同一个对象在不同的局部E-R模型中可能被给予了不同的抽象，将局部E-R模型合并为全局E-R模型时难免会出现冲突。检查并消除冲突是设计全局E-R模型的重要工作内容。常见的冲突有三种，分别是结构冲突、命名冲突和属性冲突。
（1）结构冲突。
结构冲突是指同一对象在不同应用中具有不同的抽象。
第一类结构冲突是同一对象在不同的局部应用中分别被抽象为实体和属性。调整的原则是能用属性表示的对象就不要用实体表示，但是当对象的属性难以用简单属性表示时，就要在整个系统范围内把该对象用实体表示。例如，校园卡在一个局部应用中作为属性，在另一个局部应用中可以是有多个属性的实体，则我们在合并局部E-R模型时应该把校园卡作为实体。
第二类结构冲突是同一对象在不同的局部E-R模型中都被抽象为实体，但是实体的属性并不完全相同或属性的排列次序并不完全相同。因为数据库要满足所有用户的数据处理需求，因此实体的属性应该取各局部E-R模型中该实体属性的并集，再按照由主到次的顺序调整属性的顺序。例如，校园卡在一个局部应用中有卡号、开卡日期、注销日期、密码、状态等属性，在另一个局部应用中有卡号、密码、余额等属性，两个局部E-R模型合并后，校园卡实体的属性是二者的并集：卡号、密码、余额、开卡日期、注销日期、状态。
第三类结构冲突是在不同的局部应用中，实体之间的联系类型不同。例如，在一个局部应用中校园卡与商户之间是二元联系，而在另一个局部应用中校园卡、商户、商品之间是三元联系。是二元联系合适，还是三元联系合适，没有一定之规，要根据应用语义具体分析，然后对实体之间的联系类型进行设计。调整的原则是能用二元联系表示就不要用三元联系表示。例如，校园卡、商户、商品之间的三元联系，可以调整为校园卡与商户之间的二元联系和商户与商品之间的二元联系。但是并非所有的三元联系都可以用多个二元联系来表示。
（2）命名冲突。
实体名、属性名、联系名都有可能冲突，其中以属性的命名冲突尤为常见。命名冲突分为同名异义和同义异名两种情况。
同名异义是指不同意义的对象在不同的局部应用中具有相同的名字，例如，在不用的局部应用中都将实体命名为“项目”，一个是指教师承担的科研课题，一个是指学生参加的大学生创新创业项目。二者的性质、研究内容、考核指标都是不一样的，是两种不同的实体，应该用不同的实体名加以区分。
同义异名是指同一对象在不同的局部应用中被定义了不同的名字。例如，同样是学生实体，在一个局部应用中被命名为“学生”，而在另一个局部应用中又被命名为“学员”，因此，在合并为全局E-R模型时需要统一。
（3）属性冲突。
属性冲突是指同一个属性的属性域冲突，或者属性取值单位冲突。
属性域包括属性的数据类型和取值范围。属性域冲突有可能是同一属性在不同的局部应用中被定义了不同的数据类型，或者同一属性在不同的局部应用中数据类型相同但是数据的取值范围不同。例如，校园卡的卡号在一个局部应用中被定义为整数类型，而在另一个局部应用中被定义为字符类型。又如，学号在两个局部应用中都被定义为字符类型，但是在一个局部应用中学号的长度为12，在另一个局部应用中学号的长度为10。
属性取值单位冲突也很常见。例如，商品的规格属性在一个局部应用中以箱为单位，在另一个局部应用中以瓶为单位。
3. 基本E-R模型设计
基本E-R模型设计是指在全局E-R模型的基础上，去掉冗余数据和冗余联系。冗余数据是指可由基本数据导出的数据。冗余联系是指可由其他联系导出的联系。冗余数据和冗余联系容易造成数据的不一致，增加数据库维护的难度。如果全局E-R模型中存在冗余数据和冗余联系，则需要对其进行优化。优化后的全局E-R模型被称为基本E-R模型。
例如，学生的平均分是由各科成绩加权平均后得到的数据，属于冗余数据。又如，发票的总金额是由发票中商品的单价和数量计算得到的数据，属于冗余数据。
例1-2 如图1-26所示的E-R模型中是否存在冗余联系？如果存在，请你消除冗余联系。
图1-26 冗余联系示例
学生与商户之间的消费联系是一个冗余联系，因为该联系可以通过学生持有校园卡和刷卡在商户消费这两个联系推导出来。消除冗余联系后的E-R模型如图1-27所示。
图1-27 消除冗余联系后的E-R模型
基本E-R模型用尽可能少的实体、属性、联系，准确、全面地反映用户功能需求。但这并不意味着数据库中没有冗余，必要的冗余有时可以提高数据查询的效率。设计基本E-R模型时，哪些冗余信息要消除，哪些冗余信息允许存在，需要根据用户的整体需求来确定。