范式的关系数据库中的几种设计范式

发布网友 发布时间：2022-04-07 23:59

我来回答

共2个回答

懂视网 时间：2022-04-08 04:21

模式分解有一套规范化的分解标准，称为范式（本章重点，见后续小节）

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)：

关系模式设计就是寻求一个最小FD集T，一旦实现T则可以实现所有FD

（2）函数依赖的平凡性

若X→Y且Y是X的子集，则X→Y是平凡FD（子集必然依赖），否则是称FD不平凡；平凡FD无实际意义，可以通过消除平凡FD来缩小FD集

（3）函数依赖闭包

函数依赖有以下推理规则，称为Armstrong公理:

函数依赖集F逻辑蕴含的函数依赖的全体构成的集合称为函数依赖F的闭包，记做F+，通过一系列推理规则可以求得F的闭包并判断某一函数依赖X→Y是否能够由F推出（即判断X→Y是否属于F+）

（4）属性闭包

判断X→Y是否能够由F推出就去构造F+计算量比较大，其实只需构造**属性X的闭包**X+即可，X+是所有能够用A推出的属性集合（即函数依赖于A的属性集合）

（5）最小函数依赖集

最小函数依赖集F必须满足以下性质：

求某个函数依赖集的最小函数依赖集的步骤如下：

1. 分解律让右边无多属性，消除冗余属性
2. 用推理规则消去左边多属性冗余
3. 消除剩余冗余FD

11.3 关系模式的分解

关系模式R(U)的一个分解p={Ri(Ui)}满足U=∪{Ui}，模式分解必须是无损连接并且需要保持函数依赖

（1）无损连接

无损连接是指：某关系模式的事例r按照关系模式分解成多个关系r1,…,rk，若r1,…,rk的自然连接（Join操作）等于r，则称该模式分解是无损的

（2）测试无损连接

Chase方法能够检测完全的无损连接，设有n个属性的模式R分解为k个模式Ri，有如下Chase过程：

1. 构造一个k行n列的表格，每行对应一个模式Ri，每列对应一个属性Aj，若Aj在模式Ri中则表格[i][j]中填入aj，否则填入bij
2. 扫描F中的每个FD X→Y
3. 若表格中有两行在X分量上相等，在Y分量上不相等则修改Y：若Y的分量中是个是aj，则另一个也修改为aj
4. 如果没有aj，则用其中一个bij替换另一个符号（i是所有b中最小的行数）
5. 重复2、3、4一直到表格不能修改为止
6. 若此时表格中有一行全是a，则该分解是无损连接的分解

当模式分解是简单的二元分解时（即p={R1,R2}），p是无损连接的分解当且仅当下面FD之一成立：

（3）保持函数依赖

保持函数依赖是指关系模式R的FD集F在分解后仍在数据库模式中保持不变，这是模式分解的第二个条件

形式化的定义分解后F在模式Ri上的投影为：

πRi(F)={X→Y|X→Y∈F+?X、Y?Ri}

若分解p满足如下条件则称p**保持函数依赖**：

(?i=1kπRi(F))+=F+

11.4 关系模式的范式

范式xNF即是满足特定要求的模式，将低一级范式的关系模式通过模式分解转换为高一级范式的关系模式集合的过程叫做规范化

范式从低级到高级依次为：1NF、2NF、3NF、BCNF、4NF、5NF，高一级的范式总是低一级范式的真子集

根据关系模式R的不可约FD集F，可以画出节点是属性或属性集，边是由被依赖节点指向依赖节点的有向图来辅助分析关系模式，叫做函数依赖图

注：复习时间关系ppt中范式的例子来不及整理了

（1）1NF

1NF要求关系模式R的每一个实例r均满足：r中的每一个元组t的每一个属性中只有一个值，这是关系模式的基本要求

不满足1NF的关系模式有二义性！

（2）2NF

假定：R只有一个候选码，且该候选码为主码

R∈1NF且R的每一个非主属性（非候选码的其他属性）都完全函数依赖于主码时，R∈2NF

A完全依赖于W是指：W→A且A不依赖于任何一个W的真子集X，W是主键也可能包括多个属性{X、Y}，非主属性A不能局部函数依赖于X或Y

不满足2NF的关系模式可能存在［插入异常、删除异常、更新异常和数据冗余］，通过画出函数依赖图无损分解非2NF得到2NF，但2NF也不能完全消除上述问题

（3）3NF

假定：R只有一个候选码，且该候选码为主码

R∈2NF且R的每一个非主属性都不传递依赖于主码时，R∈3NF

称A传递依赖于Y则有：Y→X，X→A，并且Y不依赖于X（即Y不等于X）、A不是X的子集

不满足3NF的关系模式也可能存在［插入异常、删除异常、更新异常和数据冗余］，通过打破传递依赖链条，把关系模式分解成多个子关系模式

（4）BCNF

BCNF是3NF处理R有多个候选码的扩展，当R有多个候选码时即使R∈3NF，也可能出现［插入异常、删除异常、更新异常和数据冗余］，这时需要分解为BCNF范式

如果关系模式R的所有不平凡的、完全的函数依赖的决定因素（左边的属性集）都是候选码，则R∈BCNF

若要求保持函数依赖和无损联接，则总可以达到3NF，但不一定满足BCNF；因为BCNF可以达到无损连接，但不一定保持函数依赖

11.5 关系模式分解为范式的分解算法

（1）保持函数依赖地分解R到3NF

算法步骤：

1. 求出R的最小函数依赖集F
2. 把所有不在F中出现的属性组成一个关系模式R’，并在U中去掉这些属性
3. 若F中存在X→A且XA=U，则算法结束输出{R’,R(U)}，否则继续下一步
4. 对F中的FD按相同的左部分组构成一个关系模式Ri(Ui)，Ui包括了该组FD涉及的所有属性
5. 去掉{Ri(Ui)}中属性集Ui是其他某个关系模式属性集Uj子集的关系模式Ri，得到最终的分解p={R1,R2,…,Rk,R’}，p能够保持函数依赖地把R分解到3NF

（2）无损连接且保持函数依赖地分解R到3NF

算法步骤：

1. 按算法(1)中步骤求出保持函数依赖的3NF分解，设q={R1,R2,…,Rk}
2. 设X是R的主码，p={R1,R2,…,Rk,R(X)}
3. 若X是q中某个Ri(Ui)属性集Ui的子集，则删除p中的R(X)
4. 输出p，p能够无损连接且保持函数依赖地把R分解到3NF

（3）无损联接地分解R到BCNF

算法步骤：

1. p={R}
2. 检查p中各关系模式是否满足BCNF，是则终止输出p
3. 设p中S(Us)非BCNF，则必存在X→A且X不是S的候选码：S分解为S1(XA)和S2(Us-A)，把p中的S替换为S1、S2，跳转至第二步

版权声明：本文为博主原创文章，未经博主允许不得转载。

数据库复习11——关系模式与范式

标签：数据库   关系模式   范式   无损连接   函数依赖   

热心网友 时间：2022-04-08 01:29

1 第一范式（1NF）
在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。
简而言之，第一范式就是无重复的列。
2 第二范式（2NF）
第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被唯一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。这个唯一属性列被称为主关键字或主键、主码。
第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性。如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。
简而言之，第二范式就是非主属性非部分依赖于主关键字。
3 第三范式（3NF）
满足第三范式（3NF）必须先满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。
例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在图3-2的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。
简而言之，第三范式就是属性不依赖于其它非主属性。
4 BCNF（BC范式）
5 第四范式（4NF）
6第五范式（5NF）
是最终范式，消除了4NF中的连接依赖。
软道语录
软道范式
软道范式是对数据库进行优化的原则 。
（欢迎广大读者补充更正以上信息）
数据库设计三大范式应用实例剖析
数据库的设计范式是数据库设计所需要满足的规范，满足这些规范的数据库是简洁的、结构明晰的；同时，不会发生插入（insert）、删除（delete）和更新（update）操作异常。反之则是乱七八糟，不仅给数据库的编程人员制造麻烦，而且面目可憎，可能存储了大量不需要的冗余信息。
设计范式是不是很难懂呢？非也，大学教材上给我们一堆数学公式我们当然看不懂，也记不住。所以我们很多人就根本不按照范式来设计数据库。
实质上，设计范式用很形象、很简洁的话语就能说清楚道明白。本文将对范式进行通俗地说明，并以笔者曾经设计的一个简单论坛的数据库为例来讲解怎样将这些范式应用于实际工程。