数据库三大范式理解

设计范式（范式,数据库设计范式,数据库的设计范式）是符合某一种级别的关系模式的集合。构造数据库必须遵循一定的规则。在关系数据库中，这种规则就是范式。关系数据库中的关系必须满足一定的要求，即满足不同的范式。目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、第四范式（4NF）、第五范式（5NF）和第六范式（6NF）。满足最低要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多要求的称为第二范式（2NF），其余范式以次类推。一般说来，数据库只需满足第三范式（3NF）就行了。下面我们举例介绍第一范式（1NF）、第二范式（2NF）和第三范式（3NF）。

1 第一范式（1NF）

在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。

所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。简而言之，第一范式就是无重复的列。

2
第二范式（2NF）

第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。（通俗点就是有主键，该记录可以被唯一标识）。简而言之，第二范式就是非主属性完全依赖于主关键字。

3
第三范式（3NF）

满足第三范式（3NF）必须先满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。（通俗点就是表中不能有应该存在其他表的字段）。简而言之，第三范式就是属性不依赖于其它非主属性。

4
例子解析

为了说明方便，我们在本文中将使用一个SAMPLE数据表，来一步一步分析规范化的过程。

首先，我们先来生成一个的最初始的表。

CREATE TABLE "SAMPLE" (
"PRJNUM" INTEGER NOT NULL,
"PRJNAME" VARCHAR(200),
"EMYNUM" INTEGER NOT NULL,
"EMYNAME" VARCHAR(200),
"SALCATEGORY" CHAR(1),
"SALPACKAGE" INTEGER)
IN "USERSPACE1";

ALTER TABLE "SAMPLE"
ADD PRIMARY KEY
("PRJNUM", "EMYNUM");

Insert into SAMPLE(PRJNUM, PRJNAME, EMYNUM, EMYNAME, SALCATEGORY, SALPACKAGE)
values(100001, 'TPMS', 200001, 'Johnson', 'A', 2000), (100001, 'TPMS', 200002,
'Christine', 'B', 3000), (100001, 'TPMS', 200003, 'Kevin', 'C', 4000), (100002,
'TCT', 200001, 'Johnson', 'A', 2000), (100002, 'TCT', 200004, 'Apple', 'B',
3000);

表1-1

Project num	Project name	Employee num	Employee name	Salary category	Salary package
100001	TPMS	200001	Johnson	A	2000
100001	TPMS	200002	Christine	B	3000
100001	TPMS	200003	Kevin	C	4000
100002	TCT	200001	Johnson	A	2000
100002	TCT	200001	Apple	B	3000

考察表1-1，我们可以看到，这张表一共有六个字段，分析每个字段都有重复的值出现，也就是说，存在数据冗余问题。这将潜在地造成数据操作（比如删除、更新等操作）时的异常情况，因此，需要进行规范化。

4.1 检查第一范式

参照范式的定义，考察上表，我们发现，这张表已经满足了第一范式的要求。

1、因为这张表中字段都是单一属性的，不可再分；

2、而且每一行的记录都是没有重复的；

3、存在主属性，而且所有的属性都是依赖于主属性；

4、所有的主属性都已经定义

事实上在当前所有的关系数据库管理系统（DBMS）中，都已经在建表的时候强制满足第一范式。因此，这张SAMPLE表已经是一张满足第一范式要求的表。考察表1-1，我们首先要找出主键。可以看到，属性对<Project Number, Employee Number>是主键，其他所有的属性都依赖于该主键。

4.2 检查第二范式

根据第二范式的定义，转化为二范式就是消除部分依赖。

考察表1-1，我们可以发现，非主属性<Project Name>部分依赖于主键中的<Project Number>; 非主属性<Employee Name>，<Salary Category>和<Salary package>都部分依赖于主键中的<Employee Number>；

表1-1的形式，存在着以下潜在问题：

1． 数据冗余：每一个字段都有值重复；

2． 更新异常：比如<Project Name>字段的值，比如对值"TPMS"了修改，那么就要一次更新该字段的多个值；

3． 插入异常：如果新建了一个Project，名字为TPT, 但是还没有Employee加入，那么<Employee Number>将会空缺，而该字段是主键的一部分，因此将无法插入记录；

Insert into SAMPLE(PRJNUM, PRJNAME, EMYNUM, EMYNAME, SALCATEGORY, SALPACKAGE) values(100003, 'TPT', NULL, NULL, NULL, NULL)

4． 删除异常：如果一个员工 200003, Kevin 离职了，要将该员工的记录从表中删除，而此时相关的Salary信息 C 也将丢失, 因为再没有别的行纪录下 Salary C的信息。

Delete from sample where EMYNUM = 200003Select distinct SALCATEGORY, SALPACKAGE from SAMPLE

因此，我们需要将存在部分依赖关系的主属性和非主属性从满足第一范式的表中分离出来，形成一张新的表，而新表和旧表之间是一对多的关系。由此，我们得到：

CREATE TABLE "PROJECT" (
"PRJNUM" INTEGER NOT NULL,
"PRJNAME" VARCHAR(200))
IN "USERSPACE1";

ALTER TABLE "PROJECT"
ADD PRIMARY KEY
("PRJNUM");

Insert into PROJECT(PRJNUM, PRJNAME) values(100001, 'TPMS'), (100002, 'TCT');

表1-2

Project num	Project name
100001	TMPS
100001	TCT

CREATE TABLE "EMPLOYEE" (
"EMYNUM" INTEGER NOT NULL,
"EMYNAME" VARCHAR(200),
"SALCATEGORY" CHAR(1),
"SALPACKAGE" INTEGER)
IN "USERSPACE1";

ALTER TABLE "EMPLOYEE"
ADD PRIMARY KEY
("EMYNUM");

Insert into EMPLOYEE(EMYNUM, EMYNAME, SALCATEGORY, SALPACKAGE) values(200001,
'Johnson', 'A', 2000), (200002, 'Christine', 'B', 3000), (200003, 'Kevin', 'C',
4000), (200004, 'Apple', 'B', 3000);

Employee Number	Employee Name	Salary Category	Salary Package
200001	Johnson	A	2000
200002	Christine	B	3000
200003	Kevin	C	4000

表1-3

Employee Number	Employee Name	Salary Category	Salary Package
200001	Johnson	A	2000
200002	Christine	B	3000
200003	Kevin	C	4000

同时，我们把表1-1的主键，也就是表1-2和表1-3的各自的主键提取出来，单独形成一张表，来表明表1-2和表1-3之间的关联关系：

CREATE TABLE "PRJ_EMY" (
"PRJNUM" INTEGER NOT NULL,
"EMYNUM" INTEGER NOT NULL)
IN "USERSPACE1";

ALTER TABLE "PRJ_EMY"
ADD PRIMARY KEY
("PRJNUM", "EMYNUM");

Insert into PRJ_EMY(PRJNUM, EMYNUM) values(100001, 200001), (100001, 200002),
(100001, 200003), (100002, 200001), (100002, 200004);

表1-4

Project Number	Employee Number
100001	200001
100001	200002
100001	2000013
100002	200001
100002	200004

这时候我们仔细观察一下表1-2, 1-3, 1-4, 我们发现插入异常已经不存在了，当我们引入一个新的项目 TPT 的时候，我们只需要向表1-2 中插入一条数据就可以了， 当有新人加入项目 TPT 的时候，我们需要向表1-3, 1-4 中各插入一条数据就可以了。虽然我们解决了一个大问题，但是仔细观察我们还是发现有问题存在。

4.3 检查第三范式

考察表前面生成的三张表，我们发现，表1-3存在传递依赖关系，即：关键字段< Employee Number > --> 非关键字段< Salary Category > -->非关键字段< Salary Package >。而这是不满足三范式的规则的，存在以下的不足：

1、 数据冗余：<Salary Category>和<Salary Package>的值有重复；

2、 更新异常：有重复的冗余信息，修改时需要同时修改多条记录，否则会出现数据不一致的情况；

3、 删除异常：同样的，如果员工 200003 Kevin 离开了公司，会直接导致 Salary C 的信息的丢失。

Delete from EMPLOYEE where EMYNUM = 200003

Select distinct SALCATEGORY, SALPACKAGE from EMPLOYEE

因此，我们需要继续进行规范化的过程，把表1-3拆开，我们得到：

表1-5

Employee Number	Employee Name	Salary Category
200001	Johnson	A
200002	Christine	B
200003	Kevin	C
200004	Apple	D

和

表1-6

Salary Category	Salary Package
A	2000
B	3000

这时候如果 200003 Kevin 离开公司，我们只需要从表 1-5 中删除他就可以了， 存在于表1-6中的Salary C信息并不会丢失。但是我们要注意到除了表 1-5 中存在 Kevin 的信息之外， 表1-4中也存在 Kevin 的信息， 这很容易理解， 因为 Kevin 参与了项目 100001， TPMS， 所以当然也要从中删除。

至此，我们将表1-1经过规范化步骤，得到四张表，满足了三范式的约束要求，数据冗余、更新异常、插入异常和删除异常。

在三范式之上，还存在着更为严格约束的BC范式和四范式，但是这两种形式在商业应用中很少用到，在绝大多数情况下，三范式已经满足了数据库表规范化的要求，有效地解决了数据冗余和维护操作的异常问题。

总结

在本文描述的过程中，我们通过结合实例的方法，通俗地演绎了数据表规范化的过程，并展示了在此过程中数据冗余、数据库操作异常等问题是如何得到解决的。

在具体的工程应用中，运用数据库规范化的方法来设计数据库表，将是具有现实意义的。

（参考地址：http://www.ibm.com/developerworks/cn/data/library/techarticles/dm-0605jiangt/）