为何不保持依赖的BCNF分解仍被判定为符合BCNF？

嘿，这个问题其实戳中了BCNF分解的一个关键特性——BCNF的判定只关注分解后的每个模式自身是否满足BCNF定义，并不强制要求保持原有的所有函数依赖。咱们结合《数据库系统概念》里的dept_advisor(s_ID,i_ID,dept_name)例子来拆解清楚：

先明确BCNF的核心判定规则 #

对于模式r及依赖集F，若r符合BCNF，则F的闭包F⁺中所有形如a→b的依赖需满足以下至少一项：

1. a→b是平凡函数依赖（即b⊆a）；
2. a是模式r的超键。

分析原模式的问题 #

原模式dept_advisor的函数依赖集F是{i_ID→dept_name; s_ID,dept_name→i_ID}。咱们检查它是否满足BCNF：

• 对于依赖i_ID→dept_name：i_ID不是原模式的超键（原模式的候选键是(s_ID,i_ID)和(s_ID,dept_name)），且这是个非平凡依赖，因此原模式不满足BCNF。

拆解BCNF分解的判定逻辑 #

教材里对该模式的BCNF分解通常会得到两个子模式：

1. r1(i_ID, dept_name)：对应的依赖是i_ID→dept_name。这里i_ID是r1的超键（也是主键），完全符合BCNF的判定条件2，所以r1是BCNF模式。
2. r2(s_ID, i_ID)：这个模式里不存在非平凡的函数依赖，所有可能的依赖都是平凡的，自然满足BCNF的要求。

关键：“不保持依赖”不影响BCNF判定 #

原依赖集中的s_ID,dept_name→i_ID在分解后没有被保持——因为这个依赖涉及的三个属性被拆分到了两个不同的子模式里，无法在单个子模式中体现这个依赖关系。但这完全不影响分解结果的BCNF判定，原因很简单：
BCNF是一个子模式级别的判定标准，只要求每个分解出的子模式内部的函数依赖符合规则，对“是否保留原依赖集的所有依赖”没有强制要求。这也是BCNF分解和3NF分解的核心区别之一（3NF的合成法分解会保证保持依赖）。

总结 #

只要分解后的每个子模式都独立满足BCNF的定义，整个分解结果就会被判定为符合BCNF，不管原依赖集里的依赖有没有被全部保持。上述例子中，两个子模式都符合BCNF要求，所以这个不保持依赖的分解依然是合法的BCNF分解。

内容的提问来源于stack exchange，提问作者LYC