数据库关系不属于 BCNF 的最低限度证明是什么？

我有以下功能依赖性（它们代表我的关系上的所有功能依赖性）：

(1) BrokerName -> Office
(2) StockName -> Dividend
(3) InvestorId -> BrokerName
(4) InvestorId, Stockname -> Quantity
(5) InvestorId, Stockname -> Office

我通过使用这里的技术知道Youtube 视频 https://www.youtube.com/watch?v=YQt_kz3JgXI that (InvestorId, Stockname)是我唯一的候选键。

根据@nvogel 在这个 SO 线程中的解决方案 https://stackoverflow.com/questions/8437957/difference-between-3nf-and-bcnf-in-simple-terms-must-be-able-to-explain-to-an-8:

关系 R 在 BCNF 中，当且仅当满足每个非平凡 FD (X->A) 由 R 可知，以下条件为真：

(a) X 是 R 的超键

因为我知道 (1)、(2) 和 (3) 都是非平凡的 FD，其左侧是not就此而言，超级键或候选键，就是我需要说的来证明我的关系是不在BCNF？这个过程是证明关系不在 BCNF 中的正确方法还是有更好的方法？

我们需要知道allFD（功能依赖）用于确定 CK（候选键），而不仅仅是某些列表中的那些。查看 CK 的（正确和一般）定义或查找 CK 的算法（在已出版的教科书中，而不是 YouTube 视频中）。您的清单是否适当closure（持有的所有 FD）或cover（通过阿姆斯特朗公理暗示闭包中的 FD），无论使用哪个定义或算法？因为如果不是那么你就不能说你知道 CK 集合。您最初声称“具有以下功能依赖性”是不够的。您后来声称“它们代表所有[非平凡？]功能依赖关系”是错误的 - 如果这些成立，则 {InvestorId, Stockname} -> {Office} 也成立。您稍后将第 5 项添加到列表中并没有帮助 - 还有其他项。但是，即使阿姆斯特朗公理不会将任何 FD 添加到列表中，因此当列出的公理成立时，也不会有任何其他公理成立，为什么你还要这样做呢？think如果您没有，给定的列表在您的设计中是详尽的show it?

我们可能知道某些 FD 成立，并且阿姆斯特朗公理给出了如果这些 FD 成立则必须成立的所有 FD，但是要知道给定的 FD 形成覆盖，我们还必须证明不是由阿姆斯特朗公理生成的 FDdon't抓住。请注意，如果 X 在功能上不能确定 Y，则 X 的任何子集都不能确定 Y，并且 X 不能确定 Y 的任何超集。

同样，BCNF 的定义是在谈论all那些不平凡的FD，不仅仅是一些或封面中的那些。

另一方面，要证明 BCNF 的特定定义被违反，您需要做的就是给出some不平凡的 FD 不存在于超级密钥中。所以 -鉴于您的 FD 构成了封面，并且其中提到了每个属性--因此 {InvestorId, Stockname} 是唯一的 CK--是的，单独 1-3 中的任何一个就足够了，因为它们不是平凡的并且没有一个超出超级密钥。

PS 查找并关注一本（好的）出版的关于信息建模和数据库设计的学术教科书。数十本免费在线 PDF 版本。看斯坦福大学免费在线课程 https://lagunita.stanford.edu/courses/DB/RDB/SelfPaced/about及其 YouTube 视频（及其教授的教科书）。