范式也叫关系范式，因为范式存在于关系中。范式是关系模式满足不同程度的规范化要求的标准。满足最低程度要求的范式属于第一范式，简称1NF；在第一范式中进一步满足一些要求的关系属于第二范式，简称2NF，依次类推，还有3NF、BCNF、4NF、5NF，这些都是关系范式。对关系模式的属性间的函数依赖加以不同的限制就形成了不同的范式。这些范式是递进的，即如果是一个关系是1NF的，它比不是1NF的关系要好；同样，2NF的关系比1NF的关系要好等等，范式越高、规范化程度越高，关系模式就越好。

简介

第一范式

第二范式

第三范式

简介

关系数据库中的关系要满足一定的要求。若关系满足不同程度的要求，就称它属于不同的范式（Normal Form）。

第一范式

定义 设 R 是一个关系模式，如果 R 中的每一个属性 A 的值域中的每个值都是不可分解的，则称 R 是属于第一范式的，记作 R ∈ 1NF。

例如：在关系 SA（姓名，工资）中，属性“工资”还可再分为基本工资，奖金还有补贴 3 个数据项，这违背了第一范式中元组的每个属性不可再分的原则，所以它不满足第一范式。

将非第一范式的关系转换为第一范式的关系非常简单，只需要将所有数据项都分解成不可再分的最小数据项就可以了。例如上面的关系改为 SA（姓名，基本工资，奖金，补贴）即可。

第二范式

定义如果关系 R ∈ 1NF，并且 R 中每一个非主属性完全函数依赖于任一个候选码，则 R ∈ 2NF。

从定义可以看出，若某个 1NF 的关系的主码只由一个列组成，那么这个关系就是 2NF 关系。但是，如果主码是由多个属性列共同组成的复合主码，并且存在非主属性对属性的部分函数依赖，则这个关系不是 2NF 关系。

例如：在关系 SB（学号，姓名，系名，系主任，课号，成绩）中，、

非主属性“姓名”仅函数依赖于“学号”，也就是“姓名”部分函数依赖于主码（学号，课号）而不是完全依赖；

非主属性“系名”仅函数依赖于“学号”，也就是“系名”部分函数依赖于主码（学号，课号）而不是完全依赖；

非主属性“系主任”仅函数依赖于“学号”，也就是“系主任”部分函数依赖于主码（学号，课号）而不是完全依赖。

所以 SB 不满足第二范式，不是 2NF 关系。可以用模式分解的方法将非 2NF 的关系模式分解为多个 2NF 的关系模式。去掉部分函数依赖关系的分解过程如下：

1. 用组成主码的属性集合的每一个子集作为主码构成一个表。

2. 对于每个表，将依赖于此主码的属性放置到此表中。

例如：将 SB 分解为两个关系模式

SC（学号，课号，成绩），主码为（学号，课号）

SD（学号，姓名，系名，系主任），主码为 学号。

第三范式

定义 如果关系 R ∈ 2NF，并且 R 中每一个非主属性对任何候选码都不存在传递函数依赖，则 R ∈ 3NF 。

从定义中可以看出，如果存在非主属性对主码的传递依赖，则相应的关系模式就不是 3NF。

接着上面的例子，关系模式 SC 和 SD 均是 2NF 的，但在关系 SD（学号，姓名，系名，系主任）中，存在如下函数依赖：

学号 → 系名

系名 → 系主任

系名 －\\→ 学号

那么，存在着一个传递函数依赖“学号 → 系主任”成立。

从上面的分析可以知道，因为在 SD 中存在传递函数依赖，所以 SD 不满足 3NF。因此需要对其进行下一步的分解。去掉传递函数依赖的分解过程如下：

1. 对于不是候选码的每个决定因子，从关系模式中删除依赖于该决定因子的属性。

2. 新建一个关系模式，新的关系模式中应包含在原表中所有依赖于该决定因子的属性。

3. 将决定因子作为新关系模式的主码。

例如：将 SD 分解为

SE（学号，姓名，系名）

SF（系名，系主任）

这两个关系模式不再存在传递依赖，它们均为第三范式。在通常的数据库设计中，一般要求要达到 3NF。3NF 是一个实际可用的关系模式应满足的最低范式。