《数据库原理及应用》课件第5章

第5章关系数据库设计理论5.1基本概念5.2范式 5.3函数依赖的公理系统5.4模式分解本章小结习题5 案例二

本章主要内容

本章是关系模型的理论基础，是指导数据库设计的重要依据。本章将揭示关系数据中最深层次的一些特性——函数依赖、多值依赖，以及由此引起的诸多异常，如插入异常、删除异常、数据冗余及更新异常等，通过理论引入，对关系模式规范化、函数依赖的公理系统以及关系模式的分解进行系统阐述。

通过本章的学习，应该得到这样的重要启示，即为避免关系模式异常的出现，在设计关系模式时，应使每一个关系模式所表达的概念单一化。

本章学习目标

—

了解数据冗余和更新异常产生的根源。

—

理解函数依赖、多值依赖的基本概念。

—

重点掌握关系模式规范化的方法。

—

理解函数依赖的公理系统。

—

重点掌握关系模式分解的方法。

5.1基本概念

数据库设计的一个最基本的问题是怎样建立一个合理的数据库模式，使数据库系统无论是在数据存储方面，还是在数据操作方面都具有较好的性能。什么样的模型是合理的模型，什么样的模型是不合理的模型，应该通过什么标准去鉴别和采取什么方法来改进，这都是在进行数据库设计之前必须要明确的问题。

现实系统的数据及语义可以通过高级语义数据模型(如实体关系数据模型、对象模型)抽象后得到相应的数据模型。为了通过关系数据库管理系统实现该数据模型，需要使其向关系模型转换，变成相应的关系模式。然而，这样得到的关系模式，还只是初步的关系模式，可能存在这样或那样的问题。因此，需要对这类初步的关系模式，利用关系数据库设计理论进行规范化，以逐步消除其存在的异常，得到一定规范程度的关系模式，这就是本章所要讲述的内容。

5.1.1

规范化问题的提出

前面已经讨论了数据库系统的一般概念，介绍了关系数据库的基本概念、关系模型的三个部分以及关系数据库的标准语言SQL。但是，还有一个很基本的问题尚未涉及，那就是针对一个具体问题，应该如何构造一个适合于它的数据模式，即应该构造几个关系模式，每个关系由哪些属性组成等。这是数据库设计的问题，确切地讲，是关系数据库逻辑设计问题。

实际上，设计任何一种数据库应用系统，不论是层次的、网状的还是关系的，都会遇到如何构造合适的数据模式即逻辑结构的问题。由于关系模型有严格的数学理论基础，并且可以向别的数据模型转换，因此，人们就以关系模型为背景来讨论这个问题，形成了数据库逻辑设计的一个有力工具——关系数据库的规范化理论。规范化理论虽然是以关系模型为背景，但是对于一般的数据库逻辑设计同样具有理论上的意义。

数据语义在关系模式中的具体表现是，在关系模式中的属性间存在一定的依赖关系，即数据依赖(DataDependency)。

数据依赖有很多种，其中最重要的是函数依赖(FunctionalDependency，FD)和多值依赖(Multi-ValuedDependency，MVD)。

函数依赖极为普遍地存在于现实生活中。比如，结合数据库应用系统开发项目描述一个商品的关系，可以有商品编号(ProductId)、商品名称(ProductName)、商品价格(Price)等几个属性。由于一个商品编号只对应一个商品名称，一个商品名称只有一种价格。

【例5.1】设有一个关于教学管理的关系模式R(U)，其中U是由属性Sno、Sname、Ssex、Sdept、Cname、Tname、Grade组成的属性集合。Sno为学生学号，Sname为学生姓名，Ssex为学生性别，Sdept为学生所在系别，Cname为学生所选的课程名称，Tname为任课教师姓名，Grade为学生选修该门课程的成绩。若将这些信息设计成一个关系，则关系模式为：Teaching(Sno，Sname，Ssex，Sdept，Cname，Tname，Grade)，选定此关系的主码为(Sno，Cname)。由该关系的部分数据(见表5.1)，我们不难看出，该关系存在着如下问题：

1)数据冗余(DataRedundancy)

数据冗余的具体表现为：

(1)每一个系名对该系的学生人数乘以每个学生选修的课程门数重复存储。

(2)每一个课程名均对选修该门课程的学生重复存储。

(3)每一个教师都对其所教的学生重复存储。

2)更新异常(UpdateAnomalies)

数据冗余可能导致数据更新异常，这主要表现在以下几个方面：

(1)插入异常(InsertionAnomalies)：由于主码中元素的属性值不能取空值，如果新分配来一位教师或新成立一个系，则这位教师及新系名就无法插入；如果一位教师所开的课程无人选修或一门课程列入计划但目前不开课，也无法插入。

(2)更新异常(UpdateAnomalies)：由于数据冗余，当更新数据库中的数据时，系统要付出很大的代价来维护数据库的完整性，否则会面临数据不一致的危险。比如，如果更改一门课程的任课教师，则需要修改多个元组。如果仅部分修改，其他部分不修改，就会造成数据的不一致性。同样的情形，如果一个学生转系，则对应此学生的所有元组都必须修改，否则，也会出现数据的不一致性。

(3)删除异常(DeletionAnomalies)：如果某系的所有学生全部毕业，又没有在读学生及新生，当从表中删除毕业学生的选课信息时，则连同此系的信息将全部丢失。同样的情况，如果所有学生都退选一门课程，则该课程的相关信息也同样丢失了。

由此可知，上述的教学管理关系尽管看起来能满足一定的需求，但存在的问题太多，因此Teaching并不是一个合理的关系模式。

不合理的关系模式最突出的问题是数据冗余，而数据冗余的产生有着较为复杂的原因。虽然关系模式充分考虑了文件之间的相互关联，并且有效地处理了多个文件间的联系所产生的冗余问题，但关系本身内部数据之间的联系还没有得到充分解决，如例5.1所示。同一关系模式中各个属性之间存在着某种联系，如学生与系、课程与教师之间存在着依赖关系的事实，才使得数据出现大量冗余，引发各种操作异常。这种依赖关系称之为数据依赖。

关系系统当中，数据冗余产生的重要原因就在于对数据依赖的处理，从而影响到关系模式本身的结构设计。解决数据间的依赖关系常常采用对关系的分解来消除不合理的部分，以减少数据冗余。在例5.1中，我们将Teaching关系分解为三个关系模式来表达：Student

(Sno，Sname，Ssex，Sdept)，Course(Cno，Cname，Tname)及Score(Sno，Cno，Grade)，其中Cno为学生选修的课程编号；分解后的部分数据如表5.2、表5.3和表5.4所示。

对教学关系进行分解后，我们再来考察一下：

(1)数据存储量减少。

设有n个学生，每个学生平均选修m门课程，则表5.1中学生的信息就有4nm之多。经过改进后，Student及Score表中学生的信息仅为3n

+

mn。学生信息的存储量减少了3(m-1)n。显然，学生选课数绝不会是1，因而，经过分解后数据量要少得多。

(2)更新方便。

①插入问题部分解决。对一位教师所开的无人选修的课程可方便地在Course表中插入。但是，针对新分配来的教师、新成立的系或列入计划但目前不开课的课程，还是无法插入。要解决无法插入的问题，还需通过继续将系名与课程作分解来解决。

②更新方便。原关系中对数据更新所造成的数据不一致性，在分解后得到了很好的解决，改进后，只需要更新一处即可。

③删除问题也部分解决。当所有学生都退选一门课程时，删除退选的课程不会丢失该门课程的信息。值得注意的是，系的信息丢失问题依然存在，解决的方法是还需继续进行分解。

虽然改进后的模式部分地解决了不合理的关系模式所带来的问题，但同时，改进后的关系模式也会带来新的问题。例如，当查询某个系的学生成绩时，就需要将两个关系连接后进行查询，增加了查询时关系的连接开销，而关系的连接代价却又是很大的。

下面给出四个存在异常的关系模式及其语义，并且在后面的内容中分别加以引用。

(1)示例模式1。

Order(Id,Amount,Product_Id,Name,Price,Order_Id,Cost)；

该关系模式根据数据库应用系统开发项目建立，用来存放商品名称、商品价格、商品数量和订单金额信息。其中，Order为关系模式名，Id为订单条目编号，Amount为商品数量，Product_Id为商品编号，Name为商品名称，Price为商品价格，Order_Id为订单编号，Cost为订单金额。

假定该关系模式包含如下数据语义。

①订单与订单条目之间是l∶n的联系，即一个订单可有多个订单条目，但一个订单条目只能属于一个订单；

②商品与订单条目之间是1∶n的联系，即一种商品可以有多个订单条目，但一个订单条目只能有一种商品；

③商品与订单之间是m∶n的联系，即一种商品可以属于多个订单，一个订单可以有多种商品。

由上述语义，可以确定该关系模式的主码为(Id，Product_Id，Order_Id)。

(2)示例模式2。

Students(Sno,Sname,Sdept,Mname,Cno,CName,Grade)；

该关系模式用来存放学生及其所在的系和选课信息。其中，Students为关系模式名，Sno为学生的学号，Sname为学生姓名，Sdept为学生所在系的名称，Mname为学生所在系的系主任，Cno为学生所选修课程的课程号，CName为课程号对应的课程名，Grade为学生选修该课程的成绩。

假定该关系模式包含如下数据语义。

①系与学生之间是1∶n的联系，即一个系有多名学生，而一名学生只属于一个系。

②系与系主任之间是1∶1的联系，即一个系只有一名系主任，一名系主任也只在一个系任职。

③学生与课程之间是m∶n的联系，即一名学生可选修多门课程，而每门课程有多名学生选修，且该联系有一描述学生成绩的属性。

由上述语义，可以确定该关系模式的主码为(Sno，Cno)。

同时还假定，学生与学生所在的系及系主任姓名均存放在此关系模式中，且无单独的关系模式分别存放学生与学生所在的系及系主任姓名等信息。

(3)示例模式3。

STC(Sno,Tno,Cno);

该关系模式用来存放学生、教师及课程信息。其中，STC为关系模式名，Sno为学生的学号，Tno为教师的编号，Cno为学生所选修的、由某教师讲授课程的课程号。

假定该关系模式包含如下数据语义。

①课程与教师之间是1∶n的联系，即一门课程可由多名教师讲授，而一名教师只讲授一门课程。

②学生与课程之间是m∶n的联系，即一名学生可选修多门课程，而每门课程有多名学生选修。

由上述语义可知，该关系模式的码为(Sno，Cno)和(Sno，Tno)。

(4)示例模式4。

Teach(Cname,Tname,Rbook);

该关系模式用来存放课程、教师及课程参考书信息。其中，Teach为关系模式名，Cname为课程名，Tname为教师名，Rbook为某课程的参考书名。

假定该关系模式包含如下数据语义。

①课程与教师之间是m∶n的联系，即一门课程由多名教师讲授，而一名教师可讲授多门课程。

②课程与参考书之间是m∶n的联系，即一门课程使用多本参考书，一本参考书可用于多门课程。

③以上两个m∶n联系是分离的，即讲授课程的教师与课程的参考书之间是彼此独立的。换句话说，讲授某一课程的教师必须使用该门课程所有的参考书。

由上述语义可知，该关系模式的主码为(Cname，Tname，Rbook)。

5.1.2函数依赖

现实世界是随着时间的变化而不断变化的，因而，反映现实世界的关系也会变化。但是，现实世界的已有事实限定了关系的变化必须满足一定的完整性约束条件。这些约束或者通过对属性取值范围的限定，或者通过属性值间的相互关联(主要体现为值是否相等)反映出来。后者称为数据依赖，这种数据依赖是现实系统中实体属性间相互联系的抽象，是数据内在的性质，是语义的体现。它是数据模式设计的关键。数据依赖极为普遍地存在于现实世界中，可分为多种类型，其中最重要的是函数依赖。函数依赖用于说明在一个关系中属性之间的相互作用情况。

一般地，对于关系模式Ｒ，U为其属性集合，

X、Y为其属性子集，根据函数依赖的定义和实体间联系的定义，可以得出如下变换方法：

①如果X和Y之间是1∶1的联系，则存在函数依赖X→Y和Y→X。

②如果X和Y之间是1∶n的联系，则存在函数依赖Y→X。

③如果X和Y之间是m∶n的联系，则X和Y之间不存在函数依赖关系。

例如，在示例关系模式1(即Order关系模式)中，商品编号与商品名称之间是1∶1的联系，故有Product_Id→Name和Name→Product_Id函数依赖；商品名称与订单条目编号之间是l∶n 的联系，所以有函数依赖Id→Name；商品编号与订单编号之间是m∶n的联系，所以Product_Id与Order_Id之间不存在函数依赖。

【例5.2】在示例关系模式1中，(Id,Product_Id,Order_Id)为主码，Product_Id与Name之间为完全函数依赖关系，即Product_Id

Name，而(Id，Product_Id)与Name之间则为部分函数依赖关系，即(Id,Product_Id)

Name，因为Name只需Product_Id决定即可，不需要由Id和Product_Id共同决定。

说明：如果函数依赖的决定子只有一个属性，则该函数依赖肯定是完全函数依赖，部分函数依赖只有在决定子含有两个或两个以上属性时才可能存在。

决定子含有多个属性的情况，一般是针对由多个属性组成的主码或候选码而言的。因为只有对这类主码或候选码来谈它们与其他属性间的完全或部分函数依赖才有意义。例如，示例关系模式1中的(Id,Product_Id,Order_Id)是主码，找该主码与其他属性间的函数依赖关系是有意义的，如果在关系模式中随意将属性进行组合，再来找与其他属性间的函数依赖，则没有太大意义。何况，如果关系模式中的属性个数比较多，则任意组合关系模式中的属性所得到的组合个数也是非常大的。

5.1.3码

码是关系模式中一个重要概念。前面章节中已给出了有关码的若干定义。这里用函数依赖的概念来定义码。

说明：

①候选码可以唯一地识别关系的元组。

②一个关系模式可能具有多个候选码，可以指定一个候选码作为识别关系元组的主键或主码(PrimaryKey)。

③包含在任何一个候选码中的属性称为主属性(PrimeAttribute)或键属性(KeyAttribute)，而不包含在任何候选码中的属性则称为非主属性(Non-primeAttribute)或非键属性(Non-keyAttribute)。

④最简单的情况下，候选码只包含一个属性。

⑤最复杂的情况下，候选码包含关系模式的所有属性，称为全码(All-Key)。

【例5.4】关系模式Product(Product_Id,Name,Price)中单个属性Product_Id是码，Order_Item(Id，Product_Id，Amount)中属性组合(Id,Product_Id)是码，它们均用下画线表示出来。

【例5.5】关系模式R(P，W，A)中属性P表示演奏者，W表示作品，A表示听众。假设一个演奏者可以演奏多个作品，某一作品可被多个演奏者演奏，听众也可以欣赏不同演奏者的不同作品，这个关系模式的码为(P，W，A)，即All-Key。

定义5.6：设X是关系模式R的属性子集合。如果X是另一个关系模式的候选码，则称X是R的外部码(ForeignKey)，简称外码或外键。

例如，在Order_Item(Id,Product_Id,Amount)中，Product_Id不是码，但Product_Id是关系模式Product(Product_Id,Name,Price)的码，则Product_Id是关系模式Order_Item的外码。

主码与外码提供了一个表示关系间联系的手段。如例5.4中关系模式Product与Order_Item的联系就是通过Product_Id来体现的。

【例5.6】职工(职工号，姓名，性别，职称，部门号)；

部门(部门号，部门名，电话，负责人)；

其中，职工关系中的“部门号”就是职工关系的一个外码。

在此需要注意，在定义中说X不是R的码，并不是说X不是R的主属性。X不是码，但可以是码的组成属性，或者是任一候选码中的一个主属性。

【例5.7】学生(学号，姓名，性别，年龄…)；

课程(课程号，课程名，任课老师…)；

选课(学号，课程号，成绩)；

在选课关系中，(学号，课程号)是该关系的码，学号、课程号又分别是组成主码的属性(但单独不是码)，它们分别是学生关系和课程关系的主码，所以是选课关系的两个外码。

关系间的联系，可以通过同时存在于两个或多个关系中的主码和外码的取值来建立。如要查询某个职工所在部门的情况，只需查询部门表中的部门号与该职工部门号相同的记录即可。所以，主码和外码提供了一个表示关系间联系的途径。

5.2范式

所谓“第几范式”，是表示关系的某一种级别，所以经常称某一关系模式R为第几范式。现在把范式这个概念理解成符合某一种级别的关系模式的集合，则R为第几范式就可以写成NF。

对于各种范式之间的联系有：1NF

2NF

3NF

BCNF

4NF

5NF成立，如图5.1所示。

图5.1各种范式之间的联系

一个低一级范式的关系模式，通过模式分解(SchemaDecomposition)可以转换为若干个高一级范式的关系模式的集合，这种过程就叫规范化(Normalization)。关系模式的规范化过程实质上是以结构更简单、更规则的关系模式逐步取代原有关系模式的过程。关系模式规范化的目的在于控制数据冗余，避免插入异常和删除异常的操作，从而增强数据库结构的稳定性和灵活性。

说明：

①1NF级别最低，5NF级别最高。

②高级别范式可看成是低级别范式的特例。

③一般说来，1NF是关系模式必须满足的最低要求。

范式级别与异常问题的关系是：级别越低，出现异常的程度越高。

5.2.11NF

第一范式(FirstNormalForm)是最基本的规范形式，即关系中每个属性都是不可再分的简单项。

定义5.7：设R是一个关系模式，如果R的每个属性的值域，都是不可分的简单数据项的集合，则称R为第一范式，简称1NF，记作1NF。

下述例子如表5.5、表5.6所示，由于具有组合数据项或多值数据项，因而它们都不是规范化的关系模式。

非规范化的关系模式转化为1NF的方法很简单，当然也不是唯一的，对表5.5、表5.6分别进行横向和纵向展开，即可转化为如表5.7、表5.8所示的符合1NF的关系模式。

SLC关系存在以下三个问题：

(1)插入异常。假若要插入一个Sno

= “1002”，Sdept

=“IS”，Sloc

=“N”，但还未选课的学生，即这个学生无Cno，这样的元组不能插入SLC中，因为插入时必须给定码值，而此时码值的一部分为空，因而该学生的信息无法插入。

(2)删除异常。假定某个学生只选修了一门课，如“1024”号学生只选修了3号课程。现在3号课程这个数据项要删除，那么他连3号课程也选修不了。课程号3是主属性，删除了课程号3，整个元组就不能存在了，也必须跟着删除，从而删除了“1024”号学生的其他信息，产生了删除异常，即不应删除的信息也删除了。

(3)数据冗余度大。如果一个学生选修了10门课程，那么他的Sdept和Sloc值就要重复存储10次。并且，当某个学生从数学系转到信息系，这本来只是一件事，只需要修改此学生元组中的Sdept值。但因为关系模式SLC还含有系的住处Sloc属性，学生转系将同时改变住处，因而还必须修改元组中Sloc的值。另外，由于这个学生选修了10门课，Sdept和Sloc重复存储了10次，当数据更新时必须无遗漏地修改10个元组中的Sdept和Sloc信息。这就造成了修改的复杂化，存在破坏数据一致性的隐患。

因此，SLC不是一个好的关系模式。

关系模式仅满足1NF是不够的，仍可能出现插入异常、删除异常、数据冗余及更新异常等问题。因为在关系模式中可能存在部分函数依赖与传递函数依赖。例如，本章开头给出的4个示例关系模式都是1NF，但它们仍存在异常。

下面以示例关系模式1为例来讲述1NF关系模式的异常情况。

该关系模式存在以下四种异常：

(1)插入异常。插入订单时，订单中没有该商品，则不能插入。因为主码为(Id，Product_Id，Order_Id)，Product_Id为空值(NULL)。这就是插入异常的第一种表现，即元组插不进去。

(2)删除异常。假如某订单只选了一种商品，现要删除该订单所对应的商品，则该订单的信息也被删除。此为删除异常的第一种表现，即删除时，删掉了其他信息。

(3)数据冗余。假如某订单有多种商品，则存在有多行多个字段值的重复存储。因为该订单的订单信息会多次重复存储。

(4)更新异常。由于存在前面所说的冗余，故如果某订单要修改，则要修改多行。

5.2.22NF

定义5.8：若关系模式R是1NF，而且每一个非主属性都完全函数依赖于R的码，则称R为第二范式(SecondNormalForm)，简称2NF，记作2NF。

2NF的实质是不存在非主属性“部分函数依赖”于码的情况。

非2NF关系或1NF关系向2NF的转换方法是：消除其中的部分函数依赖，一般是将一个关系模式分解成多个2NF的关系模式，即将部分函数依赖于码的非主属性及其决定属性移出，另成一关系，使其满足2NF。

关系模式SLC出现上述问题的原因是Sdept、Sloc对码的部分函数依赖。为了消除这些部分函数依赖，可以采用投影分解法，把SLC分解为两个关系模式：

SC(Sno,Cno,Grade)；

SL(Sno,Sdept,Sloc)；

其中，SC的码为(Sno,Cno)，SL的码为Sno。

显然，在分解后的关系模式中，非主属性都完全函数依赖于码了，从而使上述三个问题在一定程度上得到了部分解决，具体如下：

(1)在SL关系中可以插入尚未选课的学生。

(2)删除学生选课情况涉及的是SC关系。如果一个学生所有的选课记录全部被删除了，那么只是SC关系中没有关于该学生的记录了，不会牵涉SL关系中关于该学生的记录。

(3)由于学生选修课程的情况与学生的基本情况是分开存储在两个关系中的，因此不论该学生选多少门课程，对Sdept和Sloc值都只存储了1次，这就大大降低了数据冗余程度。学生从数学系转到信息系，只需修改SL关系中该学生元组的Sdept值和Sloc值即可。由于Sdept、Sloc并未重复存储，因此简化了修改操作。

例如，2NF关系模式SL(Sno,Sdept,Sloc)中有下列函数依赖：

Sno→Sdept；

Sdept→Sloc；

Sno→Sloc。

由上可知，Sloc传递函数依赖于Sno，即SL中存在非主属性对码的传递函数依赖，SL关系中仍然存在删除异常、数据冗余度大和修改复杂的问题，具体如下：

(1)删除异常。如果某个系的学生全部毕业了，在删除该系学生信息的同时，把这个系的信息也丢掉了。

(2)数据冗余度大。每一个系的学生都住在同一个地方，关于系的住处的信息却重复出现，重复次数与该系学生人数相同。

(3)修改复杂。当学校调整学生住处时，比如信息系的学生全部迁到另一地方住宿时，由于关于每个系的住处信息是重复存储的，修改时必须同时更新该系所有学生的Sloc属性值。所以SL仍然存在操作异常问题，该模式仍然不是一个好的关系模式。

【例5.9】1NF分解示例。

(1)以订单明细表为例。

OrderDetail(OrderId,ProductId,ProductName,Price,Amount)。

我们知道在一个订单中可以订购多种产品，所以单独一个OrderId是不足以成为主码的，主码应该是(OrderId，ProductId)。显而易见，Amount(商品数量)完全依赖(取决)于主码(OrderId，ProductId)，而Price、ProductName只依赖于ProductId，所以OrderDetail表不符合2NF。不符合2NF的设计容易产生数据冗余，可以把OrderDetail表拆分为Order_Item(OrderId，ProductId，Amount)和Product(ProductId，ProductName，Price)来消除原订单表中Price、ProductName多次重复的情况。

(2)以示例关系模式2为例。

Students(Sno,Sname,Sdept,Mname,Cno,Cname,Grade)。

将其分解为3个2NF关系模式，各自的模式及函数依赖分别如下：

①

Student(Sno,Sname,Sdept,Mname)；

{Sno→Sname,Sno→Sdept,Sdept→Mname,Sno→Mname}；

②

Score(Sno,Cno,Grade)；

{(Sno,Cno)

Grade}；

③

Course(Cno,Cname)；

{Cno→Cname}。

这时，分解出的3个2NF关系模式的函数依赖关系，不再存在非主属性“部分函数依赖”于码的情况了。

不过，2NF关系仍可能存在插入异常、删除异常、数据冗余和更新异常的问题。因为2NF关系中还可能存在“传递函数依赖”。

【例5.10】2NF异常情况。

以例5.9分解出的第一个2NF关系模式为例，即

Student(Sno,Sname,Sdept,Mname)。

该关系模式的主码为Sno，其中的函数依赖关系有

{Sno→Sname,Sno→Sdept,Sdept→Mname,Sno→Mname}。

该关系模式存在以下四种异常：

(1)插入异常。插入尚未招生的系时，插入会失败，因为主码是Sno，而其值为NULL。

(2)删除异常。如果某系学生全毕业了，删除学生，则会删除系的信息。

(3)数据冗余。由于一个系有众多学生，而每个学生均带有系信息，故会产生数据冗余。

(4)更新异常。由于存在数据冗余，故如果要修改一个系的信息，则要修改多行。

5.2.33NF

定义5.9：若关系模式R是2NF，而且它的任何一个非主属性都不传递函数依赖于R的任何候选码，则称R为第三范式(ThirdNormalForm)，简称3NF，记作3NF。

另一个等效的定义是，在一关系模式中，对任一非平凡函数依赖，如满足下列条件之一：

①是超码(SuperKey，含有码的属性集)；

②是码的一部分；

则称此关系属于3NF。

在关系模式中，既没有非主属性对码的部分函数依赖，也没有非主属性对码的传递函数依赖，基本上解决了上述问题，其效果如下：

(1)

DL关系中可以插入无在校学生的信息。

(2)某个系的学生全部毕业了，只是删除SD关系中的相应元组，DL关系中关于该系的信息仍然存在。

(3)关于系的住处的信息只在DL关系中存储一次。

(4)当学校调整某个系的学生住处时，只需修改DL关系中一个相应元组的Sloc属性值即可。

【例5.11】2NF分解示例。

(1)以一个订单表为例。Order(OrderId,OrderDate,UserId,UserName,UserAddress,Postcode)的主码是OrderId。其中，OrderDate,UserId,UserName,UserAddress,Postcode等非主码列都完全依赖于主码OrderId，所以符合2NF。不过问题是UserName,UserAddress,Postcode直接依赖的是UserId(非主码列)，而不是直接依赖于主码，它是通过传递函数才依赖于主码的，所以不符合3NF标准。

通过拆分Order为User_Order(OrderId,OrderDate,UserId)和User(UserId,UserName,UserAddress,Postcode)，从而使各关系模式均达到3NF标准。

(2)以例5.9分解出的第一个2NF关系模式为例。

Student(Sno,Sname,Sdept,Mname)。

在该关系模式的函数依赖关系中，存在一传递函数依赖：

{Sno→Sname，Sdept→Mname，Sno→Mname}。

通过消除该传递函数依赖，将其分解为两个3NF关系模式。各自的模式及函数依赖分别如下：

①

Stud(Sno,Sname,Sdept)；

{Sno→Sname,Sno→Sdept}；

②

Dept(Sdept,Mname)；

{Sdept→Mname，Mname→Sdept}。

【例5.12】3NF异常情况。

以示例关系模式3为例：

STC(Sno,Tno,Cno)。

该关系模式的候选码为(Sno,Cno)和(Sno,Tno)，其中的函数依赖关系如下：

{(Sno,Cno)

Tno,Tno

Cno,(Sno,Tno)

Cno}。

该关系模式尽管存在一个部分函数依赖关系，但它是主属性Cno(因为Cno是其中一个候选码的属性)部分函数依赖于候选码(Sno,Tno)的情况，而不是非主属性部分函数依赖于码的情况。因此，该关系模式属于第三范式。

该关系模式存在以下四种异常：

(1)插入异常。插入尚未选课的学生时，不能插入；插入没有学生选课的课程时，不能插入。因为该关系模式有两个候选码，无论哪种情况的插入，都会出现候选码中的某个主属性值为NULL，故不能插入。

(2)删除异常。如果选修某课程的学生全毕业了，则删除学生信息时会删除课程的信息。

(3)数据冗余。每个选修某课程的学生均带有教师的信息，故会产生数据冗余。

(4)更新异常。由于存在冗余，故如果修改某门课程的信息，则要修改多行。

5.2.4BCNF

BCNF(BoyceCoddNormalForm)范式是由Boyce和E.F.Codd提出的，故称BCNF范式，亦被认为是增强的第三范式，有时也称为扩充的第三范式。

定义5.10：若关系模式R是1NF，如果对于R的每个函数依赖X→Y(

)，X必为候选码，则R为BCNF范式，记作

BCNF。

每个BCNF范式都具有以下三个性质：

(1)所有非主属性都完全函数依赖于每个候选码。

(2)所有码属性都完全函数依赖于每个不包含它的候选码。

(3)没有任何属性完全函数依赖于非码的任何一组属性。

说明：

①由于BCNF的每一个非平凡函数依赖的决定子必为候选码，故不会出现3NF中决定子可能不是候选码的情况。

②3NF与BCNF之间的区别在于，对一个函数依赖X→Y，3NF允许Y是主属性，而X不为候选码；但BCNF要求X必为候选码。因此，3NF不一定是BCNF，而BCNF一定是3NF。

③3NF和BCNF常常都是数据库设计者所追求的关系范式。有些文献在不引起误解的情况下，统称它们为第三范式。

④如果一个关系数据库的所有关系模式都属于BCNF，那么在函数依赖范畴内，它已达到了最高的规范化程度(但不是最完美的范式)，在一定程度上消除了插入异常、删除异常、数据冗余和更新异常。

从例5.13也可以看出，第三范式也避免不了异常性。如某课程本学期不开设，因此无学生选读，此时有关教师固定开设某课程的信息就无法表示。因此，要避免此种异常性，还需要进一步将关系模式分解成BCNF。如在此例中可将R进一步分解成：

R1(S,T

)；

R2(T,C

)；

R1，R2则为BCNF，这两个模式均不会产生异常现象。

综上所述，可以看出，BCNF比3NF更为严格。它将关系模式中的属性分成两类，一类是决定因素集，另一类是非决定因素集。非决定因素集中的属性均不传递函数依赖于决定因素集中的每个决定因素。

【例5.14】3NF分解示例。

以示例关系模式3为例，即

STC(Sno,Tno,Cno)。

该关系模式的候选码为(Sno,Cno)和(Sno,Tno)。由例5.12可知，该关系模式属于第三范式，且存在一个主属性Cno部分函数依赖于候选码(Sno,Tno)的情况。

通过消除主属性Cno的部分函数依赖，将其分解为ST(Sno,Tno)和TC(Tno,Cno)两个BCNF关系模式。

这时，分解出的两个BCNF关系模式不再存在主属性部分函数依赖于码的情况了。

下面用四个例子说明属于3NF的关系模式有的属于BCNF关系模式，但有的不属于BCNF关系模式。

在范式中，常用的是3NF和BCNF。在设计数据库时要综合考虑，因为尽管分解关系模式可以减少数据冗余，也可以克服数据操作容易出现异常等问题，但是数据库操作的复杂性也提高了，系统在进行多关系表操作时的开销也更大。

3NF和BCNF是在函数依赖的条件下对模式分解所能达到的分离程度的测度。一个模式中的关系模式如果都属于BCNF，那么在函数依赖范畴内，它已实现了彻底的分离，消除了插入异常和删除异常。但3NF的“不彻底”性表现在可能存在主属性对码的部分函数依赖和传递函数依赖。

5.2.5多值依赖与4NF

1．概述

属于BCNF范式的关系模式仍可能存在异常。其原因是存在多值依赖情况。

在对多值依赖描述之前，有必要理顺各个数据依赖所讨论(或关注)问题的思路，这对于明确问题的实质有帮助。

各个数据依赖所讨论问题的思路如下：

(1)函数依赖讨论的是元组内属性与属性间的依赖或决定关系对属性取值的影响，即属性级的影响。例如，某一属性值的插入要取决于其他属性或某一属性值的删除会影响到的其他属性。

(2)现将视线上升到对元组级的影响，即讨论元组内属性间的依赖关系对元组级的影响。也就是讨论某一属性取值在插入与删除时，是否影响多个元组，这就是多值依赖讨论的问题。

(3)不过，函数依赖和多值依赖在数据冗余及更新异常上的表现是相同的。关于数据冗余和更新异常的表现，可参见5.1小节的内容。

(4)沿上述思路发展下去，还会有对关系级的影响，这就是后续关于连接依赖的讨论。这里不再讨论连接依赖，有兴趣的读者可以参阅有关书籍。

2．BCNF范式异常示例

以示例关系模式4为例，即

Teach(Cname,Tname,Rbook)。

该关系模式的主码为(Cname,Tname,Rbook)。由BCNF范式的定义及性质可知，此模式属于BCNF范式。

然而，该关系模式仍然存在以下异常：

(1)插入异常。插入某课程授课教师时，因该课程有多本参考书，需插入多个元组。这是插入异常的表现之一。

(2)删除异常。删除某门课程的一本参考书时，因该课程授课教师有多名，故需删除多个元组。此为删除异常的表现之一。

(3)数据冗余。由于有多名授课教师，故每门课程的参考书需存储多次，有大量数据冗余。

(4)更新异常。修改一门课程的参考书时，因该课程涉及多名教师，故需修改多个元组。

3．多值依赖的定义

【例5.19】某一门课程由多个教员讲授，他们使用相同的一套参考书。每个教员可以讲授多门课程，每种参考书可以供多门课程使用。下列是用一个非规范化的表来表示教员T，课程C和参考书B之间的关系，如表5.9所示。

把表5.9变换成一张规范化的二维表Teaching，如表5.10所示。

从表5.10中可以看出以下两点：

(1)这个关系的数据冗余很大。

(2)这个关系的属性间有一种有别于函数依赖的依赖关系存在。

我们仔细分析这种特殊的依赖关系后，发现它有以下两个特点：

关于这个情况可以用表5.11表示。

对多值依赖有了充分了解后，我们可对它定义如下：

【例5.20】多值依赖示例。

以示例关系模式4为例，即

Teach(Cname,Tname,Rbook)，

其上的多值依赖关系有：{Cname

Tname,Cname

Rbook}。

因为每组(Cname，Rbook)的值对应一组Tname值，且这种对应只与Cname值有关(或只依赖于Cname的值)，而与Rbook的值无关。同样，每组(Cname，Tname)的值对应一组Rbook值，且这种对应只与Cname的值有关，而与Tname的值无关。

多值依赖具有以下六个性质：

4．多值依赖与函数依赖间的区别

5．4NF

函数依赖和多值依赖是两种最重要的数据依赖。如果只考虑函数依赖，则属于BCNF的关系模式规范化程度已经是最高的了。如果考虑多值依赖，则属于4NF的关系模式的规范化程度是最高的。事实上，数据依赖中除函数依赖和多值依赖之外，还有其他数据依赖。例如，有一种叫做连接依赖。函数依赖是多值依赖的一种特殊情况，而多值依赖实际上又是连接依赖的一种特殊情况。但连接依赖不像函数依赖和多值依赖那样可由语义直接导出，它要在关系的连接运算时才能反映出来。存在连接依赖的关系模式仍可能遇到数据冗余及插入异常、更新异常、删除异常等问题。如果消除了属于4NF的关系模式中存在的连接依赖，则可以进一步达到5NF的关系模式。这里不再讨论连接依赖和5NF，有兴趣的读者可以参阅有关书籍。

5.2.6规范化小结

在关系数据库中，对关系模式的基本要求是满足第一范式。这样的关系模式才是合法的。但是，人们发现有些关系模式存在插入异常、删除异常，修改复杂，数据冗余等问题。解决这些问题的方法就是规范化。

规范化的基本思想是逐步消除数据依赖中不合适的部分，使模式中的各关系模式达到某种程度的“分离”，即“一事一地”的模式设计原则，让一个关系描述一个概念、一个实体或者实体间的一种联系。如果多于一个概念，就把它“分离”出去。因此，所谓规范化实质上是概念的单一化。

规范化工作是将给定的关系模式按范式级别由低到高，逐步分解为多个关系模式。实际上，在前面的叙述中，分别介绍了各低级别的范式向其高级别范式的转换方法。人们认识这个原则是经历了一个过程的，从认识非主属性的部分函数依赖的弊端开始，2NF、3NF、BCNF和4NF的提出是这个认识过程逐步深化的标志，图5.2可以概括这个过程。

图5.2关系模式的规范化过程

关系模式的规范化过程是通过对关系模式的分解来实现的。把低一级的关系模式分解为若干个高一级的关系模式。这种分解不是唯一的。下面将进一步讨论分解后的关系模式与原关系模式“等价”的问题以及分解的算法。

5.3函数依赖的公理系统

函数依赖的公理系统是模式分解算法的理论基础。1974年，W.W.Armstrong总结了各种推理规则，把其中最主要、最基本的作为公理，这就是著名的Armstrong推理规则系统，又称为Armstrong公理(或阿氏公理)。

5.4模式分解

5.4.1模式分解定义

对一个模式的分解是多种多样的，但是分解后产生的模式应与原模式等价。

人们从不同的角度去观察问题，对“等价”的概念形成了三种不同的定义：

·分解具有“无损连接性(LosslessJoin)”。

·分解要“保持函数依赖(PreserveFunctionalDependency)”。

·分解既要“保持函数依赖”，又要具有“无损连接性”。

本节要讨论的问题有：

(1)“无损连接性”和“保持函数依赖”的含义是什么？如何判断？

(2)不同的分解等价定义能达到何种程度的分离，即分离后的关系模式是第几范式。

(3)如何实现分离，即给出分解的算法。

【例5.28】已知关系模式，其中U

=

{Sno，Sdept，Mname}，F

=

{Sno→Sdept，Sdept→Mname}。

的元组语义是学生Sno正在Sdept系学习，其系主任是Mname。一个学生(Sno)只在一个系学习，一个系只有一名系主任。R的一个关系示例如表5.14所示。

由于R中存在传递函数依赖Sno→Mname，因此它会产生更新异常。例如，如果S4毕业，则D4系的系主任王五的信息也就丢掉了。反之，如果一个系D5尚无在校学生，那么这个系的系主任是李某的信息也无法插入。于是，我们进行了如下分解：

对于分解后的数据库，要回答“Sl在哪个系学习”这样的问题已不可能。

如果分解后的数据库能够恢复到原来的情况，不丢失信息的要求也就达到了。Ri向R的恢复是通过自然连接来实现的，这就形成了无损连接性的概念。显然，本例的分解所产生的诸关系的自然连接的结果实际上是它们的笛卡尔积。这就使得其元组增加，信息丢失。

于是，对R又进行另一种分解：

ρ2

=

{R1

<

{Sno，Sdept}，{Sno→Sdept}

> ，R2

< {Sno，Mname}，{Sno→Mname}>}

以后可以证明ρ2对R的分解是可恢复的，但是前面提到的插入异常和删除异常仍然没有解决，其原因就在于原来在R中存在的函数依赖SdeptMname，现在在R1和R2中都不再存在了。因此，人们又要求分解具有“保持函数依赖”的特性。

最后对R进行以下分解：

ρ3

=

{R1

<

{Sno，Sdept}，{Sno→Sdept}

> ，R2

< {Sdept，Mname}，{Sdept→Mname}>}

可以证明，分解ρ3既具有“无损连接性”，又拥有“保持函数依赖”的特性。它解决了更新异常，又没有丢失原数据库的信息，这是人们所希望的分解。

由此，可以看出人们提出数据库模式“等价”的三个不同定义的原因。

5.4.2分解的无损连接性和保持函数依赖性

1．无损连接性

【例5.29】设有关系模式，其中，将其分解为关系模式集合ρ

=

{R1(A，B)}，{R2(A，C)}如图5.3所示。

图5.3无损分解

在图5.3中，图(a)是R上一个关系，图(b)和图(c)是r在模式R1(A，B)和R2(A，C)上的投影r1和r2。此时，不难得到

r1

r2=r。也就是说，在r投影和连接之后，仍然能够恢复为r，即没有丢失任何信息，这种模式分解就是无损分解。

的有损分解如图5.4所示。在图5.4中，图(a)R是上一个关系r，图(b)和图(c)是r在关系模式R1(A，B)和R2(A，C)上的投影，图(d)是r1r2。此时，r在投影和连接之后比原来r的元组还要多(即增加了噪声)，同时将原有的信息丢失了。此时的分解就为有损分解。

图5.4有损分解图5.5例5.30的初始表格图5.6例5.30修改后的表格

当关系模式R分解为两个关系模式R1、R2时，有下面的判定准则。

(1)构造初始表格，如表5.15所示。

(2)重复检查F中的函数依赖，修改表格元素。

①根据A→C，对表5.15进行行处理，由于第1、2和5行在A分量(列)上的值为a1(即相同)，在C分量上的值不相同，因此将属性C列的第1、2和5行上的值b13、b23和b53改为同一符号b13，结果如表5.16所示。

②根据B→C，考察表5.16，由于第2行和第3行在B列上相等，在C列上不相等，因此将属性C列的第2行和第3行中的b13和b33改为同一符号b13，结果如表5.17所示。

③根据C→D，考察表5.17，由于第1、2、3和5行在C列上的值为b13(相等)，在D列上的值不相等，因此将D列的第1、2、3和5行上的元素a4、b24、b34和b54都改为a4，结果如表5.18所示。

④根据{D，E}→C，考察表5.18，由于第3、4和5行在D和E列上的值为a4和a5(即相等)，在C列上的值不相等，因此将C列的第3、4和5行上的元素都改为a3，结果如表5.19所示。

⑤根据{C，E}→A，考察表5.19，将A列的第3、4和5行的元素都改成a1，结果如表5.20所示。

由于F中的所有函数依赖都已经检查完毕，表5.20中第三行为a1，a2，a3，a4，a5，所以关系模式的分解是无损分解。

2．保持函数依赖性

保持关系模式分解等价的一个重要条件是，原模式所满足的函数依赖在分解后的模式中仍保持不变。这就是保持函数依赖性。

5.4.3模式分解的算法

对关系模式进行模式分解，使它的模式成为3NF、BCNF或4NF，但这不一定都能保证分解具有无损连接性和保持函数依赖性。对于任一关系模式，可找到一个分解达到3NF，且具有无损连接性和保持函数依赖性。而对模式的BCNF或4NF分解，可以保证无损连接性，但不一定能保证保持函数依赖性。

算法