数据库 - 功能依赖和候选键答案

【问题标题】：Database - Functional Dependency and Candidate Keys数据库 - 功能依赖和候选键
【发布时间】：2016-03-26 20:46:50
【问题描述】：

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

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]

但是，当我做不到时，我需要有第二个候选键，因为我已经尝试了所有潜在的解决方案，但它们都不匹配所有属性。我在网上看了很多视频，但我仍然很困惑，是不是因为我做错了而无法获得第二个候选键？

谢谢，

基兰

【问题讨论】：

我也只有 {B,H}。你确定这是作业吗？
@philipxy 是的，基本上我必须做我的功能依赖，但我不确定它们是否正确。感谢您的帮助！
它听起来就像你应该改变功能依赖。这是您要“制造”另一个候选键的唯一方法。不过，我想我从未见过这样的作业。
您的意思是您是生成这些 FD 的人吗？来自什么初始信息？
我猜你的意思是，FD 是由现实世界中应用程序关系的性质决定的。如果你觉得可以询问 CK 的推导，你能找到一种方法来询问，比如说，你的 FD 理由中的第一个错误吗？也许通过解释规范的各个方面来证明每个 FD 的合理性？

【解决方案1】：

对于给定的函数依赖集，{B,H} 是唯一可能的候选键。因为B 和H 是唯一出现在给定FD 左侧的only 属性，并且闭包（BH-closure）给出了所有属性关系R。

如果您需要找到两个候选键，那么给定的 FD 集可能是错误的。

【讨论】：

谢谢你，我一直在尝试对它们进行排序，因为我需要它们用于一个项目，但是，我已经对它们进行了改造，但我认为只有一个。我和我的经理谈过这件事，他同意只有一个。仍然不确定我的新 FD 是否有意义，很快就会更新帖子