关系模型设计依据.ppt

数据库系统基础教程;属性之间的联系描述应当具有某种“内在”性质，不能只根据属性之间的某些外在关联表征，随意将一些属性放在一起组成一个关系模式，这样将可能引发一系列问题，其中最突出的就是数据冗余以及由此带来的操作异常。也就是说，如果数据模式设计不当，就会出现数据冗余；有了数据冗余，就可能产生操作异常。 ;数据冗余（Data Redundancy）是指同一数据在一个或者多个数据文件中重复存储。系统中如果出现数据冗余，不仅会大量占用消耗系统资源，造成不必要开销，更严重的是会带来各种数据操作异常，对数据库性能正常发挥造成极大影响。;从数据结构的角度考察，如果对多个文件之间和同一个文件中数据之间的联系考虑不周或者处理不当，就有可能导致数据冗余。这里有两个层面上的问题： ● 多个文件之间的联系。 ● 同一个文件中数据之间的联系。;关系数据库较好地处理了文件层面的联系，但并不意味着数据层面上的联系可以自动解决。恰恰相反，此时，第二个层面上问题反而会凸现出来。 在关系数据库中，同一关系模式中各个属性子集之间的依赖关系，通常称为数据依赖（Data Independence）。关系系统当中数据冗余产生的重要原因就在于对数据依赖处理不当，也就是在于关系模式本身的结构设计可能存在缺陷。;关系数据库中数据依赖的考虑来源于关系结构本身。在关系模式中，各个属性一般说来是有关联的，但是这些关联有着不同的表现形式。 ① 一部分属性的取值能够决定这个关系表中所有其它属性的取值，也就是部分属性构成的子集合与关系的整个属性集合的关联。事实上，一个关系可以有一个或者多个候选键，其中一个可以选为主键。主键的值唯一确定其它属性的值，它是一个元组存在的标识，也是各个元组相互区别的标识。既然作为“标识”，其取值就必须“确定无疑”，所以候选键的值不可重复出现，也不能全部或者部分设为空值。;② 一部分属性的取值决定表中其它若干属性的取值，也就是一些部分属性组成的子集合与另一些部分属性组成的子集合的关联。这种数据关联可以看作是关系结构中“候选键”问题的推广，而通常所讲的“数据依赖”主要是指这种意义下的问题。;解决关系数据库冗余问题的基本方案就是分析研究属性之间的联系，按照每个关系中属性间满足某种内在语义条件，以及相应运算当中表现出来某些特定要求，也就是按照属性间联系所处的规范等级来构造关系模式。由此产生的一整套有关理论称之为关系模式规范化理论或关系模式设计理论。在数据管理中，数据冗余一直是影响系统性能的重大问题，规范化理论就成为关系数据库模式设计中的核心部分。 ;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。;当Y函数依赖于X时，则记为　X→Y。如果X→Y，也称X为决定因素（Determinant factor）， Y为依赖因素（Dependent factor）。当Y不函数依赖于X，则记为　X／→Y 如果X→Y，且Y→X，则记为　X←→Y。 ;2.函数依赖三种类型 （1）平凡与非平凡函数依赖 如果X→Y，但Y不是X的子集，则称X→Y是非平凡函数依赖，否则称为平凡函数依赖。 按照函数依赖的定义，当Y是X的子集时，Y“自然”是函数依赖于X的，这里“依赖”不反映任何新的语义。通常意义下的函数依赖一般都是指非平凡依赖。;（2）部分与完全函数依赖 如果X→Y，但对于X中的任意一个真子集X‘，都有Y不依赖于X’，则称Y完全依赖于X。当Y完全依赖于X时，记为X Y。 如果X→Y，但Y不完全函数依赖于X，则称Y对X部分函数依赖，记为 X Y。;（3）传递与直接函数依赖 设有两个非平凡函数依赖X→Y和Y→Z，并且X不函数依赖于Y，则称Z传递函数（Transitive Functional Dependency）依赖于X。 在上述定义中，X不函数依赖于Y意味着X与Y不是一一对应；否则Z就是直接函数依赖于X，而不是传递函数依赖于X了。;3. 键的形式化定义 （1）超键 设有关系模式R（U），K是R（U）中的属性子集，如果K→U，则称K为R的超键 （2）候选键 设有关系模式R（U），K是R（U）中的属性子集，如果K U，则称K为R的候选键 ;（3）主键 一个关系模式R的候选键可以有多个。如果在其中选定一个，则称该候选键为主键。 （4）外键 设U属性子集k不是关系模式R的候选键，但是另一个关系模式S的候选键，则称k是R的外键。;为了表述简洁和推理方便，在本章的以下部分，对有关记号使用做如下约定： ● 如果声明X、Y等是属性子集，则将X∪Y简记为XY。 ● 如果声明A、