【问题标题】:BCNF and Functional dependencyBCNF 和功能依赖
【发布时间】:2018-02-25 11:45:44
【问题描述】:

我试图理解分解为 BCNF。我已经阅读了很多例子,但我仍然不明白一些事情。我按照answer 尝试解决以下问题:

属性是客户名称(A)、地址(B)、电话(C)、id(D),账户有数字(E)、类型(F)和余额(G)。

如果客户只有一个 id、姓名、地址和电话号码,而帐户只有一个号码、类型和余额,并且由一个且只有一个客户拥有,那么会有哪些功能依赖关系?使用 R(ABCDEFG) 的这些依赖关系给出 BCNF 分解

到目前为止我的成果:

首先获取问题中指定的FD:

D -> ABC // If we agree on same customer ID, then we agree on the name, address and phone #
E -> DFG // If we agree Account number, then we agree on customer ID, account balance and account type

我们唯一的候选键是:{E},因为所有属性都可以通过这个属性获得。

由于没有多余的左侧属性,也没有多余的 FD,所以我得出以下关系表:

R1={D, A, B, C}
R2={E, D, F, G}

这两个关系中的键被标记为bold

现在要检查 BCNF,我们检查这些关系 (R1,R2) 是否违反 的条件BCNF即对于每个功能依赖X->Y左侧(X必须是一个超级键强>)。

现在我们可以看到 E -> DFG 的左侧是一个超级键。但是 D -> ABC 没有左侧是超级键。所以FD违反了BCNF。但我不知道如何分解成 BCNF。

【问题讨论】:

  • 嗨。您似乎没有使用术语或正确证明。参考您正在关注的演示文稿。数十种已出版的学术教科书 pdf 可在线免费获得。 (“获得”不是一个定义或明确的术语 re CKs。当一些持有时持有的 FD 都是阿姆斯特朗公理给出的,包括琐碎的。“多余的左侧属性”和“冗余 FD”是什么意思--它们是您参考中演示文稿的一部分吗?--您为什么“来到”这些模式?每个组件都有自己的 FD 和 CK。在 BCNF nontrivial 中,FD 必须在超级键上。等等.)
  • @philipxy 已经在帖子中指定了:stackoverflow.com/a/34350122/9139313
  • 谢谢,抱歉我错过了那个链接。无论如何,SO 帖子应该是独立的。好的,这解释了你的一些措辞和结论。您仍然需要正确学习和使用术语和流程。

标签: database database-normalization relational 3nf bcnf


【解决方案1】:

当您检查分解关系的 BNCF 是否满足时,您必须分别检查每个关系的函数依赖关系。

因此,在R1={D, A, B, C} 中,唯一的(候选)键是D(正如您所指出的),所有重要的依赖项都只有D 作为左侧部分;在 R2={E, D, F, G} 中,唯一的(候选)键是 E,其中所有重要的依赖项只有 E 作为左侧部分。所以在这两种关系中都没有违反 BCNF 的(非平凡的)依赖关系,因此分解是正确的,不需要做任何其他事情。

【讨论】:

  • 我不太明白。您是否将 FD 的左侧与候选键或关系进行比较?因为从另一篇文章中说,左侧必须是超级键。这不是指候选键吗?
  • 候选键是确定所有其他属性的一组属性,超键是候选键的超集(非严格超集)。因此,在 R1 中,所有可能的(非平凡的)依赖项都是 D-> A、D->B、D->C、D->AB、D->BC 等,D->ABC。在所有这些情况下,D 都是候选键,所以它是一个超键,所以依赖关系不会违反 BCNF。在这种情况下有什么不清楚的地方?
  • 好吧,澄清一下,每个函数依赖都必须存在一个关系,这样函数依赖的左侧就是那个关系的超键?
  • 不,分解是根据算法完成的(例如,对于 BCNF,有分析算法),在分解的关系中,原始依赖集可能有几个功能依赖关系。例如,分析算法只处理有问题的依赖关系(即违反正常形式的)。
猜你喜欢
  • 2015-04-08
  • 1970-01-01
  • 1970-01-01
  • 2012-10-17
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-01-09
相关资源
最近更新 更多