数据库系统原理及应用教程(第5版)
上QQ阅读APP看书,第一时间看更新

3.3 数据库概念结构的设计

概念结构设计是将系统需求分析得到的用户需求抽象为信息结构的过程。概念结构设计的结果是数据库的概念模型。数据库设计中应十分重视概念结构设计,它是整个数据库设计的关键。

3.3.1 概念结构的特点及设计方法

只有将系统应用需求抽象为信息世界的结构(概念结构),才能转化为机器世界中的数据模型,并用DBMS实现这些需求。概念结构即概念模型,它用E-R图进行描述。

1.概念结构的特点

概念结构独立于数据库逻辑结构,同时还支持数据库的DBMS,其主要特点如下。

1)概念模型是现实世界的一个真实模型:概念模型应能真实、充分地反映现实世界,能满足用户对数据的处理要求。

2)概念模型应当易于理解:概念模型只有被用户理解后,才可以与设计者交换意见,参与数据库的设计。

3)概念模型应当易于更改:由于现实世界(应用环境和应用要求)会发生变化,这就需要改变概念模型,易于更改的概念模型有利于修改和扩充。

4)概念模型应易于向数据模型转换:概念模型最终要转换为数据模型。设计概念模型时应当注意,使其有利于向特定的数据模型转换。

2.概念结构设计的方法

概念模型是数据模型的前身,它比数据模型更独立于机器、更抽象,也更加稳定。概念结构设计的方法有4种。

1)自顶向下的设计方法:首先定义全局概念结构的框架,然后逐步细化为完整的全局概念结构。

2)自底向上的设计方法:首先定义各局部应用的概念结构,然后将它们集成起来,得到全局概念结构的设计方法。

3)逐步扩张的设计方法:首先定义最重要的核心概念结构,然后向外扩充,生成其他概念结构,直至完成总体概念结构。

4)混合策略设计的方法:采用自顶向下与自底向上相结合的方法,首先用自顶向下策略设计一个全局概念结构的框架,然后以它为骨架,通过自底向上策略中设计的各局部概念结构,其方法如图3-6所示。

978-7-111-64633-4-Chapter03-8.jpg

图3-6 自顶向下分析需求与自底向上设计概念结构

3.概念结构的设计步骤

按照图3-6所示的设计概念结构方法,概念结构的设计可分为两步:第一步是抽象数据并设计局部视图;第二步是集成局部视图,得到全局的概念结构,设计步骤如图3-7所示。

978-7-111-64633-4-Chapter03-9.jpg

图3-7 概念结构设计步骤

3.3.2 数据抽象与局部视图设计

概念结构是对现实世界的一种抽象。所谓抽象就是抽取现实世界的共同特性,忽略非本质的细节,并把这些共同特性用各种概念精确地加以描述,形成某种模型。

1.3种数据抽象方法

数据抽象的3种基本方法是分类、聚集和概括。利用数据抽象方法可以在对现实世界抽象的基础上,得出概念模型的实体集及属性。

(1)分类

分类(Classification)就是定义某一类概念作为现实世界中一组对象的类型,这些对象具有某些共同的特性和行为。分类抽象了对象值和型之间的“成员”的语义。在E-R模型中,实体集就是这种抽象。

例如,在企业环境中,张小英是职工中的一员,她具有职工们共有的特性和行为:在某个部门工作,参与某个工程的设计或施工。与张小英属同一对象的还有王丽平等其他职工。图3-8是职工的分类示意图。

978-7-111-64633-4-Chapter03-10.jpg

图3-8 职工分类示意图

(2)聚集

聚集(Aggregation)是定义某一类型的组成部分,它抽象了对象内部类型和对象内部“组成部分”的语义。若干属性的聚集组成了实体型。例如,把实体集“职工”的“职工号”“姓名”等属性聚集为实体型“职工”,如图3-9所示。

事实上,现实世界的事物是非常复杂的,某些类型的组成部分可能仍然是一个聚集,这是一种更复杂的聚集,如图3-10所示。

978-7-111-64633-4-Chapter03-11.jpg

图3-9 职工属性聚集实例

978-7-111-64633-4-Chapter03-12.jpg

图3-10 更复杂的聚集

(3)概括

概括(Generalization)定义了类型之间的一种子集联系,它抽象了类型之间“所属”的语义。例如,职工是个实体集,技术人员、干部也是实体集,但技术人员、干部均是职工的子集。可把职工称为超类(Superclass),技术人员、干部称为职工的子类(Subclass)。在E-R模型中用双竖边的矩形框表示子类,用直线加小圆圈表示超类—子类的联系,如图3-11所示。

978-7-111-64633-4-Chapter03-13.jpg

图3-11 概括表示示意图

概括的一个重要性质是继承性。继承性指子类继承超类中定义的所有抽象。例如,技术人员、干部可以有自己的特殊属性,但都继承了它们的超类属性,即技术人员和干部都具有职工类型的属性。

2.设计分E-R图

概念结构设计是利用抽象机制对需求分析阶段收集到的数据进行分类、组织(聚集),形成实体集、属性和码,确定实体集之间的联系类型(一对一、一对多或多对多的联系),进而设计分E-R图。

(1)设计分E-R图的具体做法

1)选择局部应用。

选择局部应用是根据系统的具体情况,在多层的数据流程图中选择一个适当层次的数据流程图,作为设计分E-R图的出发点,并让数据流程图中的每一部分都对应一个局部应用。选择好局部应用之后,就可以对每个局部应用逐一设计分E-R图了。

2)设计分E-R图。

在设计分E-R图前,局部应用的数据流程图应已经设计好,局部应用所涉及的数据应当也已经收集在相应的数据字典中了。在设计分E-R图时,要根据局部应用的数据流程图中标定的实体集、属性和码,并结合数据字典中的相关描述内容,确定E-R图中的实体、实体之间的联系。

(2)实体和属性的区别

实际上,实体和属性之间并不存在形式上可以截然划分的界限。但是,在现实世界中具体的应用环境常常对实体和属性做了大体的自然划分。例如,在数据字典中,“数据结构”“数据流”“数据存储”都是若干属性的聚合,它体现了自然划分意义。设计E-R图时,可以先从自然划分的内容出发定义雏形的E-R图,再进行必要的调整。

为了简化E-R图,在调整中应当遵循的一条原则:现实世界的事物能作为属性对待的尽量作为属性对待。在解决这个问题时应当遵循两条基本准则。

1)“属性”不能再具有需要描述的性质。“属性”必须是不可分割的数据项,不能包含其他属性。也就是说,属性不能是另外一些属性的聚集。

2)“属性”不能与其他实体具有联系。在E-R图中所有的联系必须是实体间的联系,而不能有属性与实体之间的联系。

图3-12所示的是一个由属性上升为用实体集表示的实例。

978-7-111-64633-4-Chapter03-14.jpg

图3-12 “职称”由属性上升为实体的示意图

图3-12中,职工是一个实体,职工号、姓名、年龄和职称是属性。如果职称没有与工资、福利挂钩,就没有必要进一步描述,可以作为职工实体集的一个属性对待;如果不同的职称有着不同的工资、住房标准和不同的附加福利,则职称作为一个实体来考虑就比较合适。

例如,在医院一个病人只能住在一个病房,病房号可以作为病人实体的一个属性。但如果病房还要与医生实体发生联系,即一个医生负责几个病房的病人,根据第二条准则,病房应作为一个实体,如图3-13所示。

978-7-111-64633-4-Chapter03-15.jpg

图3-13 病房作为一个属性或实体的例子

3.3.3 视图集成

视图集成就是把设计好的各子系统的分E-R图综合成一个系统的总E-R图。

视图集成有两种方法:一种方法是多个分E-R图一次集成,如图3-14a所示;另一种方法是逐步集成,用累加的方法一次集成两个分E-R图,如图3-14b所示。

978-7-111-64633-4-Chapter03-16.jpg

图3-14 视图集成的两种方法

a)一次集成 b)逐步集成

多个分E-R图一次集成的方法比较复杂,做起来难度较大;逐步集成方法由于每次只集成两个分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图之间的冲突主要有3类:属性冲突、命名冲突和结构冲突。

(1)属性冲突

属性冲突主要有以下两种情况。

1)属性域冲突。属性值的类型、取值范围或取值集合不同。例如,对于零件号属性,不同的部门可能会采用不同的编码形式,而且定义的类型又各不相同,有的定义为整型,有的则定义为字符型,这都需要各个部门之间协商解决。

2)属性取值单位冲突。例如,零件的重量,不同的部门可能分别用公斤、斤或千克来表示,结果会给数据统计造成错误。

(2)命名冲突

命名冲突主要有以下两种。

1)同名异义冲突:不同意义的对象在不同的局部应用中具有相同的名字。

2)异名同义冲突:意义相同的对象在不同的局部应用中有不同的名字。

(3)结构冲突

结构冲突有以下3种情况。

1)同一对象在不同的应用中具有不同的抽象。例如,职工在某一局部应用中被当作实体对待,而在另一局部应用中被当作属性对待,这就会产生抽象冲突问题。

2)同一实体在不同分E-R图中的属性组成不一致。此类冲突即所包含的属性个数和属性排列次序不完全相同。这类冲突是由于不同的局部应用所关心的实体的不同侧面而造成的。解决这类冲突的方法是使该实体的属性取各个分E-R图中属性的并集,再适当调整属性的次序,使之兼顾到各种应用。

3)实体之间的联系在不同的分E-R图中呈现不同的类型。此类冲突的解决方法是根据应用的语义对实体联系的类型进行综合或调整。

设有实体集E1、E2和E3,在一个分E-R图中E1和E2是多对多联系,而在另一个分E-R图中E1、E2是一对多联系,这是联系类型不同的情况;在某一E-R图中E1与E2发生联系,而在另一个E-R图中E1、E2和E3三者之间发生联系,这是联系涉及的对象不同的情况。

图3-15所示的是一个综合E-R图的实例。在一个分E-R图中零件与产品之间的联系构成是多对多的;另一个分E-R图中产品、零件与供应商三者之间存在着多对多的联系“供应”;在合并的综合E-R图中把它们综合起来表示。

978-7-111-64633-4-Chapter03-17.jpg

图3-15 合并两个分E-R图时的综合

2.消除不必要的冗余,设计基本E-R图

在初步E-R图中可能存在冗余的数据和实体间冗余的联系。冗余数据是指可由基本数据导出的数据,冗余的联系是可由其他联系导出的联系。冗余的存在容易破坏数据库的完整性,给数据库维护增加困难,应当消除。消除了冗余的初步E-R图就称为基本E-R图。

(1)用分析方法消除冗余

分析方法是消除冗余的主要方法。分析方法消除冗余是以数据字典和数据流程图为依据,根据数据字典中关于数据项之间逻辑关系的说明来消除冗余的。

在实际应用中,并不是要将所有的冗余数据与冗余联系都消除。有时为了提高数据查询效率,减少数据存取次数,在数据库中就设计了一些数据冗余或联系冗余。因而,在设计数据库结构时,冗余数据的消除或存在要根据用户的整体需要来确定。如果希望存在某些冗余,则应在数据字典的数据关联中进行说明,并把保持冗余数据的一致作为完整性约束条件。

例如,在图3-16中,如果Q3=Q1×Q2并且Q4=ΣQ5,则Q3和Q4是冗余数据,Q3和Q4就可以被消去。而消去了Q3,产品与材料间m∶n的冗余联系也应当被消去。但是,若物资部门经常要查询各种材料的库存总量,就应当保留Q4,并把“Q4=ΣQ5”定义为Q4的完整性约束条件。每当Q5被更新,就会触发完整性检查的例程,以便对Q4做相应的修改。

978-7-111-64633-4-Chapter03-18.jpg

图3-16 消除冗余的实例

(2)用规范化理论消除冗余

在关系数据库的规范化理论中,函数依赖的概念提供了消除冗余的形式化工具,有关内容将在规范化理论中介绍。