cmu ssd7: database systems

73
CMU SSD7: Database Systems Lu Wei School of Software Northwestern Polytechnical University

Upload: acton-collins

Post on 03-Jan-2016

54 views

Category:

Documents


7 download

DESCRIPTION

CMU SSD7: Database Systems. Lu Wei School of Software Northwestern Polytechnical University. 3.3 关系数据理论. 第一节 问题的提出 第二节 规范化. 第一节 问题的提出. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: CMU SSD7:  Database Systems

CMU SSD7: Database Systems

Lu Wei

School of Software

Northwestern Polytechnical University

Page 2: CMU SSD7:  Database Systems

Lu Wei 2

3.3 关系数据理论

第一节 问题的提出第一节 问题的提出

第二节 规范化第二节 规范化

Page 3: CMU SSD7:  Database Systems

Lu Wei 3

第一节 问题的提出

前面我们已经讨论了关系数据库的基本概念、关系模型的三个部分以及关系数据库的标准语言,还学习了数据库设计的基本技术,能够构建基本的数据库 ER 模型。但是还有一个很基本的问题尚未涉及,针对一个具体问题,应该如何构造一个适合于它的数据库模式,即应该构造几个关系模式,每个关系由哪些属性组成等。这是数据库设计的问题,确切地讲是关系数据库逻辑设计问题。

Page 4: CMU SSD7:  Database Systems

Lu Wei 4

首先回顾一下关系模型的形式化定义 一个关系模式应当是一个五元组。

R ( U, D, DOM, F ) 其中, D 和 DOM 对模式设计关系不大,因此,在

本章讨论中把关系模式看作是一个三元组: R ( U, F ) 因此,本章的主要是围绕着属性和属性间的数据

依赖来讨论问题。

Page 5: CMU SSD7:  Database Systems

Lu Wei 5

第一个例子有一个关系模式 R ( TNAME , ADDRESS , C# , CN

AME ),分别表示教师姓名、教师地址、课程编号和课程名。

TNAME ADDRESS C# CNAME

T1 A1 C1 N1

T1 A1 C2 N2

T1 A1 C3 N3

T2 A2 C4 N4

T2 A2 C5 N2

T3 A3 C6 N4

Page 6: CMU SSD7:  Database Systems

Lu Wei 6

在使用过程中有以下几个问题:1 、数据冗余 如果一个教师教几门课程,那么这个教师的地址

就要重复几次存储;2 、修改异常

必须同时修改几个主键相同的元组的相关信息;

Page 7: CMU SSD7:  Database Systems

Lu Wei 7

3、插入异常

如果一门课程没有教师来教,则无法插入到数据库中去(缺少主关键字);

4、删除异常

如果删除一个教师的教学任务,同时也会删除教师信息。

Page 8: CMU SSD7:  Database Systems

Lu Wei 8

所以,关系模式 R的设计不是一个好的设计。如果我们用下面的两个关系模式来代替 R:

TNAME

ADDRESS

T1 A1

T2 A2

T3 A3

TNAME

C# CNAME

T1 C1 N1

T1 C2 N2

T1 C3 N3

T2 C4 N4

T2 C5 N2

T3 C6 N4R1 :教师信息 R2:课程教授信息

Page 9: CMU SSD7:  Database Systems

Lu Wei 9

在上例中模式 R ,为什么教师 T1 的地址会重复出现,因为 TNAME 和 ADDRESS 之间存在依赖关系。

函数依赖势必造成关系出现冗余现象,在 R 分解成R1 和 R2 后,消除了冗余和异常情况。

Page 10: CMU SSD7:  Database Systems

Lu Wei 10

第二个例子 数据库模式 S 〈 U , F 〉

U = { SNO , SDEPT , MN , CNAME , G }

F = {SNO→SDEPT , SDEPT→MN , (SNO , CNAME)→G}

SNO CNAME

SDEPT MN

G

Page 11: CMU SSD7:  Database Systems

Lu Wei 11

这个关系模式同样存在数据冗余、插入异常、修改异常和删除异常问题。

这是因为这个模式中的函数依赖存在某些不好的性质。假如我们把这个单一的模式改造一下 , 分成三个关系模式:

S 〈 SNO,SDEPT, SNO→SDEPT 〉; SG 〈 SNO,CNAME,G, (SNO,CNAME)→G 〉; DEPT 〈 SDEPT,MN, SDEPT→MN 〉;

Page 12: CMU SSD7:  Database Systems

Lu Wei 12

这三个模式都不会发生上述异常的毛病 , 数据的冗佘也得到了控制。

SNO CNAME

SDEPT

MN

G

SNO

SDEPT

Page 13: CMU SSD7:  Database Systems

Lu Wei 13

为什么上面的两个例子经过改造以后会变得比改造前好?还能不能继续改造?

或者说如何得到最优的关系模式?标准是什么?是我们下面要讨论的问题。

Page 14: CMU SSD7:  Database Systems

Lu Wei 14

第二节 规范化

• 1.1. 基本概念基本概念

• 2.2. 规范化规范化 ---- 范式范式

Page 15: CMU SSD7:  Database Systems

Lu Wei 15

1. 基本概念

1. 数据依赖 关系中属性值之间相互依赖又相互制约的联系称为数据依

赖。数据依赖主要有两种:函数依赖和多值依赖。2. 函数依赖 (Functional Dependency ,简记为 FD)

用 U 表示属性集的全集 {A1, A2, ... , An} ,设 R( U )是属性集 U 上的关系模式。 X , Y 是 U 的子集。若对于 R ( U )的所有具体关系 r 都满足如下约束:对于X 的每一个具体值, Y 有唯一的具体值与之对应,则称 Y函数依赖于 X ,或 X 函数决定 Y ,记作 XY , X 称作决定因素 (Determinant) 。

若 XY , YX ,则记作 X Y 若 Y 不函数依赖于 X ,则记作 XY

Page 16: CMU SSD7:  Database Systems

Lu Wei 16

如果 XY ,并且 Y 不是 X 的子集 (YX) ,则称 XY 是非平凡的函数依赖。如果 XY ,且 Y 是 X 的子集 (YX) ,则称 XY 是平凡的函数依赖。

根据函数依赖的定义,可以找出下面规律:① 在一个关系模式中,如果属性 X 、 Y 有 1 : 1 联系,则

存在函数依赖 X Y 、 Y X ,可记作 XY 。② 如果属性 X 、 Y 是 1 : m 的联系,则存在函数依赖 Y X ,但 X Y 。

③ 如果属性 X 、 Y 是 n : m 的联系,则 X 与 Y 之间不存在任何函数依赖。

Page 17: CMU SSD7:  Database Systems

Lu Wei 17

函数依赖是语义范畴的概念,只能根据语义来确定一个函数依赖。它是由数据库设计人员创建。

例子:对于一个学习关系模式 R( S#, SNAME, C#, GRADE, CNAME, TNAME, TAGE)中属性分别表示学生学号、姓名、课程号、成绩、课程名、任课教师姓名和年龄。

如果规定一个学号只能有一个学生姓名,一个课程号只能决定一门课程,那么可以有下列 FD形式:

S#→SNAME , C#→CNAME

( S#,C#)→ GRADE,C#→CNAME,TNAME,TAGE

Page 18: CMU SSD7:  Database Systems

Lu Wei 18

3. 完全函数依赖 设 X Y 是关系模式 R ( U )的一个函数依赖,

如果存在 X 的真子集 X‘ ,使得 X’ Y 成立,则称 Y 部分依赖于 X ,或 Y 对 X 部分函数依赖,记作 X Y 。否则,称 Y 完全依赖于 X ,或 Y对 X 完全函数依赖,记作 X Y 。

由定义可知,当 X 是单个属性时,由于 X 不存在任何真子集,如果 X Y ,则 X Y 。

Page 19: CMU SSD7:  Database Systems

Lu Wei 19

设有关系模式选课 SCl(S# , C# , GRADE ,CREDIT) 其中, S# 表示学号, C# 表示课程号,GRADE 表示成绩, CREDIT 表示学分。

S# 或 C# 都不能单独确定成绩 GRADE 。 GRADE 只能由属性组合 (S# , C#) 来确定。课程学分 CREDIT 是 C# 决定的, C# CREDIT 。由此可知:

(S# , C#) GRADE

(S# , C#) CREDIT

F

P

S#

C#

GRADE

CREDIT

Page 20: CMU SSD7:  Database Systems

Lu Wei 20

4. 传递依赖 在同一关系模式 R ( U )中,如果存在非平凡

函数依赖 X Y , Y Z 而 Y X ,则称 Z 传递依赖于 X ,或 Z 对 X 传递依赖。

定义强调 Y X 十分必要。如果 X 、 Y 互相依赖,实际上处于等价地位, X Z 则为直接函数依赖联系,并非传递依赖。

另外一种定义: 如果 X → Y , Y → Z ,且 Y → X 和 Z Y ,那

么称 X → Z 是传递依赖( Z 传递函数依赖于X )

Page 21: CMU SSD7:  Database Systems

Lu Wei 21

设关系模式 S1(S# , SNAME , D# , DNAME , LOCATION) 各属性分别代表学号、姓名、所在系、系地址。

存在函数依赖: S# D# , D# LOCATION ,根据传递依赖的定义,可知 S# LOCATION 是传递依赖。

实际上,部分依赖必然是传递依赖。如例 2 中 , SCl(S# , C# , GRADE , CEDIT) (S# , C#) C# , C# CREDIT ,形成传

递依赖 (S# , C#) CREDIT 。

Page 22: CMU SSD7:  Database Systems

Lu Wei 22

5. 码 设 K 为 R 〈 U , F 〉中的属性或属性组合,若 K U 则K 为 R 的候选码( Candidate key )。若候选码多于一个,则选定其中的一个为主码( Primary key )。

候选码两个属性:唯一标识性和无冗余性包含在任何一个候选码中的属性 , 叫做主属性 (Prime attribute) 。不包含在任何码中的属性称为非主属性 (Nonprime attribute) 或非码属性 (Non-key attribute) 。

最简单的情况 , 单个属性是码。最极端的情况 , 整个属性组是码 , 称为全码 (All-key) 。

Page 23: CMU SSD7:  Database Systems

Lu Wei 23

关系模式 R 中属性或属性组 X 并非 R 的码 , 但 X 是另一个关系模式的码 , 则称 X 是 R 的外部码 (Foreign key) 也称外码。 主码与外部码提供了一个表示关系间联系的手段。

Page 24: CMU SSD7:  Database Systems

Lu Wei 24

学生选课关系 SC(S# , C# , GRADE , CREDIT)中,属性组 (S# , C#) 是候选码,也是主码。 S# 、 C# 是主属性。 GRADE 、 CREDIT 是非主属性。

演唱关系 YC ( P , W , A ),属性 P 表示演奏者,W 表示作品, A 表示听众。假设一个演奏者可以演奏多个作品,某一作品可被多个演奏者演奏。听众也可以欣赏不同作品,这个关系模式的码为( P , W , A ),即全码。

Page 25: CMU SSD7:  Database Systems

Lu Wei 25

Armstrong 公理

逻辑蕴涵:对于满足一组函数依赖 F 的关系模式 R(U,F) ,其中任何一个关系 r ,若函数依赖 X→Y 都成立,则称 F逻辑蕴涵 X→Y 。

Armstrong 公理:设 U 为属性集总体, F 是 U 上的一组函数依赖,对于关系模式 R(U,F), 有一下推理规则:

A1 自反律:若YXU ,则X→Y 为 F 所蕴含

A2 增广律:若X→Y 为 F 所蕴含,且ZU ,则XZ→YZ为 F 所蕴含

A3 传递律:若X→Y 及Y→Z 为 F 所蕴含,则X→Z 为 F所蕴含

Page 26: CMU SSD7:  Database Systems

Lu Wei 26

公理推理规则:合并规则:若 X→Y , X→Z ,则 X→YZ 。伪传递规则:若 X→Y , WY→Z ,则 XW→Z 。分解规则:若 X→Y 且 ZY ,则 X→Z 。组合规则:若 A→B , C→D ,则 AC→BD 。

根据函数依赖以及 Armstrong 公理及推理确定一个关系的主键。(教材 278 页例 13.5 )

Page 27: CMU SSD7:  Database Systems

Lu Wei 27

F 的闭包:在关系模式 R(U,F) 中为 F 所逻辑蕴含的函数依赖的

全体叫做 F 的闭包,记为 F +。X 关于函数依赖集 F 的闭包:设 F 为属性集 U 上的一组函数依赖, XU , XF

= {A|X→A 能由 Armstrong 公理导出 } , XF+称

为属性集 X 关于函数依赖 F 的闭包。思考:求 XF

+算法等价:若 G += F + ,则 F 与 G 等价

Page 28: CMU SSD7:  Database Systems

Lu Wei 28

若函数依赖集 F 满足下列条件,则称 F 为一个极小函数依赖集或最小依赖集或最小覆盖。

( 1 ) F 中任一函数依赖的右部仅含有一个属性( 2 ) F 中不存在这样的函数依赖X→A ,使得 F-{X→A} 与F 等价

( 3 ) F 中不存在这样的函数依赖X→A ,X 有真子集Z使得(F-{X→A} )∪ {Z→A} 与F 等价

每个函数依赖集 F均等价与一个极小函数依赖 Fm。思考:求 Fm的算法

Page 29: CMU SSD7:  Database Systems

Lu Wei 29

例:关系模式 S(U,F) ,其中U={SNO,SDEPT,MN,CNAME,G}

F={SNO→SDEPT,SDEPT→MN, ,(SNO,CNAME)→G}

F’={SNO→SDEPT,SNO→MN,SDEPT→MN,(SNO,CNAME)→G,(SNO,SDEPT)→SDEPT}

其中 F 为极小覆盖,而 F’ 不是。F’-{SNO→MN} 与 F’ 等价。

判断极小依赖集和判断一个依赖集是否为极小依赖集的算法思想基本一致。

Page 30: CMU SSD7:  Database Systems

Lu Wei 30

2. 规范化 -- 范式

设计关系数据库时,关系模式不可以随意建立,它们必须满足一定的规范化要求。一个关系模式满足某一指定的约束,称此关系模式为特定范式的关系模式。

满足最低要求的叫第一范式 , 简称 lNF 。在第一范式中满足进一步要求的为第二范式 , 其余以此类推。

R 为第几范式就可以写成 R xNF∈

Page 31: CMU SSD7:  Database Systems

Lu Wei 31

我们将要讨论的各种范式之间的联系有5NF 4NF BCNF 3NF 2NF lNF

一个低一级范式的关系模式,通过模式分解转换为若干个高一 级范式的关系模式的集合,这种过程称为规范化。

1NF 3NF2NF 4NFBCNF 5NF

数据独立性数据独立性 低 高 低 高

Page 32: CMU SSD7:  Database Systems

Lu Wei 32

第一范式( 1NF )

定义 在关系模式 R 中的每一个具体关系 r 中,如果每个属性值都是不可再分的最小数据单位,则称 R 是第一范式( First Normal Form )的关系模式。记为 RlNF 。

不是 1NF 的关系称为非规范化的关系,满足 1NF 的关系称为规范化的关系。关系数据库研究的关系都是规范化的关系。因此,1NF 也是关系数据库中关系的最低要求。

Page 33: CMU SSD7:  Database Systems

Lu Wei 33

• 例 1

职工号 姓名 电话号码 1001 李明 701 2633(O)

714 6688(H) 1002 张敏 500 1287 1003 刘大维 253 3886(O)

204 6543(H) 1004 章良弟 567 8901 1005 何为民 504 7996

Page 34: CMU SSD7:  Database Systems

Lu Wei 34

将该表规范成 lNF 可以有三种方法:

第一种方法是重复存储职工号和姓名。

第二种方法是保留职工号的码的地位,把电话号码拆分成单位电话和住宅电话两个属性。

第三种方法是保留职工号的码的地位。维持原模式不变,但强制每个元组只能录入一个电话号码。

以上三种选择,第一种最不可取,后两种选择可根据应用需要确定一种。

Page 35: CMU SSD7:  Database Systems

Lu Wei 35

满足第一范式的关系是否还存在问题

例 2 :设有关系模式 SC(S# , C# , GRADE , CREDIT), 其中 CREDIT 表示学分。存在函数依赖: (S# , C#) GRADE , C# CREDIT ,候选码是(S# , C#) 。

S# C# GRADE CREDIT S1 C1 90 4 S1 C2 85 3 S1 C3 70 2 S2 C2 80 3 S2 C3 75 2 S2 C4 95 3 S3 C2 85 3

Page 36: CMU SSD7:  Database Systems

Lu Wei 36

该关系模式在实际使用中会出现下列问题:① 数据冗余。② 更新异常。③ 插入异常。④ 删除异常。 原因在于关系模式中的非主属性 CREDIT 函

数依赖于组合关键字 (S# , C#) 的一部分,而不是全部,即 (S# , C#) CREDIT 。

Page 37: CMU SSD7:  Database Systems

Lu Wei 37

第二范式( 2NF )

定义 若 R lNF,∈ 且每一个非主属性完全函数依赖于码 , 则 R 2NF∈ 。

上面例 2 中的关系模式 SC显然就不是 2NF ,因为它存在部分依赖 (S# , C#) CREDIT ,将上述非 2NF 的关系 SC 规范化为 2NF关系,应设法消除部分依赖

Page 38: CMU SSD7:  Database Systems

Lu Wei 38

通过投影把它分解为以下两个关系模式:

SCl(S# , C# , GRADE)

C2(C# , CREDIT)

新关系模型包括两个关系模式,它们之间通过SCl 中的外关键字 C# 相联系,需要时再自然联接,则恢复了原来的关系。

Page 39: CMU SSD7:  Database Systems

Lu Wei 39

例 3 关系模式 S-L-C(SNO,SDEPT,SLOC,CNO,G)

其中, SLOC 为学生的住处,并且每个系的学生住在同一个地方。

这个关系模式的码为( SNO,CNO ),函数依赖有 ( SNO,CNO ) G , SNO SDEPT

SNO SLOC,SDEPT SLOC

( SNO,CNO ) SDEPT

( SNO,CNO ) SLOC

如下图所示

F

P

P

Page 40: CMU SSD7:  Database Systems

Lu Wei 40

关系模式 S-L-C(SNO,SDEPT,SLOC,CNO,G) 不符合 2NF ,即 S-L-C 2NF∈

SDEPT

G

SLOC

SNO

CNO

Page 41: CMU SSD7:  Database Systems

Lu Wei 41

这个关系模式存在的问题:1.插入异常 例如,插入 SNO=7 , SDEPT=PHY , SLOC=BLD2 ,由于没有 CNO 值,所以无法插入

2.删除异常 假设 S4 只选修了一门课 C3 ,如果现在不选 C3 ,删除 C3

数据项时,由于 C3 是主属性,所以整个元组将删除, S4的其他信息都将被删除。

3.修改复杂 例如,修改某个学生的系时,本来只需要修改 SDEPT ,但SLOC 也必须跟着修改。

另外,如果学生选修了 K门课程, SDEPT,SLOC重复存储了 K次,不仅冗余度大,而且修改复

Page 42: CMU SSD7:  Database Systems

Lu Wei 42

分析上面的例 3 ,关系模式产生问题的主要原因在于,关系模式中存在非主属性对码的部分依赖,解决的办法是用投影分解把关系模式 S-L-C 分解为两个关系模式。

SC(SNO,CNO,G)

S-L(SNO,SDEPT,SLOC)

如下图所示

Page 43: CMU SSD7:  Database Systems

Lu Wei 43

G

SNO

CNO

SDEPT

SLOC

SNO

分解之后,关系模式 SC 的码为 (SNO,CNO), 关系模式 S-L 的码为 SNO ,这样就使得非主属性对码都是完全函数依赖了。

Page 44: CMU SSD7:  Database Systems

Lu Wei 44

满足第二范式的关系模式是否就没有问题了

例 4 关系模式 Sl(S# , SNAME , D# , DNAME ,LOCATION) ,关键字是 S# ,不存在部分依赖,属于 2NF 。但仍然存在大量冗余,关于系的重复值随着学生的增加而增加。在插入、删除或修改元组时也将产生类似例 3 的异常情况。

分析其原因,由于关系中存在传递依赖 S# LOCATION ,( S# D# , D# S# ,

D# LOCATION )。

Page 45: CMU SSD7:  Database Systems

Lu Wei 45

在例 3 中,我们通过把关系模式 S-L-C(SNO,SDEPT,SLOC,CNO,G)

分解为两个关系模式 SC(SNO,CNO,G)

S-L(SNO,SDEPT,SLOC)

从而使分解后的两个关系模式满足 2NF ,但是对于关系模式 S-L 是否还存在问题

Page 46: CMU SSD7:  Database Systems

Lu Wei 46

第三范式( 3NF )

定义 如果关系模式 R ( U , F )中若不存在这样的码 X ,属性组 Y 及非主属性组 Z(ZY) 使得 XY,(YX) YZ 成立,则 R( U , F ) 3NF 。

或者 如果关系模式 R ( U , F )中的所有非主

属性对码都不存在传递依赖(第二种定义),则称关系只是第三范式的。

如果 R 3NF∈ ,则 R 2NF∈

Page 47: CMU SSD7:  Database Systems

Lu Wei 47

上面的例 4显然就不满足 3NF ,因为它存在传递依赖 S#D# , D#S# , D#LOCATION ,我们通过将关系模式 S1 分解为两个关系模式

S(S# , SNAME , D#) D(D# , DNAME , LOCATION) 后,则这两个关系模式都满足 3NF

注意,投影时不能从关系 S 中遗漏外关键字 D# ,否则这两个关系之间将失去联系,就不能通过自然联接再恢复原来的关系了

Page 48: CMU SSD7:  Database Systems

Lu Wei 48

在例 3 中,我们通过把关系模式 S-L-C(SNO,SDEPT,SLOC,CNO,G)

分解后,得到两个满足 2NF 的关系模式 SC(SNO,CNO,G) S-L(SNO,SDEPT,SLOC) 其中,关系模式 S-L(SNO,SDEPT,SLOC)仍然不

满足 3NF ,刚才讨论过,这个关系模式还可能出现问题,因此可以继续分解为

S-D(SNO,SDEPT) D-L(SDEPT,SLOC) 从而使这两个关系模式满足 3NF

Page 49: CMU SSD7:  Database Systems

Lu Wei 49

部分函数依赖和传递函数依赖是产生存储异常的两个重要原因, 3NF 消除了大部分存储异常,具有较好的性能。

但 3NF并没有要求消除主属性对候选关键字的传递依赖,如果存在这种情况, 3NF 模式仍然可能发生存储异常现象。

Page 50: CMU SSD7:  Database Systems

Lu Wei 50

BCNF 范式

定义 关系模式 R ( U , F ) 1NF 。若 XY ,且YX ,则 X 必含有码,则 R ( U , F ) BCNF 。

或者 如果关系模式 R ( U , F )的所有属性都不传递

依赖于 R 的任何候选码,那么称关系 RBCNF 。

如果 RBCNF ,则 R3NF

Page 51: CMU SSD7:  Database Systems

Lu Wei 51

结论: 所有非主属性对每一个码都是完全函数依

赖 所有主属性对每一个不包含它的码,也是

完全函数依赖 没有任何属性完全函数依赖于非码的任何

一组属性

Page 52: CMU SSD7:  Database Systems

Lu Wei 52

例 4 关系模式 SJP(S,J,P) 中 ,S 是学生 ,J 表

示课程 ,P 表示名次。每一个学生选修每门课程的成绩有一定的名次 , 每门课程中每一名次只有一个学生(即没有并列名次)。由语义可得到下面的函数依赖:

(S,J)→P , (J,P)→S (S,J) 与 (J,P) 都可以作为候选码。 SJP3NF , SJPBCNF

Page 53: CMU SSD7:  Database Systems

Lu Wei 53

例 5 关系模式 STJ(S,T,J) 中 ,S 表示学生 ,T

表示教师 ,J 表示课程。每一教师只教一门课。每门课有若干教师 , 某一学生选定某门课 , 就对应一个固定的教师。由语义可得到如下的函数依赖。

(S,J)→T ; (S,T)→J ; T→J 。 这里 (S,J),(S,T) 都是候选码。 STJ3NF, STJBCNF

Page 54: CMU SSD7:  Database Systems

Lu Wei 54

3NF 的“不彻底”性表现在可能存在主属性对码的部分依赖和传递依赖。非 BCNF 的关系模式也可以通过分解成为 BCNF 。例如 STJ 可分解为 ST(S,T) 与 TJ ( T,J), 它们都是 BCNF 。

一个模式中的关系模式如果都属于 BCNF,那么在函数依赖范畴内 , 它已实现了彻底的分离 , 已消除了插入和删除的异常。

Page 55: CMU SSD7:  Database Systems

Lu Wei 55

关系满足第三范式却违反 BCNF 范式一般在下列情况下发生:

关系中包括两个或更多个复合候选关键字候选关键字有重叠属性

Page 56: CMU SSD7:  Database Systems

Lu Wei 56

可以将任何不符合 BCNF 范式的关系分解成符合 BCNF 范式的关系,但是在所有情况下都将一个关系转化为符合 BCNF 范式的关系并不一定是最佳选择。因为在对关系从 3NF 分解为 BCNF 时,有可能会丢失一些函数依赖。而且在分解后的关系种要满足原来的函数依赖是非常困难的。在这种情况下,最好只将关系规范到 3NF ,在 3NF 中,所有的函数依赖都会保留下来。

Page 57: CMU SSD7:  Database Systems

Lu Wei 57

考虑关系模式 ClientInterview(clientNo,interviewDate, interviewTime,staffNo,roomNo),该关系中,参与会谈的职员被分配到一个特定的房间进行会谈,一个房间在一个工作日内可能会被分配几次,一个客户在特定的日期只能参与一次会议,但可能在以后进行更进一步的会谈。

ClientInterview 有三个候选关键字 :(clientNo,interviewDate),(staffNo,interviewDate,interviewTime),(roomNo,interviewDate,interviewTime),这三个候选关键字都为符合候选关键字,并且有一个共同属

性 interviewDate

Page 58: CMU SSD7:  Database Systems

Lu Wei 58

选择 (clientNo,interviewDate) 作为该关系的主关键字,该关系上的函数依赖如下:

fd1: (clientNo,interviewDate)→interviewTime, staffNo, roomNo

fd2: (staffNo,interviewDate,interviewTime) →clientNo

fd3: (roomNo,interviewDate,interviewTime) → staffNo, clientNo

fd4: (staffNo,interviewDate)→ roomNo

Page 59: CMU SSD7:  Database Systems

Lu Wei 59

该关系属于第三范式,但是不属于 BCNF 范式,因为 fd4 的函数依赖决定方不是码。这个关系仍然会出现更新异常问题。例如更改职员 SG5 在 2002年 5月 13日进行会谈的房间号时,需要更新两个元组。

为了将该关系转化为 BCNF 范式,就必须消除关系中违背 BCNF 的函数依赖,将关系拆分为两个新的关系

Interview(clientNo,interviewDate,interviewTime,staffNo)

StaffRoom(staffNo,interviewDate,roomNo)

从而满足 BCNF 范式要求,但是丢失了函数依赖 fd3

Page 60: CMU SSD7:  Database Systems

Lu Wei 60

多值依赖

以上我们完全是在函数依赖的范畴内讨论问题。属于 BCNF 的关系模式是否就很完美了呢?

例 学校中某一门课程由多个教员讲授,他们使用相

同的一套参考书。每个教员可以讲授多门课程,每种参考书可以供多门课程使用。我们可以用一个非规范化的关系来表示教员 T, 课程 C 和参考书 B 之间的关系:

Page 61: CMU SSD7:  Database Systems

Lu Wei 61

课程 C    教员 T      参考书 B ------------------------------物理 李 勇 普通物理学 王 军 光学原理 物理习题集 ------------------------------数学 李 勇 数学分析 张 平 微分方程 高等代数

Page 62: CMU SSD7:  Database Systems

Lu Wei 62

课程 C 教员 T 参考书 B ------------------------ 物 理 李 勇 普通物理学 物 理 李 勇 光学原理 物 理 李 勇 物理习题集 物 理 王 军 普通物理学 物 理 王 军 光学原理 物 理 王 军 物理习题集 数 学 李 勇 数学分析 数 学 李 勇 微分方程 数 学 李 勇 高等代数 数 学 张 平 数学分析 数 学 张 平 微分方程 数 学 张 平 高等代数

Page 63: CMU SSD7:  Database Systems

Lu Wei 63

关系模型 TEACHING(C,T,B) 的码是 (C,T,B),即 A1l_Key 。 TEACHING BCNF∈ 。

问题: 当某一课程 ( 如物理 )增加一名讲课教员 ( 如周英 ) 时 , 必须插入多个元组: (物理 ,周英 ,普通物理学 ),(物理 ,周英 ,光学原理 ),(物理 ,周英 ,物理习题集 )

这个关系模式数据的冗余也十分明显,对数据的增删改很不方便

Page 64: CMU SSD7:  Database Systems

Lu Wei 64

多值依赖定义 设 R(U) 是属性集 U 上的一个关系模式。 X , Y , Z 是的U 的子集 ,并且 Z=U-X-Y 。关系模式 R(U) 中多值依赖X→→Y 成立,当且仅当对 R(U) 的任一关系 r,给定的一对(x , z) 值有一组 Y 的值,这组值仅仅决定于 x 值而与 z值无关。

在关系模式 TEACHING 中 , 对于一个 (物理 ,光学原理 )有一组 T 值 {李勇 ,王军 }, 这组值仅仅决定于课程 C 上的值 (物理 ) 。也就是说对于另一个 (物理 ,普通物理学 ) 它对应的一组 T 值仍是 {李勇 ,王军 },尽管这时参考书 B 的值已经改变了。因此 T 多值依赖于 C, 即 C→→T 。

Page 65: CMU SSD7:  Database Systems

Lu Wei 65

形式化定义 在 R(U) 的任一关系 r 中,如果存在元组 t,s 使得 t[X]=s[X], 那么就必然存在元组 w,v r∈ ( w,v 可以与 t,s相同),使得 W[X]=V[X]=T[X]=s[X] ,而 w[Y]=t[Y],w[Z]=s[Z],v[Y]=s[Y],v[Z]=t[Z], 则 Y 多值依赖于 X ,记作 X→→Y 。其中, X,Y 是 U 的子集 ,Z=U-X-Y 。

若 X→→Y ,而 Z= 即 Z 为空,则 X→→Y 为平凡的多值依赖。

Page 66: CMU SSD7:  Database Systems

Lu Wei 66

第四范式( 4NF )

定义 关系模式 R 〈 U,F 〉∈ lNF, 如果对于 R 的每个非平凡多值依赖 X→→Y (YX) , X 都含有码 , 则称 R 〈 U,F 〉 4NF 。

4NF限制关系模式的属性之间不允许有非平凡且非函数依赖的多值依赖。

如果 R4NF ,则 R BCNF 多值依赖的问题在于数据冗余太大。我们可以用投影分解的方法消去非平凡且非函数依赖的多值依赖

Page 67: CMU SSD7:  Database Systems

Lu Wei 67

例 关系模式 WSC(W,S,C) 中, W 表示仓库 ,S 表示保管员 ,C 表示商品。假设每个仓库有若干保管员,有若干商品;每个保管员保管所在仓库的所有商品,每种商品被所有保管员保管。

W S C W1 S1 C1 W1 S1 C2 W1 S1 C3 W1 S2 C1 W1 S2 C2 W1 S2 C3 ...

Page 68: CMU SSD7:  Database Systems

Lu Wei 68

其中有 W→→S, W→→C,他们都是非平凡的多值依赖,并且 W 不为码,因此,关系模式 WSC4NF ,但是 WSCBCNF ,对于 WSC 这个关系模式,数据冗余仍然比较大。

可以将关系模式 WSC 分解为两个关系模式 WS(W,S)

WC(W,C)

这样,在 WS 和 WC 中,虽然仍然存在多值依赖,但他们已经是平凡的多值依赖。 WS 和 WC 不存在非平凡的非函数依赖的多值依赖,因此, WS 和 WC 都为 4NF

Page 69: CMU SSD7:  Database Systems

Lu Wei 69

小结

函数依赖和多值依赖是两种最重要的数据依赖。 如果只考虑函数依赖,则属于 BCNF 的关系模式规

范化程度已最高了。 如果考虑多值依赖,则属于 4NF 的关系模式规范

化程度是最高的了。 当然,数据依赖中除了函数依赖和多值依赖,还

有其他数据依赖(例如,连接依赖)。 函数依赖是多值依赖的一种特殊情况,而多值依

赖又是连接依赖的一种特殊情况,满足 4NF 的关系模式经进一步改造,可以进一步达到 5NF 。

Page 70: CMU SSD7:  Database Systems

Lu Wei 70

规范化理论为数据库设计提供了理论的指南和工具,但是它仅仅是指南和工具。并不是规范化程度越高,模式就越好,必须结合实际情况合理选择应用数据库模式。

Page 71: CMU SSD7:  Database Systems

Lu Wei 71

无损连接依赖

Page 72: CMU SSD7:  Database Systems

Lu Wei 72

5NF

Page 73: CMU SSD7:  Database Systems

Lu Wei 73

模式的分解

无损连接性保持函数依赖性保持无损连接和函数依赖性