数据库设计/函数依赖

函数依赖 (FD) 是两个属性之间的关系，通常是表中主键和其他非主键属性之间的关系。对于任何关系 R，属性 Y 函数依赖于属性 X（通常是主键），如果对于 X 的每个有效实例，该 X 值都唯一地确定 Y 的值。这种关系由下面的表示表示

X ———–> Y

上述 FD 图的左侧称为决定因素，右侧称为依赖因素。这里有一些例子。

在第一个例子中，SIN 决定 Name、Address 和 Birthdate。给定 SIN，我们可以确定表中的任何其他属性。

SIN ———-> Name, Address, Birthdate

对于第二个例子，SIN 和 Course 决定完成日期 (DateCompleted)。对于复合主键，这也必须有效。

SIN, Course ———> DateCompleted

第三个例子表明 ISBN 决定 Title。

ISBN ———–> Title

函数依赖规则

考虑表 11.1 中所示的关系模式 R(ABCDE) 的数据表 r(R)。

表 11.1. 函数依赖示例，作者：A. Watt。

当你看这个表时，问问自己：在表 R 中的属性之间，我们能观察到什么样的依赖关系？由于 A 的值是唯一的（a1、a2、a3 等），因此从 FD 定义可以得出

A → B, A → C, A → D, A → E

也可以得出 A →BC （或 ABCDE 的任何其他子集）。
这可以概括为 A →BCDE。
从我们对主键的理解来看，A 是主键。

由于 E 的值始终相同（全部为 e1），因此可以得出

A → E, B → E, C → E, D → E

但是，我们通常不能用 ABCD → E 来概括以上内容，因为通常情况下， A → E, B → E, AB → E。

其他观察结果

BC 的组合是唯一的，因此 BC → ADE。
BD 的组合是唯一的，因此 BD → ACE。
如果 C 值匹配，则 D 值也匹配。
1. 因此， C → D
2. 但是，D 值不能确定 C 值
3. 所以 C 不能确定 D，而 D 也不能确定 C。

查看实际数据可以帮助澄清哪些属性是依赖属性，哪些是决定因素。

推理规则

阿姆斯特朗公理是用于推断关系数据库上所有函数依赖的一组推理规则。它们是由威廉·W·阿姆斯特朗开发的。以下是描述将在符号方面使用的内容，以解释这些公理。

令 R(U) 是一个在属性集 U 上的关系模式。我们将使用字母 X、Y、Z 来表示 U 的任何子集，并简写两个属性集的并集，而不是通常的 X U Y。

自反公理

该公理表示，如果 Y 是 X 的子集，则 X 决定 Y（见图 11.1）。

图 11.1. 自反公理的方程。

例如，PartNo —> NT123 其中 X (PartNo) 由多个信息组成；即 Y (NT) 和 partID (123)。

扩充公理

扩充公理，也称为部分依赖，表示如果 X 决定 Y，则 XZ 决定 YZ，对于任何 Z（见图 11.2）。

图 11.2. 扩充公理的方程。

扩充公理表示每个非主键属性都必须完全依赖于主键。在下面显示的示例中，StudentName、Address、City、Prov 和 PC（邮政编码）仅依赖于 StudentNo，而不依赖于 StudentNo 和 Grade。

StudentNo, Course —> StudentName, Address, City, Prov, PC, Grade, DateCompleted

这种情况不可取，因为每个非主键属性都必须完全依赖于主键。在这种情况下，学生信息仅部分依赖于主键 (StudentNo)。

要解决这个问题，我们需要将原始表分解成两个，如下所示

表 1：StudentNo, Course, Grade, DateCompleted
表 2：StudentNo, StudentName, Address, City, Prov, PC

传递公理

传递公理表示，如果 X 决定 Y，而 Y 决定 Z，则 X 也必须决定 Z（见图 11.3）。

图 11.3. 传递公理的方程。

下面的表包含与学生没有直接关系的信息；例如，ProgramID 和 ProgramName 应该有自己的表。ProgramName 不依赖于 StudentNo；它依赖于 ProgramID。

StudentNo —> StudentName, Address, City, Prov, PC, ProgramID, ProgramName

这种情况不可取，因为一个非主键属性 (ProgramName) 依赖于另一个非主键属性 (ProgramID)。

要解决这个问题，我们需要将此表分解成两个：一个用于保存有关学生的信息，另一个用于保存有关程序的信息。

表 1：StudentNo —> StudentName, Address, City, Prov, PC, ProgramID
表 2：ProgramID —> ProgramName

但是，我们仍然需要在学生表中保留外键，以便我们可以识别学生注册的哪个程序。

并集

此规则表明，如果两个表是分开的，而主键相同，则您可能需要考虑将它们放在一起。它表示如果 X 决定 Y 并且 X 决定 Z，则 X 也必须决定 Y 和 Z（见图 11.4）。

图 11.4. 并集规则的方程。

例如，如果

SIN —> EmpName
SIN —> SpouseName

您可能希望将这两个表合并成一个，如下所示

SIN –> EmpName, SpouseName

一些数据库管理员 (DBA) 可能选择将这些表分开，原因有二。第一，每个表都描述了一个不同的实体，所以应该将这些实体分开。第二，如果 SpouseName 要在大多数情况下保留为 NULL，则无需将其包含在与 EmpName 相同的表中。

分解

分解是并集规则的逆运算。如果您有一个表，其中似乎包含两个由相同主键决定的实体，请考虑将它们分解成两个表。此规则表示，如果 X 决定 Y 和 Z，则 X 分别决定 Y 和 X 决定 Z（见图 11.5）。

图 11.5. 补偿规则的方程。

依赖图

依赖图（见图 11.6）说明了非规范化表中可能存在的各种依赖关系。非规范化表是指其中存在数据冗余的表。

图 11.6. 依赖图。

此表中确定了以下依赖关系

ProjectNo 和 EmpNo 共同构成主键。
部分依赖
- ProjectNo —> ProjName
- EmpNo —> EmpName, DeptNo,
- ProjectNo, EmpNo —> HrsWork
传递依赖
- DeptNo —> DeptName

关键词

阿姆斯特朗公理: 一组用于推断关系数据库中所有函数依赖的推理规则

DBA: 数据库管理员

分解: 一条规则，建议如果有一个表看起来包含两个由相同主键确定的实体，则考虑将它们拆分成两个表。

依赖: 函数依赖图的右侧

决定因素: 函数依赖图的左侧

函数依赖 (FD): 两个属性之间的关系，通常是表中的主键和其他非键属性之间的关系。

非规范化表: 包含数据冗余的表

并集: 一条规则，建议如果两个表是分开的，而主键是相同的，则考虑将它们合并。

练习

参见下一章。

归属

数据库设计的本章（包括图像，除非另有说明）是维基百科自由百科全书中阿姆斯特朗公理的衍生副本，该副本在知识共享署名-相同方式共享 3.0 未移植许可下获得许可。

以下材料由 Adrienne Watt 撰写

一些函数依赖规则
关键词

参考资料

BCOpenCampus：数据库设计

← ER 建模

数据库设计

规范化 →