资源描述
,第二级,第三级,第四级,第五级,第,8,章,关系规范化理论与数据库设计,第8章 关系规范化理论与数据库设计,8.1 函数依赖,8.2 规范化和范式,8.3 数据库设计概述,8.4 需求分析,8.5 概念结构设计,8.6 逻辑结构设计,8.7 物理结构设计,8.8 数据库的实施和维护,习题,8.1 函 数 依 赖,建立一个关系数据库系统，首先要考虑怎样建立数据模式，即应该构造几个关系模式，每个关系模式中需要包含哪些属性等，这是数据库设计的问题。关系规范化主要讨论的就是建立关系模式的指导原则，所以有人把规范化理论称为设计数据库的理论。,数据依赖是通过一个关系中属性间值的依赖与否体现出来的数据间的相互关系，它是现实世界属性间相互联系的抽象，是数据内在的性质，是语义的体现。现在人们已经提出了许多种类型的数据依赖，其中最重要的是函数依赖(,FD，Functional Dependency),和多值依赖(,MVD，,Multivalued,Dependency)。,这里只讨论函数依赖，有关多值依赖的概念，有兴趣的读者可以参阅有关书籍。,函数依赖极为普遍地存在于现实生活中。比如描述一个学生的关系，可以有学号(,SNO)，,姓名(,SNAME),和系名(,SDEPT),等几个属性。由于一个学号只对应一个学生，一个学生只在一个系学习，因而当“学号”值确定以后，姓名和该生所在系的值也就被惟一的确定了。就象自变量,x,确定以后，相应的函数值,f(x),也就惟一地确定了一样，称,SNO,函数决定,SNAME,和,SDEPT，,或者说,SNAME,和,SDEPT,函数依赖于,SNO，,记为,SNOSNAMESNOSDEPT,用形式化的方式表示，关系模式,R,可以记为,R,其中,U,表示一组属性的集合，,F,表示属性组,U,上的一组数据依赖集合。对于上述的学生关系，可有,U = SNO，SNAME，SDEPT,F = SNOSNAME，SNOSDEPT,对于关系模式,R，,当且仅当,U,上的一个关系,r,满足,F,时，称,r,为关系模式,R,的一个关系。,定义8,-,1,设,R(U),是属性集,U,上的关系模式，,X，Y,是,U,的子集。若对于,R(U),的任意一个可能的关系,r，r,中不可能存在两个元组在,X,上的属性值相等，而在,Y,上的属性值不等，则称,X,函数确定,Y,或,Y,函数依赖于,X，,记为,XY。,注意，函数依赖不是指关系模式,R,的某个或某些关系满足的约束条件，而是指,R,的一切关系均需要满足的约束条件。,函数依赖是语义范畴的概念，我们只能根据语义来确定函数依赖。例如在没有同名的情况下，,NAMEAGE，,而在有同名的情况下，这个函数依赖就不成立了。,下面介绍一些术语和记号：, 若,XY，,则,X,叫做决定因素。, 若,XY，YX，,则记为,XY。,若,Y,不函数依赖于,X，,则记为,XY。,若,XY，,但,Y X，,则称,XY,是平凡的函数依赖。, 若,XY，,但,Y X，,则称,XY,是非平凡的函数依赖。若不特别声明，下面总是指非平凡的函数依赖。,函数依赖可分为三类：完全函数依赖，部分函数依赖和传递函数依赖。这三类函数依赖定义如下：,(1) 完全函数依赖。,定义8,-,2,在,R(U),中，如果,XY，,并且对于,X,的任何一个真子集,X，,都有,XY，,则称,Y,对,X,完全函数依赖，记为,X Y。,可简写为 。,例8,-,1,在关系,S(SNO，SNAME，SDEPT),中，,SNOSNAME，SNOSDEPT。,用图解表示如图8-1所示。,若关系中没有同姓名的学生，则用,SNO,可以惟一确定,SNAME,，,用,SNAME,也可惟一确定,SNO,，,形成了两者的相互依赖关系，可以记作,SNO,SNAME,。,图,8-1,(2),部分函数依赖。,定义8,-,3,在,R(U),中，如果,X,Y,，,并且对于,X,的某个真子集,X,，,有,X,Y,，,则称,Y,对,X,部分函数依赖，记为,X Y,。,只有当,X,为属性组时，才有可能发生部分函数依赖的情况。因为如果,X,为单个属性，其子集,X,就是,X,本身。,例8,-,2,若在关系,SC(SNO,，,CNO,，,GRADE),中增加一个属性,CLASS(,学生所在班级,),，则在新关系,SCNEW(SNO,，,CNO,，,GRADE,，,CLASS),中有,(,SNO,，,CNO),GRADE,SNO,CLASS,(SNO,，,CNO)CLASS,用图解表示，如图,8-2,所示。请读者注意图中两个箭头的不同出发点。,图,8-2,(3),传递函数依赖。,定义8,-,4,在,R(U),中，如果,X,Y,，,(Y X),，,Y,Z,，,但,Y X,，,则称,Z,对,X,传递函数依赖，记为,X Z,。,请注意上述定义中的条件,Y X,。,如果不加上这一限制，当,X,Y,时允许,Y,X,，,则,X,Y,，,而在,X,Y,的条件下，,Y,Z,就等于,X,Z,，,这样,X,就直接决定,Z,，,而不是通过,Y,的“传递”决定,Z,了。,例8,-,3,在关系,S(SNO,，,SNAME,，,SDEPT),中，增加一个属性,SDMN(,系主任,),，则在新关系,SNEW(SNO,，,SNAME,，,SDEPT,，,SDMN),中有,SNO,SNAME,，,SNO,SDEPT,又因为,SDEPT,SDMN,所以,SNOSDMN,图8-3是它的图解，图中的虚线箭头表示传递依赖。,图,8-3,8.2,规范化和范式,8.2.1,引例,在定义各种范式之前，先看一个例子。,例8,-,4,假设现有学生关系,S(SNO，SN，CLS，MON，CNO，GRD)，,其中,SNO,是学号，,SN,是学生姓名，,CLS,是学生所在班级，,MON,是班主任，,CNO,是学生所选的课程号，,GRD,是学生选课的成绩等级。图8-4表示了这个关系的现有元组。,不难看出，如果把这一关系付诸实用，会有较多的问题。例如：,(1) 插入异常。所谓异常，就是说“不好办”。例如当某学生尚未选课前，虽然已知他的学号、姓名与班级，仍无法将他的信息插入关系,S，,这是因为,S,的主码是(,SNO，CNO)，CNO,为“空”值时，插入是禁止的。,(2) 删除异常。假定学生周明不再选修,C1,课程了，本应删去,C1，,但,C1,是主码的一部分，要删，必须将整个元组一起删去，这样，有关周明的其它信息就丢失了。若想保留周明的其它信息，就只好不删。,(3) 冗余量大。一个学生通常要选多门课，,SNO，SN，CLS,与,MON,都重复多次，占用存储空间多。,图8-4 关系,S,(4) 修改复杂。如果学生更改了姓名，他的所有元组都要修改,SN。,又如某班改换了班主任，属于该班的学生都要修改,MON,的内容。一不小心就可能此改彼漏，破坏数据的完整性(即造成数据不一致)。,产生上述问题的原因，直观的说，是因为关系中“包罗万象”，内容太杂了。从属性间函数依赖的关系看，由于关系中除完全函数依赖外，还存在着部分函数依赖和传递函数依赖。下面从消除后两种函数依赖关系入手，尝试解决上述问题。,(1) 将原关系分解成两个新关系，以消除,SN，CLS,和,MON,对主码(,SNO，CNO),的部分依赖。新产生的关系是,S1(SNO，SN，CLS，MON),SC(SNO，CNO，GRD),图8-5是从图8-4中导出的两个新关系的内容。,图 8-5,(,a) S1；(b) SC,与原关系比较，消除了许多冗余信息，减少了修改量，同时也减少了插入和删除异常。但新关系,S1,仍然存在以下问题：,(1) 班主任的姓名要重复存储(有冗余数据)，类似“更换班主任”这样的修改，仍需改动较多的元组。,(2) 仍有插入、删除、修改等异常。例如，若学生丁芳转到计算机班，如果修改她的,CLS、MON,两项，便会失去“机械班主任为方方”的信息，造成修改异常。又如，新增加一个电子班，班主任也已确定，但在该班招收学生之前，这些信息不能插入,S1。,为了解决上述问题，可再作一次分解。,(2) 第二次分解，消除,MON,对,SNO,的传递函数依赖。此时关系,SC,不变，仅将,S1,分解成以下两个关系：,S2(SNO，SN，CLS),CL(CLS，MON),图8-6是根据图8-5(,a),导出的,S2,与,CL,的内容。,图 8-6,(,a) S2；(b) CL,8.2.2,第一范式,(1,NF),及规范化,规范化的理论是,E.F.,Codd,首先提出的。他认为，一个关系数据库中的关系，都应满足一定的规范，才能构造出好的数据模式，,Codd,把应满足的规范分成几级，每一级称为一个范式,(,Normal Form),。,例如满足最低要求，叫第一范式,(1,NF),；,在,1,NF,基础上又满足一些要求的叫第二范式,(2,NF),；,第二范式中，有些关系能满足更多的要求，就属于第三范式,(3,NF),。,后来,Codd,和,Boyce,又共同提出了一个新范式：,BC,范式,(,BCNF),。,以后又有人提出第四范式,(4,NF),和第五范式,(5,NF),。,范式的等级越高，应满足的条件也越严。,图,8-7,各种范式之间的关系,所谓“第几范式”，是表示关系的某一种级别，所以经常称某一关系模式,R,为第几范式。但现在人们把范式这个概念理解成符合某一种级别的关系模式的集合，则,R,为第几范式就可以写成,R,x,NF,。,对于各种范式之间的联系有,5,NF 4NF BCNF 3NF 2NF 1NF,成立，如图,8-7,所示。,一个低一级范式的关系模式，通过模式分解可以转换为若干个高一级范式的关系模式的集合，这个过程就叫规范化。,关系，作为一张二维表，对它有一个最起码的要求：每一个分量必须是不可分的数据项。满足了这个条件的关系模式就属于第一范式,(1,NF),。,这一限制是在关系的基本性质中提出的，任何关系都必须遵守。,第一范式是对关系的最低要求，由于第一范式和第二范式在应用中有许多缺点，实际的数据库系统一般都使用第三范式以上的关系，但也不是范式等级越高越好。下面分别讨论这些范式。,8.2.3,第二范式,(2,NF),与第三范式,(3,NF),定义8,-,5,若关系模式,R1NF，,且它的每一个非主属性都完全函数依赖于码，则,R2NF。,2NF,就是不允许关系模式的属性之间有这样的函数依赖,XY，,其中,X,是码的真子集，,Y,是非主属性。即不允许有非主属性对码的部分函数依赖。,定义8,-,6,若关系模式,R2NF，,且它的每一个非主属性都不传递函数依赖于码，则,R3NF。,3NF,就是不允许关系模式的属性之间有这样的函数依赖,XY，,其中,X,不包含码，,Y,是非主属性。,X,不包含码有两种情况，一种情况,X,是码的真子集，这是2,NF,所不允许的；另一种情况,X,不是码的真子集，这是3,NF,所不允许的。即3,NF,不允许有非主属性对码的部分函数依赖和传递函数依赖。,从以上定义可知，2,NF,关系可从1,NF,关系中消除非主属性对码的部分函数依赖后获得，3,NF,关系可从2,NF,关系中消除非主属性对码的传递函数依赖后获得。,现在按照上述定义来考察引例中的几个关系，了解它们各属于哪一种范式。,例8-5,求关系,S(SNO，SN，CLS，MON，CNO，GRD),的范式等级。,为了分析方便，写出关系的表示式后，可以在主属性下方划一横线，并用箭头标出属性之间的依赖关系。,分析：,S(SNO，CNO，SN，CLS，MON， GRD),(1),各分量都是原子的。,(2) 存在部分函数依赖，如(,SNO，CNO)SN。,结论：,S1NF。,结论：,S1NF。,例8,-,6,求关系,S1(SNO，SN，CLS，MON),的范式等级。,分析：,S1(SNO，SN，CLS，MON),(1),分量全是原子的。,(2) 主关键字为单个属性，不可能存在部分函数依赖。,(3) 存在传递函数依赖，如,SNOMON(,因为,SNOCLS，CLSMON)。,例8,-,7,求关系,S2，CL,与,SC,的范式等级。,(1),S2(SNO，SN，CL,S),(2) CL(CLS，MON),(3) SC(SNO，CNO，GRD),8.2.4,BC,范式,(,BCNF),BCNF(Boyce,Codd,Normal Form),是由,Boyce,和,Codd,提出的，该范式比上述的3,NF,又进了一步，通常认为,BCNF,是修正的第三范式，有时也称为扩充的第三范式。,定义8,-,7,若关系模式,R,1NF，,且对于每一个非平凡的函数依赖,XY，X,必包含码，则,RBCNF。,也就是说，关系模式,R(U),中，若每一个决定因素都包含码，则,R(U),BCNF。,由,BCNF,的定义可以得到结论，一个满足,BCNF,的关系模式有：,(1) 所有非主属性对每一个码都是完全函数依赖。,(2) 所有主属性对每一个不包含它的码，也是完全函数依赖。,(3) 没有任何属性完全函数依赖于非码的任何一组属性。,BCNF,是第三范式的进一步规范化，即限制条件更严格。3,NF,不允许有,X,不包含码，,Y,是非主属性的非平凡函数依赖,XY。BCNF,则不管,Y,是主属性还是非主属性，只要,X,不包含码，就不允许有,XY,这样的非平凡函数依赖。因此，若,RBCNF，,则必然,R3NF，,若,R3NF，,未必,R,属于,BCNF。,然而，,BCNF,又是概念上更加简单的一种范式，判断一个关系模式是否属于,BCNF，,只要考察每个非平凡函数依赖,XY,的决定因素,X,是否包含码就行了。,例如我们在前面见过的关系模式,S2(SNO，SN，CL,S),CL(CLS，MON),SC(SNO，CNO，GRD),它们都属于3,NF，,并且每一个决定因素都是码，所以它们也都属于,BCNF。,但并不是每一个属于3,NF,的关系模式都属于,BCNF。,例8,-,8,有一关系模式,CSZ(CITY，ST，ZIP)，CITY,是城市，,ST,是街道，,ZIP,是邮政编码，其属性组上的函数依赖集为,F = (CITY，ST),ZIP，ZIPCITY ,即城市、街道决定邮政编码，邮政编码决定城市。可用图8-8表示如下。,容易看出，(,CITY，ST),和(,ST，ZIP),是两个候选码，,CITY，ST，ZIP,都是主属性，没有非主属性，自然,CSZ3NF。,但函数依赖,ZIPCITY,的决定因素,ZIP,不包含码，所以,CSZBCNF。,图,8-8,CSZ,中的函数依赖,对于不是,BCNF,的关系模式，仍然存在不合适的地方。关系模式,CSZ,就存在着种种“毛病”，例如，若无街道信息，则一个邮政编码是哪个城市中的邮政编码的信息无法存在数据库中。若将,CSZ,分解为两个关系模式：,ZC(ZIP，CITY),SZ(ST，ZIP),就没有在非平凡的函数依赖的决定因素中不包含码的情况，两者都是,BCNF,的关系模式。,从以上讨论和例8-4的引例可以看出，关系模式的规范化过程，就是通过关系的投影分解逐步提高关系范式等级的过程。从1,NF,到,BCNF，,其过程如图8-9所示。,图8-9 各种范式及规范化过程,3,NF,和,BCNF,是在函数依赖的条件下对模式分解所能达到的分离程度的测度。一个模式中的关系模式如果都属于,BCNF，,那么在函数依赖范畴内，它已实现了彻底的分离，已消除了插入和删除的异常。3,NF,的“不彻底”性表现在可能存在主属性对码的部分依赖和传递依赖。,把低一级的关系模式分解为若干个高一级的关系模式，这种分解不是惟一的。下面进一步讨论关系模式的分解，即分解后的关系模式与原关系模式的等价问题。,8.2.5,关系模式的分解,分解可以使各关系模式达到某种程度的分离，让一个关系模式描述一个概念、一个实体或者实体间的一种联系，即所谓“一事一地”的设计原则，若多于一个概念就把它“分离”出去。分解是提高关系范式等级的重要方法。从例8-4的引例中，读者已看到分解所起的作用。,那么，如何对关系模式进行分解呢？在这一小节中，我们将通过一个实例说明模式分解的一般方法和对分解质量的要求。,例8,-,9,已知关系,S(SNO，CLS，MON),2NF，,图8-10(,a),显示了它包含的内容，图8-10(,b),给出了属性间的依赖关系。,试将,S,分解为两个3,NF,的新关系。,图8-10 关系,S,及属性间的联系,这里有三种不同的分解法，即,S-C(SNO，CLS),(1) S,C-M(CLS，MON),S-C(SNO，CLS),(2) S,S-M(SNO，MON),S-M(SNO，MON),(3) S,C-M(CLS，MON),三种方案得出的新关系，全是,BCNF，,但分解的质量却大有差异。以下结合对分解质量的要求，对这三种方案作一比较。,(1) 分解必须是无损的，既不应在分解中丢失信息。,在上例中，第(3)种方案就不能保证无损分解。图8-11显示了这一方案得出的两个关系。由于计算机班和电子班的班主任是同一个人，分解后将无法分辩,S1S4,各属于哪一个班。,图8-11 第(3)种方案得出的关系,S-M,和,C-M,(a) S-M；(b) C-M,(2) 分解后的新关系应相互独立，对一个关系内容的更改，不会影响另一个关系。,试比较以上的(1)、(2)两种方案。设,S4,从电子班转到机械班。按第(1)种方案，仅修改,S-C,就可以了；而按第(2)种方案，就要同时修改,S-C,与,S-M,两个关系。,在插入的时候，(1)、(2)两种方案的情况也不相同。假定增加了一个新班，并有了班主任。按第(1)种方案，可以直接在,C-M,中插入一个新元组；而按第(2)种方案，则必须等这个班已有了学生，才能将,CLS,与,MON,的信息分别插入,S-C,与,S-M,两个关系。,产生以上这些差别的原因，可以结合图8-10(,b),来说明。在图中的三个属性之间，,SNO,CLS，CLS,MON,都是完全函数依赖，而,SNO,MON,则为传递函数依赖。方案(1)建立的两个新关系分别使用了两个原有的完全函数依赖关系，方案(2)和方案(3)都只有一个新关系使用了完全函数依赖，另一个新关系使用的传递函数依赖，对于未用到的那个完全函数依赖关系，只能靠推导才能得到。这就是方案(1)优于其它方案的原因。可见，借助于图8-10(,b),的属性依赖图解，可以帮助选择正确的分解方案。,从上例可知，对关系模式的分解，不能仅着眼于提高它的范式等级，还应遵守无损分解和分解后的新关系相互独立等原则。只有兼顾到各方面的要求，才能保证分解的质量。,还需要注意的是，有些模式在理论中存在冗余或异常，实际应用中不一定有多少影响。例如有些关系模式在运行中只有查询操作，没有插入和删除等操作，就不必担心发生“异常”。,总之，处理模式分解必须从实际出发，并不是范式等级越高越好。分解得过细，即使对消除更新异常有些好处，但查询时需要更多的连接操作，很可能是得不偿失的。,8.3,数据库设计概述,数据库设计是指数据库应用系统的设计，数据库应用系统是含有数据库的信息系统的通称。数据库应用系统的设计是对于一个给定的应用环境(包括硬件环境和软件环境)，如何来表达用户的要求，构造最优的数据库模式，建立数据库及围绕数据库展开的应用系统，使之能够有效地收集、存储、操作和管理数据，满足各类用户的应用需求(信息需求和处理需求)。,对一般的用户来说，数据库管理系统(,DBMS),已经随机器配置，不需要自行设计。所谓应用系统的设计，实际上就是“数据库 + 应用程序”的设计，而中心问题则是数据库的设计。具体地说，数据库设计包括结构特性的设计和行为特性的设计两方面的内容。结构特性的设计是指确定数据库的数据模型。数据模型反映了现实世界的数据及数据间的联系，要求在满足应用需求的前提下，尽可能减少冗余，实现数据共享。行为特性的设计是指确定数据库应用的行为和动作，应用的行为体现在应用程序中，所以行为特性的设计主要是应用程序的设计。,数据库设计工作量大而且过程比较复杂，既是一项数据库工程，也是一项庞大的软件工程，数据库设计的各阶段可以和软件工程的各阶段对应起来，软件工程的某些方法和工具同样可以适用于数据库工程。数据库工程与传统的软件工程的区别在于：软件工程中比较强调行为特性的设计；在数据库工程中，由于数据库模型是一个相对稳定的并为所有用户共享的数据基础，所以在数据库工程中更强调对于结构特性的设计，并与行为特性的设计结合起来。,为了使数据库设计更合理更有效，需要有效的指导原则，这种指导原则称做数据库设计方法学。数据库规范设计方法中比较著名的有新奥尔良(,New Orleans),方法，它将数据库设计过程分为4个阶段：需求分析(分析用户要求)、概念结构设计(信息分析与定义)、逻辑结构设计(设计实现)和物理结构设计(物理数据库设计)。其后，,S.B.,Yao,等人又将数据库设计分为5个步骤。又有,I.R.Palmer,等人主张把数据库设计当成一步接一步的过程，并采用一些辅助手段实现每一过程。,按照规范设计的方法，考虑数据库及其应用系统开发全过程，将数据库设计分为以下6个阶段(如图8-12所示)。,l,需求分析；,l,概念结构设计；,l,逻辑结构设计；,l,物理结构设计；,l,数据库实施；,l,数据库运行与维护。,图8-12 数据库设计步骤,数据库设计开始之前，首先必须选定参加设计的人员，包括系统分析人员、数据库设计人员和程序员、用户和数据库管理员。系统分析和数据库设计人员是数据库设计的核心人员，他们将自始至终参与数据库设计，他们的水平决定了数据库系统的质量。用户和数据库管理员在数据库设计中也是举足轻重的，他们主要参加需求分析和数据库的运行维护，他们的积极参与不但能加快数据库设计，而且也是决定数据库设计的质量的重要因素。程序员则在系统实施阶段参与进来，分别负责编制程序和准备软硬件环境。,1,需求分析阶段,在进行数据库设计时，首先必须准确了解与分析用户需求(包括数据与处理)。需求分析是整个设计过程的基础，作为地基的需求分析是否做得充分与准确，决定了在其上构建数据库大厦的速度与质量，需求分析做得不好，甚至会导致整个数据库设计返工重做。该阶段的工作是收集和分析用户对系统的要求，确定系统的工作范围，并产生“数据流图”和“数据字典”。,2,概念结构设计阶段,根据对系统的要求，提出能够反映各个用户要求的局部概念模型，然后将局部概念模型综合为总的概念模型。应该指出，概念模型仅是用户活动的客观反映，并不涉及用什么样的数据模型来实现它的问题，即概念模型独立于具体的,DBMS。,因此在这一阶段，应该把注意力集中在弄清系统要求上面，暂不要考虑怎样去实现，以免分散精力。,实体联系方法是设计概念模型的主要方法，在该阶段结束时应该产生系统的基本,ER,图。,3,逻辑结构设计阶段,这一阶段首先要选择一种适当的数据模型，然后将系统的概念模型转换为所需的数据模型。通常一种,DBMS,只支持某一种数据模型(如关系、网状或层次模型)，所以,DBMS,一旦确定，数据模型的类型也就定了。此时逻辑设计的任务，仅是把概念模型转换为系统的,DBMS,所支持的数据模型。,逻辑结构设计一般分为初始设计和优化设计两步。优化设计要用到规范化理论和,LRA,方法。,4,物理结构设计阶段,该设计阶段内容包括：确定存储结构；建立存取路径；分配存储空间等。这些工作主要由,DBMS,在操作系统支持下自动完成，只有少量工作可由用户选择或干预。例如，有些,DBMS,允许用户在一定范围内选择主文件和索引文件的结构，决定在哪些属性码上建立索引，建什么样的(单码或组合码)索引等。在存储分配上，用户可以指定存储介质，如磁盘、磁带等。,5,数据库实施阶段,在数据库实施阶段，设计人员运用,DBMS,提供的数据语言及其宿主语言，根据逻辑设计和物理设计的结果建立数据库，编制和调试应用程序，组织数据入库，并进行试运行。应用程序须按照不同用户的要求分别考虑和设计，需要时可以先在逻辑模式上定义适合于用户需要的外模式。,6,数据库运行和维护阶段,数据库应用系统经过试运行后即可投入正式运行。在数据库系统运行过程中必须不断地对其进行评价、调整与修改。,设计一个完善的数据库应用系统是不可能一蹴而就的，它往往是上述六个阶段的不断反复。,需要指出的是，这个设计步骤既是数据库设计的过程，也包括了数据库应用系统的设计过程。在设计过程中把数据库的设计和对数据库中数据处理的设计紧密结合起来，将这两个方面的需求分析、抽象、设计、实现在各个阶段同时进行，相互参照，相互补充，以完善两方面的设计。,下面就以图8-12的设计过程为主线，讨论数据库设计各个阶段的设计内容、设计方法和工具。,8.4,需,求,分,析,需求分析简单地说就是分析用户的要求。需求分析是设计数据库的起点，需求分析的结果是否准确地反映了用户的实际要求，将直接影响到后面各个阶段的设计，并影响到设计结果是否合理和实用。所以，准确而无遗漏地弄清用户对系统的要求，是系统设计取得成功的重要前提。,8.4.1,需求分析的任务,需求分析的任务是对现实世界要处理的对象(组织、部门、企业等)进行详细调查，在了解现行系统的概况，确定新系统功能的过程中，收集支持系统目标的基础数据及其处理方法。需求分析是在用户调查的基础上，通过分析，逐步明确用户对系统的需求，包括数据需求和围绕这些数据的业务处理需求。,调查的重点是“数据”和“处理”，通过调查、收集与分析，获得用户对数据库的如下要求：,(1) 信息要求。指用户需要从数据库中获得信息的内容与性质。由信息要求可以导出数据要求，即在数据库中需要存储哪些数据。,(2) 处理要求。指用户要完成什么处理功能，对处理的响应时间有什么要求，处理方式是批处理还是联机处理。,(3) 安全性与完整性要求。,确定用户的最终需求是一件很困难的事，这是因为一方面用户缺少计算机知识，开始时无法确定计算机究竟能为自己做什么，不能做什么，因而往往不能准确地表达自己的需求，所提出的需求往往不断地变化。另一方面，设计人员缺少用户的专业知识，不易理解用户的真正需求，甚至误解用户的需求。因此设计人员必须不断深入地与用户交流，才能逐步确定用户的实际需求。,8.4.2,需求分析的方法,进行需求分析首先是调查清楚用户的实际要求，与用户达成共识，然后分析与表达这些需求。,调查用户需求的具体步骤是：,(1) 调查组织机构情况。包括了解该组织的部门组成情况、各部门的职责等，为分析信息流程做准备。,(2) 调查各部门的业务活动情况。包括了解各个部门输入和使用什么数据，如何加工处理这些数据，输出什么信息，输出到什么部门，输出结果的格式是什么，这是调查的重点。,(3) 在熟悉了业务活动的基础上，协助用户明确对新系统的各种要求，包括信息要求、处理要求、安全性与完整性要求，这是调查的又一个重点。,(4) 确定新系统的边界。对前面调查的结果进行初步分析，确定哪些功能由计算机完成或将来准备让计算机完成，哪些活动由人工完成。由计算机完成的功能就是新系统应该实现的功能。,在调查过程中，可以根据不同的问题和条件，使用不同的调查方法。常用的调查方法有：,(1) 跟班作业。通过亲身参加业务工作来了解业务活动的情况。这种方法可以比较准确地理解用户的需求，但比较耗费时间。,(2) 开调查会。通过与用户座谈来了解业务活动情况及用户需求。,(3) 请专人介绍。,(4) 询问。对某些调查中的问题，可以找专人询问。,(5) 设计调查表请用户填写。如果调查表设计得合理，这种方法很有效，也易于为用户接受。,(6) 查阅记录。查阅与原系统有关的数据记录。,做需求调查时，往往需要同时采用上述多种方法。但无论使用何种调查方法，都必须有用户的积极参与和配合。,调查了解了用户的需求以后，还需要进一步分析和表达用户的需求。在众多的分析方法中，结构化分析(,SA，Structured Analysis),方法是一种简单实用的方法。,SA,方法从最上层的系统组织机构入手，采用自顶向下、逐层分解的方式分析系统。,SA,方法把任何一个系统都可以抽象为图8-13那样的数据流图(,DFD，Data Flow Diagram),形式。,图8-13 系统高层的数据流图,图8-13给出的只是最高层次抽象的数据流图，要反映更详细的内容，可将处理功能分解为若干子功能，每个子功能还可以继续分解，直到把系统工作过程表示清楚为止。在处理功能逐步分解的同时，它们所用的数据也逐级分解，形成若干层次的数据流图。,数据流图表达了数据和处理过程的关系。在,SA,方法中，处理过程的处理逻辑常常借助判定表或判定树来描述。系统中的数据则借助数据字典(,DD，Data Dictionary),来描述。,数据字典是系统中各类数据描述的集合，是进行详细的数据收集和数据分析所获得的主要成果。数据字典在数据库设计中占有很重要的地位。数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程五种成分的描述。其中数据项是数据的最小组成单位，若干个数据项可以组成一个数据结构，数据字典通过对数据项和数据结构的定义来描述数据流、数据存储的逻辑内容。数据字典是在需求分析阶段建立，在数据库设计过程中不断修改、充实、完善。,需求分析阶段的文档是系统需求说明书，系统需求说明书主要包括数据流图、数据字典的雏形、各类数据的统计表格、系统功能结构图，并加以必要的说明编辑而成。系统需求说明书将作为数据库设计全过程的重要依据文件。,8.5 概念结构设计,8.5.1,概念结构,在需求分析阶段所得到的应用需求应该首先抽象为信息世界的结构，才能更好地、更准确地用某一,DBMS,实现这些需求。,概念结构的主要特点是：,(1) 能真实、充分地反映现实世界，包括事物和事物之间的联系，能满足用户对数据的处理要求。概念结构是对现实世界的一个真实模型。,(2) 易于理解。从而可以用它和不熟悉计算机的用户交换意见，用户的积极参与是数据库设计成功的关键。,(3) 易于更改。当应用环境和应用要求改变时，容易对概念模型修改和扩充。,(4) 易于向关系、网状、层次等各种数据模型转换。,概念结构是各种数据模型的共同基础，它比数据模型更独立于机器、更抽象，从而更加稳定。,描述概念模型的有力工具是,ER,模型。有关,ER,模型的基本概念已在前面介绍。下面将用,ER,模型来描述概念结构。,8.5.2,概念结构设计的方法和步骤,设计概念结构通常采用的策略是自底向上的方法，即首先定义各局部应用的概念结构，然后将它们集成起来，得到全局概念结构，如图8-14所示。,自底向上设计概念结构通常分为两步：第一步是设计各局部应用的局部视图；第二步是集成各局部视图，得到全局的概念结构。,图8-14 自底向上策略,1,局部,E,R,模型的设计,概念结构设计的第一步就是对需求分析阶段收集到的数据进行分类、组织，形成实体、实体的属性、标识实体的码，确定实体之间的联系类型(11，1,n，mn)，,设计分,ER,图。具体做法是：,(1) 选择局部应用。根据某个系统的具体情况，在多层的数据流图中选择一个适当层次的数据流图，作为设计分,ER,图的出发点。让这组图中每一部分对应一个局部应用。,由于高层的数据流图只能反映系统的概貌，而中层的数据流图能较好地反映系统中各局部应用的子系统组成，因此人们往往以中层的数据流图作为设计分,ER,图的依据。,(2) 逐一设计分,ER,图。选择好局部应用之后，就要对每个局部应用逐一设计分,ER,图，亦称局部,ER,图。,在前面选好的某一层次的数据流图中，每个局部应用都对应了一组数据流图，局部应用涉及的数据都已经收集在数据字典中了。现在就是要将这些数据从数据字典中抽取出来，参照数据流图，标定局部应用中的实体、实体的属性、标识实体的码，确定实体之间的联系及其类型。,这里最关键的步骤是确定实体和属性。就是说，首先要决定在每一个应用中包含哪些实体，这些实体又包含哪些属性。事实上，在现实世界中具体的应用环境常常对实体和属性已经作了大体的自然的划分。在数据字典中，“数据结构”、“数据流”和“数据存储”都是若干属性有意义的聚合，就可以作为实体对待。实体确定后，再确定实体之间的联系。这样就可建立起对应于每一个应用的局部,ER,模型，然后再进行必要的调整。,假设某工厂要设计一个查询系统。主管生产的部门要掌握产品的性能、各种零件的用料和每种产品的零件组成情况，并需据此编制工厂的生产计划；主管供应的部门需要了解产品的价格、各种产品的用料情况以及这些材料的价格与库存量，并需根据这些资料提出材料的订购计划。下面以供应部门的供应查询为例，可以把“产品”、“材料”确定为实体，前者应有“产品名”和“价格”两个属性，后者有“材料名”、“价格”和“库存量”三个属性。实体确定后，再确定实体之间的联系。在本例中，“产品”与“材料”是通过“使用”互相联系的，故可把“使用”定为联系，而“用量”是它的属性。把这些用,ER,图来表示，就可得到供应部门的局部,ER,模型，如图8-15所示。,图8-15 供应部门的局部,E-R,模型,用类似的方法，可以建立生产部门的,ER,模型，如图8-16所示。,图8-16 生产部门的局部,ER,模型,应该说明，实体和属性的划分并无绝对的标准。一般说来，凡不需要对它进行再描述的事物，均作为属性对待。举例说，假定材料不只存放在一个仓库，只须在图8-15的“材料”实体下再增加一个属性“仓库号”就可以了，这时的库存量也相应的改成每一仓库所拥有的材料数量。但如果需要把仓库本身的信息(例如“仓库号”、“面积”、“地点”等)也存入数据库以备查询，就应将“仓库”作为一个新的实体加入图中，把图8-15修改成如图8-17的样子。,图8-17 更改后的供应部门局部,ER,模型,局部,ER,模型建立后，应对照每一个应用进行检查，确保模型能满足数据流图对数据处理的需要。,2,全局,E,R,模型的设计,各子系统的分,ER,模型设计好以后，下一步就是要将各个应用的分,ER,模型综合成系统总的概念模型(总,ER,模型)。一般说来，综合可以有两种方式：,(1) 多个分,ER,图一次集成；,(2) 逐步集成，用累加的方式一次集成两个分,ER,图。,第一种方式比较复杂，做起来难度较大；第二种方式每次只集成两个分,ER,图，可以降低复杂度。无论采用哪种方式，每次集成局部,ER,图时都需要分两步走：第一步合并，解决各分,ER,图之间的冲突，将各分,ER,图合并起来生成初步,ER,图；第二步修改和重构，消除不必要的冗余，生成基本,ER,图。,1) 合并分,E,R,图，生成初步,E,R,图,各个局部应用所面向的问题不同，且通常是由不同的设计人员进行局部,ER,图设计，这就导致各个分,ER,图之间必定会存在许多不一致的地方，称之为冲突。因此合并分,ER,图时并不能简单地将各个分,ER,图画到一起，而是必须着力消除各个分,ER,图中的不一致，以形成一个能为全系统中所有用户共同理解和接受的统一的概念模型。合理消除各分,ER,图的冲突是合并分,ER,图的主要工作与关键所在。,各分,ER,图之间的冲突主要有三类：属性冲突、命名冲突和结构冲突。,(1) 属性冲突：包括属性值的类型、取值范围、取值单位的不同。,(2) 命名冲突：包括实体名、联系名、属性名之间异名同义，或同名异义等。,(3) 结构冲突：例如同一对象在一个局部,ER,图中作为实体，而在另一个局部,ER,图中作为属性，同一实体在不同的,ER,图中属性个数和类型不同等。,属性冲突和命名冲突通常用讨论、协商等行政手段解决；结构冲突则要认真分析后用技术手段解决，例如把实体变换为属性或属性变换为实体，使同一对象具有相同的抽象，又如，取同一实体在各局部,ER,图中属性的并作为集成后该实体的属性集，并对属性的取值类型进行协调统一。,在进行综合时，除相同的实体应该合并外，还可在属于不同分,ER,图的实体间添加新的联系。图8-18显示了将图8-15和图8-16综合得到的,ER,图。图中“材料”与“零件”两个实体之间的联系(“消耗”)，就是综合后添加的。产品的属性也从分,ER,图中的两项增加为三项。,图8-18 综合后的初步,ER,图,但是，这样综合得出的,ER,图仅是初步的，很可能存在冗余的数据和实体间的冗余联系，需要进一步的修改。,2) 消除不必要的冗余，设计基本,E,R,图,在初步,ER,图中，可能存在一些冗余的数据和实体间冗余的联系。所谓冗余的数据是指可由基本数据导出的数据，冗余的联系是指可由其它联系导出的联系。冗余数据和冗余联系的存在，不仅将占用更多的存储空间，而且会增加数据维护工作，甚至可能在修改数据时破坏数据的完整性，应当予以消除。消除了冗余后的初步,ER,图称为基本,ER,图。,仍以图8-18为例，产品对各种材料的“用量”，实际上是根据产品包含的“零件数量”和零件的材料消耗“定额”推导出来的。也就是说，与“用量”相比，“零件数量”与“定额”是更基本的数据，因为“用量”可以由它们推导求得。如果保留“零件数量”与“定额”，就可以消除“用量”。进一步说，“用量”又是产品与材料间的联系(“使用”)的属性，“用量”省去了，“使用”这个联系也可随之取消。这样，图8-18就可改进为图8-19，这就是包括生产和供应两个部门在内的系统的基本概念模型，或称为系统的基本,ER,图。,图8-19 系统的基本,ER,图,8.6,逻辑结构设计,逻辑结构设计的任务就是把概念结构设计阶段设计好的基本,ER,图转换为与选用的,DBMS,产品所支持的数据模型相符合的逻辑结构。逻辑结构设计包括初步设计和优化设计两个步骤。所谓初步设计就是按照,ER,图向数据模型转换的规则，将已经建立的概念模型转换为,DBMS,所支持的数据模型，这里只介绍,ER,图向关系数据模型的转换原则与方法；优化设计是对初步设计所得到的逻辑模型做进一步的调整和改良，如图8-20所示。,图8-20 逻辑结构设计的过程,8.6.1,E,R,图向关系模型的转换,ER,图向关系模型转换要解决的问题是如何将实体和实体间的联系转换为关系模式，以及如何确定这些关系模式的属性和码。,关系模型的逻辑结构是一组关系模式的集合。,ER,图则是由实体、实体的属性和实体之间的联系三个要素组成的。所以将,ER,图转换为关系模型实际上就是要将实体、实体的属性和实体之间的联系转换为关系模式，这种转换一般遵循如下原则：,(1) 一个实体转换为一个关系模式。实体的属性就是关系的属性，实体的码就是关系的码。,(2) 一个11联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，每个实体的码均是该关系的候选码。如果与某一端实体对应的关系模式合并，则需要在该关系模式的属性中加入另一个关系模式的码和联系本身的属性。,(3) 一个1,n,联系可以转换为一个独立的关系模式，也可以与,n,端对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为,n,端实体的码。,(4) 一个,mn,联系转换为一个关系模式。与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为各实体码的组合。,(5) 三个或三个以上实体间的一个多元联系可以转换为一个关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为各实体码的组合。,(6) 具有相同码的关系模式可合并。,下面结合图8-19的,ER,图，把它转换为关系模型。关系的码用下横线标出。,实体名：产品,对应的关系模式：产品(,产品名,，价格，主要性能),实体名：零件,对应的关系模式：零件(,零件号,，零件名),实体名：材料,对应的关系模式：材料(,材料名,，价格，库存量),联系名：组成,所联系的实体及其主码：,产品(主码为“产品名”)和零件(主码为“零件号”),对应的关系模式：产品零件一览表(,产品名，零件名,，零件数量),联系名：消耗,所联系的实体及其主码：,零件(主码为“零件号”)和材料(主码为“材料名”),对应的关系模式：零件用料表(,零件号，材料名,，定额),8.6.2,数据模型的优化,数据库逻辑设计的结果不是惟一的。为了进一步提高数据库应用系统的性能，还应该根据应用需要适当地修改、调整数据模型的结构，这就是数据模型的优化。关系数据模型的优化通常以规范化理论为指导，具体方法为,(1) 确定数据依赖。,(2) 对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。,(3) 按照数据依赖的理论对关系模式逐一进行分析，考察是否存在部分函数依赖、传递函数依赖等，确定各关系模式分别属于第几范式。,(4) 按照需求分析阶段得到的处理要求，分析这些模式对于这样的应用环境是否合适，确定是否要对某些模式进行合并或分解。,必须注意的是，并不是规范化程度越高的关系就越优。例如，当查询经常涉及到两个或多个关系模式的属性时，系统经常进行连接运算。连接运算的代价是相当高的，可以说关系模型低效的主要原因就是连接运算引起的。这时可以考虑将这几个关系合并成一个关系。因此在这种情况下，第二范式甚至第一范式也许是合适的。对于一个具体的应用来说，到底规范化到什么程度，需要权衡响应时间和潜在问题两者的利弊决定。,(5) 对关系模式进行必要的分解，提高数据操作的效率和存储空间的利用率。常用的两种分解方法是水平分解和垂直分解。,例如，某大学记载学生情况的关系，包括大专生、本科生与研究生三大类学生。如果多数查询一次只涉及其中的一类学生，就应把整个学生关系“水平分割”为大专生、本科生、研究生三个关系，以便提高系统的查询效率。,再如，设有记载职工情况的关系：,EMP(,工号，姓名，性别，年龄，职务，工资，工龄，住址，电话),如果经常查询的仅是前六项，后三项使用较少，就可将该关系“垂直分割”为两个关系，即,EMP1(,工号，姓名，性别，年龄，职务，工资),和,EMP2(,工号，工龄，住址，电话),以便减少访问时传送的数据量，提高查询的效率。,8.7,物理结构设计,数据库在物理设备上的存储结构与存取方法称为数据库的物理结构，它依赖于给定的计算机系统。为一个给定的逻辑数据模型选取一个最适合应用要求的物理结构的过程，就是数据库的物理设计。,数据库的物理设计通常分为两步：,(1) 确定数据库的物理结构，在关系数据库中主要指存取方法和存储结构；,(2) 对物理结构进行评价，评价的重点是时间和空间效率。,如果评价结果满足原设计要求，则可进入到物理实施阶段，否则，就需要重新设计或修改物理结构，有时甚至要返回逻辑设计阶段修改数据模型。,1,物理设计的内容和方法,不同的数据库产品所提供的物理环境、存取方法和存储结构有很大差别，能供设计人员使用的设计变量、参数范围也很不相同，因此没有通用的物理设计方法可遵循，只能给出一般的设计内容和原则。通常，关系数据库物理设计的内容主要包括：,1) 存储结构的设计,确定数据库物理结构主要指确定数据的存放位置和存储结构，包括确定关系、索引、日志、备份等的存储安排和存储结构，确定系统配置等。,确定数据的存放位置和存储结构要综合考虑存取时间、存储空间利用率和维护代价三方面的因素。这三个方面常常是相互矛盾的，因此需要进行权衡，选择一个折中方案。,2) 存取方法的设计,存取方法设计为存储在物理设备上的数据提供数据访问的路径。数据库系统是多用户共享的系统，对同一个关系要建立多条存取路径才能满足多用户的多种应用要求。物理设计的任务之一就是要确定选择哪些存取方法，即建立哪些存取路径。,索引是数据库中一种非常重要的数据存取路径，在存取方法设计中要确定建立何种索引，以及在哪些表和属性上建立索引。通常情况下，对数据量很大，又需要做频繁查询的表建立索引，并且选择将索引建立在经常用做查询条件的属性或属性组，以及经常用做连接属性的属性或属性组上。,物理设计的结果是物理设计说明书，包括存储记录格式、存储记录位置分布及存取方法，并给出对硬件和软件系统的约束。,2,物理设计的评价,数据库物理设计过程中需要对时间效率、空间效率、维护代价和各种用户要求进行权衡，其结果可以产生多种方案，数据库设计人员必须对这些方案进行细致的评价，从中选择一个较优的方案作为数据库的物理结构。,评价物理数据库的方法完全依赖于所选用的,DBMS，,主要是从定量估算各种方案的存储空间、存取时间和维护代价入手，对估算结果进行权衡、比较，选择出一个较优的合理的物理结构。如果该结构不符合用户需求，则需要修改设计。,8.8,数据库的实施和维护,1,数据库的实施,完成数据库的物理设计之后，设计人员就要用,RDBMS,提供的数据定义语言和其它实用程序将数据库逻辑设计和物理设计结果严格描述出来，成为,DBMS,可以接受的源代码，再经过调试产生目标模式。然后就可以组织数据入库了，这就是数据库实施阶段。,数据库实施阶段包括两项重要的工作，一项是数据的载入，另一项是应用程序的编码和调试。,一般数据库系统中，数据量都很大，而且数据来源于部门中的各个不同的单位，数据的组织方式、结构和格式都与新设计的数据库系统有相当的差距，组织数据录入就要将各类源数据从各个局部应用中抽取出来，输入计算机，再分类转换，最后综合成符合新设计的数据库结构的形式，输入数据库。因此，这样的数据转换、组织入库的工作是相当费力费时的。,数据库应用程序的设计应该与数据库设计同时进行，因此在组织数据入库的同时还要调试应用程序。应用程序的设计、编码和调试的方法、步骤将在软件工程中讲解，这里就不详述了。,2,数据库的试运行,在原有系统的一小部分数据输入数据库后，就可以开始对数据库系统进行联合调试，这又称为数据库的试运行。,这一阶段要实际运行数据库应用程序，执行对数据库的各种操作，测试应用程序的功能是否满足设计要求。如果不满足，则要对应用程序部分进行修改、调试，直到达到设计要求为止。,在数据库试运行时，还要测试系统的性能指标，分析其是否达到设计目标。如果测试的结果与设计目标不符，则要返回物理设计阶段，重新调整物理结构，修改系统参数。某些情况下甚至要返回逻辑设计阶段，修改逻辑结构。,这里特别要强调两点，第一，上面已经讲到组织数据入库是十分费时费力的工作。如果试运行后还要修改数据库的设计，则还要重新组织数据入库。因此应分期分批地组织数据入库，先输入小批量数据做调试用，待试运行基本合格后，再大批量输入数据，逐步增加数据量，逐步完成运行评价。,第二，在数据
展开阅读全文