我具有以下功能依赖关系（它们代表我的关系上的所有功能依赖关系）：
(1) BrokerName -> Office
(2) StockName -> Dividend
(3) InvestorId -> BrokerName
(4) InvestorId, Stockname -> Quantity
(5) InvestorId, Stockname -> Office
通过使用此YouTube video中的技术，我知道(InvestorId, Stockname)是我的唯一候选密钥。
根据@nvogel's solution in this SO thread：
对于每个满足的非平凡FD（X-> A），BC中的关系R满足 通过R满足以下条件：
（a）X是R的超键
由于我知道（1），（2）和（3）都是非平凡FD，因此它们的左手边不是 not 超级键或候选键，这就是我所需要的要证明我的恋人不是不是在BCNF中？这个过程是证明某个恋人不在BCNF中的正确方法还是有更好的方法？
答案 0 :(得分：2)
我们需要了解 all ，它们不仅可以确定CK（候选键），而且还可以确定CK（候选键）。查看CK的（正确和通用）定义或用于查找CK的算法（在已出版的教科书中，而不是youtube视频中）。无论定义或算法使用哪种形式，您的列表是适当的 closure （持有的所有FD）还是 cover （暗示通过Armstrong公理在闭合中的FD的FD）？因为如果没有，您就不能说您知道CK集。最初声称您“具有以下功能依赖性”是不够的。您后来声称“它们代表了所有[重要的]功能依赖项”，这是错误的，如果这些条件成立，InvestorId，Stockname-> Office也成立。您以后将项目5添加到列表中并没有帮助-还有其他项目。但是，即使Armstrong的公理不会在列表中添加任何FD，所以当列出的FD成立时也不会有其他FD持有，为什么您认为给定的列表在您的设计中是详尽无遗的如果您没有显示它？
我们可能知道有些FD成立，而阿姆斯特朗公理给出了所有必须持有的FD，但要知道给定FD构成了掩盖，我们还必须证明并非由阿姆斯特朗公理生成的FD >不要按住。请注意，如果X在功能上不能确定Y，那么X的子集不会确定Y，X不会确定Y的任何超集。
类似地，BCNF的定义所指的是所有持有的非平凡FD，而不仅仅是一些或掩盖的FD。
另一方面，您需要证明BCNF的特定定义被违反的原因在于，持有的 some FD并非不是超键。所以-鉴于那是唯一的CK -是的，仅1-3个就足够了，因为没有一个是超级键。
PS查找并遵循一本（很好的）出版的有关信息建模和数据库设计的学术教科书。数十个在线免费提供pdf。参见the Stanford University free online course及其youtube视频（及其教授的教科书）。