schema - 对 BCNF 的困惑

Question

Schema：R(A,B,C,D,E,F,G,H,I,J)和功能依赖FD = { A->DE, IJ->H, I->A, J->FG, G->BC }

问题： BCNF中有关系吗？

答：不是因为Ais not superkey。

我知道在什么条件下关系在 BCNF 中，但一直让我感到困惑的是superkey. 谁能解释为什么答案A不是超级键？为什么不选择，例如，IJ或者I作为超级键？ķ

Answer 1

一个人不会“选择”超级密钥。给定模式和功能依赖关系，一些属性集是候选键。候选键的每个超集都是一个超键。

不过，候选密钥的概念通常是根据超级密钥来定义的。超级键是确定每个属性的一组属性。候选键是一个超键，它没有作为超键的适当（较小）子集。

定义“超级键”的另一种方法是一组属性，其中每个子行的值都是唯一的。因此，我们经常通过说它是“唯一的”来表达或识别一组属性是一个超键。

（您可以任意“选择”一个候选键作为“主键”，但这与关系理论无关。将您的选择告诉 DBMS 可能会影响它的功能。具有讽刺意味的是，一组列在 SQL 状态中声明为 PRIMARY KEY它是一个超级键，不一定是候选键，即不一定是主键。就约束而言，它意味着 UNIQUE NOT NULL。）

当某些功能依赖关系存在于模式中时，其他功能依赖关系就会存在。共同持有的是根据阿姆斯特朗公理原件所暗示的那些。{A} 要成为超键，它的某个子集必须是候选键。但鉴于您的一组函数依赖关系，{} 和 {A} 都不是候选键。{I} 也是如此。但是{IJ}，如果你确定它的闭包，就确定了所有的属性。所以它是一个超级密钥。它的每个超集也是如此。由于它没有适当的子集，因此它也是候选键。

Answer 2

BCNF 的定义要求关系的非平凡函数依赖不R具有作为超键的行列式（左侧）。超级键是确定关系的所有属性的一个属性或一组属性。因此，如果至少一个依赖项具有不是超键的行列式，则该关系不在 BCNF 中。

在这个例子中，我们可以从任何依赖项开始。让我们从A → DE. 我们可以A通过计算它的闭包来检查它是否是一个超级键，看看它是否包含所有的属性：

A+ → A
A+ → ADE (because of A → DE)

不能添加其他属性，因此A不是 的超键R，并且关系不在 BCNF 中。

同样，我们可以看到I,J和G不是超级键。

实际上这个关系有一个唯一的候选键，这个IJ事实可以通过计算它的闭包来检查IJ+。这意味着每个超级键必须包含IJ.