假设 R 具有以下属性:{A,B,C,D,E} 并具有以下功能依赖关系:
A -> BC
CD -> E
B -> D
E -> A
并且有一个由 R1(A,B,C) 和 R2(A,D,E) 组成的分解。如何计算 R1 和 R2 的函数依赖关系?
作业上的实际问题问我 R1/R2 是否在 BCNF/3NF/两者中,但我已经知道如何做这部分(查看 FD 的左侧是否包含在候选键中)。
假设 R 具有以下属性:{A,B,C,D,E} 并具有以下功能依赖关系:
A -> BC
CD -> E
B -> D
E -> A
并且有一个由 R1(A,B,C) 和 R2(A,D,E) 组成的分解。如何计算 R1 和 R2 的函数依赖关系?
作业上的实际问题问我 R1/R2 是否在 BCNF/3NF/两者中,但我已经知道如何做这部分(查看 FD 的左侧是否包含在候选键中)。
诀窍是将 FD 视为定义键,而不是在您给定的模式上,而是在它的 PROJECTIONS 上。
例如,在您的起始模式 {ABCDE} 中,FD A -> BC 表示 A ( {A}, 实际上) 构成此表上的一个键,向下投影到 {ABC}。也就是说,FD 的 LHS 和 RHS 的并集定义了哪个投影,而 LHS 定义了该投影上的键。
现在转到分解后的版本,其中有两个不同的表(模式){ABC} 和 {ADE}。
您的第一个和最后一个 FD 仍然可以在这些模式中表达。第一个模式/表上的第一个 FD 和后者上的最后一个。
但是剩下的两个由于分解而变得无法表达(即无法表达AS AN FD )。对于整个数据库设计,这意味着您必须声明/定义/实现一个数据库约束,该约束说和做与原始 FD 完全相同的事情。(这样做的一般方法如下:通过再次将分解连接在一起来重构原始表,投影连接到所提到的属性,并在该投影上强制执行键。对于诸如此类的情况,实现这一点并非易事这些课程练习。)
决定 R1/R2 是否在 xNF 中,现在必须只考虑那些仍然可表达的原始 FD (a->BC)。
我想你应该得出结论,R1 在 3/BC NF 中,而 R2 仍然不是。
诸如此类的示例(以及大多数课程练习都属于这种性质)实际上说明了规范化概念在数据库设计领域中被过分强调的荒谬。重要的是包含适用于数据库的所有约束的整体情况。