数据库系统概念：关系数据库的设计

CH8 Relational Database Design

关系数据库设计目标：

生成一组关系模式，存储信息时避免不必要的冗余，可以方便的获取信息。
$$本章概览\{\begin{array}{l}基于函数依赖关系数据库设计的规范方法\\ 函数依赖+数据依赖->定义范式\end{array}$$

8.1 好的关系设计的特点

8.1.1 设计选择：更大的模式

用下面这个关系模式替代instructor和department 模式

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

表示instructor和department进行自然连接。

造成问题：

• 信息冗余
• 数据不一致风险
• 新增信息

8.1.2 设计选择：更小的模式

在模式inst_dept中，我们要能发现dept_name--->budget这样的规则，才能分解这个模式。

这条规则被定义为：函数依赖。

有employee模式：

employee(ID, name, street, city, salary);

分解成下面的两个模式：

employee1(ID, name);
employee2(name, street, city, salary);

假如有两个同名的员工，那么将两张表做笛卡尔乘积将会出现问题。

这样分解称为有损分解lossy decommposition。

8.2 原子域和第一范式

8.2.1.原子域

某些属性具有某种程度上的子结构。

创建表时对于多值属性和组合属性的处理：
$$\begin{gathered} 多值属性：一个实体可能有多个值——一个人的兴趣爱好 \\ 组合属性：家庭地址\{\begin{array}{l}street\\ city\\ state\\ ...\end{array} \end{gathered}$$

• 组合属性：我们要消除这种子结构，让每个子属性称为一个属性。
• 多值属性：为多值属性中的每个项创建一个元组。

关系模型中，将：属性不具有任何子结构这个思想形式化。

域是原子的：一个域是原子的，如果该域的元素被认为是不可分的单元。

非原子的例子：

• 一个属性是名字的集合。
• 组合属性的地址也具有非原子域。

8.2.2 第一范式

关系属于第一范式的定义：如果关系R的所有属性的域都是原子的，那么关系模式R属于第一范式。

两个例子：

（1）一个机构给雇员分配标识号，前两个字母表示系，剩下的四个数字是雇员在该系的唯一号码。比如CS0012。
这样的标识号可以分解为更小的单元，因此不是原子的

（2）大学数据库使用课程’cs-101’，CS表示计算机系。但是一个原则：只要数据库应用没有将标识号拆开，并且将标识号的一部分解析为系的缩写，那么他仍然视为原子的。

8.3 使用函数依赖进行分解

表示法概述：

• 希腊字母表示属性集，如$\alpha$
• 关系模式：$r(R)$。r表示关系名，R是属性集。不关心关系的名字时，常简化表示法只用R。
• 属性集是一个超码，使用K。

8.3.1 码和函数依赖

数据存在各种约束，比如学生和教师通过一个唯一的ID标识。

满足所有约束的实例，称为关系的合法实例。

约束可以形式化的表示为码——超码，候选码，主码，或者定义的函数依赖。

1.超码

超码是可以唯一标识关系中一条元组的一个或者多个属性的集合。

K是r®的超码：在关系r®的任意合法实例中，对于r的实例中的所有元组对t1和t2，如果t1≠t2，那么t1[K]≠t2[K]。

没有两条元组在属性集K上可以具有相同的值。

2.函数依赖

考虑一个关系模式$r(R)$，令$\alpha \subseteq R$且，$\beta \subseteq R$。

给定r®的一个实例，满足函数依赖$\alpha \to \beta$的条件是：

• 对实例中的所有元组对$t_1$和$t_2$，若$t_1[\alpha ]=t_2[\alpha ]$，那么$t_1[\beta ]=t_2[\beta ]$
• 如果所有合法实例都满足函数依赖$\alpha \to \beta$，那么该函数依赖在模式$r(R)$上成立。

使用函数依赖表示超码：

如果函数依赖$K\to R$，那么K是关系r®的一个超码。

属性对(ID, dept_name)构成超码的记录：
$$ID,dept\_name\to name,salary,building,budget$$

$$\begin{gathered} A\to C \\ 但是C不决定A \end{gathered}$$
使用函数依赖的方式：

• 判定关系的实例是否满足给定函数依赖集
• 说明合法关系集上的约束

3.平凡的trivial

平凡的：有些函数依赖在所有关系中都满足，则称之为平凡的。

例：
$$\begin{gathered} A\to A \\ AB\to A \end{gathered}$$
一般的，如果$\beta \subseteq \alpha$，那么$\alpha \to \beta$的函数依赖是平凡的。

4.函数依赖的闭包

给定关系r®上成立的函数依赖集F，有可能隐含了某些函数依赖也在该关系上成立：
$$\{\begin{array}{l}A\to B\\ B\to C\end{array}\Rightarrow A\to C$$
使用$F^{+}$来表示F集合的闭包，也就是能从给定的F集合推导出来的所有函数依赖。

$F^{+}$包含了F中的所有函数依赖。

8.3.2 第二范式

这里插入书上未作说明的第二范式

第二范式要满足的条件：

• 不含有不属于非主属性对码的部分依赖

部分函数范式：
$$\alpha ,\beta \in R，若\gamma 是关系的主码，且有\alpha \subseteq \gamma ，那么\alpha \to \beta 就是非主属性的函数依赖。$$
没有没有这种依赖即是满足第二范式。

所以说第二范式消除了部分的函数依赖。

8.3.3 Boyce-Codd范式

1.BCNF范式

Boyce-Codd范式即Boyee-Codd Normol Form, BCNF范式。

BCNF范式消除了所有能由函数依赖发现的冗余。

具有函数依赖集F的关系模式R属于BCNF范式的条件是，对于$F^{+}$中所有形如$\alpha \to \beta$的函数依赖（其中$\alpha \subseteq R$且$\beta \subseteq R$），下面至少有一项成立：

• $\alpha \to \beta$是一个平凡的函数依赖
• $\alpha$是模式R的一个超码

一个数据库属于BCNF范式的条件是：构成该设计的关系模式集中的每个模式都属于BCNF。

不属于BCNF范式的例子：
$$inst\_dept(ID,name,salary,dept\_name,building,budget)$$
函数依赖$dept\_name\to budget$在inst_dept上成立，但是dept_name不是超码。

2.BCNF模式规则

设R为不属于BCNF范式的一个模式，则至少存在一个非平凡的函数依赖$\alpha \to \beta$，其中$\alpha$不是R的超码。我们在设计中用一下两个模式取代R：

• $(\alpha \bigcup \beta )$
• $(R-(\beta -\alpha ))$

在inst_dept的例子中， α = d e p t _ n a m e , β = { b u i l d i n g , b u d g e t } \alpha = dept\_name,\beta = \{building, budget\} α=dept_name,β={building,budget}，且inst_dept被取代为：

• KaTeX parse error: Expected '}', got '_' at position 37: …) = (\text{dept_̲name,building,b…
• KaTeX parse error: Expected '}', got '_' at position 39: …xt{ID,name,dept_̲name,salary})

当我们进行分解的时候，可能分解的结果中还会有一个或者多个不属于BCNF。这种情况下需要进一步分解。

8.3.4 BCNF和保持依赖

数据库一致性约束的方式很多：主码约束，函数约束，check约束，断言和触发器。

每次数据库检查这些约束的开销很大。

BCNF的分解会妨碍对某些函数依赖项的检查。

例：

假定将学生和导师的关系修改为：教师只能和单个系关联，一个学生可以有多个老师，但是一个给定的系中最多一个。

我们将advisor，student和department结合成一个三元联系集合：dept_advisor。它是从{instructor，student}到department是唯一的。关系模式如下：

dept_advisor(s_ID, i_ID, dept_name)

下面的函数依赖在上面的关系模式中成立：
$$\{\begin{array}{l}i\_ID\to dept\_name：一个教师只能在一个系担任导师\\ s\_ID,dept\_name\to i\_ID：对于一个指定系，一个学生可以由至多一个导师\end{array}$$
因为存在函数依赖$i\_ID\to dept\_name$，其中$i\_ID$不是超码，所以需要根据BCNF原则进行分解。结果如下：
KaTeX parse error: Expected '}', got '_' at position 10: \text{(s_̲ID,i_ID)}\\ \te…
这两个关系都满足BCNF范式，但是以来的检查计算变得很困难。

因此称我们的设计不是保持依赖的（dependency preserving）。我们希望保持依赖，所以常常使用一种比BCNF弱的范式，它允许我们保持以来，该范式称为第三范式。

8.3.5 第三范式

1.第三范式和BCNF的区别

• BCNF要求所有非平凡函数依赖都形如$\alpha \to \beta$，其中$\alpha$是一个超码。
• 第三范式（3NF）允许左侧不是超码的某些非平凡函数依赖

2.第三范式定义

对于$F^{+}$中的所有形如$\alpha \to \beta$的函数依赖（其中$\alpha \subseteq R$且$\beta \subseteq R$），以下至少一项成立：

• $\alpha \to \beta$是一个平凡的函数依赖
• $\alpha$是R的一个超码
• $\beta -\alpha$中的每一个属性A都包含于R的一个候选码中

前两个条件与BCNF相同。

第三个条件中，由于候选码不止一个，所以可以不是全包含于一个候选码。$\beta -\alpha$中的每个属性A可以包含于不同的候选码中。它意味着BCNF的最小放宽，确保每个模式都有保持依赖的3NF分解。

任何满足BCNF范式的模式也满足与3NF，反之不一定。BCNF比3NF更严格。

再次考虑关系dept_advisor：
$$函数依赖\{\begin{array}{l}i\_ID\to dept\_name\\ s\_ID,dept\_name\to i\_ID\end{array}$$
函数依赖$i\_ID\to dept\_name$导致模式不属于BCNF，这里$\alpha =i\_ID$,$\beta =dept\_name$。

所以$\beta -\alpha =dept\_name$。又由于有第二个函数依赖存在，所以有$s\_ID,dept\_name$是一个候选码。于是dept_name包含于一个候选码中。所以$dept\_advisor$属于3NF。

8.3.6 更高的范式

BCNF范式有多好？

多值属性仍满足BCNF范式。但是会造成会多的冗余。

8.4 函数依赖理论

判定是否属于BCNF范式或者第三范式的首要任务：找到所有的函数依赖。

8.4.1 函数依赖集的闭包

1.逻辑蕴含

给定模式上的函数依赖集F，我们可以证明某些其他的函数依赖在该模式上也成立。我们称这些函数依赖被F逻辑蕴涵。

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

e.g.
$$\begin{gathered} A\to B \\ A\to C \\ CG\to H \\ CG\to I \\ B\to H \end{gathered}$$
那么函数依赖：
$$A\to H$$
被逻辑蕴涵。也就是说，一个关系只要满足给定的函数依赖集，那么这个关系一定满足$A\to H$。

2.函数依赖的闭包-Armstrong’s Axioms

F是一个函数依赖集，F的闭包是被F逻辑蕴涵的所有函数依赖的集合，记作$F^{+}$。给定F，可以由函数依赖的形式化定义计算出$F^{+}$。

阿姆斯特朗定理：

由阿姆斯特朗定理不断应用，可以找到$F^{+}$
$$\begin{gathered} 自反律：if\beta \subseteq \alpha ,then\alpha \to \beta \\ 增补律：if\alpha \to \beta ,then\gamma \alpha \to \gamma \beta \\ 传递律：if\alpha \to \beta ,and\beta \to \gamma ,then\alpha \to \gamma \end{gathered}$$

• 自反律：一个集合可以决定他的所有子集。
• 增补率：增加一项

Armstrong定理特点：

• 正确有效的sound
• 完备的complete

Example:

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-GO2oTdyB-1635593884006)(https://gitee.com/sun-yunqi/img/raw/master/pictureStore/image-20211011213859885.png)]

Armstrong定理的引申：

• union右侧可合并：$if\alpha \to \beta and\alpha \to \gamma ,then\alpha \to \beta \gamma$
• decomposition右侧可拆分：$if\alpha \to \beta \gamma ,then\alpha \to \beta and\alpha \to \gamma$
• pseudotransitivity伪传递律：$if\alpha \to \beta holdsand\gamma \beta \to \delta ,then\gamma \alpha \to \delta$

3.Armstrong定理求解函数依赖闭包

F+ = F
	repeat
		for each F+中的函数依赖f
			在f上应用自反律和增补律
			将结果加到F+中
         for each F+中的一对函数依赖f1和f2
         	if f1和f2可以使用传递律结合起来
         		将结果加到F+中
   	until F+不再发生变化

这种算法最终会收敛。由于包含n个元素的集合有$2^n$个子集，因此共有$2^n\times 2^n$个可能的函数依赖。

8.4.2 属性集的闭包

如果$\alpha \to B$，那么称属性B被$\alpha$函数确定。

情景：判断$\alpha$是不是超码？

• 所有属性都被$\alpha$函数确定
• 依照union，那么$\alpha$就是超码

这样就有一个需求：计算被$\alpha$函数确定的属性集。

1.函数确定的属性集

概念：如果$\alpha \to B$，那么称属性B被$\alpha$函数确定。

函数确定的属性集的作用如下：

• 判定是否是超码
• 判定函数依赖
• 计算F的函数闭包

2.函数确定属性集的计算方法

令$\alpha$为一个属性集，我们将函数依赖F下被$\alpha$函数确定的所有属性的集合称为F下$\alpha$的闭包，记作${\alpha }^{+}$。

计算函数确定的属性集有两种方法：

• 计算$F^{+}$，找出所有左半部分为$\alpha$的函数依赖，合并右半部分——开销大，F+可能很大

• 如下的伪代码算法：

  result:= α;
  	repeat
  		for each 函数依赖β→r in F do
  			begin
  				if β 蕴涵于 result then result := result ∪ r;
  			end
         	until (result 不变)
  

  即：对函数依赖集F下的每一个函数依赖，如果依赖的左边$\beta$在结果属性集中，那么依赖的右边$\gamma$加入到结果集中。

  e.g.
  R = ( A , B , C , G , H , I ) F = { A → B A → C C G → H C G → I B → H } R = (A,B,C,G,H,I)\\ F = \{A\rightarrow B\\ A\rightarrow C\\ CG\rightarrow H\\ CG\rightarrow I\\ B\rightarrow H\}\\ R=(A,B,C,G,H,I)F={A→BA→CCG→HCG→IB→H}
  求$(AG{)}^{+}$：
  $$\begin{gathered} 1.result=AG//初始化结果 \\ 2.result=ABCG//A\to B,A\to C \\ 3.result=ABCGHI//CG\to HCG\to I \end{gathered}$$
  问：AG是一个候选码吗？

  step1.AG是一个超码吗？

  所有的属性都在$(AG{)}^{+}$中，是一个超码。

  step2.判断是否是候选码：是否有他的真子集是超码；依次判断A和G在F下的闭包$A^{+}$和$B^{+}$。
  $$\begin{gathered} A\to R? \\ G\to R? \end{gathered}$$

8.4.3 正则覆盖

需求分析：数据库进行更新操作，数据库必须保证此更新不破坏任何函数依赖，也就是说，F中的所有函数依赖在新的数据库状态下仍然满足。但是由于函数依赖过多，所以检测每个函数依赖都满足的代价较高。我们可以通过检测与给定函数依赖集相同闭包的简化集来减小检测冲突的开销。

1.无关属性

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

注意这里说明的：去除掉函数依赖的（属性），不改变函数依赖的（闭包）

无关属性的判定，考虑函数依赖集F以及F中的函数依赖$\alpha \to \beta$：

• 如果$A\in \alpha$并且F逻辑蕴含 ( F − { α → β } ) ⋃ { ( α − A ) → β } (F-\{\alpha\rightarrow\beta\})\bigcup\{(\alpha-A)\rightarrow\beta\} (F−{α→β})⋃{(α−A)→β}，那么属性A在$\alpha$中是无关的。
• 如果$A\in \beta$并且函数依赖集 ( F − { α − β } ) ⋃ { α → ( β − A ) } (F - \{\alpha-\beta\})\bigcup\{\alpha\rightarrow(\beta-A)\} (F−{α−β})⋃{α→(β−A)}逻辑蕴含F，则属性A在$\beta$中是无关的。

由于去掉属性后不改变函数依赖的闭包才是无关属性，所以其实蕴涵关系的两个式子必然是有相同的闭包的。

2.无关属性的检验

令R为一个关系模式，且F是在R上成立的给定函数依赖集合。考虑$\alpha \to \beta$中的一个属性A。

• 如果$A\in \alpha$，判断A是否无关，令 γ = α − { A } \gamma = \alpha-\{A\} γ=α−{A}，检查$\gamma \to \beta$是否可以由F推出。

  做法：计算F下的$\gamma$的闭包${\gamma }^{+}(\gamma$的闭包$)$；如果${\gamma }^{+}$包含$\beta$的所有属性，那么A在$\alpha$中是无关的。

  属性集合的闭包求法见8.4.2

• 如果$A\in \beta$，为检验A是否是无关的，考虑集合
  F ′ = ( F − { α − β } ) ⋃ { α → ( β − A ) } F'=(F - \{\alpha-\beta\})\bigcup\{\alpha\rightarrow(\beta-A)\} F′=(F−{α−β})⋃{α→(β−A)}
  并且检验$\alpha \to A$能否由F’推出。计算F下的$\alpha$的闭包${\alpha }^{+}$；如果包含A，那么A在$\beta$中是无关属性，否则不是。

Example：
F = { A B → C D , A → E , E → C } F = \{AB\rightarrow CD,A\rightarrow E,E\rightarrow C\} F={AB→CD,A→E,E→C}
要求检验C在$AB\to CD$中是否是无关的。
∵ C ∈ C D ∴ 考 虑 集 合 F ′ = { A B → D , A → E , E → C } , 求 A B → c 能 否 在 F ′ 下 推 导 出 来 。 为 此 我 们 求 出 A B 在 F ′ 下 的 属 性 集 合 闭 包 。 求 得 r e s u l t = A B C D E , 包 含 C ， 所 以 C 在 C D 中 是 无 关 的 。 ∵C\in CD\\ ∴考虑集合F'=\{AB\rightarrow D,A\rightarrow E,E\rightarrow C\},求AB\rightarrow c能否在F'下推导出来。\\ 为此我们求出AB在F'下的属性集合闭包。\\ 求得result = ABCDE,包含C，所以C在CD中是无关的。 ∵C∈CD∴考虑集合F′={AB→D,A→E,E→C},求AB→c能否在F′下推导出来。为此我们求出AB在F′下的属性集合闭包。求得result=ABCDE,包含C，所以C在CD中是无关的。

3.正则覆盖

F的正则覆盖Fc是一个依赖集，使得F逻辑蕴含Fc中的所有函数依赖，并且Fc逻辑蕴含F中的所有依赖。

此外，Fc具有以下的性质：

• Fc中的任何函数依赖都不含无关属性
• Fc中的函数依赖的左半部分是唯一的。即Fc中不存在两个依赖：${\alpha }_1\to {\beta }_1$和${\alpha }_2\to {\beta }_2$，满足${\alpha }_1={\alpha }_2$。

函数依赖集的正则覆盖算法如下：

注意点：

• 当检验一个属性是否无关时，使用的是Fc中的函数依赖，而不是F中的函数依赖。
• 如果出现了去掉某个属性后，函数依赖的左边或者右边为空，那么这样的依赖应该删除

4.正则覆盖的作用与计算

F与Fc有相同的闭包$\Rightarrow$验证是否满足Fc等价于验证是否满足F.

Fc是最小的，不含无关属性。验证Fc比验证F更容易。

Example：

考虑到模式$(A,B,C)$上的函数依赖集F：
$$\begin{gathered} A\to BC \\ B\to C \\ A\to B \\ AB\to C \end{gathered}$$

• $A\to BC$和$A\to B$合并成$A\to BC$

• 去除掉无关属性