第10章 数据依赖和关系模式的规范化.pptVIP

第10章 数据依赖和关系模式的规范化 10.1 关系模式设计中的一些数据语义问题 数据的语义不但表现为完整性约束，对数据库的状态或状态的转换施加一定的限制，而且对关系模式的设计也提出一定的要求。 属性间往往存在一定的依赖关系，而最基本的依赖关系是函数依赖。所谓函数依赖是指一个或一组属性的值可以决定其他属性的值。 一般地讲，设Ｘ，Ｙ是关系的两个不同的属性组，如果Ｙ函数依赖于Ｘ，或Ｘ函数决定Ｙ，则其依赖关系可表示为Ｘ→Ｙ。 设有一关系Ｒ，具有下列属性：学号（S＃）、课程号（C＃）、成绩（G）、任课教师姓名（TN）、教师所在系名（D）。这些数据具有下列语义： （１）学号是一个学生的标识，课程号是一门课程的标识，这些标识与其代表的学生和课程分别一一对应； （２）一位学生所修的每门课程都有一个成绩； （３）每门课程（注意：不是每种课程！同一种课，如数学课，可以开好多门，每门课有一个课程号）只有一位任课教师，但一位教师可以教多门课； （４）教师中没有重名，每位教师只属于一个系。 根据上述语义，可以确认下面函数依赖的集合： Ｆ＝｛｛Ｓ＃，Ｃ＃｝→Ｇ，Ｃ＃→ＴＮ，ＴＮ→Ｄ｝ 从图１０－１可以看出，属性集｛Ｓ＃，Ｃ＃｝可以 决定其他所有属性的值，而｛Ｓ＃，Ｃ＃｝的任何子集 则不能，故｛Ｓ＃，Ｃ＃｝是这个关系的主键。这样的 关系用来查询是很方便的。 计算机系通知教师准备给学生补考，可以“查询图10-1　 函数依赖计算机系所开课程的不及格学生的学号、不及 格课程号以及任课教师的姓名” .查询仅涉及Ｒ一个关 系，是一元查询，不须做连接运算，可以用下面的SQL语 句来表达： SELECT S＃，C＃，TN FROM R WHERE Ｄ＝CS′AND Ｇ＝F′; 但是这样的关系也有问题，首先数据冗余太多，如一门课程的教师名须对选这门课的所有学生重复一次；一个系名须对选该系所开课程的所有学生重复一次。除冗余外，在进行增、删、改操作时，还会发生所谓更新异常现象: （１）由于冗余，在修改时往往会导致数据的不一致。例如，改变一门课程的任课教师，或一门课改由另一个系开出，则需要修改多个元组。如果部分修改，部分不修改，则会导致数据的不一致。这叫修改异常。 （２）由于主属性不能为空值，如某系有位教师不教课，则这位教师的姓名及所属的系名就不能插入；同样，如果一位教师所开的课暂时无人选，或是列入计划而目前不开，则也无法插入。这叫插入异常。 （３）如果所有学生都退选一门课，则有关这门课的其他数据（任课教师名及所属系名）也将被删除。如果一位教师因病暂时停开他所开的课，则有关这位教师的其他信息（所属系、可开课程）都将被删去。这叫删除异常。 在上例的关系中，包含了三方面的信息：学生各门课程 的成绩，各门课程开课的教师以及各个教师所属的系。 上例中,所有这三方面的数据都集中在一个关系中，此 关系的主键为属性集｛S＃，C＃｝。 （C＃，TN）和（TN，D）本来可以作为独立的关系而存 在，而今却不得不依附于其他关系。这就是说，必须对应 一个主键｛S＃，C＃｝的值，才能插入或存在一个（C＃， TN）或（TN，D）的值。这是关系结构带来的限制，不是现 实世界的真实反映。 解决这个问题的途径是把关系分解，也就是进行所谓关系规范化。例如，把上例的关系分解为下列三个关系： 　SCG（S＃，C＃，G） CTN（C＃，TN） TND（TN，D） 这样的分解使关系的语义单纯化，使之符合“一地一事”的原则。但是分解以后，对某些查询必须进行开销很大的连接操作，影响数据库的性能。 关系的规范化主要是对关系进行必要的分解，但如何分解，分解后是否有损于原来的信息，回答这些问题需要理论的指导，下面将讨论这些问题。 Ｒ表示一个关系的模式，U={A1,A2,…,An}是R的所有属性的集合，F是R中函数依赖的集合，r是R所取的值，即R实有元组的集合。 定义10-1 设有一关系模式R(A1,A2,…,An),X和Y为其属性的子集。设t1,t2是关系R中的任意两个元组，如果t1[X]=t2[X],则t1[Y]=t2[Y]。这时我们称Y函数依赖于X，或X函数决定Y，X称为决定子（determinant）。 一个函数依赖要能成立，不但要求关系的当前值都能满足函数依赖条件，而且还要求关系的任一可能值都能满足函数依赖条件。确认一个函数依赖，需要弄清数据的语义，而语义是现实世界的反映，不是主观的臆断。 如果Ｙ为Ｘ的子集，显然Ｘ→Ｙ成立，这称为平凡函数依赖（trivial functional dependency）。平