[工学]第3章 关系模式设计理论.ppt

3.1 关系模式设计准则 3.2 函数依赖 3.3 关系模式的分解特性 3.4 范式 3.5 多值依赖和第四范式 问题的提出 关系数据库逻辑设计 如何构造一个合适的数据模式？ 应该构造几个关系模式？ 每个关系应该由哪些属性组成？ 数据库逻辑设计的工具 关系数据库的规范化理论 概念回顾 关系模式的形式化定义： 关系模式由五部分组成，即它是一个五元组： R(U, D, DOM, F) R： 关系名 U： 组成该关系的属性名集合 D： 属性组U中属性所来自的域 DOM：属性向域的映象集合 F： 属性间数据的依赖关系集合 概念回顾 关系模式的简化表示： 关系模式R（U, D, DOM, F） 简化为一个三元组： R（U, F） 当且仅当U上的一个关系r 满足F时，r称为关系模式 R（U, F）的一个关系 数据依赖 什么是数据依赖？ 是现实世界属性间相互联系的抽象 是数据内在的性质 是语义的体现 数据依赖的类型 函数依赖（Functional Dependency，简记为FD） 多值依赖（Multivalued Dependency，简记为MVD） 关系模式设计中的问题(1) 【例】设有一个医生与患者之间的就诊关系模式R（Dname，Dlevel，Dsal，Pname，Fsum），其属性分别表示医生姓名、医生职称级别、医生工资、患者姓名、诊治费用 R上的语义： 假设医生和患者的姓名分别都是唯一的。 医生与患者之间是多对多的关系，即医生可以为不同的患者看病，同时患者可以选择不同的医生。假设同一名患者不看相同的医生，即可以选择Dname和Pname作为就诊关系模式R的主键。 一位患者每次就诊都有一个花销总金额。 每位医生具有相应的职称级别。 职称级别决定了医生的工资金额。 关系模式设计中的问题(3) 可以确定以下函数依赖： F = {{Dname,Pname}→Fsum，Dname→Dlevel，Dlevel→Dsal} 这些函数依赖关系如图所示。 关系模式设计中的问题(2) 关系模式设计中的问题(4) 使用过程中会出现以下几个问题： 关系模式设计中的问题(5) 插入异常（Insert Anomalies） 如果一位医生刚到医院报到，但还未分配就诊任务，那么要将医生的姓名、职称和工资等信息存储到数据库时，患者姓名和诊疗费用就会出现空值。由于医生姓名和患者姓名是该模式的主键，主键上必须遵循实体完整性规则，即主键不允许出现空值。因此，这位新医生的基本信息无法存储到数据库中。 关系模式设计中的问题(6) 关系模式的非形式化设计准则 关系模式的设计应尽可能只包含有直接联系的属性，不要包含有间接联系的属性。 关系模式的设计应尽可能使得相应关系中不出现操作异常现象。 关系模式的设计应尽可能使得相应关系中避免放置经常为空值的属性。 关系模式的设计应尽可能使得关系的等值连接在主键和外键的属性上进行，并保证连接以后不生成额外的元组。 3.1 关系模式设计准则 3.2 函数依赖 3.3 关系模式的分解特性 3.4 范式 3.5 多值依赖和第四范式 3.2.1函数依赖的定义 函数依赖（FD）的定义 符号说明：R表示一个关系的模式； U＝{A1，A2，…，An}是R的所有属性的集合； F是R中函数依赖的集合； r是R所取的值； t[X]表示元组t在属性X上的取值。 例: Student(Sno, Sname, Ssex, Sage, Sdept) 假设不允许重名，则有: Sno → Ssex， Sno → Sage , Sno → Sdept， Sno ←→ Sname, Sname → Ssex， Sname → Sage Sname → Sdept 但Ssex →Sage 若X→Y，并且Y→X, 则记为X←→Y。 3.2.1函数依赖的定义 完全函数依赖与部分函数依赖 3.2.1函数依赖的定义 传递函数依赖  3.2.4函数依赖与码的联系  3.2.5属性集的闭包 3.2.5属性集的闭包 3.2.5属性集的闭包 3.2.5属性集的闭包 3.2.5属性集的闭包 FD推理规则是正确的（Sound）且是完备的（Complete） 正确性：从FD集F使用推理规则推出的FD必定在F+中。 完备性：F+中的FD都能从F集使用推理规则推出。 3.2.6 FD集的最小依赖集 3.2.6 FD集的最小依赖集 3.2.6 FD集的最小依赖集 3.1 关系模式设计准则 3.2 函数依赖 3.3 关系模式的分解特