没有合适的资源?快使用搜索试试~ 我知道了~
第6章-关系数据库规范化理论.doc
1.该资源内容由用户上传,如若侵权请联系客服进行举报
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
版权申诉
0 下载量 93 浏览量
2021-10-03
14:52:13
上传
评论
收藏 154KB DOC 举报
温馨提示
试读
11页
第6章-关系数据库规范化理论.doc
资源推荐
资源详情
资源评论
第 6 章 关系数据库标准化理论
一个关系数据库模式由一组关系模式组成,一个关系模式由一组属性名组成。关系数据库
设计,就是如何把已给定的相互关联的一组属性名分组,并把每一组属性名组成关系的问题。
然而,属性的分组不是唯一的,不同的分组对应着不同的数据库应用系统,它们的效率往往相
差很远。
为了使数据库设计合理可靠,简单实用,长期以来,形成了关系数据库设计的理论——标
准化理论。
6.1 关系标准化的作用
标准化,就是用形式更为简洁,结构更加标准的关系模式取代原有关系模式的过程。
如果将两个或两个以上实体的数据存放在一个表里,就会出现以下三个问题:
数据冗余度大
插入异常
删除异常
所谓数据冗余,就是相同数据在数据库中多次重复存放的现象。数据冗余不仅会浪费存储
空间,而且可能造成数据的不一致性。
插入异常是指,当在不标准的数据表中插入数据时,由于实体完整性约束要求主码不能为
空的限制,而使有用数据无法插入的情况。
删除异常是指,当不标准的数据表中某条需要删除的元组中包含有一部分有用数据时,就
会出现删除困难。
〔以 P98 工资表为例〕
解决上述三个问题的方法,就是将不标准的关系分解成为多个关系,使得每个关系中只包
含一个实体的数据。
〔讲例子解〕
当然,改良后的关系模式也存在另一问题,当查询职工工资时需要将两个关系连接后方能
查询,而关系连接的代价也是很大的。
那么,什么样的关系需要分解?分解关系模式的理论依据又是什么?分解完后能否完全消
除上述三个问题?答复这些问题需要理论指导。下面,将加以讨论:
6.2 函数依赖
属性间关系
实体间的联系有两类:一类是实体与实体之间联系;另一类是实体内部各属性间的联系。
数据库建模一章中讨论的是前一类,在这里我们将学习第二类。
和第一类一样,实体内部各属性间的联系也分为 1:1、1:n 和 m:n 三类:
例:职工〔职工号,,身份证号码,职称,部门〕
1、 一对一关系〔1:1〕
设 X、Y 是关系 R 的两个属性〔集〕。如果对于 X 中的任一具体值,Y 中至多有一个值与
之对应,反之,对于 Y 中的任一具体值,X 中也至多有一个值与之对应,则称 X、Y 两属性间是
一对一关系。
如本例职工关系中职工号与身份证号码之间就是一对一关系。
1
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〕
其中最重要的是函数依赖和多值依赖。
函数依赖
函数依赖,是属性之间的一种联系。在关系 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,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 的某一部分元组的集合,例如:地测学院的学生关系中只包含
了地测学院学生的数据,所以它是长安大学学生关系的一个子集。
6. 码的定义
前面,我们对码进行了直观化的定义,下面用函数依赖的概念对码作出较为精确的形式化
的定义:
设 K 是关系模式 R〔U,F〕中的属性或属性组,K’是 K 的任一子集。假设 K→U,而不存
在 K'→U,则 K 为 R 的候选码〔Candidate Key〕
假设候选码多于一个,则选其中的一个为主码〔Primary Key〕;
包含在任一候选码中的属性,叫做主属性〔Primary Attribute〕;
不包含在任何码中的属性称为非主属性〔Nonprime Attribute〕或非码属性〔Nonkey
Attribute〕
关系模式中,最简单的情况是单个属性是码,称为单码〔Single Key〕;最极端的情况
2
X Y
是整个属性组是码,称为全码〔All-Key〕。
前面已多次遇到单码的情况,下面是一个全码的例子:
签约〔演员名,制片公司,电影名〕
外码:设有两个关系 R 和 S,X 是 R 的属性或属性组,并且 X 不是 R 的码,但 X 是 S 的码
〔或与 S 的码意义相同〕,则称 X 是 R 的外部码〔Foreign Key〕,简称外码或外键。
如:职工〔职工号,,性别,职称,部门号〕
部门〔部门号,部门名, ,负责人〕
其中职工关系中的“部门号”就是职工关系的一个外码。
在此需要注意,在定义中说 X 不是 R 的码,并不是说 X 不是 R 的主属性,X 不是码,但可
以是码的组成属性,或者是任一候选码中的一个主属性。
如:学生〔学生号,,性别,年龄…〕
课程〔课程号,课程名,任课老师…〕
选课〔学生号,课程号,成绩〕
在选课关系中,〔学生号,课程号〕是该关系的码,学生号、课程号又分别是组成主码的属
性〔但单独不是码〕,它们分别是学生关系和课程关系的主码,所以是选课关系的两个外码。
关系间的联系,可以通过同时存在于两个或多个关系中的主码和外码的取值来建立。如要
查询某个职工所在部门的情况,只需查询部门表中的部门号与该职工部门号相同的记录即可。
所以,主码和外码提供了一个表示关系间联系的途径。
函数依赖和码的唯一性
由上述码的形式化定义,我们可以说:码是由一个或多个属性组成的,可唯一标识元组的
最小属性组。
码在关系中总是唯一的,即一个码函数唯一地决定一行。如果码的值重复,则整个元组都
会重复。否则,违反了实体完整性规则。而元组的重复则表示存在两个完全相同的实体,这显
然是不可能的,所以码是不允许重复取值的。
所以,只有当某个属性或属性组能够函数决定关系中的每一个其它的属性,且该属性组的
任何一个真子集都做不到这一点时,该属性或属性组才是该关系的码。
函数依赖是一个与数据有关的事物规则的概念。如果属性 B 函数依赖于属性 A,那么假设
知道了 A 的值,则完全可以找到 B 的值。这并非是可以由
A
的值计算出
B
的值,而是逻辑上只
能存在一个
B
的值。
6.3 关系模式的标准化
一、非标准化的关系
当一个表中存在还可以再分的数据项时,这个表就是非标准化的表。非标准化表存在两种
情况:
表中具有组合数据项〔P102 表 6-4〕
表中具有多值数据项〔P103 表 6-5〕
例:
那么什么是标准化关系呢?
当一个关系中的所有分量都是不可再分的数据项时,该关系是标准化的。即当表中不存在
组合数据项和多值数据项,只存在不可分的数据项时,这个表是标准化的。
3
职工号 工资 基本工 资 职务工资 工龄工 资 1002 张 三
1000800200
职工号 职称 系名 系办地址 学历 毕业年份 001 张三 教授 电脑 1305 大学
研究生 1963
1982
剩余10页未读,继续阅读
资源评论
zhangao_fengg
- 粉丝: 16
- 资源: 5万+
下载权益
C知道特权
VIP文章
课程特权
开通VIP
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功