数据库范式的提出是为了对关系数据库中的数据进行规范而提出的一个概念，第一范式，第二范式，第三范式这三个范式逐渐对数据进行细分，意思就是指属于这三种范式之一的关系数据库的数据相互之间的依赖关系越来越清晰明了。下面对三种范式进行详细的讲解。
第一范式（1NF）：属于第一范式的数据库的表的列（属性）是不能再进一步拆分的。如
| 学号 | 课程 |
| 2014212797 | 软件技术基础 高数 |
很显然，这个表格的第二列是可以在细分的，所以不属于第一范式。第一范式是数据库数据的最低要求，不满足第一范式的的“数据库”不能称为关系数据库，在非规范化数据去掉组合项。
| 学号 | 课程 |
| 2014212797 | 软件技术基础 |
| 2014212798 | 高数 |
第一范式会出现数据冗余、插入、删除异常现象。（比如上面表格中学号的重复现象）
第二范式（2NF）:首先得满足第一范式的条件，并且表中必须要有一个主键，同时不属于主键的属性（意思是主键可以是几个属性）必须完全依赖于主键（这句话有点绕，好好理解下），即设置好某个表的属性后可以根据这个主键检索得到唯一的一个属性，而不能得到几个结果。如果出现的部分依赖的属性则应当将该属性与主键的依赖部分单独分离出来，单独建立一个表。第二范式的任务就是在满足第一范式的条件下消除部分函数依赖。
学号 | 姓名 | 邮箱 | 课程号 | 课程地址
2323 lf ddd 123 345
2323 lj dsd 345 3789
显然这个表属于第一范式，主键（由学号与课程地址）能定位到唯一一行。但是课程地址部分依赖于课程号，与学号无联系，所以该数据库不属于第二范式。所以需要讲部分依赖的主键与属性单独建立一个表。原表变为两个表：
学号 | 姓名 | 邮箱 | 课程号
2323 lf ddd 123
2323 lj dsd 345
课程号 | 课程地址
123 34
345 3789
不符合第二范式的数据库容易产生数据冗余
第三范式（3NF）：首先满足第二范式，同时不能存在传递性依赖。即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的情况。
简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性。
StudyNo | Name | Sex | Email | bounsLevel | bouns
20040901 john Male kkkk@ee.net 优秀 $1000
20040902 mary famale kkk@fff.net 良 $600
这个完全满足了第二范式,但是bounsLevel和bouns存在传递依赖
更改为：
StudyNo | Name | Sex | Email | bouunsNo
20040901 john Male kkkk@ee.net 1
20040902 mary famale kkk@fff.net 2
bounsNo | bounsLevel | bouns
1 优秀 $1000
2 良 $600
表中bounsNo作为主键
一般符合第三范式的关系数据库能够避免数据冗余的情况。
本文参考了一下几篇博文：
http://blog.csdn.net/sunzhenhua0608/article/details/16850053
http://blog.csdn.net/famousdt/article/details/6921622
学生管理系统：http://www.cnblogs.com/nx520zj/archive/2013/05/29/3105725.html