规范化－数据库设计原则

表1-1

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

第一范式

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

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

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

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

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

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

从一范式转化到二范式

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

考察表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 = 200003
Select 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

表 1-3

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
200004    Apple    B    3000
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-1的主键，也就是表1-2和表1-3的各自的主键提取出来，单独形成一张表，来表明表1-2和表1-3之间的关联关系：

表 1-4

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

从二范式转化到三范式

考察表前面生成的三张表，我们发现，表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

和

表 1-6

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

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

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

结束语

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

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

参考资料

• Database Normalization Basics：数据库规范化基础原则
• Normalization principles：数据库规范化原则和范式定义

 转自：http://www.ibm.com/developerworks/cn/data/library/techarticles/dm-0605jiangt/

规范化－数据库设计原则

标签：