第一范式（1NF）：每一列都是不可分割的原子数据项（什么意思，每一项都不可分割，像下面的表格就能分割，所以它连第一范式都算不上）
分割后的样子
（它就是第一范式了）
第二范式：在1NF基础上，非码属性必须完全依赖于候选码（在1NF基础上消除非主属性对主码的部分函数依赖）
几个重要的概念:
1.函数依赖：A–>B，如果通过A属性（属性组）的值，可以确定唯一的B属性的值，则称B依赖于A
例如：学号---->姓名 （学号、课程名称 的属性组）–> 分数
2.完全函数依赖：A–>B 如果A是一个属性组，则B属性值的确定需要依赖A属性组的中所有的属性值
例如：（学号、课程名称）–> 分数
3. 部分函数依赖： A–>B 如果A是一个属性组，则B属性值的确定只需要依赖A属性组的中某一些的属性值（第二范式就是消除这个）
例如：（学号 、课程名称）–> 姓名
4.传递函数依赖：A – >B , B – >C 如果通过A属性（属性组）的值，可以确定唯一的B属性的值，再通过B属性（属性组）的值，可以唯一确定C属性的值，那么称C传递依赖于A
例如： 学号 --> 系名 ，系名 --> 系主任
5.码 ：如果在一张表中，一个属性或属性组，被其他所有的属性（非主属性）所完全函数依赖，则称这个属性（属性组）为该表的码。（上面的表，学号和课程名称所构成的属性组就是码）
例如： 该表中码为 （学号、课程名称）
主属性： 码中所有属性
非主属性： 除码之外的所有属性
表3
例如：
对于表3，主属性就有两个，学号 与 课名。
终于可以回过来看2NF了。首先，我们需要判断，表3是否符合2NF的要求？根据2NF的定义，判断的依据实际上就是看数据表中是否存在非主属性对于码的部分函数依赖。若存在，则数据表最高只符合1NF的要求，若不存在，则符合2NF的要求。判断的方法是：
第一步：找出数据表中所有的码。
第二步：根据第一步所得到的码，找出所有的主属性。
第三步：数据表中，除去所有的主属性，剩下的就都是非主属性了。
第四步：查看是否存在非主属性对码的部分函数依赖。
对于表3，根据前面所说的四步，我们可以这么做：
第一步：
查看所有每一单个属性，当它的值确定了，是否剩下的所有属性值都能确定。查看所有包含有两个属性的属性组，当它的值确定了，是否剩下的所有属性值都能确定。……查看所有包含了六个属性，也就是所有属性的属性组，当它的值确定了，是否剩下的所有属性值都能确定。看起来很麻烦是吧，但是这里有一个诀窍，就是假如A是码，那么所有包含了A的属性组，如（A，B）、（A，C）、（A，B，C）等等，都不是码了（因为作为码的要求里有一个“完全函数依赖”）。
下图表示了表中所有的函数依赖关系：
图4
这一步完成以后，可以得到，表3的码只有一个，就是 （学号、课名） 。
第二步：主属性有两个：学号 与 课名
第三步：非主属性有四个：姓名、系名、系主任、分数
第四步：
对于（学号，课名） → 姓名，有 学号 → 姓名，存在非主属性 姓名 对码（学号，课名）的部分函数依赖。
对于（学号，课名） → 系名，有 学号 → 系名，存在非主属性 系名 对码（学号，课名）的部分函数依赖。
对于（学号，课名） → 系主任，有 学号 → 系主任，存在非主属性 对码（学号，课名）的部分函数依赖。
所以表3存在非主属性对于码的部分函数依赖，最高只符合1NF的要求，不符合2NF的要求。
为了让表3符合2NF的要求，我们必须消除这些部分函数依赖，只有一个办法，就是将大数据表拆分成两个或者更多个更小的数据表，在拆分的过程中，要达到更高一级范式的要求，这个过程叫做”模式分解“。模式分解的方法不是唯一的，以下是其中一种方法：
选课（学号，课名，分数）
学生（学号，姓名，系名，系主任）
我们先来判断以下，选课表与学生表，是否符合了2NF的要求？
对于选课表，其码是（学号，课名），主属性是学号和课名，非主属性是分数，学号确定，并不能唯一确定分数，课名确定，也不能唯一确定分数，所以不存在非主属性分数对于码 （学号，课名）的部分函数依赖，所以此表符合2NF的要求。
对于学生表，其码是学号，主属性是学号，非主属性是姓名、系名和系主任，因为码只有一个属性，所以不可能存在非主属性对于码 的部分函数依赖，所以此表符合2NF的要求。
图5表示了模式分解以后的新的函数依赖关系
表4表示了模式分解以后新的数据
表4
（这里还涉及到一个如何进行模式分解才是正确的知识点，先不介绍了）
现在我们来看一下，进行同样的操作，是否还存在着之前的那些问题？
只需要修改一次单纯的荷花对应的系的值即可。——有改进数据冗余是否减少了？
学生的姓名、系名与系主任，不再像之前一样重复那么多次了。——有改进删除某个系中所有的学生记录
该系的信息仍然全部丢失。——无改进插入一个尚无学生的新系的信息。
因为学生表的码是学号，不能为空，所以此操作不被允许。——无改进
所以说，仅仅符合2NF的要求，很多情况下还是不够的，而出现问题的原因，在于仍然存在非主属性系主任对于码学号的传递函数依赖。为了能进一步解决这些问题，我们还需要将符合2NF要求的数据表改进为符合3NF的要求。
3. 第三范式（3NF）3NF在2NF的基础之上，消除了非主属性对于码的传递函数依赖。也就是说， 如果存在非主属性对于码的传递函数依赖，则不符合3NF的要求。
接下来我们看看表4中的设计，是否符合3NF的要求。
对于选课表，主码为（学号，课名），主属性为学号和课名，非主属性只有一个，为分数，不可能存在传递函数依赖，所以选课表的设计，符合3NF的要求。
对于学生表，主码为学号，主属性为学号，非主属性为姓名、系名和系主任。因为 学号 → 系名，同时 系名 → 系主任，所以存在非主属性系主任对于码学号的传递函数依赖，所以学生表的设计，不符合3NF的要求。
为了让数据表设计达到3NF，我们必须进一步进行模式分解为以下形式：
选课（学号，课名，分数）
学生（学号，姓名，系名）
系（系名，系主任）
对于选课表，符合3NF的要求，之前已经分析过了。
对于学生表，码为学号，主属性为学号，非主属性为系名，不可能存在非主属性对于码的传递函数依赖，所以符合3NF的要求。
对于系表，码为系名，主属性为系名，非主属性为系主任，不可能存在非主属性对于码的传递函数依赖（至少要有三个属性才可能存在传递函数依赖关系），所以符合3NF的要求。。
新的函数依赖关系如图6
图6
新的数据表如表5
表5
现在我们来看一下，进行同样的操作，是否还存在着之前的那些问题？
删除某个系中所有的学生记录
该系的信息不会丢失。——有改进
插入一个尚无学生的新系的信息。
因为系表与学生表目前是独立的两张表，所以不影响。——有改进
数据冗余更加少了。——有改进
结论
由此可见，符合3NF要求的数据库设计，基本上解决了数据冗余过大，插入异常，修改异常，删除异常的问题。当然，在实际中，往往为了性能上或者应对扩展的需要，经常 做到2NF或者1NF，但是作为数据库设计人员，至少应该知道，3NF的要求是怎样的。
总结：
MYSQL
数据库三范式
一： 确保每列的原子性
二：非主键列不存在对主键的部分依赖 （要求每个表只描述一件事情）
三： 满足第二范式，并且表中的列不存在对非主键列的传递依赖
参考文章：
详解第一范式、第二范式、第三范式、BCNF范式