关系数据理论

6.1 为什么要学习关系数据理论
- 什么是好的数据库逻辑设计
- 什么是数据依赖
- 关系模式的简化表示
6.2 规范化 — 关系的规范化理论
- 6.2.1 函数依赖
- - 1.函数依赖
  - 2.平凡函数依赖与非平凡函数依赖
  - 3.完全函数依赖与部分函数依赖
  - 4.传递函数依赖
- 6.2.2 码
- - 候选码、超码
  - 主码
  - 主属性、非主属性
  - 全码
  - 外码
- 6.2.3 范式
- 6.2.4 第二范式（2NF）
- - 2NF的问题
- 6.2.5 第三范式（3NF）
- - 3NF的问题
- 6.2.6 BC范式（BCNF）
- 6.2.9 规范化小结
6.3 数据依赖的公理系统
- 函数依赖闭包
- 求属性集X 关于F的闭包X~F~^+^
- 函数依赖集等价的概念
- 最小依赖集
6.4 模式的分解
- 6.4.1 模式分解的3个定义
- - 模式分解示例
- 6.4.2 分解的无损连接性和保持函数依赖性
- - 1.具有无损连接性的模式分解
  - 2.保持函数依赖的模式分解
  - 3.分解的无损连接性和保持函数依赖性
- 6.4.3 模式分解的算法
6.5 小结
【习题】

笔记目录点这里：南邮计算机专业基础

6.1 为什么要学习关系数据理论

什么是好的数据库逻辑设计

举一个反面例子：

学校开发一个学校教务的数据库，涉及的对象有：
学生的学号（Sno）、所在系（Sdept）、系主任姓名（Mname）、课程号（Cno）和成绩（Grade）。

语义：

一个系有若干学生，但一个学生只属于一个系；
一个系只有一名主任；
一个学生可以选修多门课程，每门课程有若干学生选修；
每个学生所学的每门课程都有一个成绩。

设计了一个关系模式：STUDENT（Sno, Sdept, Mname, Cno, Grade）

这个关系模式存在很多问题：

数据冗余度太大，浪费存储空间
如：系主任的姓名重复出现，重复次数与该系所有学生的所有课程成绩出现次数相同。
更新异常（Update Anomalies）
数据冗余，更新数据时，维护数据完整性代价大；
如果某系更换系主任，系统必须修改与该系学生有关的每一个元组。
插入异常（Insertion Anomalies），该插入的数据插不进去
如果新成立一个软件工程系，还没有招生，我们就无法把这个系及其系主任的信息存入数据库。
删除异常（Deletion Anomalies），不该删除的数据也删去了
如果某个系的学生全部毕业了，我们在删除该系学生信息的同时，把这个系及其系主任的信息也丢掉了。

很明显这不是一个好的关系模式。
问题的原因：由于模式中的某些数据依赖引起的。
解决方法：把这个单一模式分成3个关系模式。

S ( Sno，Sdept ) ;
Sno → Sdept
SC ( Sno，Cno，Grade ) ;
( Sno，Cno ) → Grade
DEPT ( Sdept，Mname ) ;
Sdept → Mname

这3个模式不会发生插入异常、删除异常毛病；数据冗余得到控制。

再把观察、经验上升为理论：用规范化理论改造关系模式，消除其中不合适的数据依赖。

什么是数据依赖

数据依赖是完整性约束的一种表现形式。
数据依赖是通过一个关系中属性间值的相等与否体现出来的数据间的相互关系。

例如：存在关系 STUDENT ( Sno ,Sdept, Mname,Cno,Grade )

该关系模式的属性集合记为U：

U ＝{ Sno, Sdept, Mname, Cno, Grade }

数学中的函数 y = f(x)，自变量 x 确定之后，相应的函数值 y 也就唯一地确定了。
Sdept = f(Sno)，Sno 函数确定 Sdept，记为 Sno → Sdept；
Mname = f(Sdept)，Sdept 函数确定 Mname，记为 Sdept → Mname；
Grade = f((Sno, Cno)) , (Sno, Cno) 函数确定 Grade，记为 (Sno, Cno) → Grade；

属性组U上的函数依赖集合，记为F：

F ＝{ Sno → Sdept, Sdept → Mname, (Sno, Cno) → Grade }

用一个图表示数据依赖：

数据依赖的主要类型

函数依赖(Functional Dependency，简记为FD)
多值依赖(Multivalued Dependency，简记为MVD)
连接依赖
… …

数据依赖对关系模式的影响

不合适的数据依赖，造成插入异常、删除异常、更新异常和数据冗余问题

关系模式的简化表示

关系模式的形式化定义：R ( U, D, DOM, F )

R：关系名，是符号化的元组语义
U：该关系的属性集合
D：属性组U中属性所来自的域
DOM：属性向域的映象集合
F：属性间数据的依赖关系集合

关系模式的简化表示：R<U, F>
将关系模式简化为一个三元组，影响数据库模式设计的主要是 U 和 F。
当且仅当 U 上的一个关系 r 满足 F 时，r 称为关系模式 R(U, F) 的一个关系。

例如：关系模式 STUDENT<U, F>

属性集合 U = { Sno, Sdept, Mname, Cno, Grade }
依赖关系 F =｛ Sno → Sdept, Sdept → Mname, (Sno, Cno) → Grade｝
STUDENT ( Sno, Sdept, Mname, Cno, Grade,
Sno → Sdept, Sdept → Mname, (Sno, Cno) → Grade )
该关系模式 STUDENT<U,F> 存在诸多问题。

如何解决关系模式中存在的问题？
规范化理论 — 找出关系模式中不合适的数据依赖，消除它们，可以在不同程度上解决插入异常、删除异常、更新异常和数据冗余问题。

6.2 规范化 — 关系的规范化理论

6.2.1 函数依赖

1.函数依赖

定义：
设 R(U) 是一个属性集 U 上的关系模式，X 和 Y 是 U 的子集。若对于 R(U) 的任意一个可能的关系 r，r 中不可能存在两个元组在 X 上的属性值相等，而在 Y 上的属性值不等则称 “X函数确定Y” 或 “Y函数依赖于X” ，记作X → Y。X 称为这个函数依赖的决定属性组，也称为决定因素(Determinant)。

反例：

问：由下面的关系表, 能否得出 Sname → Sno ?

答：只由关系表不能得出依赖关系。函数依赖不是指关系模式R的某个或某些关系实例r满足的约束条件，而是指R的所有关系实例r均要满足的约束条件。

如何确定函数依赖?
函数依赖是语义范畴的概念。只能根据数据的语义来确定函数依赖。

如Sname →Sno函数依赖只有在“学生不允许有重名”的条件下成立。

数据库设计者可以对现实世界作强制的规定。

例如设计者可以强行规定不允许学生有重名，因而使函数依赖
Sname → Sno，Sname → Ssex， Sname → Sage，Sname → Sdept 成立。

函数依赖是指关系模式R在任何时刻的关系实例均要满足的约束条件。

不是指某个或某些关系实例r满足的约束条件，而是指R的所有关系实例r均要满足的约束条件。

2.平凡函数依赖与非平凡函数依赖

定义：

示例：

对于任一关系模式，平凡函数依赖都是必然成立的，它不反映新的语义，因此若不特别声明， 我们总是讨论非平凡函数依赖。

3.完全函数依赖与部分函数依赖

定义：

示例：

4.传递函数依赖

定义：

示例：

6.2.2 码

候选码、超码

候选码、超码定义：

候选码、超码示例：

主码

主属性、非主属性

主属性、非主属性定义：

主属性、非主属性示例：

全码

外码

外码定义：

外码示例：

6.2.3 范式

范式是符合某一种级别的关系模式的集合。
关系数据库中的关系必须满足一定的要求。满足不同程度要求的为不同范式。

范式的种类：

第一范式(1NF)
第二范式(2NF)
第三范式(3NF)
BC范式(BCNF，Boyce和Codd共同提出的范式）
第四范式(4NF)
第五范式(5NF)

各种范式之间存在联系：

第一范式：
1NF的定义：如果一个关系模式R的所有属性都是不可分的基本数据项，则R∈1NF。

第一范式是对关系模式的最起码的要求。不满足第一范式的数据库模式不能称为关系数据模式。（不能表中有表）

6.2.4 第二范式（2NF）

只满足第一范式的关系模式并不一定是一个好的关系模式。

2NF定义：

2NF示例：

一个关系模式R不属于2NF，就会产生问题。

原因： SLC(Sno, Sdept, Sloc, Cno, Grade) 中
Sdept、 Sloc 部分函数依赖于码。SLC的码为(Sno, Cno)

2NF的问题

6.2.5 第三范式（3NF）

3NF的定义：

3NF示例：

3NF的性质：

3NF的问题

6.2.6 BC范式（BCNF）

BC范式定义：

BC范式示例：

BC范式的性质：

6.2.9 规范化小结

6.3 数据依赖的公理系统

Armstrong公理系统：

导出规则：

函数依赖闭包

闭包 F⁺ 定义：

X关于函数依赖集F的闭包X_F⁺定义：

求属性集X 关于F的闭包X_F⁺

算法：

示例：

Armstrong公理系统的有效性与完备性：

函数依赖集等价的概念

函数依赖集等价定义：

最小依赖集

最小依赖集定义：

最小依赖集例题：

求出了A⁺，发现 B 是冗余的。

求出 B⁺，B 不是冗余的。

这边一眼就能看出来了，所谓求XX的闭包不过是种说法罢了，千万不要被思维定式。

F 的最小依赖集 F_m 不一定是唯一的。

6.4 模式的分解

6.4.1 模式分解的3个定义

模式分解示例

6.4.2 分解的无损连接性和保持函数依赖性

1.具有无损连接性的模式分解

定义：

算法：

例题：
这题看不懂看这个：数据库系统（哈尔滨工业大学）P167 16.2-无损连接分解及其检验算法

特殊情况：

2.保持函数依赖的模式分解

定义：

示例：

3.分解的无损连接性和保持函数依赖性

例题：

6.4.3 模式分解的算法

6.5 小结

【习题】

（1）

（2）

（3）

（4）

（5）

（6）

（7）

（8）

（7）

【数据库系统设计】关系数据理论（函数依赖、码、范式、模式分解）相关推荐

数据库原理与应用（SQL）——3、关系数据理论(函数依赖、闭包、函数依赖集的最小集、规范化---范式 )
加油! 不要停止奔跑, 不要回顾来路, 来路无可眷顾, 值得期待的只有远方. 关系数据理论是关系数据库的理论基础, 为数据库设计提供了判别标准, 是设计关系数据库的指南. 数据存储异常(因为存在数据 ...
『数据库』朴实无华且枯燥的数据库文章--关系数据理论
『数据库』朴实无华且枯燥的数据库教程–入门必看!(不收藏,真的吃亏了) 文章目录问题的提出规范化数据依赖的公理系统模式的分解小结问题的提出一.概念回顾关系:描述实体.属性.实体间的联 ...
数据库复试--关系数据理论（主观题）
第五章关系数据理论 1. 在关系模式R(D,E,G)中,存在函数依赖关系{E→D,(D,G)→E},则候选码是__________,关系模式R(D,E,G)属于____________. 正确答案: ...
数据库复习——关系数据理论中的几个重要概念（闭包，逻辑蕴含，覆盖...）
前言关系数据理论中几个比较抽象的概念正文一.函数依赖定义设R(U)是属性集合U={A1,A2,-,An}上的一个关系模式,X, Y是U上的两个子集,若对R(U)的任意一个可能的关系r, r中 ...
【数据库】关系数据理论习题及解析
一.选择题 1. 为了设计出性能较优的关系模式,必须进行规范化,规范化主要的理论依据是( A) . A. 关系规范化理论 B. 关系代数理论 C．数理逻辑 D. 关系运算理论 2. 规范化理论是关系数 ...
关系数据理论中的范式
标准化表示从你的数据存储中移去数据冗余(redundancy)的过程.如果数据库设计达到了完全的标准化,则把所有的表通过关键字连接在一起时,不会出现任何数据的复本(repetition).标准化的优点 ...
数据库原理关系数据理论-为什么要学关系数据库理论
数据库逻辑设计关系模式存在的问题好的关系模式什么是数据依赖关系模式的简化表示
关系型数据库第四章笔记---关系数据理论
文章目录关系模式设计中的问题关系规范化数据依赖函数依赖函数依赖的定义定义满足依赖的关系模式上成立的依赖平凡函数依赖与非平凡函数依赖完全函数依赖与部分函数依赖传递函数依赖与直接函数 ...
第6章关系数据理论—范式的介绍
第6章关系数据理论-范式的介绍本文全部内容来自数据库系统概论(第5版)-王珊.萨师煊著部分函数依赖图,出于自己的理解,如有错误,请大家评论指正! 范式:关系数据库中需要满足的一定要求的规范形式. ...

【数据库系统设计】关系数据理论（函数依赖、码、范式、模式分解）

关系数据理论

6.1 为什么要学习关系数据理论

什么是好的数据库逻辑设计

什么是数据依赖

关系模式的简化表示

6.2 规范化 — 关系的规范化理论

6.2.1 函数依赖

1.函数依赖

2.平凡函数依赖与非平凡函数依赖

3.完全函数依赖与部分函数依赖

4.传递函数依赖

6.2.2 码

候选码、超码

主码

主属性、非主属性

全码

外码

6.2.3 范式

6.2.4 第二范式（2NF）

2NF的问题

6.2.5 第三范式（3NF）

3NF的问题

6.2.6 BC范式（BCNF）

6.2.9 规范化小结

6.3 数据依赖的公理系统

函数依赖闭包

求属性集X 关于F的闭包XF+

函数依赖集等价的概念

最小依赖集

6.4 模式的分解

6.4.1 模式分解的3个定义

模式分解示例

6.4.2 分解的无损连接性和保持函数依赖性

1.具有无损连接性的模式分解

2.保持函数依赖的模式分解

3.分解的无损连接性和保持函数依赖性

6.4.3 模式分解的算法

6.5 小结

【习题】

【数据库系统设计】关系数据理论（函数依赖、码、范式、模式分解）相关推荐

最新文章

热门文章

求属性集X 关于F的闭包X_F⁺