论文部分内容阅读
[摘要]一个关系数据库模式设计的好坏直接对数据库中数据是否冗余以及操作异常产生直接的影响。通过实例分析在数据库系统设计中异常产生的原因，提出解决数据库模式操作异常的具体方法。
[关键词]关系数据库 模式 设计
中图分类号：TP3 文献标识码：A 文章编号：1671－7597(2008)0520037－02
一、引言
关系数据库设计理论主要用于指导数据库的逻辑设计，确定关系模式的划分，每个关系模式所包含的属性，从而使得由一组关系模式组成的关系模型作为一个整体，既能客观地描述各种实体，又能准确地反映实体间的联系，还能如实地体现出实体内部属性之间的相互依存与制约。然而，如果不对系统进行认真的分析和研究，数据库模式不按照一定的范式级别设计，就不能从根本上解决诸如数据冗余、更新异常、插入异常以及删除异常等诸多问题。[1] 本文以一个实现的应用系统为例，对模式进行规范设计，把异常限定在一定的范围内。
二、规范化理论介绍
逻辑数据库设计主要是以关系规范化理论为基础。关系数据库中的关系模式必须满足一定的要求，满足不同程度要求的模式属于不同范式。所谓范式就是符合某一种级别的关系模式的集合。目前主要有六种范式：第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、BC范式(BCNF)、第四范式(4NF)、第五范式(5NF)。第一范式需要满足的要求最低，在第一范式基础上满足进一步要求的为第二范式，其余以此类推。各级范式之间存在如下联系：
函数依赖是指一个或一组属性的值可以决定其他属性的值。对于函数依赖W→A，如果存在VW(V是W的真子集)而函数依赖V→A成立，则称A部分依赖(partial dependency)于W，记作W→A；否则，若不存在这种V，则称A完全依赖于(full dependency)W，记作W→A。对于函数依赖XY，如果YX(X不函数依赖于Y)而函数依赖Y→Z成立，则称Z对X传递依赖(transitive dependency)。
三、在员工揽储管理系统中的应用分析
（一）例子及异常
在设计关系数据库模式时，特别是从面向对象的ODL设计或从E/R设计直接向关系数据库模式转换时，最容易出现的问题是数据的大量冗余，即同一个事实在多个元组中重复。而且，我们发现造成冗余的最常见原因是企图把一个对象的单值和多值特性包含在一个关系中。某银行曾建立这样的一个关系数据库，统计各部门员工每月的揽储情况，关系名及属性为employee(eno，ename，edept，eleader，month，detosit)，各属性依次代表工号、姓名、部门、部门领导、月份、揽储额，具体的关系实例如图3.1。
从这个关系数据库里，我们可以看出，当我们把员工的单值信息(如所在部门)和多值特性(如月份集)存储在一起的时候，就导致了信息的冗余。
当我们企图把太多的信息存放在一个关系中时，就会出现数据冗余和异常问题。主要表现如下：
(1)数据冗余量大。(2)更新异常。(3)删除异常。(4)插入异常。
（二）问题产生的原因
在初步分析了关系Employee的实例以后，我们想知道为什么把这些属性放在一起组成一个关系模式？这些属性之间有什么相互联系？这样的属性组合与我们看到的数据冗余和更新异常有没有什么联系？为了构成一个好的关系模式应该考虑哪些原则？如果开始面对的是一个不太好的关系模式又该如何处理，使之转化为比较满意的结局等问题。关系的键码函数决定该关系的所有其他属性，由于键码能唯一地确定一个元组，所以，也可以说关系的键码函数决定该关系的所有属性。换句话说，一个关系中的所有属性都函数依赖于该关系的键码。然而，当我们进一步分析时，就会发现不同的属性在关系模式中所处的地位和扮演的角色是不同的。为了强调这种差别，我们把键码所在的属性称为主属性，而把键码属性以外的属性称为非主属性。比如对于关系模式Employee来说，eno和month为主属性，而另外4个属性则为非主属性。如果再深入分析，又会发现不同的属性对键码函数依赖的性质和程度是有差别的。
1. 部分依赖。在关系模式Employee中，{eno，month}为键码，函数依赖集如下（其中P表示部分(part)依赖，F表示完全(full)依赖）：enoename，edept，edept eleader，enoeleader；eno，monthename，edept，eleader；eno，monthdetosit。ename，edept和 eleader都函数依赖于eno，而部分依赖于键码。2观察employee关系的实例，就会注意到：对键码完全依赖的属性detosit没有任何冗余，每个员工的每月都有特定的揽储额(当然几个月揽储额相同完全有可能，但这并不属于数据冗余)；对键码部分依赖的属性ename，edept和eleader由于只函数依赖于eno，因此，当显示一个员工几个月的情况时，这些数据就会出现多次重复，造成大量数据冗余；另一方面，当对一个员工的基本情进行更新时，又会出现更新异常。从这个例子可以看出，在一个关系模式中，当存在非主属性对键码的部分依赖时，就会产生数据冗余和更新异常。若非主属性对键码完全依赖，则不会出现类似问题。
2. 传递依赖。在Employee关系中，存在如下函数依赖：enoedept，edepteleader，enoeleader。由于单位有很多员工，所以edepteno。根据传递依赖的定义可知，eleader传递依赖于eno。在员工关系的实例中可以看到，当一个员工有几个月的揽储额时，部门领导的姓名也会多次重复出现；当对员工的基本情况进行更新时，同样会出现类似的更新异常。从上面的分析可以看出，部分依赖和传递依赖有一个共同之处，这就是，二者都不是基本的函数依赖，而都是导出的函数依赖；部分依赖是以对键码的某个真子集的依赖为基础；而传递依赖的基础则是通过中间属性联系在一起的两个函数依赖。而导出的函数依赖在描述属性之间的联系方面并没有比基本的函数依赖提供更多的信息。关系模式中非主属性对键码的部分依赖和传递依赖是产生数据冗余和更新异常的主要根源。
（三）解决的途径
在一个函数依赖集中，导出的依赖相对于基本的依赖而言，虽然形式上多一种描述方式，但本质上完全是冗余的。正是由于关系模式中存在对键码的这种冗余的依赖导致数据库中的数据冗余和更新异常。找到了问题的所在，也就有了解决的途径。系模式的规范化过程是通过对关系模式的分解来实现的。通过投影分解，消除不合理的数据依赖，使关系模式刻画的概念单一化，消除关系模式中各属性对键码的冗余依赖。由于冗余的依赖有部分依赖与传递依赖之分，而属性又有主属性与非主属性的区别，于是，从不同的分析与解决问题的角度出发，导致分解的深度与效果也有所不同，因此，把解决的途径分为几个不同的级别。根据以上分析，对关系模式employee分解为三个关系模式：
Employee (eno，ename，edept)；department (edept，eleader)；amount (eno，month，detosit)。对应的三个关系如图3.2、3.3、3.4。
通过分解，形成的函数依赖集为：eno，montheno enoename，edept，eleader，edepteleadereno，monthdetosit。我们看到，每个非主属性对于键码既不存在部分依赖，也不存在传递依赖，基本消除了数据冗余和异常问题，同时这个分解即保持了函数依赖，又具有无损连接性，语义和数据没有受到损失。
分解后各个关系通过主键建立联系，如图3.5。
四、小结
通过对关系数据库中数据冗余和更新异常原因的分析，要求我们在设计数据库模式时应尽量避免这种情况的发生，当然真的出现了这种情况，我们还要具体分析，对关系数据库进行有效的模式分解，争取使数据冗余和更新异常减小到最小程度。
参考文献：
[1]萨师炫、王珊，数据库系统概论[M].第3版 北京：高等教育出版社.2000.
[2]王珊、陈红， 数据库系统原理教程. 北京:清华大学出版社，1998.
[3]石树刚、郑振楣. 关系数据库.北京:清华大学出版社，1993.
[关键词]关系数据库 模式 设计
中图分类号：TP3 文献标识码：A 文章编号：1671－7597(2008)0520037－02
一、引言
关系数据库设计理论主要用于指导数据库的逻辑设计，确定关系模式的划分，每个关系模式所包含的属性，从而使得由一组关系模式组成的关系模型作为一个整体，既能客观地描述各种实体，又能准确地反映实体间的联系，还能如实地体现出实体内部属性之间的相互依存与制约。然而，如果不对系统进行认真的分析和研究，数据库模式不按照一定的范式级别设计，就不能从根本上解决诸如数据冗余、更新异常、插入异常以及删除异常等诸多问题。[1] 本文以一个实现的应用系统为例，对模式进行规范设计，把异常限定在一定的范围内。
二、规范化理论介绍
逻辑数据库设计主要是以关系规范化理论为基础。关系数据库中的关系模式必须满足一定的要求，满足不同程度要求的模式属于不同范式。所谓范式就是符合某一种级别的关系模式的集合。目前主要有六种范式：第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、BC范式(BCNF)、第四范式(4NF)、第五范式(5NF)。第一范式需要满足的要求最低，在第一范式基础上满足进一步要求的为第二范式，其余以此类推。各级范式之间存在如下联系：
函数依赖是指一个或一组属性的值可以决定其他属性的值。对于函数依赖W→A，如果存在VW(V是W的真子集)而函数依赖V→A成立，则称A部分依赖(partial dependency)于W，记作W→A；否则，若不存在这种V，则称A完全依赖于(full dependency)W，记作W→A。对于函数依赖XY，如果YX(X不函数依赖于Y)而函数依赖Y→Z成立，则称Z对X传递依赖(transitive dependency)。
三、在员工揽储管理系统中的应用分析
（一）例子及异常
在设计关系数据库模式时，特别是从面向对象的ODL设计或从E/R设计直接向关系数据库模式转换时，最容易出现的问题是数据的大量冗余，即同一个事实在多个元组中重复。而且，我们发现造成冗余的最常见原因是企图把一个对象的单值和多值特性包含在一个关系中。某银行曾建立这样的一个关系数据库，统计各部门员工每月的揽储情况，关系名及属性为employee(eno，ename，edept，eleader，month，detosit)，各属性依次代表工号、姓名、部门、部门领导、月份、揽储额，具体的关系实例如图3.1。
从这个关系数据库里，我们可以看出，当我们把员工的单值信息(如所在部门)和多值特性(如月份集)存储在一起的时候，就导致了信息的冗余。
当我们企图把太多的信息存放在一个关系中时，就会出现数据冗余和异常问题。主要表现如下：
(1)数据冗余量大。(2)更新异常。(3)删除异常。(4)插入异常。
（二）问题产生的原因
在初步分析了关系Employee的实例以后，我们想知道为什么把这些属性放在一起组成一个关系模式？这些属性之间有什么相互联系？这样的属性组合与我们看到的数据冗余和更新异常有没有什么联系？为了构成一个好的关系模式应该考虑哪些原则？如果开始面对的是一个不太好的关系模式又该如何处理，使之转化为比较满意的结局等问题。关系的键码函数决定该关系的所有其他属性，由于键码能唯一地确定一个元组，所以，也可以说关系的键码函数决定该关系的所有属性。换句话说，一个关系中的所有属性都函数依赖于该关系的键码。然而，当我们进一步分析时，就会发现不同的属性在关系模式中所处的地位和扮演的角色是不同的。为了强调这种差别，我们把键码所在的属性称为主属性，而把键码属性以外的属性称为非主属性。比如对于关系模式Employee来说，eno和month为主属性，而另外4个属性则为非主属性。如果再深入分析，又会发现不同的属性对键码函数依赖的性质和程度是有差别的。
1. 部分依赖。在关系模式Employee中，{eno，month}为键码，函数依赖集如下（其中P表示部分(part)依赖，F表示完全(full)依赖）：enoename，edept，edept eleader，enoeleader；eno，monthename，edept，eleader；eno，monthdetosit。ename，edept和 eleader都函数依赖于eno，而部分依赖于键码。2观察employee关系的实例，就会注意到：对键码完全依赖的属性detosit没有任何冗余，每个员工的每月都有特定的揽储额(当然几个月揽储额相同完全有可能，但这并不属于数据冗余)；对键码部分依赖的属性ename，edept和eleader由于只函数依赖于eno，因此，当显示一个员工几个月的情况时，这些数据就会出现多次重复，造成大量数据冗余；另一方面，当对一个员工的基本情进行更新时，又会出现更新异常。从这个例子可以看出，在一个关系模式中，当存在非主属性对键码的部分依赖时，就会产生数据冗余和更新异常。若非主属性对键码完全依赖，则不会出现类似问题。
2. 传递依赖。在Employee关系中，存在如下函数依赖：enoedept，edepteleader，enoeleader。由于单位有很多员工，所以edepteno。根据传递依赖的定义可知，eleader传递依赖于eno。在员工关系的实例中可以看到，当一个员工有几个月的揽储额时，部门领导的姓名也会多次重复出现；当对员工的基本情况进行更新时，同样会出现类似的更新异常。从上面的分析可以看出，部分依赖和传递依赖有一个共同之处，这就是，二者都不是基本的函数依赖，而都是导出的函数依赖；部分依赖是以对键码的某个真子集的依赖为基础；而传递依赖的基础则是通过中间属性联系在一起的两个函数依赖。而导出的函数依赖在描述属性之间的联系方面并没有比基本的函数依赖提供更多的信息。关系模式中非主属性对键码的部分依赖和传递依赖是产生数据冗余和更新异常的主要根源。
（三）解决的途径
在一个函数依赖集中，导出的依赖相对于基本的依赖而言，虽然形式上多一种描述方式，但本质上完全是冗余的。正是由于关系模式中存在对键码的这种冗余的依赖导致数据库中的数据冗余和更新异常。找到了问题的所在，也就有了解决的途径。系模式的规范化过程是通过对关系模式的分解来实现的。通过投影分解，消除不合理的数据依赖，使关系模式刻画的概念单一化，消除关系模式中各属性对键码的冗余依赖。由于冗余的依赖有部分依赖与传递依赖之分，而属性又有主属性与非主属性的区别，于是，从不同的分析与解决问题的角度出发，导致分解的深度与效果也有所不同，因此，把解决的途径分为几个不同的级别。根据以上分析，对关系模式employee分解为三个关系模式：
Employee (eno，ename，edept)；department (edept，eleader)；amount (eno，month，detosit)。对应的三个关系如图3.2、3.3、3.4。
通过分解，形成的函数依赖集为：eno，montheno enoename，edept，eleader，edepteleadereno，monthdetosit。我们看到，每个非主属性对于键码既不存在部分依赖，也不存在传递依赖，基本消除了数据冗余和异常问题，同时这个分解即保持了函数依赖，又具有无损连接性，语义和数据没有受到损失。
分解后各个关系通过主键建立联系，如图3.5。
四、小结
通过对关系数据库中数据冗余和更新异常原因的分析，要求我们在设计数据库模式时应尽量避免这种情况的发生，当然真的出现了这种情况，我们还要具体分析，对关系数据库进行有效的模式分解，争取使数据冗余和更新异常减小到最小程度。
参考文献：
[1]萨师炫、王珊，数据库系统概论[M].第3版 北京：高等教育出版社.2000.
[2]王珊、陈红， 数据库系统原理教程. 北京:清华大学出版社，1998.
[3]石树刚、郑振楣. 关系数据库.北京:清华大学出版社，1993.