关系数据库模式设计研究和应用.doc

关系数据库模式设计研究和应用 　　[摘要]一个关系数据库模式设计的好坏直接对数据库中数据是否冗余以及操作异常产生直接的影响。通过实例分析在数据库系统设计中异常产生的原因，提出解决数据库模式操作异常的具体方法。 　　[关键词]关系数据库 模式 设计 　　中图分类号：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关系的实例，就会注意到：