第四讲 关系数据库规范化理论.

函数依赖

函数依赖和别的数据依赖一样是语义范畴的概 念．我们只能根据语义来确定——个函数依赖． 例如姓名→年龄这个函数依赖只有在没有同名 人的条件下成立．如果允许有相同名字，则年 龄就不再函数依赖于姓名了．设汁者也可以对 现实世界作强制的规定．例如规定不允许同名 人出现，因而使姓名→年龄函数依赖成立。这 样当插入某个元组时这个元组上的属性值必须 满足规定的函数依赖，若发现有同名人存在， 则拒绝装入该元组．

第四讲 关系数据库规范化理论

规范化是关系数据库逻辑设计的另一种方法， 它和ER模型的出发点不一样，但是一个基于规 范化的关系设计和一个由ER模型转换成的关系 设计几乎得到相同的结果。两种方法具有互补 性。规范化方法中，从一个将被建模的现实世 界的情形出发，分析数据项之间的相互影响， 通过无损分解使数据库的逻辑设计趋于合理， 把低一级的关系模式分解为若干个高一级的关 系模式。
2NF
若关系模式R 1NF，并且每一个非主属性都完全函数依赖于R 的码，则R 2NF。 把SLC分解为两个关系模式：
SL（学号，系别，宿舍） SC（学号，课程号，成绩）
关系模式SL（学号，系别，宿舍）存在：
插入异常 删除异常 数据冗余度大 修改复杂

关系模式的设计问题

更新异常(Update Anomaly)：如果更改表所对应的 某个实体实例或者关系实例的单个属性时，需 要将多行更新，那么就说这个表存在更新异常。 数据冗余引起更新异常。 删除异常(Delete Anomaly) ：如果删除表的某一 行来反应某个实体实例或者关系实例消失时， 会导致丢失另一个不同实体实例或者关系实例 的信息，而这是我们不希望丢失的，那么就说 这个表存在删除异常。
工资管理模式1
工号 001 002 姓名 张三 李四 级别 一级 三级 基本 800 1200 津贴 2000 4000 考勤扣款 120 20 违纪扣款 10 实发额 2670 5180
说明：应发工资额为基本工资和津贴之和，应发工 资减去扣款项目为实发工资额，基本工资和津贴的 额度由级别决定，扣款额根据实际情况决定。

函数依赖 设R是一个关系，X和Y是R中两个属性。若R中X的任 何一个值，仅有一个Y的值与之对应，则称为R的属 性Y函数依赖于属性X，记为X Y。

完全函数依赖 如果属性Y函数依赖于复合属性X，而且不与X的任何 真子集函数依赖，则称属性Y完全函数依赖于复合属 性X。
部分函数依赖 若X Y，但不是完全函数依赖，

关系模式的设计问题

存在大量数据冗余的数据库模式不是良好的数据 库模式。因为大量的数据冗余不仅造成存储空间 的浪费，存取效率的低下，而且使得数据信息的 更新变得繁琐复杂，另外还隐藏着破坏数据一致 性完整性的危险。 良好的数据库模式不存在数据冗余、插入异常、 删除异常和更新异常等问题。重新分配数据项到 不同的表中，能够消除这些问题，这恰是规范化 过程将实现的任务。
第二范式2NF的[定义] 如果关系R属于1NF，且每个非主属性完全函数依赖于主关键字，则关系模式R属于 第二范式。
非主属性是指不包含在任何主键中的属性。满足2NF的条件：消除了从 非主属性 到 主属性 的“部分函数依赖” .
规 范 化 处 理 后
存在部分函数依赖的关系模式存在的问题。 1 数据冗余、更新异常 2 插入、删除异常
关系模式的设计问题
工资管理模式1存在以下问题： 1）扣款项目不是每个职工都发生，数据冗余 ，浪费空间。

2）当公司出现其他扣款项目时，必须修改模 式结构。

3）应发工资额由级别决定，当没有职工级别 是二级时，二级的基本工资和津贴无法添加，插 入异常。删除张三信息时，把一级与应发工资额 的对应规则也删除了，删除异常。修改级别与应 发工资额的对应规则时，必修修改多行，更新异 常。
第四讲 关系数据库规范化理论
关系模式的设计问题 函数依赖
关系模式的分解特性
范式和关系模式规范化
关系模式的设计问题

关系实质上是—张二维表．表的每一行叫做一个 元组，每一列称为—个属性．因此，一个元组就 是该关系所涉及的属性集的笛卡尔积的一个元 素．关系是元组的集合，也就是笛卡尔积的一个 子集．关系模式就是这个元组集合的结构上的描 述． 现实世界的许多已知事实限定了关系模式的所有 可能的关系必须满足—定的完整性约束条件．这 些约束或者通过对属性取值范围的限定，例如职 工年龄小于65岁(65岁以后必须退休)，或者通过属 性值间的相互关连(主要体现于值的相等与否)反映 出来．后者称为数据依赖，它是数据库模式设计 的关键．关系模式应当刻划这些完整性约束条 件．

关系模式的设计问题
–下图模式2是改进后的职工工资管理关系模式。
工资管理模式2
工号 001 001 002 姓名 张三 张三 李四 级别 一级 一级 三级 基本 800 800 1200 津贴 2000 2000 4000 扣款项目 考勤 违纪 考勤 扣款金额 120 10 20

说明：该模式解决了问题2，当公司出现其他扣款项 目时，无须修改模式结构，比模式1合理。


插入异常(Insert Anomaly) ：如果某个实体或者 实例信息随着另一个实体或实例信息的存在而 存在，在缺少另一个实体或实例信息时，无法 表示这个实体或者实例信息，而这是我们不希 望看到的，那么就说这个表存在插入异常。
关系模式的设计问题

异常情况举例：

下图模式1是管理职工工资的一个常见的简化的关 系模式。
函数依赖
一些记号和术语

X→Y，但Y不属于X，则称X→Y是非平凡的函数 依赖．若不特别声明，我们总是讨论非平凡的 函数依赖． 若X→Y，则X叫做决定因素(Determinant)． 若X→Y，Y→X，则记作X←→Y．


若Y不函数依赖于X，则记作x不依赖于y．
第四讲 关系数据库规范化理论
函数依赖
函数决定的最大属性集合Y称为属性X的闭包 X+，X+={属性Y|X→Y在F+中}。从X求出X+并不 难。
例：工资管理模式2中的属性闭包（推导 过程见后页）： 工号+={工号,姓名,级别,基本,津贴}； 级别+={级别,基本,津贴}；
{工号,扣款项目}+={工号,姓名,级别,基 本,津贴,扣款项目,扣款金额}。
传递函数依赖： 在一个关系模式中，若存在 A-->B 和 B-->C， 则必有 A-->C 成立，即C传递函数依赖于A。 如上表中存在 A-->C 和 C-->D ，即“专业”传递函数依赖于“学号”。 第三范式3NF的[定义] 如果R属于2NF，且每个非主属性都不传递函数依赖于主关键字，则关系模式R属于 第三范式。 满足3NF的条件：消除了“传递函数依赖” 修改上表

码或关键字 设K为关系模式R<U,F>中的属性或属性组合。 若K->U，则K称为R的一个侯选码（candidate key）。若关系模式R中有多个侯选码，则选 定其中的一个做为主码（primary key）。
外码(Foreign Key)：是另一关系主码 主属性：侯选码中的属性 非主属性：不包含在任何码中的属性

关系模式的设计问题

为了使数据库设计的方法走向完备，人们研究了 规范化理论．从1971年起，E．F．Codd就提出了这 一理论，目前规范化理论的研究已经有了很大进 展．
关系模式的设计问题

关系模型要求关系必须是规范化的，即要求数据 库表中不允许含有多值属性和含有内部结构，关 系的每一个分量必须是一个不可分的的数据项， 不允许表中还有表。遵守这样规则的表称为第一 范式。这是关系数据库设计过程中的一个最基本 的约束 满足第一泛式不能保证数据库模式是良好的数据 库模式。所谓良好的数据库模式的标准是什么？ 如何实现？这就是关系模式的设计问题。
建筑9902班 服装9901班
建筑设计专业 服装设计专业


总结
1NF2NF 3NF BCNF 4NF 5NF
1NF
如果一个关系模式R的所有属性都是不可分的基本数据项，则 R1NF SLC(学号，系别，宿舍，课程号，成绩) 插入异常 学号->系别，学号->宿舍，系别->宿舍 删除异常 （学号，课号） ->成绩 数据冗余度大 修改复杂
Байду номын сангаас三范式(3NF) 与传递函数依赖
[思考]下表虽然满足2NF，但仍是一个 蹩脚的设计 ：
学号 9901001 9901002 9901003 9903003 9903002 9905056 姓名 陈小蕾 李泉勇 张小芳 笪小波 李群 高明 班级 计算机9901班 计算机9901班 计算机9901班 建筑9902班 建筑9902班 服装9901班 专业 计算机应用专业 计算机应用专业 计算机应用专业 建筑设计专业 建筑设计专业 服装设计专业
关系模式的设计问题
工资管理模式2仍然存在问题： 1）职工信息和应发项目随扣款项目重复，数 据冗余。

2）应发工资额由级别决定，当没有职工级别 是二级时，二级的基本工资和津贴无法添加，插 入异常。删除张三信息时，把一级与应发工资额 的对应规则也删除了，删除异常。修改级别与应 发工资额的对应规则时，必修修改多行，更新异 常。

[例] 考虑关系模式；学生(学号,姓名,课程,分数) 设有函数依赖：学号姓名,{学号,课程}分 数。 上述两个函数依赖都是完全依赖。
由这两个函数依赖可以推出{学号,课程}姓 名，
这个新的函数依赖是部分依赖。
工资管理模式2属于1NF，但不属于2NF， 因为非主属性‘姓名’、‘级别’、 ‘基本’、‘津贴’是部分函数依赖 于候选键{工号,扣款项目}的
• 定义：设关系模式R的属性集是U，X 是U的一个子集。如果X→U在R上成 立，那么称X是R的一个超键。如果 X→U在R上成立，但对于X的任一个 真子集X1都有X1→U不成立，那么称 X是R的一个候选键。