ch4-1需要按英文版及改范式.ppt

* 1、数据冗余。虽然每个教师只开一门课，但每个选修该 教师该该门课程的学生元组都要记录这一信息。 2、插入异常。当某门课程本学期不开，自然就没有学生 选修。没有学生选修，因为主属性不能为空，教师上  该门课程的信息就无法插入。同样原因，学生刚入校, 尚未选课，有关信息也不能输入。 3、删除异常。如果选修某门课程的学生全部毕业，删除 学生记录的同时，随之也删除了教师开设该门课程的 信息。 4、更新异常。当某个教师开设的某门课程改名后，所有 选修该教师该门课程的学生元组都要进行修改，如果 漏改某个数据，则破坏了数据的完整性。 * 分析出现上述问题的原因在于主属性部分依赖于码：(S，T) → C（因T→C） 。因此，关系模式还要继续分解，转换成更高一级的范式BCNF，以消除数据库操作中的异常现象。 将STC分解为两个关系模式：ST(S，T) 和 TC(T，C)。 消除函数依赖(S，T) → C。其中ST的码为(S,T)，TC的码为T。ST?BCNF，TC?BCNF。 * 关系模式TCS规范到BCNF后，原来存在的四个异常问题得到了解决。 数据冗余降低。每个教师开设课程的信息只在TC关系中存储一次。 不存在插入异常。对于所开课程尚未有学生选修的教师信息可以直接存储在关系TC中，而对于尚未选修课程的学生可以存储在关系ST中。 不存在删除异常。如果选修某门课程的学生全部毕业，可以只删除关系ST中的相关学生记录，而不影响系关系TC中相应教师开设该门课程的信息。 不存在更新异常。当某个教师开设的某门课程改名后，只需修改关系TC中的一个相应元组即可，不会破坏数据的完整性。 * 如果一个关系数据库中所有关系模式都属于3NF，那么已经在很大程度上消除了插入异常和删除异常，但由于可能存在主属性对候选码的部分依赖和传递依赖，因此关系模式的分离仍不够彻底。 如果一个关系数据库中所有关系模式都属于BCNF，那么在函数依赖的范畴内，已经实现了模式的彻底分解，消除了产生插入异常和删除异常的根源，而且数据冗余也减少到极小程度 。 * 属于3NF也属于BCNF的例子。 例：关系模式SCP(S,C,P)，C-课程，P-名次。 语义：(1)每一个学生选修每门课程的成绩有一定的名次。 (2)每门课程中每一名次只有一个学生 (即没有并列名次)。 由语义可得到如下的函数依赖：  (S，C)→P；(C，P)→S 所以，(S，C)与(C，P)都可以作为候选码。 这个关系模式中显然没有非主属性对码传递依赖或部分依赖，所以SCP?3NF。 而且除(S，C)与(C，P)以外没有其它决定因素,所以SCP?BCNF。 * 4.3.5 关系规范化小结 一、关系模式规范化的步骤 对1NF关系进行投影，消除原关系中非主属性对码的部分函数依赖，将1NF关系转换成若干个2NF关系。 对2NF关系进行投影，消除原关系中非主属性对码的传递函数依赖，将2NF关系转换成若干个3NF关系。 对3NF关系进行投影，消除原关系中主属性对码的部分函数依赖和传递函数依赖，也就是说使决定因素都包含一个候选码。得到一组BCNF关系。 * 1NF 2NF 3NF BCNF 非规范关系 去掉嵌套属性或重复组(使每个属性及其值都成为不可再分的数据项) 消去非主属性对候选码的部分函数依赖 消去非主属性对候选码的传递函数依赖 消去主属性对候选码的部分和传递函数依赖 关系规范化过程 消去决定因素非码的非平凡函数依赖 4NF 消去非平凡且非函数依赖的多值依赖 * 二、结论 1、3NF必定为2NF和1NF，反之不一定； 2、BCNF必为3NF，反之不一定； 3、3NF已在很大程度上控制了数据冗余，消去 了插入和删除操作异常； 4、3NF分解仍不够彻底（可能存在主属性对候 选码的部分函数依赖和传递函数依赖）； 5、在函数依赖范围内，BCNF已完全消去了插入 删除异常； 6、范式并非越高越好；范式越高，异常越少， 但查询操作越麻烦； 7、适可而止，理论上：一般到3NF。 8、分解不唯一。 * 一般情况下，我们说没有异常弊病的数据库设计是好的数据库设计，一个不好的关系模式也总是可以通过分解转换成好的关系模式的集合。 但是在分解时要全面衡量，综合考虑，视实际情况而定。 对于那些只要求查询而不要求插入、删除等操作的系统，几种异常现象的存在并不影响数据库的操作。这时便不宜过度分解，否则当要对整体查询时，需要更多的多表连接操作，这有可能得不偿失。 在实际应用中，最有价值的是3NF和BCNF，在进行关系模式的设计时，通常分解到3NF就足够了。 * 4.3.1 第一范式 定义5：如果关系模式R，其所有的属性均为简单属性，即每个属性都是不可再分的，则称R属于第