范式：使模式的函数依赖满足特定要求的模式叫范式．
做好数据库范式是需要离散数学方面的知识．
范式主要分为:
1.第一范式
2.第二范式
3.第三范式
4.BCNF
5.第四范式
6.第五范式
浏览本文之前做如下约定：
关系 ＜－＞ 表
属性 ＜－＞ 字段
元组 ＜－＞ 记录
插入异常:在进行插入数据时，无法将数据插入到数据库中，关系数据库无法操作，即为插入异常。
删除异常:删除一个关系中不必要的信息时，将不该删除的信息也删除了，即为删除异常。
更新异常:对数据库进行更新时，如有疏漏，某些记录被漏改，造成数据的不一致而出错，这即是更新异常。
1.第一范式：如果关系模式R（U，F）中如果每个属性值都是不可再分的最小数据单位，则称R是第一范式的关系。
例1:用＂职工号＂，＂姓名＂，＂电话号码＂三个字段来组成一个表，其中＂电话号码＂字段的值可以是公司的电话号码
也可以是家里的电话号码．那么如何把它分解为第一范式，我们可以
一．电话号码为关键字，重复存储职工号和姓名．
二．职工号为关键字，电话号码分为单位电话和住宅电话两个属性．
三．是职工号为关键字，但强制每条记录只能有一个电话号码。
以上三个方法，第一种方法最不可取，因为它造成了冗余，按实际情况选取后两种情况。
２.第二范式：如果关系模式R（U，F）中的所有非主属性都完全依赖于任意一个候选关键字,则称关系R 是属于第二范式的。
选课关系SCI(SNO,CNO,GRADE,CREDIT) 其中
１．SNO是学号
２．CNO是课程号
３．GRADE是成绩
４．CREDIT是学分
由语义可知，关键字为组合关键字（SNO，CNO）
在应用中使用以上关系模式会出现以下问题
A.数据冗余，假如同一门课程由１００个学生选修，则这门课程的学分要重复储存１００次，而实际上一门课程对应一个 学分．
B.更新异常，若要重新调整学分，则相应的元组的CREDIT的属性值都要更新，假如更新不完全，则有可能出现一门课程对
应多个学分．
C.插入异常，若计划开新课，需要把新课对应的学分插入到数据库，但此时没有学生选修该课程，也就是没有学生号关键 字，则导致插入不进去，直到有人选择该课程．
D.删除异常，若学生已经结业，需要从当前数据库中删除选修记录，但与此同时，CNO,GRADE的信息也被删除了．
原因：非关键字属性CREDIT仅函数依赖于CNO，也就是CREDIT部分依赖组合关键字（SNO，CNO）而不是完全依赖。
解决方法：分解成两个关系模式 SC1(SNO,CNO,GRADE),C2(CNO,CREDIT)
其实这与我在另一篇文章里面说的两个实体A,B，它门是M:N的联系，则将联系定义为新的关系，属性为双方的码是一样的 道理．
3. 第三范式：如果关系模式R(U,F)中所有的非主属性对任何候选关键字都不存在传递依赖，则称关系R是属于第三范式
例3:
如S1(SNO,SNAME,DNO,DNAME,LOCATION)各属性含义如下
1.SNO 学号
2.SNAME 姓名
3.DNO 所在系
4.DNAME 系名称
5.LOCATION 系地址
关键字SNO决定各个属性。由于是单个关键字，没有部分依赖的问题，肯定是2NF。但这关系肯定有大量的冗余，有关学生所在的几个属性DNO，DNAME，LOCATION将重复存储，插入，删除和修改时也将产生类似以上例的情况。
原因：关系中存在传递依赖造成的，
1.SNO学号－＞DNO所在系
2.DNO所在系-＼->SNO学号
3.DNO所在系－＞LOCATION系地址
所以SNO学号－＞LOCATION系地址是传递依赖的
解决目地：每个关系模式中不能留有传递依赖。
解决方法：分为两个关系 S（SNO，SNAME，DNO），D（DNO，DNAME，LOCATION）
注意：关系S中不能没有外关键字DNO。否则两个关系之间失去联系。
