函数依赖

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

5.2 函 数 依 赖

在数据依赖现象的讨论中,函数依赖是最为常见和最为基本的情形。本节将较为详细地讨论函数依赖及其相关问题。

数据库理论及应用基础 33

5.2.1 函数依赖基本概念

1. 函数依赖

设R(U)是属性集U 上的关系模式,X 、Y 是U 的一个子集。r 是R(U)中任意给定的一个关系。若对于r 中任意两个元组s 和t ,当s[X] = t[X]时,就有s[Y] = t[Y],则称属性子集X 函数决定属性子集Y 或者称Y 函数依赖于X(Functional Dependence),否则就称X 不函数决定Y 或者称Y 不函数依赖于X 。

当Y 函数依赖于X 时,则记其为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 中任意属性子集的决定因素。

2. 函数依赖的3种基本情形

函数依赖可以分为3种基本情形。

(1) 平凡与非平凡函数依赖

如果X →Y ,但Y 不是X 的子集,则称X →Y 是非平凡函数依赖(Nontrivial Functional Dependence),否则称为平凡函数依赖(Trivial Functional Dependence)。

按照函数依赖的定义,当Y 是X 的子集时,Y 自然是函数依赖于X 的,这里“依赖”不反映任何新的语义。通常意义下的函数依赖一般都是指非平凡依赖。

(2) 部分与完全函数依赖

如果X →Y ,但对于X 中的任意一个真子集X',都有Y 不依赖于X',则称Y 完全依赖(Full Functionalal Dependency)于X ,否则称为Y 不完全依赖于X 。当Y 完全依赖于X 时,

记为X Y 。如果X →Y ,但Y 不完全函数依赖于X ,则称Y 对X 部分函数依赖(Partial Functional Dependency),记为 X Y 。 ⎯→⎯

F

⎯→⎯

P 如果Y 对X 部分函数依赖,X 中的“部分”就可以确定对Y 的关联,从数据依赖的观点来看,X 中存在“冗余”属性。

(3) 传递与直接函数依赖

设有两个非平凡函数依赖X →Y 和Y →Z ,而且X 不函数依赖于Y ,则称Z 传递函数(Transitive Functional Dependency)依赖于X 。

在上述定义中,X 不函数依赖于Y 意味着X 与Y 不是一一对应;否则Z 就是直接函数依赖于X ,而不是传递函数依赖于X 了。

按照函数依赖的定义,可以知道,如果Z 传递依赖于X ,则Z 必然函数依赖于X 。

数据库理论及应用基础 34 如果Z 传递依赖于X ,说明Z 是“间接”依赖于X ,从而表明X 和Z 之间的关联较弱。

3. 函数依赖与数据冗余

由前面的分析和函数依赖相应概念可知,部分函数依赖存在“冗余属性”,传递函数依赖表现“间接”的弱数据依赖,因此是产生数据冗余的主要原因。

例5-2 设有学生关系模式S :S(S#,Sn,Dn,Dh,Cn,G)

其中S#、Sn 、Dn 、Dh 、Cn 和G 分别表示属性:学生学号、学生姓名、所在系名称、所在系的系主任、课程名称和课程成绩。不难得到S 有惟一候选键{S#,Cn},此时各个属性之间的关系如图5.1所示。

图5.1 属性间依赖关系

此时有{S#,Cn} Sn 和{S#,Cn} Dn ,同时有S#→Dn →Dh 。显然,这些都会带来数据冗余。

⎯→⎯

P ⎯→⎯P

由此可以理解,如果要消除数据冗余和由数据冗余引发的数据异常现象,适当处理好关系模式中的部分函数依赖和传递函数依赖,就称为需要着力完成的基本工作。事实上,关系数据库规范化理论正是按照相应的思路展开的。 5.2.2 键的函数依赖表述

前面已经说明,函数依赖实际上可以看作是候选键概念的推广,因此可以从函数依赖角度分析和定义候选键。

(1) 超键:设有关系模式R(U),K 是R(U)中的属性子集,如果K →U ,则称K 为R 的超键(Super Key)。

(2) 候选键(键):设有关系模式r(U),K 是r(U)中的属性子集,如果K U ,则称K 为r 的候选键(Candidate Key)。候选键一定是超键,而且是“最小”的超键,即K 的任意一个真子集都不再是r 的超键。总之,候选键是能够起到标识作用的关系模式r(U)的最小属性子集。候选键有时也简称为“键”。

⎯→⎯

F

(3) 主键:一个关系r 的候选键可以有多个。如果在其中选定一个,则称该候选键为主

数据库理论及应用基础35

键(Prime Key)。

(4) 外键:设属性子集k不是关系模式R的候选键,但是另一个关系模式S的候选键,则称k是r的外键(Foreign Key)。

如前所述,主键起着数据导航的作用,而主键和外键的结合实际上提供了描述两个关系中元组间的联系手段。在数据库设计当中,常常需要根据实际情形来增设外键以表示两个关系中元组间的联系,例如在两个关系进行连接运算时,本质上就是外键在发挥作用。

5.2.3 主属性与非主属性

候选键中的任意一个属性元素称为主属性(Prime Attribute);不在候选键中的属性称为非主属性(Nonprime Attribute)或者非键属性(Non-Key Attribute)。

由上述定义可知,一个关系模式中的所有属性或者是主属性,或者是非主属性,二者必居其一。从函数依赖观点来看,主属性和非主属性有着值得注意的差异。对于非主属性,可以“无条件”地考虑其部分函数依赖和传递函数依赖;对于主属性,部分函数依赖和传递函数依赖只对于不含有该属性的属性子集才有实际意义。在5.5节的范式讨论中,第二范式和第三范式实际上是针对非主属性,而BC范式可以看作是着眼于主属性的。

相关文档
最新文档