第5节关系数据库设计理论.ppt

第5章 关系数据库设计理论 5.1关系模式的非形式化设计规则 一个关系数据库模式包括一组关系模式，各关系之间既存在一定的独立性（分别反映事物某一方面的特性），又存在必然的关联，从而构成一个关系数据库模式整体。 下面将详细讨论关系模式的设计质量方面的相互关联的四个非形式化的衡量标准。 5.1.1关系属性的语义 规则5.1：设计一个关系模式要能够更容易解释它的语义。不要将多个实体类型和联系类型的属性组合成一个单一的关系。如果一个关系模式对应于一个实体类型或一个联系类型，那么它的语义就很清晰。否则，若一个关系对应于多个实体和联系的混合，就会变得语义不清。 5.1.2元组中的冗余信息和更新异常 一个学生肯定要学几十门课，那么该学生的姓 名、系、系主任等信息就要重复存储，其存储冗余 问题是相当严重的。 对于刚成立的系，如果还没有学生，由 于Snum是主属性，不能为空值，因此该系 主任等信息就无法加入到该关系中，这是极 不合理的。即存在插入异常问题。 若某学生因病下学期未选课程，则需删除该学 生所对应所有元组，结果该学生的学号、姓名、性 别等信息也同时删去了，即删去了一些不该删除的 信息。这样在该关系中就找不到该学生的姓名、性 别等信息了。这也是极不合理的。 如果更换了某个系的主任，那么该系学生所有 对应的元组的系主任等信息都要修改，修改量很 大，潜在着严重的数据不一致问题，有可能会出现 同一个系有不同主任的情况。这种不一致性是由于 数据的存储冗余产生的。 规则5.2：设计的关系模式不要出现插入异常、删除异常和修改异常。如果有任何异常出现，要明确注释，确保数据库进行插入、删除和修改时能正确操作。 规则5.2和规则5.1是一致的，并且某种程度上是对规则5.1的重新陈述。所以我们需要一种更形式化的方法，来评估一个设计是否满足这些规则。 5.1.3 元组中的空值 规则5.3：设计一个关系模式要尽可能避免在其中放置经常为空值的属性。如果空值不可避免，则应确保空值在特殊情况下出现而不是在大部分元组中出现。 5.1.4 伪元组的生成 规则5.4：设计关系模式要使它们在主码或外码的属性上进行等值连接，并且保证不会生成伪元组。如果一定要有不满足上述条件的关系，则不要将它们在这类非主码-外码的属性上进行连接，以避免产生伪元组。 函数依赖(functional dependency，简 记为FD)是关系模式设计理论中的一个基本 概念，是一种分析工具。函数依赖这一概念 是码概念的推广，是合法关系集上的一种特 殊约束。函数依赖在数据库设计中具有重要 作用。 如果R上的一个约束说明在R的 任一具体关系r中都没有两个或两个 以上的具有给定的X值的元组，即X 是R的候选码 ，那么对于R的任一属 性子集Y均有X→Y。 函数依赖不是指关系模式R的某个或某些关系满 足定义中的约束条件，而是指R的一切关系都要满足 定义中的约束条件。 关系模式中属性或属性组之间的函数依赖取决于 属性的语义的理解，即这些属性如何相互关联。所 以，函数依赖的主要作用是通过在其属性上指定总 是必须保持的约束，来进一步来描述关系模式R。 定义5.2: 在关系模式R(U)中，X, Y是U的子集，若X→Y，且不存在X‘?X，使X’→Y，则称X→Y是完全函数依赖（full functional dependency），记作： 否则称 X→Y是部分函数依赖（partial functional dependency），记作： 定义5.3: 在关系模式R(U)中，X, Y是U的子集，若X→Y，Y→Z，并且X不函数依赖于Y ，则称Z传递函数依赖于X。 这里加上条件X 不函数依赖于Y很重要，如果Y→X则X?Y，X与Y一一对应，实际上处于等价地位，Z就直接函数依赖于X，而不是传递函数依赖于X。 5.2.2 函数依赖的逻辑蕴涵 在2.3节中，关系模式形式化地表示为: R(U, D, dom, F) 其中R是关系名，是符号化的元组语义；U为 组成关系的属性名的集合；D为属性组U中属性 所来自的域；dom 为属性和域之间的映像集 合；F 为关系中属性间的依赖关系集合。这个 关系模式可以简化为一个三元组：R(U, F)。 设计者典型地确定语义明显的函数依赖。通常只考虑给定的函数依赖集是不够的，还要考虑模式上成立的其它所有函数依赖。即从一些已知的函数依赖，去推导其它一些函数依赖也成立。 定义5.4：设F是关系模式R(U, F)的一个函数依赖集，X、Y是U的子集，若对R的每个满足F的关系r，X→Y都成立，则称F逻辑蕴涵X→Y。记作 F|=X→Y 定义5.4表示函数依赖X→Y可由函数依