3、范式及其对数据库设计的指导意义

可避免异常：关系规范化理论对设计者 有指导意义的是消除可避免异常引起的 数据冗余。 冗余和范式关系：
一般消除了一个关系中的数据冗余（除外键
引用为必要的数据冗余外），该关系也就符 合了范式要求。 一个关系符合范式要求，一般就不会产生数 据冗余，但必须注意的是范式可以消除一个 关系中的（单行）数据冗余，但不能消除一 个表的行间冗余和多个关系之间的数据冗余。
对上述关系模型的分析：

分析代码包含信息：“代码”属性不是原子项，它至 少包含了下列两个信息（所以不符合1NF）：
本级代码 上级代码， 而上级代码又包含了上述两个信息。


1NF规范化：主要任务是把代码项分解为原子项：


思考一：把代码分解成本级代码和上级代码两项，由于上级 代码仍包含本级代码和上级代码，所以不是原子项。这个思 路不可行 思考二：由于“代码”实际包含了一个树结构信息，参考数 据结构中方法，可以把代码分解成下列原子项： id： 流水号，主键 code： 本级代码 pid： 父结点id
品号 G01 G02 G02
品名 A B B
数量 10 12 20

{单据号，品号}为关系的主码，“单据日期”为非主属 性，“单据号”“单据日期”，即非主属性“单据 日期”部分依赖于码,这种设计的数据冗余显而易见。 把关系分解为：单据摘要（单据号*、单据日期）和单 据明细（单据号*，品号*，品名，数量），通过单据 号建立关联。
2）各范式之间关系：1NF2NF 3NF BCNF 4NF 5NF DKNF6NF 3）规范化方法：一个属于低一级的范式的 关系模式可以通过模式分解转换成属于 高一级范式的关系模式，这个过程称为 关系模式的规范化。
4）规范化目的：消除关系中的数据冗余
由于数据冗余引发的问题： 浪费了存储资源，并且重复的数据占用的空间 随数据量的递增而递增。 由于数据的重复，为保证数据的一致性，将增 加数据维护（插入、更新和删除）的代价，从 而降低了系统的开发和运行效率 各种意外还是可能造成重复数据的不一致，从 而降低了系统的稳定性和可靠性。 是产生插入，更新和删除异常根源（见下例）
code
01 0101 010101 010102 0102 010201 010202 010203 0103 02 0201 0202 03

name
服装 男装 西装 休闲装 女装 套装 职业装 休闲装 童装 电器 进口 国产 日用品

id
0 1 2 3 4 5 6 7 8 9 10 11 12 13



插入异常：当新成立一个系但还没有学 生时，产生插入异常。 删除异常：当一个系的学生被全部删除 后，系信息也被删除。 更新异常：当系名称或系主任发生变化， 必须同时更新这个系所有学生记录，若 漏改一个，就产生更新异常。
5）规范化理论对实践的指导意义


异常分类：关系设计不规范引起插入，更新和 删除异常有的可以通过严密的算法避免发生， 有的则不能避免。在上例中，插入和删除异常 不可避免，而更新异常却可以避免。 不可避免异常：若数据库的设计中存在不可避 免的异常时，需求将无法实现，设计者会自觉 地消除这些异常。在上例中，一般会增加一个 “系（系名，系主任）”关系来排除不可避免 的插入和删除异常。这时，规范化设计成为设 计师自觉的行动
一）冗余



每一个结点只需要知道其父结点代码，就可以 构建一棵树，而根据第一种设计，其每一个结 点均包含了其所有祖先的结点代码，这就是冗 余的信息。 设计一冗余的信息被隐藏在一个列中，并且随 树结构层数的增加而增加 设计二没有冗余
二）扩展能力及空间利用率


第一种设计表示的树结点的层数受code列长度的限制，而第 二种设计则没有这种限制。 为了能适应结点层数的扩展，第一种设计不得不加大code列 的长度，由于code列为主码，从效率角度考虑，通常其数据 类型会首先考虑使用char型，所以在实际的代码后会存在大 量的空格。 在每一级代码长度不一样的情况下，第二种设计的code列同 样会产生少量的空格，但由于code列不是主码，可以把其类 型定义为varchar解决这个问题。
2.2.3

3NF及对实践的指导意义
关系属于第一范式且关系中不存在非主属性Z传递函数 依赖于码，则称关系属于第三范式。

如在学生关系中增加所在“系”和“系主任” 属性，则该关系就不符合第三范式，因为由依 赖关系“学号系系主任”，中间就存在了 传递函数依赖，学号系主任。 学号 姓名 系 系主任 001 wang 数学 Li 002 Feng 数学 Li 003 Cheng 数学 Li 004 Huang 物理 Xu 显然这种设计存在数据冗余
两种设计的比较：范式的意义


两种设计的可行性：原始设计中关系虽 然不符合1NF，但此设计中代码包含了分 类树的所有结构信息，所以设计方案是 可行的。规范后的设计通过pid建立结点 的父子关系同样包含了树的所有结构信 息，所以也是可行的。 比较方法：从冗余、扩展能力及空间利 用率、结点引用和各种算法四个方面进 行比较
2.2 范式 2.2.1 1NF及对实践的指导意义 1）定义



1NF的定义1：若关系中所有属性是不可再分的 基本项（原子项），即关系中的属性不能是组合 属性，称关系属于或服从第一范式。 1NF的定义2：关系模式R中不能含有任何重复的 数据项。（Robert D. Schnneider 规划与建立高 性能SQL Server 6.5数据库） 第一范式是关系数据模式必须遵循的规范，其他 规范均建立在此基础之上。 关系的一切数学理论均基于关系模式服从1NF。
4）1NF的第三层次的解释




1NF要求在一行中不能有重复组，不管是重复的列还 是列中含有的重复信息都不允许。(数据库设计) 如不要把数学成绩，语文成绩和外语成绩作为学生关 系中的属性，因为，一旦增加一门课程，该关系就必 须作修改。 正确的做法是把成绩独立出来，形成的关系模型为： 成绩（学号，学科号，成绩） 类似的如在学生关系中有联系电话属性，而每一个学 生可能有不确定的电话数量，则增加属性“电话1”、 “电话2”…，同样不符合1NF要求，正确的做法是增 加关系：R(学号，电话号码)
1）范式理论形成： 1971年，由1970年首先提出“大型共享数据 库数据的关系模型”的关系数据库之父 Edgar Frank Codd相继提出了三级规范化形式1NF3NF 1974年，E.F.Codd和Boyce共同提出BCNF 1977 Ronald Fagin提出了第四范式 以后又相继提出了5NF（Project-Join Normal Form (PJ/NF)) 、DKFN（Domain/Key Normal Form）和6NF
第二章 范式及其对数据库设计的 指导意义

范式理论及对实践指导意义概述。 范式：1NF、2NF、3NF、BCNF、4NF、5NF 实例分析及1NF、3NF的认识误区
关系模型下的树结构表达 供应商和系名问题


范式的局限－对冗余的进一步讨论
单表行间冗余 多表间冗余

2.1 范式理论及对实践指导意义概述
2）1NF的第一层次的解释



如一个学生的成绩包括数学，语文，外 语等，则成绩不能作为学生关系中的一 个属性。 要使其符合1NF,必须把数学，语文，外 语成绩直接作为学生关系的属性。 由于关系数据库中表中列之间的关系相 互并列,本身不支持层次结构或数组,所以 表面上看,只要是二维表,就一定符合1NF
名称
服装 男装 西装 休闲装 女装 套装 职业装 休闲装 童装 电器 进口 国产 日用品
冗余分析：


在上述设计中增加“上级代码”、“代码级 数”、“是否为叶结点”等列，显然，这些列 的数据为冗余数据，因为这些数据值完全可以 由“代码”计算得到。 这些列并不传递或部分依赖于码 似乎产生了一种既有数据冗余但又符合所有范 式的模式
3）1NF的第二层次的解释



不要或没有必要把若干属性或代码组合成一 个组合属性或组合代码放在一个数据列中。 这同样违反1NF 。 这样做的风险是数据库系统对组合属性中某 属性的可操作性(子串)一定不如对列的可操作 性。 解决上述问题的方法也不要简单地把组合属 性分解成列,当这些属性有扩充的可能时,应单 独建立一个关系。（后面有详例分析）
三）结点的引用


第一种设计若直接选择code列主码，则一旦代码进 行修改，通过外键引用该表的关系也要做修改。 第二种设计由于其他关系通过id列引用该表，所以当 code列修改后，通过外键引用该表的关系无需做修 改。 作为外码，引用第二种设计的id对空间的占用比引 用第一种设计code对空间占用要小。 设计一也可人为地增加一个主码，但客观上又造成 新的空间占用。
插入，更新和删除异常实例：
假设存在下列关系，包含学生和系的基本信息： 学号 姓名 所在系 系主任 001 zhang 数学 Mr Li 002 wang 数学 Mr Li 003 zhou 数学 Mr Li 004 feng 计算机 Mr chen 005 dong 计算机 Mr chen
ห้องสมุดไป่ตู้
该关系存在插入，更新和删除异常。
例.学生学科成绩的关系模型设计
若把学生学科成绩设计成（学号，姓名，学科 号，学科名，成绩），该关系就不符合第二范 式。（“学号”，“学科号”）为该关系的主 键（码），非主属性中，除“成绩”完全依赖 于主键，“姓名”和“学科名”不完全依赖于 主键，即仅分别完全依赖于主键的子集“学号” 和“学科号”。 要使其符合2NF，必须把上述关系分解成三个 关系：学生(学号,姓名,…)、学科(学科号,学科 名,…)和成绩(学号, 学科号, 成绩)。


正确的做法是在学生关系中增加“系编号”属 性，同时增加一个关系：系（系编号，系名， 系主任） 。 学号 姓名 系号 系号 系 系主任 001 wang 01 01 数学 Li 002 Feng 01 02 物理 Xu 003 Cheng 01 004 Huang 02 单据中包含商品代码外,还包括商品属性,同样 不符合第三范式,因为存在下列传递函数依 赖:(单据号,单据明细序号)商品代码商品属 性。
2.3 实例分析： 2.3.1 正确理解1NF-树结点的数据表设计：
一个商场的商品分类:
商品分类 服装
男装 西装 休闲装 女装 套装 职业装 休闲装
童装
电器 进口 国产 日用品
关系模型设计：
代码（主码）
01 0101 010101 010102 0102 010201 010202 010203 0103 02 0201 0202 03
四）算法比较

对某个结点是否为叶结点的判断
2.2.2
2NF及对实践的指导意义
函数依赖： 函数依赖：属性或属性组A的值确定后能唯一 确定属性或属性组B的值，则称B函数依赖于 A。 如B是A的子集，则一定依赖于A，称为平凡 的函数依赖，以下提到的函数依赖，均指非 平凡的函数依赖。 B函数依赖于A，C是A的子集，若B也函数依 赖于C，则称B部分函数依赖于A，反之，如 不存在A的子集使B函数依赖于这个子集，则 B称为完全函数依赖A。
code
01 01 01 02 02 01 02 03 03 02 01 02 03
pid
0 0 1 2 2 1 5 5 5 1 0 10 10 0
name
服装 男装 西装 休闲装 女装 套装 职业装 休闲装 童装 电器 进口 国产 日用品
为以后算法实现的方便，左边设计第一行为根结点，并且code类型必须使用var char避免空格。以下假设上列数据对应两个表：classes_1和classes_2。
2.2.2

2NF及对实践的指导意义
关系属于第一范式并且每一个非主属性完全依 赖于码，则称关系属于第二范式。 由于非主属性均函数依赖于码，所以第二范式 去除了非主属性对码的部分依赖。
例.单据的单表设计就不属于第2范式
单据号 b001 b001 b002

单据日期 2003-2-1 2003-2-1 2004-2-7