NF: normal form，中文叫范式。实质是数据库建表的规则，旨在减少数据库存储的冗赘。
1NF
符合1NF的关系中的每个属性都不可再分。
相当于ER-diagram中任何multiple attribute不能独立作为表中单独的一个字段。
例子：家庭地址可以被继续拆分成：省、市、街道、小区、邮编。所以不符合1NF。
字段是否真的不可拆分，根据你的设计目标而定。不能一概而论。
2NF
[ 消除非主属性对键的部分函数依赖 ]
2NF在1NF的基础之上，消除了非主属性对于码的部分函数依赖。
大白话就是，属性完全依赖于主键，不依赖于其他字段。
不满足2NF可能会存在问题：
（以最经典的学生选课系统为例）
- 数据冗余: 每条记录都含有相同信息；
- 删除异常：删除所有学生成绩，就把课程信息全删除了；
- 插入异常：学生未选课，无法记录进数据库；
- 更新异常：调整课程学分，所有行都调整。
依赖
完全函数依赖
在一张表中，若 X → Y，且对于 X 的任何一个真子集（假如属性组 X 包含超过一个属性的话），X ‘ → Y 不成立，那么我们称 Y 对于 X 完全函数依赖。
部分函数依赖
假如 Y 函数依赖于 X，但同时 Y 并不完全函数依赖于 X，那么我们就称 Y 部分函数依赖于 X。
大白话：X中的一部分字段，足够决定Y。
传递函数依赖
设X,Y,Z是关系R中互不相同的属性集合，存在X→Y(Y !→X),Y→Z，则称Z传递函数依赖于X。
大白话： Y 对于 X 完全函数依赖，Z对于 Y 完全函数依赖。Z传递函数依赖于X。
至少要有三个属性才可能存在传递函数依赖关系。
码
码设 K 为某表中的一个属性或属性组，若除 K 之外的所有属性都完全函数依赖于 K（这个“完全”不要漏了），那么我们称 K 为候选码，简称为码。
大白话就是：假如当 K 确定的情况下，该表除 K 之外的所有属性的值也就随之确定，那么 K 就是码。一张表中可以有超过一个码。实际应用中为了方便，通常选择其中的一个码作为主码（主键）。
包含在任何一个候选码中的属性，称为主属性。不包含在任何码中的属性称为非主属性或非码属性。
3NF
[ 消除非主属性对键的传递函数依赖 ]
3NF是对字段的冗余性，要求任何字段不能由其他字段派生出来，它要求字段没有冗余，即不存在传递依赖。
第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。
BCNF
[ 消除主属性对键的部分函数依赖 ]
鲍依斯-科得范式 Boyce-Codd Normal Form，也被称为3.5范式。
在某些特殊情况下，即使关系模式符合 3NF 的要求，仍然存在着插入异常，修改异常与删除异常的问题。造成此问题的原因：存在着主属性对于码的部分函数依赖与传递函数依赖。
4NF
[消除非平凡且非函数依赖的多值依赖]
4NF就是限制关系模式的属性之间不允许有非平凡且非函数依赖的多值依赖。
4NF所允许的多值依赖实际上是函数依赖。
大白话，如果一张表出现两个或以上1：N关系，大概率不符合4NF。
多值依赖
多值依赖是属性之间的一对多关系，记为K→→A。
函数依赖事实上是单值依赖，所以不能表达属性值之间的一对多关系。（有人称函数依赖为多值依赖的特例）
平凡的多值依赖：全集U=K+A，一个K可以对应于多个A，即K→→A。此时整个表就是一组一对多关系。
非平凡的多值依赖：全集U=K+A+B，一个K可以对应于多个A，也可以对应于多个B，A与B互相独立，即K→→A，K→→B。整个表有多组一对多关系，且有：“一”部分是相同的属性集合，“多”部分是互相独立的属性集合。
5NF
[消除不是由候选码所蕴含的连接依赖]
也被称为完美范式和项目连接正常形式(PJ/NF)
如果关系模式R中的每一个连接依赖均由R的候选码所隐含，则称此关系模式符合第五范式。
第五范式有以下要求：必须满足第四范式；表不能被无损地分解为较小的表，
除非那些表在逻辑上拥有与原始表相同的主键。
大白话，不包含任何连接依赖关系并且连接应该是无损的。
