1 .为什么要考虑分解数据库关系模型？
a )因为现有模型可能存在数据冗馀过大、更新异常、插入异常、删除异常等添加或删除数据的弊端。 因此，为了完善数据库增删检查的功能，有必要寻找等价的关系模型，这些弊端将得到解决。
2 .如何实现关系模型的分解？
答：以上等价关系由1》保持无损连接性。A .解释：分解后，n个分解关系自然连接(自然连接是在等价连接的基础上去掉同一列， 如果在自然连接中找不到等价信息，自然连接等价于笛卡儿积)形成的二次元表和分解前无关的二次元表等价)的组不增加，不增加，如何判断不增加的b .无损连通性：2》保持函数依赖性。解释： http://
1 ) B1:关于分解为多个关系模式的方法例1 (适用于所有情况) :
无损分解的测试方法。 输入：关系模型r=(a1，A2.An )，f是r上成立的函数依赖集，={R1，R2.Rn}是r的一个分解； 输出)判断对f是否具有无损分解特性。 无损分解的测试算法如下。
1 .制作与属性phdhm(1jn )对应的k行n列的表，使图案rj ) 1Ik )与各行对应。 如果phdhm在Ri中，请在表的第I行第j列中填写符号wydbz，否则填写bij。
2 .将表视为模式r的关系，反复检查f中的各FD在表中是否成立，如果不成立，则修正表中的值。 修正方法是，f中的一个函数依赖于XY，如果表中的两行在x值上相等，在y值上不相等，则变更为这两行在y值上也相等。 如果其中一个y值是wydbz，并且没有另一个wydbz要更改为相同的值，请用其中一个bij替换另一个单词。 (将下表ij更改为尽可能小的数字。 在表无法修改之前，此过程为chase (跟踪)过程
3 .如果修改后的最后一个直线表中的一个都是a，即a1，a2.an，则对于f为无损分解，否则称为损失分解
2 ) B2:仅分解为两个关系图案时，也可以使用例2方法。
当关系模型r的一个分解={ R11，F1，R22，f2}u1u2u1-u2属于f的子集时，或者当U1U2 U2-U1属于f的子集时，破坏连通性
该定理可以用于被2分割的模式分解不损害连接性的判定
例2 )学生关系s(SnO，Sname，Ssex，Dept，DeptManager )为s ) SnO，Sname，Ssex，SDept )和d ) Dept，DeptManager )，ds=
3 .关系模式范式：
主要有四种范式。 1NF、2NF、3NF和BCNF。 从左到右的顺序一个比一个严格。 为了符合某种范式，之前的所有范式也必须满足。 一般项目的数据库设计达到3NF即可，可以根据情况适当增加冗余度，不需要教条式地遵守所谓的规范。
简而言之，1NF要求表里仅配置相互关联的字段，每个字段中仅配置一个信息，这仅仅是最基本的要求。
1）第一范式
在关系模型r的每个具体关系r中，如果每个属性值都是不可分割的最小数据单位，则r称为第一范式关系。
在所有关系数据库中，第一模式(1NF )是关系模型的基本要求，不满足第一模式(1NF )的数据库不是关系数据库。
例如，将员工号码、姓名、电话号码制成表格(一个人可能有办公室电话和家庭电话)的规范为1NF有两种方法。
一个是以员工号码为关键词，电话号码分为公司电话和住宅电话两个属性
第二个是员工号码作为关键字，但每条记录只能有一个电话号码。
2）第二范式(2NF)
当关系模型r为1NF，r内的各非主属性完全依赖于r的候补关键词时，r为第2范式，简称为2NF
例)设置关系模型r (学校编号S#，授课编号C#，成绩g，yxdspTN，教师专业知识TS )，基于r的函数依存集合f=((s#，c ) ) g，C#TN，TNTS} )，r为220
解： (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,yxdspTN,教师专长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,yxdspTN,教师专长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属于第一范式，且每个属性都不传递依赖于键码。