为了建立数据冗余小，没有数据异常（更新、删除、插入）的数据库。设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库，必须满足一定的范式。
设计数据库的时候遵循下面三个范式基本就能满足业务需要。
第一范式（1NF）：数据库表中的所有字段都是单一属性，不可再分。
解释：第一范式要求数据库中的表都是二维表。一般情况下，关系型数据库是只能设计出二维表的。
例如，下面这张就是违反第一范式的表。因为它的“用户信息”字段可以再拆分。
用户信息表
| 用户ID | 帐号 | 密码 | 用户信息 | |
| 1 | zhangsan | ****** | 姓名 | 手机 |
| 张三 | 13588888888 | |||
将“用户信息”字段拆分后的表。
用户信息表
| 用户ID | 帐号 | 密码 | 姓名 | 手机 | ||||
| 1 | zhangsan | ****** | 张三 | 13588888888 | ||||
第二范式（2NF）：数据库的表中不存在非关键字段对任一候选关键字段的部分函数依赖。
解释：部分函数依赖是指存在着组合关键字段的某一个关键字段决定非关键字段的情况。只要确保表中的每个字段都和关键字段相关就符合第二范式。
例如，下面这张就是违反第二范式的表。
社团加入信息表
| 学生 | 社团 | 加入时间 | 社团简介 | 性别 |
| 张三 | 动漫社 | 2015.9.30 | 动漫迷的聚集地 | 男 |
| 周玉 | 动漫社 | 2015.9.29 | 动漫迷的聚集地 | 女 |
学生与社团的关系是，一个学生可以加入多个社团，一个社团也可以拥有多个学生，即的，多对多关系。
“学生”字段与“社团”字段组合在一起，才能决定“加入时间”字段。所以这是一张组合关键字段（“学生”，“社团”）的表。
但是“学生”决定了“性别”，“社团”决定了“社团简介”，所以存在组合关键字段的某个关键字段决定非关键字段的情况。
违反第二范式的表存在的问题：
1、插入异常
如果没有任何人加入动漫社，那么是不是意味着，动漫社的简介是不存在的。
2、删除异常
如果把动漫社的同学都删除掉，是不是意味着，动漫社的简介是不存在的。
3、更新异常
如果要更新动漫社的简介，是不是要更新多条记录。
4、数据冗余
很明显，动漫社的简介存在多条简介信息。
下面是按第二范式拆分后的表。
学生表
| 学生 | 性别 |
| 张三 | 男 |
| 周玉 | 女 |
社团表
| 社团 | 社团简介 |
| 动漫社 | 动漫迷的聚集地 |
学生与社团关系表
| 学生 | 社团 | 加入时间 |
| 张三 | 动漫社 | 2015.9.30 |
| 周玉 | 动漫社 | 2015.9.29 |
第三范式（3NF）： 数据库的表中不存在非关键字段对任意候选关键字段的传递函数依赖。
解释：传递函数依赖是指候选关键字段间接决定非关键字段。
例如，下面这张就是违反第三范式的表。
商品信息表
| 商品名称 | 分类 | 分类描述 |
| 狼皮大衣 | 外套 | 一种可以装x的衣服。 |
“商品名称”决定了“分类”，然而“分类”又决定了“分类描述”。所以，存在非关键字段“分类描述”对候选关键字段“商品名称”的传递函数依赖。
即：“商品名称” ---> “分类” ---> “分类描述”
“分类描述”间接与“商品名称”相关。
商品信息表
| 商品名称 | 分类 | 分类描述 |
| 狼皮大衣 | 外套 | 一种可以装x的衣服。 |
下面是按第三范式拆分后的表。
分类信息表
| 分类 | 分类描述 |
| 外套 | 一种可以装x的衣服。 |
商品信息表
| 商品名称 | 分类 |
| 狼皮大衣 | 外套 |