来自数据库系统概念教科书，针对具有依赖关系 F r 对于 F + 中的所有依赖关系（即 F 的关闭），将在BCNF中考虑 ） a→b 形式，至少有以下一项必须为真：
教科书提供的示例是针对具有功能依赖关系 F dept_advisor （ s_ID，i_ID，dept_name ）的示例> = { i_ID→dept_name; s_ID，dept_name→i_ID }，BCNF分解为：
此分解实现了第一个依赖关系（ i_ID→dept_name ），因为 i_ID 是 r2 的超级密钥，但由于它不满足第二个依赖项（ s_ID，dept_name→i_ID ，因此是非依赖项保留），这种分解不会遵循BCNF，因为第二个依赖关系是非常重要的，但不是该模式的超级密钥。分解？
答案 0 :(得分：1)
您已正确报告BCNF的定义：对于F + 的每个非平凡依赖关系，行列式都是超级密钥。
因此，在您的示例中，分解中的关系模式都满足此定义：在r2中唯一的非平凡依赖i_ID → dept_name中，行列式是超级密钥，而在{{1}中没有非平凡的依赖关系，所以仍然满足定义。所以你有两个模式都在BCNF。
但是，正如您已经正确注意到的那样，依赖项r1并不包含在分解的依赖关系集中（即使您执行{{1的依赖关系集合的关联） }和s_ID, dept_name → i_ID），这意味着分解不会保留依赖关系。在实践中，这意味着在分解的模式中，r1和r2的几个值可能对应于s_ID的多个值，因此丢失了一个重要的值诚信约束。
这个例子可以教给我们什么？我们可以在BCNF中分解模式，从而生成可能包含不一致数据的数据库。请注意，在这种特殊情况下，BCNF中存在 no 分解，可以保留依赖关系。因此，BCNF并不是消除数据库设计中所有问题的灵丹妙药，实际上已经定义了其他常规形式，可以用来缓解数据库设计的几个问题。例如，该示例的原始模式已经采用第三范式（3NF），在实际情况下这被认为是可接受的。