数据库设计（函数依赖，范式）
2010-01-16 21:00阅读：
按：数据库的范式设计是为了优化关系数据库的关系模式，便于减少数据冗余以及冲突。
而范式是建立在函数依赖的基础上的。
要看懂这个还有一个基础是要明白主码，主属性和非主属性的概念。
不同阶段的范式是一个不断的优化关系模式的过程，其实就是限制条件不断升级，关系模式不断精化的过程。
不过随着范式的提高，关系模式的数量也会增加（对于个别表精化了，被剔除的关系只能形成新的关系模式），如果多个关系之间进行连接或并的操作的话，对数据库的性能会产生影响。
综合考虑一般精化至3NF即可。
高阶段的范式是在低阶段范式的基础上，加入新的限制条件形成的。所以满足高范式的一定满足比其低的范式。
第一范式是确定模式是符合关系关系模式的要求，即确立某关系属于关系模式。
第二范式是消除了非主属性对主码的部分函数依赖。
第三范式是消除了非主属性的传递函数依赖。
*3NF去除了非主属性对主键的部分函数依赖和传递函数依赖*
BCNF是消除了所有属性的传递函数依赖。
*BC范式既检查非主属性，又检查主属性。当只检查非主属性时，就成了第三范式。满足BC范式的关系都必然满足第三范式*
第四范式取消了多值依赖。
第五范式取消了连接依赖。
*严格的说上述两种依赖，不属于函数依赖的范畴，可以自己参考相关书籍理解*
由于现在没有时间深入说，就把之间的关系说清就好了，反正也不难理解，再看看书就明白了^_^
文中的例子是汇总于网络文章的，谢谢原作者了。
函数依赖
部分函数依赖-------
完全函数依赖：在一个关系中，若某个非主属性数据项依赖于全部关键字称之为完全函数依赖。
如果非主属性B函数依赖于构成某个候选关键字的一组主属性A，而不函数依赖于A的任何一个真子集，则称B完全函数依赖于A；反之，则称B部分函数依赖于A。
传递函数依赖-----------
非平凡依赖-----------
在关系模式R(U)中，对于U的子集X和Y，
如果X→Y，但Y ? X，则称X→Y是非平凡的函数依赖
若X→Y，但Y ? X,
则称X→Y是平凡的函数依赖
例：在关系SC(Sno, Cno, Grade)中，
非平凡函数依赖： (Sno, Cno) → Grade
平凡函数依赖： (Sno,
Cno) → Sno
(Sno, Cno) → Cno
多值依赖
见下“范式”部分，针对第四范式，第四范式就是为了取消多值依赖
连接依赖
见下“范式”部分，针对的是第五范式
----------------------------------------------------------------------------
首先要明白，范式的包含关系。一个数据库设计如果符合第二范式，一定也符合第一范式。如果符合第三范式，一定也符合第二范式…
范式
---------------------------------------------------------------------------
第一范式
定义：如果关系R
中所有属性的值域都是单纯域，那么关系模式R是第一范式的
那么符合第一模式的特点就有
1)有主关键字
2)主键不能为空，
3)主键不能重复,
4)字段不可以再分
例如：
StudyNo |
Name | Sex |
Contact
20040901
john
Male
Email:kkkk@ee.net,phone:222456
20040901
mary
famale email:kkk@fff.net
phone:123455
以上的表就不符合，第一范式：主键重复(实际中数据库不允许重复的)，而且Contact字段可以再分
所以变更为正确的是
StudyNo |
Name | Sex |
Email
|
Phone
20040901
john
Male
kkkk@ee.net 222456
20040902 mary
famale kkk@fff.net
123455
这两种情况都不满足第一范式。不满足第一范式的数据库，不是关系数据库！所以，我们在任何关系数据库管理系统中，做不出这样的“表”来。
在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。例如，对于图3-2
中的员工信息表，不能将员工信息都放在一列中显示，也不能将其中的两列或多列在一列中显示；员工信息表的每一行只表示一个员工的信息，一个员工的信息在表中只出现一次。简而言之，第一范式就是无重复的列。
------------------------------------------------------------------------------------------
第二范式：
定义：如果关系模式R是第一范式的，而且关系中每一个非主属性不部分依赖于主键，称R是第二范式的。
所以第二范式的主要任务就是
满足第一范式的前提下，消除部分函数依赖。
StudyNo |
Name | Sex |
Email
| Phone
| ClassNo |
ClassAddress
01
john
Male
kkkk@ee.net 222456
200401
A楼2
01
mary
famale
kkk@fff.net 123455
200402
A楼3
这个表完全满足于第一范式,
主键由StudyNo和ClassNo组成，这样才能定位到指定行
但是,ClassAddress部分依赖于关键字(ClassNo-〉ClassAddress),
所以要变为两个表
表一
StudyNo |
Name | Sex |
Email
|
Phone |
ClassNo
01
john
Male
kkkk@ee.net 222456 200401
01
mary
famale
kkk@fff.net
123455
200402
表二
ClassNo | ClassAddress
200401
A楼2
200402
A楼3
（学生上课表）
学生 课程 老师 老师职称 教材 教室 上课时间
小明 一年级语文（上） 大宝 副教授 《小学语文1》 101
14：30
一个学生上一门课，一定在特定某个教室。所以有（学生，课程）－>教室
一个学生上一门课，一定是特定某个老师教。所以有（学生，课程）－>老师
一个学生上一门课，他老师的职称可以确定。所以有（学生，课程）－>老师职称
一个学生上一门课，一定是特定某个教材。所以有（学生，课程）－>教材
一个学生上一门课，一定在特定时间。所以有（学生，课程）－>上课时间
因此（学生，课程）是一个码。
然而，一个课程，一定指定了某个教材，一年级语文肯定用的是《小学语文1》，那么就有课程－>教材。（学生，课程）是个码，课程却决定了教材，这就叫做不完全依赖，或者说部分依赖。出现这样的情况，就不满足第二范式！
有什么不好吗？你可以想想：
1、
校长要新增加一门课程叫“微积分”，教材是《大学数学》，怎么办？学生还没选课，而学生又是主属性，主属性不能空，课程怎么记录呢，教材记到哪呢?
……郁闷了吧?(插入异常)
2、
下学期没学生学一年级语文（上）了，学一年级语文（下）去了，那么表中将不存在一年级语文（上），也就没了《小学语文1》。这时候，校长问：一年级语文（上）用的什么教材啊？……郁闷了吧?(删除异常)
3、
校长说：一年级语文（上）换教材，换成《大学语文》。有10000个学生选了这么课，改动好大啊！改累死了……郁闷了吧？（修改异常）
那应该怎么解决呢？投影分解，将一个表分解成两个或若干个表
学生 课程 老师 老师职称 教室 课时间
小明 一年级语文（上） 大宝 副教授 101 14：30
学生上课表新
课程 教材
一年级语文（上） 《小学语文1》
课程的表
第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体
--------------------------------------------------------------------------------
第三范式：
满足第二范式的前提下，消除传递依赖。
例:
StudyNo |
Name | Sex |
Email
|
bounsLevel |
bouns
20040901
john
