数据库系统概念笔记——第八章：关系数据库设计

第八章：关系数据库设计

这一章比较难，学得不是很好，有些内容需要期末再补充

8.1 好的关系设计的特点

8.1.1 设计选择：更大的模式

在课本的示例中中，我们考虑将instructor表和department表合并为一个更大的表，起名为inst_dept

在合成这张新表后，似乎有好处，比如某些查询可以使用更少的连接来表达

但合成完后的表也有弊端，比如对每个系的教师，必须重复一遍系得信息（building,budget）
如果用原先的两张表，那么对于每个预算数额只存储一遍。
这说明合并后的inst_dept表并不好，因为它重复存储了预算，并且要承担某些用户可能更新一条元组而不是所有元组的预算数额，这样会产生数据不一致

这个合并后的关系还有其它的问题，比如出现一个没有教师的系时，会插入空值信息，等等

8.1.2 设计选择：更小的模式

假设从之前的大模式inst_dept表开始，我们是如何指定它要分成instructor表和department表的呢？

我们发现，在合并后的大模式中，budget会出现重复，存在数据冗余
换句话说，存在一个规则，如果存在dept_name->budget的函数一路来关系，那么这张表就存在问题，由于dept_name不是主码，因此budget会出现重复，重复即冗余

因此由于存在这个函数依赖，需要将这张表拆成instructor和department两张表

对于很多数据库而言，由于有大量属性和多个函数依赖，找到正确的分解要难得多，因此为了处理这种情况，需要后面的规范方法

注意并不是所有的分解都是有益的

比如将employee分解为以下两个模式


当分解为这两张表后，如果出现员工重名的情况，那么这两张表做自然连接的结果就和原始数据不一样了，会出现信息不一致的问题，因此这种分解是不可取的

上面的这种分解称为有损分解。反之，如果分解后的数据仍然一致，则称为无损分解

8.2 原子域和第一范式

如果一个域被认为是不可再分的单元，那么这个域是原子的

如果一个关系模式R的所有属性都是原子的，那么这个关系模式R属于第一范式（1NF）

注意要对这个原子性有正确的理解，具体的例子课本里有

8.3 使用函数依赖进行分解

首先明确，我们学习和使用函数依赖的目的是什么？

利用函数依赖，可以对现有关系进行分解，所以，函数依赖的本质作用是对现有的冗余的关系模式进行分解

关于后续相关符号的介绍

8.3.1 码和函数依赖

在现实世界中，数据通常存在各种约束，而满足所有这种约束的实例，被称为合法实例

现实世界中的约束可以转换为数据库中的码（超码，候选码，主码）

回顾超码的定义

函数依赖的定义

从另一个角度来说，超码所反映的依赖关系是函数依赖的一个特例

也就是说，函数依赖可以用于表示不能用超码表现的约束

例：对于关系模式inst_dept

inst_dept(ID,name,salary,dept_name,building,budget)

在该模式中函数依赖dept_name->budget成立
属性对(ID,dept_name)构成inst_dept的一个超码

使用函数依赖的两种方式

• 判定关系的实例是否满足给定函数依赖集F
• 说明合法关系集上的约束。如果我们希望只考虑R上满足函数依赖集F的关系，我们说F在r®上成立

平凡函数依赖

F集合的闭包

8.3.2 Boyce-Codd范式

Boyce-Codd范式（BCNF）可以消除基于函数依赖发现的冗余

判定有函数依赖集F的关系模式R属于BCNF的条件是

两个条件满足一个即可

举例


不属于BCNF模式的关系模式分解的一般规则

8.3.3 BCNF和保持依赖

在第七章的关于大学数据库的E-R图中，一位学生只能有一位导师。假如我们将该关系模式做一个小小的改动，让一个学生可以有多个导师，但一个系最多只能有一个

修改后的E-R图如下

对于新的E-R图，之前的关系模式不变，但导出的dept_advisor模式变为

dept_advisor(s_ID,i_ID,dept_name)

则下面两个函数依赖在dept_advisor上成立

• i_ID->dept_name
• s_ID,dept_name->i_ID

注意dept_advisor不属于BCNF模式，如果按BCNF分解规则进行分解，会得到以下两张表

(s_ID,i_ID)
(i_ID,dept_name)

但是照这样分解之后，新的模式虽然满足BCNF，但却不满足我们要求的依赖关系

上面这种分解不是保持依赖的，由于常常希望保持依赖，需要考虑一种比BCNF更弱的范式，称为3NF

8.3.4 第三范式

第三范式的定义

注意任何满足BCNF的关系模式都满足3NF，所以BCNF是比3NF更严格的范式

8.3.5 更高的范式

注意BCNF分解不一定是完美的，也可能会出现问题，比如下面这个例子

因此解决这些问题需要多值依赖和更高的范式

8.4 函数依赖理论

8.4.1 函数依赖集的闭包

给定模式上的函数依赖F，我们就可以证明，某些其它的函数依赖在模式上也成立。我们称这些函数依赖被F“逻辑蕴含”。
在检验范式时，不能只考虑给定的函数依赖集，还需要考虑模式上成立的所有函数依赖

逻辑蕴含的定义

给定关系模式r ( R )，如果r ( R )的每一个满足F的实例也满足f，则R上的函数依赖f被r上的函数依赖集F逻辑蕴含

例子：

Armstrong公理

计算F+的算法

8.4.2 属性集的闭包

属性集闭包的概念

例子

8.4.3 正则覆盖

对于一个关系模式的函数依赖集F，每当用户在该关系上执行更新时，数据库系统必须确保此更新不破坏任何函数依赖

无关属性

如果去除函数依赖中的一个属性不改变该属性依赖集的闭包则称该属性是无关的

无关属性的形式化定义

正则覆盖的定义

计算正则覆盖的算法

求正则覆盖的例子

注意，在有些例子里，正则覆盖不止一个，可能有多个

8.4.4 无损分解

无损分解的定义

更通俗地说，无损分解地意思是，分解后两者作自然连接的结果与分解前相同

select * from
r1 natural join r2

与

select * from
r

得到的结果相同

对于二元分解，判断无损连接的方法

8.4.5 保持依赖

在分解后依然保持依赖，称为保持依赖

保持依赖的具体定义

8.5 分解算法

8.5.1 BCNF分解

1.判定一个关系模式是否属于BCNF的简化方式

2.BCNF分解算法

如果一个关系模式不属于BCNF，需要将其转换为BCNF，可以利用BCNF算法将其转换，算法的具体步骤如下

BCNF分解的例子

对于一个关系模式


使用算法不断迭代之后得到最终的分解结果

8.5.2 3NF分解

将模式转换为3NF无损分解且保持依赖的算法

8.5.4 BCNF和3NF的比较

关于数据库设计的两种范式：3NF和BCNF，3NF的一个优点是我们总可以在满足无损并保持依赖的前提下得到3NF设计。但3NF也有缺点，有时候需要用空值表示数据项间的某些可能有意义的联系

对于应用函数依赖的数据库的设计目标是

• BCNF
• 无损
• 保持依赖

由于不能总是满足这三个要求，因此不得不在BCNF和3NF两者间作选择

8.6 使用多值依赖的分解

多值依赖的部分不太重要，考试也不涉及，这里省略

二、PPT补充的内容

1.候选码求解理论

求解一个关系的候选码，是一个NP问题，但这里有一个相对简单的方法

对于给定的关系模式R(U,F)，可以将其属性分为4类

• L类：仅出现在F的函数依赖左部的属性
• R类：仅出现在F的函数依赖右部的属性
• N类：在F的函数依赖两边均未出现的属性
• LR类：在F的函数依赖两边均出现的属性

快速求解候选码的充分条件

例：设关系模式R(U,F)，U = {A，B，C，D}，F = {D->B，B->D，AD->B，AC->D}，求R的候选码

A、C是L类属性，AC必是R的一个候选码的成员，(AC)F+ = {ACDB}，所以AC是R的唯一候选码

推论

定理2

定理3

例题

推论

2.无损连接的判断——表格法

使用以下方法可以判断是否是无损连接


具体的示例在PPT上有

3. 第二范式（2NF）

什么关系属于第二范式呢？