第八章 数据库课件6db关系数据库理论1new.ppt

第六章 关系数据理论 任何一个二目关系模式R（A，B）一定属于BCNF吗？ 一个全是主属性的关系模式一定可以达到第几范式？ 一个全码的关系模式一定可以达到第几范式？ 关系模式R（A，B，C），有函数依赖集F＝{AB → C,BC → A},则最高达到第几范式？ 应用系统设计的共同问题： 如何把现实世界表达成合适的数据库模式,即设计数据库的逻辑结构 以关系模型为背景讨论： 针对一个具体问题,如何构造合适的数据模式? 构造几个关系? 每个关系由哪些属性组成? 等等。 这些直接决定数据库的运行效率 关系模式的形式化定义 关系模式由五部分组成，即它是一个五元组： R(U, D, DOM, F) R： 关系名 U： 组成该关系的属性名集合 D： 属性组U中属性所来自的域 DOM：属性向域的映象集合 F： 属性间数据的依赖关系集合 注意： 插入异常： 该插入的数据未插入√ 不该插入的数据被插入× 删除异常： 该删除的数据未删除× 不该删除的数据被删除√ 插入异常： 如果没有职工具有8级工资，则8级工资的工资数额就难以插入。 删除异常： 如果仅有职工赵明具有4级工资，如果将赵明删除，则有关4级工资的工资数额信息也随之删除了。 数据冗余： 职工很多，工资级别有限，每一级别的工资数额反复存储多次。 更新异常： 如果将5级工资的工资数额调为620，则需要找到每个具有5级工资的职工，逐一修改。 结论： 该关系模式不是一个好的模式。 “好”的模式： 不会发生插入异常、删除异常、更新异常， 数据冗余应尽可能少。 原因：由存在于模式中的某些数据依赖引起的: 工号?姓名 工号?级别 级别?工资 6.2 规范化 规范化理论正是用来改造关系模式，通过分解关系模式来消除其中不合适的数据依赖，以解决插入异常、删除异常、更新异常和数据冗余问题，把不好的关系模式变成好的关系模式。 数据依赖 数据依赖 函数依赖(Functional Dependency,FD) 多值依赖(Multivalued Dependency,MVD) X 数据依赖是针对数据模式，而不是特定的实例 是属性间的关联 是一种约束 函数依赖 假设给定 X 属性的值，就知道 Y的值，那么 X 函数决定 Y，记作X→Y 函数依赖 说明 函数依赖不是指关系模式R的某个或某些关系实例满足的约束条件，而是指R的所有关系实例均要满足的约束条件。 函数依赖是语义范畴的概念。只能根据数据的语义来确定函数依赖。 例如“姓名→年龄”这个函数依赖只有在不允许有同名人的条件下成立 函数依赖反映了一种语义完整性约束 说明（续） 函数依赖与属性间的联系类型有关 函数依赖 函数依赖的导出 通过关系中各属性的实际意义直接定义 通过Amstrong公理推导 通过有代表性的关系值反推 函数依赖的分类 完全函数依赖与部分函数依赖 在关系模式R(U)中，如果X→Y，并且对于X的任何一个真子集X’，都有 X’ Y, 则称Y完全函数依赖于X，记作X F Y。 若X→Y，但Y不完全函数依赖于X，则称Y部分函数依赖于X，记作X P Y。 注意： 只有当决定因素是组合属性时，讨论部分依赖才有意义 函数依赖的分类 传递函数依赖与直接函数依赖 在R(U)中,如果X?Y,(Y?X),Y?X,Y?Z,则称Z对X传递函数依赖,记做： 设有关系模式R（职工名，项目名，工资，部门名，部门经理），若规定每位职工可参加多个项目，各领一份工资；每个项目只属于一个部门管理；每个部门只有一个经理。 思考：关系模式R的基本函数依赖？ （项目，职工）→工资 项目→部门 部门←→经理 6.2.2 码 码 (形式化定义) 定义：设有关系模式R(U，F)，X为U的子集， 若X U，则X为R的一个候选码(Candidate Key)。 最简单情况——单个属性为码； 最极端情况——全部属性为码，称为全码。 6.2.3范式(Normal Forms) 异常的原因 数据依赖的约束 解决方法 数据库设计的规范化→分解 范式是对关系的不同数据依赖程度的要求，是规范化过程中为不同程度的规范化要求而设立的不同标准。 范式(Normal Forms) 规范化 各种不同的范式都是以对关系模式的属性间允许的数据依赖加以限制的形式表示的。 一个关系满足某个范式所规定的一系列条件时,它就属于该范式。 可以用规范化要求来设计数据库。 也可以用来验证设计结果的合理性，用其指导优化过程。 1NF→2NF→3NF→BCNF→4NF 范式——第一范式(1NF) 当且仅当一个关系R（U）中，每一个元组的每一个属性只含有一个值（不可再分的基本数据元素，其原子值）时，该关系属于第一范式。即不能以集合、序列等