1. 函数依赖集，到底在考什么

接触过数据库系统原理这门课的人，大概率都经历过被函数依赖支配的恐惧。上课听懂了，做题发懵；考前背了定义，遇到综合题还是不会拆。坦白讲，函数依赖集这个知识点，是数据库设计中从“会建表”走向“会设计表”的一个分水岭。

你可能会问，函数依赖集到底解决了什么问题？往大了说，它描述的是属性之间的内在约束关系，也就是“给定某些属性的值，能不能唯一确定另一些属性的值”。往小了说，它是判断一张表设计得好不好、需不需要拆分的数学工具。没有它，你只能凭感觉设计表结构，有了它，你就能用一套严谨的推导规则，从逻辑上证明当前的表结构是否合理、冗余在哪里、该怎么拆。

这篇文章不打算从课本第一章开始复述定义，而是围绕函数依赖集这个主题，把常见的例题类型、推导手法、易错点一次性讲透。适合正在复习数据库系统原理的在校同学、准备相关岗位面试的开发者，以及工作中需要做数据库建模但一直没系统补过这块理论的后端工程师。看完之后，至少你拿到一道函数依赖集的题目，能知道从哪里下手，每一步推导的依据是什么。

2. 从零理解函数依赖集的三个底层概念

2.1 函数依赖的本质是“确定关系”

函数依赖（Functional Dependency）的数学定义很简洁：设R(U)是一个关系模式，X、Y是属性集U的子集，如果对于R中任意两个元组，只要它们的X属性值相等，它们的Y属性值也必然相等，就称X函数决定Y，记作X→Y。这个定义背下来不难，难的是理解它到底在描述什么。

我用一个生活化的场景来说明。假设有一个学生表，包含学号、姓名、班级、辅导员四个字段。学号定了，姓名一定定了，因为一个学号对应一个学生。学号定了，班级也定了，因为一个学生只属于一个班级。但反过来，班级定了，辅导员一定定了，可班级定了学号并不一定，因为一个班级有几十个学生。这些就是函数依赖的直观体现。

有一点需要特别提醒：函数依赖是语义层面的约束，不是数学推导出来的。也就是说，X→Y是否成立，取决于你业务上怎么定义这些属性，而不是数据库系统帮你判断的。你在表设计阶段就要想清楚，哪些依赖关系是业务规则本身就具备的。

2.2 函数依赖集：多个依赖的集合

函数依赖集就是一组函数依赖的集合，通常用F表示。比如学生表的依赖集F = {学号→姓名, 学号→班级, 班级→辅导员}。之所以要研究“集合”，是因为实际业务中属性很多，依赖关系错综复杂，我们需要一套规则来管理它们。

依赖集里有一个容易忽略的点：依赖的条件是“任意两个元组”。这意味着，只要存在哪怕一条记录违反了规则，这个函数依赖就不成立。所以在举反例的时候，一条反例就足够推翻一个依赖。

多个函数依赖之间还会互相影响。比如已知学号→班级和班级→辅导员，我们能不能推断出学号→辅导员？当然可以，这就是依赖之间的传递性。正式化之后，就成了Armstrong公理体系。

2.3 属性闭包：判断依赖是否成立的核心工具

在解函数依赖集相关例题时，属性闭包是最常用的工具。给定属性集X和依赖集F，X在F下的闭包记作X⁺，表示从X出发，利用F中的所有函数依赖，能推导出的所有属性的集合。

计算闭包有一套固定的迭代算法：先把X本身加入闭包，然后反复扫描F中的每个依赖，如果某个依赖的左边属性已经全部在闭包里，就把它的右边属性也加入闭包，直到闭包不再变化为止。

闭包算法的意义在于，判断X→Y是否成立，只需要检查Y是否包含在X⁺中即可。这个转换非常关键，因为“判断依赖成立”是一个语义问题，而“计算闭包”是一个机械的迭代过程，后者可以用程序实现，也可以手算。

3. 例题拆解一：属性闭包的计算全过程

3.1 一道标准的闭包计算题

先给出一道经典例题。设关系模式R(U)，U = {A, B, C, D, E, F}，函数依赖集F = {A→BC, B→CF, E→A, CE→F}。求属性集(AE)的闭包(AE)⁺。

我看到很多初学者拿到这种题，第一反应是想当然：A推BC，E推A，所以AE推BCA……然后就开始乱组合。这种思路是最大的坑。闭包计算必须严格按迭代算法来，每一步都基于当前闭包内容去找可用的依赖，而不是凭直觉跳跃。

下面把完整的迭代过程写出来。

初始：X = {A, E}，闭包集合 = {A, E}。

第一轮扫描：

• A→BC：A在闭包中，加入B、C。闭包变为{A, E, B, C}。
• B→CF：B在闭包中，C也在，加入F。闭包变为{A, E, B, C, F}。
• E→A：E在闭包中，A已经在，闭包不变。
• CE→F：C、E都在闭包，F已经在，闭包不变。

第二轮扫描： 检查所有依赖，左边属性是否都已在闭包中。A、B、C、E、F都已经在闭包中，没有新的属性可以加入。

至此闭包不再变化，所以(AE)⁺ = {A, B, C, E, F}。

这里有几个容易出错的细节。第一，初始闭包一定包含属性集本身，这很容易被忽略，尤其是属性集里本来就有多个属性的时候。第二，每一轮扫描的顺序会影响你发现新属性的早晚，但不影响最终结果，因为迭代本身是单调的，最后都会收敛到同一个结果。第三，依赖右边如果是多个属性，要逐个加入，别漏了任何一个。

3.2 闭包计算结果的三种用途

计算闭包不是目的，用闭包去解决问题才是目的。闭包计算的结果，至少有三个用途。

第一个用途是判断特定函数依赖是否成立。比如在上面的例子中，判断AE→F是否成立，只需要看F是否在(AE)⁺中。很明显F在，所以AE→F成立。这道题给的依赖集中有CE→F，并没有直接给出AE→F，但通过闭包计算我们可以确认，AE→F是由F逻辑蕴含的。

第二个用途是求解候选码。关系中的候选码，就是能唯一确定所有属性的最小属性集。判断一个属性集K是否为候选码，第一步看K⁺是否等于U，第二步看K的任意真子集的闭包是否都不等于U。这个“最小性”检查是很多人会漏掉的。

第三个用途是判断两个依赖集是否等价。这个概念后面单独展开。

3.3 关于闭包计算的实操建议

手算闭包的时候，我建议你养成一个习惯：把每一轮加入的属性用下划线或颜色标记出来，避免下一轮扫描的时候看不清楚。另外，扫描依赖集的时候按顺序逐一检查，不要跳来跳去，这样不容易漏。

还有一个很实用的技巧：如果依赖左边的属性很多，不要盲目扫描，先看哪些依赖的左边已经完整出现在当前闭包中。这个检查其实很快，扫一眼就能判断。如果某条依赖的左边永远无法凑齐，那它在计算过程中就不会被触发，可以暂时忽略。

4. 例题拆解二：候选码求解与Armstrong公理的应用

4.1 Armstrong公理与增强规则

Armstrong公理体系是函数依赖推导的推理规则全集，包括三条基本公理和若干推论。

三条基本公理：

• 自反律：若Y ⊆ X，则X→Y。
• 增广律：若X→Y，则XZ→YZ。
• 传递律：若X→Y且Y→Z，则X→Z。

由此导出的常用推论：

• 合并规则：若X→Y且X→Z，则X→YZ。
• 分解规则：若X→YZ，则X→Y且X→Z。
• 伪传递规则：若X→Y且WY→Z，则WX→Z。

很多人疑惑，为什么要学这套公理？直接算闭包不就行了？这么说吧，闭包计算是验证工具，公理体系是推导工具。两者是同一件事的两面：闭包算法的正确性正是由Armstrong公理保证的。而且在求解候选码、判断依赖蕴含关系时，用公理推导往往比盲目计算更直观。

4.2 候选码求解的完整思路

求解候选码是函数依赖集相关考试题和面试题的重灾区，因为步骤多、细节多。先给出标准流程。

第一步，将属性分为四类：

• L类：只出现在所有函数依赖左边的属性。
• R类：只出现在所有函数依赖右边的属性。
• LR类：两边都出现的属性。
• N类：两边都不出现的属性。

第二步，有一个非常重要的结论：N类属性一定包含在任何一个候选码中，L类属性也一定包含在某个候选码中。R类属性一定不在任何候选码中。

第三步，先尝试把N类和L类属性组合起来，计算闭包。如果闭包等于全集U，那么这些属性就构成候选码。如果闭包不等于U，就需要从LR类属性中逐个补充进来测试。

需要注意一个细节：候选码不一定只有一个，但所有候选码具有相同的属性个数（在函数依赖集确定的情况下）。判断最小性时，必须检查其真子集的闭包是否等于全集。

4.3 实例：求解候选码

给定关系模式R(U)，U = {A, B, C, D, E}，函数依赖集F = {AB→C, C→D, D→B, D→E}。

先分类：

• 只出现在左边的属性：A。
• 只出现在右边的属性：E。
• 两边都出现的属性：B、C、D。
• 两边都不出现的属性：无。

A是L类，所以候选码中一定包含A。E是R类，E一定不在候选码中。

尝试{A}⁺：初始{A}。A没有出现在任何依赖的左边，所以闭包就是{A}，不等于U。

由于所有依赖的左边都不是单独的A，我们需要补充LR类属性。依次尝试AB、AC、AD。

先算(AB)⁺：初始{A, B}。AB→C，加入C；C→D，加入D；D→B已在，D→E，加入E。所以(AB)⁺ = {A, B, C, D, E} = U。到此还不能立刻下结论，还要检查AB的真子集A和B。A⁺ = {A}，不是U；B⁺ = {B}，也不是U（B没有出现在任何依赖的左边）。因此AB是一个候选码。

再算(AC)⁺：初始{A, C}。C→D，加入D；D→B，加入B；D→E，加入E；AB→C，C已在。所以(AC)⁺ = {A, C, D, B, E} = U。检查真子集：A不是U，C⁺ = {C, D, B, E}，不等于U（缺少A）。所以AC是第二个候选码。

再算(AD)⁺：初始{A, D}。D→B，加入B；D→E，加入E。此时闭包为{A, D, B, E}，缺少C，不等于U。AD不是候选码。

结论：候选码为AB和AC。

这道题做完，有一个体会想分享给你：如果属性多、依赖多，逐一手算容易出错，建议借助闭包计算表格来整理，每一列记录当前闭包中的属性，每一行记录一次依赖触发。这样即使中间算错了，也能快速回溯发现问题。

5. 例题拆解三：函数依赖集等价性判定

5.1 等价性判定的标准方法

两个函数依赖集F和G，如果F的逻辑蕴含集等于G的逻辑蕴含集，就称它们是等价的。判断等价，不需要逐一比较所有逻辑蕴含的依赖，只需要做两件事：检查F中的每个依赖是否都能由G推出，检查G中的每个依赖是否都能由F推出。

具体操作方法是：对于F中的每个依赖X→Y，在G下计算X⁺，看Y是否包含在X⁺中。如果全部成立，说明F ⊆ G⁺，即F中所有依赖都被G蕴含。反过来再算一遍，就能判断等价。

这个方法看起来很机械，但实操中有一个效率痛点：如果F和G都很大，依赖条数多，每条依赖都要算一次闭包，计算量不小。所以考试和面试中给的依赖集通常不会太大，但“逐个验证、不要漏”的原则依然适用。

5.2 实例：判断两个依赖集是否等价

设F = {A→B, A→C, AB→D}，G = {A→BCD, B→D}。判断F与G是否等价。

先检查F的依赖是否能由G推出。在G下计算A⁺：初始{A}。A→BCD，加入B、C、D。闭包为{A, B, C, D}。检查F的第一条A→B，B在闭包中，成立。第二条A→C，C在闭包中，成立。第三条AB→D，左边是AB，需要在G下计算(AB)⁺：初始{A, B}。A→BCD，加入C、D。闭包为{A, B, C, D}。D在闭包中，成立。所以F的所有依赖都被G蕴含。

再检查G的依赖是否能由F推出。在F下计算A⁺：初始{A}。A→B，加入B；A→C，加入C；AB→D，A和B都在，加入D。闭包为{A, B, C, D}。检查G的第一条A→BCD，BCD都在闭包中，成立。计算B⁺：初始{B}。B没有出现在任何依赖的左边，闭包为{B}。检查G的第二条B→D，D不在闭包中，不成立。

结论：F不等价于G，F蕴含G中的A→BCD，但G中的B→D无法由F推出。

这个例子的另一个观察是：虽然F里没有直接写B→D，但也别急着认为G必定不等价于F，因为闭包计算的结果说了算。这类“看起来不对称”的情况很常见，一定要算完再下结论。

5.3 等价性判定的工程意义

你可能觉得等价性判定是纯理论问题，离实际工作很远。其实不是。在做数据库表结构重构时，你可能会调整字段依赖，比如把冗余字段去掉、把大表拆成多个小表。你要保证重构前后的数据约束是一致的，也就是说，重构后的函数依赖集与原依赖集等价。如果不等价，说明你在拆分过程中丢失了某些约束，可能导致数据不一致。

我见过有人重构表结构时只关注字段数量减少，完全不验证依赖集等价性，上线后出现重复数据、解析异常才发现问题。如果当时花十分钟做一次依赖等价性验证，这些问题都能提前暴露。从这个角度说，函数依赖集的等价性判断是一个很有工程价值的预热检查。

6. 例题拆解四：最小函数依赖集的求解

6.1 最小依赖集的三条判定标准

一个函数依赖集F称为最小函数依赖集，必须同时满足三个条件：

• F中每个依赖的右边都是单属性。
• F中不存在冗余依赖，即从F中删除任何一个依赖后，所得依赖集与F不等价。
• F中不存在冗余属性，即对于依赖X→Y，X中的任何属性都不能被删除后仍保持等价。

注意，第一条“右边单属性”是形式要求，第二条和第三条是内容要求。实际求解最小依赖集的算法正好对应这三个条件，顺序也很重要，一般是先处理右边、再处理左边、最后删冗余，但不同教材顺序略有不同，我下面给出的是我个人反复验证后认为最不容易出错的顺序。

6.2 完整求解算法与步骤

输入依赖集F，输出最小依赖集。

第一步，把每个依赖的右边拆成单属性。比如X→YZ拆成X→Y和X→Z。

第二步，处理每个依赖左边多余的属性。对每条依赖X→Y，假设X = A₁A₂...Aₙ，对于每个属性Aᵢ，计算(X − Aᵢ)⁺在原始F下是否包含Y。如果包含，说明Aᵢ是多余属性，把它从左边删掉，并更新依赖集。

第三步，删除冗余依赖。对每条依赖X→Y，在去掉该依赖后的依赖集F'下计算X⁺，如果Y包含在X⁺中，说明该依赖冗余，删除它。

这个顺序的建议来自我的实操经验：先拆右边，让依赖变短，后面算闭包更轻松；先删左边冗余再删依赖，可以避免依赖删除导致的连锁变化。有教材是先删依赖再删左边冗余，结果也正确，但步骤会重复，容易算乱。

6.3 实例：求解最小函数依赖集

给定F = {A→BC, B→C, AB→D, AC→E, E→A}。

第一步，拆右边：F变为{A→B, A→C, B→C, AB→D, AC→E, E→A}。

第二步，删左边冗余属性。

先看AB→D。试删A，计算B⁺在当前F下：初始{B}。B→C，加入C。此时闭包为{B, C}，不包含D，所以A不能删。试删B，计算A⁺：初始{A}。A→B，加入B；A→C，C已在；B→C，C已在。此时闭包为{A, B, C}，不包含D，所以B不能删。AB→D保留。

再看AC→E。试删A，计算C⁺：初始{C}。没有依赖以C为左边，闭包为{C}，不包含E，A不能删。试删C，计算A⁺ = {A, B, C}，不包含E，C不能删。AC→E保留。

第三步，删冗余依赖。

按序检查每条依赖。先看A→B，去掉它后，在F' = {A→C, B→C, AB→D, AC→E, E→A}下计算A⁺：初始{A}。A→C，加入C；AC→E，A和C都在，加入E；E→A，A已在。闭包为{A, C, E}，不包含B，所以A→B不冗余。

看A→C，去掉它后，F' = {A→B, B→C, AB→D, AC→E, E→A}，计算A⁺：初始{A}。A→B，加入B；B→C，加入C；AC→E，A和C都在，加入E；E→A已在。闭包为{A, B, C, E}，包含C吗？包含。所以A→C是冗余依赖，删除。

更新F = {A→B, B→C, AB→D, AC→E, E→A}。

继续检查B→C，去掉它后，F' = {A→B, AB→D, AC→E, E→A}，计算B⁺：初始{B}。B没有出现在任何依赖的左边，闭包为{B}，不包含C，B→C不冗余。

检查AB→D，去掉它后，F' = {A→B, B→C, AC→E, E→A}，计算(AB)⁺：初始{A, B}。A→B已在；B→C，加入C；AC→E，A和C都在，加入E；E→A已在。闭包为{A, B, C, E}，不包含D，AB→D不冗余。

检查AC→E，去掉它后，F' = {A→B, B→C, AB→D, E→A}，计算(AC)⁺：初始{A, C}。A→B，加入B；B→C已在；AB→D，A和B都在，加入D。闭包为{A, C, B, D}，不包含E，AC→E不冗余。

检查E→A，去掉它后，F' = {A→B, B→C, AB→D, AC→E}，计算E⁺：初始{E}。E不在任何依赖左边，闭包为{E}，不包含A，E→A不冗余。

最终得到最小依赖集Fm = {A→B, B→C, AB→D, AC→E, E→A}。

6.4 最小依赖集的多个版本问题

这里有一个很多人不知道的知识点：同一个函数依赖集的最小依赖集不一定是唯一的。因为第三步删除冗余依赖的顺序不同，可能得到不同的结果。这是正常现象，并不是你算错了。在考试中，如果题目没有要求特定的删除顺序，一般只要你的结果满足三个判定条件，都算正确。

实操中我习惯先处理那些左边属性较少的依赖，这样往往能更早地删掉冗余，后续步骤计算量更小。这个策略仅供参考，不保证最优，但实测下来很省事。

7. 依赖集与范式判断：理论如何落到表设计

7.1 从依赖集判断范式级别

数据库范式与函数依赖有着直接对应关系。判断一张表属于第几范式，本质上就是分析依赖集中的依赖类型。

第一范式要求属性原子性，这个与函数依赖无关，是表结构的底线。第二范式要求消除非主属性对候选码的部分函数依赖。翻译成依赖集的语言：检查是否存在某个非主属性，它函数依赖于候选码的真子集。在之前的候选码例题中，候选码是AB和AC，如果存在B→C而C是非主属性，就存在部分依赖，属于第二范式违规。

第三范式要求消除非主属性对候选码的传递依赖。判断方法：是否存在非主属性Y，使得存在X满足X→Y，但X不是候选码。更严格地说，是是否存在非主属性对候选码的传递依赖。BC范式（BCNF）要求所有依赖的左边都包含候选码，这个检查最干脆。

我建议你把四种范式的判定条件和依赖集特征整理成一张速查表，遇到题目直接对照：

7.2 无损分解与依赖保持

范式分解有两个性质必须同时关注：无损连接性和依赖保持性。函数依赖集在这里扮演着检验工具的角色。

无损分解的判定用自然连接检验，也可以通过依赖集推导来判断：将分解后的关系进行自然连接，再检验函数依赖是否仍然成立。依赖保持性则更直接：分解后所有关系模式上的函数依赖的并集，是否等价于原依赖集。如果不保持依赖，虽然数据没有冗余，但插入、更新时可能无法检查某些约束，导致数据异常。

实际项目里，我通常会优先保证依赖保持，因为约束的完整性比消除轻微冗余更重要。如果两者冲突，再看业务场景，有些场景甚至可以接受一定程度的反范式化，但这已经超出函数依赖集的范畴了。

8. 常见错误与排查技巧实录

8.1 闭包计算中的典型错误

闭包计算错误集中在三个地方。

第一个错误是忘记加入初始属性集。比如求(AE)⁺，只从空集开始，或者只加入能推导出的属性，忽略了A和E本身。这个错误在前面的例题中几乎必然出现，因为A和E不一定在依赖的右边。

第二个错误是过早停止迭代。有些初学者扫描完一轮，发现没有新属性加入，就认为计算结束了。实际上，一轮扫描结束后新加入的属性，可能在下一轮会触发新的依赖。正确的结束条件是在连续一轮完整扫描中没有任何新属性加入，才算闭包收敛。

第三个错误是忽略了依赖左边需要全部在闭包中。比如依赖AB→D，闭包中只有A没有B，就不能触发这条依赖。这个错误在属性多、依赖多的时候特别容易犯，解决办法是逐条依赖检查，而不是凭记忆判断。

8.2 候选码求解中的常见错误

候选码求解中，最大的问题是漏算候选码。很多同学找到一个候选码之后就不再继续找，但题目有时候会存在多个候选码。判断是否找全的方法是：所有候选码必须包含相同的L类和N类属性，不同之处在于LR类属性的搭配。

另一个常见错误是忘记验证“最小性”。只验证K⁺ = U就草率得出结论，没有检查真子集的闭包。如果一个属性集的真子集的闭包也是U，那么它才应该被看作候选码，K反而不是。这种情况在依赖集设计巧妙的题目里很常见。

8.3 最小依赖集求解中的注意事项

最小依赖集求解的坑主要在“顺序”上。如果先删冗余依赖，再处理左边冗余属性，可能因为依赖被删了导致原本判定为多余的属性变得不冗余，从而漏删。反过来，先处理左边再删依赖，能避免这个问题。

另外，拆右边之后，依赖数量变多，闭包计算工作量加大。别嫌麻烦，这是必要步骤。如果跳过第一步，直接在原依赖集上做后续操作，得到的结果可能不满足“右边单属性”条件，被判定为错误。

8.4 一张问题排查速查表

把上述经验整理成一张速查表，方便你在做题或复查时对照排查。

这张表里的每一行都对应着真实踩过的坑，我在带新人做表结构评审的时候，也经常让他们对照这张表自查依赖集分析过程。

9. 函数依赖集的学习路径建议

如果你是被考试逼着学这块，我的建议是：不要死记硬背定义，而是把闭包计算练到肌肉记忆。每天手算三道闭包题，坚持一周，你会发现几乎所有依赖集问题都能拆解成“求闭包”这一个动作。函数依赖集这个知识点就是这么特别——概念虽然抽象，但解题手法高度统一，本质上就是闭包的反复应用。

如果你是为了工作中学，我的建议略有不同。先去理解真题背后的设计目标：为什么需要候选码、为什么需要范式分解、为什么需要保持依赖。这些理论最终都是为了回答一个问题：你的表结构在数据约束上是否健康。函数依赖集是回答这个问题的语言，真正掌握了它，你在做数据库建模评审时就能说出“这里存在传递依赖，建议拆分”而不是“感觉不太对，要不拆一下吧”。

我个人的体会是，函数依赖集这个知识点最有价值的瞬间，不是在考试卷上拿到满分，而是在项目里发现了一处因为依赖分析不到位导致的数据冗余，然后用半小时重构表结构，让数据量减半、查询性能提升的那一刹那。理论这时候就不再是理论了，它是你手里的工具。

最后再分享一个小技巧：如果你在做综合题时卡住了，先别急着套公式，把依赖集写在纸上，把涉及的所有属性列出来，先用闭包把所有能推的属性都推一遍。做完这步，90%的题目思路都会自己浮现出来。剩下的10%，就是本文里反复强调的那些细节了。