关系模式的分解与范式
1. 为什么要研究数据库关系模式的分解？
答：因为现有的模式可能会存在一些数据增删改的弊端，比如说：数据冗余太大，更新异常，插入异常，删除异常。因此为了完善数据库的增删改查的功能，需要寻找一种等价的关系模式，使得以上弊端得以解决。
2. 如何实现关系模式的分解？
答：以上的这种等价关系需要满足两个条件：1》保持无损连接性。A.解释：在分解之后，n个分解关系通过自然连接（自然连接是在等值连接的基础上去掉相同的列，如果自然连接中找不到等值信息那么自然连接就等价于笛卡尔积）形成的二维表和没分解之前关系的二维表是等价的（元组没有增加也没有减少），则称这种分解形成的关系模式保持无损连接性；B.如何判断无损连接性：2》保持函数依赖性。解释：若分解之后的关系模式中仍然存在和没分解之前属性的函数依赖关系则称保持分解的函数依赖性.
1） B1: 对于分解为多个关系模式的方法如例1（适用于所有情况）：
无损分解的测试方法。①输入：关系模式R=（A1，A2...An），F是R上成立的函数依赖集，ρ={R1,R2...Rn}是R的一个分解；②输出：判断ρ相对于F是否具有无损分解特性。无损分解的测试算法如下：
1. 构造一张k行n列的表格，每列对应一个属性Aj（1≤j≤n），每行对应一个模式Rj（1≤i≤k）。如果Aj在Ri中，那么在表格的第i行第j列处填上符号aj，否则填上bij。
2. 把表格看成模式R的一个关系，反复检查F中每个FD在表格中是否成立，若不成立，则修改表格中的值，修改方法为：对于F中一个函数依赖X→Y，如果表格中有两行在X值上相等，在Y值上不相等，那么把这两行在Y值上也改成相等的值，如果Y值中一个是aj,那么另一个也改成aj;如果没有aj那么用其中一个bij替换另一个字（尽量把下表ij改成较小的数）。一直到表格不能修改为止，这个过程成为chase（追踪）过程
3. 若修改后的最后一直表格中有一方全是a,即a1，a2...an，则称ρ相对于F是无损分解，否则称为损失分解
2） B2: 对于只分解为二个关系模式的还可以使用例2的方法：
关系模式R的一个分解 ρ = { R11,F1>，R22,F2>}如果U1∩U2→ U1－U2属于F+的子集或 U1∩U2 → U2－U1属于F+的子集 ，那么ρ具有无损连接性。
此定理可用于一分为二的模式分解无损连接性的判定
例2：学生关系S ( Sno,Sname, Ssex, Dept, DeptManager )分解为S(Sno,Sname, Ssex, Sdept) 和D(Dept,DeptManager), D∩S = Dept , D－S = DeptManager, Dept→DeptManager为原关系中的函数依赖，此分解为无损连接的分解。
3. 关系模式的范式：
主要有4种范式，1NF，2NF，3NF，BCNF，按从左至右的顺序一种比一种要求更严格。要符合某一种范式必须也满足它前边的所有范式。一般项目的数据库设计达到3NF就可以了，而且可根据具体情况适当增加冗余，不必教条地遵守所谓规范。
简单而言，1NF就是要求一张表里只放相互关联的字段，一个字段里只放一条信息，这只是最基本的要求。
1）第一范式：
在关系模式R中的每一个具体关系r中，如果每个属性值都是不可再分的最小数据单位，则称R是第一范式的关系。
在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
例：如职工号，姓名，电话号码组成一个表（一个人可能有一个办公室电话和一个家里电话号码）规范成为1NF有两种方法：
一是职工号为关键字，电话号码分为单位电话和住宅电话两个属性
二是职工号为关键字，但强制每条记录只能有一个电话号码。
2）第二范式(2NF)：
如果关系模式R为1NF，并且R中的每一个非主属性都完全依赖于R的某个候选关键字，则称R是第二范式的，简记为2NF
例. 设有关系模式R(学号S#,课程号C#,成绩G,任课教师TN,教师专长TS)，基于R的函数依赖集F={(S#,C#)→G,C#→TN,TN→TS},判断R是否为2NF。
解：(1) 容易看出，关系模式R是1NF。因为R符合关系的定义，R的所有属性值都是不可再分的原子值。
R是否为2NF，应根据2NF的定义来判断。
首先要确定关系模式R中各属性间的函数依赖情况。如果没有直接给出R的函数依赖集，就要按照语义把它确定下来。在本例中，已直接给出基于R的函数依赖集F，我们可使用阿氏推理规则并结合下面介绍的方法，进一步确定R中哪些是主属性、哪些是非主属性、侯选关键字由哪些属性构成。
写出函数依赖集F中的各个函数依赖以帮助分析
用阿氏推理规则由F可推出：(S#,C#)→{S#,C#,G,TN,TS}，即属性组合(S#,C#)是R的候选关键字(R只有这一个候选键)。(S#,C#)的一个值可惟一标识R中的一个元组(并且没有多余的属性)。
在R中，S#,C#是主属性；其余的属性G,TN,TS为非主属性。
非主属性G对键是完全依赖：(S#,C#)→G。但非主属性TN,TS对键是部分依赖(他们仅依赖于键的真子集C#)。由于R中存在非主属性对候选键的部分依赖，所以关系模式R不是2NF。
R中存在非主属性对候选键的部分依赖，将会引起数据冗余、数据操作异常等问题。可以把关系R无损联接地分解成两个2NF的关系模式：
ρ={R1,R2}，R1={S#.C#,G},R2={C#,TN,TS}。
3）第三范式(3NF)：
如果关系模式R为2NF，并且R中的每一个非主属性都不传递依赖于R的某个候选关键字，则称R是第三范式的，简记为3NF。
例续上例（R(学号S#,课程号C#,成绩G,任课教师TN,教师专长TS)），判断关系模式R1={S#.C#,G},R2={C#,TN,TS} 是否为3NF。
解：
(1) 在关系模式R1={S#,C#,G}，候选关键字是(S#,C#)，主属性是S#,C#，非主属性是G，函数依赖为(S#,C#)→G。 由于R1中不存在非主属性对候选关键字的传递依赖，所以关系模式R1是3NF。
(2) 在关系模式R2={C#,TN,TS}，候选关键字是C#，主属性是C#，非主属性是TN,TS，函数依赖为C#→TN，TN→TS。由于R2中存在非主属性对候选关键字的传递依赖C#TS，所以关系模式R2不是3NF。
可以把关系R2无损联接地分解成两个3NF的关系模式：
ρ={R3,R4}，R3={C#,TN},R4={TN,TS}。
4）Boyce-Codd范式(BCNF)：
如果关系模式R为1NF，并且R中的每一个函数依赖X→Y(YÏX),必有X是R的超关键字，则称R是Boyce-Codd范式的，简记为BCNF。
从BCNF的定义中，可以明显地得出如下结论：
(1) 所有非主属性对键是完全函数依赖；
(2) 所有主属性对不包含它的键是完全函数依赖；
(3)没有属性完全函数依赖于非键的任何属性组合。
与2NF,3NF的定义不同，BCNF的定义直接建立在1NF的基础上。但实质上BCNF是3NF的改进形式。3NF仅考虑了非主属性对键的依赖情况，BCNF把主属性对键的依赖情况也包括进去。BCNF要求满足的条件比3NF所要求的更高。如果关系模式R是BCNF的，那么R必定是3NF，反之，则不一定成立。
续前例（学号S#,课程号C#,成绩G,任课教师TN,教师专长TS）,判断两个3NF关系模式R3={C#,TN},R4={TN,TS}是否为BCNF。
解：在关系模式R3中有函数依赖C#→TN，决定因素C#是R3的键；
在关系模式R4中有函数依赖TN→TS，决定因素TN是R4的键；
R3,R4都满足BCNF的定义，所以，这两个关系模式都是BCNF。
4. 总结
第一范式（1NF）：数据库表中的字段都是单一属性的，不可再分。这个单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。
第二范式（2NF）：数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖（部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况），也即所有非关键字段都完全依赖于任意一组候选关键字。
第三范式（3NF）：在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。所谓传递函数依赖，指的是如果存在"A → B → C"的决定关系，则C传递函数依赖于A。因此，满足第三范式的数据库表应该不存在如下依赖关系： 关键字段 → 非关键字段x → 非关键字段y
BCNF: 在3NF的基础上不存在关键字段决定关键字段的情况。
1、第一范式（1NF）：一个关系模式R的所有属性都是不可分的基本数据项。
2、第二范式（2NF）：关系模式R属于第一范式，且每个非主属性都完全函数依赖于键码。
3、第三范式（3NF）：关系模式R属于第一范式，且每个非主属性都不传递依赖于键码。
4、 BC范式（BCNF）：关系模式R属于第一范式，且每个属性都不传递依赖于键码。