关系规范化理论

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

《关系规范化理论》

关系数据库是以关系模型为基础的数据库,它利用关系描述现实世界。一个关系即可用来描述一个实体及其属性,也可用来描述实体间的一种联系。关系模式是用来定义关系的,一个关系数据库包含一组关系,定义这组关系的关系模式的全体就构成了该数据库的模式。关系数据库规范化理论是用来研究如何将一个“设计不合理”的关系模型转化为一个“好”的关系模式,就是用形式更为简洁、结构更加规范的关系模式取代原有关系的过程。其基本思想是通过合理的分解关系模式来消除其中不合适的数据依赖,以解决数冗余、插入异常、删除异常以及更新复杂等问题。不规范化的关系模式存在的问题:

1数据冗余大,浪费大量的存储空间。

2更新异常,数据冗余,更新数据时,维护数据完整性代价大。

3插入异常,该插的插不进去。

4 删除异常不该删除的数据不得不删,原因:由于存在于模式中的某些数据依赖引起的。

解决方法:通过关系模式分解来消除其中不合适的数据依赖

关系数据库的设计主要是关系模式的设计。关系模式设计的好坏将直接影响到数据库设计的成败。将关系模式规范化,使之达到较高的范式是设计好关系模式的唯一途径。否则所设计的关系数据库会产生一系列的问题。我们结合一个实例来分析数据库模式设计的好与坏。例如有一个教学管理数据库,包括的信息有学生的学号、姓名、性别、系别、系主任、课程号和选修课程的学生成绩,以及一个教师只能带一门课,一个学生选修一门课就对应一个教师。若将此信息按要求设计为一个关系模式,则该关系模式为:学生(学号、姓名、性别、系别、系主任、课程号、任课教师、成绩)。此关系模式的主码应为(学号、课程号),从关系模式上看,该关系模式已经包括需要的全部信息,如果按此关系模式建立关系,并对其进行深入分析,就会发现其中的问题所在:

1. 数据冗余度大:每一个“系别”和“系主任”信息存储的次数等于该系的学生人数乘以每个学生选修的课程门数。

2. 插入异常:一个新系没有招生时,“系别”和“系主任”信息就无法插入到数据库中。因为,主码为(学号、课程号),此时没有学

生而使学号为空。

3. 删除异常:当一个系的学生都毕业了而又没招新生时,删除了全部学生记录时,随之也删除了“系别”和“系主任”等信息。这个系依然存在,而在数据库中却无法找到该系信息。从上面的分析可知,学生关系不是一个合理的数据库模式。一个合理的模式应当避免发生上述异常问题。规范化理论认为,关系中的各属性是相互关联的,他们互相依赖、互相制约,构成一个结构严谨的整体。因此,在关系设计中,必须从语义中摸清这些关联,特别是依赖关系,只能把那些相互关联密切的属性拼凑在一起。构造一个“好”的数据库模式,必须使它的关系模式的属性之间满足某种内在的语义条件,而这种联系又可对关系的不同要求分为若干等级,这就是关系规范化。

一般而言,我们通过一个关系模式是否属于某一范式来确定其在多大程度上解决了数据冗余度大、插入异常、删除异常及更新复杂等问题,下面我们结合范式的几种定义来探讨数据库的规范化。

第一范式。如果一个关系模式R 的所有属性都是原子的,也就是其属性域中的元素是不可再分的单元,则称其属于第一范式的关系模式。显然,此学生关系模式中不存在可分的数据项,即满足了第一范式的要求。但是,满足1NF 并不能保证它就是一个好的关系,其原因就是第一范式不够规范,即限制太少,造成表中存放的信息太杂。因此,应考虑高一级范式的关系模式。

第二范式。如果关系模式R(U,F)属于第一范式并且R 中每个非主属性都完全函数依赖于关系的码,则R(U,F)属于第二范式。

将第一范式转化为第二范式,其实质是采用投影分解法,将一个第一范式的关系无损分解为几个第二范式的关系。分解方式为:将部分函数单独提取出来,把学生关系模式分解为学生信息和学生成绩两个关系模式,分别表示为

学生信息(学号、姓名、性别、系别、系主任)

学生成绩(学号、课程号、任课教师、成绩)

此时,两个分解后的关系模式均属于第二范式,再对学生信息模式分析,发现其中仍然存在以下问题:

1) 数据冗余度大:系主任信息会重复存储多次。

2) 修改麻烦:若某个系更换了系主任,则必须重复修改相应系的每个学生对应的系主任的名字,若漏改一处则造成数据不一致。

3) 插入异常:如果新开设一个系,会因为没有招生而不能插入相应系的信息。

4) 删除异常。若删除李明记录,则整个元组不复存在,连同系的信息一并删掉,这样会引起信息丢失。存在以上问题的原因就是学生信息模式中存在传递函数依赖:学号系主任。故仍需考虑更高一级范式的关系模式。

第三范式。如果关系模式R(U,F)属于第二范式,并且所有非主属性都不传递依赖于关系的码,则R(U,F)属于第三范式。要想使学生信息模式满足第三范式,就要去掉表中的传递函数依赖,方法仍是表的无损分解。分解方式为:将传递函数依赖单独提取出来,把模式分解为学生基本信息和系别信息两个关系模式,分别为

学生基本信息(学号、姓名、性别、系别)

系别信息(系别、系主任)。此时,两个关系模式分别属于第三范式,基本上避免了上述几种异常问题的发生。再分析第一次分解后得到的学生成绩关系模式,虽然它也满足第三范式,但它仍然存在以下问题:

(1)数据冗余度大:任课教师这一信息重复了多次。

(2)修改麻烦:若某个老师所带的课程更换教师,则必须重复修改其所带班级每个学生对应的任课教师的名字,若漏改一处则造成数据不一致。

(3)插入异常。如果新来了一个老师,会因为没有学生选课而不能插入相应的信息。

(4)删除异常。若删除某个学生的某课程成绩,则整个元组不复存在,连任课教师的信息一并删掉,这样会引起信息丢失。存在以上问题的原因就是学生成绩关系模式中存在作为非主码的“任课教师”作为决定因素,因此,我们仍需对其探讨更高级范式的关系模式。

BC范式。若某关系模式满足第三范式,且关系中每一个决定因素都包含码,则称该关系满足BC范式。要想使学生成绩关系模式满足BC范式,就要去掉表中的非主码作为决定因素,方法仍是表的无损分解。分解方式为:将非主码作为决定因素的信息单独提取出来,把模式分解为学生选课和教师信息两个关系模式,分别为

相关文档
最新文档