【数据库设计】数据库设计理论及应用（4）——概念结构设计

数据库设计理论及应用（4）——概念结构设计

作者：最后一只恐龙 发表时间：2007-6-27

该系列计划包括5部分：完整性约束理论及应用、范式理论及应用、需求分析、概念结构设计、逻辑结构设计。本文是第四部分，介绍概念结构设计的内容，包括分E-R的设计、分E-R图的集成、以及基本E-R图的设计。

1．概念模型

概念模型是现实世界到机器世界的一个中间层次，在这个层次中，使用接近计算机存储的方式表示数据，同时又不涉及具体的DBMS。做出概念模型后，再转换为具体的DBMS（如SQL Server或Oracle）下的模型，就成为逻辑模型。

概念模型中包括实体、属性、码、域、联系等概念，在本系列文章的第一部分已作说明，下面再介绍其它几个概念。

1.1两个实体型间的联系

（1）一对一联系：实体集A中的每一个实体，实体集B中至多有一个实体与之有联系，反之亦然，则称实体集A与B具有一对一联系，记为1：1。如班级与班长的联系，一个班只有一个班长，一个班长也只能在一个班级中任职。

（2）一对多联系：实体集A中的每一个实体，实体集B中有n(n≥0)个实体与之有联系；而实体B中的每一个实体，实体A中至多有一个与之有联系，则称实体集A与B具有一对多联系，记为1：n。如班级与学生的联系，一个班有多个学生，一个学生只能在一个班级学习。

（3）多对多联系：实体集A中的每一个实体，实体集B中有n(n≥0)个实体与之有联系；而实体B中的每一个实体，实体A中有m(m≥0)个与之有联系，则称实体集A与B具有多对多联系，记为m：n。如教师与学生的联系，一个教师可以教多名学生，一名学生也可以上多位老师的课。

1.2其它类型的联系

两个以上实体集之间也存在1：1、1：n、m：n的联系。如教师、课程、参考书的联系。注意把这三个实体之间的联系与两两直接的多个联系区分开来。

同一个实体集的各实体之间也存在1：1、1：n、m：n的联系。如职工和职工之间有直接领导的联系。

1.3概念模型的一种表示方法：实体-联系方法

概念模型最著名的方法就是P.P.S.Chen于1976年提出的实体-联系方法，也就是E-R图方法了。E-R图的表示方法：

(1)实体型：用矩形表示，矩形框内写明实体名。

(2)属性：用椭圆表示，并用无向边与相应实体连接起来。

(3)联系：用菱形表示，菱形框内写明联系名，并用无向边分别与有关实体连接起来，同时在无向边上标明关系的类型。

一般E-R图的构造过程是：

（1）根据局部应用的数据流图，设计分E-R图。

（2）将各局部应用的分E-R图合并起来，消除冲突，形成初步E-R图。

（3）消除初步E-R图中的冗余，构造基本E-R图。

下面讨论上篇文章介绍的工厂管理信息系统的E-R图构造方法。先看一下销售子系统的分E-R图。

2．销售子系统的分E-R图

2.1存储实体

根据上节所画的数据流图，我们发现了如下几个数据存储：应收帐款、订单（订单记录本）、产品（产品描述）、待完成订单、发票主清单、发票记录本。我们对这几个存储对象进行分析，明确以下几点：

（1）待完成订单：因为订单完成后开发票，因此没有发票号的订单就可以认为是待完成订单，因此这个实体虽然对用户来讲是必须的，但在设计中没有必要单独存储。

（2）发票主清单和发票记录本：这个数据存储对应手工凭证，发票上的信息在开发票时已存入应收帐款，因此没有必要再存储。

这样，需要存储的实体只剩下应收帐款、订单、产品描述3个。

2.2角色

数据流图中涉及3个角色：顾客、主管部门、生产部门。主管部门和生产部门是实际操作该应用系统的角色，拥有不同权限，这两个角色要到权限管理子系统中设计。

顾客不是操作系统的角色，而是由系统管理的对象，应收帐款和订单都与顾客有联系，因此必须在E-R图中体现。

这样，需要存储的实体又增加了一个：顾客。

2.3分E-R图

根据以上4个实体，我们画出分E-R图的框架。（记得Microsoft Visio Enterprise Architect版上有E-R图设计的，但现在用的是Microsoft Office Visio 2003版，直接就是逻辑结构设计的模型图了，因此没有用Visio画。）

图2.1销售子系统分E-R图架构

对这个架构，做如下说明：

（1）首先分析订单实体：我们拿到一张订单，会发现每张订单由订单号、若干头信息和订单细节组成。订单细节又有序号、零件号、数量等描述。这样订单细节具有需要描述的性质，因此不能作为属性对待，而应上升为一个实体（也就是一条细节对应一条记录），一张订单可以订若干产品，因此订单与订单细节直接是1：n联系。

（2）原订单与产品之间的联系，实际上是订单细节与产品的联系。订单处理时，从产品中获得当前价格等信息。

（3）在需求分析过程中，发现工厂对大宗订货有优惠，每种产品都规定了不同订货数量的折扣。因为每种产品根据订货数量的不同，折扣不同，因此折扣规则应单独作为一个实体，而不应放到产品描述实体中。

图2.2销售子系统分E-R图

经过以上分析，我们可以画出该子系统的分E-R图：

需要特别注意的是，该分E-R图的订单细节实体是有问题的。我们选择了序号作为订单细节的唯一标识，这在一张订单中是没有问题的，但放到全局中，它并不能准确定位一个订单细节，因为我们只有知道的该细节是哪张订单的，才能准确知道对应哪条记录。关于这一点的处理在下篇文章中介绍。

3．视图的集成

各子系统的分E-R图设计完成以后，下一步就是把所有的分E-R图合并成一个总E-R图，这个总E-R图称为初步E-R图。

视图集成的方法可以是一次集成，也可以分步集成（比如每次集成两个，直到最后都集成到一起）。

在集成过程中，经常碰到分E-R图有冲突的情况，具体如下。

3.1合并过程中的冲突及解决方法

（1）属性冲突

i）属性域冲突：即属性值的类型、取值范围或取值集合不同，如零件号，有的部门作为整数对待，有的部门则使用字符串。不同部门对零件号的编码也可能不同。

解决办法：统一起来就是了，只是这个过程不太容易。

ii）属性取值单位冲突：如零件重量，有的部门以公斤为单位，有的部门以克为单位。

解决办法：部门间协商解决，但也不容易。试想一下，管螺栓的部门自然希望以克为单位，而管几百斤重的零件的部门则希望以公斤为单位；即使零件重量差别没有这么大，习惯也是个问题。

（2）命名冲突

包括同名异义和异名同义。如科研项目，财务科称为项目，科研处称为课题，生产管理处称为工程，这就是一个异名同义的例子。

解决办法：协商或采用行政手段加以解决。当然如果你不嫌麻烦，也可以自己先统一起来，然后为不同用户定义不同的视图，使不同用户看到的是适合自己的别名。

（3）结构冲突

图3.1物资子系统分E-R图

i）同一对象在不同应用中有不同的抽象：如在教学管理中，职称是一个属性；而在人事管理中，因为职称与工资、住房挂钩，因此是一个实体。

解决办法：把属性变换为实体。

ii）同一实体在不同分E-R图中包含的属性个数不完全相同。

解决办法：取并集。

iii）实体间的联系在不同分E-R图中为不同类型：如生产子系统分E-R图中，产品和零件构成1：n联系。而物资子系统分E-R图中，产品、零件、供应商三者构成多对多联系。

图3.2人事子系统分E-R图

解决办法：根据应用的语义进行综合或调整。

3.2实例

对工厂的E-R图，现在仅完成了销售子系统的分E-R图（图2.2）。而其它两个小组则完成了物资子系统（图3.1）和人事子系统（图3.2）的分E-R图（因为篇幅关系，没有画出属性）。

现在要把它们合并起来，经分析，发现三个图中的“产品描述”实体和“项目”实体存在异名同义的冲

图3.3初步E-R图

突，把名字统一为“产品”，得到初步E-R图（图3.3）。

4．设计基本E-R图

初步E-R图中，还可能存在数据冗余，需要将这些冗余消除。冗余大致可分为两类：

l冗余数据：存在可由基本数据导出的数据；

l冗余联系：存在可由其它联系导出的联系。

图4.1是一个数据冗余的例子，其中有两个冗余：

（1）产品使用材料的“用量”，可以通过其使用的零件，以及每个零件消耗材料的“消耗量”计算出来。

（2）每种材料的“总存量”，可以通过每个仓库中存放该零件的“存放量”累加得到。

寻找这些冗余的方法，一是本文这种分析方法，另一种方法是求数据依赖集的最小覆盖的方法。后一种方法数学理论要求比较高，就不介绍了。

消除掉这些冗余信息后，就得到了基本E-R图，整个概念结构设计过程也宣告完成。

http://blog.csdn.net/octverve/article/details/1809548