7.3 概念结构设计将需求分析得到的用户需求抽象为信息结构即概念模型的过程就是概念结构设计。

它是整个数据库设计的关键。

(概念结构是对用户需求的客观反映，不涉及到软硬件环境，也不能直接在数据库管理系统DBMS上实现，是现实世界与机器世界的中介。

这一阶段所产生的工作结果一般表现为E-R图的形式，它不仅能够充分反映客观世界，而且易于非计算机人员理解，易于向关系、网状、层次等各种数据模型转换。

)7.3.1 概念结构在需求分析阶段所得到的应用需求应该首先抽象为信息世界的结构，才能更好地、更准确地用某一DBMS实现这些需求。

概念结构的主要特点是:(1) 能真实、充分地反映现实世界，包括事物和事物之间的联系，能满足用户对数据的处理要求。

是对现实世界的一个真实模型。

(2) 易于理解，从而可以用它和不熟悉计算机的用户交换意见，用户的积极参与是数据库的设计成功的关键。

(3) 易于更改，当应用环境和应用要求改变时，容易对概念模型修改和扩充。

(4) 易于向关系、网状、层次等各种数据模型转换。

概念结构是各种数据模型的共同基础，它比数据模型更独立于机器、更抽象，从而更加稳定。

描述概念模型的有力工具是E-R模型。

有关E-R模型的基本概念已在第一章介绍。

下面将用E-R模型来描述概念结构。

7.3.2 概念结构设计的方法与步骤设计概念结构通常有四类方法:·自顶向下。

即首先定义全局概念结构的框架，然后逐步细化，如图7.7(a)所示。

·自底向上。

即首先定义各局部应用的概念结构，然后将它们集成起来，得到全局概念结构，如图7.7（b）所示。

·逐步扩张。

首先定义最重要的核心概念结构，然后向外扩充，以滚雪球的方式逐步生成其他概念结构，直至总体概念结构，如图7.7(c)所示。

·混合策略。

即将自顶向下和自底向上相结合，用自顶向下策略设计一个全局概念结构的框架，以它为骨架集成由自底向上策略中设计的各局部概念结构。

其中最经常采用的策略是自底向上方法。

即自顶向下地进行需求分析，然后再自底向上地设计概念结构。

如图7.8所示。

这里只介绍自底向上设计概念结构的方法。

它通常分为两步:第1步是抽象数据并设计局部视图，第2步是集成局部视图，得到全局的概念结构，如图7.9所示。

(a)自顶向下策略(b)自底向上策略(c)逐步扩张策略图7.7设计概念结构的策略图7.8 自顶向下分析需求与自底向上设计概念结构图7.9概念结构设计步骤7.3.3数据抽象与局部视图设计概念结构是对现实世界的一种抽象。

所谓抽象是对实际的人、物、事和概念进行人为处理，抽取所关心的共同特性，忽略非本质的细节，并把这些特性用各种概念精确地加以描述，这些概念组成了某种模型。

一般有三种抽象:1.分类 (Classification)定义某一类概念作为现实世界中一组对象的类型。

这些对象具有某些共同的特性和行为。

它抽象了对象值和型之间的”is member of”的语义。

在E-R模型中，实体型就是这种抽象。

例如在学校环境中，张英是学生 (如图7.10所示)，表示张英是学生中的一员(is member of 学生)，具有学生们共同的特性和行为:在某个班学马某种专业，选修某些课程。

图7.10分类2.聚集 (Aggregation)定义某一类型的组成成分。

它抽象了对象内部类型和成分之间"is part of"的语义。

在E-R模型中若干属性的聚集组成了实体型，就是这种抽象，如图7.11所示。

更复杂的聚集如图7.12所示，即某一类型的成分仍是一个聚集。

图7.11聚集图7.12更复杂的聚集3.概括(Generalization)定义类型之间的一种子集联系。

它抽象了类型之间的“is subset of”的语义。

例如学生是一个实体型，本科生、研究生也是实体型。

本科生、研究生均是学生的子集。

把学生称为超类 (Superclass)，本科生、研究生称为学生的子类 (Subclass)。

原E-R模型不具有概括，本书对E-R模型作了扩充，允许定义超类实体型和子类实体型。

并用双竖边的矩形框表示子类，用直线加小圆圈表示超类-子类的联系(如图7.13所示)。

图7.13 概括概括有一个很重要的性质:继承性。

子类继承超类上定义的所有抽象。

这样，本科生、研究生继承了学生类型的属性。

当然，子类可以增加自己的某些特殊属性。

概念结构设计的第一步就是利用上面介绍的抽象机制对需求分析阶段收集到的数据进行分类、组织 (聚集)，形成实体、实体的属性，标识实体的码，确定实体之间的联系类型(1:1，l:n，m:n)，设计分E-R图。

具体做法是:1.选择局部应用根据某个系统的具体情况，在多层的数据流图中选择一个适当层次的数据流图，作为设计分E-R图的出发点。

让这组图中每一部分对应一个局部应用。

由于高层的数据流图只能反映系统的概貌，而中层的数据流图能较好地反映系统中各局部应用的子系统组成，因此人们往往以中层数据流图作为设计分E-R图的依据(如图7.14所示)。

图7.14设汁分E-R图的出发点2.逐一设计分E-R图选择好局部应用之后，就要对每个局部应用还不设计分E-R图，亦称局部E-R图。

在前面选好的某一层次的数据流图中，每个局部应用都对应了一组数据流图，局部应用涉及的数据都已经收集在数据字典中了。

现在就是要将这些数据从数据字典中抽取出来，参照数据流图，标定局部应用中的实体、实体的属性、标识实体的码，确定实体之间的联系及其类型。

事实上，在现实世界中具体的应用环境常常对实体和属性已经作了大体的自然的划分。

在数据字典中，"数据结构"、"数据流"和"数据存储"都是若干属性有意义的聚合，就体现了这种划分。

可以先从这些内容出发定义E-R图，然后再进行必要的调整。

在调整中遵循的一条原则是:为了简化E-R图的处置，现实世界的事物能作为属性对待的，尽量作为属性对待。

那么符合什么条件的事物可以作为属性对待呢?本来，实体与属性之间并没有形式上可以截然划分的界限，但可以给出(划分实体与属性的)两条准则:(1) 作为"属性"，不能再具有需要描述的性质。

"属性"必须是不可分的数据项，不能包含其他属性。

(2) "属性"不能与其他实体具有联系，即E-R图中所表示的联系是实体之间的联系。

凡满足上述两条准则的事物，一般均可作为属性对待。

例如:职工是一个实体，职工号、姓名、年龄是职工的属性，职称如果没有与工资、福利挂钩，换句话说，没有需要进一步描述的特性，则根据准则(1)可以作为职工实体的属性。

但如果不同的职称有不同的工资、住房标准和不同的附加福利，则职称作为一个实体看待就更恰当，如图7.15所示;图7.15职称作为一个实体再如，在医院中，一个病人只能住在一个病房，病房号可以作为病人实体的一个属性。

但如果病房还要与医生实体发生联系，即一个医生负责几个病房的病人的医疗工作，则病房根据准则(2)应作为一个实体，如图7.16所示。

图7.16病房作为属性或一个实体又如，如果一种货物只存放在一个仓库，那么就可以把存放货物的仓库的仓库号作为描述货物存放地点的属性。

但如果一种货物可以存放在多个仓库中，或者仓库本身又用面积作为属性，或者与职工发生管理上的联系，那么就应把仓库作为一个实体，如图7.17所示。

图7.17仓库作为一个实体实例销售管理子系统分E-R图的设计。

某工厂开发管理信息系统，经过可行性分析和详细调查，确定了该系统由物资管理、销售管理、劳动人事管理等子系统组成。

为每个子系统组成了开发小组。

销售管理子系统开发小组的成员经过调查研究、信息流程分析和数据收集，明确了该子系统的主要功能是:处理顾客和销售员送来的订单；工厂是根据订货安排生产的；交出货物同时开出发票；收到顾客付款后，根据发票存根和信贷情况进行应收款处理，得到了该子系统二层数据流图(共5张)和数据字典，其中包括14个数据结构和29个数据流 (总共14个矩形或半矩形，29个箭头) 。

(注：牵涉到的14个数据结构并不都是独立的，有些数据结构是多个子系统共享的，仔细观察几个子图就会发现。

)图7.18是第一层数据流图。

虚线部分划出了系统边界。

图中把系统功能又分为四个子系统。

图7.19至图7.22是第二层数据流图。

由于该子系统不太复杂，设计分E-R图可以从图7.18第一层数据流图入手。

若某一局部应用仍比较复杂，则可以从更下层的数据流图入手。

例如，从图7.19至图7.22开始，分别设计它们的分E-R图，再汇总成该局部应用的分E-R图。

分析图7.18和数据字典，知道整个系统功能围绕了“订单”和“应收账款”的处理。

数据结构中订单、顾客、顾客应收账目用得最多，是许多子功能、数据流共享的数据，因此先设计该分E-R图的草图(如图7.23所示)。

图7.18 销售管理子系统第一层数据流图图7.19 接收订单图7.20 处理订单图7.21 开发票图7.22 支付过账图7.23 分E-R图的框架然后参照第二层数据流图和数据字典中的详尽描述，遵循前面给出的(划分实体与属性的)两个准则，进行了如下调整，(1)每张订单由订单号、若干头信息和订单细节组成。

订单细节又有订货的零件号、数量等来描述。

按照准则(2)，订单细节就不能作订单的属性处理而应该上升为实体。

一张订单可以订若干产品，所以订单与订单细节两个实体之间是l:n的联系。

(2) 原订单和产品的联系实际上是订单细节和产品的联系。

每条订货细节对应一个产品描述，订单处理时从中获得当前单价、产品重量等信息。

(3) 图7.21中“发票清单”是一个数据存储，是否应作为实体加入分E-R 图呢? 答案是不必。

这里的数据存储对应手工凭证，发票上的信息在开具发票的同时已及时存入应收账款中了。

(4) 工厂对大宗订货给予优惠。

每种产品都规定了不同订货数量的折扣，应增加一个“折扣规则”实体存放这些信息，而不应把它们放在产品描述实体中。

最后得到分E-R图如图7.24所示。

对每个实体定义的属性如下：顾客：｛顾客号，顾客名，地址，电话，信贷状况，账目余额｝订单：｛订单号，顾客号，订货项数，订货日期，交货日期，工种号，生产地点｝订单细则:｛订单号，细则号，零件号，订货数，金额｝应收账款:｛顾客号，订单号，发票号，应收金额，支付日期，支付金额，当前余额，货款限额｝产品描述：｛产品号，产品名，单价，重量｝折扣规则：｛产品号，订货量，折扣｝(注意:为了节省篇幅，实体与属性的关系没有用图形表示，实体的标识码用下横线划出)。

图7.24 销售管理子系统的分E-R图(注：销售管理子系统虽然还牵涉到其它实体，但未必都由这个子系统来负责给出定义；因为还有物资管理、劳动人事管理等子系统都在同时开发，还有总体设计人员也在工作。