第2章-范式及其对数据库设计的指导意义.ppt

An Introduction to Database Systenm 第二章 范式及其对数据库设计的指导意义 计算机信息工程学院 范式及其对数据库设计的指导意义 问题的引出 范式理论概述 1NF及对实践的指导意义 数据依赖 2NF及对实践的指导意义 3NF及对实践的指导意义 BCNF-扩充的第三范式 范式应用实例分析 范式的局限 － 对冗余的进一步讨论 2.2 范式理论概述 1971年，由1970年首先提出“大型共享数据库数据的关系模型”的关系数据库之父 Edgar Frank Codd相继提出了三级规范化形式1NF-3NF 1974年，E.F.Codd和Boyce共同提出BCNF 1977 Ronald Fagin提出了第四范式 以后又相继提出了5NF（Project-Join Normal Form (PJ/NF)) 、DKFN（Domain/Key Normal Form）和6NF 范式FN 范式是符合某一种级别的关系模式的集合 某一关系模式R为第n范式，可简记为R∈nNF。 各范式之间关系 1NF?2NF ?3NF ?BCNF ?4NF ?5NF ?DKNF?6NF 规范化方法 一个属于低一级的范式的关系模式可以通过模式分解转换成属于高一级范式的关系模式，这个过程称为关系模式的规范化。 规范化目的：消除关系中的数据冗余。 异常的分类 不可避免异常：若数据库的设计中存在不可避免的异常时，需求将无法实现，设计者会自觉地消除这些异常。 可避免异常：关系规范化理论对设计者有指导意义的是消除可避免异常引起的数据冗余。 冗余和范式关系 一般消除了一个关系中的数据冗余（除外键引用为必要的数据冗余外），该关系也就符合了范式要求。 一个关系符合范式要求，一般就不会产生数据冗余，但必须注意的是范式可以消除一个关系中的（单行）数据冗余，但不能消除一个表的行间冗余和多个关系之间的数据冗余。 2.3 1NF及对实践的指导意义 第一范式是关系数据模式必须遵循的规范，其他规范均建立在此基础之上 关系的一切数学理论均基于关系模式服从1NF 是唯一没有严格定义的范式，容易被忽视和误解 若一个表中所有列是不可再分的数据项（原子项），就称这样的设计属于或服从第一范式 P19表2-4 1NF的另一种表述 若一个表中不包含任何重复的数据项，称这样的设计属于或服从第一范式。 所谓重复的数据项是指这些数据项具有相同性质并且数据项数量具有变化的预期。 定义中隐含了表中的一个列不能组合多个数据的要求。 不要把若干数据组合成一个字符串或组合列作为数据表的一个列。 2.4 数据依赖 是一个关系内部属性与属性之间的一种约束关系。 是现实世界属性间相互联系的抽象 是数据内在的性质 是语义的体现 数据依赖的类型 函数依赖（Functional Dependency，简记为FD） 多值依赖（Multivalued Dependency，简记为MVD） 其他 2NF 例:学生学科成绩的关系模型设计 （学号，姓名，学科号，学科名，成绩） 该关系就不符合第二范式。 （“学号”，“学科号”）为该关系的主键（码），非主属性中，除“成绩”完全依赖于主键，“姓名”和“学科名”不完全依赖于主键，即仅分别完全依赖于主键的子集“学号”和“学科号”。 要使其符合2NF，必须把上述关系分解成三个关系：学生(学号,姓名,…)、学科(学科号,学科名,…)和成绩(学号, 学科号, 成绩)。 2.8 范式应用实例分析 一个商场的商品分类: 商品分类 服装 男装 西装 休闲装 女装 套装 职业装 休闲装 童装 电器 进口 国产 日用品 关系模型设计： 代码（主码） 名称 01 服装 0101 男装 010101 西装 010102 休闲装 0102 女装 010201 套装 010202 职业装 010203 休闲装 0103 童装 02 电器 0201 进口 0202 国产 03 日用品 对上述关系模型的分析： 分析代码包含信息：“代码”属性不是原子项，它至少包含了下列两个信息（所以不符合1NF）： 本级代码 上级代码， 而上级代码又包含了上述两个信息。 1NF规范化：主要任务是把代码项分解为原子项： 思考一：把代码分解成本级代码和上级代码两项，由于上级代码仍包含本级代码和上级代码，所以不是原子项。这个思路不可行 思考二：由于“代码”实际包含了一个树结构信息，参考数据结构中方法，可以把代码分解成下列原子项： id： 流水号，主键 code： 本级代码 pi