子模式中未出现具有功能依赖项的依赖项保留分解

时间:2019-01-24 06:49:54

标签: database-normalization relational-algebra functional-dependencies

我正在读一本教科书,其中包含以下问题:

Given the following relation R {A,B,C,D,E,H} and the functional 
dependencies AB->CD, BC->D, C->H, D->HB, CH->AE
does the following decomposition is dependency preserving?
R1(A,C,E,H) R2(B,D,H), R3(A,B,C), R4(B,C,D)

教科书的答案是它实际上是功能依赖项保留,我认为这不是因为依赖项AB->D
Reading this answer使其更加混乱,因为它使它看起来像
if there is a key inside one of the sub relations, the decomposition must be dependency preserving
我无可争议的反例是
For the two rows a1 b1 c1 d1 h1 e2 and a2 b1 c2 d2 h2 e2
R持有的所有F.D,但现在R3已拥有
a1 b1 c1 and a2 b1 c2
并且R4具有 b1 c1 d1 and b1 c2 d2
在B上将R3和R4连接在一起会得到a1 b1 c2 d2,这会破坏AB->D F.D

1 个答案:

答案 0 :(得分:1)

在示例中,依存关系被保留,如AntC在注释中所示。

在分解关系中存在原始关系的候选键的条件并不能保证保留依赖性。

例如考虑具有依赖项<script src="//code.jquery.com/jquery-2.2.4.min.js"></script> <img src="hello.png" />和分解R(A B C D E){A → E, BCE → A, D → C}R1(A B D)的关系R2(A E)。关系R1包含原始关系(R3(C D))的候选键之一,但是在分解过程中,不保留依赖项{ABD}

原始键之一存在于一个分解关系 中这一事实可能表明分解是无损的,但通常无损分解与依赖项保留之间没有关系(请参阅参考资料)。实例this)。但是,结果以某种方式将两个属性联系在一起,如对所引用问题的回答所示。