函数依赖和关系模式分解

文章目录

一，第一范式
二，关系数据库设计中易犯的错误
- 2.1 数据冗余
- 2.2 插入、删除、修改异常
三，模式分解（I）
四，函数依赖（FD）
- 4.1 什么是函数依赖
- 4.2 函数依赖的使用
- 4.3 函数依赖集的闭包
- - Armstrong 公理
  - 计算 F^+^
五，属性集的闭包
- 5.1 什么是属性集的闭包
- 5.2属性闭包的用途
六，正则覆盖
- 无关属性
- 检测属性是否无关
七，模式分解（II）
- 规范化的目标
- 分解应有的特性
八，总结

一，第一范式

如果某个域中元素被认为是不可分的，则这个域称为是原子的

非原子域的例子:
---- 复合属性：名字集合
---- 多值属性：电话号码
---- 复合数据类型：面向对象的

如果关系模式R中的所有属性的域是原子的，则R称为属于第一范式（1NF）

非原子值存储复杂并易导致数据冗余

我们假定所有关系都属于第一范式

如何处理非原子值

对于组合属性：让每个子属性本身称为一个属性
对于多值属性：为多值集合中的每个项创建一条元组

原子性实际上是由域元素在数据库中被使用决定的

例，字符串通常是被认为是不可分割的
假设学生被分配这样的标识号：CS0012或EE1127，如果前两个数字表示系所，后四位表示学生在该系所内的唯一号码，则这样的标识号不是原子的
当采用这种标识号时，是可取的。因为这需要额外的编程，而且信息是在应用程序中，而不是在数据库中编码。

二，关系数据库设计中易犯的错误

关系数据库设计要求我们找到一个“好的”关系模式集合。一个坏的设计可能导致：

数据冗余
插入、删除、修改异常

假设我们用以下模式代替instructor模式和department模式：

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

2.1 数据冗余

每个系的dept_name，building，budget数据都要重复一次
缺点：浪费空间，可能会导致不一致问题

2.2 插入、删除、修改异常

更新异常

更新复杂，容易导致不问题。
例修改dept_name，很多相关元组都需要修改。

插入/删除异常

使用空值null：存储一个不知道所在系所的教师信息，可以使用空值表示dept_name，building，budget数据，但是空值难以处理。

三，模式分解（I）

例，可以将关系模式（A,B,C,D）分解为：（A,B）和（B,C,D）,或（A,C,D）和（A,B,D）,或（A,B），（B,C）和（C,D）等等…

例，将关系模式inst_dept分解为：

instructor(ID, name, dept_name, salary)
department(dept_name, building, budget)

原模式（R）的所有属性都必须出现在分解后的（R₁，R₂）中：R = R₁ ∪ R₂

无损连接分解

对关系模式R上的所有可能的关系r

目标：设计一个理论

以判断关系模式R是否为“好的”形式（不冗余）
当R不是“好的”形式时，将它分解为模式集合{ R₁，R₂，…，R_n }使得：
---- 每个关系模式都是“好的”形式
---- 分解是无损链接分解
我们的理论基于：
---- 函数依赖（function dependencies）
---- 多值依赖（multivalue dependencies）

四，函数依赖（FD）

4.1 什么是函数依赖

设R是一个关系模式，且有属性集 α包含于R，β包含于R

在R上成立当且仅当对任意合法关系r(R)，若r的任意两条元组t₁和t₂在属性集α上的值相同，则它们的属性集β上的值也相同。

即：t₁[α] = t₂[α] → t₂[β] = t₂[β]
称：β函数依赖于α，α函数决定β
如下图，图中的α和β满足函数依赖关系

函数依赖：一种完整性约束，表示特定的属性值之间的关系，可以用来判断模式规范化和建议还进

函数依赖是码概念的推广
K是关系模式R的超码，当且仅当 K → R
K是R的候选码当且仅当
---- K → R，并且
---- 没有 α 包含于 K，使 α → R（不存在K的真子集α，使之满足 α → R）

函数依赖使我们可以表达用超码无法表达的约束，考虑模式

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

我们希望下列函数依赖成立：
---- dept_name → building
---- ID → building（码是一个比较特殊的FD，可以函数决定所有的属性）
而不希望下列函数依赖成立：
---- dept_name → salary

4.2 函数依赖的使用

若果在关系模式R上所有合法关系都满足F，则称F在R上成立。

其中 R = { r₁®，r₂®，… }

注：容易判断一个r是否满足给定的F。不易判断F是否在R上成立。不能仅由某个r推断出F。R上的函数依赖F，通常由定义R的语义决定。

被所有的关系实例所满足的函数依赖称为平凡的

例，A → A，AB → A，（ID，name）→ ID，ID → ID
一般的，若β包含于α，则α → β是平凡的。即，
平凡的函数依赖：若β包含于α，α → β。
非平凡的函数依赖：若β不包含于α，α → β。

4.3 函数依赖集的闭包

Armstrong 公理

计算 F⁺

下列过程计算函数依赖集F的闭包：

F+ = F
repeatfor each F+中的函数依赖f对应f应用'自反率'和'增补率'，将结果函数依赖加入F+for each F+中的一对函数依赖f1和f2if f1和f2可以使用'传递性'结合起来，则将结果函数依赖加入F+
until F+不再变化

由于包含n个元素的集合含有2ⁿ子集，因此共有 2ⁿ * 2ⁿ个可能的函数依赖。
后边会介绍完成此任务的另一过程。

五，属性集的闭包

如何判断集合α是否为超码

一种方法是：计算F⁺，在F⁺中找出所有的α → β，检查{ β₁β₂β₃ … } = R；
但这么做开销很大，因为F⁺可能很大。
另一种方法是：计算α的闭包。

5.1 什么是属性集的闭包

定义：给定一个属性集α，在函数依赖集F下由α函数确定的所有属性的集为F下α的闭包（记作α⁺）

检查函数依赖α → β是否属于F⁺ ↔ β包含于α⁺
判断α是否为超码：α → β属于F⁺ ↔ R包含于α⁺

计算α⁺的算法

result := a;
while(result有变化) dofor each β → γ in F dobeginif β包含于resultthen result := result ∪ γenda+ := result

避免了找F⁺（反复使用公理）的麻烦。
示例讲解

最终，AG可以表示R中的所有属性，则说AG是R的一个key。

5.2属性闭包的用途

六，正则覆盖

数据库管理系统（DBMS）总是检查确保数据库更新不会破坏任何函数依赖。但如果F很大，其开销就会很大。因此我们需要简化函数依赖集

直观地说，F的正则覆盖（记作F_c）是指与F等价的“极小的”函数依赖集合

F_c中任何函数依赖都不包含无关属性
F_c中函数依赖的左半部都是唯一的
例，α₁ → β₁，α₁ → β₂，可以写为α₁ → β₁β₂

无关属性

定义：考虑函数依赖集合F及其中的函数一来α → β

如果A∈α并且F逻辑蕴含F’ =（F - { α → β }）∪ {（α → A ）→ β}，则称A在α中是无关的
---- 例，给定F = { A → C，AB → C }，其中B在AB → C中是无关的，因为A → C逻辑蕴含了AB → C。
如果A∈β并且F’ =（F - { α → β }）∪ { α →（α → A ）}逻辑蕴含F，则称A在β中是无关的
---- 例，给定F = { A → C，AB → CD }，其中C在AB → CD中是无关的，因为即使删除C也能推出A → C。

检测属性是否无关

计算F的正则覆盖

repeat对F中的依赖利用'合并'规则α1 → β1 和 α1 → β2 替换成 α1 → β1β2找出含有无关属性的函数依赖 α → β（在α或β中）如果找到无关属性，从α → β中删除
until F不再变化

注：删除某些无关属性之后，可能导致合并规则可以使用，则必须重新应用。

七，模式分解（II）

规范化的目标

以判断关系模式R是否为“好的”形式（不冗余，误插入，删除，更新异常）
当R不是“好的”形式时，将他分解成模式集合{ R₁，R₂，…，R_n }使得：
– 每个关系模式都是“好的”形式
– 分解是无损连接分解
– 分解是保持依赖的

分解应有的特性

八，总结

描述了原子域和第一范式假设；
给出了数据库设计中易犯的错误，这些错误包括信息重复和插入、删除、修改异常；
介绍了函数依赖的概念，展示了如何用函数依赖进行推导；
理解F⁺，α⁺，F_C；
介绍了如何分解模式，一个有效的分解都必须是无损的；
如何分解是保持依赖的，则给定一个数据库更新，所有的函数依赖都可以由单独的关系进行验证，无须计算分解后的关系链接。