Microsoft Word - 第5章.doc

Size: px

Start display at page:

Download "Microsoft Word - 第5章.doc"

陌静赖
4 years ago
Views:

1 第 5 章关系规范化 5.1 函数依赖数据依赖是一个关系内部属性和属性之间的一种约束关系它是显示属性间相互联系的抽象, 是数据内在的性质人们提出了许多种类型的数据依赖, 其中最重要的是函数依赖 (Function Dependency, FD) 和多值依赖 (Multivalued Dependency,MVD) 函数依赖极为普遍地存在于现实生活中比如描述一个学生关系, 可以有学号 sno, 姓名 sname, 系名 dname 等几个属性由于一个学号只对应一个学生, 一个学生只在唯一的一个系, 因而当学号确定后, 学生的姓名和系名的值也就被唯一确定了属性间的这种依赖关系类似于数学中的函数 y=f(x), 当自变量 x 确定之后, 相应的函数值 y 也就确定了类似的有 sname=f(sno),dname=f(sno), 即 sno 函数决定 sname 和 dname, 或 sname 和 dname 函数依赖 sno, 记作 sno sname,sno dname 函数依赖研究的是一个关系中属性之间的相互依赖关系 1. 一般函数依赖定义 : 设一个关系为 R(U),X 和 Y 为属性集 U 上的子集, 若对于元组中 X 上的每个值都有 Y 上的一个唯一值对应, 则 X 和 Y 之间存在函数依赖, 并称 X 函数决定 Y, 又称 Y 函数依赖 X, 记作 X Y, 称 X 为决定因素设一个职工关系为 ( 职工号, 姓名, 性别, 年龄, 职务 ) 其中, 职工号用来标识每个职工, 选作为该关系的主码对于该关系中每个职工的职工号, 都对应着姓名属性中的唯一值, 即该职工的姓名, 或者说一个职工的姓名由职工号唯一确定, 所以称职工号函数决定姓名, 或称姓名函数依赖于职工号, 记作 : 职工号姓名同理, 职工号函数决定性别年龄职务在该关系中除职工号外, 其他属性都不能成为决定因素形成函数依赖, 因为对于它们的每个属性值都可能对应另一个属性的多个不同的值 2. 平凡和非平凡函数依赖定义 : 设一个关系为 R(U),X 和 Y 为属性集 U 上的子集, 若存在 X Y 且 X 不包含 Y, 则称 X Y 为非平凡函数依赖, 否则为平凡函数依赖职工号姓名为非平凡函数依赖 ( 职工号, 姓名 ) 职工号或者 ( 职工号, 姓名 ) 姓名为平凡函数依赖

2 数据库原理与应用教程基于 SQL Server 部分和完全函数依赖定义 : 设一个关系为 R(U),X 和 Y 为属性集 U 上的子集, 若存在 X Y, 同时 X 的一个真子集 X 也能函数决定 Y, 即存在 X' Y, 则称 X 部分函数决定 Y, 或 Y 部分函数依赖 X; 若不存在一个真子集 X 能函数决定 Y, 则称 X 完全函数决定 Y, 或 Y 完全函数依赖 X 完全函数依赖都是非平凡函数依赖, 因为若是平凡函数依赖, 则表明 X 包含 Y,X 的真子集 Y 能够函数决定 Y, 这与完全函数依赖的定义相矛盾 ( 职工号, 姓名 ) 性别, 同时 ( 职工号, 姓名 ) 的真子集职工号也能函数决定性别, 所以性别部分函数依赖 ( 职工号, 姓名 ), 如主码是职工号, 则全部都是完全函数依赖 4. 传递函数依赖定义 : 设一个关系为 R(U),X Y 和 Z 为属性集 U 上的子集, 若存在 X Y Y Z, 且不存在 Y X, 则存在 X Z, 称此为传递函数依赖, 即 X 传递函数决定 Z,Z 传递函数依赖 X 这里必须强调不存在 Y X, 如果 X Y 可以相互函数依赖, 那么 X Z 就是直接函数依赖设一个学生关系 ( 学号, 姓名, 性别, 系号, 系名 ), 通常一个学生只属于一个系, 学号可以函数决定姓名性别系号, 而系号又函数决定系名, 所以学号函数决定系名, 系名是传递函数依赖学号 5. 函数依赖的增广性规则定义 : 设一个关系为 R(U),X Y 和 Z 为属性集 U 上的子集, 若 X Y, 则存在 XZ YZ 和 XZ Y 6. 函数依赖的合并性规则定义 : 若 X Y 和 X Z 成立, 则存在 X YZ 7. 关系的最小函数依赖集定义 : 设一个关系为 R(U),X 和 Y 为属性集 U 上的子集, 若 X 完全函数决定 Y, 同时 Y 为单属性, 则称该依赖关系为 R 的最小函数依赖由 R 中所有最小函数依赖构成 R 的最小函数依赖集, 其中不含有冗余的传递函数依赖设一个学生关系 ( 学号, 姓名, 性别, 系号, 系名 ) 最小函数依赖集 ={ 学号姓名, 学号性别, 学号系号, 系号系名 } 8. 根据函数依赖求关系的候选码定义 : 设一个关系为 R(U),X 为 U 上的子集, 若 X 能够函数决定 U 中的所有属性, 且 X 的任何真子集都不能函数决定 U 中的所有属性, 则称 X 为关系 R 的一个候选码设一个成绩关系 ( 学号, 姓名, 课程号, 课程名, 分数 ) 最小函数依赖集 ={ 学号姓名, 课程号课程名,( 学号, 课程号 ) 分数 } 可以看出只有 ( 学号, 课程号 ) 可以函数决定所有属性, 且不存在任何真子集函数决定所有属性, 所以 ( 学号, 课程号 ) 是该关系的一个候选码

3 5.2 规范化在一个设计不好的关系模式中, 会存在很多问题, 具体问题如例 7 分析 : 例 : 描述学校教务的数据库, 设计对象包括学生学号 sno 学生姓名 sname 所在系编号 dno 所在系名称 dname 系主任名称 dmgr 课程号 cno 课程名 cname 和成绩 score, 假设用一个关系表达 : student={sno,sname, dno,dname,dmgr, cno,cname, score} (1) 一个系有若干学生, 但一个学生只属于一个系 ; (2) 一个系只有一个系主任 ; (3) 一个学生可以选多门课程, 每门课程可以有多个学生选 ; (4) 每个学生的每门课只有一个成绩则最小函数依赖集 F={sno sname,sno dno, dno dname,dno dmgr,cno cname,(sno,cno) score} 下面是数据示例, 如表 5-1 所示表 5-1 数据示例 sno sname dno dname dmgr cno cname score S1 张三 01 计算机系张明 01 数据库 80 S1 张三 01 计算机系张明 02 操作系统 70 S1 张三 01 计算机系张明 03 C 语言 90 S1 张三 01 计算机系张明 04 汇编语言 85. 根据上面的数据内容, 这个关系存在如下问题 (1) 数据冗余太大同样一个学生, 姓名出现多次, 同样一个系, 系名和系主任名也出现了多次, 课程名称也是如此 (2) 更新异常当更新数据时, 系统要付出很大代价来维护数据库完整性比如某系更换系主任, 则必须修改与该系有关的每个元组 (3) 插入异常如果一个系成立, 尚无学生, 就无法把这个系的信息存入数据库 (4) 删除异常某个系的学生全部毕业了, 在删除该系学生信息时, 这个系的信息就丢了鉴于以上种种问题, 可得出结论 :student 关系不是一个好的模式, 一个好的模式不该发生数据修改异常和大量数据冗余, 模式需要规范化规范化的主要目的是减少数据冗余, 但规范化的程度越高, 关系分解越细, 查询时就需要做连接运算, 系统运行效率会降低大多数生产环境的数据库模式满足三范式第一范式定义 : 设一个关系为 R(U), 若 U 中的每个属性都是不可再分的, 或者说都是不被其第 5 章科关系规范化

4 数据库原理与应用教程基于 SQL Server 他属性所包含的独立属性, 则称关系 R(U) 是符合第一范式的 (First Normal Form), 简称 1NF 设一个学生关系 ( 学号, 姓名, 性别, 系号, 系名 ) 关系中的 5 个属性均不可再拆分, 符合 1NF, 但如果关系中增加属性联系方式, 则不符合 1NF, 因为联系方式还可以细分为联系电话 QQ 号码等 2. 第二范式定义 : 设一个关系为 R(U), 它是满足第一范式的, 若 R 中不存在非主属性对候选码的部分函数依赖, 则称该关系是符合第二范式的 (Second Normal Form), 简称 2NF 设一个成绩关系 ( 学号, 姓名, 课程号, 课程名, 成绩 ) 上述关系的 5 个属性均不可再拆分, 符合 1NF 根据分析关系中的学号和课程号可以组合在一起作为候选码, 能函数决定其他非主属性, 也就是 ( 学号, 课程号 ) 姓名 ( 学号, 课程号 ) 课程名 ( 学号, 课程号 ) 成绩, 但是存在候选码的真子集也能决定非主属性, 学号姓名课程号课程名, 也就是说, 姓名和课程名都是部分函数依赖 ( 学号, 课程号 ), 如果把部分函数依赖消除掉就能满足第二范式 3. 第三范式定义 : 设一个关系为 R(U), 它是满足第一范式的, 若不存在这样的码 X, 属性组 Y 及非主属性 Z, 使得 X Y,Y Z 成立, 则称该关系是符合第三范式的 (Third Normal Form), 简称 3NF 设一个成绩关系 ( 学号, 姓名, 课程号, 课程名, 成绩, 系号, 系名 ) 上述关系的 7 个属性均不可再拆分, 符合 1NF 根据分析关系中的学号和课程号可以组合在一起作为候选码, 能函数决定其他非主属性, 但存在 ( 学号, 课程号 ) 系号, 系号系名, 也就是 ( 学号, 课程号 ) 传递决定系名, 或系名传递依赖 ( 学号, 课程号 ), 如果把传递函数依赖消除掉就能满足第三范式 4.BC 范式定义 : 设一个关系为 R(U), 它是满足第一范式的, 若 R 中不存在任何属性对候选码的传递函数依赖, 则称该关系是符合 BC 范式的 (Boyce-Codd Normal Form), 简称 BCNF BCNF 通常称为扩充的 3NF, 任何属性都不能存在对码的传递依赖设一个关系 SCT(S,C,T),S 为学生,C 为课程,T 为教师每名教师只教一门课, 每门课有若干教师, 每个学生可选某门课, 对应一个固定教师 (S,C) T ; (S,T) C; T C 其中前两个是候选码, 所有属性都是主属性, 满足 3NF, 但存在 (S,C) T, T C, 就是主属性对码的传递依赖, 不符合 BCNF 可拆分为:(S,T) 和 (T,C) 5.4NF 多值依赖属 4NF 的定义范围, 比函数依赖要复杂得多在关系模式中, 函数依赖不能表示属性值之间的一对多联系, 这些属性之间有些虽然没有直接联系, 但存在间接的联系, 把没有直接联系但有间接联系称为多值依赖的数据依

5 赖例如, 教师和学生之间没有直接联系, 但教师和学生可通过系名或任课把教师和学生联系起来定义 : 设 R(U) 是属性集 U 上的一个关系模式 X Y Z 是 U 的子集, 并且 Z=U-X-Y 关系模式 R(U) 中多值依赖 X Y 成立, 当且仅当对 R(U) 的任一关系 r, 给定的一对 (x,z) 值有一组 Y 的值, 这组值仅决定于 x 值而与 z 值无关平凡的多值依赖与非平凡的多值依赖 : 若 X Y, 而 Z 为空集, 则称 X Y 为平凡的多值依赖 ; 若 Z 不为空, 则称其为非平凡的多值依赖设有这样一个关系 ( 仓库管理员, 仓库号, 库存产品号 ), 假设一个产品只能放到一个仓库中, 但是一个仓库可以有若干管理员, 那么对应于一个 ( 仓库管理员, 库存产品 ) 有一个仓库号, 而实际上, 这个仓库号只与库存产品号有关, 与管理员无关, 就说这是多值依赖 6. 案例分析假如存在一个记录学生课程成绩的表格, 如表 5-2 所示, 按照数据库三范式设计关系表 5-2 学生成绩表学号姓名课程编号课程介绍成绩任课教师编号教师名称教师联系电话 101 李良 01 Java 语言王帅李良 01 JSP 技术张楠赵阳 01 Java 语言王帅赵阳 03 物理曲晓钢 ) 按照第一范式来设计上述表格中的属性均为独立属性, 不可再分, 按照表格中属性设计关系, 已经满足第一范式成绩关系 score( 学号, 学生姓名, 课程编号, 课程介绍, 课程成绩, 任课教师编号, 教师名称, 教师联系电话 ) 最小函数依赖集 ={ 学号学生姓名, 课程编号课程介绍, ( 学号, 课程编号 ) 课程成绩, ( 学号, 课程编号 ) 任课教师编号, 任课教师编号教师名称, 任课教师编号教师联系电话 } 学号学生姓名, 那么根据依赖的增广性规则 : ( 学号, 课程编号 ) 学生姓名 63 第 5 章科关系规范化

6 数据库原理与应用教程基于 SQL Server 课程编号课程介绍, 那么根据依赖的增广性规则 : ( 学号, 课程编号 ) 课程介绍 ( 学号, 课程编号 ) 课程成绩 ( 学号, 课程编号 ) 任课教师编号根据依赖的传递性,( 学号, 课程编号 ) 任课教师编号, 任课教师编号教师名称, 任课教师编号教师联系电话, 则 ( 学号, 课程编号 ) 教师名称 ( 学号, 课程编号 ) 教师联系电话可见 ( 学号, 课程编号 ) 是候选码, 可为主码, 可以函数决定所有非主属性 2) 按照第二范式来设计分析部分依赖, 非主属性依赖主码的部分属性其中, 学生姓名依赖于学号, 不依赖于课程编号 ; 课程介绍依赖于课程编号, 不依赖于学号其余项都完全依赖主码不消除部分依赖的缺点 : 同一个学生有多个成绩, 学生姓名就会重复多次, 同样一门课会有多个学生选, 课程介绍也会重复多次信息冗余, 不利于维护将部分依赖属性消除, 单独建立关系规范后的关系为 : 关系 score( 学号, 课程编号, 课程成绩, 任课教师编号, 教师名称, 教师联系电话 ), 其中 ( 学号, 课程编号 ) 作主码关系 student( 学号, 学生姓名 ), 其中学号作主码关系 course( 课程编号, 课程介绍 ), 其中课程编号作主码 3) 按照第三范式来设计分析传递依赖属性, 非主属性除依赖主码外, 还依赖其他非主属性, 造成依赖的传递教师名称, 教师联系电话除依赖主码外, 均依赖非主属性任课教师编号, 造成了传递依赖关系, 即 ( 学号, 课程编号 ) 任课教师编号, 任课教师编号 ( 教师姓名教师联系电话 ) 将传递依赖关系的字段消除, 单独建立关系规范后的关系为 : 关系表 score( 学号, 课程编号, 课程成绩, 任课教师编号 ), 其中 ( 学号, 课程编号 ) 作主码关系 student( 学号, 学生姓名 ), 其中学号作主码关系 course( 课程编号, 课程介绍 ), 其中课程编号作主码关系 teacher( 任课教师编号, 教师名称, 教师联系电话 ), 其中任课教师编号作主码小结关系设计是使用数据库的重要环节, 本章主要讲解如何设计合理的关系本章首先讲解函数依赖, 包括一般函数依赖平凡与非平凡函数依赖部分与完全函数依赖传递依赖最小函数依赖集等内容 ; 接下来重点讲解了数据库范式, 包括 1NF 2NF 3NF BCNF

7 和 4NF, 其中前三个范式是数据库设计时常用的, 并通过具体案例介绍了规范化过程习题 1. 什么是一般函数依赖? 2. 什么是平凡和非平凡函数依赖? 3. 什么是部分和完全函数依赖? 4. 什么是传递函数依赖? 5. 假设存在如下员工关系, 写出最小函数依赖集, 并根据最小函数依赖集找出候选码员工 ( 员工编号, 员工姓名, 员工年龄, 员工性别, 入职日期, 部门编号, 部门名称, 部门经理 ) 6. 按照数据库三范式对习题 5 中的员工关系进行规范化 65 第 5 章科关系规范化

复习上节课内容

复习上节课内容第六章关系数据理论范式一关系模式相关定义定义 6.4: 设 K 为 R(U,F) 中的属性或属性组合若 K U, 则 K 称为 R 的侯选码 ; 若候选码多于一个, 则选定其中的一个做为主码 ; 主属性与非主属性包含在任何一个候选码中的属性, 称为主属性 ; 不包含在任何码中的属性称为非主属性或非码属性 ; 最简单情况 : 一个属性是码 ; 最极端情况 : 整个属性组是码, 也称全码 ;