关系数据库的范式

1.7　关系数据库的范式

关系数据库规范化理论是数据库设计的一种理论指南。在数据库逻辑设计中，就是用关系数据库范式理论构造数据库的逻辑结构问题。

关系型数据库的规范化理论是数据库设计的理论基础，其目的是研究关系模式中各个属性之间的依赖关系及其对关系模式的影响。

规范化理论不仅能够作为数据库设计优劣的判断依据，而且还可以预测数据库系统可能出现的问题。

在关系型数据库理论中，把一个二维表称为一个关系。

二维表由行和列组成，一列对应于一个字段，称为属性。

一行对应于一条记录，称为一个元组。

二维表的框架对应于数据库结构，称为关系模式。

在一个关系中，必须有一个键。这个键有时也简称为主键，键可以唯一地标示出这个元组。例如，在人事档案中，可以选择工作证号或者职工编号作为键。这时，由于每一条记录都具有不同的键的值，所以可以根据键的值唯一地确定一条记录。如果在公司中没有姓名相同的员工，那么也可以使用姓名作为键。

但是，实际上存在着重名的可能性，所以使用姓名就无法唯一地标示出每一条记录，因此不能使用姓名作为键。

一般情况下，关系具有以下性质：

（1）每一列上的数据属于同一种属性。

（2）每一个列都有不同的名称，即在一个关系中属性的名称唯一。

（3）行的顺序不重要。

（4）没有重复的行（所有的行都不相同）。

（5）列的顺序不重要。

1.7.1　数据依赖

在关系型数据库理论中，用数据依赖来描述关系中属性之间的相互关系。比较重要的数据依赖有函数依赖和传递依赖两种方式。关系模式的操作异常都与数据依赖有关。下面详细介绍这两种依赖方式。

1.函数依赖（Functional Dependency，简称FD）

如果在关系R中，数据元素Y的取值依赖于数据元素X的取值，那么称为Y函数依赖X，或者称为X决定Y，记作X→Y。

例如，在学生档案数据库中，学生的姓名、出生日期、住址等属性均由学生的学号决定。当学号确定了之后，该学号所代表的学生的其他属性也就随之确定了。也可以说，姓名、出生日期、住址等属性函数依赖于学号。

2.多值依赖（Multivalued Dependency，简称MVD）

在多值依赖（表示为X→→Y，读作X多值决定Y，或Y多值依赖于X）中，对于给定的X值，其对应的是Y的一组数值（其个数可以从零到多个），而且这种对应关系，对于给定的X值所对应的（U—X—Y）每一个值都能成立。

多值依赖的定义如下：

设X、Y是关系模式R的属性集，如果对于R的任何值r，都有如下的性质，则称R满足X→→Y。

如果r中存在两个元组s、t，使得：

s[X]=t[X]

则r中必然存在两个元组s、t，使得：

u[X]=v[X]=s[X]=t[X]

u[Y]=t[Y]且u[U—X—Y]=s[U—X—Y]

v[Y]=s[Y]且v[U—X—Y]=t[U—X—Y]

即交换s、t的Y值所得的两个元组必在r中。

如果X→→Y，而U—X—Y=Q，即U=XY，则称X→→Y为平凡的多值依赖。

函数依赖可以看成多值依赖的特例。

1.7.2　关系模式的操作异常

如果有一个不合理的关系模式，那么就可能造成许多操作上的问题。例如，一个借书情况的记录关系模式如下：

借书（书名、读者姓名、读者部门、借出日期）

如果借出一本书，那么加入一条借书记录，还书之后则删除该记录。在这个关系模式中，由于借书记录和读者本人的基本情况存于一个模式中，存在下列一些操作异常问题：

（1）数据冗余。每借出一本书就要重复输入读者部门。如果一个人借了许多本书，那么就得为其保存许多相同的读者姓名和部门值。表中就有许多重复的数据内容，也造成了存储空间的浪费。

（2）更新异常。由于为读者保存了多个部门的数据内容，如果在一个元组中更改了部门，但是没有同时更改读者在其他元组中的读者姓名和部门，那么一个读者就会有两个不同的部门。

（3）插入异常。如果一个读者没有借过书，借书数据库中就无法将其记录。因此，也就无法记录该读者的姓名和部门。

（4）删除异常。当一个读者将其借出的书全部归还之后，读者的姓名和部门也随之全部删除，那有关读者的全部信息也就全部丢失了。

上面介绍的几种基本的操作异常都是由不合理的关系模式造成的。

由此可见，关系模式的设计是数据库应用系统的基础和关键，具有十分重要的意义。关系模式设计就是数据库设计，主要方法是使用范式理论去检验和评价关系模式。

1.7.3　范式

只有满足一定的条件关系模式，才能避免操作异常。关系模式要满足的条件称为规范化形式，简称为范式。有5种不同程度的范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、第四范式（4NF）、第五范式（5NF）。一个低一级范式的关系模式，通过分解方法转换为若干个高一级范式的关系模式的集合，称为规范化。下面介绍这些范式。

1.第一范式（1NF）

第一范式要求元组中的每一个数据项都不能再分割，都是原子项，记作1NF。简单地说，1NF就是要求在二维表中的每一个元素都是单一的、不可再分的数据。在表1-2中，由于工资环可以细分.所以不符合INF的要求。

表1-2　不符合1NF要求的二维表

如果工资是由基本工资和津贴两项组成，那么可以把工资分解成基本工资和津贴两项，

如表1-3所示，这时就符合1NF的要求。

表1-3　符合1NF要求的二维表

1NF是关系数据库能够保存数据并且正确访问数据的最基本条件。当然，这种费求是相对而言的。因为属性是否属于不可分割的原子状态，要根据具体情况和环境来定。

例如，在前面的这个示例中，如果工资本身只有一项内容，那么工资就已经属于不可分割的原子状态；如果工资属性由更多的项组成，那么就需要将该项分解成更多的属性项。是否属于不可分割的原子状态，也会随着应用环境的变化而变化。例如.，对于姓名这个属性项，如果用户是中国人，那么就可以认为该属性项是不可分割的原子状态；但是，如果数据库的用户是美国人，那么就会认为该属性项是可以分割的非原子状态，因为可以把姓名分解成姓项、名项甚至还有中间项。

2.第二范式（2NF）

在关系R中，如果X→Y，并且对于X的任何一个真子集X’，都有X’母Y，则称Y对X完全函数依赖。

如果一个关系模式符合第一范式（1NF），并且每一个非键属陛都完全依赖于主键，那么就可认为该关系模式符合第二范式，简记为2NF。在2NF中，非主键属性（从全部属性的集合中除去主键包含的属性）必须完全依赖于整个主键，如下面这个示例：

借书（书名、读者姓名、读者部门、借书日期）

在这个示例中，由书名和读者姓名构成复合键（忽略姓名重名和一位读者借两本以上同名书的情况），这是由于单凭书名或者读者姓名已不能惟一地确定一条借书记录，因此，用这两个属性构成键，可以惟一地确定一条记录。在这个关系模式中，借书日期是完全依赖于整个键的，而读者部门则只依赖于读者姓名，与书名无关。因此，作为非主键属性的渎者部门，只是部分函数依赖于主键，而不是完全依赖于整个主键，所以不符合2NF的要求。

为了使其符合2NF的要求，必须将那些部分函数依赖于主键的非主键属性，从这个关系模式中分离出去，如下所示：

借书（﹡书名、术读者姓名、借书日期）

读者（﹡读者姓名、读者部门）

在上面的示例中，属性名前有星号（m）表示该属性为主键。

3.第三范式（3NF）

如果在一个符合第二范式的关系模式中，所有非键属性之间不存在函数依赖关系，那么称该关系模式符合第三范式，简记为3NF。3NF的实质是从符合2NF的关系模式中除去传递依赖。例如，如果职员工资关系模式如下：

在上面这个关系模式中，非键属性为工资级别和基本工资，而基本工资函数依赖于工资级别，因此存在着传递依赖，所以该关系模式不符合3NF形式。为了满足3NF形式，必须将传递依赖从关系模式中分离出去，例如：

职员工资（﹡姓名、工资级别）

工资级别对照（﹡工资级别、基本工资）

另外一种常见的非3NF形式如下示例：

库存零件（半零件编号、名称、单价、数量、金额）

在上面这个示例中，属性项金额为库存零件占用的资金数额，是单价和数量的乘积，也就是函数依赖于单价和数量，因此不符合3NF形式。为了使该关系模式符合3NF形式，只需将金额这一项去掉，得到下面这种形式：

库存零件（球零件编号、名称、单价、数量）

4.第四范式（4NF）

第四范式（4NF）要求关系模式至少符合3NF，并且在关系模式中没有超过一个的多值事实。多值事实就是某个属性有若干个值，这些值由另一个属性的一个值决定，例如职员的孩子和职员选修的课程。如表1-4所示表示两个多值事实。

表1-4　多值事实示例

看看在这个关系中的问题——对数据的增删很不方便，数据的冗余也十分明显。那么如何解决这个问题呢?可以将这种关系模式分解成下面的形式。

如表1-5所示只有职员及其孩子的信息。

表1-5　简化了的职员信息

如表1-6所示只有职员及其所选修的课程信息。

表1-6　职员及其所选修课程信息

续表

5.第五范式（5NF）

虽然第五范式（5NF）要多解释一些，但是也有一个规则：符合第五范式（5NF）的表不能分解成两个或者多个表（每一个表都有一个主键，这是原表主键的真子集），而不丢失信息。

假设下列有关销售代理、产品和制造公司的规则是：如果某个销售代理卖掉了一定数量的产品，并且该销售代理代表制造该产品的公司，那么该销售代理为该公司销售产品，可以用表1-7所示表示这种规则。

表1-7　销售代表、公司与产品的关系

但是根据定义，观察上面的内容，各关系不符合第五范式。它可以分解成下面三种关系，而不丢失任何信息，因为可以使用前者指出的状态准确地表示销售代理什么产品，下面看看这3个关系中的内容。

如表1-8所示记录了销售代理和制造公司的关系。

表1-8　销售代理和公司的关系

如表1-9所示记录了销售代理和所销售产品的关系。

表1-9　销售代理和其产品的关系

如表1-10所示记录了制造公司和所制造产品的关系。

表1-10　制造公司和所制造产品的关系

考虑如何存储这种事实：哈利销售东风汽车。在这3个关系表中，回答很简单：输入一条（哈利，东风）关系到销售代理和制造公司关系中，一条（哈利，卡车）记录到销售代理和制造产品关系中。然而在销售代理、制造公司和产品关系中，必须增加下面的记录：

（哈利，东风，卡车）

（哈利，东风，小汽车）

这里将会怎样呢?销售代理、制造公司和产品关系存储了冗余元素——一个代理销售产品——为了满足以前提出的规则。通过分解这种关系，也可以指出代理销售公司产品的事实，不必冗余地表示这种事实。然而，重要的是，没有这种规则，需要通过一种像销售代理、制造公司和产品的关系来了解销售代理销售公司的哪一个产品。虽然第五范式刚开始很难把握好，但是它说明了范式的真正目的——清晰地创建关系代表的含义。当设计数据库时，这一点非常重要。

6.范式之间的关系

前面曾经介绍过，一个低一级范式的关系模式，通过分解方法转换为若干个高一级范式的关系模式的集合。也可以讲任何一个高层的范式，总是能够满足低层的范式。例如，2NF必然满足1NF，3NF必然满足1NF和2NF，4NF必然满足1NF、2NF和3NF，5NF必然满足1NF、2NF、3NF和4NF。为了提高范式的程度，必须对较低层的范式的关系模式进行分解，即将一个低层的关系模式分解成几个更小、更紧凑的关系模式，通常是一个关系模式描述一类实体或者实体之间的关系。

一般来说，规范化程度低会造成数据冗余和操作异常，但是规范化程度低则检索直接，处理比较简单；规范化程度高可以消除操作异常和减少数据冗余，但是规范化程度高则在检索时要访问更多的关系，即需要做更多的关联操作，比较复杂。例如，有下面两个不同的关系模式：

第一个关系模式：职员（姓名，部门，工资级别，基本工资）

第二关系模式：职员（姓名，部门，工资级别）

工资级别（工资级别，基本工资）

第一个关系模式不符合3NF，第二个关系模式符合3NF。如果需要查询某一个人的基本工资，那么在第一个关系模式中执行一次查询就可以查出，其查询过程如图1-7所示。

图1-7　不满足3NF时的查询

第二个关系模式中，由于职员关系中不包含基本工资，需要从另外一个关系中找出基本工资，这样就会影响检索的速度，其查询过程如图1-8所示。

图1-8　满足3NF时的查询

通过这样的比较可以看出，多重的关联是为减少数据冗余而付出的代价。对于一个具体的应用系统，达到3NF即可以满足一般应用要求，甚至不一定达到3NF也可满足。

在数据库的分析和设计时，要考虑到提高了范式要求后，就需要进一步对关系范式做分解，从而使数据库更加破碎，在检索时必须做更多的关联，导致检索效率明显下降。所以并不是规范化程度越高，模式就越好，而必须结合应用环境和实现世界的具体情况合理地选择数据库模式。