第一范式（1NF）
第一范式是第二和第三范式的基础，是最基本的范式。第一范式包括下列的指导原则：
- 数据组的每个属性只可以包含一个值。
- 关系中的每个数组必须只包含相同数量的值。
- 关系中的每个数组一定不能相同。
在任何一个关系数据库中，第一范式是对关系模式的基本要求，不满足第一范式的数据库就不是关系型数据库。
表1.1 不符合第一范式的学生信息表
|
学号 |
姓名 |
性别 |
年龄 |
班级 |
|
9527 |
东*方 |
男 |
20 |
计算机系3班 |
因为上表中的班级属性中包含了多个值，所以它不符合第一范式。改进后的结构如下表所示：
表1.2 符合第一范式的学生信息表
|
学号 |
姓名 |
性别 |
年龄 |
系别 |
班级 |
|
9527 |
东*方 |
男 |
20 |
计算机 |
3班 |
第二范式（2NF）
第二范式是第一范式的基础上建立起来的，即满足第二范式必先满足第一范式。第二范式要求数据库中的每个实体（即各个记录行）必须可以被唯一地区分。要求实体的属性完全依赖于主关键字，即不能存在仅依赖主关键字一部分的属性。
不符合第二范式的示范（员工工资表）：
（员工编号，岗位）-》（决定）(姓名、年龄、学历、基本工资、绩效工资、资金)
不符合的原因是，在上面的关系中，还可以进一步拆分为如下两种决定关系：
（员工编号）-》（决定）（姓名、年龄、学历）
（岗位）-》（决定）（基本工资）
符合第二范式的示范（将上面的表拆分为三张表）：
员工档案表：EMPLOYEE（员工编号、姓名、年龄、学历）
岗位工资表：QUARTERS（岗位、基本工资）
员工工资表：PAY（员工编号、岗位、绩效工资、奖金）
第三范式（3NF）
第三范式是在第二范式的基础上建立起来的，即满足第三范式必先满足第二范式。第三范式要求关系表不存在非关键字列对任意候选关键字列的传递函数依赖，也就是说，第三范式要求一个关系表中不包含已在其他表中已包含的非主关键字信息。
示范：
（员工编号）-》（决定）（员工姓名、年龄、部门编号、部门经理）
上面的这个关系是符合第二范式的，但它不符合第三范式，因为该关系表内部隐含着如下决定关系：
（员工编号）->（决定）（部门编号）-》（决定）（部门经理）
上面的关系表存在非关键字段“部门经理”对关键字“员工编号”的传递函数依赖。
更改为符合第三范式关系：
员工信息表：EMPLOYEE（员工编号、员工姓名、年龄、部门编号）
部门信息表：DEPARTMENT（部门编号、部门经理）
对于关系数据库的设计，理想的设计目标是按照“规范化”原则存储数据，因为这样做能够消除数据冗余、更新异常、插入异常和删除异常。