为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库，必须满足一定的范式。
<aside> 💡 范式当然不是强制的。
</aside>
第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值，就说明该数据库表满足了第一范式。简单的讲第一范式就是每一行的各个数据都是不可分割的，同一列中不能有多个值，如果出现重复的属性就需要定义一个新的实体。
示例：假设一家公司要存储其员工的姓名和联系方式。它创建一个如下表：
两名员工（Jon＆Lester）拥有两个手机号码，因此公司将他们存储在同一表格中，如上表所示。那么该表不符合 1NF ，因为规则说“表的每个属性必须具有原子（单个）值”，Jon＆Lester 员工的 emp_mobile 值违反了该规则。为了使表符合 1NF ，我们应该有如下表数据：
第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。
+----------+-------------+-------+
| employee | department | head |
+----------+-------------+-------+
| Jones | Accountint | Jones |
| Smith | Engineering | Smith |
| Brown | Accounting | Jones |
| Green | Engineering | Smith |
+----------+-------------+-------+
上表描述了被雇佣者，工作部门和领导的关系。我们把能够唯一表示数据库中表的一行的数据成为这个表的主键。表中 head 列不和主键相关。 因此，该表是不符合第二范式的，为了使上面的表符合第二范式，需要将它拆分为两个表：
-- employee 为主键
+----------+-------------+
| employee | department |
+----------+-------------+
| Brown | Accounting |
| Green | Engineering |
| Jones | Accounting |
| Smith | Engineering |
+----------+-------------+
-- department 为主键
+-------------+-------+
| department | head |
+-------------+-------+
| Accounting | Jones |
| Engineering | Smith |
+-------------+-------+
满足 2NF 的前提下，非主键外的所有字段必须互不依赖，即需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。
简而言之，第三范式（3NF）要求一个关系中不包含已在其它关系已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。