数据基础与应用 1

关系规范化理论第5章2026数据库原理与应用教材第90—103页本章为什么要学(1)本章导入教材第90页002/140【简介】本章节深入探讨了数据库规范化理论，核心内容围绕函数依赖展开。首先，定义了函数依赖的概念，阐述了其在数据库设计中的关键作用，即指导如何有效组织数据以减少冗余并保障数据完整性。函数依赖被分为完全依赖、部分依赖和传递依赖等类别，并详细讨论了其基本性质，如自反性、传递性和合并性。接着，通过实例详细解析了第一范式(1NF)至第三范式(3NF)以及BCNF(Boyce-Codd范式)的要求和实现路径。本章为什么要学(2)本章导入教材第90页003/140引入多值依赖和第四范式(4NF)。通过丰富实例，深入讲解了关系模式的分解原则及步骤，旨在优化数据库结构。同时，也讨论了规范化与反规范化的策略，强调在实际应用中需权衡数据冗余与查询性能，以达到最佳设计效果。在关系数据库的设计中，通常用E-R模型实现对现实世界中的事物、概念及其联系的抽象表示，再用关系(表)对E-R模型表示的信息进行组织和存储。E-R模型向关系的转化称为数据库逻辑结构设计。本章为什么要学(3)本章导入教材第90页004/140在将E-R模型转化成关系时，存在着关系设计的优劣问题，有时在构造的关系中会出现数据冗余和更新异常、插入异常、删除异常等现象。关系规范化理论为我们提供了判断关系模式好坏的理论标准。而这些标准是根据属性间的依赖关系，即函数依赖的概念给出的，因此，本节首先讨论函数依赖的概念，然后讨论规范化标准。本章知识要点(1)本章导入教材第90页005/1401NF、2NF、3NF、BCNF、4NF的定义本章内容地图本章导入教材第90页006/1405.1函数依赖5.2范式5.3关系模式的规范化5.4章节结语5.1函数依赖5.1函数依赖教材第91页007/1405.1函数依赖5.1.1函数依赖的定义5.1.2为什么要讨论函数依赖5.1.3函数依赖的分类5.1.4函数依赖的基本性质5.1.5主码和外部码5.1.1函数依赖的定义5.1.1函数依赖的定义教材第91页008/1405.1.1函数依赖的定义定义条件语义性质决定属性集教材食品关系示例5.1.1函数依赖的定义｜定义中的符号5.1.1函数依赖的定义教材第91页009/140R(U)：关系模式U：R的属性集合X、Y：U的子集5.1.1函数依赖的定义｜定义5.1.1函数依赖的定义教材第91页010/140教材定义函数依赖的定义：假设R(U)是一个关系模式，U是R的属性集合，X和Y是U的子集，即X⊆U，Y⊆U。设t₁，t₂是关系R中的任意两个元组，如果由t₁[X]=t₂[X]可以推导出t₁[Y]=t₂[Y]。则称“X函数决定Y“或“Y函数依赖于X“，记作X→Y。5.1.1函数依赖的定义｜教材说明(1)5.1.1函数依赖的定义教材第91页011/140对于函数依赖，需要说明以下几点。5.1.1函数依赖的定义｜性质（1）5.1.1函数依赖的定义教材第91页012/140教材定义函数依赖的定义：(1)函数依赖不是指关系模式R(U)的某个或某些关系实例满足的约束条件，而是指R(U)的所有关系实例均要满足的约束条件。5.1.1函数依赖的定义｜性质（2）5.1.1函数依赖的定义教材第91页013/140教材定义函数依赖的定义：(2)函数依赖和别的数据之间的依赖关系一样，是语义范畴的概念。例如，“姓名→年龄”这个函数依赖只有在没有同名学生的条件下成立。如果有相同名字的人，则“年龄“就不再依赖于“姓名“了。5.1.1函数依赖的定义｜性质（3）5.1.1函数依赖的定义教材第91页014/140教材定义函数依赖的定义：(3)若X→Y，则X称为这个函数依赖的决定属性集。5.1.1函数依赖的定义｜教材示例(1)5.1.1函数依赖的定义教材第91页015/140例如有食品关系食品(食品编号，食品名称，食品价格)5.1.1函数依赖的定义｜教材示例(2)5.1.1函数依赖的定义教材第91页016/140在该关系中则有函数依赖食品编号→食品名称5.1.1函数依赖的定义｜教材示例(3)5.1.1函数依赖的定义教材第91页017/140食品编号→食品价格显然函数依赖讨论的是属性之间的对应关系，它是语义范畴的概念，也就是说关系模式的属性之间是否存在函数依赖只与语义有关。5.1.2为什么要讨论函数依赖5.1.2为什么要讨论函数依赖教材第91页018/1405.1.2为什么要讨论函数依赖数据冗余数据更新数据插入数据删除5.1.2为什么要讨论函数依赖｜教材例5.15.1.2为什么要讨论函数依赖教材第91页019/140【例5.1】假设有关系模式食品（食品名，商家名，价格，食品类别号，类别描述）。如图5-1所示的具体食品关系，看一看在这个关系模式中存在一些什么问题。5.1.2为什么要讨论函数依赖｜教材图5-15.1.2为什么要讨论函数依赖教材第91页020/1405.1.2为什么要讨论函数依赖｜教材示例(1)5.1.2为什么要讨论函数依赖教材第91页021/140(1)数据冗余5.1.2为什么要讨论函数依赖｜教材示例(2)5.1.2为什么要讨论函数依赖教材第91页022/140在这个关系中由于相同食品可能在多个商家有售，所以相同的食品名和食品类别信息会在表中多次出现；类别描述也会因为食品名的重复而重复。5.1.2为什么要讨论函数依赖｜教材示例(2)5.1.2为什么要讨论函数依赖教材第91页023/140(2)数据更新5.1.2为什么要讨论函数依赖｜教材示例(3)5.1.2为什么要讨论函数依赖教材第91—92页024/140食品类别的描述变化，也需要更新多个地方。比如把第3条记录的类别描述“中式炒菜类”字段值改为“炒菜类”，而第4条记录的相应字段类别描述没有修改，这样就是同样的食品类别号出现了不同的类别描述，导致数据库中的数据不一致，不可信。5.1.2为什么要讨论函数依赖｜教材示例(3)5.1.2为什么要讨论函数依赖教材第91页025/140(3)数据插入5.1.2为什么要讨论函数依赖｜教材示例(4)5.1.2为什么要讨论函数依赖教材第91页026/140在这个关系中的关键字显然是(食品名，商家名)，当新增加一个商家时，但该商家暂未将食品上架，由于主属性食品名不存在，因此无法插入新的记录，因此不能存入新的商家的信息。5.1.2为什么要讨论函数依赖｜教材示例(4)5.1.2为什么要讨论函数依赖教材第91页027/140(4)数据删除5.1.2为什么要讨论函数依赖｜教材示例(5)5.1.2为什么要讨论函数依赖教材第91—92页028/140如果某个商家不再生产某种食品时，删除该商家的该条食品记录，假设该商家只生产了一种食品，就会同时删除了商家信息，而这一点可能并不是用户期望的。类似的种种问题都称之为操作异常。为什么会出现以上操作异常现象呢？因为这个关系模式没有设计好，在它的某些属性之间存在着“不良”的函数依赖。5.1.2为什么要讨论函数依赖｜教材示例(6)5.1.2为什么要讨论函数依赖教材第91—92页029/140如何改造这个关系模式，解决或避免以上种种问题，就是本章要讨论的主要内容，也是讨论函数依赖的根本原因。5.1.3函数依赖的分类5.1.3函数依赖的分类教材第92页030/1405.1.3函数依赖的分类平凡与非平凡函数依赖完全与部分函数依赖传递函数依赖5.1.3函数依赖的分类｜平凡函数依赖与非平凡函数依赖5.1.3函数依赖的分类教材第92页031/1401.平凡函数依赖与非平凡函数依赖5.1.3函数依赖的分类｜教材说明(1)5.1.3函数依赖的分类教材第92页032/140在关系模式R(U)中，X和Y是U的子集，即X⊆U，Y⊆U，如果X→Y，但Y⊄X，则称X→Y是非平凡函数依赖。若Y⊆X，则称X→Y为平凡函数依赖。5.1.3函数依赖的分类｜定义5.1.3函数依赖的分类教材第92页033/140教材定义函数依赖的分类的定义：对于任一关系模式，平凡函数依赖都是必然成立的，它不反映新的语义，因此若不特别声明，平常所指的函数依赖一般都是指非平凡函数依赖。5.1.3函数依赖的分类｜完全函数依赖与部分函数依赖5.1.3函数依赖的分类教材第92页034/1402.完全函数依赖与部分函数依赖5.1.3函数依赖的分类｜完全与部分函数依赖5.1.3函数依赖的分类教材第92页035/140教材定义完全函数依赖与部分函数依赖的定义：设X、Y是某关系的不同属性集，若X→Y，且不存在X′⊂X，使X′→Y，则称Y完全函数依赖于X，记作X—ᶠ→Y；否则称Y部分函数依赖于X，记作X—ᵖ→Y。5.1.3函数依赖的分类｜教材例5.25.1.3函数依赖的分类教材第92页036/140【例5.2】如图5-1所示的食品关系中，（食品名，商家名）是主键，则有如下函数依赖：（食品名，商家名）—ᶠ→价格（食品名，商家名）—ᵖ→食品类别号（食品名，商家名）—ᵖ→类别描述5.1.3函数依赖的分类｜传递函数依赖5.1.3函数依赖的分类教材第92页037/1405.1.3函数依赖的分类｜传递函数依赖传递函数依赖的定义教材例5.35.1.3函数依赖的分类｜传递函数依赖的定义5.1.3函数依赖的分类教材第92页038/140教材定义传递函数依赖的定义：设X、Y、Z是某关系的不同属性集，如果X→Y，Y↛X，Y→Z，则称Z对X传递函数依赖（TransitiveFunctionalDependency）。5.1.3函数依赖的分类｜教材例5.35.1.3函数依赖的分类教材第92页039/140【例5.3】图5-1所示的食品关系中，食品名→食品类别号，食品类别号↛食品名，食品类别号→类别描述，则属性类别描述传递依赖于食品名。5.1.4函数依赖的基本性质5.1.4函数依赖的基本性质教材第92页040/1405.1.4函数依赖的基本性质Armstrong公理系统三条基本推理规则三条导出规则5.1.4函数依赖的基本性质｜Armstrong公理5.1.4函数依赖的基本性质教材第92页041/1401974年W·W·Armstrong提出了一套有效而完备的公理系统——Armstrong公理，该公理后来成为关系模式分解的算法基础。5.1.4函数依赖的基本性质｜公理系统5.1.4函数依赖的基本性质教材第92页042/1405.1.4函数依赖的基本性质｜公理系统适用对象：关系模式R<U，F>5.1.4函数依赖的基本性质｜推理规则的对象5.1.4函数依赖的基本性质教材第92页043/140设关系模式R具有属性集合U和函数依赖集合F。对于R<U，F>来说，有以下三条推理规则：5.1.4函数依赖的基本性质｜Armstrong公理（1/2）5.1.4函数依赖的基本性质教材第92—93页044/140①自反律：若Y⊆X⊆U，则F蕴含X→Y（X→Y是平凡依赖，与F无关）。②增广律：若F蕴含X→Y，Z⊆U，则F蕴含XZ→YZ。5.1.4函数依赖的基本性质｜Armstrong公理（2/2）5.1.4函数依赖的基本性质教材第92—93页045/140③传递律：若F蕴含X→Y，Y→Z，则F蕴含X→Z。5.1.4函数依赖的基本性质｜公理的推理5.1.4函数依赖的基本性质教材第92—93页046/140根据Armstrong公理（以下简称A规则）可以得到下面三条很有用的推理规则：5.1.4函数依赖的基本性质｜导出规则（1/2）5.1.4函数依赖的基本性质教材第92页047/140①合并规则：若X→Y，X→Z，则X→YZ。②伪传递规则：若X→Y，YW→Z，则XW→Z。5.1.4函数依赖的基本性质｜导出规则（2/2）5.1.4函数依赖的基本性质教材第92页048/140③分解规则：若X→Y，Z⊆Y，则X→Z。5.1.5主码和外部码5.1.5主码和外部码教材第93页049/1405.1.5主码和外部码候选码与主码主属性与非主属性单码与全码外部码5.1.5主码和外部码｜候选码的定义5.1.5主码和外部码教材第93页050/140教材定义候选码的定义：设K是关系模式R(U)中的属性或属性组，K′是K的任一真子集。若K→U，而不存在K′→U，则K为R的候选码（CandidateKey）。5.1.5主码和外部码｜主码与属性的定义5.1.5主码和外部码教材第93页051/140教材定义主码、主属性与非主属性的定义：若候选码多于一个，则选其中的一个为主码(PrimaryKey)。包含在任一候选码中的属性，叫做主属性(PrimaryAttribute)。不包含在任何码中的属性称为非主属性(NonprimaryAttribute)或非码属性(Non-keyAttribute)。5.1.5主码和外部码｜单码与全码的定义5.1.5主码和外部码教材第93页052/140教材定义单码与全码的定义：关系模式中，最简单的情况是单个属性是码，称为单码(SingleKey)。最极端的情况是整个属性组是码，称为全码(All-Key)。5.1.5主码和外部码｜教材全码示例5.1.5主码和外部码教材第93页053/140关系模式授课（工号，课程编号，书号），属性工号表示教师，课程编号表示课程，书号表示参考书。一个教师可以讲授多门课程，每门课程又可以使用多本参考书；参考书也可以被多个教师的不同课程使用。这个关系模式的码为（工号，课程编号，书号），即All-key。5.1.5主码和外部码｜外部码的定义5.1.5主码和外部码教材第93页054/140教材定义外部码的定义：设有两个关系R和S，X是R的属性或属性组，并且X不是R的码，但X是S的码（或与S的码意义相同），则称X是R的外部码（ForeignKey），简称外码或外键。5.1.5主码和外部码｜教材说明(4)5.1.5主码和外部码教材第93页055/140如：教师(工号，姓名，性别，职称，系部编号)系部(系部编号，系部名称，主任，人数)5.1.5主码和外部码｜教材说明(5)5.1.5主码和外部码教材第93页056/140其中系部关系中的“系部编号“就是教师关系的一个外码。需要注意，在定义中说X不是R的码，并不是说X不是R的主属性，X不是码，但可以是码的组成属性，或者是任一候选码中的一个主属性。5.1.5主码和外部码｜教材说明(6)5.1.5主码和外部码教材第93页057/140如：学生(学号，姓名，性别，出生日期)课程(课程编号，课程名称，课程性质，总学时，学分)5.1.5主码和外部码｜教材说明(7)5.1.5主码和外部码教材第93页058/140选修(学号，课程编号，成绩)在选修关系中，(学号，课程编号)是该关系的码，学号、课程编号又分别是组成主码的属性(但单独不是码)，它们分别是学生关系和课程关系的主码，所以是选修关系的两个外部码。5.1.5主码和外部码｜教材说明(8)5.1.5主码和外部码教材第93页059/140关系间的联系可以通过同时存在于两个或多个关系中的主码和外部码的取值来建立。如要查询某个教师所在部门的情况，只需查询系部表中的系部编号与该教师系部编号相同的记录即可。所以，主码和外码提供了一个两个关系表互相联系的途径。5.2范式5.2范式教材第95页060/1405.2范式5.2.1第一范式(1NF)5.2.2第二范式(2NF)5.2.3第三范式(3NF)5.2.4BCNF与更高范式5.2范式｜教材说明(1)5.2范式教材第94页061/140范式(NormalForms,NF)的概念是由E.F.codd在1971年提出的，对关系模式的规范化，就是要使它满足不同级别的范式，目的是要设计“好的”关系模式。他在1971年~1972年提出了第一范式(1NF)、第二范式(2NF)与第三范式(3NF)。1974年codd和Boyce又共同提出了BCNF。5.2范式｜各范式之间的关系5.2范式教材第94页062/1401976年Fagin提出了4NF，后来又有人提出了5NF。各范式之间的关系如图5-2所示。1NF⊃2NF⊃3NF⊃BCNF⊃4NF⊃5NF5.2范式｜教材图5-25.2范式教材第93—94页063/1405.2范式｜规范化的定义5.2范式教材第94页064/140教材定义规范化的定义：通过模式分解把属于低级范式的关系模式转换为几个属于高级范式的关系模式的集合，这一过程称为规范化(Normalization)。范式越高，规范化的程度越高，则关系模式越好。通常把某一关系R为第n范式，简记为R∈nNF。5.2.1第一范式(1NF)5.2.1第一范式(1NF)教材第94页065/1405.2.1第一范式(1NF)第一范式的定义原子属性教材图5-3与图5-45.2.1第一范式(1NF)｜第一范式的定义5.2.1第一范式(1NF)教材第94页066/140教材定义第一范式（1NF）的定义：对于关系模式R的任一关系r，若其每一属性值都是基本属性（或原子属性），则称R为满足第一范式的关系，记作R∈1NF。5.2.1第一范式(1NF)｜基本要求5.2.1第一范式(1NF)教材第94页067/140第一范式是关系模式必须满足的最低要求，不满足第一范式的数据库模式不能称为关系数据库模式。每一列必须是原子的，不能分成多个子列；每一行和列的位置只能有一个值，不能具有多值列。5.2.1第一范式(1NF)｜教材图示说明5.2.1第一范式(1NF)教材第94页068/140图5-3所示的表格不是规范化关系，因为“高级职称人数”不是基本数据项，它由另外两个基本数据项组成。非规范化关系转换为规范化关系时，需要将所有数据项表示为不可分的最小数据项。图5-4所示表格就是图5-3规范化后的1NF关系。图5-3非规范化表格5.2.1第一范式(1NF)教材第95页069/140图5-3非规范化表格图5-4规范化表格5.2.1第一范式(1NF)教材第95页070/140图5-4规范化表格5.2.2第二范式(2NF)5.2.2第二范式(2NF)教材第95页071/1405.2.2第二范式(2NF)第二范式的定义完全函数依赖食品关系的模式分解5.2.2第二范式(2NF)｜第二范式的定义5.2.2第二范式(2NF)教材第95页072/140教材定义第二范式（2NF）的定义：若关系模式R属于第一范式，且每个非主属性都完全函数依赖于主键，则R属于第二范式，记作R∈2NF。5.2.2第二范式(2NF)｜教材说明(1)5.2.2第二范式(2NF)教材第95页073/140推论：如果关系模式R∈1NF，且它的每一个候选码都是单码，则R∈2NF。5.2.2第二范式(2NF)｜教材例5.15.2.2第二范式(2NF)教材第95页074/140【例5.1】对于5.1给出的食品关系，主键为(食品名，商家名)。非主属性“价格”完全依赖于关键字，但非主属性“食品类别号”和“类别描述”却部分依赖于关键字，既有“食品名→食品类别号”，“食品名→类别描述”，因此食品关系不属于2NF。那么再这样的关系中存在哪些问题呢？5.2.2第二范式(2NF)｜教材示例(2)5.2.2第二范式(2NF)教材第95页075/140那些在5.2中列出的各种操作异常问题都有可能出现，读者可以自行分析。这些操作异常均是由该关系模式中存在的部分函数依赖导致的。为了解决这些操作异常问题就要消除这种部分函数依赖，将图5-1所示的关系中将食品关系分解为如下两个关系模式：5.2.2第二范式(2NF)｜教材示例(3)5.2.2第二范式(2NF)教材第95页076/140售卖信息(商家名，食品名，价格)5.2.2第二范式(2NF)｜教材示例(4)5.2.2第二范式(2NF)教材第95页077/140食品信息(食品名，食品类别号，类别描述)5.2.2第二范式(2NF)｜教材示例(5)5.2.2第二范式(2NF)教材第95页078/140由于分解后消除了原关系模式中的部分函数依赖，这样的两个关系模式均满足2NF的要求，以前可能导致的各种异常操作得到了部分的解决。对于上述分解后的食品信息，仍然会有相同的“食品类别号”重复存储了“类别描述”。这样的重复存储同时也会带来更新复杂的问题。5.2.2第二范式(2NF)｜教材示例(6)5.2.2第二范式(2NF)教材第95页079/140由此可以看出，满足第二范式的关系模式仍然可能出现异常操作。这是因为第二范式只要求每个非主属性完全依赖于主键，并未限定非主属性不能函数依赖于其他非主属性，从而也就允许传递依赖的存在。因此，还需要对满足第二范式的关系模式进一步判断与分解。5.2.3第三范式(3NF)5.2.3第三范式(3NF)教材第95页080/1405.2.3第三范式(3NF)第三范式的定义传递函数依赖食品信息的模式分解5.2.3第三范式(3NF)｜第三范式的定义5.2.3第三范式(3NF)教材第95页081/140教材定义第三范式（3NF）的定义：若关系模式R属于第二范式，且每个非主属性都不传递依赖于主键，则R属于第三范式，记作R∈3NF。5.2.3第三范式(3NF)｜教材说明(1)5.2.3第三范式(3NF)教材第95页082/140推论1如果关系模式R∈1NF，且它的每一个非主属性既不部分依赖、也不传递依赖于任何候选码，则R∈3NF。推论2不存在非主属性的关系模式一定为3NF。5.2.3第三范式(3NF)｜教材例5.25.2.3第三范式(3NF)教材第95页083/140【例5.2】分解例5.1中的关系食品信息(食品名，食品类别号，类别描述)，使其满足3NF的要求。5.2.3第三范式(3NF)｜教材示例(2)5.2.3第三范式(3NF)教材第95页084/140解：在食品信息中，食品名→食品类别号，食品类别号↛食品名，食品类别号→类别描述，因此非主属性“类别描述”传递依赖于码“食品名”。正是由于这种传递依赖，导致关系模式中仍存在数据冗余、更新复杂等问题，因此将它进一步分解为以下两个关系模式。5.2.3第三范式(3NF)｜教材示例(3)5.2.3第三范式(3NF)教材第95页085/140食品关系(食品名，食品类别号)5.2.3第三范式(3NF)｜教材示例(4)5.2.3第三范式(3NF)教材第95页086/140食品类别(食品类别号，类别描述)5.2.3第三范式(3NF)｜教材示例(5)5.2.3第三范式(3NF)教材第95—96页087/140分解后的两个关系模式消除了传递依赖，这两个关系模式都满足3NF，且解决了数据冗余和更新复杂的问题。当按第三范式的要求把所有传递依赖都消除时，同时也能消除部分依赖。即若关系模式R属于第三范式，则每个非主属性对于主键既不存在部分依赖，也不存在传递依赖。5.2.3第三范式(3NF)｜教材示例(6)5.2.3第三范式(3NF)教材第95—96页088/140把关系模式分解到第三范式，可以在相当程度上减轻原关系中的异常和信息冗余，但不能保证完全消除关系模式中的各种异常和信息冗余。5.2.4BCNF与更高范式5.2.4BCNF与更高范式教材第96页089/1405.2.4BCNF与更高范式BCNF多值依赖第四范式(4NF)第五范式(5NF)5.2.4BCNF与更高范式｜BCNF的定义5.2.4BCNF与更高范式教材第96页090/140教材定义Boyce-Codd范式（BCNF）的定义：设有关系模式R∈1NF，F是R的函数依赖集，若F中的每个非平凡函数依赖X→Y（Y⊄X），X都含有主键，则称R是Boyce-Codd范式，记作R∈BCNF。5.2.4BCNF与更高范式｜BCNF的三个性质5.2.4BCNF与更高范式教材第96页091/140①R中所有非主属性对每一个码都是完全函数依赖。②R中所有主属性对每一个不包含它的码，都是完全函数依赖。③R中没有任何属性完全函数依赖于非码的任何一组属性。5.2.4BCNF与更高范式｜教材例5.35.2.4BCNF与更高范式教材第96页092/140【例5.3】若有Teaching（Student，Teacher，Course）关系模式，简记为Teaching（S，T，C）。规定一个教师只能教一门课，每门课程可由多个教师讲授；学生一旦选定某门课程，教师就相应地固定。判断其是否满足BCNF范式；若不满足，分解关系模式使之满足BCNF范式。5.2.4BCNF与更高范式｜教材示例(2)5.2.4BCNF与更高范式教材第96页093/140解：F＝｛T→C，(S，C)→T，(S，T)→C｝该关系的候选码是(S，C)和(S，T)，因此，三个属性都是主属性，由于不存在非主属性，该关系一定是3NF。但由于决定因素T没包含码，故它不是BCNF。5.2.4BCNF与更高范式｜教材示例(3)5.2.4BCNF与更高范式教材第96页094/140关系模式Teaching仍然存在着数据冗余问题，因为存在着主属性对码的部分函数依赖问题。Teaching关系可以分解为以下两个BCNF关系模式：Teacher(Teacher，Course)5.2.4BCNF与更高范式｜教材示例(4)5.2.4BCNF与更高范式教材第96页095/140Student(Student，Teacher)3NF的“不彻底“性表现在可能存在主属性对码的部分依赖和传递依赖。一个关系模式如果达到了BCNF，那么，在函数依赖范围内，它就已经实现了彻底的分离，消除了数据冗余、插入和删除异常。5.2.4BCNF与更高范式｜教材示例(4)5.2.4BCNF与更高范式教材第96页096/1402.多值依赖与4NF(1)问题的提出5.2.4BCNF与更高范式｜教材示例(5)5.2.4BCNF与更高范式教材第96页097/140前面所讨论的情况属于函数依赖范畴，即当属性子集X取定一个值时，属性子集Y有唯一的一个值与之对应，有点类似于数学中的单值函数。但在某些应用领域中，关系模式的属性之间出现“组对应“的情况，即当属性子集X取定一个值时，属性子集Y有一组值与之对应，有点类似于数学中的多值函数。此时的数据依赖属于下面讨论的多值依赖范畴。5.2.4BCNF与更高范式｜教材表5.2.4BCNF与更高范式教材第96页098/140仓库雇员物资康乐陈大马达康乐陈大水泵康乐赵二马达康乐赵二水泵天河张三种子5.2.4BCNF与更高范式｜教材表(续)5.2.4BCNF与更高范式教材第96页099/140仓库雇员物资天河张三农药唐湾李四饲料唐湾王五饲料新造马六化肥5.2.4BCNF与更高范式｜多值依赖的定义5.2.4BCNF与更高范式教材第96—97页100/140教材定义多值依赖的定义：设R是关系模式，U是其属性集合。X、Y是U的子集，Z=U-X-Y。若对R任一实例r，r在（X，Z）上每个值对应一组Y值，这种对应关系与Z无关，则称X多值确定Y，或称Y多值依赖于X，记作X→→Y。若Z为空集，称X→→Y为平凡的多值依赖，否则称为非平凡的多值依赖。5.2.4BCNF与更高范式｜第四范式的定义5.2.4BCNF与更高范式教材第98页101/140教材定义第四范式（4NF）的定义：若关系模式R每个非平凡多值依赖X→→Y（Y⊄X），X都含有候选键，则R满足第四范式，简记为R∈4NF。5.2.4BCNF与更高范式｜教材示例(25)5.2.4BCNF与更高范式教材第98页102/140存在连接关系依赖的关系模式可能也会存在数据冗余以及数据插入、修改、删除异常的问题，因此需在满足4NF的关系模式上消除连接依赖，从而达到5NF的关系模式。本书不讨论连接依赖和5NF，有兴趣的读者参阅其他书籍。5.3关系模式的规范化5.3关系模式的规范化教材第98—99页103/1405.3关系模式的规范化5.3.1关系模式的分解5.3.2关系模式的规范化及反规范化5.3关系模式的规范化｜教材说明(1)5.3关系模式的规范化教材第98页104/140关系模式的规范化过程是通过对关系模式的分解来实现的。把低一级的关系模式分解为若干个高一级的关系模式。这种分解不是唯一的。各范式之间的关系如下：5.3关系模式的规范化｜教材说明(2)5.3关系模式的规范化教材第98页105/1401NF：每个分量是不可分的数据项。消除非主属性对码的部分函数依赖5.3关系模式的规范化｜教材说明(3)5.3关系模式的规范化教材第98—99页106/1402NF：非主属性完全函数依赖于码。消除非主属性对码的传递函数依赖5.3关系模式的规范化｜教材说明(4)5.3关系模式的规范化教材第99页107/1403NF：非主属性既不部分依赖于码也不传递依赖于码。消除主属性对码的部分和传递函数依赖5.3关系模式的规范化｜教材说明(5)5.3关系模式的规范化教材第98—99页108/140BCNF：所有属性都不部分依赖于码也不传递依赖于码。消除非平凡且非函数依赖的多值依赖5.3关系模式的规范化｜教材说明(6)5.3关系模式的规范化教材第98—99页109/1404NF：所有非平凡的多值依赖都是函数依赖。消除不由候选码所蕴含的连接依赖5.3关系模式的规范化｜教材说明(7)5.3关系模式的规范化教材第98页110/1405NF5.3.1关系模式的分解5.3.1关系模式的分解教材第99页111/1405.3.1关系模式的分解关系模式分解无损连接性函数依赖保持性教材例5.55.3.1关系模式的分解｜关系模式分解的定义5.3.1关系模式的分解教材第99页112/140教材定义关系模式分解的定义：把一个关系模式分解成若干个关系模式的过程，称为关系模式的分解。规范化过程中将一个关系模式分解为若干个关系模式，应该保证分解后产生的模式和原来的模式等价。常用的等价标准有要求：5.3.1关系模式的分解｜无损连接性的定义5.3.1关系模式的分解教材第99页113/140教材定义无损连接性的定义：设关系模式R(U，F)分解为关系模式R₁(U₁，F₁)，R₂(U₂，F₂)，…，Rₙ(Uₙ，Fₙ)，其中U=U₁∪U₂∪…∪Uₙ，且不存在Uᵢ⊆Uⱼ，Fᵢ为F在Uᵢ上的投影，如果R与自然连接的结果相等，则称关系模式R的分解具有无损连接性。5.3.1关系模式的分解｜函数依赖保持性的定义5.3.1关系模式的分解教材第99页114/140教材定义函数依赖保持性的定义：设关系模式R(U，F)分解为关系模式R₁(U₁，F₁)，R₂(U₂，F₂)，…，Rₙ(Uₙ，Fₙ)，其中U=U₁∪U₂∪…∪Uₙ，且不存在Uᵢ⊆Uⱼ，Fᵢ为F在Uᵢ上的投影，如果F所蕴含的函数依赖一定也由分解得到的某个关系模式中的函数依赖Fᵢ所蕴含，则称关系模式R的分解具有函数依赖保持性。5.3.1关系模式的分解｜教材例5.55.3.1关系模式的分解教材第99—100页115/140【例5.5】设关系模式S-C-I(studentNo,classNo,instituteNo)，如表5-2所示，分解该关系模式。5.3.1关系模式的分解｜教材表5.3.1关系模式的分解教材第100—101页116/140studentNoclassNoinstituteNo1214310131141214320232141221110311211221110411215.3.1关系模式的分解｜教材示例(2)5.3.1关系模式的分解教材第99—101页117/140解：(1)分解方案一：将关系模式S-C-I分解为：S-C-I11(studentNo,classNo)和S-C-I12(classNo,classNo)，则将S-C-I投影到S-C-I11和S-C-I12的属性上，得到如表5-3和5-4。5.3.1关系模式的分解｜教材表5.3.1关系模式的分解教材第100—101页118/140studentNoinstituteNo12143101141214320214122111032112211104215.3.1关系模式的分解｜教材表5.3.1关系模式的分解教材第99—100页119/140classNoinstituteNo3114321411215.3.1关系模式的分解｜教材表5.3.1关系模式的分解教材第100—101页120/140studentNoclassNoinstituteNo1214310131141214320231141214310132141214320232141221110311215.3.1关系模式的分解｜教材表(续)5.3.1关系模式的分解教材第100—101页121/140studentNoclassNoinstituteNo1221110411215.3.1关系模式的分解｜教材表5.3.1关系模式的分解教材第100—101页122/140studentNoclassNo12143101311214320232122111031112211104115.3.1关系模式的分解｜教材表5.3.1关系模式的分解教材第100—101页123/140studentNoinstituteNo12143101141214320214122111032112211104215.3.1关系模式的分解｜教材示例(11)5.3.1关系模式的分解教材第101页124/140若要求分界保持函数依赖，那么模式分解可以达到3NF，但不一定能达到BCNF。若要求分解既具有无损连接性，又保持函数依赖，则模式分解可以达到3NF，但不一定能达到BCNF。5.3.2关系模式的规范化及反规范化5.3.2关系模式的规范化及反规范化教材第101页125/1405.3.2关系模式的规范化及反规范化规范化的作用反规范化的原因设计中的性能权衡5.3.2关系模式的规范化及反规范化｜教材说明(1)5.3.2关系模式的规范化及反规范化教材第101页126/140当一个表是规范化的，则其非主码列依赖于主码列。从关系模型的角度来看，表满足3NF最符合标准，这样的设计容易维护。一个完全规范化的设计并不总能生成最优的性能，因此通常是先按照3NF设计，如果有性能问题，再通过反规范化来解决。5.3.2关系模式的规范化及反规范化｜教材说明(2)5.3.2关系模式的规范化及反规范化教材第101