浅谈数据库设计中范式的应用

2011-10-31邹琼

湖北经济学院学报·人文社科版 2011年11期

关键词：主键字段姓名

邹琼

（湖北经济学院信息管理学院，湖北武汉 430205）

浅谈数据库设计中范式的应用

邹琼

（湖北经济学院信息管理学院，湖北武汉 430205）

非计算机专业的数据库理论的教学是个难点，文章针对“范式”概念的理解结合笔者在教学实践中的实验案例，对数据库设计中的数据模式的规范化进行了详细阐述。并对常用的三大范式和反范式的一些应用进行了探讨。

数据库设计；范式；关系规范化

随着信息化时代的到来，数据库技术被广泛地应用于经济建设、科学研究、组织管理的各个领域和我们生活的各个方面，学习和掌握一定的数据库知识变得尤为重要，为此许多高等院校都为非计算机专业的学生开设了《数据库原理》公共课程。但是许多学生对数据库的基本理论知识的掌握存在困难，特别是数据库设计中的范式的定义与作用，普遍觉得难以理解。下面就针对这个知识点结合笔者多年的教学实践中的一些教学案例来进行说明。

一、范式概述

在整个数据库的开发过程中，数据库的设计的好坏是一个数据库成败与否的关键；而对于占主流地位的关系数据库的设计而言，如何构造一个适合该系统的数据模式，如何确定每个关系模式或者直接说确定每张表的属性字段等就直接影响到未来该系统的运行效率。这里我们就需要一个数据库设计的有力工具——规范化理论。关系数据库规范化理论是E. F.Godd在1971年提出的，它按照属性间的不同依赖程度分为第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、Boyce-Codd范式、第四范式（4NF）和第五范式（5NF）等。这些范式其实就是一些确定关系模式的规则，而且这些规则是按层次递进分等级的，每一级都是在下一级的基础上制定的更严格的规则，即满足最低要求的范式是第一范式（1NF），在第一范式的基础上进一步满足更多要求的是第二范式（2NF），以此类推。实际上在一般的系统设计中，通常只需要规范到3NF的层次就足够了。满足3NF规则的数据库结构明晰的，可以避免发生插入、删除和更新操作异常，最大限度降低数据库的冗余度，提高了数据库的通用性和安全性。

二、范式的理解与应用

（一）第一范式（1NF）

第一范式是关系数据库中的关系要满足的最低要求，它要求每一个关系或表中的每一个字段分量都是不可再分的数据项，简而言之，第一范式就是无重复的列。我们以常见的教学管理系统数据库中的信息为例，以下表1是一张记录学生基本信息以及选课情况的表。这是我们手工制表中经常出现的形式，但是很明显表中的选修课程字段存在大量重复的字段信息，它不满足第一范式的要求，列中出现子列的形式根本不属于关系模型，是不可能导入到任意一个关系型的数据库管理系统DBMS中的。所以我们应该对它进行规范和细分。

我们可以通过把重复的字段放到一个独立的表中，把这些表通过一对多关联联系起来的这种方式来消除表中的重复字段。这里我们可以将选修课程字段从学生表中拿出，单独放置到选课表中，而选课表包含学号，课程编号和课程名称字段。这样每一条记录就能表达一个学生所选的一门课程，同一个学生所选的不同课程就会产生另一条学号相同，课程名称不同的记录。而且这张表通过学号字段就能与原来的学生表关联起来。这样消除了重复的选修课程字段后表就属于1NF。

（二）第二范式（2NF）

第一范式是关系数据库中的表要满足的最低要求，而仅仅满足这个最低要求的表极有可能出现一些异常，我们还是来看这样一张记录选修课程情况的表，表中包含字段有：学号、姓名、课程编号、课程名称、学分、成绩。看起来这张表中的数据十分完备，而且表中没有重复字段，已经是1NF了。可是进一步分析我们却能发现其中问题多多：每当有一位同学选修了一门新的课程时，该同学的姓名就不得不随着新记录的插入而被重复存储一次，学生们选修的课程越多意味着姓名重复越多。同时课程名称和学分字段也是如此，一门课程被选修的次数越多，意味着该课程的课程名称与学分字段也必须得重复存储越多，这就是典型的数据冗余。重复的冗余数据进而会引发数据的更新异常。因为一旦需要修改某个姓名或课程名称、学分等所涉及到的修改就不止一条记录，重复的越多意味着出错的可能性越大。而且由于课程名称和学分字段仅存于这张表中，若有新开的课程要记录就会因为还没有选修该课程的学生而无法存入该表，这就带来了插入异常。同样的道理，如果出于某些原因如转学等将某个学生的选课记录删除，那么如果只有该生选修了某门课程的话，这门课程的信息也将随着该记录的删除而彻底丢失，这也就是发生了删除异常的情况。

这些异常情况的发生实际上都是因为表中的字段存在部分依赖的情况。所谓部分依赖就是指表中的非主键字段，并不是完全依赖于主键而确定，而仅仅是由主键的一部分来确定。我们知道主键是能够确定每一条记录的标识字段，也就是一个主键值对应一条记录。对于单一字段的主键，是不可能出现部分依赖的情况的，而对于多字段构成的联合主键则不然。如果表中某个字段仅由联合主键中的某一个字段就能确定的话，我们就称之为发生了部分依赖。在这张选修课程记录表中，很明显主键是由学号和课程编号两个字段联合担当，也就是说每一条记录的学号与课程编号的组合都是互不相同的唯一的。但是其中姓名字段仅只依赖于学号就可以确定；课程名称和学分字段也是非主键字段，但它们也仅仅只依赖于主键的一部分——课程编号字段就能确定。

正是由于这些部分依赖的存在引发了各种异常情况，所以我们必须通过进一步规范化的手段消除这些部分依赖。我们可以通过分解原表，使得每一张表都成为2NF。将姓名字段归并到一张学生表中，与原表靠学号字段关联；将课程名称和学分字段也单独成立一张课程表依靠课程编号字段关联，分解后的3张表中的字段如下：学生表（学号、姓名、性别、出生日期等）；课程表（课程编号、课程名称、学分）；选课表（学号、课程编号、成绩）。当我们消除了表中的部分依赖后，我们就可以说我们的表已经是2NF了。因此所谓第二范式就是要消除表中的部分依赖，同时我们也就清楚了如果表中的主键是单一字段的话那么就一定是2NF，因为只有联合主键才可能出现违反2NF的部分依赖。

（三）第三范式（3NF）

第三范式是在第二范式的基础上加上了更严格的限制条件：表中非主键字段不能传递依赖与主键。我们来看这样一张记录学生基本信息的表，表中字段有：学号，姓名，性别，出生日期、专业、所属院系。我们可以很直观的判断出这是一个2NF，因为表的主键是单一字段学号，表中其他的非主键字段如姓名、出生日期、专业、院系都完全依赖于学号，不可能出现部分依赖。可是该表仍有明显的问题，那就是学号能够唯一确定专业，可是专业也能够唯一确定院系，也就是说出现了传递依赖的情况。当存储学生信息时，同一个专业的学生所属院系将会被重复存储，这便带来了数据冗余。所以表7没有达第三范式的要求，不是3NF。

为了使该表成为3NF，我们同样要对表进行规范化的重新设计，我们将专业与院系的字段从学生表中移除，使其单独成为一张院系表，并且通过专业编号进行关联，这样的两张表消除了传递依赖关系，就都是第三范式了。

经过3个范式的层层规范，现在的数据模式已经得到了极大程度的优化，通过这几张表之间适当的连接查询，我们既可以得到所需的数据，同时又避免了数据冗余和各种异常。

三、反范式的应用

规范化的优点是明显的，它避免了大量的数据冗余，节省了存储空间，保持了数据的一致性。当一个库里的数据经常发生变化时，达到3NF的库可以使用户不必在超过两个以上的地方更改同一个值。那么是不是只要把所有的表都规范为3NF后，数据库的设计就是最优的呢？这可不一定。范式越高意味着表的划分更细，一个数据库中需要的表也就越多，用户不得不将原本相关联的数据分摊到多个表中。当用户同时需要这些数据时只能采用连接表的形式将数据重新合并在一起。同时把多个表联接在一起的花费是巨大的，尤其是当需要连接的两张或者多张表数据非常庞大的时候，表连接操作几乎是一个噩梦，这严重地降低了系统运行性能。

所以有时为了提高数据库的性能，需要适当牺牲规范化的要求，采取所谓反范式的设计，即不完全按照范式的理论来设计数据表结构。比如在上面的数据库中学生的姓名是很少变化的，而选课表中由于保存的数据非常多，而且最终提取学生成绩时常常是需要姓名信息的，那么为了避免数据库系统实际运行时为获取姓名频繁地联接学生表，我们就干脆违反2NF将姓名字段重复的存储在选课表中。还有一种情况就是当表中数据量很大，而数据的紧要程度又不完全相同的时候，我们也可以违反范式的无重复原则，把一张完整的表分成多张子表来分表存储。比如我们可以用水平分割表的方法将表中的历史陈旧数据分割到另一张表中进行静态存储，这样可以加快表的查找速度。但同时反范式也会引入相应的更新删除等额外操作和程序设计的复杂性，因此在实际应用中应按实际需求适当使用。