吉林大学 数据库系统概念 期末复习 第六部分 关系数据库设计

6.1 好的关系设计的特点

6.1.1设计选择：更大的模式

更大的模式容易导致数据冗余，即使容许冗余问题，难以添加新的数据。
举例： 用inst_dept 代替instructor和department（inst_dept 是instructor和department自然连接的结果）

6.1.2设计选择更小的模式

• 在我们的例子中我们如何知道我们的大学的每个系必须位于单个办公楼中必须具有单个预算数额呢？

• 因此提出了函数依赖“dept_name的每个特定的值至多一个budget“这样的规则。这条规则被称为函数依赖。

无损连接：将重新分解产生的模式生成的元组用自然连接重新生成元组的结果和分解之前的结果相同。

有损连接：将重新分解产生的模式生成的元组用自然连接重新生成元组的结果和分解之前的结果不同。

6.2 原子域和第一范式

在关系模型中，我们将属性不具有任何子结构这个思想形式化。如果该域的元素被认为不可分割则称这个域是原子的。如果关系模型R的属性都是原子的，则R属于第一范式。

非原子值的例子：名字的集合，如果属性children ，它的域是名字的集合，则该模式不是第一范式。组合属性也具有非原子域。

6.3使用函数依赖进行分解

6.3.1码和函数依赖

重新定义超码：令r（R）是一个关系模式。R的子集K是超码的条件是：在关系r（R）任意合法实例中，对于r的实例中的元组对$t_1,t_2$满足若$t_1\ne t_2$则 $t_1[k]\ne t_2[k]$在r中K唯一标识一条元组。

鉴于超码是唯一标识整条元组的属性集，函数依赖让我们可以表达唯一标识某些属性的值的约束

• 给定r（R）的一个实例，我们说这个实例满足函数依赖$\alpha \to \beta$的条件是： $t_1[\alpha ]=t_2[\alpha ]$则$t_1[\beta ]=t_2[\beta ]$.
• 如果在r（R）的每个合法实例都满足$\alpha \to \beta$，则说该函数依赖在模式r（R）中成立。
  如果函数依赖$k\to R$在r（R）上成立，则K是超码。

我们将以两种方式使用函数依赖：

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

6.3.2 BCNF和保持依赖

我们能达到较满意的范式之一是BCNF范式，它能消除所有函数依赖的冗余。具有函数依赖集F的关系模式R属于BCNF的条件是对$F^{+}$中所有形如$\alpha \to \beta$的函数依赖，至少有一项成立。

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

根据BCNF的分解规则，函数依赖很难保持，这会使得在计算上十分困难，因此我们的设计不是保持依赖的，所以我们提出了比BCNF弱的范式-3NF范式

8.3.3第三范式

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

• $\alpha \to \beta$是平凡函数依赖
• $\alpha$是模式R的超码。
• $\beta -\alpha$的每一个属性A都包含于R中的一个候选码中。
  ⚠️注意：$\beta -\alpha$每个属性A可能包含在不同的候选码中。

6.4函数依赖理论

6.4.1函数依赖集的闭包

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

Asmstrong 公理

• 自反律
• 增补律
• 传递律

另外的规则

• 合并律
• 分解律
• 伪传递律

latex还用的不太熟，就不给出详细的内容，如果想看详细的内容建议看书或这篇博客：
Asmstrong 公理详细解读

这个不太好用，建议使用下一节属性集的闭包来计算函数依赖集的闭包。

6.4.2 属性集的闭包

属性集的闭包算法有多种用途：

• 判断$\alpha$是否为超码
• 检查$\alpha \to \beta$是否成立。
• 计算另一种计算$F^{+}$的算法

6.4.3 正则覆盖

正则覆盖定义：一个依赖集F的正则覆盖Fc也是一个依赖集，F逻辑蕴含Fc中所有依赖，且Fc逻辑蕴涵F的所有依赖。Fc满足以下两个特性

·Fc中任何函数依赖都不含无关属性

·Fc中函数依赖左半部分都是唯一的，不允许重复

概念
无损分解指的是对关系模式分解时，原关系模型下任一合法的关系值在分解之后应能通过自然联接运算恢复起来。反之，则称为有损分解。

设R是一个关系模式，F是R上的一个依赖集，R分解为关系模式的集合p={R1(U1),R2(U2),…,Rn(Un)}。如果对于R中满足F的每一个关系r，都有r=πR1®⋈πR2®⋈…πRn®则称分解相对于F是无损连接分解，否则有有损连接。

以函数依赖说明什么情况下分解是无损的。令R1和R2是R的无损分解，如果以下函数依赖中至少有一个属于$F^{+}$：

• R1 $\cap$R2$\to$R1
• R1 $\cap$R2$\to$R2

6.4.4 保持依赖

验证保持依赖有两种方式

第一种，需要计算$F^{+}$

第二种方法：
验证方法对F中的每一个$\alpha \to \beta$使用下面过程

分解是保持依赖的当且仅当F中所有的都保持依赖。

6.5 分解算法

6.5.1 BCNF分解

BCNF的验证
一种方法是，对于一个关系R，每个函数依赖X→Y的左侧都包含关系R的码，也就是说每个函数依赖的左侧都是关系R的一个超码，那么这个关系R是BCNF范式的。但此方法在关系分解后便不再适用。
另一种方法是对于Ri的每个子集$\alpha$,确保${\alpha }^{+}$要么不包含Ri-$\alpha$的任意属性，要么包含所有属性
BCNF的分解

6.5.2 3NF的分解

3NF的分解

6.5.3 3NF的正确性

6.5.4 BCNF和3NF的比较

在数据库设计中，BCNF（Boyce-Codd范式）和3NF（第三范式）是两个重要的规范化概念。

首先，BCNF是对3NF的进一步约束。它要求在关系模式中任何非平凡的函数依赖F都满足：对于F中的每一个X→Y，都必须满足X是F的超键。这意味着没有任何两个属性集能同时决定另一个属性集。

相比之下，3NF则要求在关系模式中不存在任何非平凡的传递依赖。

最终选择何种范式取决于数据的特征。为了消除不一致和误解，使用规范化原理为基础来设计数据库是一个好主意，但应该优先考虑数据库的性能和数据需要。

总结

这篇文章显的很草率，因为这全都是算法，所以我以后将会更新关于相关算法例题。