第五章的关系数据库理论.ppt

第五章　关系数据库理论 关系数据库设计中存在的问题 示例： 考虑为管理职工的工资信息而设计一个关系模式。 存在的问题分类 插入异常 如果没有职工具有8级工资，则8级工资的工资数额就难以插入。 删除异常 如果仅有职工赵明具有4级工资，如果将赵明删除，则有关4级工资的工资数额信息也随之删除了。 数据冗余 职工很多，工资级别有限，每一级别的工资数额反复存储多次。 更新异常 如果将5级工资的工资数额调为620，则需要找到每个具有5级工资的职工，逐一修改。 关系数据库设计中存在的问题 解决之道：模式分解 有关学生的关系模式S(S# , SN , SD , DEAN , C# , G)  下面首先回顾一下关系模型的形式化定义。 一个关系模式应当是一个五元组 R（U, D, DOM, F） 说明: 关系名R，它是符号化的元组语义； 一组属性U； 属性组U中属性所来自的域D； 属性到域的映射DOM； 属性组U上的一组数据依赖F。  由于D和DOM对模式设计关系不大,因此我们在本章中把关系模式看作是一个三元组：R〈U,F〉 当且仅当U上的一个关系r满足F时,r称为关系模式R〈U,F〉的一个关系。  第一范式 关系,作为一张二维表,我们对它有一个最起码的要求：每一个分量必须是不可分的数据项。满足了这个条件的关系模式就属于第一范式（1NF）。我们的任务是研究模式设计，研究设计一个“好”的（没有“毛病”的）关系模式的办法。 数据依赖 数据依赖是通过一个关系中属性间值的相等与否体现出来的数据间的相互关系。它是现实世界属性间相互联系的抽象,是数据内在的性质,是语义的体现。 现在人们已经提出了许多种类型的数据依赖,其中最重要的是函数依赖(Functional Dependency简记为FD)和多值依赖(Multivalued Dependency简记为MVD)。 比如描述一个学生的关系,可以有学号(SNO),姓名(SNAME),系名(SDEPT)等几个属性。由于一个学号只对应一个学生,一个学生只在一个系学习。 因而当“学号”值确定之后,姓名和该生所在系的值也就被唯一地确定了。就象自变量x确定之后,相应的函数值f(x)也就唯一地确定了一样，我们说SNO函数决定SNAME和SDEPT,或者说SNAME，SDEPT函数依赖于SNO,记为∶SNO→SNAME,SNO→SDEPT。 建立一个描述学生的数据库 分析: 面临的对象有 学生(用学号SNO描述) 系(用系名SDEPT描述) 系负责人(用其姓名MN描述) 课程(用课程名CNAME描述) 成绩(G)。 现实世界的已知事实告诉我们∶ 1．一个系有若干学生,但一个学生只属于一个系； 2．一个系只有一名(正职)负责人； 3．一个学生可以选修多门课程,每门课程有若干学生选修； 4．每个学生学习每一门课程有一个成绩； 如果只考虑函数依赖这一种数据依赖,我们就得到了一个描述学校的数据库模式S〈U，F〉，它由一个单一的关系模式构成： U = { SNO，SDEPT，MN，CNAME，G } F = { SNO→SDEPT，SDEPT→MN，(SNO，CNAME)→G } 这组函数依赖如图5.l所示。 前面的学生模式有下述三个“毛病”： 1.插入异常如果一个系刚成立尚无学生,或者虽然有了学生但尚未安排课程。那么我们就无法把这个系及其负责人的信息存入数据库。 2.删除异常反过来,如果某个系的学生全部毕业了,我们在删除该系学生选修课程的同时,把这个系及其负责人的信息也丢掉了。 3.冗余太大比如,每一个系负责人的姓名要与该系每一个学生的每一门功课的成绩出现的次数一样多。这样,一方面浪费存储,另一方面系统耍付出很大的代价来维护数据库的完整性。比如某系负责人更换后,就必须逐一修改有关的每一个元组。 为什么会发生插入异常和删除异常呢 ? 这是因为这个模式中的函数依赖存在某些不好的性质。假如我们把这个单一的模式改造一下,分成三个关系模式： S（SNO,SDEPT, SNO→SDEPT）； SG（SNO,CNAME,G, (SNO,CNAME)→G）； DEPT（SDEPT,MN, SDEPT→MN）； 这三个模式都不会发生插入异常、删除异常的毛病,数据的冗佘也得到了控制。 一个模式的函数依赖会有哪些不好的性质,如何改造一个不好的模式,这就是下一节规范化理论讨论的内容。  定义5.1函数依赖 定义5.1 设R(U)是属性集U上的关系模式。X,Y是U的子集。若对于R(U)的任意一个可能的关系r，r中不可能存在两个元组在X上的属性值相等,而在Y上的属性值不等,则称X函数确定Y或Y函数依赖于X，记作X→Y。 函数依赖：设R(U)是属性集U上的关系模式，X , Y ? U， r是R(U