第一范式
定义
关系中的每个属性都不可再分。
理解
基本的数据库都满足第一范式。
第二范式
定义
1）关系中不存在非主属性对于主属性的部分函数依赖。
2）非主属性必须对主属性完全依赖。
举例
比如主属性为：A、B，而C作为一个非主属性，只与A有依赖关系，C与B无关，那么此时C对于A、B只存在部分依赖，此时不符合第二范式。
理解
符合第二范式的关系能够保证每一个非主属性都严格的依赖主属性。就是任何一个非主属性都必须和所有的主属性有关。通俗的说，这张表中的内容都和主键有关，主键是最核心的部分。如果存在冗余的字段，将在第二范式中被剔除。
作用
1）消除冗余，只有完全依赖的才能留下，依赖性不强的字段都删掉了。
2）降低数据间的耦合，对一类事物的修改不会影响其他事物。
第三范式
定义
关系中不存在非主属性对于非主属性的任何函数依赖。
举例
比如主属性为：A，而B、C作为非主属性，存在“B依赖A，C完全依赖或部分依赖B”的情况。那么此时C对于B存在依赖情况，此时不符合第三范式。
理解
第三范式更加严格，第二范式说普通的属性必须和主属性（如果主属性是多个，那么就必须和所有的主属性（或主属性联合起来的概念）有关）有关，但是没有规定这些普通属性间有什么要求。第三范式说，如果普通属性之间也有关系，比如C会被B决定或影响，那么C就应该被踢出去，单独和B（或含有B和其他的属性）建另外的一张表。
作用
1）消除冗余，往往C依赖于B，当有大量B的时候C也都是大量一样的数据，浪费。
2）降低数据间的耦合，对一类事物的修改不会影响其他事物。
BC范式
定义
主属性中不存在某些属性部分依赖另外一些属性。
举例
比如主属性为：A、B、C。存在B依赖于A、C的情况。此时不符合BC范式。
理解
看了第二第三范式你会发现一个问题，如果我把主属性也就是主键定义的很大，基本都能满足这两个范式，因为第二第三范式是针对非主属性的规定。范式也想到了这个问题，就出现了BC范式，通俗地说，BC范式就是告诉我们“别吧主键定太多，主键也要符合规矩啊”。主键内不能存在依赖的情况。
作用
1）降低数据间的耦合，对一类事物的修改不会影响其他事物。