Chapter07 -chinese.ppt

第7章 关系数据库设计 关系数据库设计的过程 “好”的关系数据库设计 关系数据库是由一组关系构成的 “好”的关系数据库设计要求我们找到一些“好”关系 然而有时…… 包含“坏”关系的“坏”数据库设计具有某些问题 关系数据库中的问题 考虑以下数据库设计 关系：worker (name, branch, manager) 假设一个部门仅有一位经理。但反过来，一个经理可以是多个部门的经理。 关系数据库中的问题 该数据库设计有如下问题 冗余 思考：有几个元组存储了David是部门B经理的信息？ 同部门的每一个员工都不必要地重复关于谁是部门经理的信息 关系数据库中的问题 更新异常 思考：如果部门B的经理变成Debbie，需要更新几个元组？ 如果一个部门的经理变动，我们必须更新部门里的每个员工以反映谁是新经理，否则就会出现这样的错误：该部门有两个经理 关系数据库中的问题 插入异常 思考：假设成立一个新部门D。经理是kevin，没有员工。我们能增加关于部门D的信息么？ 如果一个部门还没有员工，我们就无法添加这个部门的信息 关系数据库中的问题 删除异常 思考：在删除了部门B的所有员工以后，我们还能找出谁是部门B的经理么？ 如果一个部门里的所有员工都被删除了，谁是部门经理的信息也会被删除 什么导致了这些问题？ 不良的数据依赖 函数依赖(简记为FD)是一种数据依赖，它具有以下形式 ? ? ? (读作：?蕴涵?) 意义：当任意两个元组在属性集?上相等时，则它们在属性集?上也相等。即同一个?（的值），必然对应同一个?（的值） 什么导致了这些问题？ 我们可以在worker关系中发现某些函数依赖，如下所示 name → branch branch → manager name → manager 什么导致了这些问题？ worker关系的这些函数依赖中, branch → manager是不良的 由于左边的branch不是关系的码（这里指超码），同一branch可能出现多次，造成同一组合: (branch，manager)的重复 如何解决这些问题？ 分解 把一个“坏”关系分解为几个更小但是“好”的关系 例如 worker (name, branch, manager) →  worker1 (name, branch),  branch (branch, manager) 如何解决这些问题？ 在分解后消除了不良函数依赖，所以避免了同一组合的重复，解决了以上问题 如何解决这些问题？ 考虑另一种分解方案，如下所示 worker (name, branch, manager) →  worker2 (name, manager),  branch (branch, manager) 如何解决这些问题？ 思考 在分解后，你能找出Jones在哪个部门么？ 不正确的分解可能带来新的问题：丢失某些信息 例如，这里会丢失有关员工属于哪个部门的信息 数据库设计理论 如何获得“好”的数据库设计？ ① 判定其中的一个关系R是否“好”的，即有没有“坏”数据依赖 ② 如果R不是好的，则要正确地分解为几个较小的好关系 ③ 重复以上两步，直到全部关系都变成“好”的为止 数据库设计理论 两个要点 如何知道一个关系是否“好”的，是否有“坏”数据依赖 判断属于哪一级别的范式 越高级的范式，不良数据依赖就越少 如何正确地分解某个关系(没有信息的丢失) 进行规范化 思考与练习 观察以下关系，然后回答问题 问题1：在这个关系上能找到哪些函数依赖？它们是“好”的还是“坏”的？ 问题2: 它是一个“好”关系么？如果不是，存在哪些问题？ 函数依赖 定义 R: 一个关系 U: 关系R中的所有属性 ?, ? : R中一或多个属性的集合 函数依赖 我们说关系R上存在以下函数依赖 ? ? ? (读作：?蕴涵? ，或?依赖?) 的条件是当且仅当：如果两个元组如果在属性集?上相等，它们在属性集?上必然相等（ 同一个?对应同一个?） t1[?] = t2 [?] ? t1[? ] = t2 [? ] 函数依赖 例如 考虑以下关系 以上关系满足什么函数依赖？ 特殊类型的函数依赖 函数依赖? ? ?，当? ? ? 时是平凡的；否则是非平凡的 例如，以下是平凡的函数依赖 name, branch ? name name ? name 例如，以下是非平凡的函数依赖 name, branch ? manager 思考与练习 平凡的函数依赖总是成立的，为什么？ 换句话