Database design 数据库-功能依赖项和候选键

我在理解函数依赖项和候选键时遇到了一个大问题。我目前正在做一个项目，我必须确定“两个”候选键，并且只能有四个功能依赖项。我的整个关系是：

R(A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U,V,W)

我的功能依赖性是：

B -> A,C,D,G
M -> K,L,N
W -> R,T,S
BH -> Q,P,O,U,I,V,J,K,L,M,E,F,W

因此，我将我的候选密钥计算为：

[BH]

但是，我需要有第二个候选密钥，因为我已经尝试了所有可能的解决方案，但没有一个匹配所有属性。我在网上看了很多视频，但我仍然很困惑，为什么我不能得到第二个候选密钥是因为我做错了

谢谢

---

Kieran

对于给定的函数依赖集，{B，H}是唯一可能的候选键。As

B

和

H

是仅出现在给定FDs左侧的唯一属性，因此闭包（BH闭包）给出了关系R的所有属性

---

如果需要找到两个候选密钥，那么可能给定的FD集的格式错误。

我也只得到{B，H}。你确定这是作业吗？@philipxy是的，基本上我必须做我的函数依赖，但我也不确定它们是否正确。谢谢你的帮助！听起来您需要更改函数依赖项。这是“制造”另一个候选密钥的唯一方法。不过，我想我从来没有见过这样的作业。你是说你是那些FD的生成者吗？从什么初始信息？我猜你的意思是，FD是由现实世界中应用程序关系的性质决定的。如果你觉得可以询问CK推导，你能找到一种方法来询问，比如说，你的FDs证明中的第一个错误吗？也许通过解释规范的各个方面来证明每个FD的合理性？谢谢，我一直在尝试对它们进行排序，因为我需要它们用于一个项目，然而，我已经对它们进行了修改，但我认为只有一个仍然存在。我和我的经理谈过，他同意只有一个。但我仍然不确定我的新FDs是否有意义，我将很快更新帖子