第一范式(1NF)
数据表的每一列都要保持它的原子特性，也就是列不能再被分割。
这张表就不符合第一范式规定的原子性，不符合关系型数据库的基本要求，在关系型数据库中创建这个表的操作就不能成功。不得不将数据表设计为如下形式。
第二范式(2NF)
概念：属性必须完全依赖于主键。
下满这张表不符合第二范式的要求。
缺点
- 表中的每一行数据都存储了系名、系主任，数据的冗余太大。
- 如果有一个新的系还没有开始招到学生，那么不能将该系的信息添加到数据表中去，从数据表中看不到该系的存在
- 如果将某个系的学生信息全部删除，那么这个系在数据表里也就不存在了，但这个系还存在。
- 如果某个人要转系，那么为了保证数据库中数据的一致性，需要修改三条记录中系与系主任的数据
依赖
在数据表中，属性（属性组）X 确定的情况下，能完全推出来属性Y，皆可以说属性Y 依赖于属性（属性组）X，记作：X->Y。
完全依赖
完全依赖是针对于属性组来说的，当一组属性X能推出来Y 的时候就说Y 完全依赖于X。
部分依赖
一组属性X中的其中一个或几个属性能推出Y 就说Y 部分依赖于X。
结论：当一个第一范式的候选码只有一个属性的时候，那它就是第二范式（2NF）
候选码
当一个属性或者属性组确定的情况下，这张表的其余所有属性就能确定下来，这个属性或者属性组就叫做候选码。
一张表可以有多个候选码
一般只选一个候选码作为主键
从表中找到两个属性：学号和课程
学号可以推出姓名、系名、系主任。
课程可以推出成绩。
将它们两个设置为联合主键
存在的部分依赖
- 姓名对学号存在部分依赖
- 系名对学号存在部分依赖
- 系主任对学号存在部分依赖
这显然不符合第二范式的要求，做出修改：
表一中分数完全依赖于学号和课程的属性。
表二中姓名、系名、系主任完全依赖于学号的属性
缺点
删除某个系的所有学生后，该系的信息仍然全部丢失。（第一范式的问题依赖存在）
第二范式消除了第一范式的部分依赖
第三范式(3NF)
概念：所有的非主属性不依赖于其它的非主属性
传递函数依赖
设X,Y,Z是关系R中互不相同的属性集合，存在X→Y(Y !→X),Y→Z，则称Z传递函数依赖于X。
在改进后的学生表中：
主属性：学号
非主属性：姓名、系名、系主任
知道系名可以推出系主任，所以非主属性系主任对主属性学号存在传递函数依赖，这不符合非主属性不依赖于其它的非主属性的设计要求。将该数据表改进如下：
第三范式消除了第二范式的传递函数依赖
BC 范式
主属性不能对候选码存在部分函数依赖或者传递函数依赖
这张表不存在部分函数依赖于传递函数依赖，属于第三范式。
表中的依赖关系
- 仓库名—>管理员
- 管理员—>仓库名
- 物品名—>数量
主属性：仓库名、管理员、物品名
非主属性:数量
存在的问题
- 先新增加一个仓库，但尚未存放任何物品，不可以为该仓库指派管理员，因为物品名也是主属性，根据实体完整性的要求，主属性不能为空。
- 某仓库被清空后，该仓库的信息也被清空
- 当需要更换仓库管理员，该仓库存放了多少物品，就要修改多少条信息。
在这个问题中就是存在了主属性对于候选码的部分依赖，也就是仓库名对于管理员和物品名的部分依赖。
修改为
仓库（仓库名，管理员）
库存（仓库名、物品数、数量）
第四范式(4NF)
消除表中的多值依赖
设R是一个关系模型，D是R上的多值依赖集合。如果D中存在凡多值依赖X->Y时，X必是R的超键，那么称R是第四范式的模式。
例如，职工表(职工编号，职工孩子姓名，职工选修课程)，在这个表中，同一个职工可能会有多个职工孩子姓名，同样，同一个职工也可能会有多个职工选修课程，即这里存在着多值事实，不符合第四范式。如果要符合第四范式，只需要将上表分为两个表，使它们只有一个多值事实，例如职工表一(职工编号，职工孩子姓名)，职工表二(职工编号，职工选修课程)，两个表都只有一个多值事实，所以符合第四范式。
优缺点：表的冗余性，提高了多表的联合查询的效率。
范式之间的关系
范式的目的
- 减少数据的冗余性
- 提高效率