二目关系属于4nf_关系数据理论知识点总结

最新推荐文章于 2023-06-20 00:16:21 发布

weixin_39608398

最新推荐文章于 2023-06-20 00:16:21 发布

阅读量2.1k

点赞数 1

文章标签：二目关系属于4nf

本文链接：https://blog.csdn.net/weixin_39608398/article/details/113330573

版权

本文详细介绍了关系数据理论，包括函数依赖、完全函数依赖、传递函数依赖、候选码、主属性、多值依赖等概念，并通过实例解析了1NF到4NF的规范化过程，帮助读者理解数据库设计的基础知识。

摘要由CSDN通过智能技术生成

由于头条号对公式支持还不够完备，所以建议大家关注微信公众号“IT工匠”后在后台回复B2获取本文原文pdf获得更佳阅读体验。

本文目录如下：

image-20190626234720043

关系数据理论

提示：由于公众号对公式的支持太垃圾，会出现比如公式编号消失不见等问题，建议大家点击阅读原文获得更佳阅读体验。

前备知识

函数依赖

在属性集U上，X、Y都是U上的子属性集，如果可以根据属性集X中属性的值唯一确定属性集Y中属性的值，则称Y函数依赖于X，记做$Xo Y$.

比如说：

实例1：属性集U={学号，姓名，年龄}，{学号}和{姓名}都是属性集U上的子集，当给定一个学号的值时，可以唯一个姓名的值，这样就符合函数依赖的关系，我们说{姓名}函数依赖于{学号}，即$学号姓名{学号}o {姓名}$。

实例2：还有一种情况，比如说X={学号,姓名}，Y={姓名}，当给定一个X的值时，也可以唯一确定Y的值，也有Y函数依赖于X，即$学号姓名姓名{学号,姓名}o{姓名}$

可以发现实例2中Y是X的子集，即$Y subseteq X$，这种情况我们称$Xo Y$是平凡的函数依赖，而对于实例1，$Y subseteq X$不成立，这种情况下我们称$Xo Y$是非平凡的函数依赖。

完全函数依赖

在R(U)中，如果Y函数依赖于X但是Y不函数依赖于X的任何子集，则称Y完全函数依赖于X，记为$Xstackrel{F} o Y$,否则称Y部分依赖于X，记做$X stackrel{P} o Y$。

比如属性集U中有3个属性：${a,b,c}$，如果${a,b}o {c}$，且${a} o {c}$，就不能说${c}$完全函数依赖于$，{a，b}$，反过来，如果${a,b} o {c } $，但${a} rightarrow {c}$且${b} rightarrow {c}$，则说明{c}完全函数依赖于{a,b}，即${a,b}stackrel{F} o {c}$.

传递函数依赖

在R(U)中，如果$X o Y , Y rightarrow X,Yo Z$，则称Z传递函数依赖于X，记为$传递X stackrel{传递} o Z$.

注意这里一定要满足条件$ Y rightarrow X$，如果$Yo X$，则有$X leftrightarrow Y$，这时就是$Xo Z$，而不是$传递X stackrel{传递} o Z$.

候选码

设K为R(U)中的属性或属性集合，若$Kstackrel{F} o U$，则称K为R的候选码.

其实说白了，候选码就是最小的可以推出U中所有属性的集合，也就是说，如果确定了一组候选码的值，可以唯一确定一组U中所有属性的值，举个例子，U={a,b,c,d}，如果{a,b}的属性值确定后可以唯一确定{c,d}的值，即${a,b}o {c,d}$，则{a，b}就是一组候选码(因为${a,b} o {a,b}$一定是成立的，又有${a,b}o {c,d}$，所以${a,b} o {a,b,c,d}$即${a,b} o U$)。

主属性

我们说候选码是最小的可以推出U中所有属性的集合，而这个集合中的任意一个属性值，就称为主属性，而在集合U中但不在候选码集合中的属性称为非主属性。

多值依赖

多值依赖比较抽象，这里用一张图解释：

image-20190626200649372

如上图所示，我们假设R(U)是属性集U上的一个关系模式，将U划分为3个子集X、Y、Z，注意这里的X、Y、Z是三个子集，每一个子集中都可能含有若干个属性，且X、Y、Z、U满足$Xcap Y =phi ,Xcap Z=phi ,Y cap Z=phi ,Xcup Y cup Z=U$，即X、Y、Z两两不相交、X、Y、Z之并为U(图上画的很清楚了)。

如果X，Y，Z满足X可以决定Z的值且Y和Z没有任何关系(Y的值变化不会引起Z的值变化)，则称Z多值依赖于X，记为$X o o Z$.

多值依赖有以下几个特性：

对称性
如上图所示，如果$X o o Z$，则必有$X o o Y$.
传递性
如果$Xo o {a},{a} o {a,b,c}$，则$X o o {b,c}$.

1NF

一阶范式(1NF)的定义：关系中每一个分量都不可再分，则这样的关系模式属于第一范式(1NF)，即“键值”对中的“值“应该为单个数值，而不是集合。

比如如下关系模式：

image-20190626233133946

这样的关系模式就不属于第一范式，因为$A1o{b1,b2,b3}$，b1,b2,b3还可再分，若想将其变为第一范式，则应该：

image-20190626233149436

这时这个关系模式就属于第一范式。

2NF

二阶范式(2NF)的定义：在1NF的基础上，消除关系模式中非主属性对候选码的部分函数依赖后，称该关系模式为2NF。

考虑下表：

image-20190626202517264

可以发现，我们通过学生编号就可以确定出来学生姓名、班级编号、学生院系，即：

{学生编号}o {学生姓名，班级编号，学生院系}

我们发现除了这个函数依赖，还有课程编号、成绩这两个属性没有用到，也就是说我们可以得出:

{学生编号，课程编号，成绩}o {学生姓名，班级编号，学生院系}

综合(1)式和(2)式，我们可以得出$学生姓名，班级编号，学生院系{学生姓名，班级编号，学生院系}$部分函数依赖于$学生编号{学生编号}$这个结论，则当前关系模式就不满足2NF的条件，即不属于2NF。

那么我们如何将上述关系模式转化为满足2NF要求的关系模式呢？自然是消除关系模式中非主属性对候选码的部分函数依赖，我们发现，上述关系模式不是2NF的原因在于$学生姓名，班级编号，学生院系{学生姓名，班级编号，学生院系}$部分函数依赖于$学生编号{学生编号}$，再进一步，是因为上述关系模式中出现了课程编号、成绩这两个属性，那么我们将这两个属性单独分离出来即可打破这种部分函数依赖，即将上面拆分为下面两个表格：

学生表：

image-20190626203227546

学生-课程表：

image-20190626203245296

这样就消除了关系模式中非主属性对候选码的部分函数依赖，该关系模式就属于2NF了。

3NF

定义：在1NF的基础上消除了非主属性对候选码的传递函数依赖后即满足3NF的要求。

以下表为例：

image-20190626203227546

上表中主属性、候选码为学生编号，其他3个属性为非主属性，我们发现根据学生编号可以唯一确定院系，即院系函数依赖于学生编号，但是思考一下，我们是拿到学生编号后就能直接查出来所属院系吗？实际的流程应该是先根据学生编号确定班级编号，然后再根据班级编号确定院系，即从学生编号确定院系这个过程经历了班级编号这一中间属性，即院系是传递函数依赖于学生编号的，所以说，上表是不满足3NF的要求的。

要将一个关系模式转化为3NF，需要消除非主属性对候选码的传递函数依赖，对上表来说就是要消除院系对学生编号的传递函数依赖，那我们直接将院系和学生编号划分到两个表中就可以了，就像这样：

学生表：

image-20190626204050866

班级-院系表：

image-20190626204101596

这样该关系模式中就不存在非主属性对候选码的传递函数依赖了，就满足3NF的要求了。

BCNF

定义：在1NF的基础上，将主属性对候选码的部分函数依赖、传递函数依赖消除后，就满足了BCNF的要求，如果这么说不够明白，我们换种说法，如果每一个函数依赖的决定因素都包含候选码，则满足BCNF的要求，也就是说，对于关系模式中的任意一个函数依赖$Xo Y$，如果X中都含有候选码，则该关系模式属于BCNF。

在理解定义之前我们先明确主属性和候选码的区别，我们说，如果从一个属性集合X出发可以确定所有属性集U中属性的值，就称X为该关系模式的候选码，即候选码是一个集合，而候选码集合中的属性称为主属性。

我们以一个例子来说明BCNF：

关系模式R(U)，属性集U={a,b,c}，有如下依赖关系：

{a,b} o {c}

{c} o {a}

很明晰在这个关系模式中{a,b}为候选码，a，b为主属性，那么它是否符合BCNF范式的要求呢？我们再看一遍BCNF范式的要求：每一个函数依赖的决定因素都包含候选码

对于第一个函数依赖：${a,b} o {c}$，其决定因素${a,b}$包含了候选码，没有问题；

对于第二个函数依赖：${c} o {a}$，其决定因素是${c}$，可是这个决定因素没有包含候选码即${a,b}$，所以这个函数依赖破坏了BCNF范式的要求。

那么我们如何将上述关系模式转化为满足BCNF范式要求的关系模式呢？方法和之前范式的规范化相同，很明显我们可以将(3)式转化为一张表：

{a,b} o {c}