对数据库范式的分析与应用

李小莲

摘要：文章首先介绍了关系、关系模式、函数依赖等相关概念，然后针对关系数据库的第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、第四范式（4NF）以及BCNF范式做了详细分析，使用简明清晰的方法帮助大家理解范式的定义，并且通过实例來说明各范式需要满足的函数依赖关系。

关键词：函数依赖；关系；数据库；范式

中图分类号：TP393 文献标识码：A 文章编号：1009-3044（2018）08-0007-02

数据库有关系型数据库和非关系型数据库，现在应用广泛的流行的数据库就是关系型数据库。关系型数据库是建立在关系模型的基础上的，所以我们首先需要了解关系、关系模式以及关系模式里属性间的函数依赖关系。

关系用来表示现实世界的实体以及实体间的各种联系，它的逻辑结构其实就是一张二维表。在关系模式R（U，F）中R是关系名，U为一组属性，F为属性组U上的一组数据依赖。数据依赖是一个关系内部属性与属性之间的一种约束关系。数据依赖主要有两种类型：函数依赖（FD）和多值依赖（MVD）。那到底什么是函数依赖呢？它是这么定义的：设R（U）是一个属性集U上的关系模式，X和Y是U的子集。若对于R（U）的任意一个可能的关系r，r中不可能存在两个元组在X上的属性值相等，而在Y上的属性值不等，则称“X函数确定Y”或“Y函数依赖于X”，记作X→Y。举个实际例子：教师信息表（员工编号，姓名，所在系别，教龄），其中X代表属性集（员工编号），它只有一个属性。Y代表属性集（姓名，所在系别，教龄）。当X的属性值相等时，Y值也是相等的，即若员工编号相同，则其他属性“姓名，所在系别，教龄”也都一定相同。故称此关系模式中x函数确定Y，X→Y，也就是：员工编号一姓名，所在系别，教龄。

1各范式概念剖析及实例分析

关系数据库一共有六种，按属性间依赖关系可以分为第一范式、第二范式、第三范式、BCNF范式、第四范式、第五范式。要想设计出好的数据库，需要遵循规范化理论，使数据库一步一步达到所需规范化的要求。本文主要剖析前面五种范式的相关概念，捋清各范式要求的属性间的依赖关系并结合实际的应用例子来说明。

1.1第一范式（1NF）

第一范式要求数据库表中的属性不可再分，这是关系数据库必须满足的条件。在平时的工作中，常常会见到如下表（表1）中这样的数据表。客户有一个手机号，还有一个办公电话，但放到数据库设计中，这就不满足第一范式，数据项“联系方式”这一项有两个数据项。要使其满足第一范式则应将联系方式分解为“手机”和“公司电话”两个数据项。

1.2第二范式（2NF）

第二范式的定义：若关系模式R∈1NF，并且每一个非主属性都完全函数依赖于任何一个候选码，则RE2NF。请注意这里的依赖关系是完全函数依赖，是不允许部分函数依赖，但是传递函数依赖是可以存在的。下面分情况讨论：

1.2.1关系模式中不存在组合候选键

关系模式中不存在组合候选键，即每个候选键只有一个属性，这时每个非主属性都完全函数依赖任何一个码。

例：关系模式用户表（用户号，身份证号，姓名，年龄，家庭住址，家庭成员数）。其中用户号，身份证号都能唯一标识用户，都是此数据库表的候选键，故两个属性也都是主属性，其他非主属性都完全函数依赖主属性用户号和身份证号。即

1）用户号→姓名，年龄，家庭住址，家庭成员数；

2）身份证号→姓名，年龄，家庭住址，家庭成员数。

故此数据库表满足第二范式。显然，只含单关键字的码的数据库表一定是满足第二范式的。

1.2.2关系模式表中有组合键作为候选键

下面给出两个成绩关系模式表来对照分析：

例：成绩表1（学号，课程号，成绩，）。其中（学号，课程号）为组合候选码，非主属性“成绩”完全函数依赖候选码（学号，课程号），即（学号，课程号）→成绩，此数据库表满足第二范式。

成绩表2（学号，姓名，课程号，成绩）。其中（学号，课程号）为组合候选键，存在如下决定关系：

1）（学号，课程号）→姓名、成绩

2）学号→姓名

可以看到非主属性“姓名”不完全函数依赖于候选键（学号，课程号），而是部分函数依赖候选键（学号，课程号），故此关系表不满足第二范式。如果要使其满足第二范式，则需要把上表（成绩表2）拆分为两张表：学生表（学号，姓名）和成绩表（学号，课程号，成绩），从而消除非主属性“姓名”对候选键的部分函数依赖。所以，第二范式其实就是需要消除表中非主属性对候选键的部分函数依赖。

1.3第三范式（3NF）

例：关系模式商户信息表（商户编号，姓名，年龄，商户单位，单位电话，单位地址），存在下列依赖关系：

1）商户编号→商户单位

2）商户单位→单位电话，单位地址

3）商户编号→单位电话，单位地址

即存在非主属性“单位电话”、“单位地址”对候选码“商户编号”的传递函数依赖，所以上面商户信息表不满足第三范式。要使其满足第三范式，必须对表进行拆分。对原关系表进行规范化，将上表拆分为商户信息表（商户编号，姓名，年龄）和商户单位信息表（商户单位，单位电话，单位地址）。拆分后的两个表都不存在非主属性对码的传递函数依赖，都满足第三范式。

1.4 BCNF范式

例：某连锁超市有多个商店，一个商店有多名职工，一名职工只在一个商店工作，每个商店有多种商品，每个员工负责销售几种商品，同一种商品可以存放在不同的商店。设有下列关系模式（商店编号，商品编号，员工号，数量），则存在以下函数依赖关系：

1）（商店编号，商品编号）→员工号，数量

2）（商品编号，员工号）→商店编号，数量

3）员工号→商店编号

由以上依赖关系可以看出该关系模式满足第三范式。组合键（商店编号，商品编号）和（商品编号，员工号）都是它的码。我们再来仔细观察一下它是否满足BNCF范式。（商店编号，商品编号）→员工号，员工号→商店编号，这表明主属性“商店编号”对码（商店编号，商品编号）存在传递函数依赖，所以它不符合BCNF范式。

虽然不满足BCNF范式，也会导致一些冗余，但是将关系模式分解成满足BCNF范式的关系模式后可能会丢掉原来的函数依赖关系，所以，我们不会要求一定要满足BCNF范式，在实际应用中视具体隋况而论，大多数情况下满足第三范式就符合应用要求了。

1.5第四范式（4NF）

前面的范式讨论都是在函数依赖的范围内讨论，到了第四范式，讨论范围就扩大了，涉及的是多值依赖，所以我们先来了解什么是多值依赖。

多值依赖：设R（U）是属性集u上的一个关系模式。X，Y，Z是U的子集，并且Z=U-X-Y。关系模式R（U）中多值依赖X→→Y成立，当且仅当对R（U）的任一关系r，给定的一对（x，z）值，有一组Y的值，这组值仅仅决定于x值而与z值无关。

在这个客户信息表中，客户有多个联系地址和多个联系电话，这时，此表就违反了第四范式。在这种情况下，此表的设计会带来很大维护上的麻烦，解决问题的方法就是设计新表——联系方式表，这样就不会违反第四范式了。下面进行规范化设计，把此表进行分解为客户信息表（表3）和客户联系方式表（表4），使其满足第四范式。

2结语

范式是我们在设计数据库结构时用到的一种方法，一般情况下，范式级别越高，数据库结构就会越清晰合理。在实际的数据库应用中，要去灵活地运用数据库的四大范式及BCNF范式，有些数据库只要满足第三范式就够用，不必强行去满足BC-NF范式、第四范式。要对关系数据库理解透彻，首先要理解数学中的集合、函数等概念，关系数据库理论是依托数学中的集合论，在分析范式定义时，必须先数学中的相关概念熟悉。其次，要熟悉完全函數依赖、部分函数依赖、传递函数依赖、范式定义这些数据库概念。最后要结合实例来理解概念，让概念与实例对应联系起来，一切的分析还是为实际应用做准备的。

注解：

1.候选码：即候选键，简称码或键。