只有当表包含多个候选键时才能违反 BCNF？答案

【问题标题】：Can BCNF only be violated when table contains more than one candidate key?只有当表包含多个候选键时才能违反 BCNF？
【发布时间】：2014-06-16 05:14:46
【问题描述】：

我在一本书中读到：“只有当表包含多个候选键时，才能违反 BCNF。” 考虑以下示例： Sn Rollno Name Game 1 u11co098 Robert Basketball 2 u11ce034 Bob Cricket 3 u11co098 Robert Cricket 4 u11me049 Hogart Volleyball

从上表可以看出 Sn 是主键 FD Rollno -> Name Sn -> Rollno, Name, Game 现在根据上表的陈述是 BCNF 形式，因为它只有一个主键或候选键。 FDRollno -> Name不违反BCNF吗？（因为Rollno 不是候选键）

【问题讨论】：

哪本书？因为我们都应该避免它。 . .

标签： normalization database database-normalization bcnf

【解决方案1】：

首先，您发布的关系is not in 3NF 因为存在transitive dependency 之类的

Sn -> Rollno，名称，游戏

所以sn -> rollno 和Rollno -> Name

我们需要像下面这样分解模式

R1(Sn, Rollno, Game)

R2(Rollno, Name)

候选键是唯一确定所有其他字段的键；但是被选为主键的那个变成了PK。

定义：A table is said to be in BCNF if it don't have any overlapping candidate key

现在关系 R1 和 R2 都在 BCNF 中。

【讨论】：

关系模式 R 是 Boyce–Codd 范式当且仅当对于它的每一个依赖关系 X → Y，至少满足以下条件之一：1. X → Y is a trivial functional dependency (Y ⊆ X) 2.X is a superkey for schema R 但在Rollno -> Name , Rollno 不是候选键。
@Maverick，这就是我试图说的，在您发布的架构中没有重叠的 CK（因为只有一个 CK 只是 PK），所以它没有违反 BCNF。
Rollno -> Name 违反了两个条件：它不是一个小函数依赖（因为 Name 不是 Rollno 的子集）并且 Rollno 不是超级键。
@Maverick，我的错误.. 没有仔细阅读帖子。首先，您发布的关系不在 3NF 中。查看我的编辑。