<!-- /* Font Definitions */ @font-face {font-family:"MS 明朝"; panose-1:2 2 6 9 4 2 5 8 3 4; mso-font-alt:"MS Mincho"; mso-font-charset:128; mso-generic-font-family:roman; mso-font-pitch:fixed; mso-font-signature:-1610612033 1757936891 16 0 131231 0;} @font-face {font-family:SimSun; panose-1:2 1 6 0 3 1 1 1 1 1; mso-font-alt:宋体; mso-font-charset:134; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:3 135135232 16 0 262145 0;} @font-face {font-family:Century; panose-1:2 4 6 4 5 5 5 2 3 4; mso-font-charset:0; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:647 0 0 0 159 0;} @font-face {font-family:"/@SimSun"; panose-1:2 1 6 0 3 1 1 1 1 1; mso-font-charset:134; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:3 135135232 16 0 262145 0;} @font-face {font-family:"/@MS 明朝"; panose-1:2 2 6 9 4 2 5 8 3 4; mso-font-charset:128; mso-generic-font-family:roman; mso-font-pitch:fixed; mso-font-signature:-1610612033 1757936891 16 0 131231 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-parent:""; margin:0mm; margin-bottom:.0001pt; text-align:justify; text-justify:inter-ideograph; mso-pagination:none; font-size:10.5pt; mso-bidi-font-size:12.0pt; font-family:Century; mso-fareast-font-family:"MS 明朝"; mso-bidi-font-family:"Times New Roman"; mso-font-kerning:1.0pt;} /* Page Definitions */ @page {mso-page-border-surround-header:no; mso-page-border-surround-footer:no;} @page Section1 {size:595.3pt 841.9pt; margin:99.25pt 30.0mm 30.0mm 30.0mm; mso-header-margin:42.55pt; mso-footer-margin:49.6pt; mso-paper-source:0; layout-grid:18.0pt;} div.Section1 {page:Section1;} -->
关 系数据 库设计 之 时 是要遵守一定的 规则 的。尤其是数据 库设计 范式 现简单 介 绍 1NF (第一范式), 2NF (第二范式), 3NF (第三范式)和 BCNF ,另有第四范式和第五范式留到以后再介 绍 。在你 设计 数据 库 之 时 ,若能符合 这 几个范式,你就是数据 库设计 的高手。
第一范式( 1NF ):在 关 系模式 R 中的 每 一个具体 关 系 r 中,如果 每 个属性 值 都是不可再分的最小数据 单 位, 则 称 R 是第一范式的 关 系。例:如 职 工号,姓名, 电话 号 码组 成一个表(一个人可能有一个 办 公室 电话 和一个家里 电话 号 码 ) 规 范成 为 1NF 有三 种 方法:
一是重 复 存 储职 工号和姓名 。 这样 , 关键 字只能是 电话 号 码 。
二是 职 工号 为关键 字, 电话 号 码 分 为单 位 电话 和住宅 电话 两个属性
三是 职 工号 为关键 字,但 强 制 每 条 记录 只能有一个 电话 号 码 。
以上三个方法,第一 种 方法最不可取,按 实际 情况 选 取后两 种 情况。
第二范式( 2NF ):如果 关 系模式 R ( U , F )中的所有非主属性都完全依 赖 于任意一个候 选关键 字, 则 称 关 系 R 是属于第二范式的。
例: 选课关 系 SCI ( SNO , CNO , GRADE , CREDIT )其中 SNO 为 学号, CNO 为课 程号, GRADEGE 为 成 绩 , CREDIT 为 学分。由以上条件, 关键 字 为组 合 关键 字( SNO , CNO )
在 应 用中使用以上 关 系模式有以下 问题 :
a. 数据冗余,假 设 同一 门课 由 40 个学生 选 修,学分就重 复 40 次。
b. 更新异常,若 调 整了某 课 程的学分,相 应 的元 组 CREDIT 值 都要更新,有可能会出 现 同一 门课 学分不同。
c. 插入异常,如 计 划 开 新 课 ,由于没人 选 修,没有学号 关键 字,只能等有人 选 修才能把 课 程和学分存入。
d. 删 除异常,若学生已 经结业 ,从当前数据 库删 除 选 修 记录 。某些 门课 程新生尚未 选 修, 则 此 门课 程及学分 记录 无法保存。
原因:非 关键 字属性 CREDIT 仅 函数依 赖 于 CNO ,也就是 CREDIT 部分依 赖组 合 关键 字( SNO , CNO )而不是完全依 赖 。
解决方法:分成两个 关 系模式 SC1 ( SNO , CNO , GRADE ), C2 ( CNO , CREDIT )。新 关 系包括两个 关 系模式,它 们 之 间 通 过 SC1 中的外 关键 字 CNO 相 联 系,需要 时 再 进 行自然 联 接,恢 复 了原来的 关 系
第三范式( 3NF ):如果 关 系模式 R ( U , F )中的所有非主属性 对 任何候 选关键 字都不存在 传递 信 赖 , 则 称 关 系 R 是属于第三范式的。
例:如 S1 ( SNO , SNAME , DNO , DNAME , LOCATION )各属性分 别 代表学号 ,
姓名,所在系,系名称,系地址。
关键 字 SNO 决定各个属性。由于是 单 个 关键 字,没有部分依 赖 的 问题 ,肯定是 2NF 。但 这关 系肯定有大量的冗余,有 关 学生所在的几个属性 DNO , DNAME , LOCATION 将重 复 存 储 ,插入, 删 除和修改 时 也将 产 生 类 似以上例的情况。
原 因: 关 系中存在 传递 依 赖 造成的。即 SNO -> DNO 。而 DNO -> SNO 却不存在, DNO -> LOCATION, 因此 关键辽 SNO 对 LOCATION 函数决定是通 过传递 依 赖 SNO -> LOCATION 实现 的。也就是 说 , SNO 不直接决定非主属性 LOCATION 。
解决目地: 每 个 关 系模式中不能留有 传递 依 赖 。
解决方法:分 为 两个 关 系 S ( SNO , SNAME , DNO ), D ( DNO , DNAME , LOCATION )
注意: 关 系 S 中不能没有外 关键 字 DNO 。否 则 两个 关 系之 间 失去 联 系。
BCNF :如果 关 系模式 R ( U , F )的所有属性(包括主属性和非主属性)都不 传递 依 赖 于 R 的任何候 选关键 字,那 么 称 关 系 R 是属于 BCNF 的。或是 关 系模式 R ,如果 每 个决定因素都包含 关键 字(而不是被 关键 字所包含), 则 RCNF 的 关 系模式。
例:配件管理 关 系模式 WPE ( WNO , PNO , ENO , QNT )分 别 表 仓库 号,配件号, 职 工号,数量。有以下条件
a. 一个 仓库 有多个 职 工。
b. 一个 职 工 仅 在一个 仓库 工作。
c. 每 个 仓库 里一 种 型号的配件由 专 人 负责 ,但一个人可以管理几 种 配件。
d. 同一 种 型号的配件可以分放在几个 仓库 中。
分 析:由以上得 PNO 不能确定 QNT ,由 组 合属性( WNO , PNO )来决定,存在函数依 赖 ( WNO , PNO ) -> ENO 。由于 每 个 仓库 里的一 种 配件由 专 人 负责 ,而一个人可以管理几 种 配件,所以有 组 合属性( WNO , PNO )才能确定 负责 人,有 ( WNO , PNO ) -> ENO 。因 为 一个 职 工 仅 在一个 仓库 工作,有 ENO -> WNO 。由于 每 个 仓库 里的一 种 配件由 专 人 负责 ,而一个 职 工 仅 在一个 仓库 工作,有( ENO , PNO ) -> QNT 。
找一下候 选关 键 字,因 为 ( WNO , PNO ) -> QNT ,( WNO , PNO ) -> ENO ,因此( WNO , PNO )可以决定整个元 组 ,是一个候 选关键 字。根据 ENO->WNO ,( ENO , PNO ) ->QNT ,故( ENO , PNO ) 也能决定整个元 组 , 为 另一个候 选关键 字。属性 ENO , WNO , PNO 均 为 主属性,只有一个 非主属性 QNT 。它 对 任何一个候 选关键 字都是完全函数依 赖 的,并且是直接依 赖 ,所以 该关 系模式是 3NF 。
分析一 下主属性。因 为 ENO->WNO ,主属性 ENO 是 WNO 的决定因素,但是它本身不是 关键 字,只是 组 合 关键 字的一部分。 这 就造成主属性 WNO 对 另外一 个候 选关键 字( ENO , PNO )的部分依 赖 ,因 为 ( ENO , PNO ) -> ENO 但反 过 来不成立,而 P->WNO ,故( ENO , PNO ) -> WNO 也是 传递 依 赖 。
虽 然没有非主属性 对 候 选关键 辽 的 传递 依 赖 ,但存在主属性 对 候 选关键 字的 传递 依 赖 ,同 样 也会 带 来麻 烦 。如 一个新 职 工分配到 仓库 工作,但 暂时处 于 实习阶 段,没有独立 负责对 某些配件的管理 任 务 。由于缺少 关键 字的一部分 PNO 而无法插入到 该关 系中去。又如某个人改成不管配件了去 负责 安全, 则 在 删 除配件的同 时该职 工也会被 删 除。
解决 办 法:分成管理 EP ( ENO , PNO , QNT ), 关键 字是( ENO , PNO )工作 EW ( ENO , WNO )其 关键 字是 ENO
缺 点:分解后函数依 赖 的保持性 较 差。如此例中,由于分解 , 函数依 赖 ( WNO , PNO ) -> ENO 丢 失了 , 因而 对 原来的 语义 有所破坏。没有体 现 出 每 个 仓库 里一 种 部件由 专 人 负责 。有可 能出 现 一部件由两个人或两个以上的人来同 时 管理。因此,分解之后的 关 系模式降低 了部分完整性 约 束。
一个 关 系分解成多个 关 系,要使得分解有意 义 ,起 码 的要求是分解后不 丢 失原来的信息。 这 些信息不 仅 包括数据本身,而 且包括由函数依 赖 所表示的数据之 间 的相互制 约 。 进 行分解的目 标 是达到更高一 级 的 规 范化程度,但是分解的同 时 必 须 考 虑 两个 问题 :无 损联 接性和保持函数依 赖 。 有 时 往往不可能做到既有无 损联 接性,又完全保持函数依 赖 。需要根据需要 进 行 权 衡。
1NF 直到 BCNF 的四 种 范式之 间 有如下 关 系:
BCNF 包含了 3NF 包含 2NF 包含 1NF
小 结 :
目地: 规 范化目的是使 结 构更合理,消除存 储 异常,使数据冗余尽量小,便于插入、 删 除和更新
原 则 :遵从概念 单 一化 " 一事一地 " 原 则 ,即一个 关 系模式描述一个 实 体或 实 体 间 的一 种联 系。 规 范的 实质 就是概念的 单 一化。
方法:将 关 系模式投影分解成两个或两个以上的 关 系模式。
要求:分解后的 关 系模式集合 应 当与原 关 系模式 " 等价 " ,即 经过 自然 联 接可以恢 复 原 关 系而不 丢 失信息,并保持属性 间 合理的 联 系。
注 意:一个 关 系模式 结这 分解可以得到不同 关 系模式集合,也就是 说 分解方法不是唯一的。最小冗 余的要求必 须 以分解后的数据 库 能 够 表达原来数据 库 所有信息 为 前提 来 实现 。其根本目 标 是 节 省存 储 空 间 ,避免数据不一致性,提高 对关 系的操作效率,同 时满 足 应 用需求。 实际 上,并不一定要求全部模式都达到 BCNF 不可。有 时 故意保留部分冗余可能更方便数据 查询 。尤其 对 于那些更新 频 度不高, 查询频 度极高的数据 库 系 统 更是如此。
在 关 系数据 库 中,除了函数依 赖 之外 还 有多 值 依 赖 , 联 接依 赖 的 问题 ,从而提出了第四范式,第五范式等更高一 级 的 规 范化要求。在此,以后再 谈 。
各 位朋友,你看 过 后有何感想,其 实 ,任何一本数据 库 基 础 理 论 的 书 都会 讲这 些 东 西,考 虑 到很多网友是半途出家,来做数据 库 。特找一本 书 大抄特抄一把,各位有什 么问题 ,也 别问 我了,自已去找一本 关 系数据 库 理 论 的 书 去看吧, 说 不定, 对 各位大有帮助。 说 是 说 以上是基 础 理 论 的 东 西, 请 大家想想,你在做数据 库设计 的 时 候 有没有考 虑过 遵 过 以上几个范式呢,有没有在数据 库设计 做得不好之 时 ,想一想, 对 比以上所 讲 ,到底是 违 反了第几个范式呢?
我 见过 的数据 库设计 ,很少有人做到很符合以上几个范式的,一般 说 来,第一范式大家都可以遵守,完全遵守第二第三范式的人很少了,遵守的人一定就是 设计 数据 库 的高手 了, BCNF 的范式出 现 机会 较 少,而且会破坏完整性,你可以在做 设计 之 时 不考 虑 它,当然在 ORACLE 中可通 过 触 发 器解决其缺点。以后我 们 共同做 设计 之 时 ,也希望大家遵守以上几个范式 。