关系数据库设计理论.ppt

1,第四章 关系数据库设计理论,4.1 问题的提出 4.2 函数依赖 4.3 关系模式的规范化,2,4.1 问题的提出,一个有问题的关系 假设有如下关系： s(no,name,gen,cour,degr)，即对应学号、姓名、性别、课程、成绩；其中（ no,cour）是主键。,3,4.1 问题的提出,这个关系有如下问题： 数据冗余 不一致性 插入异常 删除异常,一个学生选修多门课程，导致表中“姓名”和“性别”被多次重复存贮；,由于数据存贮冗余，当更新某些数据项时，有可能一部分记录修改了，而另一部分未修改，造成存贮数据的不一致性。,如果某个学生尚未选修课程，那么他的（学号，姓名，性别）信息无法插入。这是因为“课程”为空，关系数据模式规定主关键字不能为空，这就导致了插入异常。,当删除所有学生的成绩时，将所有（学号，姓名，性别）信息也删除了，这就是删除异常。,4,4.1 问题的提出,为了克服这些异常，可以将s关系分解成下面的两个关系： s(no,name,gen,cour,degr) s1(no,name,gen), s2(no,cour,degr),上例说明，s关系的某些属性之间存在数据依赖关系。,5,4.2 函数依赖,数据依赖的概念 数据依赖是通过一个关系中属性间值的相等与否体现出来的数据间的相互关系。 例如，前面的学生信息关系（表）中，一个学号对应一个姓名和性别，当学号确定后，姓名和性别的值就被唯一确定了；也就是说，姓名和性别的值依赖于学号。 函数依赖和多值依赖是两种最重要的数据依赖。,6,4.2 函数依赖,函数依赖 定义：设有关系模式r(u)，x和y均为属性集u的子集， r 是r的任意一个具体关系。若r中不存在两个元组（ t1,t2 ）在x上的属性相等（ t1x=t2x ），而在y中的属性值不等（t1y!=t2y），则称x函数决定y ，或y函数依赖于x，记作xy.,例如，前面的学生关系中，不存在两个学生记录的元组，使学号相同，而姓名不相同，因此“姓名”函数依赖于“学号”，记作：学号姓名。,又如，学生关系中，学生姓名可能相同，可能存在两个元组，使姓名相同，且性别相同，“性别”不函数依赖于“姓名”。,7,4.2 函数依赖,例如：描述学生的关系模式： student (xh, xm, xb, nl) 其中: xh表示学号，xm表示姓名，xb表示性别，nl表示年龄,假定姓名唯一。 则有：xhxm，xmxb，(xh，xm)nl，xb,8,4.2 函数依赖,函数依赖 定义中，x和y均为属性集u的子集。如果xy，但y不属于x，则称xy是非平凡的函数依赖；如果y属于x，则称xy是平凡的函数依赖。 如果xy，且对于x的任何一个真子集x（除x外的子集），都有 x! y （y不函数依赖于x），则称y对x完全函数依赖，记作xyf；如果xy，但y不完全依赖于x，则称y对x部分函数依赖，记作: x yp。 若xy，则x叫做决定因素(determinant)。,9,4.2 函数依赖,sc(sno,cno,grage)中，(学号,课程号,成绩) (sno,cno) grade,完全函数依赖,(cno) grade,部分函数依赖,f,d,10,4.2 函数依赖,键（用函数依赖的概念定义） 设k为r(u,f)中的属性或属性组合，若kfu，则称k为r的候选键(candidate key, 即k能决定唯一的一个元组但又没有多余的属性集 )。若候选键多于一个，则选定其中的一个为主键(primary key)。 包含在任何一个候选键中的属性称为主属性(prime attribute)。不包含在任何键(键是唯一标识实体的属性集)中的属性称为非主属性(non-prime attribute)。 例如，学生关系中，学号是键。 又如，关系模式r(p,w,a)，其中p表示演奏者，w表示作品，a表示听众。某个演奏者可以演奏多个作品；某个作品可以被多个演奏者演奏。听众可以欣赏不同演奏者的不同作品。这个关系模式的键为(p,w,a)。,11,4.2 函数依赖,外键（用函数依赖的概念定义） 关系模式r中属性或属性组x并非r的键，但x是另一个关系模式的键，则称x是r的外键(foreign key)。 例如，关系s1(no,name,gen)和s2(no,cour,degr)中，no是s1的键，但no并不是s2的键（一个学号可能对应几门课程），no是s2的外键。,12,4.3 关系模式的规范化,第一范式 定义：如果一个关系模式r中的每一个属性的域都只包含原子项（即单一的，不可分隔的数据项），则称r满足第一范式。 形象的说，第一范式要求不能表达“表中表”。 例如，下表所示的关系不满足第一范式，“奖金”和“提成”和“工资”实际上是另一个关系。,13,4.3 关系模式的规范化,第一范式并不能排除数据冗余、更新异常和删除异常等问题。 关系的约束需要满足更高的范式。,14,4.3 关系模式的规范化,第二范式 定义：如果关系r满足第一范式，且r的所有非主属性完全函数依赖于候选键，则称r满足第二范式。 例如，下面的关系中，候选键为“课程名称”，“教师名称”和 “教师地址”属性完全函数依赖于候选键“课程名称”（即不存在一个候选键的真子集x，使“教师名称”和 “教师地址” 依赖于x），故该关系满足第二范式。,15,4.3 关系模式的规范化,又如，下面的关系显然满足第一范式，候选键为（工程号，材料号）， “开工日期”属于非主属性，但“开工日期”函数依赖于候选键的真子集“工程号”（工程号确定后，只能对应一个开工日期），因此部分依赖于候选键，该关系不满足第二范式。,16,4.3 关系模式的规范化,满足第二范式的关系仍然可能存在操作异常，例如： 如果课程的教师尚未分配，无法插入新的课程； 教师地址在元组中可能出现多次，属于数据冗余； 如果修改一个教师地址，必须更新所有元组中的地址。 删除课程时，可能删除教师的有关信息。 说明关系仍需要满足更高的范式。,17,4.3 关系模式的规范化,第三范式 传递依赖的定义：在r(u)中，如果xy，y！x，yz，则称z对x传递函数依赖。 例如，下面的关系中，一门课程有且只有一个教师授课，“教师名称”函数依赖于“课程名称”；一个教师可能讲授多门课程， “课程名称” 不函数依赖于“教师名称”；教师提供一个住址，“教师地址”函数依赖于“教师名称”； “教师地址”对“课程名称”传递函数依赖。,18,4.3 关系模式的规范化,第三范式 第三范式的定义：关系模式r满足第二范式，且r的任何一个非主属性都不传递依赖于任何候选键，则r满足第三范式。 例如，下面的关系中，候选键为“课程名称”，非主属性“教师地址”对候选解传递函数依赖，因此该关系不满足第三范式。,19,4.3 关系模式的规范化,bc范式（修正的第三范式） 定义：关系模式r(u,f)满足第一范式，若y函数依赖于x，且y不属于x时，x必含有键，则r满足bc范式。或者说，r中的每一个决定因素都包含键，则r满足bc范式。 例如，下面的关系中，候选键为“课程名称”，“教师地址”函数依赖于“教师名称” ，但“教师地址” 不属于候选键，因此该关系不满足bc范式。,20,4.3 关系模式的规范化,满足第三范式不一定满足bc范式，例如下面的关系r(no,name,course,grade)，假设没有重名情况时： 根据学号和课程名称可以唯一确定成绩；同样，根据姓名和课程名称也可以唯一确定成绩。关系的候选键为(no,course)和(name,course)。 非主属性不传递依赖于任何一个候选键，所以r满足第三范式。 但r不满足bc范式，因为name函数依赖于no，而no不是r的候选键。,21,4.3 关系模式的规范化,多值函数依赖 关系满足bc模式后，仍可能存在问题，参见下例。 例如，下面的关系表示公司在不同国家销售的不同产品。显然(公司,产品,国家)是候选键，该关系满足bc范式。但是，该关系仍有问题，例如： 公司添加某个产品时，要添加多个元组，如(ibm,服务器,中国)， (ibm,服务器,日本)等， (ibm,服务器)存在冗余； 删除一个产品时，需要删除多个元组。 上述例子中存在多值依赖。,22,4.3 关系模式的规范化,多值依赖的定义：设有关系模式r，x和y是r的属性子集。如果对于给定的x属性值，有一组y属性值与之对应，而与其他属性（除x和y以外的属性子集）无关，则称“x多值决定y”，或“y多值依赖于x”，记作x y。如果其他属性为空，则称为平凡的多值依赖。 参见下页的例子。,23,4.3 关系模式的规范化,关系模式wsc（w，s，c）中，w-仓库，s-保管员，c-仓库中商品。 要求：每个仓库有若干个保管员，有若干中商品；每个保管员保管所在的仓库中所有商品；每种商品被所在仓库的所有保管员保管。 s多值依赖w，c多值依赖w；,24,4.3 关系模式的规范化,例如，下面的关系中，对于(ibm,中国)，有一组工作站,投影仪与之对应，这组值仅与“ibm”有关，而与“中国”无关。或者说，对于一个公司，有一个完整的产品集合与之对应，而不论“国家”取何值。即使国家变成日本，即对于(ibm, 日本)，它对应的“产品”仍然是工作站,投影仪 ,因此，“产品”多值依赖于“公司”，即“公司” “产品” 。,25,4.3 关系模式的规范化,第四范式 定义：设r是一关系模式，d是r上的依赖集。如果对于任何一个多值依赖x y（其中y非空，也不是x的子集，x和y并未包含r的全部属性），且x包含r的一个键，则称r满足第四范式。 当d中只包含函数依赖时，第四范式就是bc范式，于是第四范式一定满足bc范式，但反之不成立。 对于关系r (公司,产品,国家)，可以将其拆分为两个关系r1(公司,产品),r2(公司,国家)，这样r1和r2均可以满足第四范式。,26,4.3 关系模式的规范化,范式总结,27,4.3 关系模式的规范化,结论 1）3nf必定为2nf和1nf，反之不一定； 2）bcnf必为3nf，反之不一定； 3）3nf已在很大程度上控制了数据冗余； 4）3nf已在很大程度上消去了插入和删除操作异常； 5）3nf分解仍不够彻底（可能存在主属性对候选码的部分函数依赖和传递函数依赖）； 6）在函数依赖范围内，bcnf下