引言
关系数据库中的关系必须满足一定的要求。满足不同程度要求的为不同范式。数据库的设计范式是数据库设计所需要满足的规范。只有理解数据库的设计范式，才能设计出高效率、优雅的数据库，否则可能会设计出糟糕的数据库。
数据库范式的种类
数据库的范式主要有六种：（由低到高）
-
第一范式
-
第二范式
-
第三范式
-
BC范式
-
第四范式
-
第五范式。
数据库设计满足最低要求的叫第一范式，简称 1NF。在第一范式基础上进一步满足一些要求的为第二范式，简称 2NF。在第二范式基础上进一步满足一些要求的为第三范式，简称 3NF。其余依此类推。
数据库范式的理解
数据库设计是否满足越高范式就越好？
当然不是。满足更高范式虽然可以更好的避免数据冗余，减少数据库的占用的存储空间，减轻维护数据完整性的麻烦，但是会产生更多的小表，导致操作困难，因为需要关联查询多个小表才能得到所需要数据，而且范式越高性能就会越差。
数据库设计的三大范式
在实际项目开发中，要权衡是否使用更高范式是比较麻烦的事情，数据库设计一般用得最多的也就是三大范式，因为使用第一、第二和第三范式也就足够了，不仅性能好而且方便操作和管理数据。
第一范式(1NF)
如果一个关系表中的每一个字段都是原子项，也就是不可分割，那么该表就满足第一范式
第一范式是关系表应具备的最起码的条件，如果数据库设计不能满足第一范式，就不称为关系型数据库。
例如 (学生信息表)：
| 学生编号 | 姓名 | 性别 | 联系方式 |
|---|---|---|---|
| 20080901 | 张三 | 男 | email:zs@126.com,phone:13541220018 |
| 20080902 | 李四 | 女 | email:ls@126.com,phone:1373081235 |
以上表就不符合第一范式（1NF），原因是联系方式这个字段可以再分。
正确如下：
| 学生编号 | 姓名 | 性别 | 电子邮件 | 电话 |
|---|---|---|---|---|
| 20080901 | 张三 | 男 | zs@126.com | 13541220018 |
| 20080902 | 李四 | 女 | ls@126.com | 13730812350 |
第二范式（2NF）
如果一个关系表中每个非主键字段都完全依赖于主键，而没有部分依赖于主键，那么该表就满足第二范式。
这里完全依赖是啥意思，意思就是每个非主键字段是由整个主键决定的，而不能由主键的一部分来决定。这里所谓的主键一部分指的是复合主键，就是主键是由多个字段组成的，共同定义一行数据的唯一性。比较常见的复合主键就是多对多关联表时，中间表（也叫连接表）就是采用的复合主键。
例如(学生选课表):
| 学生 | 课程 | 教师 | 教师职称 | 教材 | 教室 | 上课时间 |
|---|---|---|---|---|---|---|
| 张三 | MyBatis | 张老师 | 大数据讲师 | 《MyBatis深入浅出》 | 207 | 09:30 |
| 李四 | Hibernate | 李老师 | 大数据讲师 | 《Hibernate 深入浅出》 | 208 | 09:30 |
这里通过（学生，课程）两个字段可以确定教师、教师职称，教材，教室和上课时间，所以可以把（学生，课程）这两个字段作为复合主键。但是，教材并不完全依赖于（学生，课程），只拿出课程就可以确定教材，因为一个课程，一定指定了某个教材。
这就叫不完全依赖，或者部分依赖。出现这种情况，就不满足第二范式（2NF）。
正确如下：
- 选课表：
| 学生 | 课程 | 教师 | 教师职称 | 教室 | 上课时间 |
|---|---|---|---|---|---|
| 张三 | MyBatis | 张老师 | 大数据讲师 | 207 | 09:30 |
| 李四 | Hibernate | 李老师 | 大数据讲师 | 208 | 09:30 |
- 课程表：
| 课程 | 教材 |
|---|---|
| MyBatis | 《MyBatis深入浅出》 |
| Hibernate | 《Hibernate深入浅出》 |
所以，第二范式可以说是消除部分依赖。第二范式可以减少插入异常，删除异常和修改异常。
第三范式（3NF）
如果一个关系表中，非主主键字段之间不存在传递依赖，那么这样就满足第三范式。
选课表：
| 学生 | 课程 | 教师 | 教师职称 | 教室 | 上课时间 |
|---|---|---|---|---|---|
| 张三 | MyBatis | 张老师 | 大数据讲师 | 207 | 09:30 |
| 李四 | Hibernate | 李老师 | 大数据讲师 | 208 | 09:30 |
第二范式修改后的选课表中，一个教师能确定一个教师职称。这里，虽然教师依赖于（学生，课程），但教师职称仅依赖于教师，并不直接依赖于（学生，课程），这就叫传递依赖，第三范式就是要消除传递依赖。
正确如下：
- 选课表：
| 学生 | 课程 | 教师 | 教室 | 上课时间 |
|---|---|---|---|---|
| 张三 | MyBatis | 张老师 | 207 | 09:30 |
| 李四 | Hibernate | 李老师 | 208 | 09:30 |
- 教师表：
| 教师 | 教师职称 |
|---|---|
| 张老师 | 大数据讲师 |
| 李老师 | 大数据讲师 |
这样，新教师的职称在没被选课的时候也有地方存了，没人选这个教师的课的时候教师的职称也不至于被删除，修改教师职称时只修改教师表就可以了。
总结
数据库设计并非遵循越高范式越好，实际项目开发需要权衡，一般遵循三大范式：
-
第一范式就是原子性（字段不可再分割）
-
第二范式就是完全依赖（没有部分依赖）
-
第三范式就是没有传递依赖