7.3 概念结构设计(S)

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所示。