第一范式 第二范式 第三范式 BCNF范式

范式是符合某一种级别的关系模式的集合。关系数据库中的关系必须满足一定的要求，满足不同程度要求的为不同范式。

不同范式之间的包含关系为：

第一范式（1NF）

数据库表中的字段都是单一属性，不可再分的。本质上所有关系都满足第一范式

例子：

录入学生信息表：【学生】（姓名，学号，性别，住址）在实际注册信息登记时，经常会有家庭住址和现住址，那么这种表结构设计是不符合1NF的。要达到满足1NF的设计，就需要把住址拆分为两列，即：【学生】（姓名，学号，性别，家庭住址，现住址）。

第二范式（2NF）

首先满足1NF，所有非主属性必须依赖于整个主码而不能依赖于主码的部分属性。

例子：

考虑学生成绩表：【成绩表】（学号，姓名，性别，课程，课程编号，课程学分，分数）在实际生活中，是可能出现重名的情况，所以姓名不能作为主键。由于学号的唯一性，所以学号是可以作为主键的。而一个学生修读多门课程，每一门课程对应一个分数，仅仅一个学号是不足于获得完整成绩表的。显而易见，要获得整个成绩表，还需要课程。那么学号只能算是主键的一部分，主键应该是（学号，课程）。其中，只有成绩这一列是完全依赖取决于主键（学号，课程），姓名和性别只依赖于学号，而课程编号和课程学分只依赖于课程。所以这个学生成绩表是不符合2NF的设计结构的。不符合2NF的设计结构会产生冗余数据。可以将表拆分为三个表：【成绩表】（学号，课程，成绩），【学生】（姓名，性别），【课程信息】（课程编号，课程学分）以达到消除冗余重复数据的目的。

第三范式

首先是2NF，另外非主键列必须直接依赖于主键，不能存在传递依赖，非主键属性之间无依赖关系。（即不能存在：非主键列A依赖于非主键列B，非主键列B依赖于主键的情况）

例子：

学生信息表：【学生】（学号，姓名，性别，电话，住址）主键是（学号），其它非主键（姓名，性别，电话，住址）完全依赖于主键（学号），那么首先这个表是符合2NF的。但是，这些非主键（性别，电话，住址）直接依赖的是非主键（姓名），通过传递依赖才依赖的主键（学号），是不符合3NF的结构设计的。拆分表为【学生】（学号，姓名）和【学生信息】（姓名，性别，电话，住址）满足3NF设计要求。

BCNF

数据库表中不存在任何字段对任一候选关键字段的传递函数依赖。

例子：

假设仓库管理关系表为StorehouseManage(仓库ID, 存储物品ID, 管理员ID, 数量)，且有一个管理员只在一个仓库工作；一个仓库可以存储多种物品。

这个数据库表中存在如下决定关系：

(仓库ID, 存储物品ID) →(管理员ID,

数量)

(管理员ID, 存储物品ID) → (仓库ID,

数量)

我们可以知道(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是StorehouseManage的候选关键字，表中的唯一非关键字段为数量，它是符合第三范式的。但是，由于存在如下决定关系：

(仓库ID) → (管理员ID)

(管理员ID) → (仓库ID)

即存在关键字段决定关键字段的情况，所以其不符合BCNF范式。