文章目录
关系模式设计之规范形式：
下面的范式都是针对 关系模式 而言的。就是说你可以通过一张表来判定这张表是否符合某个范式。
什么是第一范式
如果关系模式中关系的每个属性都是原子而不可分的，这种关系模式符合 第一范式。
第一范式不允许复合属性和多值属性。
不符合第一范式时的处理手段
第一种办法是转换为符合第一范式的关系模式。
对于多值属性，可以将该属性和主键一起新建一个关系。
对于复合属性，要么将其打包在一起得到一个属性，要么将其拆开形成多个属性。
第二种办法是使用其它数据模型进行处理。
什么是第二范式
如果关系模式是符合第一范式的，并且关系中每个 非主属性 都 完全依赖 于 候选键<不存在非主属性对码的部分函数依赖 >，则该关系模式符合 第二范式。
解释：候选键要求是最小的，能够决定其它所有属性的属性组。对于唯一确定关系中的一条完整的记录，候选键是必需的；但是唯一确定关系中某个属性对应的一条记录，候选键中则可能有多余的属性。
举个不满足第二范式的例子：
假设关系模式是（学号，姓名，班级，课程，成绩）。根据这个关系中的函数依赖关系，可以将（学号，课程）作为一个候选键。因此姓名是非主属性，但是（姓名）这个属性是部分依赖于（学号，课程）的，实际上只要（学号）就能唯一确定（姓名）了。
不符合第二范式的关系中存在 非受控冗余。在上面那张表中，需要时刻维护一个学号只对应一个姓名，但是相同的（学号，姓名）二元组在关系中多次出现。
不符合第二范式时的处理手段
将这个关系分解为多个小的关系即可。
什么是第三范式
如果关系模式是符合第二范式的，并且关系中不存在传递依赖，则该关系模式符合 第三范式。
不满足第三范式的例子：关系模式为（学生学号，系号，系主任）。它符合第二范式。此时（学生学号）是候选键，系主任是一个非主属性。这个关系模式中有传递依赖（学生序号）→（系号），（系号）→（系主任），因此不符合第三范式。
不符合第三范式也会导致出现非受控冗余。
不满足第三范式时的处理手段
将关系拆分成多个关系。最极端的方式是只要有个函数依赖就进行拆分，直到最后的关系中每个只有一个函数依赖关系。可以在此基础上进行合并。
什么是 Boyce-Codd 范式
如果关系是符合第一范式的，并且对于关系中的任何函数依赖 X→Y，当 Y⊈X 时必有 X 包含某个候选键，则称关系符合 Boyce-Codd 范式。
Boyce-Codd 范式比第三范式更加严格。如果一个关系不满足第三范式，则必不满足 Boyce—Codd 范式。
不符合 Boyce-Codd 范式的例子：对于关系模式（城市，街道，邮政编码）来说，候选键是（城市，街道），但是因为（邮政编码）可以唯一确定（城市），这是一个函数依赖，但是被依赖的属性组不包括候选键，因此不符合 Boyce-Codd 范式。
不满足 Boyce-Codd 范式时的处理手段
将不包含候选键的函数依赖单独拿出来组成一个关系，将包含候选键的函数依赖组成另一个关系。
什么是多值依赖
多值依赖
设全体属性是 U。设 X 和 Y 是某个关系模式上的两个属性组。对于这个关系模式的任意一个关系 r，如果记录 t∈r,s∈r,t[X]=s[X]，则一定存在 u∈r,v∈r 使得：
都成立，则称 Y 多值依赖于 X，记作 X→→Y。
函数依赖是多值依赖的特殊情况。
多值依赖的性质： 如果 X→→Y，则 X→→U−X−Y；
第四范式
符合第一范式的关系模式中，任意一组依赖 X→→Y 中，如果 Y≠∅,Y⊈X,XY≠U，能够得到 X 一定为超键，则称该关系模式满足 第四范式。
直观来看，满足第四范式的关系模式中，依赖不能依赖于候选键以外的属性。
满足第四范式一定满足 Boyce-Codd 范式。在只有函数依赖的情况下，满足 Boyce-Codd 方式便一定满足第四范式。
关于多值依赖的 Armstrong 公理
