【问题标题】:BCNF: Looking for example that actually uses superkey instead of candidate keyBCNF:寻找实际使用超级键而不是候选键的示例
【发布时间】:2019-01-20 11:55:32
【问题描述】:

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

这与上面的问题完全相同。

我实际上想知道是否有没有候选键的示例。但为什么定义会超出必要的范围呢?或者定义是否等效,因为依赖项总是可以转换的?

【问题讨论】:

  • 根据 superkey & CK 的定义,每个 CK & superkey 决定了每个属性子集。因此,如果您允许 CK 确定某些事物作为 any 条件(包括 BCNF)的一部分,您还必须允许超级键确定这些事物,因为如果CK 可以。

标签: database key relational-database database-normalization bcnf


【解决方案1】:

关键是,在定义范式时,我们必须将其表达为一般形式,作为所有保持某种关系的函数依赖的属性。

相反,当我们推理特定的关系模式时,我们通常只有所有函数依赖项的一个子集(因为它们的数量可能太大,可能与属性的数量成指数关系)。使用的特定依赖集合,通常用字母 F 表示,有一个特殊的属性:它是关系中所有依赖关系的覆盖,也就是说,我们可以从中导出所有依赖关系通过以所有可能的方式应用一组公理(称为阿姆斯特朗公理)来建立关系。

F,与关系模式中的属性一起指定的依赖项集,可以以不同的方式给出:例如,在练习中,它们可以作为练习的输入,在真实的数据库设计中,它们可以描述一个集合被认为对建模某个真实词域等很重要的约束。

即使它们是从有关要通过数据库建模的情况的知识中提取的,它们也可能包含其他已经给定的依赖关系,或者可能包含冗余属性等。

由于这些原因,找到给定依赖集的规范覆盖被认为是规范化的重要第一步,即由一组依赖构成的覆盖:a)具有rigth 部分只有一个属性; b) 在左侧没有多余的属性(即可以删除的属性保持作为封面的属性); c) 没有多余的依赖(即可以通过阿姆斯壮公理从其他人推导出的依赖)。

现在让我们考虑一下 BCNF 的一般定义:

关系模式 R 在 BCNF 中当且仅当对于 F+ 的每个非平凡依赖 X → Y,X 是一个超键。

注意我们说的是F+中的依赖,也就是F的闭包,也就是包含了all R 中的依赖关系并以某种方式从 F 派生。因此,如果关系 R 具有候选键 XK,显然不仅 XK → T 成立,因为例如,但是对于 XK 的所有超集 S,我们将有 S → T 成立,因此范式的定义必须允许这些依赖关系。

现在,可以根据 BCNF 的一般定义证明以下定理,它在某种程度上简化了它(并使检查关系是否已经在 BCNF 中的测试变得有效):

定理:关系模式 R 在 BCNF 中当且仅当对于 F 的每个非平凡依赖 X → Y,X 是一个超键。

看到区别了吗?我们现在谈论的是 F 而不是 F+

这个定理有以下推论:

推论:关系模式 R其中 F 是规范覆盖,当且仅当对于 F 的每个非平凡依赖 X → A,X 是一个候选键。

由于规范覆盖中的依赖项没有多余的属性,如果关系在 BCNF 中,则每个行列式(函数依赖项的左侧)显然都是候选键(不是通用超键),这就解释了差异在定义和我们有时在书本上找到的示例之间。

【讨论】:

  • 这对我有很大帮助并消除了我的困惑。您找到了问题的根源 :-) 感谢您花时间写出所有这些内容!
猜你喜欢
  • 2011-04-30
  • 1970-01-01
  • 2013-10-29
  • 2012-05-21
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多