数据库复习11——关系模式与范式，数据库复习11范式
数据库复习
CH11 关系模式与范式
11.1 关系模式的设计
数据库模式（Schema）是数据库中全体数据的逻辑结构和特征的描述，关系型数据库的模式又叫关系模式，我所理解的关系模式就是数据库中表结构的定义以及多张表之间的逻辑联系
关系模式的设计就是根据一个具体的应用，把现实世界中的关系用表的形式来表示的逻辑设计过程，不规范的关系模式设计会带来以下的问题：
- 数据冗余
- 更新异常
- 插入异常
- 删除异常
举ppt中例子说明四种问题，如下表中描述了老师信息（一个老师一个地址，可以教多门课，一门课只有一名老师）：
| Tname | Addr | C#(PK) | Cname |
|---|---|---|---|
| T1 | A1 | C1 | N1 |
| T1 | A1 | C2 | N2 |
| T1 | A1 | C3 | N3 |
| T2 | A2 | C4 | N4 |
| T2 | A2 | C5 | N5 |
| T3 | A3 | C6 | N6 |
- 数据冗余：T1老师的地址A1记录了三次，冗余
- 更新异常：更新了某个元组中T1老师的地址A1，其余两个没有更新，DBMS不会检测到不一致，这是逻辑上的不一致而非数据库不一致
- 插入异常：无法插入一个还未带课的新老师，因为无C#违反主键约束
- 删除异常：T3老师不带C6这门课了，删除元组时却把T3老师的个人信息如地址等删去
解决上述问题最简单的方法是模式分解，将教师信息和课程信息独立出来，下面是一种分解方式：
R(Tname,Addr,C#(PK),Cname)
=>
R1(Tname(CK), Addr)
R2(C#(PK), Cname, Tname(FK))模式分解有一套规范化的分解标准，称为范式（本章重点，见后续小节）
11.2 函数依赖
函数依赖（Functional Dependency，FD）是指一个关系模式中一个属性集和另一个属性集间的多对一关系，如选课关系SC(S#, C#, Score)，给定(S#,C#)只有一个Score对应，不同(S#,C#)对应的Score值允许相等
（1）形式化定义
X、Y是关系模式R(U)属性集U的子集，R(U)的实例r中的两个元组t1、t2，若t1[X]==t2[X]可以导出t1[Y]==t2[Y]，则称Y函数依赖于X，记作X→Y
同一个关系模式可以有不同的FD，FD和应用相关；FD是对现实世界的断言，检测FD正确性只能通过考察属性的含义
形式化定义关系模式为R(U, D, dom, F)：
- R为关系模式名
- U是一个属性集
- D是U中属性的值所来自的域
- Dom是属性向域的映射集合
- F是属性间的依赖关系
关系模式设计就是寻求一个最小FD集T，一旦实现T则可以实现所有FD
（2）函数依赖的平凡性
若X→Y且Y是X的子集，则X→Y是平凡FD（子集必然依赖），否则是称FD不平凡；平凡FD无实际意义，可以通过消除平凡FD来缩小FD集
（3）函数依赖闭包
函数依赖有以下推理规则，称为Armstrong公理:
- 自反律：若B是A的子集，则A→B
- 增广律：若A→B，则AC→BC
- 传递律：若A→B且B→C，则A→C
- 自含律：A→A
- 分解律：若A→BC，则A→B且A→C
- 合并律：若A→B且A→C，则A→BC
- 复合律：若A→B且C→D，则AC→BD
函数依赖集F逻辑蕴含的函数依赖的全体构成的集合称为函数依赖F的闭包，记做F+，通过一系列推理规则可以求得F的闭包并判断某一函数依赖X→Y是否能够由F推出（即判断X→Y是否属于F+）
（4）属性闭包
判断X→Y是否能够由F推出就去构造F+计算量比较大，其实只需构造**属性X的闭包**X+即可，X+是所有能够用A推出的属性集合（即函数依赖于A的属性集合）
（5）最小函数依赖集
最小函数依赖集F必须满足以下性质：
- F的每个FD的右边只有一个属性
- F不可约，即F中的每个X→Y,F-{X→Y}与F不等价
- F的每个FD的左部不可约，即删除任意FD左边的任何一个属性后的F’不等价于F
求某个函数依赖集的最小函数依赖集的步骤如下：
11.3 关系模式的分解
关系模式R(U)的一个分解p={Ri(Ui)}满足U=∪{Ui}，模式分解必须是无损连接并且需要保持函数依赖
（1）无损连接
无损连接是指：某关系模式的事例r按照关系模式分解成多个关系r1,…,rk，若r1,…,rk的自然连接（Join操作）等于r，则称该模式分解是无损的
（2）测试无损连接
Chase方法能够检测完全的无损连接，设有n个属性的模式R分解为k个模式Ri，有如下Chase过程：
当模式分解是简单的二元分解时（即p={R1,R2}），p是无损连接的分解当且仅当下面FD之一成立：
- R1和R2两模式属性的交集 → R1与R2两模式属性的差集
- R1和R2两模式属性的交集 → R2与R1两模式属性的差集
（3）保持函数依赖
保持函数依赖是指关系模式R的FD集F在分解后仍在数据库模式中保持不变，这是模式分解的第二个条件
形式化的定义分解后F在模式Ri上的投影为：
若分解p满足如下条件则称p**保持函数依赖**：
11.4 关系模式的范式
范式
范式从低级到高级依次为：1NF、2NF、3NF、BCNF、4NF、5NF，高一级的范式总是低一级范式的真子集
根据关系模式R的不可约FD集F，可以画出节点是属性或属性集，边是由被依赖节点指向依赖节点的有向图来辅助分析关系模式，叫做函数依赖图
注：复习时间关系ppt中范式的例子来不及整理了
（1）1NF
1NF要求关系模式R的每一个实例r均满足：r中的每一个元组t的每一个属性中只有一个值，这是关系模式的基本要求
不满足1NF的关系模式有二义性！
（2）2NF
假定：R只有一个候选码，且该候选码为主码
A完全依赖于W是指：W→A且A不依赖于任何一个W的真子集X，W是主键也可能包括多个属性{X、Y}，非主属性A不能局部函数依赖于X或Y
不满足2NF的关系模式可能存在［插入异常、删除异常、更新异常和数据冗余］，通过画出函数依赖图无损分解非2NF得到2NF，但2NF也不能完全消除上述问题
（3）3NF
假定：R只有一个候选码，且该候选码为主码
称A传递依赖于Y则有：Y→X，X→A，并且Y不依赖于X（即Y不等于X）、A不是X的子集
不满足3NF的关系模式也可能存在［插入异常、删除异常、更新异常和数据冗余］，通过打破传递依赖链条，把关系模式分解成多个子关系模式
（4）BCNF
BCNF是3NF处理R有多个候选码的扩展，当R有多个候选码时即使
如果关系模式R的所有不平凡的、完全的函数依赖的决定因素（左边的属性集）都是候选码，则
若要求保持函数依赖和无损联接，则总可以达到3NF，但不一定满足BCNF；因为BCNF可以达到无损连接，但不一定保持函数依赖
11.5 关系模式分解为范式的分解算法
（1）保持函数依赖地分解R到3NF
算法步骤：
（2）无损连接且保持函数依赖地分解R到3NF
算法步骤：
（3）无损联接地分解R到BCNF
算法步骤：
版权声明：本文为博主原创文章，未经博主允许不得转载。