转载【借鉴】
参考：1
预备知识
超键
超键(super key)：在关系中能唯一标识元组的属性集称为关系模式的超键
候选键
候选键(candidate key)：不含有多余属性的超键称为候选键。也就是关系中的一个属性组，其值能唯一标识一个元组。若从属性组中去掉任何一个属性，它就不具有这一性质了，这样的属性组称作候选键。
主属性：任何一个候选键中的属性称作主属性。
主键
主键(primary key)：用户从一个关系的多个候选键中，选定一个作为主键。
举例：
现有学生表如下：学生（学号，姓名，性别，身份证号）
- 超键
由超键的定义可知，在学生表中含有学号或者身份证号的任意组合都可以唯一标识一个学生，那么它们就是此表的超键。如：（学号）、（身份证号）、（学号，姓名）、（身份证号，性别）等。
- 候选键
候选键属于超键，它是最小的超键，就是说如果再去掉候选键中的任何一个属性它就不再是超键了。对于（学号、姓名）来说，去掉姓名后仍是一个超键，那么它就不是候选键。其中，学生表中的候选键为：（学号）、（身份证号），主属性就是学号、身份证号。
- 主键
主键就是候选键里面的一个，用户可以选择，那么在这里我们选择（学号）作为学生表的主键。
- 键 = 码，英文key。
完全函数依赖
数学描述：
通俗理解：
The value of one or a group attributes can decide the value of other attributes.一个或者一组属性的值可以决定其他属性的值。候选键都可以做到。
部分函数依赖
数学描述：
通俗理解：
举个例子，现有一关于学生的关系模式Student(学生编号 , 学生姓名, 班级编号, 院系, 课程编号 , 成绩)
（学生编号#、课程编号#）作为主键，可以唯一标识每条元组，但是对于
学生姓名、学生所属的班级编号、院系，这三个属性可以直接通过学生编号来确定，在这里课程编号#显得很多余。于是称，学生姓名、班级编号、院系对（学生编号#、课程编号#）部分函数依赖。即，非主属性对键有部分函数依赖。主属性：任何一个候选键中的属性称作主属性。 键在这里理解成候选键传递函数依赖
数学描述：
设X,Y,Z是关系R中互不相同的属性集合，存在X→Y(Y !→X),Y→Z，则称Z传递函数依赖于X。
通俗理解：
以Student表为例，
学生编号可以唯一确定他所在的院系，但是注意到这中间存在传递过程，即学生编号唯一确定该学生所对应的班级编号，班级编号对应唯一的院系。我们称，院系对学生编号传递函数依赖。即，
非主属性对键有部分函数依赖。主属性：任何一个候选键中的属性称作主属性。范式
关系数据库中的模式设计要满足一定的规范，引入了范式这一概念。
不管做哪种范式的设计，最终要的思想是“one fact in one place”，也就是“一事一地”。1NF
定义：关系中每一分量不可再分。即不能以集合、序列等作为属性。（也就是不能表中套表，要保证数据的原子性。）
举例
它就不满足1NF，因为{C1，C2，C3}和{C1，C4}是集合。
修改为符合1NF：
缺点：
1、数据冗余太大【每一个系的系主任名字重复出现】
2、更新异常【某个系更换系主任时，必须将该系学生的每一个元组的系主任项更换】
3、插入异常【如果一个系刚成立，尚无学生，就无法将老师存入数据库中】
4、删除异常【如果学生毕业了，在删除学生时，也会把系主任的信息删除】
2NF
定义：在1NF基础上，消除非主属性对键的部分依赖，则称它符合2NF。
根据上面对部分依赖的分析，对于Student表：
对于
学生姓名、学生所属的班级编号、院系，这三个属性可以直接通过学生编号来确定，在这里课程编号#显得很多余。也就是，学生姓名、班级编号、院系对（学生编号#、课程编号#）部分函数依赖。把Student表进行拆分，可以消除部分依赖。其中，学生表Student如下：
学生-课程表如下：
符合2NF！
3NF
定义：在2NF基础上，消除非主属性对键的传递依赖，则称它符合3NF。
根据上面对传递依赖的分析，对于Student表，学生编号可以唯一确定他所在的院系，但是注意到这中间存在传递过程，即学生编号唯一确定该学生所对应的班级编号，班级编号对应唯一的院系。我们称，院系对学生编号传递函数依赖。
把Student表继续进行拆分，可以消除传递依赖。
其中，学生表Student如下：
班级-院系表如下：
符合2NF！
总结
1、第一范式（1NF）：一个关系模式R的所有属性都是不可分的基本数据项。 2、第二范式（2NF）：满足第一范式，然后消除部分依赖。 3、第三范式（3NF）： 满足第二范式，消除传递依赖。BCNF
数学定义：
换言之，对于关系模式R，如果每一个函数依赖的决定因素都包含键，则R属于BCNF范式。
现在举例，现有关系模式：通讯（城市名，街道名，邮政编码）
函数依赖关系集为：
F={（城市名，街道名）-> 邮政编码，邮政编码 -> 城市名}
也就是一个城市名和一个街道名，对应一个邮政编码；一个邮政编码对应一个城市名。此时，候选键（城市名，街道名）非主属性邮政编码完全依赖于候选键，且无传递依赖，属于3NF。
那么它是否属于BCNF呢？我们按照下面的定义来看一下，
换言之，对于关系模式R，如果每一个函数依赖的决定因素都包含键，则R属于BCNF范式。对于决定因素（城市名，街道名），它包含键（城市名，街道名），其实它本身就是键了，没问题；
对于决定因素邮政编码，它不包含键（城市名，街道名）所以它不属于BCNF。在关系模式R中，如果每一个决定因素都包含码，则R属于BCNF。
