概念结构设计
前面讲解了E-R图的基本概念，本节介绍在设计E-R图的过程中如何确定实体与属性，以及在集成E-R图时如何解决冲突等关键技术。
概念结构设计的第一步就是对需求分析阶段收集到的数据进行分类、组织，确定实体、实体的属性、实体之间的联系类型，形成E-R图。首先，如何确定实体和属性这个看似简单的问题常常会困扰设计人员，因为实体与属性之间并没有形式上可以截然划分的界限。
①实体与属性的划分原则
事实上，在现实世界中具体的应用环境常常对实体和属性已经作了自然的大体划分。在数据字典中，数据结构、数据流和数据存储都是若干属性有意义的聚合，这就已经体现了这种划分。可以先从这些内容出发定义E-R图，然后再进行必要的调整。在调整中遵循的一条原则是：为了简化 E-R 图的处置，现实世界的事物能作为属性对待的尽量作为属性对待。
那么，符合什么条件的事物可以作为属性对待呢？可以给出两条准则：
(1)作为属性，不能再具有需要描述的性质，即属性必须是不可分的数据项，不能包含其他属性。
(2)属性不能与其他实体具有联系，即E-R图中所表示的联系是实体之间的联系。
凡满足上述两条准则的事物，一般均可作为属性对待。
例如，职工是一个实体，职工号、姓名、年龄是职工的属性，职称如果没有与工资、岗位津贴、福利挂钩，换句话说，没有需要进一步描述的特性，则根据准则(1)可以作为职工实体的属性；但如果不同的职称有不同的工资、岗位津贴和不同的附加福利，则职称作为一个实体看待就更恰当，如下图所示。
又如，在医院中一个病人只能住在一个病房，病房号可以作为病人实体的一个属性；但如果病房还要与医生实体发生联系，即一个医生负责几个病房的病人的医疗工作，则根据准则(2)病房应作为一个实体，如下图所示。
再如，如果一种货物只存放在一个仓库中，那么就可以把存放货物的仓库的仓库号作为描述货物存放地点的属性，但如果一种货物可以存放在多个仓库中，或者仓库本身又用面积作为属性，或者仓库与职工发生管理上的联系，那么就应把仓库作为一个实体，如图7.21所示。
【例1】销售管理子系统E-R图的设计。
某工厂开发管理信息系统，经过可行性分析，详细调查确定了该系统由物资管理、销售管理、劳动人事管理等子系统组成。为每个子系统组成了开发小组。
销售管理子系统开发小组的成员经过调查研究、信息流程分析和数据收集，明确了该子系统的主要功能是：处理顾客和销售员送来的订单；工厂是根据订货安排生产的；交出货物同时开出发票；收到顾客付款后，根据发票存根和信贷情况进行应收款处理。通过需求分析，知道整个系统功能围绕“订单”和“应收账款”的处理来实现。数据结构中订单、顾客、顾客应收账目用得最多，是许多子功能、数据流共享的数据，因此先设计该E-R图的草图(如下图所示)。
然后参照需求分析和数据字典中的详尽描述，遵循前面给出的两个准则，进行了如下一些调整：
(1)每张订单由订单号、若干头信息和订单细节组成。订单细节又有订货的零件号、数量等来描述。按照第二条准则，订单细节就不能作为订单的属性处理而应该上升为实体。一张订单可以订若干产品，所以订单与订单细节两个实体之间是1：n的联系。
(2)原订单和产品的联系实际上是订单细节和产品的联系。每条订货细节对应一个产品描述，订单处理时从中获得当前单价、产品重量等信息。
(3)工厂对大宗订货给予优惠。每种产品都规定了不同订货数量的折扣，应增加一个“折扣规则”实体存放这些信息，而不应把它们放在产品实体中。
最后得到销售管理子系统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图时并不能简单地将各个E-R图画到一起，而是必须着力消除各个E-R图中的不一致，以形成一个能为全系统中所有用户共同理解和接受的统一的概念模型。合理消除各E-R图的冲突是合并E-R图的主要工作与关键所在。
各子系统的E-R图之间的冲突主要有三类：属性冲突、命名冲突和结构冲突。
①属性冲突
属性冲突主要包含以下两类冲突：
属性域冲突，即属性值的类型、取值范围或取值集合不同。例如零件号，有的部门把它定义为整数，有的部门把它定义为字符型，不同部门对零件号的编码也不同。又如年龄，某些部门以出生日期形式表示职工的年龄，而另一些部门用整数表示职工的年龄。
属性取值单位冲突。例如，零件的重量有的以公斤为单位，有的以斤为单位，有的以克为单位。
属性冲突理论上好解决，但实际上需要各部门讨论协商，解决起来并非易事。
②命名冲突
命名冲突主要包含以下两类冲突：
同名异义，即不同意义的对象在不同的局部应用中具有相同的名字。
异名同义(一义多名)，即同一意义的对象在不同的局部应用中具有不同的名字。
如对科研项目，财务科称为项目，科研处称为课题，生产管理处称为工程。
命名冲突可能发生在实体、联系一级上，也可能发生在属性一级上。其中属性的命名冲突更为常见。处理命名冲突通常也像处理属性冲突一样，通过讨论、协商等行政手段加以解决。
③结构冲突
结构冲突主要包含以下三类冲突：
同一对象在不同应用中具有不同的抽象。例如，职工在某一局部应用中被当作实体，而在另一局部应用中则被当作属性。解决方法通常是把属性变换为实体或把实体变换为属性，使同一对象具有相同的抽象。但变换时仍要遵循上面讲述的两个准则。
同一实体在不同子系统的E-R图中所包含的属性个数和属性排列次序不完全相同。这是很常见的一类冲突，原因是不同的局部应用关心的是该实体的不同侧面。解决方法是使该实体的属性取各子系统的E-R图中属性的并集，再适当调整属性的次序。
实体间的联系在不同的E-R图中为不同的类型。如实体E1与E2在一个E-R图中是多对多联系，在另一个E-R图中是一对多联系；又如在一个E-R图中E1与E2发生联系，而在另一个E-R图中E1、E2、E3三者之间有联系。解决方法是根据应用的语义对实体联系的类型进行综合或调整。
例如，下图(a)中零件与产品之间存在多对多的联系“构成”，图(b)中产品、零件与供应商三者之间还存在多对多的联系“供应”，这两个联系互相不能包含，则在合并两个E-R图时就应把它们综合起来(图(c))。
(2)消除不必要的冗余，设计基本E-R图
在初步E-R图中可能存在一些冗余的数据和实体间冗余的联系。所谓冗余的数据是指可由基本数据导出的数据，冗余的联系是指可由其他联系导出的联系。冗余数据和冗余联系容易破坏数据库的完整性，给数据库维护增加困难，应当予以消除。消除了冗余后的初步E-R图称为基本E-R图。
消除冗余主要采用分析方法，即以数据字典和数据流图为依据，根据数据字典中关于数据项之间逻辑关系的说明来消除冗余。如下图中Q3=Q1×Q2，Q4=∑Q5，所以Q3和Q4是冗余数据，可以消去；并且由于Q3消去，产品与材料间m:n的冗余联系也应消去。
但并不是所有的冗余数据与冗余联系都必须加以消除，有时为了提高效率，不得不以冗余信息作为代价。因此在设计数据库概念结构时，哪些冗余信息必须消除，哪些冗余信息允许存在，需要根据用户的整体需求来确定。如果人为地保留了一些冗余数据，则应把数据字典中数据关联的说明作为完整性约束条件。例如，若物种部门经常要查询各种材料的库存量，如果每次都要查询每个仓库中此种材料的库存，再对它们求和，查询效率就太低了。所以应保留Q4，同时把Q4=∑Q5定义为Q4的完整性约束条件。每当Q5修改后，就触发该完整性检查，对Q4作相应的修改。
除分析方法外，还可以用规范化理论来消除冗余。在规范化理论中，函数依赖的概念提供了消除冗余联系的形式化工具。具体方法如下：
①确定分E-R图实体之间的数据依赖。实体之间一对一、一对多、多对多的联系可以用实体码之间的函数依赖来表示。如下图中：
部门和职工之间一对多的联系可表示为职工号→部门号。
职工和产品之间多对多的联系可表示为(职工号，产品号)→工作天数等。
于是有函数依赖集FL。
②求FL的最小覆盖GL，差集为D=FL-GL。
逐一考察D中的函数依赖，确定是否是冗余的
联系，若是就把它去掉。由于规范化理论受到泛关系假设的限制，应注意下面两个问题：
冗余的联系一定在D中，而D中的联系不一定是冗余的。
当实体之间存在多种联系时，要将实体之间的联系在形式上加以区分。如下图中部门和职工之间另一个一对一的联系就要表示为：
负责人.职工号→部门号，部门号→负责人.职工号
【例2】某工厂管理信息系统的视图集成。
上图为该系统的基本E-R图。集成过程中，解决了以下问题：
· 异名同义，项目和产品含义相同。某个项目实质上是指某个产品的生产，因此统一用产品作实体名。
· 库存管理中，职工与仓库的工作关系已包含在劳动人事管理的部门与职工之间的联系中，所以可以取消。职工之间领导与被领导关系可由部门与职工(经理)之间的领导关系、部门与职工之间的从属关系两者导出，所以也可以取消。
