Transcript 中文PPT课件

第7章: 关系数据库设计
第7章: 关系数据库设计
 第一范式
 关系数据库设计中易犯的错误
 函数依赖
 分解
 Boyce - Codd 范式
 第三范式
 多值依赖与第四范式
 数据库设计全过程
Database System Concepts
7.2
©Silberschatz, Korth and Sudarshan
第一范式
 如果域中元素被认为是不可分的, 则域称为是原子的
 非原子域的例子:
 名字集合, 复合属性
 象CS101之类的标识号可以分成若干部分
 如果关系模式R的所有属性的域都是原子的, 则R称为属于第一范
式
 非原子值存储复杂并易导致数据冗余
 E.g. 每个客户的账户集合, 以及每个账户的拥有者集合
 我们假定所有关系都属于第一范式(参见第9章对象关系数据库)
Database System Concepts
7.3
©Silberschatz, Korth and Sudarshan
第一范式 (续)
 原子性实际上是关于如何使用域中元素的一种性质.
 E.g. 字符串通常认为是不可分的
 假设学生具有形如 CS0012 或 EE1127的字符串学号
 若前两个字符可作为系分解出来, 则学号域不是原子的.
 这样做很不好: 导致信息编码于应用程序中而不是数据库中.
Database System Concepts
7.4
©Silberschatz, Korth and Sudarshan
关系数据库设计中易犯的错误
 关系数据库设计要求我们找到一个 “好的” 关系模式集合.
一个坏的涉及可能导致
 信息的重复
 某些信息不能表示
 设计目标:
 避免冗余数据
 确保属性间联系得以表示
 方便检查更新是否破坏了数据库完整性约束
Database System Concepts
7.5
©Silberschatz, Korth and Sudarshan
例如
 考虑关系模式:
Lending-schema = (branch-name, branch-city, assets,
customer-name, loan-number, amount)
 冗余:
 branch-name, branch-city, assets 数据对某分行的每笔贷款都要重复一次
 浪费空间
 使修改操作复杂化, 可能导致assets 值的不一致
 空值
 不能存储没有贷款的分行信息
 可以使用空值, 但空值难于处理.
Database System Concepts
7.6
©Silberschatz, Korth and Sudarshan
分解
 将关系模式Lending-schema 分解成:
Branch-schema = (branch-name, branch-city,assets)
Loan-info-schema = (customer-name, loan-number,
branch-name, amount)
 原模式(R)的所有属性都必须出现在分解后的(R1, R2)中:
R = R1  R2
 无损连接分解
对模式R上的所有可能的关系r
r = R1 (r)
Database System Concepts
7.7
R2 (r)
©Silberschatz, Korth and Sudarshan
有损连接分解例
 分解R = (A, B)
R1 = (A)
A B
A
B





1
2
A(r)
B(r)
1
2
1
r
A (r)
Database System Concepts
R2 = (B)
B (r)
A
B




1
2
1
2
7.8
©Silberschatz, Korth and Sudarshan
目标 — 设计一个理论
 以判断关系模式R 是否 “好的” 形式
 当R 不是 “好的” 形式时, 将它分解成模式集合 {R1, R2, ..., Rn} 使得
 每个关系模式都是“好的” 形式
 分解是无损连接分解
 我们的理论基于:
 函数依赖
 多值依赖
Database System Concepts
7.9
©Silberschatz, Korth and Sudarshan
函数依赖
 对合法关系的约束
 要求一个属性集的值能唯一确定另一个属性集的值
 函数依赖是键概念的推广.
Database System Concepts
7.10
©Silberschatz, Korth and Sudarshan
函数依赖 (续)
 设R 是一关系模式, 且有属性集
R, R
 函数依赖

在R上成立 当且仅当对任意合法关系r(R), 若r 的任意两条元
组t1 和t2 在属性集上的值相同, 则他们在属性集 上的值也
相同. 即,
t1[] = t2 []  t1[ ] = t2 [ ]
 例如: 考虑 r(A,B) 及其下列实例r.
1
1
3
4
5
7
 对此实例, A  B 不成立, 但 B  A 成立.
Database System Concepts
7.11
©Silberschatz, Korth and Sudarshan
函数依赖 (续)
 K 是关系模式R 的超键当且仅当 K  R
 K 是R 的候选键当且仅当
 K  R, 并且
 没有  K 使  R
 函数依赖使我们可以表达用超键无法表达的约束. 考虑模式:
Loan-info-schema = (customer-name, loan-number,
branch-name, amount).
我们期望下列函数依赖成立:
loan-number  amount
loan-number  branch-name
而不期望下列函数依赖成立:
loan-number  customer-name
Database System Concepts
7.12
©Silberschatz, Korth and Sudarshan
函数依赖的使用
 我们用函数依赖来:
 检查关系在给定函数依赖之下是否合法.
 若关系r 在函数依赖集F 下是合法的, 则称r 满足F.
 对合法关系集合指定约束
 如果R 上的所有合法关系都满足F, 则称F 在R上成立.
 注意: 关系模式的特定实例可能满足一函数依赖, 但该函数依赖不是
在所有合法实例上成立. 例如, Loan-schema 的特定实例可能碰巧
满足
loan-number  customer-name.
Database System Concepts
7.13
©Silberschatz, Korth and Sudarshan
函数依赖 (续)
 被所有关系实例都满足的函数依赖称为平凡的
 例如
 customer-name, loan-number  customer-name
 customer-name  customer-name
 一般地,若    则    是平凡的
Database System Concepts
7.14
©Silberschatz, Korth and Sudarshan
函数依赖集的闭包
 给定函数依赖集F, 存在其他函数依赖被F 逻辑蕴含.
 例如: 如果 A  B 且 B  C, 则可推出 A  C
 被F 逻辑蕴含的全体函数依赖的集合称为F 的闭包.
 用F+ 表示F 的闭包.
 可利用Armstrong公理找出 F+ :
 若   , 则   
(自反)
 若   , 则     
(增广)
 若    且   , 则   
(传递)
 这些规则是
 正确的 (只产生确实成立的函数依赖)
 完备的 (产生所有成立的函数依赖).
Database System Concepts
7.15
©Silberschatz, Korth and Sudarshan
例如
 R = (A, B, C, G, H, I)
F={ AB
AC
CG  H
CG  I
B  H}
 F+ 的某些成员
 AH
 从A  B 和 B  H 根据传递规则
 AG  I
 用G增广A  C 得AG  CG, 再由CG  I 根据传递规则
 CG  HI
 由CG  H and CG  I : 可根据函数依赖的定义导出“并规则”, 或
 增广 CG  I 得到CG  CGI, 增广CG  H 得到CGI  HI, 再利用传
递规则
Database System Concepts
7.16
©Silberschatz, Korth and Sudarshan
计算F+
 下列过程计算函数依赖集F的闭包:
F+ = F
repeat
for each F+中的函数依赖 f
对f 应用自反和增广规则
将结果函数依赖加入F+
for each F+中的一对函数依赖f1 和f2
if 若 f1 和f2 可利用传递规则合并
then将结果函数依赖加入F+
until F+ 不再变化
注意: 后面会介绍完成此任务的另一过程
Database System Concepts
7.17
©Silberschatz, Korth and Sudarshan
函数依赖的闭包 (续)
 可用下列规则进一步简化F+ 的手工计算.
 若   与    成立, 则    成立 (合并)
 若    成立, 则   与   成立 (分解)
 若   与     成立, 则    h成立 (伪传递)
以上规则可以从Armstrong公理推出.
Database System Concepts
7.18
©Silberschatz, Korth and Sudarshan
属性集的闭包
 给定属性集合 , 定义 在F 下的闭包 (记做+) 为被 在F 下函数
决定的属性的集合:
   is in F+    +
 计算+ 的算法
result := ;
while (result 有变化) do
for each    in F do
begin
if   result then result := result  
end
Database System Concepts
7.19
©Silberschatz, Korth and Sudarshan
属性集闭包例
 R = (A, B, C, G, H, I)
 F = {A  B
AC
CG  H
CG  I
B  H}
 (AG)+
1. result = AG
2. result = ABCG
(A  C and A  B)
3. result = ABCGH
(CG  H and CG  AGBC)
4. result = ABCGHI
(CG  I and CG  AGBCH)
 AG 是候选键么?
1. AG 是超键么?
1. AG  R?
2. 存在AG的子集是超键么?
1. A+  R?
2. G+  R?
Database System Concepts
7.20
©Silberschatz, Korth and Sudarshan
属性闭包的用法
属性闭包算法有多种用途:
 测试超键:
 为检测 是否超键, 可计算+ 并检查+ 是否包含R的所有属性
 测试函数依赖
 为检测函数依赖   是否成立(即属于F+), 只需检查是否  +.
 即, 可计算+, 并检查它是否包含.
 这个检查简单而高效, 非常有用
 计算F的闭包
 对每个   R, 计算 +, 再对每个S  +, 输出函数依赖  S.
Database System Concepts
7.21
©Silberschatz, Korth and Sudarshan
正则覆盖
 函数依赖集合可能有冗余依赖(即他们能从其他函数依赖推出)
 例如: A  C 在 {A  B, B  C, A  C} 中是冗余的
 函数依赖的某部分可能是冗余的
 依赖右部: {A  B, B  C, A  CD} 可化简为
{A  B, B  C, A  D}
 依赖左部: {A  B, B  C, AC  D} 可化简为
{A  B, B  C, A  D}
 直观地说, F的正则覆盖是指与F等价的“极小的”函数依赖集合, 没
有冗余依赖, 依赖也没有冗余部分
Database System Concepts
7.22
©Silberschatz, Korth and Sudarshan
无关紧要的属性
 考虑函数依赖集合F 及其中的函数依赖  .
 如果A   并且F 逻辑蕴含 (F – {  })  {( – A)  }, 则称属
性A 在 中是无关紧要的.
 如果A   并且(F – {  })  { ( – A)} 逻辑蕴含F, 则称属性
A 在中是无关紧要的.
 注意: 上面两种情形中反方向的蕴含平凡成立, 因为 “较强的”函
数依赖总是蕴含较弱的函数依赖
 例如: 给定F = {A  C, AB  C }
 B 在AB  C 中是无关紧要的, 因为A  C 逻辑蕴含AB  C.
 例如: 给定 F = {A  C, AB  CD}
 C 在AB  CD 中是无关紧要的, 因为即使删除C 也能推出A  C
Database System Concepts
7.23
©Silberschatz, Korth and Sudarshan
检测属性是否无关紧要
 考虑函数依赖集合F 以及其中的函数依赖  .
 为检测属性A   在 中是否无关紧要
1. 计算在F 下的 ( – {A})+
2. 检查 (A – {})+ 是否包含; 如果是, 则A 是无关紧要的
 为检测属性A   在中是否无关紧要
1. 计算在F’ = (F – {  })  { ( – A)} 下的+
2. 检查 + 是否包含A; 如果是, 则A 是无关紧要的
Database System Concepts
7.24
©Silberschatz, Korth and Sudarshan
正则覆盖
 函数依赖集合F 的一个正则覆盖是满足下列条件的函数依赖集合Fc
 F 逻辑蕴含Fc 中的所有函数依赖
 Fc 逻辑蕴含F 中的所有函数依赖
 Fc 中的函数依赖不含无关紧要的属性
 Fc 中的函数依赖的左部都是唯一的
 计算F 的正则覆盖:
repeat
对F 中的依赖利用合并规则
1  1 和 1  1 替换成 1  1 2
找出含有无关紧要属性的函数依赖   (在 或 中)
如果找到无关紧要的属性, 从  中删去
until F 不再变化
 注: 删除某些无关紧要的属性之后,可能导致合并规则可应用, 所以必须重
新应用
Database System Concepts
7.25
©Silberschatz, Korth and Sudarshan
计算正则覆盖例
 R = (A, B, C)
F = {A  BC
BC
AB
AB  C}
 合并A  BC 及A  B 成A  BC
 集合变成 {A  BC, B  C, AB  C}
 A 在AB  C 中是无关紧要的, 因为B  C 逻辑蕴含AB  C.
 集合变成 {A  BC, B  C}
 C 在A  BC 中是无关紧要的, 因为A  BC 可由A  B 和B
 C逻辑推出.
 正则覆盖是:
AB
BC
Database System Concepts
7.26
©Silberschatz, Korth and Sudarshan
范式化的目标
 确定一个关系是否属于 “好的” 形式.
 如果关系R 不属于“好的”形式, 则将它分解为关系集合 {R1, R2, ...,
Rn} 使得
 每个关系都属于好的形式
 分解是无损连接分解
 范式化理论基于:
 函数依赖
 多值依赖
Database System Concepts
7.27
©Silberschatz, Korth and Sudarshan
分解
 将关系模式Lending-schema 分解成:
Branch-schema = (branch-name, branch-city,assets)
Loan-info-schema = (customer-name, loan-number,
branch-name, amount)
 原模式 (R) 的所有属性都必须出现在分解结果 (R1, R2)中:
R = R1  R2
 无损连接分解
对模式R上的所有可能关系r
r = R1 (r)
R2 (r)
 R 分解成R1 和R2 是无损连接的当且仅当下列依赖中的至少
一个属于F+:
 R1  R2  R1
 R1  R2  R2
Database System Concepts
7.28
©Silberschatz, Korth and Sudarshan
有损连接分解例
 有损连接分解导致信息丢失.
 例如: R = (A, B)分解成
R1 = (A)
A B
A
B





1
2
A(r)
B(r)
1
2
1
r
A (r)
Database System Concepts
R2 = (B)
B (r)
A
B




1
2
1
2
7.29
©Silberschatz, Korth and Sudarshan
利用函数依赖范式化
 当我们将具有函数依赖集合F 的关系模式R分解成R1, R2,
..., Rn 时, 我们希望
 无损连接分解: 否则分解导致信息丢失.
 无冗余: 关系Ri 最好属于Boyce-Codd 范式或第三范式.
 保持依赖: 令Fi 是F+ 中只包含Ri 中属性的依赖集合.
 分解最好保持依赖, 即 (F1
 F 2  …  F n )+ = F +
 否则检查更新是否破坏了函数依赖可能需要计算连接,代价较大.
Database System Concepts
7.30
©Silberschatz, Korth and Sudarshan
例
 R = (A, B, C)
F = {A  B, B  C)
 R1 = (A, B), R2 = (B, C)
 无损连接分解:
R1  R2 = {B} and B  BC
 依赖保持
 R1 = (A, B), R2 = (A, C)
 无损连接分解:
R1  R2 = {A} and A  AB
 不保持依赖
(不计算R1 R2 就不能检查 B  C)
Database System Concepts
7.31
©Silberschatz, Korth and Sudarshan
检查依赖保持
 为检查依赖  在R 到 R1, R2, …, Rn的分解中是否得到保持, 可进
行下面的简单测试 (设已计算了F下的属性闭包)
 result = 
while (result 有变化) do
for each 分解后的Ri
t = (result  Ri)+  Ri
result = result  t
 若result 包含中的所有属性, 则   得到保持.
 需要对F中所有依赖进行依赖保持的测试
 此算法需要多项式时间, 而计算F+ 和 (F1  F2  …  Fn)+需要指数
时间
Database System Concepts
7.32
©Silberschatz, Korth and Sudarshan
Boyce-Codd 范式
具有函数依赖集合F 的关系模式R 属于BCNF当且仅当对F+中所有函数依
赖  , 下列两条件至少一个成立:
  是平凡的 (i.e.,   )
 
 
是R的超键
Database System Concepts
7.33
©Silberschatz, Korth and Sudarshan
例
 R = (A, B, C)
F = {A  B
B  C}
键= {A}
 R 不属于BCNF
 分解成R1 = (A, B), R2 = (B, C)
 R1 与R2 属于BCNF
 无损连接分解
 保持依赖
Database System Concepts
7.34
©Silberschatz, Korth and Sudarshan
检查是否BCNF
 为检查非平凡依赖   是否违反BCNF的要求
1. 计算+,
2. 检验+是否包含R 的所有属性, 即, 是否R 的超键.
 简化的测试: 为检查具有函数依赖集合F的关系模式R 是否属于
BCNF, 只需检查F 中的依赖是否违反 BCNF即可, 而不需检查F+中
的所有依赖.
 可以证明如果F 中没有违反BCNF的依赖, 则F+中也没有违反BCNF的
依赖.
 但是, 当检查R的分解后的关系时仅用F是错误的
 例如: 考虑 R (A, B, C, D), 具有F = { A B, B C}
 分解 R 到R1(A,B) 与R2(A,C,D)
 F 中的依赖都不是只包含(A,C,D)中属性的, 因此我们可能错误地认
为R2 满足 BCNF.
 事实上, F+中的依赖A  C 显示R2 不属于BCNF.
Database System Concepts
7.35
©Silberschatz, Korth and Sudarshan
BCNF 分解算法
result := {R};
done := false;
compute F+;
while (not done) do
if (result 中存在模式Ri 不属于BCNF)
then begin
令   是Ri 上的一个非平凡函数依赖
使得  Ri 不属于F+, 且   = ;
result := (result – Ri)  (Ri – )  (,  );
end
else done := true;
注意: 每个Ri 都属于BCNF, 且分解是无损连接的.
Database System Concepts
7.36
©Silberschatz, Korth and Sudarshan
BCNF分解例
 R = (branch-name, branch-city, assets,
customer-name, loan-number, amount)
F = {branch-name  assets branch-city
loan-number  amount branch-name}
键 = {loan-number, customer-name}
 分解
 R1 = (branch-name, branch-city, assets)
 R2 = (branch-name, customer-name, loan-number, amount)
 R3 = (branch-name, loan-number, amount)
 R4 = (customer-name, loan-number)
 最终分解
R1, R3, R4
Database System Concepts
7.37
©Silberschatz, Korth and Sudarshan
检查分解是否属于BCNF
 为检查关系R 的分解结果Ri 是否属于BCNF,
 针对F在Ri上的限制 (即, F+中所有只包含Ri中属性的FD) 检查Ri 是否属
于BCNF
 或者: 使用R 的原始依赖集F, 但作如下测试:
– 对每个属性集   Ri, 检查+是否要么不包含Ri-  的属性, 要么
包含Ri 的所有属性.
 若该条件被某个 破坏, 则可证明依赖
  (+ -  )  Ri
在Ri 上成立, 且违反BCNF.
 利用上面的依赖分解Ri
Database System Concepts
7.38
©Silberschatz, Korth and Sudarshan
BCNF与依赖保持
BCNF分解不总是保持依赖的
 R = (J, K, L)
F = {JK  L
L  K}
两个候选键 = JK and JL
 R 不属于BCNF
 R 的任何分解都不会保持
JK  L
Database System Concepts
7.39
©Silberschatz, Korth and Sudarshan
第三范式: 动机
 存在这样的情况
 BCNF 不保持依赖, 并且
 有效地检查更新违反FD是重要的
 解决方法: 定义较弱的范式, 称为第三范式.
 允许出现一些冗余 (从而带来问题; 见后例)
 但FD可以在单个关系中得到检查, 不必计算连接.
 总是存在到3NF 的保持依赖的无损连接分解.
Database System Concepts
7.40
©Silberschatz, Korth and Sudarshan
第三范式
 关系模式R 属于第三范式 (3NF) 当且仅当对所有F+中依赖:

下列条件中至少一个成立:
    是平凡的 (i.e.,   )
  是R 的超键
  –  中的每个属性A 包含在R 的某个候选键中.
(注: 各属性可能包含在不同候选键中)
 若一个关系属于BCNF则必属于3NF (因为BCNF要求的正是上面
的前两个条件).
 第三个条件是对BCNF要求的最小的放宽, 以便保持依赖.
Database System Concepts
7.41
©Silberschatz, Korth and Sudarshan
3NF (续)
 例
 R = (J, K, L)
F = {JK  L, L  K}
 两个候选键 JK and JL
 R 属于3NF
JK  L
LK
JK 是超键
K 包含在一候选键中
 BCNF 分解导致 (JL) 和 (LK)
 检查JK  L 需要连接
 上面模式存在一些冗余
 等价于书上的例子:
Banker-schema = (branch-name, customer-name, banker-name)
banker-name  branch name
branch name customer-name  banker-name
Database System Concepts
7.42
©Silberschatz, Korth and Sudarshan
检查是否属于3NF
 优化: 只需检查F 中的FD, 而不必检查F+中的所有FD.
 对每个依赖  , 利用属性闭包来检查 是否超键.
 如果 不是超键, 必须检查中的每个属性是否包含在R的某个候选
键中
 这个检查较昂贵, 因为它涉及求候选键
 检查3NF是 NP-hard 的
 有趣的是, 分解到第三范式可以在多项式时间内完成
Database System Concepts
7.43
©Silberschatz, Korth and Sudarshan
3NF 分解算法
令Fc 是F 的正则覆盖;
i := 0;
for each Fc中的函数依赖   do
if 没有模式Rj (1  j  i) 包含  
then begin
i := i + 1;
Ri :=  
end
if 没有模式Rj (1  j  i) 包含R 的候选键
then begin
i := i + 1;
Ri := R 的任意候选键;
end
return (R1, R2, ..., Ri)
Database System Concepts
7.44
©Silberschatz, Korth and Sudarshan
3NF 分解算法(续)
 上述算法确保:
 每个关系模式Ri 属于3NF
 分解是保持依赖的和无损连接的
 正确性证明在本文件末尾 (click here)
Database System Concepts
7.45
©Silberschatz, Korth and Sudarshan
例
 关系模式:
Banker-info-schema = (branch-name, customer-name,
banker-name, office-number)
 本关系模式上的函数依赖包括:
banker-name  branch-name office-number
customer-name branch-name  banker-name
 键:
{customer-name, branch-name}
Database System Concepts
7.46
©Silberschatz, Korth and Sudarshan
对Banker-info-schema应用3NF
 算法中的for 循环使下列模式包含在分解中:
Banker-office-schema = (banker-name, branch-name,
office-number)
Banker-schema = (customer-name, branch-name,
banker-name)
 由于Banker-schema 包含Banker-info-schema的候选键, 分解
过程到此为止.
Database System Concepts
7.47
©Silberschatz, Korth and Sudarshan
BCNF与 3NF的比较
 总是可以将一个关系分解到3NF并且满足
 分解是无损的
 保持依赖
 总是可以将一个关系分解到BCNF并且满足
 分解是无损的
 但可能不保持依赖.
Database System Concepts
7.48
©Silberschatz, Korth and Sudarshan
BCNF与 3NF的比较 (续)
 因3NF的冗余引起的问题
 R = (J, K, L)
F = {JK  L, L  K}
J
L
K
j1
l1
k1
j2
l1
k1
j3
l1
k1
null
l2
k2
属于3NF但不属于 BCNF的模式有下面的问题
 信息重复 (e.g., 联系l1, k1)
 需要使用空值 (e.g., 表示联系l2, k2 , 这里没有对应的J 值).
Database System Concepts
7.49
©Silberschatz, Korth and Sudarshan
设计目标
 关系数据库设计的目标是:
 BCNF.
 无损连接.
 依赖保持.
 如果不能达到这些, 也可接受
 缺少依赖保持
 因3NF引起的冗余
 除了超键之外, SQL 并没有提供直接声明函数依赖的方法.
可以通过断言声明FD, 但检测代价大.
 因此即使我们有一个保持依赖的分解, 用SQL我们也不能有效地检
测左部不是键的函数依赖.
Database System Concepts
7.50
©Silberschatz, Korth and Sudarshan
跨关系检测FD
 如果分解不保持依赖, 我们可以为Fc中每个未被保持的依赖 
定义实视图
 实视图定义为分解关系的连接在 上的投影
 许多新一代数据库系统支持实视图, 并且数据库系统负责当关系更
新时对视图的维护.
 FD 成为实视图上的候选键.
 程序员没有额外的更新时维护冗余数据一致性的编码负担
 空间开销: 保存实视图
 时间开销: 当关系更新时需要维护实视图
Database System Concepts
7.51
©Silberschatz, Korth and Sudarshan
多值依赖
 有时属于BCNF的模式仍然未充分规范化
 考虑数据库
classes(course, teacher, book)
其中 (c,t,b)  classes 意思是教师t 可以教课程c, 而b 是需用于课
程c的教材
 数据库将为每门课程列出能讲授该课程的教师的集合, 以及需用的
书的集合(不管谁讲授该课).
Database System Concepts
7.52
©Silberschatz, Korth and Sudarshan
course
database
database
database
database
database
database
operating systems
operating systems
operating systems
operating systems
teacher
Avi
Avi
Hank
Hank
Sudarshan
Sudarshan
Avi
Avi
Jim
Jim
book
DB Concepts
Ullman
DB Concepts
Ullman
DB Concepts
Ullman
OS Concepts
Shaw
OS Concepts
Shaw
classes
 由于没有非平凡依赖, (course, teacher, book) 是唯一的键, 因此该
关系模式属于BCNF
 插入异常 – 如果Sara 是能教数据库的新教师, 必须插入两条元组
(database, Sara, DB Concepts)
(database, Sara, Ullman)
Database System Concepts
7.53
©Silberschatz, Korth and Sudarshan
 因此, 最好将classes 分解成:
course
teacher
database
Avi
database
Hank
database
Sudarshan
operating systems
Avi
operating systems
Jim
teaches
course
book
database
database
operating systems
operating systems
DB Concepts
Ullman
OS Concepts
Shaw
text
我们将看到这两个关系都属于第四范式 (4NF)
Database System Concepts
7.54
©Silberschatz, Korth and Sudarshan
多值依赖 (MVD)
 设有关系模式R, 令  R 及  R. 多值依赖
  
在R 上成立当且仅当在任意合法关系r(R)中, 对所有满足
t1[] = t2 []的元组对t1 和t2, 必存在元组t3 和t4 使得:
t1[] = t2 [] = t3 [] = t4 []
t3[]
= t1 []
t3[R –  – ] = t2[R –  – ]
t4[ ]
= t2[]
t4[R –  – ] = t1[R –  – ]
Database System Concepts
7.55
©Silberschatz, Korth and Sudarshan
MVD (续)
 用表来表示   
Database System Concepts
7.56
©Silberschatz, Korth and Sudarshan
例
 设关系模式R 的属性集合被分成三个非空子集
Y, Z, W
 称Y  Z (Y 多值决定Z)当且仅当对所有可能的关系r(R), 若
< y 1, z 1, w 1 >  r 及 < y 2, z 2, w 2 >  r
则
< y 1, z 1, w 2 >  r 及 < y 1, z 2, w 1 >  r
 注意由于Z和W 的行为完全对称, 若Y  W 则Y  Z
Database System Concepts
7.57
©Silberschatz, Korth and Sudarshan
例(续)
 在前面的例子中:
course  teacher
course  book
 上述形式定义表达了这种概念: 给定Y (course)的特定值,
则有一个Z (teacher)值的集合和一个W (book)值的集合与
之相关联, 而这两个集合在某种意义上是相互独立的.
 注: 若Y  Z 则 Y  Z
 事实上我们有(用前面的表示法) Z1 = Z2
所以此命题成立.
Database System Concepts
7.58
©Silberschatz, Korth and Sudarshan
多值依赖的用法
 有两种使用多值依赖的方法:
1. 检测关系以确定他们在给定函数依赖和多值依赖集合之下是否
合法
2. 对合法关系集合声明约束. 这样我们就只关心满足给定函数依
赖和多值依赖的关系.
 若关系r 不满足给定多值依赖, 我们可以通过增加元组来构造
满足该多值依赖的关系r.
Database System Concepts
7.59
©Silberschatz, Korth and Sudarshan
MVD理论
 根据多值依赖的定义, 可导出下列规则:
 若   , 则  
即函数依赖是多值依赖的特例

D的闭包D+ 是D 逻辑蕴含的所有函数依赖和多值依赖的集合.
 可根据函数依赖与多值依赖的形式定义来从D 计算 D+.
 我们只对在实践中较常见的简单多值依赖可用这样的推理
 对于复杂的依赖, 最好利用一套推理规则(见附录C)来对依赖集合进行
推理.
Database System Concepts
7.60
©Silberschatz, Korth and Sudarshan
第四范式
 关系模式R 关于函数依赖及多值依赖集合D 属于4NF 当且仅当对
D+中所有形如  的多值依赖, 其中  R 且  R, 下列条件
中至少一个成立:
    是平凡的 (i.e.,    或   = R)
  是模式R 的超键
 若关系属于4NF 则它必属于BCNF
Database System Concepts
7.61
©Silberschatz, Korth and Sudarshan
多值依赖的限制
 D在Ri 上的限制是指由下列组成的集合Di
 所有D+中只包含Ri 的属性的函数依赖
 所有形如
  (  Ri)
的多值依赖, 其中  Ri 且   属于D+
Database System Concepts
7.62
©Silberschatz, Korth and Sudarshan
4NF分解算法
result: = {R};
done := false;
compute D+;
令Di 表示D+ 在Ri 上的限制
while (not done)
if (在result 中有不属于4NF的模式Ri) then
begin
令   是在Ri 上成立的一个非平凡多值依赖, 它使得 
Ri 不属于Di, 并且    ;
result := (result - Ri)  (Ri - )  (, );
end
else done:= true;
注: 每个Ri 属于4NF, 且分解是无损连接的
Database System Concepts
7.63
©Silberschatz, Korth and Sudarshan
例
 R =(A, B, C, G, H, I)
F ={ A  B
B  HI
CG  H }
 R 不属于4NF, 因为A  B 且A 不是R 的超键
 分解
a) R1 = (A, B)
(R1 属于4NF)
b) R2 = (A, C, G, H, I)
(R2 不属于4NF)
c) R3 = (C, G, H)
(R3 属于4NF)
d) R4 = (A, C, G, I)
(R4不属于4NF)
 由于A  B 且B  HI, A  HI, A  I
e) R5 = (A, I)
(R5 属于4NF)
f)R6 = (A, C, G)
(R6 属于4NF)
Database System Concepts
7.64
©Silberschatz, Korth and Sudarshan
进一步的范式
 join dependencies generalize multivalued dependencies
 lead to project-join normal form (PJNF) (also called fifth normal
form)
 A class of even more general constraints, leads to a normal form
called domain-key normal form.
 Problem with these generalized constraints: i hard to reason
with, and no set of sound and complete set of inference rules.
 Hence rarely used
Database System Concepts
7.65
©Silberschatz, Korth and Sudarshan
数据库设计全过程
 假设给定了模式R
 R 可能是经转换E-R图到表而生成的.
 R 可能是单个包含所有属性的关系 (称为全关系).
 规范化将R 分解成较小的关系.
 R 可能是某种特定设计的结果, 然后再测试/转换成范式.
Database System Concepts
7.66
©Silberschatz, Korth and Sudarshan
ER模型与规范化
 当E-R图是很仔细地设计, 正确地标识所有实体, 则从E-R图生成的关系
应该不需要进一步的规范化.
 但是, 在现实 (不完善的) 设计中可能存在从实体的非键属性到其他属性
的FD
 例如: employee 实体具有属性 department-number 和department-
address, 以及FD department-number  department-address
 好的设计应该将department 作为实体
 从联系集的非键属性引出FD是可能的, 但极少 --- 多数联系是二元的
Database System Concepts
7.67
©Silberschatz, Korth and Sudarshan
全关系方法
 悬空元组 – 计算连接时 “消失”的元组.
 令r1 (R1), r2 (R2), …., rn (Rn) 是一个关系集合
 关系ri 的元组r 称为悬空元组, 如果r 不属于关系:
Ri (r1
r2
…
rn )
r2 … rn 称为全关系, 因为它包含了由下式定义的“属
性全集”中的所有属性
 关系r1
R1  R2  …  Rn
 如果数据库中允许出现悬空元组, 则我们可能宁愿从给定属性集合
合成若干范式化模式, 而不是分解全关系.
Database System Concepts
7.68
©Silberschatz, Korth and Sudarshan
全关系方法(续)
 悬空元组在实际数据库应用中可能出现.
 他们代表不完全的信息
 例如: 可能想将关于贷款的信息分解成:
(branch-name, loan-number)
(loan-number, amount)
(loan-number, customer-name)
 全关系需要用到空值, 并且具有悬空元组
Database System Concepts
7.69
©Silberschatz, Korth and Sudarshan
全关系方法 (续)
 特定分解定义了数据库中可接受的一个不完全信息的限制性形式.
 上例中至少需要customer-name, branch-name 或amount 之一以便输
入贷款号而不用空值
 排除没有适当loan-number 而存储customer-name, amount 的情况(
由于它是键, 不得为空!)
 唯一角色假设: 全关系要求每个属性名在数据库中具有唯一的意义
 e.g. customer-name, branch-name
 重用属性名在SQL中是很自然的, 因为关系名可作为前缀来避免名
字的歧义
Database System Concepts
7.70
©Silberschatz, Korth and Sudarshan
为性能而反规范化
 为提高性能可能使用非规范化的模式
 例如: 一道显示customer-name 与account-number 及balance 需将
account 和depositor 连接
 其他做法1: 使用包含account 以及depositor 的所有上述属性的反规
范化关系
 查找迅速
 额外空间以及额外更新执行时间
 程序员的额外编码工作以及更多出错可能性
 其他做法2: 使用如下定义的实视图
account
depositor
 优缺点同上, 除了程序员的额外编码工作和避免可能的错误
Database System Concepts
7.71
©Silberschatz, Korth and Sudarshan
其他设计问题
 有些数据库设计问题不能被规范化解决
 应避免的坏的数据库设计例:
不用earnings(company-id, year, amount), 而是用
 具有同样模式 (company-id, earnings) 的 earnings-2000, earnings2001, earnings-2002, 等等.
 这属于BCNF, 但使得跨年度查询很困难, 并且每年都需要新表
 company-year(company-id, earnings-2000, earnings-2001,
earnings-2002)
 也属于BCNF, 但同样使跨年度查询很困难, 并且每年都需要新表.
 这是一个crosstab的例子, 将属性值作为了列名
 可用于spreadsheets, 以及数据分析工具
Database System Concepts
7.72
©Silberschatz, Korth and Sudarshan
End of Chapter