DBMS - 规范化

函数依赖

函数依赖 (FD) 是关系中两个属性之间的一组约束。函数依赖表示，如果两个元组在属性 A1, A2,..., An 上具有相同的值，则这两个元组在属性 B1, B2, ..., Bn 上也必须具有相同的值。

函数依赖用箭头符号 (→) 表示，即 X→Y，其中 X 函数决定 Y。左侧的属性决定了右侧属性的值。

Armstrong 公理

如果 F 是一组函数依赖，则 F 的闭包，记作 F⁺，是 F 逻辑蕴含的所有函数依赖的集合。Armstrong 公理是一组规则，通过反复应用这些规则，可以生成函数依赖的闭包。

• 自反律 − 如果 alpha 是一组属性且 beta 是 alpha 的子集，则 alpha 蕴含 beta。

• 增广律 − 如果 a → b 成立且 y 是属性集，则 ay → by 也成立。也就是说，在依赖中添加属性，不会改变基本依赖关系。

• 传递律 − 与代数中的传递律相同，如果 a → b 成立且 b → c 成立，则 a → c 也成立。a → b 称为 a 函数决定 b。

平凡函数依赖

• 平凡的 − 如果函数依赖 (FD) X → Y 成立，其中 Y 是 X 的子集，则称为平凡 FD。平凡 FD 总是成立。

• 非平凡的 − 如果 FD X → Y 成立，其中 Y 不是 X 的子集，则称为非平凡 FD。

• 完全非平凡的 − 如果 FD X → Y 成立，其中 X ∩ Y = Φ，则称为完全非平凡 FD。

规范化

如果数据库设计不完善，它可能会包含异常，这些异常对任何数据库管理员来说就像一场噩梦。管理包含异常的数据库几乎是不可能的。

• 更新异常 − 如果数据项分散且未正确关联，则可能导致奇怪的情况。例如，当我们尝试更新一个数据项时，其副本散布在多个地方，有些实例正确更新，而其他一些仍保留旧值。这种情况会导致数据库处于不一致状态。

• 删除异常 − 我们尝试删除一条记录，但由于不知情，其部分数据未被删除，因为数据还保存在其他地方。

• 插入异常 − 我们尝试向不存在的记录中插入数据。

规范化是一种方法，用于消除所有这些异常并使数据库达到一致状态。

第一范式

第一范式在关系（表）的定义中就已经规定了。该规则定义，关系中的所有属性必须具有原子域。原子域中的值是不可分割的单元。

我们将关系（表）重新排列如下，以转换为第一范式。

每个属性必须仅包含来自其预定义域的单个值。

第二范式

在学习第二范式之前，我们需要了解以下内容 −

• 主属性 − 作为 candidate-key 一部分的属性被称为主属性。

• 非主属性 − 不属于 prime-key 的属性被称为非主属性。

如果遵循第二范式，则每个非主属性都应完全函数依赖于主键属性。也就是说，如果 X → A 成立，则 X 的任何真子集 Y 都不应满足 Y → A。

我们在 Student_Project 关系中看到，主键属性是 Stu_ID 和 Proj_ID。根据规则，非键属性，即 Stu_Name 和 Proj_Name 必须同时依赖于两者，而不能单独依赖于任何一个主属性。但是我们发现 Stu_Name 可以由 Stu_ID 单独确定，Proj_Name 可以由 Proj_ID 单独确定。这被称为部分依赖，在第二范式中是不允许的。

我们如上图所示将关系拆分为两个关系。这样就不存在部分依赖了。

第三范式

要使关系处于第三范式，它必须处于第二范式，并且满足以下条件 −

• 没有非主属性传递依赖于主属性。
• 对于任何非平凡函数依赖 X → A，要么 −
  X 是 superkey，要么
• A 是主属性。

我们发现，在上面的 Student_detail 关系中，Stu_ID 是键且是唯一的主键属性。我们发现 City 可以由 Stu_ID 确定，也可以由 Zip 本身确定。Zip 既不是 superkey，City 也不是主属性。此外，Stu_ID → Zip → City，因此存在传递依赖。

为了将此关系转换为第三范式，我们将其拆分为两个关系，如下所示 −

Boyce-Codd 范式

Boyce-Codd 范式 (BCNF) 是第三范式的严格扩展。BCNF 规定 −

• 对于任何非平凡函数依赖 X → A，X 必须是 super-key。

在上面的图像中，Stu_ID 是 Student_Detail 关系中的 super-key，Zip 是 ZipCodes 关系中的 super-key。因此，

Stu_ID → Stu_Name, Zip

和

Zip → City

这证实了两个关系都处于 BCNF。