范式与数据库设计

aicehua

贡献于2014-03-08

字数:0 关键词: 数据库建模

数据库基础 范式与数据库设计 0 小张的数据设计之旅 • 小张到义软公司后,老丁给他安排了一个 考验: – 设计义软公司的一个内部管理系统 – 要求能够管理员工信息,部门信息,以及公司 正在进行的项目信息 – 要求:不会发生插入异常、删除异常、更新异 常,数据冗余应尽可能少 1 小张的数据设计之旅 • 小张知道关系数据库是由一组关系组成的, 那么针对一个具体问题,应该如何构造一 个适合的数据模式? – 也就是应构造几个关系,每个关系由哪些属性 组成的? – 其实这是关系数据库的模式设计问题,规范化 理论正是指导我们进行设计的指南和有力工具 2 数据依赖 磨刀不误砍柴功 3 关系模式的定义 • 关系模式由五部分组成,即它是一个五元 组: R(U, D, DOM, F) R: 关系名 U: 组成该关系的属性名集合 D: 属性组U中属性所来自的域 DOM:属性向域的映象集合 F: 属性间数据的依赖关系集合 关系模式的定义 • 在实际应用中,这些约束条件有些是通过对 属性取值范围的限定反映出来,有些是通 过属性间的相互关联反映出来 – 前者限定属性取值范围:例如学生成绩必须在 0-100之间 – 后者定义属性值间的相互关连(主要体现于值 的相等与否),这就是数据依赖,它是数据库 模式设计的关键 5 关系模式的定义 • 在关系模式中,对DB模式设计影响最大的 是U和F,我们把五元组简化为三元组 R(U,F) 6 R: 关系名 U: 组成该关系的属性名集合 F: 属性间数据的依赖关系集合——数据依赖 数据依赖 • 数据依赖特点 – 是通过一个关系中属性间值的相等与否体现出 来的数据间的相互关系 – 是现实世界属性间相互联系的抽象 – 是数据内在的性质 – 是语义的体现 7 数据依赖 • 数据依赖对关系模式的影响 – 在数据依赖中,最重要的是函数依赖 – 函数依赖是指对当前关系r的任意两个元组,如 果X值相同,则要求Y值也相同,即有一个X值就 有一个Y值与之对应 8 数据依赖对关系模式的影响 • 数据依赖会对关系模式产生重要影响,下面以图 书馆系统来举例说明 • 在学校图书馆中,我们面临这些对象 • 借书证,读者,读者单位,联系电话,书号,书名, 出版社,出版社地址,借阅日期 • 分析这些对象,我们得到一组属性 • U={借书证号,读者姓名,读者单位,单位电话,书号, 书名,出版社,出版社地址,借阅日期} 9 数据依赖对关系模式的影响 • 数据之间的关系是语义的体现,我们得到的这些 属性有下面一些语义规定: • 每个读者只属于一个单位 • 每个读者可借多本书 • 不同的书可有相同的书名 • 一个单位只设一个联系电话号码 • 不同的单位不能有相同的电话号码 • 一个出版社有一个地址,不同出版社可以在同一个地 址 10 数据依赖对关系模式的影响 • 由此得到属性组U上的一组函数依赖: • F={借书证号→读者姓名,借书证号→读者单位,借书 证号→单位电话,读者单位↔单位电话,书号→书名, 书号→出版社,书号→出版社地址,出版社→出版社地 址, (借书证号,书号)→借阅日期} 11 借书证号 书 号 读者姓名 书 名 借阅日期 读者单位 单位电话 出版社 出版社地址 函 数 依 赖 图 数据依赖对关系模式的影响 • 如果只考虑函数依赖这一种数据依赖,就 得到一个描述图书馆的关系模式 Borrow(U,F) • Borrow由一个单一的关系模式构成: • Borrow(借书证号,读者姓名,读者单位,单位电话,书号, 书名,出版社,出版社地址,借阅日期) • 这不是一个好的关系! 12 数据依赖对关系模式的影响 • Borrow关系的问题 – 数据冗余太大,一个读者可以借多本书,有关 这个读者的信息就要在关系中出现多次;而一 个单位有许多读者,每个读者都有相同的信息; 同时图书馆又要面对许多单位…… – 修改复杂,如果某个读者更换了单位,他若借 了10本书,有关他所在单位的信息在Borrow中 重复存放10次,当数据更新时必须无遗漏地修 改10个元组中全部的信息 13 数据依赖对关系模式的影响 • Borrow关系的问题 – 插入异常,如果刚买进一批新书,因为还没有 读者借阅,就无法把有关新书的信息存入 Borrow中,这就是插入异常 – 删除异常,如果某个读者把他借的所有的书都 还给了图书馆,那么随着这些书的相关信息的 删除,这个读者的信息也丢失了。这就产生了 删除异常,即不该删除的信息也删除了 14 数据依赖对关系模式的影响 • Borrow不是一个好的关系模式! – 原因是由存在于关系模式中的某些函数依赖引 起的 – 怎么消除这些函数依赖? – 规范化理论正是用来消除函数依赖,从而改造 关系模式的指南 15 数据依赖 • 数据依赖对关系模式产生了影响,为了解 决这些问题,我们需要分析都有哪些类型 的依赖,然后逐一解决 16 数据依赖相关概念 函数依赖 17 数据依赖相关概念 • 函数依赖 – 定义 • 设R(U)是一个关系模式,U是R的属性集合,X和Y是U 的子集。对于R(U)的任意一个可能的关系r,如果r中 不存在两个元组,它们在X上的属性值相同,而在Y 上的属性值不同,则称“X函数决定Y”或“Y函数依 赖于X”,记作X→Y。 – 说明 • 函数依赖不是指关系模式R的某个或某些关系实例满 足的约束条件,而是指R的所有关系实例均要满足的 约束条件。 • 函数依赖是语义范畴的概念。 • 设计者可对现实世界作强制规定 18 数据依赖相关概念 • 函数依赖 – 术语和记号 • X→Y,但Y⊄X,则称X→Y是非平凡函数依赖。 • X→Y,但Y⊆X,则称X→Y是平凡函数依赖。 • 若X→Y,则X叫做决定因素。 • 若X→Y,Y→X,则记作X↔Y。 • 若Y不函数依赖于X,则记作X↛Y 19 数据依赖相关概念 • 完全函数依赖与部分函数依赖 – 定义 • 在R(U)中,如果X→Y,并且对于X的任意一个真子集 X’,都有X’↛Y,则称Y完全函数依赖于X,记作 : • 若X→Y,但Y不完全函数依赖于X,则称Y部分函数依 赖于X,记作: 20 fXY YX p 数据依赖相关概念 • 传递函数依赖 – 定义 • 在R(U)中,如果X→Y(Y⊄X),Y→Z,且 Y↛X,则称Z 传递函数依赖于X,记作 21 tXZ 数据依赖相关概念 • Borrow关系中的函数依赖 22 函 数 依 赖 图 p 借书证号 书 号 读者姓名 书 名 借阅日期 读者单位 单位电话 出版社 出版社地址 f p p p p p t t 数据依赖相关概念 • 码 – 设K为R(U,F)中的属性或属性组,若 , 则称K为R的候选码,若候选码多于一个,则选 定其中一个为主码 23 fKU 数据依赖相关概念 • 至此,我们了解了依赖的种类,现在该是 解决他们的时候了! • 使用什么样的方法来去除依赖呢? – 在数据库设计中,规范化理论是指导我们进行 设计的指南和有力工具 – 在数据库设计中,我们使用范式来标示关系模 式的的规范化级别,级别越高,规范化程度越 高 24 范式 规范化标准 25 范式 • 范式是符合某一种级别的关系模式的集合。 • 关系数据库中的关系必须满足一定的要求。 满足不同程度要求的为不同范式。 • 范式的种类: 第一范式(1NF) 第二范式(2NF) 第三范式(3NF) BC范式(BCNF) 第四范式(4NF) 第五范式(5NF) 范式 • 范式之间存在的联系 – 1NF⊃2NF⊃3NF⊃BCNF⊃4NF⊃5NF – 一个低一级范式的关系模式通过模式分解可转 化成若干个高一级范式的关系模式集合,这个 过程就叫做规范化。 27 范式 • 第一范式 – 定义 • 若一个关系模式R的所有属性都是不可再分的基本 数据项,则R∈1NF。 • 例: Borrow∈1NF,但不是一个好的关系模式。 • Borrow(借书证号,读者姓名,读者单位,单位电话, 书号,书名,出版社,出版社地址,借阅日期) 28 范式 • 第一范式示例 – 要求每一个分量都必须是不可分割的数据项 29 学号 姓名 年龄 系别 系主 任 课程成绩 课程号 成绩 S1 赵亦 17 计算机 刘伟 C1 90 S1 赵亦 17 计算机 刘伟 C2 82 S2 钱尔 18 信息 王平 C3 84 S3 刘思佳 17 信息 王平 C2 68 不符合规范 约束条件 范式 • 第一范式示例 – 要求每一个分量都必须是不可分割的数据项 30 学号 姓名 年龄 系别 系主 任 课程号 成绩 S1 赵亦 17 计算机 刘伟 C1 90 S1 赵亦 17 计算机 刘伟 C2 82 S2 钱尔 18 信息 王平 C3 84 S3 刘思佳 17 信息 王平 C2 68 处理后符合规 范约束条件 范式 • 第二范式 – 定义 • 若关系模式R∈1NF,并且每一非主属性都完全函数 依赖于R的码,则R∈2NF – 我们将Borrow分解为2NF,即要消除非主属性 对码的部分函数依赖 – 方法:投影分解法 31 范式 • 第二范式 32 把Borrow分解为三个关系模式: Reader(借书证号,读者姓名,读者单位,单位电话) Book(书号,书名,出版社,出版社地址) BORR(借书证号,书号,借阅日期) 分 解 图 p 借书证号 书 号 读者姓名 书 名 借阅日期 读者单位 单位电话 出版社 出版社地址 f p p p p p t t 范式 • 第二范式 – 函数依赖图 – 这三个关系都属于2NF,联合起来共同表达了 原来一个关系所表达的内容,且原来关系不能 表达的,它们也能表达。因此,第二范式比第 一范式有更强的表达能力,是对现实世界更准 确的描述。 33 读者姓名 借书证号 读者单位 单位电话 书 号 出版社 书 名 出版社地址 借阅日期 书号 借书证号 范式 • 第二范式 – 2NF的关系模式还会存在某些问题: • Reader(借书证号,读者姓名,读者单位,单位电 话) • Book(书号,书名,出版社,出版社地址) – 原因:存在传递函数依赖 34 冗余消失 仍有冗余 冗余消失 仍有冗余 范式 • 第二范式示例 – 例 35 学 号 姓名 年 龄 系别 系主 任 S1 赵亦 17 计算机 刘伟 S2 钱尔 18 信息 王平 S3 刘思佳 17 信息 王平 学 号 课程 号 成 绩 S1 C1 90 S1 C2 82 S2 C3 84 S3 C2 68 将表进行分解为两个满 足2NF的关系模式 范式 • 第三范式 – 定义 • 若关系模式R中不存在候选码X,属性组Y以及非主 属性Z(Z Y),使得X→Y,Y→Z和 Y X成立,则 R∈3NF – 要消除关系模式中非主属性对码的传递函数依 赖,用投影分解法 36  读者姓名 借书证号 读者单位 单位电话 书 号 出版社 书 名 出版社地址 范式 • 第三范式 – 投影分解后: • Reader(借书证号,读者姓名,读者单位) • Unitphone(读者单位,单位电话) • Book(书号,书名,出版社) • Press(出版社,出版社地址) • Borrow(借书证号,书号,借阅日期) 37 读者姓名 借书证号 读者单位 读者单位 单位电话 出版社 书 号 书 名 出版社 出版社地址 书 号 借书证号 借阅日期 范式 • 第三范式 – 一个属于3NF的关系模式一般可令人满意 – 局部依赖和传递依赖是模式产生冗余和异常的 两个重要原因,由于3NF中不存在非主属性对 码的局部和传递函数依赖,因此消除了很大一 部分异常现象,具有较好的性能 38 范式 • 第三范式示例 – 不仅满足第二范式,而且任何一个非主属性都 不传递于任何主关键字 39 学号 姓名 年龄 系别 S1 赵亦 17 计算机 S2 钱尔 18 信息 S3 刘思佳 17 信息 系别 系主任 计算机 刘伟 信息 王平 学 号 课程 号 成 绩 S1 C1 90 S1 C2 82 S2 C3 84 S3 C2 68 处理后符合规 范约束条件 范式 • BC范式(BCNF) – 设有关系模式 STC(学生,教师,课程) – 若规定: • 每一教师只教一门课,每门课由若干教师教 • 某一学生选定某门课,就确定了一个固定的教师 – 则,F={教师 →课程,(学生,课程) →教师, (学生,教师) →课程} 40 范式 • BC范式 –STC的候选码为:(学生,课程),(学生,教师) – 函数依赖图为: – 该关系存在的异常: • 插入异常:学生刚入学,没有课程 • 删除异常:学生毕业,删除学生元组后,教师授课信息 丢失 • 数据冗余:教师多次存储 • 修改复杂:课程改名,需要修改多处 41 教师 学生 课程 课程 学生 教师 范式 • BC范式 –STC关系出现问题的原因在于:主属性课程依赖 于教师,即课程部分依赖于码(学生,教师) – 解决这一问题同样可用投影分解法,将STC分解 为两个关系模式: •ST(学生,教师), TC(教师,课程) – 定义 • 关系模式R∈1NF,若X→Y,且Y X时,X必含有码, 则R∈BCNF • 即:在R中,若每个决定因素都包含码,则R∈BCNF 42  范式 • BC范式 – 由定义可知: • STC(学生,教师,课程)不属于BCNF,因为教师→课程, 但教师即不是候选码,也不包含候选码 •ST(学生,教师)和 TC(教师,课程)都属于BCNF。 –BCNF即检查非主属性,又检查主属性,比3NF 限制更严 43 范式 • BC范式 – BC范式的特点: • 所有非主属性都完全函数依赖于每个码 • 所有主属性都完全函数依赖于每个不包含它的码 • 没有任何属性完全函数依赖于非码的任何一组属性 – 若R∈BCNF,则⇒R∈3NF。 – 若R∈3NF⇒R∈BCNF,若R只有一个候选码,则 R∈3NF⇒R∈BCNF 44 范式 • BC范式 – 若一个关系DB中的所有关系模式都属于BCNF, 则在函数依赖范畴内已实现了模式的彻底分解, 达到了最高的规范化程度,消除了插入异常和 删除异常 45 范式 • 第四范式,第五范式 – 一般来说,第三范式和BC范式已能满足需求, 因此,这里不再细论,有兴趣的同学可以参阅 相关书籍 46 小张的数据设计之旅 实战篇 47 小张的数据设计之旅 • 温习了数据库设计的规范,小张信心满满 的开始了他的设计之旅 小张的数据设计之旅 • 首先分析涉及到的实体——部门,员工,项 目 • 分析实体的属性,得到 – 部门编号,部门名称,工号,姓名,项目编号, 项目名称,客户名称,客户地址 • 设计关系(部门,员工,项目) – DEP(部门编号,部门名称,工号,姓名,项 目编号,项目名称,客户名称,客户地址) 49 小张的数据设计之旅 • DEP不是一个好的关系!小张笑了,这不典型 的不符合第二范式吗? 50 函 数 依 赖 图 p 工号 项目编号 姓名 项目名称 开始日期 部门编号 部门名称 客户单位 客户地址 f p p p p t t p 小张的数据设计之旅 • DEP不符合第二范式,采用投影分解 51 函 数 依 赖 图 p 工号 项目编号 姓名 项目名称 参与日期 部门编号 部门名称 客户单位 客户地址 f p p p p t t p 把DEP分解为三个关系模式: Employee(工号,姓名,部门编号,部门名称) Project(项目编号,项目名称,客户单位,客户地址) Develop(项目号,工号,参与日期) 小张的数据设计之旅 • 采用投影分解,消除部分依赖,分解成为 第二范式后: – Employee关系中还存在: • F: 工号->部门编号->部门名称 • 传递依赖造成数据冗余 – 同样的,Project中也存在同样的问题 – 因此,需要消除传递依赖,分解成为第三范式 52 姓名 工号 部门编号 部门名称 项目号 客户单位 项目名 客户地址 小张的数据设计之旅 • 投影分解消除传递依赖后: – Employee(工号,姓名,部门编号) – Department(部门编号,部门名称) – Customer(客户,客户地址) – Project(项目编号,项目名称,客户) – Develop(项目编号,工号,参与日期) 53 姓名 工号 部门编号 部门编号 部门名称 客户 项目编号 项目名称 客户 客户地址 工号 项目编号 参与日期 小张的数据设计之旅 • 分解后的关系已经是BC范式,达到了老丁 提的要求,小张满意的笑了 • 在分解的过程中,小张想到,有没有更好 的方法? – 小张向同在义软工作的同事老马求助: – 老马说:ER模型! 54 小张的数据设计之旅 • ER模型! – 小张顿悟,自己光顾着范式,却遗忘了数据库 设计的方法——先把现实世界抽象为信息世界, 再将信息世界转换为逻辑数据模型 – 也就是说先ER模型,再将ER模型转换为关系模 式 55 小张的数据设计之旅 • 第一步,抽象现实世界为ER模型 56 项目 部门 组成 n 1 开发 n m 产物 人数 员工 客户 1 n 委托 小张的数据设计之旅 • 将ER模型转换为关系 – 实体直接转换为一个关系,实体名称作为关系 名称,该关系包括对应实体的全部属性,并确 定出该关系的关键字 – 联系 • 一对一联系:作为关系的属性 •A与B是一对多联系:将A的码作为候选码放入B中 •A与B是多对多联系:将联系作为一个关系,A与B的 码作为候选码 57 小张的数据设计之旅 • 将ER模型转换为关系 58 Employee(工号,姓名,部门编号) Department(部门编号,部门名称) Customer(客户,客户地址) Project(项目编号,项目名称,客户) Develop(项目编号,工号,参与日期) 项目 部门 组成 n 1 开发 n m 产物 人数 员工 客户 1 n 委托 小张的数据设计之旅 • ER模型转换而来的关系与直接设计而来的 关系一样,殊途同归 – ER模型显得更简便 – ER模型能规避为了满足范式而进行的分解问题 – 范式是数据设计的规范,使用ER模型时也要参 照 • 小张使用两种方法设计了自己满意的数据 库,高兴的笑了,这次是发自内心的笑  59 小张的数据设计之旅 • 小张将成果提交给老丁,老丁看完后说: – 果然是刚毕业的同学啊! • 小张不解: – 有什么问题吗? • 老张说: – 范式是把双刃剑,设计时必须参照他,但是并 不一定要完全参照 – 有些时候,为了性能,往往会牺牲范式,添加 适当的冗余来换取整体性能的提高,比如我们 可以将部门名称冗余到员工表中 60 小张的数据设计之旅 • 适当的冗余换来的是系统的高效率 – Employee(工号,姓名,部门编号), Department(部门编号,部门名称) • 要获取工号对应的部门名称,需要关联Employee和 Department做笛卡尔积运算 • 在数据量较大时,关联非常消耗时间 – Employee(工号,姓名,部门编号,部门名称), Department(部门编号,部门名称) • 将部门名称冗余进Employee,查询时可以直接根据 工号得到部门名称 • 牺牲更新和存储空间换取查询的便利 61 小张的数据设计之旅 • 小张似懂非懂的点了点头 • 老丁笑着说: – 时间见真章、实践见真章,现在不理解没关系, 多做几个项目就明白了 – 关于更为详细的数据库设计,且听下回分解 62 单元小结 学有所思 单元小结 • 数据依赖对关系模式有什么影响? • 第一范式,第二范式,第三范式,BC范式 有什么特点? • ER模型怎么转换为关系模式? 课后练习 温故而知新 65 课后练习 • 举例说明数据依赖对关系模式的影响 • 在个人博客中,可以发布自己的日志,每 篇日志有自己的分类,并且还能添加多个 tag,同时,每个tag还能添加到多篇日志中。 请设计个人博客的数据库,要求满足BC范 式。 66 67

下载文档,方便阅读与编辑

文档的实际排版效果,会与网站的显示效果略有不同!!

需要 10 金币 [ 分享文档获得金币 ] 0 人已下载

下载文档

相关文档