数据库"范式"

Posted 2020-08-03 杨龙飞的博客

1.为什么要学习数据库”范式”?

当我们独立去完成一个自己的小项目的时候,肯定要去设计”合适”的数据模型即逻辑架构,那么,我们怎么知道自己设计的数据模型是最”合适”的呢?肯定得有一个标准去衡量自己设计的数据模型,看到这里,大家知道为什么要学习范式了.

2.”范式”能解决什么问题?

刚才说过,学习范式是为了去设计一个”合适的”数据模型,那么，一个”合适”的数据模型，它能解决什么问题呢?

1.消除数据冗余.
2.消除更新异常.
3.消除插入异常
4.消除删除异常.

3.范式的概念

范式是符合某一种级别的关系模式的集合,它是关系数据库理论的基础,也是我们在设计数据库结构中所要尊循的规则和指导方法. 数据库有5个基本的范式:即第一范式(1NF),第二范式(2NF),第三范式(3NF),BCNF(BC范式),第四范式(4NF)。甚至还有5NF,6NF,DK范式，本文只讨论前面五种范式,这五种范式，就是为了解决第二个点中所说的问题.从1NF到4NF逐级提高标准,大家可以把它理解为猿到人的进化过程。　　

4.具体的例子

用一个具体的例子来分析这几种范式.　　

学号	姓名	系名	宿舍楼	课程号	成绩
03001	周毅	电信系	A楼	语文	95
03001	周毅	电信系	A楼	数学	89
04015	崔勇	计算机系	C楼	大物	70
04015	崔勇	计算机系	C楼	英语	85
03018	王文涛	电信系	A楼	语文	87
03019	马季军	法律系	B楼	大物	88
03019	贺智平	法律系	B楼	大物	56

在上面提到了关系模式.而这张表的关系有
1.学号(x)–>姓名(y).
2.学号(x)–>系名(y).
3.系名(x)–>宿舍楼(y).
4.(学号,课程)(x)–>成绩(y).
怎样去理解上面的关系呢?它们的关系就是y=x^2,当x确定时,y一定有唯一值,即x唯一确定y.

4.几种特殊的函数依赖

1.平凡函数依赖:如果A属性组唯一确定B,并且B属性属于A属性组,那么A–>B是平凡函数依赖。eg:在上表中(学号,课程)—>课程.课程属于(学号,课程)这个属性组. 对于任以关系模式,平凡函数依赖都是成立的。所以,讨论它是，没有意义的,所以大家了解就行.
2.非平凡函数依赖:如果A属性组唯一确定B,并且B属性不属于A属性组,那么A—>B是非平凡函数依赖.eg:在上表中(学号,课程)—->成绩,成绩不属于(学号,课程)这个属性组,所以是非平凡函数依赖.
3.部分函数依赖:A属性组可以确定B,但是B不完全依赖于X，什么意思呢,eg(学号,课程)—>姓名.(学号,课程)可以唯一确定姓名,但是姓名只需要一个学号就能唯一确定,没有课程也可以,这就称B部分依赖A.
4.完全函数依赖:A属性组唯一确定B,并且A属性组的任何一个真子集不能唯一确定B。那么称B完全依赖于A.eg: (学号,课程)–>成绩.(学号,课程中的任何一个都不能唯一确定成绩),所以说成绩完全依赖于(学号,课程);
5.传递函数依赖:如果属性A–>B,B–>C,那么A–>C.且B不属于A,B也不能唯一确定A,那么A–>C.eg:学号—>系名,系名—>宿舍楼. 那么学号—>宿舍楼.为传递函数依赖.
6.码:一个属性或者属性组能唯一确定本属性或属性组之外的所有属性，即其它属性完全依赖此属性或属性组.eg(学号,课程)唯一确定(姓名,系名,宿舍楼,成绩),那么，怎样去找码呢,如果有n个属性列，那么所有的组合,一个属性的组合n种,二个属性的组合,Cn2(代表从n个中任意取两个),三个属性的组合Cn3(代表从n个中任意取三个)……….当然，不可能一个一个去试.那是有技巧的,当你已经知道(学号,课程)是码,那么以后,包含这个列的组成直接忽略.因为码是完全函数依赖.
7.主属性:码中包含的属性叫做主属性.
8.非主属性:除过码中包含的属性之外的所有属性.
9.单码:单个属性是码.
10.全码:整个属性组是码,称为全码.

6.第一范式(1NF)

如果关系模式R中不包含多值属性,则R满足第一范式.并且，关系模式中所有的属性都是不可再分事务数据项,第一范式是对关系模式的最低要求,不满足第一范式的数据库模式称为关系型数据库. 具体来看个例子吧:

在上面这个表中,学生对应(学号,姓名),明显学生既对应学号，又对应姓名.所以，这应该分开做出调整,第一张(下面这张表就满足第一范式).

学号	姓名	系名	宿舍楼	课程号	成绩
03001	周毅	电信系	A楼	语文	95
03001	周毅	电信系	A楼	数学	89
04015	崔勇	计算机系	C楼	大物	70
04015	崔勇	计算机系	C楼	英语	85
03018	王文涛	电信系	A楼	语文	87
03019	马季军	法律系	B楼	大物	88
03020	贺智平	法律系	B楼	大物	56

在看上面我们提到的4个范式我们要解决的4个问题,第一范式是否解决了上面的问题,解决了几个:
* 数据冗余可以看到姓名,系名,宿舍楼大量的重复.
* 更新异常:如果一个学生改名,则关于这个学生的所有的选课元组都得更新(eg:如果周毅改名,则需要去改两列).
* 删除异常:如果计算机的系的学生全部毕业,相应的计算机系以及C楼的信息也会被删除.
* 插入异常:如果学校新开了某个系,但是没有招学生,这个系就无法插入.

7.第二范式(2NF)

在第一范式的基础上,如果每个非主属性对主属性都达到了完全函数依赖,则满足第二范式的要求(2NF),换去话说,就是消除所有非主属性对主属性的部分函数依赖(ps:这是第二范式的要求),那么，怎么去分析呢?看我们上面的例子:
主属性:(学号,课程); ps:主属性必须是码哦.
非主属性:姓名,系,宿舍楼,成绩.

(学号,课程)—>姓名: 姓名由学号就能唯一确定,所以姓名对(学号,课程)是部分函数依赖.
(学号,课程)—>系:系和姓名一样,由学号能唯一确定.
为了消除关系模式中的部分函数依赖，采用投影分解法,将部分函数依赖从关系模式中分离出来,得到以下两张表.

SC(学号,课程,成绩);
SL(学号,姓名,系名,宿舍楼);
得到两张表分别为:
SC表

学号	课程	成绩
03001	语文	95
03001	数学	89
04015	大物	70
04015	英语	85
03018	语文	87
03019	大物	88
03020	大物	56

S表　　

学号	姓名	系名	宿舍楼
03001	周毅	电信系	A楼
04015	崔勇	计算机系	C楼
03018	王文涛	电信系	A楼
03019	马季军	法律系	B楼
03020	贺智平	法律系	B楼

在看上面提到的4个问题我们解决了几个:
数据冗余:明显的可以看出姓名,系名,系主任的数据冗余得到了明显的改善.
更新异常:现在,一个学生改名,,只需要改S表中的姓名，而没有必要改他的每一条选课记录.
插入异常:如果现在学校新开设一个系,在没有招生的情况下，系还是不能插入到S表中,因为学号是主属性.()
删除异常:一个系的所有学生毕业,再删除所有学生信息的同时,会连带着删掉所有系的信息.
既然第二范式只是降低了数据冗余度,其它的并没有得到提高. 那么,接着，我们一起来看第三范式:

8.第三范式(3NF)

同样,第三范式是建立在第二范式的基础上.而第三范式的目的是消除非主属性对主属性的传递函数依赖.
在第二范式中,我们得到了两张表:
SC表:选课(学号,课程,成绩).
S表:(学号,姓名,系名,宿舍楼)
还记得什么是传递函数依赖吧,如果忘了,翻到上面去看看.分析SC表,我们发现,不存在传递函数依赖,而在S表(学号)–>(系名) (系名)—>(宿舍楼)存在传递函数依赖,那我们就解决了这个传递函数依赖,看看上面的问题能不能得到改善呢?
SC表:选课(学号,课程,分数)
S表:学生(学号,姓名,系名);
D表:系(系,宿舍楼);
　
得到三张表
SC表

学号	课程	成绩
03001	语文	95
03001	数学	89
04015	大物	70
04015	英语	85
03018	语文	87
03019	大物	88
03020	大物	56

S表

学号	姓名	系名
03001	周毅	电信系
04015	崔勇	计算机系
03018	王文涛	电信系
03019	马季军	法律系
03020	贺智平	法律系

D表

系	宿舍楼
电信系	A楼
法律系	B楼
计算机系	C楼

再看上面的问题我们第三范式解决了几个:
插入异常:如果现在学校新开设一个系.就算没有纳入招生计划,此系还是可以插入到D表中.
删除异常,就算现在一个系中的所有学生都毕业了,删除这个系的所有学生的信息,这个系的信息也不会被删除。　
大家可以发现,到现在为止,数据冗余,更新异常,插入异常,删除异常都得到了改善.它已经能基本满足我们的需要了.

9.BC范式(BCNF)

BC范式:BC范式是在第三范式的基础上的一种特殊情况,既每个表只有一个候选键(在一个数据库中每行的值都不相同,则可称为候选键)。
每一个决定因素都为键,则R一定属于BC范式,对于BCNF的关系模式,具有以下性质:
(1)所有非主属性都完全依赖于每个主属性.(在第二范式2NF中已经实现)
(2)所有主属性对每一个不包含它的主属性都是完全函数依赖;
(3)没有任何属性完全函数依赖于非主属性中任何一组属性. (第三范式中已经实现)
那么，BC范式就是完全针对主属性而言的,即上面所说的第二条.所有主属性对每一个不包含它的主属性都是完全函数依赖;
看个具体的例子　
假设仓库管理关系表为storehourseMange(仓库ID,存储物品ID,管理员ID,数量).

仓库ID	存储物品ID	管理员ID	数量
A1	S1	C1	20
A1	S2	C1	30
A2	S3	C2	40
A2	S4	C2	50
A2	S5	C2	60

此表满足:

• 一个管理员只在一个仓库工作
• 一个仓库可以存储多种物品
  这个数据库表存在如下决定关系:
  (仓库ID，存储物品ID)—->(管理员ID,数量)
  (管理员ID,存储物品ID)—>(仓库ID,数量)
  主属性:仓库ID,存储物品ID,管理员ID.
  非主属性:数量.
  码(还记得码的概念吧,不记得了翻上去看看):(仓库ID,存储物品ID),(管理员ID,存储物品ID).
  先来确定这个张表是否满足第三范式(3NF)，因为BCNF范式是建立在第三范式的基础之上的.
  分析表可以看出.不存在非主属性对对主属性的部分函数依赖和传递函数依赖.满足第三范式.
  那么先来看看上面提到的四个问题:
  数据冗余:看表很明显这个问题不存在.
  插入异常:如果现在新建一个仓库，但是不给这个仓库中存任何物品,那么，此条数据无法存入.
  删除异常:如果某个仓库的物品全部出库,删除这个物品的同时,对应的仓库也会被删除.
  更新异常:如果某个仓库换了管理员,则要改多条数据.
  原因是什么呢?
  看这个关系(仓库ID,)
  (管理员ID,存储物品ID)—->(仓库ID);看这个关系,三个属性都是主属性,但是(管理员ID就能唯一确定仓库ID)，所以仓库ID对(管理员ID,存储物品ID)存在部分函数依赖.
  分解表得到:
  仓库:(仓库ID,管理员ID);
  物品:(仓库ID,存储物品ID,数量);
  仓库:

仓库ID	管理员ID
A1	C1
A2	C2

物品:

仓库ID	存储物品ID	数量
A1	S1	20
A1	S2	30
A2	S3	40
A2	S4	50
A2	S5	60

再看刚才的问题:

• 插入异常: 新建一个仓库,就算里面没有东西，也可以插入仓库表.
• 更新异常:，某个仓库的管理员换了，则只需要改仓库表中的一条数据.
• 删除异常:某个仓库的物品全部出库,此仓库也不会被删除.

10.第四范式(4NF)

上面解决的是在函数依赖的范畴内有关关系模式的规范化问题,如果一个关系模式达到了BCNF,是否就完美了。看下面这个例子:
在一个教学管理系统中,有一个关系模式Teaching(C,T,B)，其中C表示课程,T表示教师,B表示参考书.

存在如下关系:

• 一门课程由多个老师讲授，它们使用同一套参考书.
• 每个老师可以讲授多门课程,每本参考书可以供多门课程使用.

课程C	教师T	参考书B
数据库原理及应用	邓宇	数据库系统概论
数据库原理及应用	邓宇	SQL Server2000
数据库原理及应用	邓宇	离散数学
数据库原理及应用	孙泽	数据库系统概论
数据库原理及应用	孙泽	数据库系统概论
数据库原理及应用	孙泽	数据库系统概论
数据结构	孙泽	数据结构与算法
数据结构	孙泽	数据结构
数据结构	孙泽	离散数学
数据结构	曹鹏	数据结构与算法
数据结构	曹鹏	数据结构与算法
数据结构	曹鹏	离散数学

很显然:这张表是全键;

先来看上面所提到的4个问题:

• 数据冗余:课程,教师,参考书的有关信息大量重复存储.
• 插入异常:当某门课增加一个任课老师,必须插入多个元组.
• 更新异常:如果某门课换了老师,则必须修改多行值.
• 删除异常:若要删除某一本参考书,则需要删除多条记录.
  这张表为什么会出现这样的问题呢?
  大家先来看看这张表的关系:
  

一门课程有多本参考书,很明显是一对多的关系. 也就是说课程对参考书有多值依赖关系。
刚才说到了多值依赖，那么，先来看看什么叫做多值依赖:

设R(U)是属性集U上的一个关系模式,X,Y,Z是U的子集,且Z=U-X-Y.关系模式R(U)中多值依赖X–>—>Y成立，当且仅当对R(U)的任一关系r,给定的一对(x,z)值，有一组Y的值.这组值仅仅决定x的值而与z的值无关.
eg: 在上面的关系模式中,对于一个(C,B)值(数据库原理及应用,SQL Server 2000),有一组T值{邓宇,孙泽}，而这组值仅仅决定于课程C(数据库原理及应用),所以T的值与B的值无关m仅由C决定，C—>—>T;
将上表分解为两个关系模式:
T(课程C,教师T) ;
B(课程C,参考书) ;
关系T

课程C	教师T
数据库原理及应用	邓宇
数据库原理及应用	孙泽
数据结构	孙泽
数据结构	曹鹏

关系B

课程C	参考书B
数据库原理及应用	数据库系统概论
数据库原理及应用	SQL Server2000
数据库原理及应用	离散数学
数据结构	数据结构与算法
数据结构	数据结构
数据结构	离散数学

看看上面的问题有没有得到改善:

• 信息冗余: 得到改善;
• 插入问题:某个课程增加老师季,只要在T表中添加一条记录就好了.
• 删除问题:删除一本书,也只要在BC表中删除一条记录即可.

总结一下:

• 上面对于数据库范式进行分解的过程中不难看出，应用的范式登记越高，则表越多。表多会带来很多问题：
• 查询时要连接多个表，增加了查询的复杂度.
• 查询时需要连接多个表，降低了数据库查询性能.
• 而现在的情况，磁盘空间成本基本可以忽略不计，所以数据冗余所造成的问题也并不是应用数据库范式的理由。
• 因此，并不是应用的范式越高越好，要看实际情况而定。第三范式已经很大程度上减少了数据冗余，并且减少了造成插入异常，更新异常，和删除异常了。我个人观点认为，大多数情况应用到第三范式已经足够，在一定情况下第二范式也是可以的。