第5章 关系模式的规范化设计

第5章关系模式的规范化设计

主要内容:本章讨论关系模式的规范化设计。这章将从数据库逻辑设计中如何构造一个好的数据库模式这一问题出发，阐明了关系规范化理论研究的实际背景，介绍关系内部属性与属性之间的一种约束关系即函数依赖的各种形式。介绍规范化理论，讨论各种范式及可能存在的插入、删除等问题，并直观地描述解决办法。

25.1问题提出前面的章节已经介绍了数据库当中涉及到的基本概念，关系模型的三个部分(关系数据结构、关系操作集合和关系完整性)以及关系数据库的标准语言。 但是有一个很基本的问题没有提及，就是针对一个具体的问题，应该构造几个关系模式，每个关系由哪些属性组成，各属性之间的依赖关系及其对关系模式性能的影响等。 这就是关系数据库逻辑设计的问题。本章主要来讨论实体内部属性与属性之间的数据关联，目标就是要设计一个“好”的数据库。3关系模型原理的核心内容就是规范化概念。

规范化是把数据库组织成在保持存储数据完整性的同时最小化冗余数据的结构的过程。 规范化的数据库必须符合关系模型的范式规则。范式可以防止在使用数据库时出现不一致的数据，并防止数据丢失。 关系模型的范式有第一范式、第二范式、第三范式、BCNF范式、第四范式等多种。45.2数据依赖 数据依赖是关系内部属性与属性之间的一种约束关系。这种约束关系是通过属性间值的相等与否体现出来的数据间的相关联系，它是现实世界属性间相互联系的抽象，是数据内在的性质，是语义的体现。如教师姓名和地址之间，每一个教师都有个确定的地址，意味着：

教师编号确定了，地址就确定了．地址依赖于教师编号。

5数据依赖的类型函数依赖（FunctionalDependency，简记为FD）多值依赖（MultivaluedDependency，简记为MVD）其他6数据依赖对关系模式的影响“好”的模式：不会发生插入异常、删除异常、更新异常，数据冗余应尽可能少“不好”原因：由存在于模式中的某些数据依赖引起的解决方法：通过分解关系模式来消除其中不合适的数据依赖75.2.2函数依赖函数依赖（functiondependency）是最基本的一种数据依赖，也是设计关系模式时应着重考虑的因素.-平凡函数依赖与非平凡函数依赖-完全函数依赖与部分函数依赖-传递函数依赖函数依赖定义5.1设R(U)是属性集U上的一个关系模式。X和Y是U的子集。若对于R(U)中任意一个可能关系r，r中不存在有两个元组，它们在X上的属性值相等，而在Y上的属性值不等，则称“X函数决定Y”，或称“Y函数依赖于X”。记作X→Y。8函数依赖Y=f(X)函数Y=sin(X)Y=X+1Y=X2+2X+1省=f(城市)系名=f(学号)?X是自变量，自变量确定了，Y的值也就确定了城市=f(省)学号=f(系名)√9一个关系模式由五部分组成，即它是一个五元组：描述为：R(U,D,dom,F)。其中：（1）R是关系名；（2）U是一组属性，即组成R的全部属性的集合；（3）D为域的集合，即属性取值范围的集合；（4）dom为U与D之间的映象；（5）F是属性组U上的一组函数依赖。

说明：由于域的定义对关系模式设计关系不大，（3）和（4）往往可以忽略。10术语和符号如果X→Y，但Y不是X的子集，则称X→Y是非平凡的函数依赖。如果X→Y

，但Y是X的子集，则称X→Y为平凡的函数依赖。说明：平凡函数依赖对于任一关系模式都是必然成立的。因此，一般讨论的都是非平凡的函数依赖。例：在关系选修(学号,课程号,成绩)中，(学号,课程号)→成绩(学号,所在系)→所在系非平凡依赖平凡依赖11术语和符号(续)如果X→Y，则X称作决定因素或决定属性集。 如:学号→所在系，则学号称作决定因素。如果X→Y，并且Y→X，则可记作X←→Y。如果Y不函数依赖于X，则记作

。12定义5.2在R(U)中，如果X→Y，并且对于X的任何一个真子集X’，都有,

则称Y对X完全函数依赖，记作若X→Y，但Y不完全函数依赖于X，则称Y对X部分函数依赖，记作。13例题（学号，课程号）→课程名（学号，课程号）→学分（学号，课程号）→成绩部分函数依赖部分函数依赖完全函数依赖[例]在成绩表SC(Sno,Cno,Credit,Grade)中，Sno是学号，Cno是课程号，Credit是学分，Grade是成绩。14定义5.3在R(U)中，如果X→Y，Y→Z，且Y不是X的子集，Z不是Y的子集（非平凡的函数依赖），则称Z对X传递函数依赖。记为：说明:如果Y→X，即X←→Y，则Z直接依赖于X。[例]:在关系Std(Sno,Sdept,Mname)中，Sno是学号，Sdept是系名，Mname是系主任名，有：

Sno→Sdept，Sdept→Mname

Mname传递函数依赖于Sno155.2.4键本节用函数依赖的概念来定义键。 定义5.5设K为R（U，F）中的属性或属性组合，若K→U则K为R的候选键。若候选键多于一个，则选定其中的一个为主键（Primarykey）。 含在任何一个候选键中的属性,叫做主属性(Primeattribute)。 不包含在任何键中的属性称为非主属性(Nonprimeattribute)。 最简单的情况：单个属性是键。 最极端的情况：整个属性组是键,称为全键（All-key).

16定义5.6关系模式R中属性或属性组X并非R的键,但X是另一个关系模式的键,则称X是R的外部键(Foreignkey)也称外键。如在SC（Sno，Cno，Grade）中，Sno不是码，但Sno是关系模式S（Sno，Sdept，Sage）的码，则Sno是关系模式SC的外码。主键与外部键提供了一个表示关系间联系的手段。175.3规范化的关系模式 范式是符合某一种级别的关系模式的集合。关系数据库中的关系必须满足一定的要求。满足不同程度要求的为不同范式。范式的种类： 第一范式(1NF)，第二范式(2NF)，第三范式(3NF) BC范式(BCNF)，第四范式(4NF)，第五范式(5NF)18各种范式之间的关系195.3.1第一范式1NF的定义 定义5.7如果一个关系模式R的所有属性都是不可分的基本数据项，则R∈1NF说明：第一范式是对关系模式的最起码的要求。不满足第一范式的数据库模式不能称为关系数据库。但是满足第一范式的关系模式并不一定是一个好的关系模式20例如，在表1，籍贯含有省、市／县两项，出现了“表中有表”的现象，则为非规范化关系（不符合“第一范式”），而把籍贯分成省、市／县两列，将其规范化，如表2所示。姓名籍贯省市/县王洪黑龙江齐齐哈尔李利吉林长春表1不规范的关系表2规范后的关系长春吉林李利齐齐哈尔黑龙江王洪市/县省姓名小表不允许表中有表21[例5-6]关系模式S-L-C(Sno,Sdept,Sloc,Cno,G)其中，Sno为学生的学号，Sdept为学生的系别，Sloc为学生住处，假设每个系的学生住在同一个地方，Cno为课程号，G为学生的成绩。本例中的函数依赖包括：5.3.2第二范式22关系模式S-L-C的函数依赖关系图S-L-C满足第一范式。

S-L-C的码为(Sno,Cno)非主属性Sdept和Sloc部分函数依赖于码(Sno,Cno)本例中的函数依赖包括：说明：实线表示完全函数依赖，虚线表示部分函数依赖23一个“非2NF”的关系模式Sno（学号）Sdept（系别）Sloc（学生住处）Cno（课程号）G（成绩）S1电子商务10号楼180S1电子商务10号楼290S1电子商务10号楼375S2计算机20号楼185S2计算机20号楼382S3外语15号楼288S4会计30号楼58624S-L-C不是一个“好”的关系模式(1)插入异常 没有选课的学生记录插不进去，因为Cno是主码的一部分，主码不能为空。(2)删除异常 删除选课记录会将学生信息也一同删掉。即不该删除的信息也删除掉了。(3)数据冗余度大 系别和学生住处会重复存放。如一个学生选修了10门课程，那么他的Sdept和Sloc的值就要重复存储10次。(4)修改复杂 如某个学生从电子商务系转到外语系，本来只需要修改此学生的Sdept值。但因为关系模式SLC中还含有系的住处Sloc属性，学生转系将同时改变住处，因此还必须修改Sloc的值。如果该学生选修了3门课，由于Sdept和Sloc的值重复存放了3次，当数据更新时必须无遗漏的修改3个元组中全部Sdept和Sloc的值，这就造成了修改的复杂化。25“不好”原因

分析该例，可见有2种非主属性，一是G，它对码（Sno,Cno）是完全函数依赖。另一种是Sdept和Sloc，它们都是部分函数依赖于码（Sno,Cno）。解决方法

用投影分解把S-L-C分解为两个关系模式，以消除这些部分函数依赖

SC（Sno，Cno，G）

S-L（Sno，Sdept，Sloc）26“分解”以后的函数依赖图：关系模式SC的码为（Sno，Cno）关系模式S-L的码为Sno这样非主属性对码都是完全函数依赖27定义5.8若R∈1NF，且每一个非主属性完全函数依赖于键，则R∈2NF。第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求实体的非主属性完全函数依赖于主键，不存在非主属性对主键的部分函数依赖5.3.2第二范式S-L-C(Sno,Sdept,Sloc,Cno,G)SC(Sno,Cno,G)S-L(Sno,Sdept,Sloc)282NF总结：

所有非主属性都完全函数依赖于主键，

即：不存在部分函数依赖例：学生成绩表（课程号，学号，姓名，成绩）是否满足2NF？为什么？不满足2NF，因为成绩依赖于（课程号，学号）而姓名只依赖于学号，因此存在部分函数依赖29解决办法：把此关系分解为如下两个表：

学生：

(学号,姓名)；

选课：

(学号,课程号,成绩)

这样的数据库表是符合第二范式的30采用投影分解法将一个1NF的关系分解为多个2NF的关系，可以在一定程度上减轻原1NF关系中存在的插入异常、删除异常、数据冗余度大、修改复杂等问题。但是，将一个1NF关系分解为多个2NF的关系，并不能完全消除关系模式中的各种异常情况和数据冗余。315.3.3第三范式定义5.9若R∈2NF，且每一个非主属性都不传递函数依赖于键，则R∈3NF。说明：若R∈3NF，则每一个非主属性既不部分依赖于键也不传递依赖于键。若R∈3NF，则若R∈2NF； 反之不成立。32【例5-6】2NF关系模式S-L(Sno,Sdept,Sloc)中函数依赖：

由于Sno→Sdept

Sdept→Sloc

可得：，即S-L中存在非主属性对键的传递函数依赖，因此33解决方法 采用投影分解法，把S-L分解为两个关系模式，以消除传递函数依赖：

S-D（Sno，Sdept）

D-L（Sdept，Sloc）

其中，S-D的键为Sno，D-L的键为Sdept。分解后的关系模式S-D与D-L中不再存在传递函数依赖34S-D的键为Sno，D-L的键为Sdept35所谓传递函数依赖，指的是如果存在“A→B→C”的决定关系，则C传递函数依赖于A。例：关于职工，有如下关系。假定：每个级别对应不同的工资。请问该关系是否属于3NF？3NF总结：

不存在传递函数依赖职工号姓名级别工资001张三技41500002李四技61200传递依赖关系：职工号－>级别－>工资36解决办法：把此关系分解为如下两个表：

这样的数据库表是符合第三范式的职工号姓名级别001张三技4002李四技6级别工资技41500技61200第三范式——消除了非主属性对键的传递函数依赖375.3.6规范化小结关系数据库的规范化理论是数据库逻辑设计的工具。一个关系只要其分量都是不可分的数据项，它就是规范化的关系，但这只是最基本的规范化。规范化程度可以有多个不同的级别。规范化的目的：尽量消除插入异常、删除异常，修改复杂、数据冗余基本思想：逐步消除数据依赖中不合适的部分实质：概念的单一化（“一事一地”原则）38关系模式的规范化过程是通过对关系模式的分解来实现的。把低一级的关系模式分解为若干个高一级的关系模式。说明：这种分解不是唯一的。关系模式规范化的基本步骤39不能说规范化程度越高的关系模式就越好在设计数据库模式结构时，必须对现实世界的实际情况和用户应用需求作进一步分析，确定一个合适的、能够反映现实世界的模式上面的规范化步骤可以在其中任何一步终止40规范化程度过低的关系不一定能够很好地描述现实世界，可能会存在插入异常、删除异常、修改复杂、数据冗余等问题。一个低一级范式的关系模式，通过模式分解（投影）方法可以转换为若干个高一级范式的关系模式集合，这种过程就叫关系模式的规范化。规范化的方式是进行模式分解。415.5模式分解

模式分解：把低一级的关系模式分解为若干个高一级的关系模式。 模式分解的方法并不是唯一的。只有能够保证分解后的关系模式与原关系模式等价，分解方法才有意义。 三种模式分解“等价”的定义：

1．分解具有无损连接性。（数据的完整性）

2．分解要保持函数依赖。（语义的完整性）

3．分解既要保持函数依赖，又具有无损连接性。42例【5-17】：S-L（Sno，Sdept，Sloc）

F={Sno→Sdept,Sdept→Sloc,Sno→Sloc}S-L∈2NF分解方法可以有多种：1.S-L分解为三个关系模式：

SN(Sno)

SD(Sdept)

SO(Sloc)2.S-L分解为下