[旋转]数据库的三范式经典实例分析
数据库的三范式
1N:关系r的属性都是不可分割的项目
2N:基于1N，每个非主要属性的完全函数取决于代码。
3N:基于2N，每个非主要属性都不依赖于代码，也不依赖于代码。
1N
|消除非主属性对代码的部分函数依赖
2N
|消除对非主属性代码的传递函数依赖
3N
|消除主属性对代码的部分传递函数依赖
BCNF
|消除非平凡且非函数依赖的多值依赖
4N
简要说明：
第三种模式的要求如下
1、每列只有一个值
2、每行都能区分。
3 )每个表都不包含其他表中已经存在的主键以外的信息。
你说的两个表，如果每个都满足三种模式，那么两个表也满足三种模式。
转自： http://www.blogjava.net/hijack wust/archive/2007/10/21/154793.html
数据库设计范式是数据库设计必须满足的规范，满足这些规范的数据库简洁、结构清晰，同时不会出现插入(insert )、删除(delete )、更新(update )操作异常。 反之则是胡作非为，不仅会给数据库程序员带来麻烦，而且一脸厌恶，可能保存了大量不必要的冗余信息。
设计范式很难理解吗？ 不，大学教材里有很多公式，我们当然不能理解，也记不住。 所以我们大多数人没有根据范式设计数据库。
实质上，设计范式可以用形象简洁的语言说清楚，明白。 本文对范式进行了简明的说明，并以笔者曾经设计过的简单论坛的数据库为例，说明如何将这些范式应用于实际工程中。
正规形式的说明
第一正则表达式(1NF ) :数据库表中的所有字段都是单个属性，不能再细分。 该单一属性由基本类型构成，有整数型、实数型、字符型、逻辑型、日期型等。
很明显，现在的关系数据库管理系统(DBMS )，即使是傻瓜也不能制作不符合第一范式的数据库。 因为这些DBMS不能将数据库表中的一列再分为两个以上的列。 因此，用现有的DBMS设计不符合第一模式的数据库是不可能的。 在第二范式(2NF )数据库表中，不存在非关键字段对任何关键字段候选的部分函数依赖性。 也就是说，某些函数依赖是组合键的一些字段决定非键字段的情况。 也就是说，所有非关键字段完全依赖于任何一个关键候选集。 将选择关系表作为SelectCourse (学校号码、姓名、年龄、课程名称、成绩、单位)，关键词组合；学校号码、课程名称)姓名、年龄、成绩、单位)的数据库表，决定如下
由于不符合2NF，该选择关系表存在以下问题。
(1)数据冗余：
如果n名学生选择了相同的课程，则“单位”重复n-1次； 同一学生修完m科目后，名字和年龄会重复m-1次。
)2)更新异常：
如果调整了课程的学分，则必须更新数据表中所有行的“学分”值。 否则，同一课程的单位可能会不同。
)3)插入异常：
如果开设新课程的话，还没有人选择。 这样，由于没有“学校号码”关键字，课程名称和学分也无法记录在数据库中。
)4)删除异常：
假设一组学生完成了课程的选修，则必须从数据库表中删除这些选修记录。 但是，与此同时，课程名称和学分信息也被删除了。 很明显，这也会导致插入异常。
将选择关系表SelectCourse更改为以下三个表。 学生： Student (学校号码、姓名、年龄)； 课程： Course (课程名称、单位)； 选择关系： SelectCourse (学号、课程名称、成绩)。 这些数据库表遵循第二范式，消除了数据冗馀、更新异常、插入异常和删除异常。 此外，所有单关键字数据库表都遵循第二种模式，因为不存在联接关键字。 第三范式(3NF ) )基于第二范式，如果数据表中没有对任何非关键字段候选的传递函数依赖性，则符合第三范式。 传递函数依赖是指，如果存在' A B C '的决定关系，则c传递函数依赖于a。 因此，在满足第三模式数据库表格中，关键字段非关键字段x 非关键字段y表示将学生关系表格存储在Student ()学校号码、姓名、年龄、所属学院、学院场所、学院电话、关键词
(学校号码) )所在学院) )、学院地点、学院电话)。
也就是说，存在对非关键字段“学院场所”、“学院电话”的关键字段“学号”的传递函数依赖。
还有数据冗余、更新异常、插入异常、删除异常，读者可以自行分析了解。
将学生关系表分为以下两个表。
学生：(学号、姓名、年龄、所属学院)；
学院：(学院、地点、电话。
这些数据库表符合第三范式，消除了数据冗馀、更新异常、插入异常和删除异常。
rydbq增益范式(BCNF
）：在第三范式的基础上，数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合第三范式。假设仓库管理关系表为StorehouseManage(仓库ID, 存储物品ID, 管理员ID, 数量)，且有一个管理员只在一个仓库工作；一个仓库可以存储多种物品。这个数据库表中存在如下决定关系：
(仓库ID, 存储物品ID) →(管理员ID, 数量)
(管理员ID, 存储物品ID) → (仓库ID, 数量)
所以，(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是StorehouseManage的候选关键字，表中的唯一非关键字段为数量，它是符合第三范式的。但是，由于存在如下决定关系：
(仓库ID) → (管理员ID)
(管理员ID) → (仓库ID)
即存在关键字段决定关键字段的情况，所以其不符合BCNF范式。它会出现如下异常情况：
(1) 删除异常：
当仓库被清空后，所有"存储物品ID"和"数量"信息被删除的同时，"仓库ID"和"管理员ID"信息也被删除了。
(2) 插入异常：
当仓库没有存储任何物品时，无法给仓库分配管理员。
(3) 更新异常：
如果仓库换了管理员，则表中所有行的管理员ID都要修改。
把仓库管理关系表分解为二个关系表：
仓库管理：StorehouseManage(仓库ID, 管理员ID)；
仓库：Storehouse(仓库ID, 存储物品ID, 数量)。
这样的数据库表是符合BCNF范式的，消除了删除异常、插入异常和更新异常。