关系数据库的规范化

数据库的课，学校讲的教材是王珊的那本红书。上课的时候听的就不是很懂，所以课下又参考了其他的教材和博客，在此做一个总结和整理（仅供学习使用）。希望自己可以更加清楚，也希望看的人能够明白。

文章目录

关系数据库的规范化关系数据库的规范化概述函数依赖范畴的规范化函数依赖相关概念BCNF3NF2NF1NF 多值依赖范畴的规范化多值依赖第四范式 后备知识：公理相关模式分解

关系数据库的规范化概述

首先，明确一下可能会用到的术语：

关系模式的形式化定义：$R(U,D,DOM,F)$ R为关系名U为组成该关系的属性集，一般用α或β表示U的子集D为属性集的域DOM为属性向域的映像集合F为属性间数据的依赖关系集合

属性到域的映像： 关系模式的定义是：关系模式是对关系的描述，包括关系名、组成该关系的属性名、属性到域的映像。

数据依赖：是通过一个关系中属性间的相互关联（主要是值的相等与否）体现出来的数据间相互依赖又相互制约的关系。 这个定义其实没啥用😀具体的函数依赖、多值依赖的定义会在后面详细说明

其次，要知道为何要提出数据的规范化：

数据冗余太大更新异常插入异常删除异常

规范化理论于1971年由E.F.Codd提出,用来改造关系模式，通过分解关系模式来消除其中不合适的数据依赖，以解决插入异常、删除异常、更新异常和数据冗余问题。

举个例子（以下例子内容来自知乎，有删改）

假设关系模式R为：

(学生ID，姓名，课程号，课程名，所在系，系主任，成绩)

数据冗余

我们有理工大类学生A，选了数学与英语课。那么在关系模式中则会存有两个字段：

(A_Id，A，课程号1，数学，理工大类，AAA，1.0)

(A_ID, A，课程号2，英语，理工大类，AAA，1.0)

从这我们可以看出，除了课程的相关属性，其他属性完全一样，纯粹是再存入了一遍，这明显造成了数据冗余。

插入异常

那么现在来一个转学生B，转学生初来乍到还没有选课，但是学生信息必须先录入那该怎么办呢？我们会发现我们遭遇了这样的窘状：

(B_ID,B，NULL，NULL，理工大类,AAA，NULL）

当我们在录入课程号和课程名的时候，完全无法填写，那么我们就无法插入新的记录。造成了插入异常。

删除异常

那么现在假设我们的B同学终于选了一门语文课，录入数据库以后突然觉得自己更喜欢数学课，于是出现了下面这一幕：

B：老师老师！我要改课，我想把我的语文课退了改成数学课！

老师：好的等一下我先把你的语文课记录删去…OK，搞定，现在给你登入数学课的记录，额…你学号是多少？

B：啊?学号？我忘了!!(小B刚来学校，还没完全记住学号) 直接在数据库里找我的学号不就好了

老师：啊可是我刚刚删掉了你的记录…

我们发现，刚刚老师在删除小B选的语文课记录时，这个关系模式中同样包含了小B的姓名学号等其他信息，当我们删除这条记录以后，可能会给我们带来其他数据的损失，这就是删除异常。

更新异常

小A是一个很矫情的小婊砸，有一天他突然觉得自己的名字不好听，去民政局把自己的名字改成了Accepted.一下子高大上了有没有！

于是理所当然的小Accepted跑去了数据库老师那更新信息，然后数据库老师便找到了

(A_Id，学生A，课程号1，数学，理工大类，AAA)

这条字段，很潇洒的把记录更改为

(A_Id, Accpted，课程号1，数学，理工大类，AAA)

心想这下肯定不会出差错了吧。然而细心的我们其实早就意识到，关于小A的记录并非只有一条，老师虽然将这条记录更改了，但是数据库中还存在着另外一条记录

(A_Id，学生A，课程号1，数学，理工大类，AAA)

这便是更新异常

最后，介绍一个贯穿本节始终的概念：范式

范式(Normal Form)是符合某一种级别的关系 模式的集合。某一关系模式𝑅为第𝑛范式，可简记为 𝑅 ∈ 𝑛𝑁F规范化就是，一个低一级范式的关系模式，通过模式分解转换为若干个高一级范式的关系模式的集合的过程。

函数依赖范畴的规范化

这部分课堂老师的讲解顺序是从1NF讲到BCNF，这里采用的从BCNF到1NF的顺序。

函数依赖相关概念

函数依赖：

简单来说，就是α和β是U的子集，若$X[\alpha ]=X[\beta ]$，则$Y[\alpha ]=Y[\beta ]$，则$\alpha \to \beta$，读为“α函数决定β”或“β函数依赖于α”（个人比较喜欢视为推出）。

如果这个概念还是抽象，不妨将其理解为y=f(x)的形式，初中就学过函数的定义(这个定义真的给我留下了特别深刻的印象)：一对一、多对一是允许的，一对多就是不行的。

平凡函数依赖和非平凡函数依赖

这个就更好理解了，平凡函数依赖就是当β是α的子集，显然α可以推出β。非平凡就是反过来。

因此：平凡函数依赖对于任一关系模式都必然成立。

完全函数依赖、部分函数依赖、传递函数依赖

这些概念比较好理解。

码相关 超码、候选码、主码、全码、非主属性、外码

BCNF

判断BCNF，这里沿用《数据库原理》中的定义方法，感觉会比较好理解： 这里涉及到闭包F+的概念，可以暂时理解为所有可以获得的函数依赖。

3NF

3NF在BCNF之上，放宽了条件。

2NF

2NF的条件进一步放宽，允许传递函数依赖，不允许部分函数依赖

1NF

1NF就已经放到了最宽，即如果一个关系模式𝑅的所有属性都是不可分的基本数据项。

多值依赖范畴的规范化

多值依赖

多值依赖的定义 首先，先明确多值依赖是怎样的：

在关系模式中，函数依赖不能表示属性值之间的一对多联系，这些属性之间有些虽然没有直接关系，但存在间接的关系，把没有直接联系、但有间接的联系称为多值依赖的数据依赖。 在函数依赖中，X与Y是否存在函数依赖关系，只需考察X,Y的两组属性，与别的属性无关。而在多值依赖中，X与Y是否存在多值依赖还需看属性Z。

在网上看到了一个比较易懂的解释，就是正常的函数依赖就是我们储中学的函数y = f(x)，而多值依赖就像是到了高中学的x = f(y)，尽管它严格意义上不是函数，但我们也把它看成函数，利用其性质做题。

其次，来看一个例子（图片来源于网络）： 可以看到，这个模式存在数据冗余、插入、删除、修改难度大。而产生这些问题的原因就是多值依赖的存在。

最后，来说一下多值依赖的定义

X、 Y和Z是U的子集，并且Z＝U－X－Y。关系模式R(U)中多值依赖 X→→Y成立，不仅需要一个X决定一组Y的值，还需要Z跟这个无关。

对于这个的理解，也是在网上看到一个有意思的解释，（由于人物原因）稍作改动如下：如果X是潘金莲跟西门庆私通，Y是武大郎绿了，Z是武松出现/武大郎死了等等的话，那么只要X成立，Y必然成立，跟Z无关。大概就是这个意思。

再来一个比较正经的定义： 平凡多值依赖和非平凡的多值依赖

平凡：Z压根就不存在，显然没关系

多值依赖的性质

对称性：从上面的表格可以看出，若X→→Y，则X必然 →→R-X-Y

传递性：若X →→ Y，Y →→ Z，则X必然 →→ Z-Y

函数依赖是多值依赖的特殊情况：一对一自然是一对多的特殊情况

传递性和下面这几个性质还是不知道怎么理解（有知道的可以评论一下）

第四范式

后备知识：公理相关

这里没啥好解释的，就是看书去理解，极力推荐数据库原理书上的解释

把概念列一下： 逻辑蕴含、阿姆斯特朗公理及其推论、证明、F的闭包、属性的闭包、算法们

模式分解

这里上课老师是临时补充的，没讲太多，又很重要。后续我会把这个部分整理好发上来，包括前面的阿姆斯特朗公理也整理一下。

[参考]

https://zhuanlan.zhihu.com/p/22337031 https://blog.csdn.net/qq_39521554/article/details/78974213 本校老师上课ppt 数据库原理（第六版）