Boyce–Codd范式的定义指出,所有非平凡的函数依赖项的决定因素都必须是超键。
我发现的BCNF中所有关系示例均使用候选键。我正在寻找一个示例,该示例实际上具有一个超级键作为决定因素,而不是候选键。
我无法提出仅使用超级键的关系,而该超级键无法转换为使用候选键。
比方说,我们与候选关键字有关系,而附加功能依赖项则由超键作为决定因素。
R1(A,B,C)
{A}
A,B -> C
此额外的FD是多余的,因为它包含明显确定另一个属性(A-> C)的候选键。
尝试用两个候选键构建另一个示例也是没有用的。
R2(A,B,C,D)
{A,B},{B,C}
A,B,C -> D
这与上面的问题完全相同。
我实际上在想是否还有没有候选键的示例。但是,为什么定义会超出必要范围呢?还是定义是等效的,因为始终可以转换依赖关系?
答案 0 :(得分:1)
关键是,在定义标准格式时,我们必须以通用格式将其表示为所有具有某种关系的功能依赖项的属性。
相反,当我们推理特定的关系模式时,通常通常只有所有功能依赖项的子集(因为它们的数量可能太大,可能与属性的数量成指数关系)。通常使用字母F表示的一组特定依赖项具有一个特殊的属性:它是关系中所有依赖项的 cover ,也就是说,我们可以从中推导所有依赖项。通过以所有可能的方式应用一组称为阿姆斯特朗公理的公理来实现这种关系。
F是在关系模式中与属性一起指定的一组依赖关系,可以用不同的方式给出:例如,在练习中,可以将它们作为练习的输入,在实际数据库设计中,它们可以描述一组对建模某个实词域等重要的约束条件,等等。
即使它们是从有关要通过数据库建模的情况的知识中提取的,它们也可能包含已由其他人暗示的依赖关系,或者可能包含冗余属性等。
由于这些原因,找到给定依赖项集的
现在让我们考虑BCNF的一般定义:
当且仅当对于F + 的每个非平凡依赖项X→Y,X是超键时,关系模式R
位于BCNF中。
请注意,我们在谈论的是F + 中的依赖关系,它是F的 closure ,换句话说,它包含 all R中包含的依赖项,并且以某种方式从F派生。因此,如果关系R具有候选键X K ,则显然不仅X K →T成立,对于实例,但是对于X K 的所有超集S,我们将拥有S→T成立,因此规范形式必须的定义必须允许这些依赖项。
现在,可以从BCNF的一般定义证明以下定理,以某种方式简化了该定理(并使检查BCNF中是否存在关系的测试有效):
定理:当且仅当对于F的每个非平凡依赖项X→Y,X是超键时,关系模式R
在BCNF中。
看到区别了吗?我们现在谈论的是F,而不是F + 。
该定理具有以下推论:
推论:当且仅当对于每个非平凡依赖项X→A的F为X时,BC为BCNF的关系模式R
,其中F为规范封面。候选密钥。
由于规范封面中的依赖项没有多余的属性,因此,如果关系在BCNF中,则每个行列式(功能依赖项的左侧)显然都是候选键(而不是泛型超键),这解释了差异在定义和我们有时在书上找到的例子之间。