第六章 关系数据理论（上）数据依赖+码+范式

---

6.0 示例

---

6.0.1 示例题干

• 学校开发一个学校教务的数据库,涉及的对象有:
    学生的学号(Sno)、所在系(Sdept)、系主任姓名(Mname)、课程号(Cno)和成绩(Grade)。
   

6.0.2 示例语义

• 语义:

1. 一个系有若干学生, 但一个学生只属于一个系;
2. 一个系只有一名主任;
3. 一个学生可以选修多门课程, 每门课程有若干学生选修;
4. 每个学生所学的每门课程都有一个成绩。

• 存储并管理这些信息
• 设计了一个关系模式：STUDENT(Sno ,Sdept, Mname,Cno,Grade)

 

6.0.3 示例表

示例 Student表

Sno	Sdept	Mname	Cno	Grade
S1	计算机系	张明	C1	95
S2	计算机系	张明	C1	90
S3	计算机系	张明	C1	88
S4	计算机系	张明	C1	70
S5	计算机系	张明	C1	78
: :	: :	: :	: :	: :

 
 

6.1 为什么学习关系数据理论

---

6.1.1 问题提出

6.1.1.1 什么是一个好的数据库逻辑设计

1. 关系数据库的基本概念
2. 关系模型
3. 关系数据库的标准语言
4. 关系数据库逻辑设计：针对一个具体问题,应如何构造一个适合于它的数据模
   式,即应该构造几个关系,每个关系由哪些属性组成等。

那么，什么是一个好的数据库逻辑设计？
 
 

6.1.1.2 什么是函数依赖

关系模式STUDENT(Sno ,Sdept, Mname,Cno,Grade)中存在的问题:

1. 数据冗余度太大,浪费存储空间
   如:系主任的姓名重复出现,重复次数与该系所有学生的所有课程成绩
   出现次数相同。
2. 更新异常(Update Anomalies)
   数据冗余 ,更新数据时,维护数据完整性代价大
   如果某系更换系主任,系统必须修改与该系学生有关的每一个元组
   
3. 插入异常(Insertion Anomalies),该插入的数据插不进去
   如果新成立一个软件工程系,还没有招生,我们就无法把这个系及其系主任的信息
   存入数据库。
   
4. 删除异常(Deletion Anomalies),不该删除的数据也删去了
   如果某个系的学生全部毕业了, 我们在删除该系学生信息的同时,把这个系及其系
   主任的信息也丢掉了。

由此可见，示例中的模式不是一个好的关系模式：好的模式不会发生插入异常、删除异常、更新异常、数据冗余应尽可能少。
问题的原因：由于模式中的某些数据依赖引起的。

解决方法: 把这个单一模式分成3个关系模式:
S(Sno,Sdept,Sno → Sdept);
SC(Sno,Cno,Grade,(Sno,Cno) → Grade);
DEPT(Sdept,Mname,Sdept→ Mname)
这3个模式不会发生插入异常、删除异常毛病;数据冗余得到控制。
 
再把观察、经验上升为理论:
用规范化理论改造关系模式,消除其中不合适的数据依赖。

 
 

6.2 数据依赖

 

6.2.0 关系模式的简化表示

---

6.2.0.1 关系模式的形式化定义

关系模式的形式化定义(2.1.2关系模式 P.41讲解过)
R(U, D, DOM, F)

• R:关系名,是符号化的元组语义
• U:该关系的属性集合
• D:属性组U中属性所来自的域
• DOM:属性向域的映象集合
• F:属性间数据的依赖关系集合

6.2.0.2 关系模式的简化表示

简化表示：R<U, F>
说明：将关系模式简化为一个三元组,影响数据库模式设计的主要是 U 和 F。当且仅当U上的一个关系 r 满足F时,r 称为关系模式R(U, F)的一个关系。

再看例子
关系模式 STUDENT<U,F>
U = { Sno,Sdept,Mname,Cno,Grade }
F ={ Sno→Sdept, Sdept→Mname, (Sno, Cno)→Grade}
STUDENT(Sno,Sdept,Mname,Cno,Grade, Sno→Sdept, Sdept→Mname, (Sno, Cno)→Grade)
关系模式 STUDENT<U,F>存在诸多问题 。

6.2.0.3 如何解决关系模式中存在的问题 – 规范化

规范化理论—找出关系模式中不合适的数据依赖,消除它们,可以在不同程度上解决插入异常、删除异常、更新异常和数据冗余问题。

 
 

6.2.1 数据依赖相关概念

---

6.2.1.0 数据依赖示例

STUDENT(Sno ,Sdept, Mname,Cno,Grade)
该关系模式的属性集合记为U：
  U ={ Sno, Sdept, Mname, Cno, Grade }
说明：

属性组U上的函数依赖集合,记为F:
  F ={ Sno→Sdept, Sdept→Mname, (Sno, Cno)→Grade}

6.2.1.1 数据依赖的定义

1. 数据依赖是完整性约束的一种表现形式
   1.1 限定属性取值范围（例如学生成绩必须在0-100之间）
   1.2 定义属性值间的相互关连(即通过属性间值的相等与否来描述，主要体现于值的相等与否)
   1.3 它是数据库模式设计的关键
2. 数据依赖是通过一个关系中属性间值的相等与否体现出来的数据间的相互关系
3. 数据依赖是现实世界属性间相互联系的抽象
4. 数据依赖是数据内在的性质
5. 数据依赖是语义的体现

 
 

6.2.1.2 数据依赖的主要类型

• 函数依赖(Functional Dependency,简记为FD)
• 多值依赖(Multivalued Dependency,简记为MVD)
• 连接依赖
• … …

这里，我们主要讲解下函数依赖。

 

6.2.1.3 数据依赖对关系模式的影响

  不合适的数据依赖,造成插入异常、删除异常、更新异常和数据冗余问题

 
 

6.2.3 函数依赖

---

6.2.3.1 函数依赖定义

设R(U)是一个属性集U上的关系模式，X和Y是U的子集。

  若对于R(U)的任意一个可能的关系r，r中不可能存在两个元组在X上的属性值相等， 而在Y上的属性值不等，即有一个X值就有一个确定的的Y值与之对应，则称“X函数确定Y”或“Y函数依赖于X”，记作X→Y。X称为这个函数依赖的决定属性组，也称为决定因素(Determinant)。换句话说，函数需要有输入输出，那么X就是输入，Y就是输出：

  X（属性1，属性2，...） → Y（属性a，属性b，...）

例: S (Sno, Sname, Ssex, Sage, Sdept)
 
F = {Sno→Sname，Sno→Ssex，… ，(Sno，Sname)→Sage，(Sno，Sname)→（Sage，Sdept)}
 
诸如此类的，都叫做函数依赖，不过，前两个叫做完全函数依赖，后面两个依赖叫做部分函数依赖。

 
 

6.2.3.2 确定函数依赖的方法

函数依赖不是指关系模式R的某个或某些关系实例r满足的约束条件,而是指R的所有关系实例r均要满足的约束条件。
 

• 函数依赖是语义范畴的概念，只能根据数据的语义来确定函数依赖。
    如Sname →Sno函数依赖只有在“学生不允许有重名”的条件下成立。
• 数据库设计者可以对现实世界作强制的规定。
    例如设计者可以强行规定不允许学生有重名,因而使函数依赖Sname →Sno,Sname →Ssex, Sname →Sage,Sname→Sdept成立。
• 函数依赖是指关系模式R在任何时刻的关系实例均要满足的约束条件。
    不是指某个或某些关系实例 r 满足的约束条件,而是指R的所有关系
  实例 r 均要满足的约束条件。

 
 

6.2.3.3 平凡函数依赖与非平凡函数依赖

取决于Y是否是X的子集

• X→Y，Y⊈X，则称X→Y是非平凡的函数依赖。
• X→Y，但Y⊆X，则称X→Y是平凡的函数依赖。

例：在关系SC(Sno, Cno, Grade)中：
 
  非平凡函数依赖: (Sno, Cno) → Grade
 
  平凡函数依赖：(Sno, Cno) → Sno
         (Sno, Cno) → Cno

 
 

6.2.3.4 完全函数依赖与部分函数依赖

完全/部分 ： 取决于X中是否包含冗余属性
 
如下：这里，不需要Cno就能确定Sdept，也就是在这个函数依赖中，Cno是冗余属性

 
 

6.2.3.5 传递函数依赖

例：

 
 

 
 

6.3 码的分类

---

6.3.0 主属性与非主属性

• 主属性：包含在任何一个候选码中的属性 ,称为主属性(Prime attribute)
• 非主属性：不包含在任何码中的属性称为非主属性(Nonprime attribute)或非码属性(Non-key attribute)**

[例]

• S(Sno, Sdept, Sage)：Sno是码， Sno是主属性， Sdept, Sage是非主属性。
• SC(Sno, Cno, Grade)：(Sno, Cno)是码，Sno，Cno是主属性， Grade是非主属性

 
 

6.3.1 候选码 & 超码 & 主码 & 全码 & 外码

设K为关系模式R<U,F>中的属性或属性组合。

• 候选码 / 码：若$K\stackrel{F}{\to }U$，则K称为R的一个候选码(Candidate Key)，简称码。
• 超码：如果U部分函数依赖于K，即$K\stackrel{P}{\to }U$，则K称为超码(Surpkey)。
     候选码是最小的超码,即K的任意一个真子集都不是候选码
  
• 主码：若关系模式R有多个候选码,则选定其中的一个做为主码(Primary key)。
  
• 全码：整个属性组是码,称为全码(All-key)
  
• 外码：关系模式 R<U,F>，U中属性或属性组X 并非 R的码，但 X 是另一个关系模式的码，则称 X 是R 的外部码(Foreign key)也称外码。
  

主码与外部码一起提供了表示关系间联系的手段

已知 关系模式 R<U,F>,
  U = {A,B,C,D,E,G}
  F = {AC→B,CB→D,A→BE,E→GC}
求关系R的候选码?

 
 

 
 

6.4 范式

---

6.4.1 范式的定义

• 范式是符合某一种级别的关系模式的集合
• 关系数据库中的关系必须满足一定的要求，满足不同程度要求的为不同范式

 
 

6.4.2 范式之间的关系

某一关系模式R为第n范式,可简记为R ∈ nNF。

$1NF\supset 2NF\supset 3NF\supset BCNF\supset 4NF\supset 5NF$

 
 

6.4.3 规范化基本概念

---

6.4.3.1 定义

  一个低一级范式的关系模式，通过模式分解(schema decomposition)可以转换为若干个高一级范式的关系模式的集合，这种过程就叫规范化(normalization)。

 
 

6.4.3.2 基本思想

• 逐步消除数据依赖中不合适的部分，使模式中的各关系模式达到某种程度的“分离”
• 采用“一事一地”的模式设计原则
  1. 让一个关系描述一个概念、一个实体或者实体间的一种联系。
  2. 若多于一个概念就把它“分离”出去。
• 规范化实质上是概念的单一化

 
 

6.4.3.3 关系模式规范化的基本步骤

 

 

6.4.3.4 规范化说明

1. 一个关系模式只要其分量都是不可分的数据项，它就是规范化的关系模式，但这只是最基本的规范化。
2. 规范化程度过低的关系模式不一定能够很好地描述现实世界，可能会存在插入异常、删除异常、修改复杂、数据冗余等问题，解决方法就是对其进行规范化，转换成高级范式。
3. 一个低一级范式的关系模式，通过模式分解可以转换为若干个高一级范式的关系模式集合，这种过程就叫关系模式的规范化。
4. 关系数据库的规范化理论是数据库逻辑设计的工具。

 
 
 
 

6.4.2 范式分类

---

6.4.2.1 第一范式

• 第一范式(1NF)：如果一个关系模式R的所有属性都是不可分的基本数据项,则R∈1NF
         第一范式是对关系模式的最起码的要求，不满足第一范式的数据库模式不能称为关系数据模式。
  

满足第一范式的关系模式并不一定是一个好的关系模式。
 
[例] 已知关系模式 S-L-C(Sno , Cno , Sdept, Sloc, Grade)，Sloc为学生住处，假设每个系的学生住在同一个楼。

 
 

6.4.2.2 第二范式

• 第二范式(2NF)：若关系模式R ∈ 1NF，并且每一个非主属性都完全函数依赖于R的码，则R∈2NF。

由前面可知，非主属性 Sdept 和 Sloc 部分函数依赖于码(Sno, Cno)。
那么根据定义可知：
  S-L-C(Sno , Cno , Sdept, Sloc, Grade) $\in$ 1NF
  S-L-C(Sno , Cno , Sdept, Sloc, Grade) $\notin$ 2NF
 
一个关系模式R不属于2NF,就会产生问题
例如S-L-C (第一范式) 存在的问题:

1. 插入异常
   假设Sno=2014102，Sdept=IS，Sloc=N的学生还未选课，因课程号是主属性，因此该学生的信息无法插入SLC
   
2. 删除异常
   假定2014104学生只选修了3号课程这一门课。现在因身体不适，他连3号课程也不选修了。因课程号是主属性，此操作将导致该整个元组的删
   除。这样，2014104学生信息都被删除了。
   
3. 数据冗余度大
   如果一个学生选修了8门课程，那么他的Sdept和Sloc值就要重复存储了8次。
   
4. 修改复杂
   例如学生转系，在修改此学生元组的Sdept值的同时，还可能需要修改住处(Sloc)。如果这个学生选修了K门课，则必须无遗漏地修改K个元组中全部Sdept、Sloc信息。
   

因此，SLC不是一个好的关系模式。

原因:
  SLC(Sno , Cno , Sdept, Sloc, Grade) 中 Sdept、 Sloc部分函数依赖于SLC的码(Sno, Cno)。

解决方法：
  采用投影分解法，把S-L-C分解为两个关系模式，消除这些部分函数依赖

结果说明：

1. 关系模式SC的码为(Sno, Cno)，关系模式S-L的码为Sno
2. 非主属性对码都是完全函数依赖。他们都是2NF。
3. 从而使上述四个问题得到了一定程度的解决。
   
   

• 由于学生选修课程的情况与学生的基本情况是分开存储在两个关系中的,在S-L关系中可以插入尚未选课的学生。
• 删除一个学生的所有选课记录,只是SC关系中没有关于该学生的记录了,S-L关系中关于该学生的记录不受影响。
• 不论一个学生选多少门课程,他的Sdept和Sloc值都只存储1次。这就大大降低了数据冗余
• 学生转系只需修改S-L关系中该学生元组的Sdept值和Sloc值,由于Sdept、 Sloc并未重复存储,因此减化了修改操作。

 
 

6.4.2.3 第三范式

• 第三范式(3NF)：关系模式R<U,F>∈1NF,若R中不存在这样的码X、属性组Y及非主属性Z (Y⊇ Z)，使得X→Y、Y→Z、Y↛X成立，则称R<U,F> ∈ 3NF。

3NF的一些性质:

1. 若R∈3NF，则R的每一个非主属性既不部分函数依赖于候选码也不传递函数依赖于候选码。
2. 如果R∈3NF，则 R∈2NF。
3. 采用投影分解法将一个2NF的关系分解为多个3NF的关系，可以在一定程度上解决原2NF关系中存在的插入异常、删除异常、数据冗余度大、修改复杂等问题。
4. 将一个2NF关系分解为多个3NF的关系后，并不能完全消除关系模式中的各种异常情况和数据冗余。

2NF还有什么问题? ==> 为什么需要第三范式？

• 采用投影分解法,把S-L-C分解为两个关系模式：
    S-C和S-L,消除了S-L-C中非主属性对码的部分函数依赖。
• 一般地,如果把1NF关系模式 通过投影分解方法,消除非主属性对码的部分函数依赖,分解为多个2NF的关系模式。
• 可以在一定程度上减轻 原1NF关系模式中存在的插入异常、删除异常、数据冗余度大、修改复杂等问题。
• 但是还不能完全消除关系模式中的各种异常情况和数据冗余
   

---

【例】2NF关系模式S-L(Sno, Sdept, Sloc)中

Sloc传递函数依赖于Sno,即S-L中存在非主属性对码的传递函数依赖$Sno\stackrel{传递}{\to }Sloc$ 。
S-L关系存在的问题:

1. 插入异常
   如果某个系因种种原因(例如刚刚成立)，目前暂时没有在校学生，我们就无法把这个系的信息，如MA， S，存入数据库。
   
2. 删除异常
   如果某个系(如IS)的学生全部毕业了，我们在删除该系学生信息的同时，把这个系的信息，如IS， N，也丢掉了。
   
3. 数据冗余度大
   每一个系的学生都住在同一个地方，关于系的住处的信息却重复出现，重复次数与该系学生人数相同。
   
4. 修改复杂
   学校调整学生住处时，由于关于每个系的住处信息是重复存储的，修改时必须同时更新该系所有学生的Sloc属性值。
   

所以，S-L仍不是一个好的关系模式。
原因＆解决方法

说明：
  S-D的码为Sno, D-L的码为Sdept。异常的情况得到改善:

1. D-L关系中可以插入系的信息，即使还没有在校学生。
2. 某个系的学生全部毕业了，只是删除S-D关系中的相应元组，D-L关系中关于该系的信息仍存在。
3. 关于系的住处的信息只在D-L关系中存储一次。
4. 当学校调整某个系的学生住处时,只需修改D-L关系中一个元组的Sloc属性值。
    

在分解后的关系模式中既没有非主属性对码的部分函数依赖，也没有非主属性对码的传递函数依赖，进一步解决了上述四个问题。

 
 

6.4.2.4 BC范式

BCNF，Boyce和Codd共同提出的范式，扩展的第三范式

• BC范式：设关系模式R<U,F> ∈ 1NF，如果对于R的每个函数依赖X→Y，且X ⊇ Y时，X必含有码，那么R ∈ BCNF。即，在关系模式R<U,F>中，如果每一个决定因素都包含码，则R∈BCNF。

例如：
  STJ(S,T,J)∈ 3NF   T→J ,(S,J)→T, (S,T)→J
  SJ(S,J)∈ BCNF    SJ的码为(S,J), all-key
  TJ(T,J)∈ BCNF   TJ的码为T, T→J

BCNF的关系模式所具有的性质

1. 所有非主属性对每一个码都是完全函数依赖。
2. 所有主属性对每一个不包含它的码也是完全函数依赖。
3. 没有任何属性完全函数依赖于非码的任何一组属性。
4. 如果关系模式R∈BCNF，必定有R∈3NF(证明略)
5. 如果关系模式R∈3NF，不一定有 R∈BCNF(举一个例子说明)
6. 如果一个关系数据库中的所有关系模式都属于BCNF，那么在函数依赖范畴内，它已实现了模式的彻底分解，达到了最高的规范化程度，消除了操作异常诸多问题。

3NF还有什么问题? ==> 为什么需要BC范式？
 
【例】

 
存在以下异常：

1. 插入异常
   如果某个教师开设了某门课程,但尚未有学生选修,则有关信息也无法存入数据
   库中。
2. 删除异常
   如果选修过某门课程的学生全部毕业了,在删除这些学生元组的同时,相应教师
   开设该门课程的信息也同时丢掉了。
3. 数据冗余度大
   虽然一个教师只教一门课,但每个选修该教师该门课程的学生元组都要记录这一
   信息。
4. 修改复杂
   某个教师开设的某门课程改名后,所有选修了该教师该门课程的学生元组都要进
   行相应修改。
    

可见，虽然 STJ(S,T,J) ∈ 3NF ，但它仍存在增删改等异常，还不是一个理想的关系模式
原因 & 解决方法

说明

在分解后的关系模式中，没有任何属性对码的 部分函数依赖和传递函数依赖。它解决了上述四个问题：

1. TJ关系中可以存储所开课程尚未有学生选修的教师信息。
2. 选修过某门课程的学生全部毕业了，只是删除SJ关系中的相应元组，不会影响TJ关系中相应教师开设该门课程的信息。
3. 关于每个教师开设课程的信息只在TJ关系中存储一次。
4. 某个教师开设的某门课程改名后，只需修改TJ关系中的一个相应元组即可。

 
 

6.4.2.5 第四范式

• 第四范式(4NF)：参考DBMS第四范式（4NF）
   
   

6.4.2.6 第五范式

• 第五范式(5NF)：参考DBMS第五范式（5NF）

 
 

 
 

思考题

1. 举例例子说明属于3NF的关系模式有的属于BCNF,但有的不属于BCNF。

2. 在关系数据库中,任意一个二元关系模式R至少可以达到第几范式?(指在函数依赖的范畴内,可达到的最高范式)

3. 如果一个关系模式R的主码是全码,则R至少可以达到第几范式?
    
   至少可以达到第三范式，最高能达到BC范式：关系模式中若属性都是主属性，则不会存在非主属性对码的部分函数依赖，也不会存在非主属性对码的传递函数依赖，消除这两种分别代表达到第二范式和第三范式(这里的码指的是候选码)。若关系模式中全都是主属性，则至少是第三范式，若想达到BC范式，还要消除主属性对码的部分函数依赖和传递函数依赖。