database - 数据库关系不在 BCNF 中的最小证据是什么？

Question

我有以下函数依赖(它们代表了我关系上的所有函数依赖):

(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 :

A relation, R, is in BCNF iff for every nontrivial FD (X->A) satisfied by R the following condition is true:

(a) X is a superkey for R

因为我知道 (1)、(2) 和 (3) 都是非平凡的 FD，其左侧不是 super 键或候选键，所以我只需要证明我的关系不在 BCNF 中？这个过程是证明关系不在 BCNF 中的正确方法还是有更好的方法？

Answer 1

我们需要知道所有 FD(功能依赖)来确定 CK(候选键)，而不仅仅是某些列表中的那些。查看 CK 的(正确和一般)定义或查找 CK 的算法(在已出版的教科书中，而不是 youtube 视频中)。您的列表是否适本地是闭包(所有持有的 FD)或覆盖(通过阿姆斯特朗公理暗示闭包中的 FD)，无论该定义或算法使用哪个？因为如果不是那么你就不能说你知道这组 CK。您最初声称“具有以下功能依赖性”是不够的。您后来声称“它们代表所有 [nontrivial?] 函数依赖项”是错误的——如果这些成立，{InvestorId, Stockname} -> {Office} 也成立。您稍后将第 5 项添加到列表中没有帮助——还有其他项。但即使阿姆斯特朗公理不会将任何 FD 添加到列表中，所以当列出的公理成立时不会有任何其他公理成立，您为什么认为给定列表在您的设计中是详尽无遗的如果你没有展示呢？

我们可能知道某些 FD 成立，并且 Armstrong 公理给出了所有必须成立的 FD，但要知道给定的 FD 形成一个覆盖层，我们还必须证明不是由 Armstrong 公理生成的 FD 不要坚持。请注意，如果 X 不能在功能上确定 Y，则 X 的子集不能确定 Y，并且 X 不能确定 Y 的任何超集。

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

另一方面，要证明违反了 BCNF 的特定定义，您需要做的就是给出 一些 非平凡的 FD，它持有的不是超键。所以——假设你的 FD 形成一个封面并且其中提到了每个属性——所以 {InvestorId, Stockname} 是唯一的 CK——是的，1-3 中的任何一个都足够了，因为它们非常重要，而且没有一个是超键之外的。

PS 查找并遵循一本(优秀的)已出版的关于信息建模和数据库设计的学术教科书。数十个以 pdf 格式免费在线提供。参见 the Stanford University free online course及其 youtube 视频(及其教授的教科书)。