第9章 关系数据库规范化理论

DLPU第9章关系数据库规范化理论1.函数依赖2.规范化面向具体的应用需求，建立适合的关系数据库系统，关键是关系数据库模式的设计。关系数据库模式是由若干关系模式组成的，这些关系模式并不是完全孤立的，它们之间可能存在着某种联系。一个好的关系数据库模式应该包括多少关系模式，而每一个关系模式又应该包括哪些属性，又如何将这些相互关联的关系模式组建一个适合的关系模型，这些工作决定了到整个系统运行的效率，也是系统成败的关键所在。规范化理论是关系数据库模式设计的理论指南，为评判关系模式的好坏提供了理论标准，也为得到好的关系模式提供了方法指南。9.1函数依赖关系模式中的各属性之间相互依赖、相互制约的联系称为数据依赖。数据依赖是通过一个关系中属性间的值的相等与否体现出来的数据间的相互关系。这些相互关系是根据现实世界的语义来确定的。作为一种重要的数据依赖，函数依赖（FunctionalDependency，简记为FD）极为普遍地存在于现实生活中。而在一些关系模式中，一些函数依赖的存在会对其产生不好的影响。9.1.1不好的关系模式存在的问题考虑某书店的图书销售关系Book_Order，该关系涉及的属性包括：OrderNo（订单号）、ClientNo（客户号）、ClientName（客户名）、Address（客户地址）、BookNo（书号）、Title（书名）、Publisher（出版社）、Price（单价）、Quantity（订购数量）。根据现实世界已知的事实，对于上述关系有如下语义：①订单号、客户号和书号分别唯一地确定一个份订单、一个客户和一种图书。②每份订单只对应唯一的一个客户，但一个客户可以有多个订单。③每个客户有唯一的客户名称和地址。④每种图书有唯一的书名、出版社和单价。⑤每份订单可以包含多种图书，每种图书也可以在多份订单中订购。⑥每份订单订购每一种图书，有唯一的订购数量。实际上，如果一组属性的值能够唯一地确定另一组属性的值，这两组属性之间就满足函数依赖（正式的定义将在后面给出）关系。因此，根据上述语义可以得到一组函数依赖：F={OrderNo→ClientNo,ClientNo→ClientName,ClientNo→Address,BookNo→Title,BookNo→Publisher,BookNo→Price,(OrderNo,BookNo)→Quantity}。关系模式Book_Order上述关系模式可以描述为Book_OrderU，F，其中，U={OrderNo,ClientNo,ClientName,Address,BookNo,Title,Publisher,Price,Quantity}。可以分析，Book_Order关系中订单号和书号的组合能够唯一地确定一条记录（标识一个元组），因此该关系模式的主键为(OrderNo,BookNo)。关系模式Book_Order对应的一个实例OrderNo订单号ClientNo客户号ClientName客户名Address地址BookNo书号Title书名Publisher出版社Price单价Quantity订购数量100010801北方大学北京04042数据结构清华大学出版社2250100010801北方大学北京06051数据库系统概论高等教育出版社33.840100010801北方大学北京09033数据库原理及应用机械工业出版社3130100020602赵刚上海06051数据库系统概论高等教育出版社33.830100020602赵刚上海04084人工智能清华大学出版社2730100030801北方大学北京99075Linux操作指南人民邮电出版社4025100030801北方大学北京08094人工智能教程电子工业出版社4025100040904南方大学长沙06051数据库系统概论高等教育出版社33.860100040904南方大学长沙04042数据结构清华大学出版社2230不好的关系模式存在的问题1.数据冗余太大2.更新异常（UpdateAnomalies）3.插入异常（InsertAnomalies）4.删除异常（DeleteAnomalies）这些异常主要是由于在一些属性之间存在某些依赖造成的。如果要把一个不好的关系模式改造成好的模式，就要设法消除那些会带来各种问题的依赖，这正是规范化理论要研究的问题。对于上述的Book_Order关系模式，如果将其改造成如下的四个关系模式，上述的插入异常、删除异常和数据冗余等问题都得到了很好的克服。Client(ClientNo,ClientName,Address,ClientNo→ClientName,ClientNo→Address)；Book(BookNo,Title,Publisher,Price,BookNo→Title,BookNo→Publisher,BookNo→Price)；OrderClient(OrderNo,ClientNo,OrderNo→ClientNo)；OrderBook(OrderNo,BookNo,Quantity,(OrderNo,BookNo)→Quantity)。9.1.2函数依赖的基本概念函数依赖的定义定义设关系模式R(U)，是属性集U上的关系模式，X和Y是U的子集。若对于R(U)的任意一个可能的关系r，r中不可能存在两个元组在X上的属性值相等，而在Y上的属性值不等，则称X函数决定Y，或Y函数依赖于X，记作X→Y。对于函数依赖，有几点要注意：函数依赖不是指关系模式R的某个或某些实例（关系）满足的约束条件，而是关系模式R的所有实例（关系）都必须满足的约束条件。函数依赖讨论的是属性之间的依赖关系，是由语义决定的。只能通过语义来确定一个函数依赖。设计者也可以根据现实世界的情况进行一些强制的规定。几个术语和记号若X→Y，则X叫做决定因素（Determinant），通常也称X为左部属性集（简称左部），Y为右部属性集（简称右部）。若X→Y，Y→X，则称X与Y等价，记作XY。若Y不函数依赖于X，则记作X↛Y。平凡与非平凡函数依赖定义对于任意的属性集X和Y，如果YX，那么一定有X→Y，这样的函数依赖称为平凡的函数依赖；否则如果X→Y，Y⊈X，则称X→Y是非平凡的函数依赖。若不特别声明，总是讨论非平凡的函数依赖。完全与部分函数依赖定义在关系模式R（U）中，如果X→Y，并且对于X的任何一个真子集，都有X'↛Y，则称Y完全函数依赖于X，记作：。若X→Y，Y不完全函数依赖于X，则称Y部分函数依赖于X，记作：。YXFYXP例子对于前面提到的关系模式Book_Order：(OrderNo,BookNo)Quantity，即订购数量完全函数依赖于订单号和书号；(OrderNo,BookNo)Title，即书名部分函数依赖于订单号和书号。FP传递函数依赖定义在关系模式R(U)中，如果X→Y，Y→Z，且Y⊈X，Y↛X，则称Z传递函数依赖于X，记作：XY。对于上述定义，加上限制条件Y⊈X是因为如果YX，那么，即Y部分函数依赖于X；加上限制条件Y↛X，是因为如果Y→X，则有XY，那么实际上是XY，即是直接函数依赖，而非传递函数依赖。TYXP直接例子对于关系模式Book_Order，OrderNo→ClientNo且ClientNo→ClientName，而ClientNo↛OrderNo，因此有OrderNoClientName，即客户名称传递函数依赖于订单号。T9.1.3键在前面的章节中，对键（也称做码、候选键或候选码）的概念已经进行了一些非形式化的说明。下面通过函数依赖给出键的严格定义。候选键的定义设K为RU，F中的属性或属性组合，若KU（即K完全函数决定R的全部属性U），则K为R的候选键(CandidateKey)，简称键。主键：若候选键多于一个，则选定其中的一个为主键(PrimaryKey)。全键：若候选键是由组成该关系模式的所有属性组成，此候选键就称为全键（AllKey）。主属性与非主属性：包含在任何一个候选键中的属性，叫做主属性(PrimeAttribute)；不包含在任何候选键中的属性称为非主属性(NonprimeAttribute)或非键属性(Non-keyAttribute)。F寻找候选键对于任何一个关系模式，找出该模式的候选键是一项非常重要且比较困难的工作。通常需要对关系模式的语义进行细致的分析。对于某个关系模式RU，F，寻找候选键时，以下分析是有帮助的。①如果U中的某个属性没有出现在F中的任何函数依赖当中（即任何依赖的左部和右部都不包含该属性），那么该属性一定是所有候选键中的属性；②如果某个属性只出现在F中的函数依赖的左部，那么该属性也一定是所有候选键中的属性。对于前面的关系模式Book_Order，(OrderNo,BookNo)是该模式的唯一的候选键，也是主键；相应地，OrderNo和BookNo是主属性，而其他的属性（包括：ClientNo，ClientName，Address，Title，Publisher，Price和Quantity）都是非主属性。键的例子1【例9-1】对于学生关系模式：学生(学号，姓名，性别，年龄，专业，身份证号)，由于每个学生有唯一的学号和身份证号，这两个属性分别都能函数决定学生关系模式的所有属性。因此，该关系模式的候选键有两个：学号和身份证号。可以选择其中之一作为主键。其主属性包括：学号和身份证号非主属性包括：姓名、性别、年龄和专业。键的例子2【例9-2】考虑某商业集团数据库中的一个关系模式：销售(商店编号，商品编号，库存数量，部门编号，负责人)。如果规定：①每个商店的每种商品只在一个部门销售；②每个商店的每个部门只有一个负责人；③每个商店的每种商品只有一个库存数量。根据语义，上述销售关系模式满足的函数依赖为：(商店编号，商品编号)→部门编号，(商店编号，部门编号)→负责人，(商店编号，商品编号)→库存数量。由于商店编号和商品编号只出现在函数依赖的左部，键中必含有这两个属性。而且，(商店编号，商品编号)能够完全函数决定该关系模式的所有属性，因此该销售关系模式的候选键（也是主键）为：(商店编号，商品编号)。相应地主属性包括：商店编号和商品编号。非主属性包括：部门编号、负责人和库存数量。键的例子3【例9-3】考虑一个描述教师授课的关系模式：授课(教师号，课程号，学期)。其满足的语义为：①每位教师可以讲授多门课程，每门课程可以由多位教师讲授；②每位教师可以在不同学期讲授同一门课程，每门课程在不同学期也可以由同一位教师讲授。根据语义，教师号、课程号和学期之间不存在任何非平凡的函数依赖，每一个属性都不出现在任何依赖中，只有这三个属性的值全部确定才能够确定一个元组，因此该关系模式的候选键为(教师号，课程号，学期)，是全键，此候选键也是主键。教师号、课程号和学期这三个属性都是主属性，不存在非主属性。外键（ForeignKey）定义关系模式R中属性或属性组X并非R的键，但X是另一个关系模式的键，则称X是R的外键(Foreignkey)，也称外码。例子例如，对于如下两个关系模式：专业(专业代码，专业名称，开设时间)；学生(学号，姓名，性别，年龄，专业代码)。9.2规范化规范化（Normalization）的基本思想是消除关系模式存在的数据依赖中的不合适部分，达到减小数据冗余，解决数据插入、删除时发生的异常问题。这就要求关系数据库设计出来的关系模式要满足一定的条件。我们把关系数据库的规范化过程中为不同程度的规范化要求设立的不同标准称为范式（NormalForm）。由于规范化程度的不同，就产生了不同级别的范式。每种范式都对关系模式规定了一些限制约束条件。范式的概念最早是由E.F.Codd提出的。从最低要求的1NF开始，形成了规范化程度从低到高的一系列范式：1NF，2NF，3NF