数据库复习 - PART2 - 建模设计与范式
数据库复习 - PART2 - 建模设计与范式
- 数据库复习 - PART2 - 建模设计与范式
- 4. 数据建模
- 4.1 概述
- 4.2 E-R模型
- 4.2.1 基本组成
- 4.2.2 联系专题
- 4.2.3 绘制流程
- 4.3 Chen方法
- 4.3.1 基本组成
- 4.3.2 联系的绘制方法
- 4.3.3 联系的绘制方法（2）
- 4.3.4 Chen方法举例
- 4.4 Crow's foot方法
- 4.4.1 基本构成（类似UML类图）
- 4.4.2 联系基数表示
- 5. 建模工程方法及案例分析
- 5.1 两种实体
- 5.2 数据库设计过程
- 5.2.1 概述
- 5.2.2 需求分析
- 5.2.3 CDM设计（概念模型，Concept Data Model）
- 5.2.4 LDM设计（逻辑模型，Logic Data Model）
- 5.2.5 PDM设计（物理模型，Physical Data Model）
- 6. 函数依赖及其公理定理
- 6.1 函数依赖
- 6.2 部分或完全函数依赖
- 6.3 传递函数依赖
- 6.4 候选键
- 6.5 逻辑蕴含
- 6.6 闭包
- 6.7 关于函数依赖的公理和定理
- 6.8 属性集闭包
- 6.9 覆盖
- 6.10 最小覆盖
- 6.11 多值依赖
- 6.12 多值依赖公理及定理
- 7. 范式
- 7.1 第一范式（原子性）
- 7.2 第二范式（非主属性的完全函数依赖）
- 7.3 第三范式（候选键无传递依赖）
- 7.3+ Boyce-Codd范式（关系中的依赖必含候选键[超键]）
- 7.4 第四范式（X必为超键）
- 7.5 第五范式
- 7.5.1 模式分解
- 7.5.2 无损连接分解
- 7.5.3 保持依赖分解
- 7.5.4 无损连接分解为BCNF算法
- 7.5.5 保持依赖分解为3NF算法
- 7.5.6 既保持依赖又无损连接的分解（3NF）
- 7.5.7 无损连接分解为4NF（存疑）
- 7.5.8 连接依赖
- 7.5.9 第五范式（无损链接分解各模式必含候选键）
承接上篇
文中图片参考自哈工大（深圳）数据库系统课程
冲冲冲！
数据库复习 - PART2 - 建模设计与范式
4. 数据建模
4.1 概述
- 数据模型：表达计算机世界的模型称为数据模型；
- 概念模型：表达信息世界的模型称为概念数据模型
4.2 E-R模型
4.2.1 基本组成
实体与实例（类与对象的概念）
属性
- 单一属性与复合属性：如家庭住址：省份，详细住址；
- 单值属性与多值属性：电话号码有多个；
- 可空值属性与非空值属性
- 导出属性：可计算得到的
联系
指一个实体的实例和其他实体实例之间所可能发生的联系
一元联系
参与联系的实体仅有一个，例如：评论与评论之间的关系（一个评论可以评论另一个评论）；
为了区分同一实体的不同实例参与一个联系时，为区别各实例参与联系的方式， 需要显式指明其角色(role)
例如：
评论 被评论的评论 阴阳怪气，xxx 哈哈，我xx xx给你吗一交 祖安是吧 二元联系
参与联系的实体有两个，例如：读者与图书的借阅联系；
多元联系
参与联系的实体有多个，例如：游戏、游戏开发者与游戏平台的联系
游戏 游戏开发者 游戏平台 Need For Speed EA Origin Need For Speed EA Steam Heartstone Blizzard Blizzard
关键字标记
4.2.2 联系专题
以二元联系为例
联系的种类
一对一联系
实体A的一个实例只能和实体B的一个实例发生联系，反之亦然；
一个学生只能有一张床，一张床只能属于一个学生；
一对多联系
实体A的实例能和实体B的多个实例发生联系，反之，实体B 的 实例只能和实体A的一个实例发生联系；
一个游戏厂商可能有多部游戏，但是每部游戏只能属于一家厂商；
多对多联系
实体A的实例可以和实体B的多个实例发生联系，反之，实体B的实例也可以和实体A的多个实例发生联系；
一个玩家可以拥有多部游戏，每部游戏也可以被多个玩家持有；
联系的基数
基数指：实体实例之间的联系的数量，即一个实体的实例通过一个联系能够与另一实体中相关联的实例的数目；
常见的映射基数为：一对一、一对多以及多对多；
完全参与联系： 即该端实例至少有一个可参与到联系中，最小基数为1；
部分参与联系： 即该端可以不参与联系，最小基数为0；
基数示例
Exp：书架与图书
一个书架可以存放0本或多本图书，而一本图书只能存放在一个书架上；
书架参与存放图书联系的基数为（0…m）；图书参与存放图书联系的基数为（1…1）；
4.2.3 绘制流程
- Step 1：寻找实体；
- Step 2：寻找属性；
- Step 3：确定实体主键；
- Step 4：分析实体间的联系；
- Step 5：检查是否满足需求；
4.3 Chen方法
4.3.1 基本组成
- 实体：矩形框
- 属性：椭圆框
- 多值属性：双线椭圆
- 导出属性：虚线椭圆
- 关键字：下划线
- 联系：菱形框；
- 复合关键字：标有相同的数字
- 多组关键字：标有不同的数字
4.3.2 联系的绘制方法
- 1：1联系：箭头直线，由联系指向实体；
- 1：m联系：指向1端为箭头直线，指向多端为无箭头直线；
- m：n联系：无箭头直线；
- 完全参与联系：双直线；
- 部分参与联系：单直线；
4.3.3 联系的绘制方法（2）
- 1端实体：直线标1；
- 多段实体：直线标m或n，完全/部分参与联系也可以标注（最小基数…最大基数）进行区分，最小基数0 的为部分参与联系，最小基数1的为完全参与联系；
- 直线旁还可标：1…1，0…1，1…m，0…m；
4.3.4 Chen方法举例
图书管理的E-R图
带有基数映射
下图表明：
一个读者（读者的一个实例）可以不借阅图书或者借阅多本图书，于是读者参与到关系借阅中的联系基数为0…m；
一本图书可以被一个读者借阅也可以不被借阅，于是图书参与到关系借阅中的联系基数为0…1；
同理：一本图书必须被放置在一个书架上，于是图书参与到关系保存中的联系基数为1…1；
一个书架上可以不保存图书或者保存多本图书，于是书架参与到关系保存中的联系基数为0…m；
无基数映射
下图表明：
- 一个读者可借阅多本书，一本书只能被一个读者借阅，因此读者与图书是一对多关系；
- 一个书架可存放多本书，一本书只能存放在一个书架上，因此书架与图书是一对多关系；
4.4 Crow’s foot方法
4.4.1 基本构成（类似UML类图）
- 实体：矩形框，实体的名称写在横线上面；
- 属性：实体框横线的下面；
- 关键字（主键）：属性下加下划线；
- 联系：菱形框表示（亦可省去，直接以联系名代替）；
4.4.2 联系基数表示
完全参与和部分参与联系表达
完全参与
下图说明：
一个教授至少教一节课，一节课只能由一个教授教；
部分参与
下图说明：
一个教授要么不用教授，要么可以教授多节课，而一节课只能由一个教授教；
一元联系表达
一个评论可以评论也可以不评论另一个评论，而一个评论同时也可不被或被多个评论评论；
5. 建模工程方法及案例分析
5.1 两种实体
一个实体表示一个现实和抽象事物的集合，这些事物必须具有相同的属性和特征。这个集合的一个元素就是该实体的一个实例；
独立实体 - 强实体
具有主键；
从属实体 - 弱实体
没有足够的属性构成主键；
联系
标定联系
子实体的实例都是由它与父实体的联系而确定的。父实体的主关键字是子实体主关键字的一部分（构成主键）；
例如：
课程 （课程号，课程名） - 父实体
选课（学生号，课程号） - 子实体
非标定联系
子实体的实例能够被唯一标识，而无需依赖与其实体的联系。父实体的主关键字不是子实体的主关键字（构成外键）；
例如：
课程 （课程号，课程名） - 父实体
选课（选课ID，学生号，课程号） - 子实体
分类联系
一个实体是由一个一般实体实例及多个分类实体实例构成的；
例如：
一般实体：人类；（类）分类实体：学生、工人；（对象）
分类实体具有与一般实体相同的主关键字
思考Electronic Music
BaseItem（id）
^
|
EMCard（id），EMOptions（id）
分类联系引申出具体化和泛化两种关系（IS-A）：
- 具体化（子类）
- 泛化（抽象父类）
非确定联系（即实体之间的多对多的联系）
5.2 数据库设计过程
5.2.1 概述
共四个流程：
- 需求分析
- 概念数据库设计
- 逻辑数据库设计
- 物理数据库设计
5.2.2 需求分析
目标：理解企业、理解企业业务过程与数据处理流程、 需求分析理解数据处理的性能需求；
产出：需求分析报告
略
5.2.3 CDM设计（概念模型，Concept Data Model）
目标：进一步深入理解企业，对信息源进行抽象，发现信息(属性)之间的内在本质联系，这些本质联系可能隐藏于需求分析得到的信息源中，绘制E-R图。
产出：概念数据库设计报告
- 本部分主要明确4个问问题：
- 实体的发现、划分和定义；
- 属性的发现、分析和定义；
- 关键字的定义；
- 联系的发现、分析和定义；
- 概念视图以及外部视图的定义；
- 设计的两种思路：
- 先全局后局部；
- 先局部后全局；
- 可能产生的冲突：
- 属性冲突：单位取英尺和米；
- 结构冲突：
- 同一对象在不同应用中的抽象不同；
- 同一实体在不同E-R图中属性不同；
- 实体之间的联系在不同E-R图中呈现不同类型；
- 命名冲突：命名异义，异名同义；
5.2.4 LDM设计（逻辑模型，Logic Data Model）
目标：用指定DBMS要求的模式描述方法，给出概念 数据库的逻辑模式描述；
产出：逻辑数据库设计报告
将E-R图转化为关系模式
实体转为关系；
属性转为关系属性；
注意多值属性的转化，将多值属性与所在实体关键字一起组成一个新的关系；
关键字转为关键字；
联系的转化：
一对一联系：若双方均部分参与，则将联系定义为一个新关系；若联系一方全部参与，则将其关键字作为另一方的属性，无需联系集；
例如：宿舍床与同学
一对多联系：将1方参与实体的关键字，作为多方参与实体对应关系的属性；
多对多联系：将联系定义为新的关系，属性为参与双方实体的关键字；
弱实体关系转化：
本身属性 + 所依赖强实体的关键字，如下图CDM中的Watch实体；
虽然该实体没有主键，但经过转换后，变为了（注意，这里的id是我自己加上的，为了消除外键不能是主键的警告）：
可以看到，Watch中增加了User和Video关系的主键；
多元联系转换：
- 1型：把各个实体主键作为属性；
- 2型：新增一个ID作为区分属性；
- 更多：可将多元联系转换为多个二元联系处理；
数据库的不正确设计可能带来的影响
冗余
非受控冗余：就像硬编码一样；
受控冗余：外键
插入异常
删除异常
游戏名 类别 NFS 竞速 Honey Select 动作 Diablo II RPG 假设游戏类别仅靠上表维护，那么，如果删除所有动作类游戏，那么就丢失了“动作”类别；
5.2.5 PDM设计（物理模型，Physical Data Model）
目标：结合指定DBMS物理数据库管理方法，给出概念数据库的物理模式描述；
产出：物理数据库设计报告
- DBMS选型；
- 确定数据库的存储结构，文件类型：堆文件、散列文件或者B-Tree等；
- 利用触发器实现完整性约束
- 访问方式（索引访问，直接访问等）
6. 函数依赖及其公理定理
6.1 函数依赖
定义：
设R（U）是属性集合U={A1，A2……An}上的一个关系模式，X，Y是U上的两个子集，若对R（U）的任意一个可能的关系r，r中不可能有两个元组满足在X中的属性值相同而在Y中的属性值不同，则称“X函数决定Y”或“Y函数依赖于X”，记作 X → Y；
即
给定一个关系，给定两个属性组X和Y，且X中对应值相同的元组其Y中对应值必定相同，那么Y就函数依赖于X；
函数依赖性质：
- 若X → Y，但Y不包含于X，那么称X → Y为非平凡的函数依赖；
- 若X → Y，则任意两个元组，若X上值相等，则Y上值必然相等,则称X为决定因素；
- 若X → Y，Y → X，则记作 X ←→ Y；
- 若Y不函数依赖于X，则记作 X （！→ ）Y；
- X → Y，有基于模式R的，则要求对任意关系r均成立；有基于具体关系r的，则要求对某一关系r成立；
- 若对某一关系r的某属性集X，r中无X上相等的两个元组存在，则 X → Y 一定成立；
举例：
GAME（游戏编号，游戏名，厂家ID，厂家名）
- 游戏编号 → {游戏名、厂家ID、厂家名}；
- 厂家ID → 厂家名；
6.2 部分或完全函数依赖
定义
在R（U）中，若 X → Y，且对X的任何真子集X‘，都有Y不函数依赖于X’，则称Y完全函数依赖于X，记为 X （→ f） Y，否则，称Y部分函数依赖于X，记作X （→ p） Y；
即
去掉X中的任意个元素，Y都不函数依赖于X，那么完全函数依赖。完全函数依赖保证X中无多余元素；
X中存在多余元素，则Y部分函数依赖于X；
举例：
GAME（游戏编号，鉴赏家编号，鉴赏家昵称，评论）
- {游戏编号、鉴赏家编号}（ → f） GAME
- {游戏编号、鉴赏家编号}（ → p） 鉴赏家昵称（参见第3条）
- 鉴赏家编号 → 鉴赏家昵称
6.3 传递函数依赖
定义
在R（U）中，若X → Y，Y → Z，且X → Y、Y → Z为非平凡依赖，Z不包含于X，Y （！→）X，则称函数 Z传递函数依赖于X；
示例：
商店（商店，商品，商品经营部，经营部经理）
- {商店，商品} → {商店，商品经营部}；
- {商店，商品经营部} → 经营部经理；
6.4 候选键
定义
设K为R（U）中的属性或属性组，若 K （→ f） U，则称K为R（U）上的候选键；若此时S包含K，则称S为R的超键（Super Key）；
6.5 逻辑蕴含
定义
可由函数依赖集合推导而出
6.6 闭包
定义
被F逻辑蕴涵的所有函数依赖集合称为F的闭包（Closure），记作 F+；
6.7 关于函数依赖的公理和定理
阿姆斯特朗定律
设R（U）是属性集U={A1,A2,…,An}上的一个关系模式，F为R（U）的一组函数依赖，记为R（U, F）, 则有如下规则成立
- **自反律：**若Y包含于X包含于U，则X→Y被F逻辑蕴含；（X→Y为平凡依赖）
- **增广率：**若X → Y ∈ F，且Z包含于U，则 XZ → YZ被F逻辑蕴含；（**或：**若X → Y ∈ F，且V包含于W，则 XW → YV被F逻辑蕴含）
- **传递率：**若X → Y ∈ F，且Y → Z，则X → Z 被F逻辑蕴含；
阿姆斯特朗定律推论
- **合并律：**若 X → Y 且 X → Z，则X → YZ；
- **伪传递律：**若X→Ｙ且WY→Z，则XW→Z；
- **分解律：**若X→Y，且Z包含于Y，则X→Z；
6.8 属性集闭包
定义
对R（U, F）, X包含于U, U = { A1,A2,…,An}, 令：
X（+F）= { Ai | 用阿姆斯特朗定律可从F导出 X → Ai }，称X（+F）为X关于F的属性集闭包；
重要定理
X → Y，当且仅当 Y 包含于 X（+F）
简单理解：
X → Y，说明Y的每个属性可由X推出，那么Y的每个属性一定在X的闭包集里；
反之，
由于Y包含于X的闭包集，所以X能够推出Y的每一个属性，所以X → Y；
** 属性集闭包求解步骤
计算属性集X关于一组函数依赖F的属性闭包；
简单来讲，就是不断迭代，寻找每一个V→W∈F，然后利用手里的X推出新的属性，直到推不出为止
X ( i ) = X , i = 0 X^{(i)}=X,i=0 X(i)=X,i=0
B = { A ∣ ( ∃ V ) ( ∃ W ) V → W ∈ F ∧ X ( i ) ⊆ V ∧ A ⊆ W } B = \{ A | (\exists V)(\exists W)V\rightarrow W \in F \wedge X^{(i)} \subseteq V\wedge A \subseteq W \} B={A∣(∃V)(∃W)V→W∈F∧X(i)⊆V∧A⊆W}
X ( i + 1 ) = X ( i ) ∪ B X^{(i + 1)} = X^{(i)} \cup B X(i+1)=X(i)∪B
i f : X ( x + 1 ) ≠ X ( i ) , t h e n : i = i + 1 if : X^{(x+1)} \neq X^{(i)},then: i=i+1 if:X(x+1)=X(i),then:i=i+1
X F + = X ( i ) X^+_F = X^{(i)} XF+=X(i)
6.9 覆盖
定义
对R（U）上的两个函数依赖集合F、G，如果F+ = G+，则称F和G是等价的，也称F覆盖G或者G覆盖F。
6.10 最小覆盖
引理
每个函数依赖集F可被一个其右端至多有一个属性的函数依赖之集G覆盖
G = {X→A|X→Y ∈ F 且 A ∈ Y}
例如：
F = { X → {Y, Z} }
则
G = { X → Y，X → Z }
此时F+ = {X → {Y, Z}，X → Y，X → Z } = G+
最小覆盖
若F满足以下条件，则称F为最小覆盖（minimal Cover）或最小依赖集：
F中每个函数依赖的右部是单个属性；
单属性
对任何X→A∈F, 有F - { X→A }不等价于F；
去掉后就不等价
对任何X→A∈F, Z包含于X，（F - { X→A }）∪ {Z → A}不等价于F；
更换后不等价
6.11 多值依赖
定义：
对R（U），设X，Y包含于U，若对于R（U）的任一关系r，若元组t∈r，s∈r，t[X] = s[X]，则必有u∈r，v∈r，使得：
- u[X] = v[X] = t[X] = s[X]
- u[Y] = t[Y] 且 u[U-X-Y] = s[U-X-Y]
- v[Y] = s[Y] 且 v[U-X-Y] = t[U-X-Y]
均成立，则称Y多值依赖于X，或X多值决定Y，记作X→→Y
简而言之
对于关系r而言，若有两个元组X相同，Y不同，但将Y交换后，这两个元组仍然存在于关系r之中，这就意味着X→→Y；
多值依赖性质
- 直观地，对于X给定值，Y有一组值与之对应（0或n个）且这组Y值不以任何方式与U-X-Y中属性值相联系，则有X→→Y；
- 若交换t, s 的Y值而得到的新元组仍在r中，则X→→Y；
- X, Y 可相交，u,v可以与t,s相同；
- 函数依赖是多值依赖的特例；（Y值相同）
- 令Z=U-X-Y,有X→→Z, 若Z=空, 则必有X→→Y；
多值依赖示例
R = {课程名C，教师名T，上课时间H，教室R，学生名S，成绩G}，则有：
C→→HR，T→→HR（时间、教室，与上课的人、上课的教师、学生等可视为无关）；
即：同一门课或同一个教师对同一批学生可以在不同教室，不同时间上课；
但，不存在C→→H和C→→R（时间与教室相关）
6.12 多值依赖公理及定理
阿姆斯特朗定律
多值依赖互补律： 若X→→Y，则X→→Z，其中Z = U - X - Y；
多值依赖增广律： 若X→→Y且V包含于W，则WX→→VY；
多值依赖传递律： 若X→→Y，Y→→Z，则X →→ Z - Y；
考虑：
若C→→HR，HR→→H，则H并非多值依赖于C；
而C→→（R-HR），C→→空集
若X→Y，则X→→Y；
若X→→Y，Z包含于Y，且对于某个与Y不相交的W，W→Z，有X→Z；
阿姆斯特朗定律推论
多值依赖合并律： 若X→→Y且X→→Z，则X→→YZ；
多值依赖伪传递律： 若X→→Y且WY→→Z，则X→→Z-WY
混合伪传递律： 若X→→Y，XY→Z，则X→Z-Y
多值依赖分解律： 若X→→Y，X→→Z则X→→Y-Z，X→→Z-Y，X→→Y∩Z
7. 范式
7.1 第一范式（原子性）
定义：
1NF，若关系模式R（U）中关系的每个分量都不可分，则称R（U）属于第一范式，记作：R（U）∈ 1NF
示例
STAR(name, addr(street, city))STAR不属于1NF，因为字段
addr包含了两个属性，非原子；解决方案：
STAR(name,addr)STAR(name,street,city)
7.2 第二范式（非主属性的完全函数依赖）
定义：
若R（U）∈ 1NF，且U中的每一非主属性完全函数依赖于候选键，则称R（U）∈2NF
示例
R（S#，Sname，Sclass，CName，Grade）
函数依赖：
S# → {Sname，Sclass}
{S#，CName} → Grade
{S#，CName} → R => S#，CName是主属性
但
{S#，CName}（ → p）Sname，非主属性Sname部分函数依赖于候选键，因此，R不属于2NF；
对其进行分解即可：
R1（S#，Sname，Sclass）与R2（S#，CName，Grade）
7.3 第三范式（候选键无传递依赖）
定义：
若R（U，F）∈ 2NF，且R中不存在这样的情况：候选键X，属性组Y包含于U和非主属性A，且A不属于X，A不属于Y，Y不包含于X，Y（！→）X，使得X → Y，Y → A成立，则称R（U）∈3NF；
示例：
学生（学号、系号、系主任）
函数依赖：
学号 → 系号，系号 → 系主任
学号 （→ f）学生，即学号为候选键；
于是非主属性系主任与候选键学号产生传递函数依赖，因此，不属于3NF；
修改为：
R1（学号，系号），R2（系号，系主任）
3NF分解方法：
将每一个函数依赖单独组成一个关系
7.3+ Boyce-Codd范式（关系中的依赖必含候选键[超键]）
定义：
若R（U，F）∈1NF，若对于任何 X → Y ∈ F（或X → A ∈ F），当Y不包含于X（或A不属于X）时，X必含有候选键（即，X为超键），则称R（U）∈ BCNF；
示例：
选课（学号，课程号，教师编号）
函数依赖：
{学号，课程号} → 教师编号，教师编号 → 课程号；
其中，教师编号不为候选键，于是关系选课不属于BCNF；
修改为：
R1（学号，课程号），R2（课程号，教师编号）；
算法：
将左侧不含候选键的函数依赖单独组成一个关系, 将包含候选键的组成一关系；
7.4 第四范式（X必为超键）
定义：
设R（U）∈ 1NF，D是其上的一组依赖（函数依赖，多值依赖），对任意 X →→ Y ∈ D，若Y非空，Y不包含于X，XY不等于U，X为超键，则称R（U）∈ 4NF
7.5 第五范式
7.5.1 模式分解
定义：
关系模式R（U）的分解是指用R的一组子集p = {R1（U1），R2（U2）……Rk（Uk）}来代替它。其中U = U1∪U1∪……∪Uk
对于关系模式R的任一关系r，它向p的投影连接记为mp（r）：
mp（r） = ΠR1（r）⋈ ΠR2（r）⋈ ……⋈ ΠRk（r）mp（r）即各个子关系模式的连接；
模式分解需要关注两个问题：
- 分解的无损连接性；（连接后的关系元组多于原关系）
- 分解的保持依赖性；（原关系的所有依赖都没丢失）
引理：
设R为一关系模式，p={R1，……，Rk}是R的一个分解，r是R的任一关系，且ri = ΠRi（r），则有下述规则成立：
r 包含于 mp（r）；
意味着原关系一定包含于子关系的连接；
若s = mp（r），则ΠRi（s）= ri；
意味着子关系的连接向某个子关系投影的结果等于该子关系；
mp（mp（r））= mp（r）；
意味着子关系的连接拆分后再做连接的结果与原关系拆分后再做连接的结果相同；
7.5.2 无损连接分解
定义：
对于关系模式R（U，F），U是属性全集，F是函数依赖集合，p = {R1，……，Rk}是R的一个分解，如果对于R的任何满足函数依赖集F的关系r，**有r = mp（r），**则称p是R相对于F的一个无损连接分解；
检验算法：
输入：关系模式 R = A1A2……An，函数依赖集F，分解 p = {R1，……，Rk}
输出：p是否是无损连接分解；
方法：
构造一个k行n列表，可称为Rp表。其中第j列对应于Aj，第i行对应于Ri；若Aj∈Ri，则Rp表中第i行，第j列位置填写符号aj，否则填写bij；
根据 X → Y ∈ F，对Rp表进行修改：
给定 X → Y，寻找X属性取值相同的行，用其值重置Y属性值（a或b）；
修改后，若有一行变为全a，则p是无损连接分解，否则为有损连接分解；
重要结论：
设F是关系模式R上的一个函数依赖集合。p={R1，R2}是R的一个分解，则：当且仅当R1∩R2→R1-R2或者R1∩R2→R2-R1属于F+时，p是关于F无损连接的；
7.5.3 保持依赖分解
定义：
对于关系模式R（U，F），U是属性全集，F是函数依赖集合，p={R1，……，Rk}是R的一个分解，如果在ΠRi（F）中的所有依赖之并集（i=1，……，k），逻辑蕴含F的每个依赖，则称分解p保持依赖集F。
其中，ΠRi（F）是F在Ri上的投影，即F中的任一投影X →Y ，如果X，Y均包含于Ri，则 X → Y ∈ΠRi（F）；
注意：
- 保持依赖的分解可能不是无损连接；
- 无损链接的分解可能不是保持依赖；
例如：
R（城市，街区，邮编），F = { {城市、街区} → 邮编，邮编 → 城市}
令城市 = C，街区 = S，邮编 = Z
则：F = {CS → Z，Z → C}
给出分解：p = {R1（SZ），R2（CZ）}
无损连接吗？
R1 ∩ R2 = Z
R1 - R2 = S
R2 - R1 = C
由于Z → C => R1 ∩ R2→R2 - R1，故是无损连接；
保持依赖吗？
ΠR1（F） = { }
ΠR2（F） = { Z → C }
ΠR1（F）∪ ΠR2（F） = { Z → C }，可见， 并不逻辑蕴含CS → Z，故不保持依赖
检验算法：
令 G = ∪（i = 1 to k）ΠRi（F），只需检查G是否覆盖F即可，具体算法如下：
首先对每个 X → Y ∈ F，计算G中的X关于G的属性闭包：（若X不包含于Ri，则不需计算了，因为G = ∪（i = 1 to k）ΠRi（F），说明ΠRi（F）中不存在X，因此必然无法推出X → Y）
Z = X；
While Z 变化 DO
For i = 1 to k DO
Z = Z ∪ （（Z ∩ Ri）+ （G）∩ Ri）
为何求关于G的属性闭包？
我们想要证明的是 G 能够逻辑蕴含 X → Y；
由分解律，如果能够证明存在 Z 包含 Y，使得 X → Z能够被G逻辑蕴含即可；
而 X → Z 当且仅当 Z 包含于 X+（G），即 X 关于 G 的属性闭包；
因此，我们需要求得X关于G的属性闭包；
判断G是否逻辑蕴含X → Y：Z 包含 Y，则G逻辑蕴含X→Y；
判断p是否保持依赖：若G逻辑蕴含F，则说明p是保持依赖的分解；
7.5.4 无损连接分解为BCNF算法
- 令p = {R}
- 对每个模式 s ∈ p，若s 不属于BCNF，则s上必有X → A成立，且X不是s的超键，且A不属于X，用模式s1，s2代替s。s1 = {A，X}，s2 = {s - A}；
- 重复步骤2，直到p中关系模式达到BCNF；
为啥无损？
分解后的关系
s1 ∩ s2 = X；
s1 - s2 = A
于是：
s1 ∩ s2 → s1 - s2，故对s的分解是无损的；
故简而言之：
把含有候选键的关系放一起，把不含候选键的关系放一起；
7.5.5 保持依赖分解为3NF算法
- 把R中不出现在F中的属性去掉并单独组成一模式；
- 对F中的任一 X→ A，则以XA组成一模式；若有X→A1，X→A2……X→Am都属于F，则以XA1A2……Am组成一模式（将n个模式合并为一个模式）；
- 取p为上述模式之集合，p即为所求；
简而言之，
若要保证F中的每个依赖在p中都出现，则直接拿F中的依赖构建关系即可；
做法为：将左端相同的函数依赖组成一个关系；
7.5.6 既保持依赖又无损连接的分解（3NF）
设σ是按7.5.5算法构造的R的一个第三范式分解，X是R的候选键，则：t = σ ∪ {X}将是R的一个分解，且该分解中的所有关系模式是第三范式的，t有保持依赖和无损性；
7.5.7 无损连接分解为4NF（存疑）
- 令p = {R}；
- 对每个模式 s ∈ p，若s 不属于4NF，则s上必有X →→ Y成立，且X不是s的超键，且Y - X 非空，XY不为s，令Z = s - Y - X？，显然有X →→ Z（交换律），此时用模式s1，s2代替s。s1 = {Y，X}，s2 = {Z}；
- 重复步骤2，直到p中全部关系模式都达到4NF；
7.5.8 连接依赖
定义
设R为一关系模式，p = {R1，R2……Rn}为R的一个分解，若对R的任一关系r均有：r（n目） = ΠR1（r）⋈ ΠR2（r）⋈ ……⋈ ΠRk（r），则称R满足n目连接依赖，记为JD[R1，…… ，Rn]，或n-JD（连接依赖好像就是无损连接）
7.5.9 第五范式（无损链接分解各模式必含候选键）
当且仅当关系模式R的每个连接依赖均按其候选键进行连接运算时(均由R的候选键所隐含)，则称 R ∈ 5NF；
第五范式消除了不按候选键连接的连接依赖（R的无损连接分解中各模式必含有一个候选键）
数据库复习 - PART2 - 建模设计与范式相关推荐
- 数据库设计三大范式和ER模型
1. 数据库设计之三范式的介绍 范式: 对设计数据库提出的一些规范,目前有迹可寻的共有8种范式,一般遵守3范式即可. 第一范式(1NF): 强调的是列的原子性,即列不能够再分成其他几列.(1NF强调字 ...
- 数据库设计三大范式应用实例剖析(转载)
引言 数据库的设计范式是数据库设计所需要满足的规范,满足这些规范的数据库是简洁的.结构明晰的,同时,不会发生插入(insert).删除(delete)和更新(update)操作异常.反之则是乱七八糟, ...
- 数据库设计三大范式【转载】
数据库设计范式 什么是范式:简言之就是,数据库设计对数据的存储性能,还有开发人员对数据的操作都有莫大的关系.所以建立科学的,规范的的数据库是需要满足一些 规范的来优化数据数据存储方式.在关系型数据库中 ...
- mysql数据库设计三大范式_了解数据库设计三大范式
数据库设计范式 什么是范式:简言之就是,数据库设计对数据的存储性能,还有开发人员对数据的操作都有莫大的关系.所以建立科学的,规范的的数据库是需要满足一些 规范的来优化数据数据存储方式.在关系型数据库中 ...
- （转载）简洁、明晰！数据库设计三大范式应用实例剖析
(转载http://bbs.database.ccidnet.com/read.php?tid=325895) 简洁.明晰!数据库设计三大范式应用实例剖析 引言OL~eR{q ;iC,$vZ 0} ...
- 数据库设计三大范式应用实例剖析
引言 数据库的设计范式是数据库设计所需要满足的规范,满足这些规范的数据库是简洁的.结构明晰的,同时,不会发生插入(insert).删除(delete)和更新(update)操作异常.反之则是乱七八糟, ...
- 数据库基础 数据库设计三大范式
转载自: http://www.cnblogs.com/knowledgesea/p/3667395.html 数据库设计范式 什么是范式:简言之就是,数据库设计对数据的存储性能,还有开发人员对数据的 ...
- 数据库设计三大范式应用实例剖析（讲得比较清楚）
分享一下我老师大神的人工智能教程!零基础,通俗易懂!http://blog.csdn.net/jiangjunshow 也欢迎大家转载本篇文章.分享知识,造福人民,实现我们中华民族伟大复兴! 转贴地址 ...
- 从第一范式到第二范式所做的操作是_数据库设计三大范式
为了建立冗余较小.结构合理的数据库,设计数据库时必须遵循一定的规则.在关系型数据库中这种规则就称为范式.范式是符合某一种设计要求的总结.要想设计一个结构合理的关系型数据库,必须满足一定的范式. 在实际 ...
最新文章
- rf运行python脚本报错_python2.7+RobotFramework的UI自动化环境搭建
- 园区交换网络和路由网络综合设计，测试完工啦
- phoenix的元数据一般存在哪里_Phoenix的一些问题
- PRD的编写竟然暗含这个思路
- vba excel 取得chart保存图片_保存Excel中的图片
- 信息资源管理——总结
- html 做王者荣耀
- Qt浅谈之七：抽奖软件（可显示图片和姓名）
- gege.fans上热搜背后是明星私域流量的折射
- 7-7 词典 (15 分)
- 信念、信仰、理想、梦想
- 深信服python面试题_深信服软件测试面试经验
- Windows安装程序遇到错误：0x80240037
- 全球隔离，生出不少坏毛病
- 面试经验（互联网，研究所，国企）
- 【C语言】极坐标转换为直角坐标
- python爬取微信群聊内容_再不学Python 你就被同龄人甩开了吗？
- 十三年前雷军跟我说：中国to B向toC学习，可能能走出一条道儿来
- linux 时间戳转换/dmesg 时间转换
- 国际电商网站APP开发-国际电商网站，跨境方案