数据库-04-第四章1-3节

第4章关系模式的规范化设计理论第4章关系模式的规范化设计理论问题：数据库中存放的基本表是否都是用户工作中实际使用的数据表格？答：不是。如第1章Students,Courses,Reports通俗地讲：如何将企事业单位实际工作中的表格转换成数据库模式——数据库模式设计建立关系数据库系统首要任务:设计关系模式；讨论问题：对一个具体的应用问题，如何构造一个适合于它的数据库模式。第4章关系模式的规范化设计理论4.2关系模式的函数依赖4.3关系模式的规范化4.4关系模式的分解特性4.1问题的提出4.1问题的提出4.1.2异常原因分析4.1.3异常问题的解决4.1.1关系模式可能存在的异常4.1.1关系模式可能存在的异常(1)例4.1以学生选课背景为，假设教务处给了我们一个实际工作需要的数据表格如下表4.1关系StudyInfo学号Sno姓名Sname系名DeptName系主任DeptHead课程Cname成绩Grade20010101张华Computer黄山英语8520010101张华Computer黄山高等数学9020010101张华Computer黄山数据库92………20010101张华Computer黄山操作系统8820010102黄河Computer黄山英语92………20010102黄河Computer黄山高等数学86………20010601刘林Math朱红英语8820010601刘林Math朱红高等数学84………20010601刘林Math朱红数学分析904.1.1关系模式可能存在的异常(1)根据以上数据表格，我们可以不加思索地设计如下关系模式：StudyInfo(Sno,Sname,DeptName,DeptHead,Cname,Grade)且可以发现{Sno，Cname}是唯一候选键，因此是主键。这样，前面的表4.1就是关系模式StudyInfo的一个实例—关系。4.1.1关系模式可能存在的异常(2)但StudyInfo存在几个异常问题：⑴插入异常。比如一个刚刚成立的系，但尚未招收学生，则因属性Sno为空，导致诸如系主任姓名之类的信息无法存入数据库；同样，没被学生选修的课程信息也无法存入数据库。⑵删除异常。如一个系的学生毕业了，删除学生记录时系主任姓名等信息也一起删除了。⑶冗余过多。如一个系的系名、系主任姓名都要与该系学生每门课的成绩出现的次数一样多。既浪费存储空间又要付出很大的代价来维护数据库的完整性。且当系主任更换后，必须逐一修改该系学生选修课程的每一个元组。4.1.2异常原因分析(1)例子启示：“好”的模式不应当发生插入异常和删除异常，且数据冗余应尽可能地少。结论：关系模式StudyInfo“不怎么好”或“不好”StudyInfo“不好”的原因：关系模式的属性之间存在过多的“数据依赖”。非形式地说：数据依赖是指关系中属性值之间的相互联系，它是现实世界属性间相互联系的体现，是数据之间的内在性质，是语义的体现。已经有多种类型的数据依赖，其中最重要的是函数依赖(FunctionalDependence，简称FD)和多值依赖(MultiValuedDependence，简称MVD)。4.1.2异常原因分析(2)函数依赖极为普遍地存在于现实生活中。对关系StudyInfo，因一个学号Sno仅对应一个学生，一个学生只在一个系注册学习。因而，当学号Sno的值确定之后，姓名Sname和他所在系DeptName的值也就被唯一地确定了。就象y=f(x)中自变量x的值确定之后，相应函数f(x)的值也就唯一地确定一样.我们说Sno决定Sname和DeptName，或者说Sname，DeptName函数依赖于Sno，记作:SnoSname，SnoDeptName。4.1.2异常原因分析(3)对关系模式StudyInfo，其属性集U={Sno,Sname,DeptName,DeptHead,Cname,Grade}。根据学校管理运行的实际情况，我们还知道：⑴一个学生只有一个学号，即SnoSname；⑵一个系有若干学生，但一个学生只属于一个系即SnoDeptName；⑶一个系只有一个系主任，即DeptNameDeptHead；⑷每个学生学习每一门课都有一个成绩，即{Sno,Cname}Grade。4.1.2异常原因分析(4)这样就得到关系模式StudyInfo属性集U上所有函数依赖组成的集合F，简称函数依赖集。F={SnoSname,SnoDeptName,DeptNameDeptHead,{Sno,Cname}Grade}。所谓关系模式StudyInfo中的数据依赖过多，是指它存在多种类型的函数依赖，比如，(1)主健{Sno,Cname}Grade;(2){Sno,Cname}的部分属性SnoSname；(3)非主键属性DeptNameDeptHead等。4.1.3异常问题的解决(1)异常问题的解决方法：将关系模式分解成若干个只有单一“数据依赖”的关系模式。因为关系模式StudyInfo出现异常问题是由于属性之间存在过多的“数据依赖”造成，分解的目的就是减少属性之间过多的“数据依赖”，以期消除关系模式中出现的异常问题。4.1.3异常问题的解决(2)例4.2将StudyInfo分解为如下三个新的关系模式：⑴Students(Sno,Sname,DeptName)，⑵Reports(Sno,Cname,Grade)，⑶Departments(DeptName,DeptHead)，则分解后的每个关系模式，其属性之间的函数依赖都大大减少，关系⑴Students的函数依赖是SnoSname,SnoDeptName；⑵Reports的函数依赖是{Sno,Cname}Grade；⑶Departments的函数依赖是DeptNameDeptHead。4.1.3异常问题的解决(3)关系模式的分解：用若干属性较少的关系模式代替原有关系模式的过程。比如用Students,Reports,Departments就是关系模式StudyInfo的一个分解。表4.1表示的关系StudyInfo就可以用表4.2,表4.3和表4.4对应的关系来表示。4.1.3异常问题的解决(3)表4.2关系StudentsSnoSnameDeptName20010101张华Computer……20010102黄河Computer20010601刘林Math……4.1.3异常问题的解决(3)表4.3关系ReportsSnoCnameGrade20010101英语8520010101高等数学9020010101数据库92……20010101操作系统8820010102英语92……20010102高等数学86……20010601英语8820010601高等代数84……20010601数学分析904.1.3异常问题的解决(3)表4.4关系DepatmentsDeptNameDeptHeadComputer黄山…Math朱红…表4.2-表4.4可以看出，分解之前存在的插入异常和删除异常等问题已经基本消除，且数据冗余程度大大降低。4.1.3异常问题的解决(4)实例表明：解决关系模式异常问题的方法是对关系模式进行分解。但如何分解的理论问题还没有解决：怎样判定关系模式好或不好?(关系模式的标准问题——要不要分解)怎样将一个不好的关系模式分解为一组好的关系模式?(分解的方法问题)这些就是后面几节所涉及的内容。4.2关系模式的函数依赖4.2.2函数依赖的一般概念4.2.3候选键与主键4.2.4函数依赖的推理规则4.2.1再论关系与关系模式4.2.1再论关系与关系模式关系：笛卡尔积的一个子集，元组的集合，其实质是一张二维表，表的每一行为一个元组。关系模式：对元组中数据组织方式的结构性描述，其实质是删去所有元组后的空表格。关系与关系模式的联系：关系模式是相对稳定的、静态的，而关系却是动态变化的，不稳定的，且关系的每一次变化结果，都是关系模式对应的一个新的具体关系。注意：关系模式R(U)对应的具体关系通常用小写字母r来表示。4.2.2函数依赖的一般概念(1)定义4.1设R(U)是属性集U={A1,A2,…,An}上的关系模式，X和Y是U的子集。若对R(U)的任一具体关系r中的任意两个元组t1和t2，只要t1[X]=t2[X]就有t1[Y]=t2[Y]。则称“X函数确定Y”或“Y函数依赖于X”(FounctionalDependence)，记作XY。类似于y=f(x)其中t1[X]和t1[Y]分别表示元组t1在属性X和Y上的取值。“X函数确定Y”的含义：在R(U)的任意一个具体关系r中，不存在这样的两个元组，它们在X上的属性值相等，而在Y上的属性值不等。4.2.2函数依赖的一般概念(2)例4.3设有一个描述学生信息的关系模式:R(Sname,Sex,Birthday,Phone)，其属性名分别代表学生的姓名、性别、出生日期和电话号码属性。它的一个具体关系r如表4.5所示。SnameSexBirthdayPhone张华女1976.08.0888547566黄河男1965.11.1785344518刘林男1972.02.25860905414.2.2函数依赖的一般概念(3)SnameSexBirthdayPhone张华女1976.08.0888547566黄河男1965.11.1785344518刘林男1972.02.2586090541如果仅从关系模式R(U)的一个具体关系r出发，由于r没有相同姓名的元组(学生)，所以我们就会得出结论：对于关系模式R有SnameSex,SameBirthday,SnamePhone；4.2.2函数依赖的一般概念(4)表4.6关系r1SnameSexBirthdayPhone张华女1976.08.0888547566黄河男1965.11.1785344518刘林男1972.02.2586090541张华男1980.07.0288336629但这个结论是不正确的:比如，对关系模式R的另外一个具体关系r1(表4.6)，这时，从关系r得出的函数依赖就不成立了。所以，关系模式中的函数依赖是对这个关系模式的任何可能的具体关系都成立的函数依赖。从例子可知，函数依赖与属性的语义有关。根据属性的语义来确定一个函数依赖。例如SnameBirthday这个函数依赖，只有当关系中没有同姓名学生的条件下才成立。如果关系中允许出现相同姓名的学生，则出生日期就不再函数依赖于姓名了，即SnameBirthday。数据库设计者应在定义数据库模式时，指明属性之间的函数依赖(主键)，使数据库管理系统根据设计者的意图来维护数据库的完整性。设计者可以对现实世界中的一些数据依赖作强制性规定，比如，引入具有唯一性的“学号”4.2.2函数依赖的一般概念(5)4.2.2函数依赖的一般概念(6)另外，为使SnameBirthday这个函数依赖成立，可以在创建基本表(CreateTable)时，指定Sname为主键来强制规定关系中不允许同名同姓的人存在。这样，元组在Sname上的属性值必须满足以上规定。当发现新输入元组在Sname上的值与关系中已有元组在Sname上的值相同，则数据库管理系统就拒绝接受该元组。解决的办法是通过人工方式使同名者为不同名者。比如两个张华，可改为“张华”，“张华b”等。在定义4.1的基础上补充以下常用术语和记号：⑴若XY，则称X为这个函数依赖的决定(Determinant)因素，简称X是决定因素。⑵若XY且YX，则记作XY。(3)若Y不函数依赖于X，则记作。⑷若XY，但YX，则称XY是平凡函数依赖。⑸若XY，但，则称XY是非平凡函数依赖。对于任一关系模式，平凡函数依赖都是必然成立的，但它不反映新的语义。4.2.2函数依赖的一般概念(7)YXXY4.2.2函数依赖的一般概念(8)在以后的讨论中，若没有特别声明，“XY”都表示非平凡函数依赖。定义4.2设R(U)是属性集U={A1,A2,…,An}上的关系模式。X和Y是U的子集。⑴如果