第二章范式及其对数据库设计的 指导意义 范式理论及对实践指导意义概述。范式：1NF、2NF、3NF、BCNF、4NF、 5NF实例分析及1NF、3NF的认识误区l关系模型下的树结构表达l供应商和系名问题范式的局限对冗余的进一步讨论l单表行间冗余l多表间冗余2.1 范式理论及对实践指导意义概述1）范式理论形成：1971年，由1970年首先提出“大型共享数据 库数据的关系模型”的关系数据库之父 Edgar Frank Codd相继提出了三级规范化形式1NF -3NF1974年，E.F.Codd和Boyce共同提出BCNF1977 Ronald Fagin提出了第四范式 以后又相继提出了5NF（Project-Join Normal Form (PJ/NF) 、DKFN（ Domain/Key Normal Form）和6NF2）各范式之间关系：1NF2NF 3NF BCNF 4NF 5NF DKNF6NF 3）规范化方法：一个属于低一级的范式 的关系模式可以通过模式分解转换成属 于高一级范式的关系模式，这个过程称 为关系模式的规范化。4）规范化目的：消除关系中的数据冗余由于数据冗余引发的问题：浪费了存储资源，并且重复的数据占用的空 间随数据量的递增而递增。由于数据的重复，为保证数据的一致性，将 增加数据维护（插入、更新和删除）的代价 ，从而降低了系统的开发和运行效率各种意外还是可能造成重复数据的不一致， 从而降低了系统的稳定性和可靠性。是产生插入，更新和删除异常根源（见下例 ）插入，更新和删除异常实例：假设存在下列关系，包含学生和系的基本信息 ： 学号姓名所在系系主任 001zhang 数学Mr Li 002wang数学Mr Li 003zhou数学Mr Li 004feng计算机Mr chen 005dong计算机Mr chen 该关系存在插入，更新和删除异常。插入异常：当新成立一个系但还没有学 生时，产生插入异常。删除异常：当一个系的学生被全部删除 后，系信息也被删除。更新异常：当系名称或系主任发生变化 ，必须同时更新这个系所有学生记录， 若漏改一个，就产生更新异常。5）规范化理论对实践的指导意义异常分类：关系设计不规范引起插入，更新 和删除异常有的可以通过严密的算法避免发 生，有的则不能避免。在上例中，插入和删 除异常不可避免，而更新异常却可以避免。不可避免异常：若数据库的设计中存在不可 避免的异常时，需求将无法实现，设计者会 自觉地消除这些异常。在上例中，一般会增 加一个“系（系名，系主任）”关系来排除不 可避免的插入和删除异常。这时，规范化设 计成为设计师自觉的行动可避免异常：关系规范化理论对设计者 有指导意义的是消除可避免异常引起的 数据冗余。冗余和范式关系：l一般消除了一个关系中的数据冗余（除外 键引用为必要的数据冗余外），该关系也 就符合了范式要求。l一个关系符合范式要求，一般就不会产生 数据冗余，但必须注意的是范式可以消除 一个关系中的（单行）数据冗余，但不能 消除一个表的行间冗余和多个关系之间的 数据冗余。2.2 范式 2.2.11NF及对实践的指导意义 1）定义1NF的定义1：若关系中所有属性是不可再分的 基本项（原子项），即关系中的属性不能是组 合属性，称关系属于或服从第一范式。 1NF的定义2：关系模式R中不能含有任何重复 的数据项。（Robert D. Schnneider 规划与建 立高性能SQL Server 6.5数据库）第一范式是关系数据模式必须遵循的规范，其 他规范均建立在此基础之上。关系的一切数学理论均基于关系模式服从1NF 。如一个学生的成绩包括数学，语文，外 语等，则成绩不能作为学生关系中的一 个属性。要使其符合1NF,必须把数学，语文，外 语成绩直接作为学生关系的属性。由于关系数据库中表中列之间的关系相 互并列,本身不支持层次结构或数组,所 以表面上看,只要是二维表,就一定符合 1NF 2）1NF的第一层次的解释3）1NF的第二层次的解释不要或没有必要把若干属性或代码组合成一 个组合属性或组合代码放在一个数据列中。 这同样违反1NF 。这样做的风险是数据库系统对组合属性中某 属性的可操作性(子串)一定不如对列的可操 作性。解决上述问题的方法也不要简单地把组合属 性分解成列,当这些属性有扩充的可能时,应 单独建立一个关系。（后面有详例分析）4）1NF的第三层次的解释1NF要求在一行中不能有重复组，不管是重复的列还 是列中含有的重复信息都不允许。(数据库设计)如不要把数学成绩，语文成绩和外语成绩作为学生 关系中的属性，因为，一旦增加一门课程，该关系 就必须作修改。正确的做法是把成绩独立出来，形成的关系模型为 ：成绩（学号，学科号，成绩）类似的如在学生关系中有联系电话属性，而每一个 学生可能有不确定的电话数量，则增加属性“电话1” 、“电话2”，同样不符合1NF要求，正确的做法是 增加关系：R(学号，电话号码)2.2.22NF及对实践的指导意义关系属于第一范式并且每一个非主属性 完全依赖于码，则称关系属于第二范式 。由于非主属性均函数依赖于码，所以第 二范式去除了非主属性对码的部分依赖 。假设(x,y)为关系R(U)的码，有非主属性z， yz，由于y不包含码，所以关系的行中y值必 有重复， yz，z值与y值同步重复。一般可以把R(U)分解成R1(U-z)和R2(y,z)， 使子关系均属于2NF，同时消除了冗余。单据号 单据日期品号 品名 数量 b0012003-2-1G01 A10 b0012003-2-1G02 B12 b0022004-2-7G02 B20单据号，品号为关系的主码，“单据日期”为非主属 性，“单据号”“单据日期”，即非主属性“单据日期” 部分依赖于码,这种设计的数据冗余显而易见。把关系分解为：单据摘要（单据号*、单据日期）和 单据明细（单据号*，品号*，品名，数量），通过单 据号建立关联。例.单据的单表设计就不属于第2范式思考练习:分别完成单据的两种设计下的下列操作 的设计，并进行比较：l单据明细的增加，删除和修改l单据的增加和删除。l空白单据的处理若把学生学科成绩设计成（学号，姓名，学 科号，学科名，成绩），该关系就不符合第 二范式。（“学号”，“学科号”）为该关系的主 键（码），非主属性中，除“成绩”完全依赖 于主键，“姓名”和“学科名”不完全依赖于主键 ，即仅分别完全依赖于主键的子集“学号”和“ 学科号”。 要使其符合2NF，必须把上述关系分解成三 个关系：学生(学号,姓名,)、学科(学科号, 学科名,)和成绩(学号, 学科号, 成绩)。例.学生学科成绩的关系模型设计2.2.33NF及对实践的指导意义关系属于第一范式且关系中不存在非主属性Z传递函 数依赖于码，则称关系属于第三范式。在传递函数依赖XYZ的定义中隐含YX和ZY， 但3NF定义中的传递函数依赖允许YX （或YX）, 由此才能保证2NF 3NF。假如不放宽传递函数依赖条件，则关系：学生选课（ 学号，课程号，课程名）不符合2NF但符合3NF，因 为我们找不到属性组Y，使唯一的非主属性“课程名” 传递函数依赖于码(学号,课程号)，即(学号,课程号) Y课程名。而定义条件放宽后，可取Y=“课程号” 。第三范式是在关系中去除非主属性对码的传递函数依 赖。不属于3NF必然存在冗余X，Y，Z为关系R(U)的属性组，且X为 码， XYZ，由于Y+X，所以Y必 不包含码，在关系的行中Y值必有重复 ，而YZ，所以Z值同步重复。一般可以把R(U)分解成R1(U-Z)和 R2(Y,Z)，使子关系均属于3NF，同时 消除了冗余。如在学生关系中增加所在“系”和“系主任”属性 ，则该关系就不符合第三范式，因为由依赖关 系“学号系系主任”，中间就存在了传递函 数依赖，学号系主任。 学号姓名系系主任 001wang数学Li 002Feng数学Li 003Cheng数学Li 004Huang物理Xu 显然这种设计存在数据冗余正确的做法是在学生关系中增加“系编号”属 性，同时增加一个关系：系（系编号，系名 ，系主任） 。 学号姓名 系号系号 系系主任 001wang 0101数学 Li 002Feng 0102物理 Xu 003Cheng 01 004Huang 02单据中包含商品代码外,还包括商品属性,同样 不符合第三范式,因为存在下列传递函数依赖 :(单据号,单据明细序号)商品代码商品属 性。2.2.4BCNF-扩充的第三范式关系模式R(U,F)1NF,若XY (YX),X必包 含码,则R(U,F) BCNF。BCNF是在3NF基础上去除主属性对码的部分 和传递依赖。 X，Y为关系R(U)的属性组， XY，且X不 包含码，在关系的行中X值必有重复，而 XY，所以Y值同步重复。一般可以把R(U)分解成R1(U-Y)和R2(X,Y) ，使子关系均属于BCNF，同时消除了冗余 。属于3NF但不属于BCNF的例：学生选课（学号，课程号，教师编号，成绩 ），假设一个教师只上一门课。则：教师编 号课程号，但教师编号不是关系的码，所 以此关系不属于BCNF。 学号课程号教师编号成绩 001数据库Li89 001C语言Zhang76 002数据库Li99 003数据库Li87 显然这种设计存在数据冗余(学号，课程号)和(学号，教师编号)均为关系 的码，所以学号、课程号和教师编号为主属 性，成绩为非主属性，显然，成绩不传递函 数依赖于上述两个码，所以关系属于3NF。 把上述关系分解成：学生选课（学号，教师 ，成绩）和教师任课（教师，课程）关系就 符合BCNF。学号教师成绩 教师 课程 001Li89 Li 数 据库 001Zhang76 Zhang C 语言 002Li99 003Li87思考和练习:是否可以分解成：学生选课（学号，课 程，成绩）和教师任课（教师，课程） ？说明原因。2.2.7 各范式关系小结1NF基础上去除非主属性对码的部分依赖成为2NF2NF基础上去除非主属性对码的传递依赖成为3NF3NF基础上去除主属性对码的部分和传递依赖成为 BCNFBCNF基础上去除非平凡和非函数依赖的多值依赖成 为4NF4NF基础上去除不是由侯选码蕴涵的连接依赖成为 5NF5NF4NF BCNF 3NF 2NF 1NF低一级模式可以通过模式分解转换为高一级模式一个商场的商品分类: 商品分类 服装 男装 西装 休闲装 女装 套装 职业装 休闲装 童装 电器 进口 国产 日用品2.3 实例分析： 2.3.1 正确理解1NF-树结点的数据表设计：代码（主码）名称 01服装 0101男装 010101西装 010102休闲装 0102女装 010201套装 010202职业装 010203休闲装 0103童装 02电器 0201进口 0202国产 03日用品关系模型设计：冗余分析：在上述设计中增加“上级代码”、“代码级 数”、“是否为叶结点”等列，显然，这些 列的数据为冗余数据，因为这些数据值 完全可以由“代码”计算得到。这些列并不传递或部分依赖于码似乎产生了一种既有数据冗余但又符合 所有范式的模式分析代码包含信息：“代码”属性不是原子项，它至少 包含了下列两个信息（所以不符合1NF）：l本级代码l上级代码， 而上级代码又包含了上述两个信息。1NF规范化：主要任务是把代码项分解为原子项：l思考一：把代码分解成本级代码和上级代码两项，由于上 级代码仍包含本级代码和上级代码，所以不是原子项。这 个思路不可行l思考二：由于“代码”实际包含了一个树结构信息，参考数据 结构中方法，可以把代码分解成下列原子项： id：流水号，主键 code