没有合适的资源?快使用搜索试试~ 我知道了~
资源推荐
资源详情
资源评论
第4章 关系数据库规范化理论
数据库设计的一个最基本的问题是怎样建立一个合理的数据库模式,使数据库系统无论
是在数据存储方面,还是在数据操作方面都具有较好的性能。什么样的模型是合理的模型,
什么样的模型是不合理的模型,应该通过什么标准去鉴别和采取什么方法来改进,这是在进
行数据库设计之前必须明确的问题。
为使数据库设计合理可靠、简单实用,长期以来,形成了关系数据库设计理论,即规范
化理论。它是根据现实世界存在的数据依赖而进行的关系模式的规范化处理,从而得到一个
合理的数据库设计效果。
本章首先说明关系规范化的作用,接着引入函数依赖和范式等基本概念,然后介绍关系
模式等价性判定和模式分解的方法,最后简要介绍两种数据依赖的概念。
4.1 关系规范化的作用
4.1.1问题的提出
从前面的有关章节可知,关系是一张二维表,它是涉及属性的笛卡尔积的一个子集。从
笛卡尔积中选取哪些元组构成该关系,通常是由现实世界赋予该关系的元组语义来确定的。
元组语义实质上是一个n目谓词(n是属性集中属性的个数)。使该n目谓词为真的笛卡尔积
中的元素(或者说凡符合元组语义的元素)的全体就构成了该关系。
但由上述关系所组成的数据库还存在某些问题。为了说明的方便,我们先看一个实例。
【例4.1】设有一个关于教学管理的关系模式R(U),其中U由属性Sno、Sname、
Ssex、Dname、Cname、Tname、Grade组成的属性集合,其中Sno的含义为学生学号
Sname为学生姓名,Ssex为学生性别,Dname为学生所在系别,Cname为学生所选的课
程名称,Tname为任课教师姓名,Grade为学生选修该门课程的成绩。若将这些信息设计
成一个关系,则关系模式为:
教学(Sno,Sname,Ssex,Dname,Cname,Tname,Grade)
选定此关系的主键为(Sno,Cname)。
由该关系的部分数据(如表4-1所示),我们不难看出,该关系存在着如下问题:
1. 数据冗余(Data Redundancy)
每一个系名对该系的学生人数乘以每个学生选修的课程门数重复存储。
每一个课程名均对选修该门课程的学生重复存储。
每一个教师都对其所教的学生重复存储。
2. 更新异常(Update Anomalies)
由于存在数据冗余,就可能导致数据更新异常,这主要表现在以下几个方面:
⑴ 插入异常(Insert Anomalies):由于主键中元素的属性值不能取空值,如果新分
配来一位教师或新成立一个系,则这位教师及新系名就无法插入;如果一位教师所开的课程
无人选修或一门课程列入计划但目前不开课,也无法插入。
⑵ 修改异常(Modication Anomalies):如果更改一门课程的任课教师,则需要修
改多个元组。如果仅部分修改,部分不修改,就会造成数据的不一致性。同样的情形,如果
一个学生转系,则对应此学生的所有元组都必须修改,否则,也出现数据的不一致性。
⑶ 删除异常(Deletion Anomalies):如果某系的所有学生全部毕业,又没有在读
及新生,当从表中删除毕业学生的选课信息时,则连同此系的信息将全部丢失。同样地,如
果所有学生都退选一门课程,则该课程的相关信息也同样丢失了。
由此可知,上述的教学管理关系尽管看起来能满足一定的需求,但存在的问题太多,从
而它并不是一个合理的关系模式。
表4-1 教学关系部分数据
Sno Sname Ssex Dname Cname Tname Grade
0450301 张三恺 男 计算机系 高等数学 李刚 83
0450301
张三恺 男 计算机系 英语 林弗然
71
0450301 张三恺 男 计算机系 数字电路 周斌 92
0450301
张三恺 男 计算机系 数据结构 陈长树
86
0450302 王薇薇 女 计算机系 高等数学 李刚 79
0450302
王薇薇 女 计算机系 英语 林弗然
94
0450302 王薇薇 女 计算机系 数字电路 周斌 74
0450302
王薇薇 女 计算机系 数据结构 陈长树
68
… … … … … … …
0420131
陈杰西 男 园林系 高等数学 吴相舆
97
0420131
陈杰西 男 园林系 英语 林弗然 79
0420131 陈杰西 男 园林系 植物分类学 花裴基 93
0420131
陈杰西 男 园林系 素描 丰茹
88
4.1.2 解决的方法
不合理的关系模式最突出的问题是数据冗余。而数据冗余的产生有着较为复杂的原因。
虽然关系模式充分地考虑到文件之间的相互关联而有效地处理了多个文件间的联系所产生的
冗余问题。但在关系本身内部数据之间的联系还没有得到充分的解决,正如例4.1所示,同
一关系模式中各个属性之间存在着某种联系,如学生与系、课程与教师之间存在依赖关系的
事实,才使得数据出现大量冗余,引发各种操作异常。这种依赖关系称之为数据依赖
(Data Independence)。
关系系统当中数据冗余产生的重要原因就在于对数据依赖的处理,从而影响到关系模式
本身的结构设计。解决数据间的依赖关系常常采用对关系的分解来消除不合理的部分,以减
少数据冗余。在例 4.1中,我们将教学关系分解为三个关系模式来表达:学生基本信息
(Sno,Sname,Ssex,Dname),课程信息( Cno,Cname,Tname,)及学生成
绩(Sno,Cno,Grade),其中 Cno为学生选修的课程编号;分解后的部分数据如表 4-
2、表4-3与表4-4所示。
表4-2 学生信息
Sno Sname Ssex Dname
0450301
张三恺 男 计算机系
0450302 王薇薇 女 计算机系
… … … …
0420131 陈杰西 男 园林系
表4-3 课程信息
Cno Cname Tname
GS01101 高等数学 李刚
YY01305
英语 林弗然
SD05103 数字电路 周斌
SJ05306
数据结构 陈长树
… …
GS01102
高等数学 吴相舆
ZF02101 植物分类学 花裴基
SM02204
素描 丰茹
表4-4 学生成绩
Sno Cno Grade
0450301 GS01101 83
0450301 YY01305 71
0450301 SD05103 92
0450301 SJ05306 86
0450302 GS01101 79
0450302 YY01305 94
0450302 SD05103 74
0450302 SJ05306 68
… … …
0420131 GS01102 97
0420131 YY01305
79
0420131 ZF02101 93
0420131 SM02204 88
对教学关系进行分解后,我们再来考察一下:
⑴ 数据存储量减少。
设有 n 个学生,每个学生平均选修 m 门课程,则表 4-1 中学生信息就有 4nm 之多。
经过改进后学生信息及成绩表中,学生的信息仅为 3n+mn。学生信息的存储量减少了
3(m-1)n。显然,学生选课数绝不会是 1,因而,经过分解后数据量要少得多。
⑵ 更新方便。
① 插入问题部分解决:对一位教师所开的无人选修的课程可方便地在课程信息表中插
入。但是,新分配来的教师、新成立的系或列入计划但目前不开课的课程,还是无法插入
要解决无法插入的问题,还可继续将系名与课程作分解来解决。
② 修改方便:原关系中对数据修改所造成的数据不一致性,在分解后得到了很好的解
决,改进后,只需要修改一处。
③ 删除问题也部分解决:当所有学生都退选一门课程时,删除退选的课程不会丢失该
门课程的信息。值得注意的是,系的信息丢失问题依然存在,解决的方法还需继续进行分
解。
虽然改进后的模式部分地解决了不合理的关系模式所带来的问题,但同时,改进后的
关系模式也会带来新的问题,如当查询某个系的学生成绩时,就需要将两个关系连接后进
行查询,增加了查询时关系的连接开销,而关系的连接代价却又是很大的。
此 外 , 必 须 说 明 的 是 , 不 是 任 何 分 解 都 是 有 效 的 。 若 将 表 4-1 分 解 为
( Sno , Sname , Ssex , Dname , ) 、 ( Sno , Cno , Cname , Tname ) 及
(Sname,Cno,Grade),不但解决不了实际问题,反而会带来更多的问题。
那么,什么样的关系模式需要分解?分解关系模式的理论依据又是什么?分解后能完
全消除上述的问题吗?回答这些问题需要理论的指导。下面几节将加以讨论。
4.1.3 关系模式规范化
由上面的讨论可知,在关系数据库的设计中,不是随便一种关系模式设计方案都“合
适”,更不是任何一种关系模式都可以投入应用的。由于数据库中的每一个关系模式的属性
之间需要满足某种内在的必然联系,设计一个好的数据库的根本方法是先要分析和掌握属
性间的语义关联,然后再依据这些关联得到相应的设计方案。在理论研究和实际应用中,
人们发现,属性间的关联表现为一个属性子集对另一个属性子集的“依赖”关系。按照属性
间的对应情况可以将这种依赖关系分为两类,一类是“多对一”的依赖,一类是“一对多”的。
“多对一”的依赖最为常见,研究结果也最为齐整,这就是本章着重讨论的“函数依赖”。“一
对多”依赖相当复杂,就目前而言,人们认识到属性之间存在两种有用的“一对多”情形,一
种是多值依赖关系,一种是连接依赖关系。基于对这三种依赖关系在不同层面上的具体要
求,人们又将属性之间的这些关联分为若干等级,这就形成了所谓的关系的规范化
(Relation Normalixation)。由此看来,解决关系数据库冗余问题的基本方案就是分析
研究属性之间的联系,按照每个关系中属性间满足某种内在语义条件,以及相应运算当中
表现出来某些特定要求,也就是按照属性间联系所处的规范等级来构造关系。由此产生的
一整套有关理论称之为关系数据库的规范化理论。
4.2 函数依赖
函数依赖是数据依赖的一种,函数依赖反映了同一关系中属性间一一对应的约束。函
数依赖是关系规范化的理论基础。
4.2.1 关系模式的简化表示
关系模式的完整表示是一个五元组:
R(U,D,Dom,F)
其中:R 为关系名;U 为关系的属性集合;D 为属性集 U 中属性的数据域;Dom 为属
性到域的映射;F 为属性集 U 的数据依赖集。
由于 D 和 Dom 对设计关系模式的作用不大,在讨论关系规范化理论时可以把它们简
化掉,从而关系模式可以用三元组来表示为:
R(U,F)
从 上 式 可 以 看 出 , 数 据 依 赖 是 关 系 模 式 的 重 要 要 素 。 数 据 依 赖 ( Data
Dependency)是同一关系中属性间的相互依赖和相互制约。数据依赖包括函数依赖
(Functional Dependency,简称 FD)、多值依赖( Multivalued Dependency,简
称 MVD)和连接依赖(Join Dependency,简称 JD)。
4.2.2 函数依赖的基本概念
1. 函数依赖
定义 4.1 设 R(U)是一个关系模式,U 是 R 的属性集合,X 和 Y 是 U 的子集。对于
R(U)的任意一个可能的关系 r,如果 r 中不存在两个元组,它们在 X 上的属性值相同,而
在 Y 上的属性值不同,则称“X 函数确定 Y”或“Y 函数依赖于 X”,记作 X→Y。
函数依赖和其他数据依赖一样,是语义范畴的概念。我们只能根据数据的语义来确定
函数依赖。例如,知道了学生的学号,可以惟一地查询到其对应的姓名、性别等,因而,
可以说“学号函数确定了姓名或性别”,记作“学号→姓名”、“性别”等。这里的惟一性并非只
有一个元组,而是指任何元组,只要它在 X(学号)上相同,则在 Y(姓名或性别)上的
值也相同。如果满足不了这个条件,就不能说它们是函数依赖了。例如,学生姓名与年龄
的关系,当只有在没有同名人的情况下可以说函数依赖“姓名→年龄”成立,如果允许有相
同的名字,则“年龄”就不再依赖于“姓名”了。
当 X→Y 成 立 时 , 则 称 X 为 决 定 因 素 ( Determinant ) , 称 Y 为 依 赖 因 素
(Dependent)。当 Y 不函数依赖于 X 时,记为 X\→Y。
如果 X→Y,且 Y→X,则记其为 X←→Y。
特别需要注意的是,函数依赖不是指关系模式 R 中某个或某些关系满足的约束条件,
而是指 R 的一切关系均要满足的约束条件。
函数依赖概念实际是是候选键概念的推广,事实上,每个关系模式 R 都存在候选键,
每个候选键 K 都是一个属性子集,由候选键定义,对于 R 的任何一个属性子集 Y,在 R 上
都有函数依赖 K→Y 成立。一般而言,给定 R 的一个属性子集 X,在 R 上另取一个属性子
集 Y,不一定有 X→Y 成立,但是对于 R 中候选键 K,R 的任何一个属性子集都与 K 有函数
依赖关系,K 是 R 中任意属性子集的决定因素。
剩余32页未读,继续阅读
资源评论
windfaddy
- 粉丝: 1
- 资源: 7
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功