关系数据库规范化理论

上传人:平*** 文档编号:9734225 上传时间:2017-10-04 格式:DOC 页数:14 大小:230.29KB
返回 下载 相关 举报
关系数据库规范化理论_第1页
第1页 / 共14页
关系数据库规范化理论_第2页
第2页 / 共14页
关系数据库规范化理论_第3页
第3页 / 共14页
关系数据库规范化理论_第4页
第4页 / 共14页
关系数据库规范化理论_第5页
第5页 / 共14页
点击查看更多>>
资源描述

《关系数据库规范化理论》由会员分享,可在线阅读,更多相关《关系数据库规范化理论(14页珍藏版)》请在金锄头文库上搜索。

1、第四章 关系数据库规范化理论一个关系数据库模式由一组关系模式组成,一个关系模式由一组属性名组成。关系数据库设计,就是如何把已给定的相互关 联的一组属性名分组 ,并把每一 组属性名组成关系的问题。然而,属性的分组不是唯一的,不同的分组对应着不同的数据库应用系统,它们的效率往往相差很远。为了使数据库设计合理可靠, 简单实用, 长期以来,形成了关系数据库设计的理论规范化理论。4.1 关系规范化的作用规范化,就是用形式更为简洁 ,结构更加规范的关系模式取代原有关系模式的 过程。如果将两个或两个以上实体的数据存放在一个表里,就会出 现下列三个问题: 数据冗余度大 插入异常 删除异常所谓数据冗余,就是相同

2、数据在数据库中多次重复存放的 现象。数据冗余不 仅会浪费存储空间,而且可能造成数据的不一致性。插入异常是指,当在不规范的数据表中插入数据 时,由于 实 体完整性约束要求主码不能为空的限制,而使有用数据无法插入的情况。删除异常是指,当不规范的数据表中某条需要 删除的元组 中包含有一部分有用数据时,就会出现删除困难。(以 P98 工资表为例)解决上述三个问题的方法,就是将不 规范的关系分解成为 多个关系,使得每个关系中只包含一个实体的数据。(讲例子解)当然,改进后的关系模式也存在另一 问题,当 查询职工工资时 需要将两个关系连接后方能查询,而关系连接的代价也是很大的。那么,什么样的关系需要分解?分

3、解关系模式的理 论依据又是什么?分解完后能否完全消除上述三个问题?回答这些问题需要理论指导。下面,将加以讨论:4.2 函数依赖4.2.1 属性间关系实体间的联系有两类:一类是实体与实体之间联系;另一类是实体内部各属性间的联系。数据库建模一章中讨论的是前一类,在 这里我们将学习第二 类。和第一类一样,实体内部各属性 间的联系也分为 1:1、1:n 和 m:n 三类:例:职工(职工号,姓名,身份证号码, 职称,部 门)1、 一对一关系(1:1)设 X、Y 是关系 R 的两个属性(集)。如果 对于 X 中的任一具体值,Y 中至多有一个值与之对应,反之,对于 Y 中的任一具体值,X 中也至多有一个 值

4、与之对应,则称 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 )

5、关系。例如,职工关系中,职称与部门之间就是多对多的关系。上述属性间的三种关系,实际 上是属性值之间相互依赖与相互制 约的反映,因而称之 为属性间的数据依赖。数据依赖共有三种: 函数依赖(Functional Dependency, FD) 多值依赖(Multivalued Dependency,MVD) 连接依赖(Join Dependency ,JD)其中最重要的是函数依赖和多值依赖。4.2.2 函数依赖函数依赖,是属性之间的一种 联系。在关系 R 中,X、 Y 为 R 的两个属性或属性组,如果对于 R 的所有关系 r 都存在:对于 X 的每一个具体值,Y 都只有一个具体值与之对应, 则称属

6、性 Y 函数依赖于属性 X。或者 说,属性 X 函数决定属性 Y,记作 XY 。其中 X 叫作决定因素,Y 叫作被决定因素。上述定义,可简言之:如果属性 X 的值决定属性 Y 的值,那么属性 Y 函数依赖于属性X。换一种说法:如果知道 X 的 值,就可以 获得 Y 的值, 则可以说 X 决定 Y。若 Y 函数不依赖于 X,记作:X Y。若 XY,YX,记作: 前面学习的属性间的三种关系,并不是每种关系中都存在着函数依 赖。 如果 X、Y 间是 1:1 关系, 则存在函数依赖 XY 如果 X、Y 间是 1:n 关系, 则存在函数依赖: XY 或 YX (多方为决定因素) 如果 X、Y 间是 m:

7、n 关系,则不存在函数依赖。注意,属性间的函数依赖不是指 R 的某个或某些关系子集满足上述限定条件,而是指R 的一切关系子集都要满足定 义中的限定。只要有一个具体的关系 r(R 的一个关系子集)不满足定义中的条件,就破坏了函数依赖,使函数依赖不成立。这里的关系子集,指的是 R 的某一部分元组的集合,例如:地测学院的学生关系中只包含了地测学院学生的数据,所以它是长安大学学生关系的一个子集。4.2.3 码的定义X Y前面,我们对码进行了直观化的定 义,下面用函数依 赖的概念 对码作出较为精确的形式化的定义:设 K 是关系模式 R(U,F)中的属性或属性组,K是 K 的任一子集。若 KU,而不存在K

8、,则 K 为 R 的候选码(Candidate Key) 若候选码多于一个,则选 其中的一个为主码(Primary Key); 包含在任一候选码中的属性,叫做 主属性(Primary Attribute); 不包含在任何码中的属性称为非主属性(Nonprime Attribute)或非码属性(Nonkey Attribute) 关系模式中,最简单的情况是 单个属性是码,称 为单码 (Single Key);最极端的情况是整个属性组是码,称为全码 (AllKey)。前面已多次遇到单码的情况,下面是一个全 码的例子:签约(演员名,制片公司,电影名)外码:设有两个关系 R 和 S,X 是 R 的属性

9、或属性组,并且 X 不是 R 的码,但 X 是 S 的码(或与 S 的码 意义相同), 则称 X 是 R 的外部码(Foreign Key),简称外码或外键。如:职工(职工号,姓名,性别, 职称, 部门号)部门(部门号,部门名,电话,负责人)其中职工关系中的“部门号” 就是职工关系的一个外码。在此需要注意,在定义中说 X 不是 R 的码,并不是 说 X 不是 R 的主属性,X 不是码,但可以是码的组成属性,或者是任一候选码中的一个主属性。如:学生(学生号,姓名,性别,年龄)课程(课程号,课程名,任课老师)选课(学生号,课程号,成绩) 在选课关系中, (学生号,课程号)是该关系的码,学生号、课程

10、号又分别是组成主码的属性(但单独不是码) ,它们分别是学生关系和课程关系的主码,所以是选课关系的两个外码。关系间的联系,可以通过同时 存在于两个或多个关系中的主 码和外码的取值来建立。如要查询某个职工所在部门的情况,只需查询部门表中的部 门号与该职工部门号相同的记录即可。所以,主码和外码提供了一个表示 关系间联系的途径。4.2.4 函数依赖和码的唯一性由上述码的形式化定义,我们 可以说:码是由一个或多个属性 组成的,可唯一 标识元组的最小属性组。码在关系中总是唯一的,即一个 码函数唯一地决定一行。如果码的值重复,则整个元组都会重复。否则,违反了实体完整性规则。而元 组的重复则表示存在两个完全相

11、同的实体,这显然是不可能的,所以码是不允许重复取值的。所以,只有当某个属性或属性组能够函数决定关系中的每一个其它的属性,且该属性组的任何一个真子集都做不到这一点时,该属性或属性组才是 该关系的码。函数依赖是一个与数据有关的事物规则的概念。如果属性 B 函数依赖于属性 A,那么若知道了 A 的值,则完全可以找到 B 的值。 这并非是可以由 A 的值计算出 B 的值,而是 逻辑上只能存在一个 B 的值。4.3 关系模式的规范化一、非规范化的关系当一个表中存在还可以再分的数据项时,这个表就是非规 范化的表。非 规范化表存在两种情况: 表中具有组合数据项(P102 表 6-4) 表中具有多值数据项(P

12、103 表 6-5)例:那么什么是规范化关系呢?当一个关系中的所有分量都是不可再分的数据项时,该关系是 规范化的。即当表中不存在组合数据项和多值数据项,只存在不可分的数据项时, 这 个表是规范化的。二维表按其规范化程度从低到高可分为 5 级范式(Normal Form),分别称为1NF、2NF、3NF(BCNF)、4NF、5NF。规范化程度较高者必是 较低者的子集,即:1NF2NF 3NF BCNF4NF 5NF二、第一范式(1NF)定义 1:如果关系模式 R 中不包含多 值属性, 则 R 满足第一范式(First Normal Form),记作:R1NF1NF 是对关系的最低要求,不满足 1

13、NF 的关系是非规范化的关系。非规范化关系转化为规范化关系 1NF 方法很简单,只要上表分别从横向、 纵向展开即可。如下表:上表虽然符合 1NF,但仍是有 问题的关系,表中存在大量的数据冗余和潜在的数据更新异常。原因是(职工号,学历)是右表的码,但姓名、职称、系名、系 办地址却与学历无关,只职工号 姓名工资基本工资 职务工资工龄工资1002 张三 1000 800 200职工号 姓名 职称 系名 系办地址 学历 毕业年份001 张三 教授 计算机 1305大学研究生19631982职工号 姓名 基本工资 职务工资 工龄工资1002 张三 1000 800 2001005 李四 1200 900

14、 150职工号 姓名 职称 系名 系办地址 学历 毕业年份1002 张三 教授 计算机 1305 大学 19631002 张三 教授 计算机 1305 研究生 19821005 李四 讲师 信电 2206 大学 1989与码的一部分有关。所以上表 还需进一步地规范化。三、第二范式(2NF )定义 1:设 X、Y 是关系 R 的两个不同的属性或属性组,且 X Y。如果存在 X 的某一个真子集 X,使 X Y 成立,则称 Y 部分函数依赖于 X,记作:X P Y(Partial)。反之,则称 Y 完全函数依赖于 X,记 作:X F Y (Full)定义 2:如果一个关系 R1NF,且它的所有非主属

15、性都完全函数依赖于 R 的任一候选码, 则 R 属于第二范式, 记作: R2NF。说明:上述定义中所谓的候选码也包括主码,因 为码首先应 是候选码,才可以被指定 为码。例如关系模式:职工(职工号,姓名,职称,项目号,项目名称, 项目角色)中(职工号,项目号)是该关系的 码,而 职工号姓名、职工号职称、项目号项目名称所以(职工号,项目号) P 职称、 (职工号, 项目号) P 项目名称故上述职工关系不符合第二范式要求。它存在三个问题:插入异常、删除异常和修改异常。其中修改异常是这样的,当职 工关系中项目名称发生变化 时,由于参与 该项目的人员很多,每人一条记录,要修改项目信息,就得 对每一个参加

16、该项目的人员信息进行修改,加大了工作量,还有可能发生遗漏,存在着数据一致性被破坏的可能。可把上述职工关系分解成如下三个关系:职工(职工号,姓名,职称)参与项目(职工号,项目号,项目角色)项目(项目号,项目名称)上述三个关系都符合定义 2 的要求,所以都符合 2NF推论:如果关系模式 R1NF,且它的每一个候选码都是单码,则 R2NF符合第二范式的关系模式仍可能存在数据冗余、更新异常等问题。如关系职工信息( 职工号,姓名,职称,系名,系办地址)虽然也符合 2NF,但当某个系中有 100 名职工时,元 组中的 系办地址就要重复 100 次,存在着较高的数据冗余。原因是关系中,系办地址不是直接函数依赖于职工号,而是因 为职工号函数决定系名,而系名函数决定系办地址,才使得系办 地址函数依赖于职工号, 这种依赖是一个传递依赖的过程。所以,上述职工信息的关系模式 还需要进一步的规范化。四、第三范式(3NF)n

展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 学术论文 > 毕业论文

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号