关系数据库规范化理论

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

关系数据库规范化理论

————————————————————————————————作者: ————————————————————————————————日期:

第四章关系数据库规范化理论

一个关系数据库模式由一组关系模式组成,一个关系模式由一组属性名组成。关系数据库设计,就是如何把已给定的相互关联的一组属性名分组,并把每一组属性名组成关系的问题。然而,属性的分组不是唯一的,不同的分组对应着不同的数据库应用系统,它们的效率往往相差很远。

为了使数据库设计合理可靠,简单实用,长期以来,形成了关系数据库设计的理论——规范化理论。

4.1关系规范化的作用

规范化,就是用形式更为简洁,结构更加规范的关系模式取代原有关系模式的过程。

如果将两个或两个以上实体的数据存放在一个表里,就会出现下列三个问题:

➢数据冗余度大

➢插入异常

➢删除异常

所谓数据冗余,就是相同数据在数据库中多次重复存放的现象。数据冗余不仅会浪费存储空间,而且可能造成数据的不一致性。

插入异常是指,当在不规范的数据表中插入数据时,由于实体完整性约束要求主码不能为空的限制,而使有用数据无法插入的情况。

删除异常是指,当不规范的数据表中某条需要删除的元组中包含有一部分有用数据时,就会出现删除困难。

(以P98工资表为例)

解决上述三个问题的方法,就是将不规范的关系分解成为多个关系,使得每个关系中只包含一个实体的数据。

(讲例子解)

当然,改进后的关系模式也存在另一问题,当查询职工工资时需要将两个关系连接后方能查询,而关系连接的代价也是很大的。

那么,什么样的关系需要分解?分解关系模式的理论依据又是什么?分解完后能否完全消除上述三个问题?回答这些问题需要理论指导。下面,将加以讨论:

4.2 函数依赖

4.2.1属性间关系

实体间的联系有两类:一类是实体与实体之间联系;另一类是实体内部各属性间的联系。数据库建模一章中讨论的是前一类,在这里我们将学习第二类。

和第一类一样,实体内部各属性间的联系也分为1:1、1:n和m:n三类:

例:职工(职工号,姓名,身份证号码,职称,部门)

1、一对一关系(1:1)

设X、Y是关系R的两个属性(集)。如果对于X中的任一具体值,Y中至多有一个值与之对应,反之,对于Y中的任一具体值,X中也至多有一个值与之对应,则称X、Y两属性

间是一对一关系。

如本例职工关系中职工号与身份证号码之间就是一对一关系。

2、一对多关系(1:n)

设X、Y是关系R的两个属性(集)。如果对于X中的任一具体值,Y中可以找到多个值与之对应,而对于Y中的任一具体值,X中至多只有一个值与之对应,则称属性X对Y是一对多关系。

如职工关系中职工号与职称之间就是一对多的关系。

3、多对多关系(m:n)

设X、Y是关系R的两个属性(集)。如果对于X中的任一具体值,Y中有n个值与之对应,而对于Y中的任一具体值,X中也有m个值与之对应,则称属性X对Y是一对多(m:n)关系。

例如,职工关系中,职称与部门之间就是多对多的关系。

上述属性间的三种关系,实际上是属性值之间相互依赖与相互制约的反映,因而称之为属性间的数据依赖。

数据依赖共有三种:

➢函数依赖(Functional Dependency,FD)

➢多值依赖(Multivalued Dependency,MVD)

➢连接依赖(Join Dependency,JD)

其中最重要的是函数依赖和多值依赖。

4.2.2 函数依赖

函数依赖,是属性之间的一种联系。在关系R中,X、Y为R的两个属性或属性组,如果对于R的所有关系r 都存在:对于X的每一个具体值,Y都只有一个具体值与之对应,则称属

性Y函数依赖于属性X。或者说,属性X函数决定属性Y,记作X→Y。其中X叫作决定因素,Y 叫作被决定因素。

上述定义,可简言之:如果属性X的值决定属性Y的值,那么属性Y函数依赖于属性X。换一种说法:如果知道X的值,就可以获得Y的值,则可以说X决定Y。

若Y函数不依赖于X,记作:X→Y。

X Y

若X→Y,Y→X,记作:

前面学习的属性间的三种关系,并不是每种关系中都存在着函数依赖。

◆如果X、Y间是1:1关系,则存在函数依赖X←→Y

◆如果X、Y间是1:n关系,则存在函数依赖:X→Y或Y→X(多方为决定因素)

◆如果X、Y间是m:n关系,则不存在函数依赖。

注意,属性间的函数依赖不是指R的某个或某些关系子集满足上述限定条件,而是指R 的一切关系子集都要满足定义中的限定。只要有一个具体的关系r(R的一个关系子集)不满足定义中的条件,就破坏了函数依赖,使函数依赖不成立。

这里的关系子集,指的是R的某一部分元组的集合,例如:地测学院的学生关系中只包含了地测学院学生的数据,所以它是长安大学学生关系的一个子集。

4.2.3码的定义

前面,我们对码进行了直观化的定义,下面用函数依赖的概念对码作出较为精确的形式化的定义:

设K是关系模式R(U,F)中的属性或属性组,K’是K的任一子集。若K→U,而不存在K'→U,则K为R的候选码(Candidate Key)

➢若候选码多于一个,则选其中的一个为主码(PrimaryKey);

➢包含在任一候选码中的属性,叫做主属性(PrimaryAttribute);

➢不包含在任何码中的属性称为非主属性(Nonprime Attribute)或非码属性(No nkey Attribute)

➢关系模式中,最简单的情况是单个属性是码,称为单码(Single Key);最极端的情况是整个属性组是码,称为全码(All-Key)。

前面已多次遇到单码的情况,下面是一个全码的例子:

签约(演员名,制片公司,电影名)

外码:设有两个关系R和S,X是R的属性或属性组,并且X不是R的码,但X是S的码(或与S的码意义相同),则称X是R的外部码(Foreign Key),简称外码或外键。

如:职工(职工号,姓名,性别,职称,部门号)

部门(部门号,部门名,电话,负责人)

其中职工关系中的“部门号”就是职工关系的一个外码。

在此需要注意,在定义中说X不是R的码,并不是说X不是R的主属性,X不是码,但可以是码的组成属性,或者是任一候选码中的一个主属性。

如:学生(学生号,姓名,性别,年龄…)

课程(课程号,课程名,任课老师…)

选课(学生号,课程号,成绩)

在选课关系中,(学生号,课程号)是该关系的码,学生号、课程号又分别是组成主码的属性(但单独不是码),它们分别是学生关系和课程关系的主码,所以是选课关系的两个外码。

关系间的联系,可以通过同时存在于两个或多个关系中的主码和外码的取值来建立。如要查询某个职工所在部门的情况,只需查询部门表中的部门号与该职工部门号相同的记录即可。所以,主码和外码提供了一个表示关系间联系的途径。

4.2.4 函数依赖和码的唯一性

由上述码的形式化定义,我们可以说:码是由一个或多个属性组成的,可唯一标识元组

相关文档
最新文档