从函数依赖确定键
我正在学习数据库理论课程，在阅读后，我不清楚如何推断出键，给定一组函数依赖关系。
我有一个示例问题：
查找具有函数依赖关系的关系R（ABCDEFG）的所有关键字
AB → C CD → E EF → G FG → E DE → C BC → A 通过确定以下哪项是关键来展示您的知识。
a. BCDEF b. ADFG c. BDFG d. BCDE
有人可以通过我应该如何分解函数依赖关系来推断一些属性的组合是关键吗？ 我希望我会面对这些types的问题，我需要了解如何处理这些问题。
拿一个FD，例如AB→C
增加直到提到所有的属性，例如ABDEFG→CDEFG（注意，这相当于ABDEFG→ABCDEFG，因为A→A和B→B是平凡的）。
这告诉你，ABDEFG是一个超级键。
检查其他LHS是你的超级键的一个子集，其RHS包含你的超级键的其他属性。
那里有两个。 EF→G和FG→E。 从你的超级键中移除这些RHS的属性。 这样做给你两把钥匙，当然是超级钥匙，但不一定是不可减less的钥匙：ABDEF和ABDFG。
然而，从AB→C和CD→E，我们也可以推导出ABD→E。 因此，我们也可以从我们的ABDEF键中删除E。 这里令人讨厌的是当我说“检查其他FD”的时候，这显然意味着你也应该检查在你的FD集合中出现的任何FD（即从你给定的FD中派生的任何FD） …手工操作有点不切实际
validation您的结果是否正确的有用网站：
http://www.koffeinhaltig.com/fds/ueberdeckung.php
您现在应该能够确定选项c是一个关键。
UPDATE
链接现在被打破，不知道网站已经走了。 也许你仍然可以在追踪互联网历史的网站上find有用的东西。
这个video解释得非常好
那么这应该是相当简单的。 所有你需要做的就是closures给定的每个关键字，看它是否包含了R的所有属性。例如，关于BCDEF = ABCDEFG，因为BC – > A和BC是BCDEF的一个子集，所以如果EF用于FD EF – > G。由于这个闭包包含R的所有属性，所以BCDEF是关键。 采取closures的主要目的是看我们是否能够“达到”来自给定属性的每个属性。 闭包是我们可以通过导航FD实际达到的一组属性。
由于你在分贝理论课程，我会假设你有SQL经验，并试图将理论与实现上下文联系起来。
基本上，一个关系就是你在实现中引用的一个表，一个关键是可以用来标识一个UNIQUE行的任何一组属性（读取列）（在db理论中这将是一个元组）。 这里最简单的比喻是，一个键是你的主键，以及任何其他可能的列，你可以用它来标识关系中的单个元组（表中的行）。 所以，下面是这样做的基本步骤（我将通过示例A，然后您可以尝试其余的）：
- 列出所有不属于您build议的密钥的属性（所以BCDEF不包括A和G）。
-
对于每个你缺less的属性，通过函数依赖列表来查看你提出的关键是否能够推断出你缺less的属性。
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的关键。 我知道有一个这样的algorithm，它可能是在你的课程文本的某个地方。 也有可能是一个例子。 您应该手动进行操作，直到模式直观。
编辑：我会回去通过文本寻找这个algorithm的原因是，你的考试将被写入，而不是多选，因为它是一个数据库理论课程。 如果这是真的，那么你会得到更多的部分功劳，如果你可以有条不紊地遵循课程文本/注释中显示的符号。
主要目标是把钥匙变成关系，这应该certificate所提出的钥匙其实是钥匙。
好吧，我不是这个东西的专家，所以纠正我，如果我错了，但我的方法是消除不可能的答案
在这种情况下：
没有你的FD“给”你B，D或F …因为那些是关系的一部分，所以不能有不包含B，D和F的超级密钥…删除答案B（缺失B）。 ..删除答案d（F缺失）
现在让我们检查剩下的答案，如果它们包含足够的信息来获得关系的所有部分
回答一个（BCDEF）会“给”你B，C，D，E和F，所以你需要用FDfindA和G … A可以通过BC到达，G可以通过EF到达，所以回答a是一个关键
答案C（BDFG）将“给”你B，D，F和G，所以你需要findA，C和E使用FD … E可以达到FG … C可以达到DE（在通过FG达到E）…最后，A可以通过BC达到（在达到C之后）…
所以答案c是某种关键，因为整个关系可以这样访问…但是我不知道这是否足以适应正式的定义…如果我不得不猜测，我会说没有
码
如果代码与您长时间的解释相比较，那么下面是一个基于函数依赖关系find关键字的algorithm的25行实现：
lovasoa/find-candidate-keys/blob/master/find-candidate-keys.html
例
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"]]
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是一个超级密钥。 然后，我们将使用depnedencies的结果来确定它们是否是键。 （这里为什么我使用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.
