数据库关系不在 BCNF 中的最小证据是什么？
What is the minimal proof that a database relation is not in BCNF?
我有以下函数依赖（它们代表了我关系上的所有函数依赖）：
(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，其左侧 不是 超级键或候选键，我需要说的就是证明我的关系 不在 BCNF 中吗？ 这个过程是证明关系不在 BCNF 中的正确方法还是有更好的方法？
我们需要知道所有 用于确定 CK（候选键）的 FD（功能依赖），而不仅仅是某些列表中的那些。查看 CK 的（正确和一般）定义或查找 CK 的算法（在已出版的教科书中，而不是 youtube 视频中）。您的列表是否适当 closure（所有持有的 FD）或 cover（通过 Armstrong 公理暗示闭包中的 FD），以哪个为准该定义或算法使用？因为如果不是那么你就不能说你知道这组 CK。您最初声称 "have the following functional dependencies" 是不够的。您后来声称 "they represent all the [nontrivial?] functional dependencies" 是错误的——如果这些成立，{InvestorId, Stockname} -> {Office} 也成立。您稍后将第 5 项添加到列表中没有帮助——还有其他项。但是即使阿姆斯特朗公理不会将任何 FD 添加到列表中，所以当列出的公理成立时不会有任何其他公理成立，你为什么 认为 给定的列表是详尽无遗的在你的设计中如果你没有展示它？
我们可能知道某些 FD 成立，并且阿姆斯特朗公理给出了所有必须成立的 FD，但要知道给定的 FD 形成一个覆盖层，我们还必须证明不是由阿姆斯特朗公理生成的 FD 不要坚持。请注意，如果 X 在功能上不能确定 Y，则 X 的子集不能确定 Y & X 不能确定 Y 的任何超集。
同样，BCNF 的定义是在谈论所有 持有的非平凡 FD，而不仅仅是封面中的一些或那些。
另一方面，要证明违反了 BCNF 的特定定义，您需要做的就是给出 some 非平凡的 FD，它持有的不是来自超级密钥.所以--假设你的 FD 形成一个封面并且其中提到了每个属性--所以 {InvestorId, Stockname} 是唯一的 CK--是的，1-3 中的任何一个足够了，因为它们很重要并且 none 超出了超级密钥。
PS 查找并遵循一本（优秀的）已出版的关于信息建模和数据库设计的学术教科书。数十个以 pdf 格式免费在线提供。请参阅 the Stanford University free online course 及其 youtube 视频（及其教授的教科书）。
我有以下函数依赖（它们代表了我关系上的所有函数依赖）：
(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，其左侧 不是 超级键或候选键，我需要说的就是证明我的关系 不在 BCNF 中吗？ 这个过程是证明关系不在 BCNF 中的正确方法还是有更好的方法？
我们需要知道所有 用于确定 CK（候选键）的 FD（功能依赖），而不仅仅是某些列表中的那些。查看 CK 的（正确和一般）定义或查找 CK 的算法（在已出版的教科书中，而不是 youtube 视频中）。您的列表是否适当 closure（所有持有的 FD）或 cover（通过 Armstrong 公理暗示闭包中的 FD），以哪个为准该定义或算法使用？因为如果不是那么你就不能说你知道这组 CK。您最初声称 "have the following functional dependencies" 是不够的。您后来声称 "they represent all the [nontrivial?] functional dependencies" 是错误的——如果这些成立，{InvestorId, Stockname} -> {Office} 也成立。您稍后将第 5 项添加到列表中没有帮助——还有其他项。但是即使阿姆斯特朗公理不会将任何 FD 添加到列表中，所以当列出的公理成立时不会有任何其他公理成立，你为什么 认为 给定的列表是详尽无遗的在你的设计中如果你没有展示它？
我们可能知道某些 FD 成立，并且阿姆斯特朗公理给出了所有必须成立的 FD，但要知道给定的 FD 形成一个覆盖层，我们还必须证明不是由阿姆斯特朗公理生成的 FD 不要坚持。请注意，如果 X 在功能上不能确定 Y，则 X 的子集不能确定 Y & X 不能确定 Y 的任何超集。
同样，BCNF 的定义是在谈论所有 持有的非平凡 FD，而不仅仅是封面中的一些或那些。
另一方面，要证明违反了 BCNF 的特定定义，您需要做的就是给出 some 非平凡的 FD，它持有的不是来自超级密钥.所以--假设你的 FD 形成一个封面并且其中提到了每个属性--所以 {InvestorId, Stockname} 是唯一的 CK--是的，1-3 中的任何一个足够了，因为它们很重要并且 none 超出了超级密钥。
PS 查找并遵循一本（优秀的）已出版的关于信息建模和数据库设计的学术教科书。数十个以 pdf 格式免费在线提供。请参阅 the Stanford University free online course 及其 youtube 视频（及其教授的教科书）。