第六章 关系数据理论1.ppt

第六章 关系数据设计理论 问题提出 规范化 前面我们已经讨论了关系数据库的基本概念、关系模型的三个部分以及关系数据库的标准语言。 但是还有一个很基本的问题尚未涉及，针对一个具体问题，应该如何构造一个适合于它的数据库模式，即应该构造几个关系模式，每个关系由哪些属性组成等。 这是数据库设计的问题，确切地讲是关系数据库逻辑设计问题。 6.1 问题的提出 下面首先回顾一下关系模型的形式化定义。 一个关系模式应当是一个五元组。 R（U, D, DOM, F） 其中R为关系名，U为组成该关系的属性名集合，D为属性组U中属性所来自的域，DOM为属性向域的映象集合，F为属性间数据的依赖关系集合。 6.1 问题的提出 由于D和DOM对模式设计关系不大，因此我们在本章中把关系模式看作是一个三元组：R〈U,F〉 当且仅当U上的一个关系r满足F时，r称为关系模式R〈U,F〉的一个关系。 关系，作为一张二维表，我们对它有一个最起码的要求：每一个分量必须是不可分的数据项。满足了这个条件的关系模式就属于第一范式（1NF）。 我们的任务是研究模式设计，研究设计一个“好”的（没有“毛病”的）关系模式的办法。 6.1 问题的提出 数据依赖对关系模式的影响 数据依赖是一个关系内部属性与属性之间的一种约束关系。这种约束关系是通过一个关系中属性间值的相等与否体现出来的数据间的相互联系。 它是现实世界属性间相互联系的抽象，是数据内在的性质，是语义的体现。 6.1 问题的提出 现在人们已经提出了许多种类型的数据依赖，其中最重要的是函数依赖(Functional Dependency 简记为FD)和多值依赖(Multivalued Dependency简记为MVD)。 函数依赖极为普遍地存在于现实生活中。 比如描述一个学生的关系,可以有学号(SNO),姓名(SNAME),系名(SDEPT)等几个属性。 6.1 问题的提出 由于一个学号只对应一个学生,一个学生只在一个系学习。因而当“学号”值确定之后,姓名和该生所在系的值也就被唯一地确定了。 就象自变量x确定之后,相应的函数值f(x)也就唯一地确定了一样，我们说SNO函数决定SNAME和SDEPT,或者说SNAME，SDEPT函数依赖于SNO,记为：SNO→SNAME,SNO→SDEPT。 6.1 问题的提出 现在我们要建立一个数据库来描述学生的一些情况。 涉及的对象有:学生(用学号SNO描述),系(用系名SDEPT描述),系负责人(用其姓名Mname描述),课程(用课程号Cno描述)和成绩(Grade)。于是得到一组属性 。 U = { SNO，SDEPT，Mname，Cno，Grade } 6.1 问题的提出 由现实世界的已知事实得知： 一个系有若干个学生，但一个学生只属于一个系； 一个系只有一名（正职）负责人； 一个学生可以选修多门课，每门课有若干学生选修； 每个学生学习每一门课程有一个成绩； 于是得到属性组U上的一组函数依赖： F = { SNO→SDEPT，SDEPT→Mname，(SNO，Cno)→Grade } 这组函数依赖如下图所示。 6.1 问题的提出 如果只考虑函数依赖这一种数据依赖,我们就得到了一个描述学校的数据库模式Student〈U，F〉，它由一个单一的关系模式构成： U = { SNO，SDEPT，Mname，Cno，Grade } F = { SNO→SDEPT，SDEPT→Mname，(SNO，Cno)→Grade } 这个模式有下述四个问题： 1.冗余太大 比如,每一个系负责人的姓名要与该系每一个学生的每一门功课的成绩出现的次数一样多。这样,将浪费大量的存储空间。 2.更新异常 比如,某系负责人更换后,就必须逐一修改有关的每一个元组。 6.1 问题的提出 3.插入异常 如果一个系刚成立尚无学生, 就无法把这个系及其负责人的信息存入数据库。 4.删除异常 如果某个系的学生全部毕业了,我们在删除该系学生信息的同时,把这个系及其负责人的信息也丢掉了。 6.1 问题的提出 为什么会发生插入异常和删除异常呢 ?这是因为这个模式中的函数依赖存在某些不好的性质。假如我们把这个单一的模式改造一下,分成三个关系模式： S〈SNO,SDEPT, SNO→SDEPT〉； SC〈SNO,Cno,Grade, (SNO,Cno)→ Grade 〉； DEPT〈SDEPT,Mname, SDEPT→Mname〉； 这三个模式都不会发生插入异常、删除异常的毛病,数据的冗佘也得到了控制。 一个模式的函数依赖会有