BCNF分解?

时间:2015-06-07 10:09:45

标签: database database-design relational-database database-schema bcnf

给定关系 R(A,B,C,D,E) FDs = {A-> BC,CD-> E,B-> D,E - >一种}
在将R转换为BCNF时:

ABCDE - > BD& ABCE 将首先进行分解 BD在BCNF

关于ABCE:

  

意见1: ABCE有FD:A-> BCE,E-> ABC,BC-> AE
  因此它已经在BCNF

     

意见2 ABCE有FD:A-> BC,E-> ABC
  因此需要分解为ABC& AE

我认为第一个应该是正确的,因为在第二个我们假设A-> E和BC-> E是不可能的,因为D不是关系的属性之一。但我不确定。
请告知ABCE A-> E BC-> E 是否会持有?

1 个答案:

答案 0 :(得分:1)

您已正确识别问题所围绕的问题。也就是说,是否" BC-> AE"确实适用于ABCE。为了适用于ABCE,需要证明它适用于原始的ABCDE。你能证明吗? (提示:从原始的B-> D开始,用普通的C-> C增加以获得BC-> CD)。

现在进行重要讨论。请完全坐下来。

现在退一步看看第一次分解后架构/设计发生了什么。第一次分解将BD挑选出自己的表/模式。这留下了现有的FD" CD-> E"在任何剩余的表/模式中都无法表达(在ABCE中,因为那个没有D,因为那个没有ACE)。但是这个FD所表达的商业规则仍然适用。这意味着在替换设计中(BD单挑出来的设计),在两个表中定义了一个额外的约束,这个约束必须对两个表的组合产生相同的影响(它们的JOIN,就像FD在原始的单桌设计上一样。也就是说,该约束必须强制执行,在两个表的任何JOIN中,不会出现相同的CD值组合与不同的(> 1)E值一起出现的情况。

没有附加约束的替换设计永远不会完全等同于包含FD的原始设计。但是因为两个设计确实应该是等价的,所以应该允许你假设这个附加约束确实存在(并且相应的FD仍然适用于JOIN")。请注意,我个人从未见过或听说过明确说明。归一化理论的处理倾向于忽略其他约束,即使它们等同于早先给出的FD。

如果你不能做出这样的假设,并且你被迫只看其余的FD对他们所适用的个人表所暗示的含义,那么就没有办法证明BC-> AE在您的ABCE表/架构。你将被迫得出结论,选项2是正确的答案。

(这里有重要的结论。)唉,周围也有很多糟糕的教学,而且所有规范化理论课程在这些问题上采取相同的立场还远远不能确定。因此,虽然我的信念/意见是你是对的,不幸的是我的回答必须是"这取决于你的老师对他/她自己的理解化理论的理解程度如何。