概念结构设计
概念结构设计的第一步就是对需求分析阶段收集到的数据进行分类、组织，确定实体、实体的属性、实体之间的联系类型，形成E-R图。首先，如何确定实体和属性这个看似简单的问题常常会困扰设计人员，因为实体与属性之间并没有形式上可以截然划分的界限。
- 实体与属性的划分原则
在整体中遵循的一条原则是:为了简化E-R图的处置，现实世界的事物能作为属性对待的尽量作为属性对待。
（1） 作为属性，不能再具有需要描述的性质，即属性必须是不可分的数据项，不能包含其他属性。
（2） 属性不能与其他实体具有联系，即E-R图中所表示的联系是实体之间的联系。
- 例1：职工是一个实体，职工号、姓名、年龄是职工的属性，职称如果没有与工资、岗位津贴、福利挂钩，换句话说，没有需要进一步描述的特性，则根据准则(1)可以作为职工实体的属性;但如果不同的职称有不同的工资、岗位津贴和不同的附加福利，则职称作为一个实体看待就更恰当，如图7.19所示。
-
例2：销售管理子系统E-R图
某工厂开发管理信息系统，经过可行性分析，详细调查确定了该系统由物资管理、销售管理、劳动人事管理等子系统组成。为每个子系统组成了开发小组。
销售管理子系统开发小组的成员经过调查研究、信息流程分析和数据收集，明确了该子系统的主要功能是:处理顾客和销售员送来的订单;工厂是根据订货安排生产的;交出货物同时开出发票;收到顾客付款后，根据发票存根和信贷情况进行应收款处理。通过需求分析，知道整个系统功能围绕“订单”和“应收账款”的处理来实现。数据结构中订单、顾客、顾客应收账目用得最多，是许多子功能、数据流共享的数据，因此先设计该E-R图的草图。
然后参照需求分析和数据字典中的详尽描述,遵循前面给出的两个准则,进行了如下一些调整:
(1）每张订单由订单号、若干头信息和订单细节组成。订单细节又有订货的零件号、数量等来描述。按照第二条准则,订单细节就不能作为订单的属性处理而应该上升为实体。张订单可以订若干产品,所以订单与订单细节两个实体之间是1:n的联系。
(2)原订单和产品的联系实际上是订单细节和产品的联系。每条订货细节对应一个产品描述，订单处理时从中获得当前单价、产品重量等信息。
(3）工厂对大宗订货给予优惠。每种产品都规定了不同订货数量的折扣，应增加一个“折扣规则”实体存放这些信息，而不应把它们放在产品实体中。
最后得到销售管理子系统E-R图如图7.23所示。
对每个实体定义的属性如下所示。
- E-R图的集成
在开发一个大型信息系统时，最经常采用的策略是自顶向下地进行需求分析，然后再自底向上地设计概念结构。即首先设计各子系统的分E-R图，然后将它们集成起来，得到全局E-R图。E-R图的集成一般需要分两步走,如图7.24所示。
(1）合并E-R图，生成初步E-R图
①属性冲突
属性冲突主要包含以下两类冲突:
·属性域冲突，即属性值的类型、取值范围或取值集合不同。例如零件号，有的部门把它定义为整数，有的部门把它定义为字符型，不同部门对零件号的编码也不同。又如年龄，某些部门以出生日期形式表示职工的年龄，而另一些部门用整数表示职工的年龄。
。属性取值单位冲突。例如，零件的重量有的以公斤为单位，有的以斤为单位，有的以克为单位。
属性冲突理论上好解决，但实际上需要各部门讨论协商，解决起来并非易事。②命名冲突
命名冲突主要包含以下两类冲突:
。同名异义，即不同意义的对象在不同的局部应用中具有相同的名字。风·异名同义（一义多名)，即同一意义的对象在不同的局部应用中具有不同的名字。如对科研项目，财务科称为项目，科研处称为课题，生产管理处称为工程。
命名冲突可能发生在实体、联系一级上，也可能发生在属性一级上。其中属性的命名冲突更为常见。处理命名冲突通常也像处理属性冲突一样，通过讨论、协商等行政手段加以解决。
③结构冲突
结构冲突主要包含以下三类冲突:
。同一对象在不同应用中具有不同的抽象。例如,职工在某一局部应用中被当作实体，而在另一局部应用中则被当作属性。解决方法通常是把属性变换为实体或把实体变换为属性，使同一对象具有相同的抽象。但变换时仍要遵循7.3.5小节中讲述的两个准则。
。同一实体在不同子系统的E-R图中所包含的属性个数和属性排列次序不完全相同。这是很常见的一类冲突，原因是不同的局部应用关心的是该实体的不同侧面。解决方法是使该实体的属性取各子系统的E-R图中属性的并集，再适当调整属性的次序。
。实体间的联系在不同的E-R图中为不同的类型。如实体E1与E2在一个E-R图中是多对多联系，在另一个E-R图中是一对多联系;又如在一个E-R图中El与E2发生联系，而在另一个E-R图中E1、E2、E3三者之间有联系。解决方法是根据应用的语义对实体联系的类型进行综合或调整。
例如，图7.25(a)中零件与产品之间存在多对多的联系“构成”，图 7.25(b)中产品、零件与供应商三者之间还存在多对多的联系“供应”，这两个联系互相不能包含，则在合并两个E-R图时就应把它们综合起来(图7.25(c))。
(2）消除不必要的冗余，设计基本E-R图
在初步E-R图中可能存在一些冗余的数据和实体间冗余的联系。所谓冗余的数据是指可由基本数据导出的数据，冗余的联系是指可由其他联系导出的联系。冗余数据和冗余联系容易破坏数据库的完整性，给数据库维护增加困难，应当予以消除。消除了冗余后的初步E-R图称为基本E-R图。
消除冗余主要采用分析方法，即以数据字典和数据流图为依据，根据数据字典中关于数据项之间逻辑关系的说明来消除冗余。如图7.26中 Q3-Q1*Q，Q4=EQs，所以Q;和Q4是冗余数据，可以消去;并且由于O,消去，产品与材料间m:n的冗余联系也应消去。
但并不是所有的冗余数据与冗余联系都必须加以消除，有时为了提高效率，不得不以冗余信息作为代价。因此在设计数据库概念结构时，哪些冗余信息必须消除，哪些冗余信息允许存在，需要根据用户的整体需求来确定。如果人为地保留了一些冗余数据，则应把数据字典中数据关联的说明作为完整性约束条件。例如，若物种部门经常要查询各种材料的库存量，如果每次都要查询每个仓库中此种材料的库存，再对它们求和，查询效率就太低了。所以应保留Oa，同时把O=EQs定义为Q的完整性约束条件。每当Os修改后，就触发该完整性检查,对O4作相应的修改。
- 例：[例7.2] 某工厂管理信息系统的视图集成。
图7.11、图7.23、图7.27分别为该厂物资、销售和劳动人事管理的分E-R图。图7.28为该系统的基本E-R图。这里基本E-R图中各实体的属性因篇幅有限从略。
集成过程中,解决了以下问题:
·异名同义，项目和产品含义相同。某个项目实质上是指某个产品的生产，因此统一用产品做实体名。
库存管理中，职工与仓库的工作关系已包含在劳动人事管理的部门与职工之间的联系中，所以可以取消。职工之间领导与被领导关系可由部门与职工(经理）之间的领导关系、部门与职工之间的从属关系两者导出,所以也可以取消。
