关系数据库理论

相关概念

• 关系：描述实体、属性、实体间的联系。从形式上看，它是一张二维表，是所涉及属性的笛卡尔积的一个子集。

• 关系模式：用来定义关系，是对关系的描述

• 关系数据库：基于关系模式的数据库。利用关系来描述现实世界从形式上看，它由一组关系组成。

• 关系模式有五部分组成，可以定义为R(U,D,DOM,F)

  • R：关系名
  • U：组成该关系的属性名集合
  • D：属性组U中属性所来自的域
  • DOM：属性向域的映像集合
  • F：属性间数据的依赖集合

• 数据依赖：是通过一个关系中属性间值的相等与否体现出来的数据间的相互关系，它是现实世界属性间相互关联的抽象。是数据内在的性质，是语义的体现。

• 数据依赖的类型分为函数依赖和多值依赖

• 由于D和DOM对模式涉及关系不大，在本节中把关系模式简化为一个三元组：R(U,F)，研究重点为：

  • 一个关系模式应该有哪些属性；
  • 这些属性间存在什么样的联系

数据依赖的影响

• 冗余数据太大，浪费大量的存储空间。比如每个分组及组长重复出现
• 更新异常：数据冗余，在更新数据时，维护数据完整性代价大。比如如果要更改一名员工到另外一个组，则需要将这个员工的所有销售对应的分组和组长进行更新。
• 插入异常：该插的数据插不进去。比如由于主码中所包含的属性值不能取空值，如果新成立一个组，由于这个组还没分配员工，就无法将这个分组插入关系中
• 删除异常：不该删除的数据不得不删除比如如果某个分组的所有员工被调到其他分组，则这个组的信息会随所有组员的调动而全部丢失

“好”的关系模式不会发生插入异常、删除异常、更新异常，数据冗余应尽可能少。

原因：由存在于模式中的某些数据依赖引起的。解决方法：通过分解关系模式来消除其中不合适的数据依赖。

我们就可以把SALE关系分解为三个关系模式：

S1(ENO, SaleDate, SaleAmount)
S21(ENO, Group)
S22(Group, GName)

函数依赖

对于R（U）上的任一一个可能的关系r，如果r中不存在两个元组，它们在X上的属性值相同，而在Y上的属性值不同，则称X函数决定Y或Y函数依赖于X，记作X->Y

X称为决定因素或决定属性集

说明：

• 函数依赖不是指关系模式R的某个或某些关系实例满足的约束条件，而是指R的所有关系实例均要满足的约束条件
• 函数依赖时语义范畴的概念
• 数据库设计着可以对现实世界作强制的规定
• 若X->Y，且Y->X，则记X<-->Y
• 若Y不函数依赖于X，则记作X!=>Y

【例】关系模式学生（学号，姓名，出生年份，性别，学院，专业，微信号），假设不允许重名，则有:

• 学号 →出生年份 , 学号 →性别，学号 → 学院，学号 → 专业， 学号 → 微信号；
• 学号 ←→ 姓名；
• 姓名 →出生年份 , 姓名 →性别，姓名 → 学院，姓名 → 专业，姓名 → 微信号；
• 但性别→专业。

非平凡函数依赖

在关系模式R（U）中，对于U的子集X和Y，如果X→Y，但Y ⊈ X，则称X→Y是非平凡函数依赖（后续主要讨论这个）；若X→Y，但Y⊆ X，则称X→Y是平凡函数依赖。

【例】在关系R1（ENO，SaleDate，SaleAmount）中，个属性分别为员工编号，日期，销售量，每个员工每天会有一个销售额，存在如下函数依赖： 非平凡函数依赖：(ENO，SaleDate) → SaleAmount； 平凡函数依赖： (ENO，SaleDate) → ENO， (ENO，SaleDate) → SaleDate。

对于任一关系模式，平凡函数依赖都是必然成立的，它不反映新的语义，因此若不特别声明， 我们总是讨论非平凡函数依赖。

完全函数依赖

• 在关系模式R（U）中，如果X→Y，并且对于X的任何一个真子集X’，都有 X’→ Y，则称Y完全函数依赖于X，记作$$X\overset{F}{\rightarrow}Y$$
• 若X→Y，但Y不完全函数依赖于X，则称Y部分函数依赖于X，记作$$X\overset{P}{\rightarrow}Y$$

【例】如在关系R1（ENO，SaleDate，SaleAmount）中，由于ENO !=> SaleAmount， SaleDate !=> SaleAmount，

因此$$(ENO, SaleDate)\overset{F}{\rightarrow}SaleAmount$$

传递函数依赖

• 在关系模式R（U）中，如果X→Y，Y→Z，且Y ⊈ X，Y→X，递 则称Z传递函数依赖于X，记作$$X\overset{传递}{\rightarrow}Z$$

【例】如在销售关系R（ENO，SaleDate，SaleAmount，Group， GName）中，各属性分别为员工编号，日期，销售量，分组，组长，存在语义每个员工只能属于一个分组，每个分组只有一个组长，由于ENO→Group，Group→GName，则$$ENO\overset{传递}{\rightarrow}GName$$

码

设K为R（U，F）中的属性或属性组合。若$$K\overset{F}{\rightarrow}U$$则K为R的候选码。若候选码多于一个，则选定其中的一个作为主码。

说明：

• 候选码可以唯一地识别关系的元组
• 包含在任何一个候选码中的属性，叫做主属性。不包含在任何候选码中的属性称为非主属性或非码属性
• 最简单的情况下，候选码只包含一个属性
• 最复杂的情况下，候选码包含关系模式的所有属性，称为全码。

关系模式R中属性或属性组X并非R的码，但X是另一个关系模式的码，则称X是R的外部码，简称外码。

第一范式

定义

• 如果一个关系模式R的所有属性都是不可分的基本数据项（不能表中有表），则R是第一范式，简称1NF，记作R∈1NF
• 第一范式是对关系模式的最起码的要求。满足第一范式的关系称为规范化关系。不满足第一范式的数据库模式不能称为关系数据库。

非规范化关系

规范化关系

问题

【例】校园超市数据库中有一个记录超市员工每天销售量的关系模式SALE（U，F），其中SALE的属性由员工编号，日期，销售量，分组，组长等属相组成，U如下所示： U={ENO，SaleDate，SaleAmount，Group，GName}；现有语义规定，每个员工每天会有一个销售额，每个员工只能属于一个分组，每个分组只有一个组长。

结合现实世界的已知事实，可以分析得到属性组U上有如下函数依赖:

关系模式SALE满足第一范式，候选码是（ENO，SaleDate），但SALE关系存在很多问题：

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

原因：Group、GName部分函数依赖于码，GName传递函数于依赖于码。

第二范式

定义

• 若关系模式R∈1NF，且每一个非主属性都完全函数依赖于码，则称R为第二范式，简称2 NF，记作R∈2NF。
• 第二范式也可以理解为：不允许关系模式中存在这样的依赖：如果X’是码X的真子集，有X’→Y，其中Y是该关系模式的非主属性。

1NF向2NF的转换

• 由第一范式向第二范式转换的方法是：消除其中非主属性对码的部分函数依赖，一般是将一个关系模式分解成多个2NF的关系模式。
• 即将部分函数依赖于码的非主属性及其决定属性移除，另外形成一个关系，从而满足2NF。

【例】关系SALE(ENO，SaleDate，SaleAmount，Group，GName)是1NF，但存在非主属性Group，GName对码的部分函数依赖，采用分解法，把SALE分解为两个关系模式：

• S1（ENO，SaleDate，SaleAmount）

• S2（ENO，Group，GName）

• 其中S1的码为（ENO，SaleDate），S2的码为ENO。

• 分解之后的关系模式S1和S2中，非主属性都完全函数依赖于码了。S1和S2的函数依赖图如图所示。

问题

• SALE关系分解之后得到的S1关系和S2关系都是第二范式，在一定程度上能够减轻原关系中存在的各种异常问题。
• 但是将一个1NF关系分解为多个2NF关系，并不能完全消除关系模式中的各种异常情况和数据冗余。
• 一个属于2NF的关系模式也不一定是一个好的关系模式

【例】SALE分解后得到的关系模式S2（ENO，Group，GName）

• 是一个2NF的关系模式
• 不存在非主属性对码的部分函数依赖
• 但S2仍然存在问题：
  • 数据冗余度大
  • 插入异常
  • 删除异常
  • 更新问题
• 原因：存在非主属性GName传递函数依赖于码（没有员工不能插入组）

第三范式

定义

如果关系R为2NF，并且R中每一个非主属性都不传递依赖于R的候选码，则称R为第三范式，简称3NF，记作R∈3NF。

2NF向3NF的转换

第二范式向第三范式转换就是消除非主属性对码的传递函数依赖。即将传递函数依赖于码的非主属性及其决定属性移除，另外形成一个关系，从而满足3NF。

【例】关系模式S2（ENO，Group，GName）是2NF，但存在非主属性GName传递依赖于码ENO，采用分解法，把S2分解为两个关系模式：

• S21（ENO，Group）
• S22（Group，GName）

其中S21的码为ENO，S22的码为Group。分解之后的关系模式S21和S22中，不存在非主属性对码的传递函数依赖。S21和S22的函数依赖图如图所示。

问题

• 将一个2NF的关系分解为多个3NF的关系，可以在一定程度上解决原2NF关系中存在的插入异常、删除异常、数据冗余度大、修改复杂等问题。
• 但是将一个2NF关系分解为多个3NF的关系后，并不一定能完全消除关系模式中的各种异常情况和数据冗余。

【例】校园超市数据库中有一个记录仓库商品管理的关系模式SM（GoodsNO，StorageNO，ManagerNO，SNUM），各属性分别是商品编码，仓库编码，仓库管理员编码，商品的存放数量；现有语义规定：一个管理员只在一个仓库工作；一个仓库只有一个管理员管理；一个仓库可以存储多种商品，一种商品可以存放在不同仓库；每种商品在一个仓库存放有一个存放数量。

结合现实世界的已知事实，可以分析得到SM的属性组 上有如下函数依赖:

• StorageNO→ManagerNO
• ManagerNO→StorageNO
• (GoodsNO，StorageNO)→SNUM
• (GoodsNO，StorageNO)→ManagerNO
• (GoodsNO，ManagerNO)→StorageNO
• (GoodsNO，ManagerNO)→SNUM

SM的候选码有两个：(GoodsNO，StorageNO)和(GoodsNO，ManagerNO)

关系SM中的唯一非主属性是SNUM，它是完全依赖于候选码的，且不传递依赖于候选码。因此SM是符合第三范式的。

但SM关系仍然存在很多问题：

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

原因：3NF没有限制主属性对码的依赖关系，因此在3NF中，可能存在主属性的部分函数依赖和传递函数依赖，从而导致操作异常。

BC范式

定义

• 关系模式是1NF，如果对于R的每个函数依赖X→Y，若Y不属于X时X必含有候选码，则称R为BC范式，简称BCNF，记作R∈BCNF。
• BCNF的定义可以这样理解：如果关系R为1NF，并且R中不存在任何属性对码的部分依赖或传递依赖，那么称R为BCNF。

BCNF的关系模式具有以下特性：

• 所有的非主属性对每一个码都是完全函数依赖。
• 所有的主属性对每一个不包含它的码，也是完全函数依赖
• 没有任何属性完全函数依赖于非码的任何一组属性

3NF向BCNF的转换

3NF和BCNF之间的区别在于，对一个函数依赖X→Y，3NF允许Y是主属性，而X不为候选码。但BCNF要求X必为候选码。因此BCNF的限制比3NF更严格，3NF不一定是BCNF，而BCNF一定是3NF。

要将3NF关系向BCNF关系转换就是要消除主属性对码的部分和传递函数依赖。

【例】校园超市数据库中有一个记录仓库商品管理的关系模式SM（GoodsNO，StorageNO，ManagerNO，SNUM），各属性分别是商品编码，仓库编码，仓库管理员编码，商品的存放数量；现有语义规定：一个管理员只在一个仓库工作；一个仓库只有一个管理员管理；一个仓库可以存储多种商品，一种商品可以存放在不同仓库；每种商品在一个仓库存放有一个存放数量。

结合现实世界的已知事实，可以分析得到SM的属性组上有如下函数依赖:

• StorageNO→ManagerNO
• ManagerNO→StorageNO
• (GoodsNO，StorageNO)→SNUM
• (GoodsNO，StorageNO)→ManagerNO
• (GoodsNO，ManagerNO)→StorageNO
• (GoodsNO，ManagerNO)→SNUM

SM的候选码有两个：(GoodsNO，StorageNO)和(GoodsNO，ManagerNO)

• 关系SM中的唯一非主属性是SNUM，它是完全依赖于候选码的，且不传递依赖于候选码。因此SM是符合第三范式的。
• 但SM存在主属性ManagerNO和StorageNO对码的部分函数依赖。不符合BC范式的要求。
• 为了消除主属性对码的部分函数依赖，分解SM为两个关系模式：
  • SM1(GoodsNO，StorageNO，SNUM)
  • SM2(StorageNO，ManagerNO)
• SM1的候选码是(GoodsNO，StorageNO)，SM2的候选码是StorageNO或者ManagerNO。SM1和SM2都满足BC范式要求。

问题

在函数依赖范畴，BCNF的关系模式规范化程度已经是最高了。但如果考虑其他数据依赖，那么属于BCNF的关系模式仍然存在问题，不能算是一个完美的关系模式。

【例】校园超市有一仓库商品管理的关系模式WMG(W，M，G)，其中W表示仓库，M表示仓库管理员，G表示商品。假设每个仓库有若干个仓库管理员，有若干种商品。每个仓库管理员管理多个仓库的多种商品，每种商品可以存放在多个仓库。

• 关系模式W M G 的码是（ W ， M ， G ） ， 即全码， 因而WMG∈BCNF。
• 但WMG关系仍然存在很多问题：
  • 数据冗余
  • 更新异常
  • 插入异常
  • 删除异常
• 原因：在WMG的属性间存在一种有别于函数依赖的依赖关系，它具有如下特点：
  • 对于一个W值，如W1，会有一组M值与之对应，如：M1，M2与之对应。
  • 仓库与仓库管理员的对应关系，与商品的取值无关。

多值依赖

• 设R(U)是一个属性集U上的一个关系模式， X、Y和Z是U的子集，并且Z＝U－X－Y，多值依赖 X→→Y成立当且仅当对R的任一关系r，r在（X，Z）上的每个值对应一组Y的值，这组值仅仅决定于X值而与Z值无关。
• 若X→→Y，而Z＝φ，则称X→→Y为平凡的多值依赖，否则称X→→Y为非平凡的多值依赖。
• 在关系模式WMG中，很显然存在着非平凡的多值依赖，即W→→M，W→→G。

多值依赖与函数依赖相比，具有下面两个基本的区别：

• 若函数依赖X→Y在R（U）上成立，则对于任何Y’⊂Y均有X→Y’成立；而多值依赖X→→Y若在R（U）上成立，我们却不能断言对于任何Y’⊂Y有X→→Y’成立。
• 在关系模式R（U）中函数依赖X→Y的有效性仅决定于X，Y这两个属性集的值。但是多值依赖的有效性与属性集的范围有关。

第四范式

定义

• 关系模式R<U，F>∈1NF，如果对于R的每个非平凡多值依赖X→→Y（Y⊆X），X都含有候选码，则称R为第四范式，简称4NF，记作R∈4NF。
• 4NF限制了关系模式的属性之间不允许有非平凡且非函数依赖的多值依赖。一个关系模式若属于4NF，则必然属于BCNF。

BCNF向4NF的转换

BCNF向4NF转换就是要消除非平凡且非函数依赖的多值依赖，以减少数据冗余，即将BCNF关系分解成多个4NF关系模式。

在WMG中，W→→M，W→→G，它们都是非平凡的多值依赖。而关系模式WMG的码是全码，即码为（W，M，G）。W不是码，对照4NF的定义WMG∉ 4NF。

采用分解的方法消去非平凡且非函数依赖的多值依赖。把WMG分解两个关系模式：

• WM（W，M）
• WG（W，G）

在WM中虽然有W→→M，但这是平凡的多值依赖，且都不是函数依赖。WM中已不存在非平凡且非函数依赖的多值依赖。所以WM∈4NF，同理WG∈4NF。

规范化小结

规范化步骤

• 1NF经消除非主属性对码的部分函数依赖后为2NF。
• 2NF经消除非主属性对码的传递函数依赖后为3NF。
• 3NF经消除主属性对码的部分和传递函数依赖后为BCNF。
• BCNF经消除非平凡且非函数依赖的多值依赖后为4NF。

规范化思想

• 消除不合适的数据依赖，采用“一事一地”的模式设计原则；
• 各关系模式达到某种程度的“分离”，实现概念的单一化
• 关系模式的规范化结果并不是唯一的，在设计数据库模式结构时，必须对现实世界的实际情况和用户应用需求作进一步分析，确定一个合适的、能够反映现实世界的模式
• 不能说规范化程度越高的关系模式就越好，要根据实际情况确定；前面的规范化步骤可以在其中任何一步终止。