【问题标题】：Determine Keys from Functional Dependencies从功能依赖中确定键
【发布时间】：2011-08-09 18:52:07
【问题描述】：

我正在上一门数据库理论课程，但在阅读了一组函数依赖项后，我不清楚如何推断键。

我有一个示例问题：

找到所有具有函数依赖关系的关系 R(ABCDEFG) 的键

AB → C
CD → E
EF → G
FG → E
DE → C
BC → A

通过确定以下哪些是关键来证明您的知识。

a. BCDEF             
b. ADFG           
c. BDFG           
d. BCDE

有人可以指导我如何分解功能依赖关系以得出某些属性组合是关键的结论吗？我预计我会面临许多此类问题，我需要了解如何解决。

【问题讨论】：

yrazlik's answer 中的视频实际上使用了 [1] 中介绍的方法，如果您有兴趣知道它为什么有效。（证明简短明了。） [1] H. Saiedian 和 T. Spencer，“计算关系数据库模式的候选键的有效算法”，计算机杂志，第一卷。 39，没有。 2，1996 年 2 月 [在线]。可用：pdfs.semanticscholar.org/ab3f/…。 [访问日期：2019 年 7 月 31 日]
@Leponzo 您在一些已删除的答案中给出的项目符号算法的介绍类似于您在此处删除的答案是不正确的。该算法要求 F 是持有的 FD 的覆盖，而不仅仅是持有的 FD 的集合。 PS 请use text, not images/links, for text--including tables & ERDs. 转述或引用其他文本。仅将图像用于无法表达为文本或增强文本的内容。无法搜索或剪切和粘贴图像。在图片中包含图例/键和说明。

标签： database functional-dependencies

【解决方案1】：

好吧，我不是这方面的专家，如果我错了，请纠正我，但我的方法是消除不可能的答案

在这种情况下：

您的 FD 都没有“给”您 B、D 或 F ...因为它们是关系的一部分，所以不可能有不包含 B、D 和 F 的超级键...删除答案 b（B 是缺失）...删除答案d（F缺失）

现在让我们检查剩余的答案是否包含足够的信息来获取关系的所有部分

回答 a (BCDEF) 将“给”您 B、C、D、E 和 F，因此您需要使用 FD 找到 A 和 G ... A 可以通过 BC 到达，G 可以通过 EF 到达，所以回答a是关键

回答 c (BDFG) 将“给”您 B、D、F 和 G，因此您需要使用 FD 找到 A、C 和 E ... E 可以通过 FG 到达 ... C 可以通过DE（FG到达E后）...最后BC可以到达A（到达C后）...

所以答案 c 是某种关键，因为可以通过这种方式访问整个关系......但我不知道这是否足以符合正式定义......如果我不得不猜测，我会说不

【讨论】：

答案 a 是一个真超键，这意味着它的某个真子集存在，它也是一个键。通常，“key”一词的意思是“不可约”，而 a. 不是这种情况。但是这些细节可能因一门课程而异...

【解决方案2】：

由于您正在学习数据库理论课程，因此我假设您具有 SQL 经验并尝试将理论与实现上下文联系起来。

基本上，关系是您在实现中称为表的内容，键是可用于标识唯一行的任何属性集（读取列）（在 db 理论中，这将是一个元组）。这里最简单的类比是键是您的主键，以及您可以用来识别关系中的单个元组（表中的行）的任何其他可能的列集。因此，以下是执行此操作的基本步骤（我将介绍示例 A，然后您可以尝试其余部分）：

列出所有不在您建议的键中的属性（因此 BCDEF 不包括 A 和 G）。

对于您缺少的每个属性，请查看功能依赖项列表，查看您建议的密钥是否能够推断您缺少的属性。

             a. So for A, you have BC -> A.  Since both B and C are in the proposed
                key BCDEF, you can infer that BCDEF -> A.  Your set now becomes
                BCDEFA.
             b. For G, again going through your FDs you find EF -> G.  Since both
                E and F are in BCDEFA, you can infer BCDEFA -> G.

因为您能够从 BCDEF 推断出 A 和 G，所以选项 a 是关系 ABCDEFG 的键。我知道有一个算法可以解决这个问题，它可能在你的课程文本中的某个地方。大概也有一个例子。您应该手动逐步完成，直到模式直观。

编辑：我会回过头来寻找这个算法的原因是你的考试很可能是写而不是选择题，因为它是一门数据库理论课程。如果这是真的，那么如果您能够有条不紊地遵循课程文本/笔记中展示的符号，您将获得更多的部分学分。

主要目标是将密钥转换为关系，这应该证明提议的密钥实际上是密钥。

【讨论】：

选项 a 确实是一个键，但不是不可约的。不可约的是选项 c。
是的，我真的看过选项 a。我并没有真正考虑指定/弄清楚哪些键是最小键，因为它不是问题的一部分。我记得在我的数据库理论课程中，识别最小键与识别任何键是不同的主题。因此，我选择将其从答案中排除，以避免混淆。
@Erwin，在进一步研究之后，我明白了你的意思。我认为问题中“关键”的使用含糊不清。这个问题的答案会根据“key”是否是候选键而有所不同。在这种情况下，您是对的，并且选项 a 不会是键，因为选项 a 的子集仍然是有效的超级键。
是的，我很抱歉不够清晰。我擅长 SQL 和在数据库中设计关系模型，但它的理论方面对我来说是新的。这个回应也帮助了我。谢谢！

【解决方案3】：

拿一个 FD，例如AB→C

增加直到所有属性都被提及，例如ABDEFG → CDEFG（注意这等价于 ABDEFG → ABCDEFG，因为 A->A 和 B->B 是平凡的）。

这告诉您 ABDEFG 是一个超级键。

检查其他 FD，其中 LHS 是您的超级密钥的子集，并且在其 RHS 上包含您的超级密钥的某些其他属性。

有两个。 EF→G 和 FG→E。从您的超级密钥中删除这些 RHS 的属性。这样做会给你两个键，它们肯定是超级键，但不一定是不可约的：ABDEF 和 ABDFG。

然而，从 AB→C 和 CD→E 我们也可以推导出 ABD→E。因此我们也可以从我们的 ABDEF 键中删除 E。这里令人讨厌的是，当我说“检查其他 FD”时，这显然意味着您还应该检查出现在您的 FD 集的闭包中的任何 FD（即任何可从您的给定 FD 集派生的 FD） ...而且手工操作有点不切实际...

验证您的结果是否正确的有用网站：

http://raymondcho.net/RelationalDatabaseTools/RelationalDatabaseTools

您现在应该能够确定选项 c 是一个键。

【讨论】：

BDF 不是候选键吗？由于 DF->C, EF->G, CD->E 我们有来自 BDF 的 G。
@NickRosencrantz：有四个候选键。 BDF 不是其中之一。他们都碰巧有四个属性。我根本不遵循您的演绎逻辑；您提到的 FD 中没有一个包含 B。
他提到了 DF->C 但没有说明。也许他误读了 DE->C。
@ErwinSmout 您能否逐步介绍如何将 AB→ C 扩充为 ABDEFG → CDEFG？我真的不明白。
有趣的是，你在四年后的同一天更新了你的答案 :) 除此之外，很好的解释。

【解决方案4】：

这应该是相当简单的。您需要做的就是关闭给定的每个键，看看它是否包含 R 的所有属性。例如，BCDEF = ABCDEFG 的关闭，因为 BC -> A 和 BC 是 BCDEF 的子集，所以如果 EF 为 FD EF -> G。由于这个闭包包含了 R 的所有属性，所以 BCDEF 是关键。使用闭包的主要目的是看看我们是否可以从给定的一组属性中“到达”每个属性。闭包是我们可以通过导航 FD 实际访问的一组属性。

【讨论】：

BCDEF 不是候选键，因为它是可约的。 (BC->E) 但 BCDF 是一个候选键。

【解决方案5】：

step1: since AB->C and CD->E.  then we get ABD->ABCDE(1)
step2: Given (1) and EF->G, then we get ABDF->ABCDEF, then ABDF->ABCDEFG(2),

所以 ABDF 是一个超级密钥。然后我们将使用依赖关系的结果来确定它们是否是键。（这就是我使用 BC->A 的原因，因为 A 是我的超级键的一部分，它依赖于 BC）。

step3: Given (2) and BC->A, we get BCDF->ABDF, so BCDF->ABCDEFG(3)   
step4: Given (3) and DE->C, we get BDEF->BCDE, so BDEF->ABCDEFG(4)   
step5: Given (4) and FG->E, we get BDFG->BDEF, so BDFG->ABCDEFG,    
So the Answer BDFG is right.

【讨论】：

【解决方案6】：

代码

如果代码对您的解释超过了冗长的解释，这里有一个 25 行的算法实现，该算法根据功能依赖关系查找键：

https://github.com/lovasoa/find-candidate-keys/blob/master/find-candidate-keys.js

示例

candidate_keys(["A","B","C","D","E","F","G"], [ [['A','B'], 'C'], [['C','D'], 'E'], [['E','F'], 'G'], [['F','G'], 'E'], [['D','E'], 'C'], [['B','C'], 'A'] ]) 返回 [["B","D","F","G"],["B","D","E","F"],["B","C","D","F"],["A","B","D","F"]]

【讨论】：