BCNF 分解不一定能保持函数依赖，**根本原因在于：为满足 BCNF 而进行的无损连接分解，可能被迫“打破”某些函数依赖所关联的属性集

BCNF（Boyce-Codd 范式）是比 3NF 更严格的范式。其定义为：关系模式 R 属于 BCNF，当且仅当对 R 的每一个非平凡函数依赖 X → Y，X 都包含（或就是）R 的一个超键（即 X 是候选键或其超集）。
换句话说：所有决定因素（左部 X）都必须是候选键（或至少是超键）。这消除了 3NF 中仍允许的“主属性对非主属性的传递依赖”所导致的异常（例如当决定因素是包含候选键的超键但非候选键本身时，3NF 允许，而 BCNF 不允许）。

✅ BCNF 与 3NF 的关系：

• BCNF ⊆ 3NF（满足 BCNF 必满足 3NF，但反之不成立）；
• BCNF 解决了 3NF 中未处理的、由主属性依赖于非候选键的决定因素引起的更新异常；
• 并非所有 3NF 关系都能保持无损连接且函数依赖保持地分解到 BCNF（BCNF 分解可能无法同时保证依赖保持）。

举例对比：
R(A,B,C), F = {AB → C, C → B}
→ 候选键：{A,B} 和 {A,C}（因 AB⁺=ABC, AC⁺=ABC）
→ C → B 是非平凡 FD，但 C 不是候选键 ⇒ 违反 BCNF（C 是决定因素但非超键）
→ 却满足 3NF：因为 B 是主属性（出现在候选键中），所以 C → B 不违反 3NF（3NF 允许主属性对主属性的依赖）
⇒ 此 R ∈ 3NF，但 ∉ BCNF。

BCNF 分解不一定能保持函数依赖，根本原因在于：为满足 BCNF 而进行的无损连接分解，可能被迫“打破”某些函数依赖所关联的属性集，导致该依赖无法在任一子模式中被直接表达（即不在任何子模式的闭包中），从而丢失语义约束。而 3NF 分解可同时保证无损连接和依赖保持，BCNF 则在严格性与实用性间做了取舍——优先保障无损连接和消除异常，牺牲依赖保持的可能性。

✅ 关键点：

• 函数依赖保持：指分解后所有子模式的函数依赖集之并的闭包，等于原关系函数依赖集 F 的闭包（即 ( \bigcup \pi_{R_i}(F) ^+ = F^+ )）；
• BCNF 要求每个非平凡 FD 的决定因素必须是超键 → 若某 FD 的决定因素不是超键，就必须分解；
• 但分解后，若该 FD 的左部和右部被分到不同子模式中，且没有子模式包含其全部涉及属性，则该 FD 无法被“局部蕴含”，也就无法保持。

🔹 经典反例（标准教材例）：

设关系模式
R(A, B, C)，函数依赖集 F = {A → B, B → C}

1. 候选键分析：
   　A⁺ = ABC ⇒ A 是候选键；
   　B⁺ = BC ≠ R；C⁺ = C；
   　故唯一候选键为 {A}。

2. 检查 BCNF：
   　B → C 是非平凡 FD，但 B 不是超键（B⁺ = BC ≠ R）→ 违反 BCNF。
   　需分解。

3. 按 BCNF 分解算法（基于违反依赖 B → C）：
   　令 R₁ = {B, C}（由 B → C 决定），R₂ = {A, B}（保留决定因素 B 和其余属性）
   　→ 分解 ρ = {R₁(BC), R₂(AB)}

4. 验证是否保持依赖：
   　- 在 R₁(BC) 上，F₁ = {B → C}（投影得）
   　- 在 R₂(AB) 上，F₂ = {A → B}（投影得）
   　⇒ ∪Fᵢ = {A → B, B → C}，看似完整？⚠️ 注意：B → C 可保持，但关键问题是：A → C 这个隐含依赖能否被推导？
   　其实更本质的缺失是：原始 F 中的传递依赖链 A → B → C 导致 A → C ∈ F⁺，但在分解后，R₁ 和 R₂ 中均不包含 {A,C} 共存的模式，因此 A → C 无法被任何子模式的 FD 推出（即不在 ∪πᵢ(F)⁺ 中）——但这不是必须保持的依赖。

❌ 真正不被保持的依赖其实是：原始 F 本身已完备，但问题出在——我们想保持的是 F，而 F 中的 A → B 和 B → C 在子模式中都存在，似乎已保持？那为何说“不保持”？

✅ 正确经典反例应为（更严谨、公认）：

R(A, B, C, D), F = {A → B, C → D}
候选键：因 A⁺ = AB, C⁺ = CD, AC⁺ = ABCD ⇒ 候选键为 {A, C}
检查 BCNF：

• A → B：A 不是超键（A⁺ = AB ≠ R）→ 违反 → 分解
• 取 R₁ = {A,B}, R₂ = {A,C,D}
  （按算法：R₁ = XY 其中 X→Y 违反，R₂ = R − Y + X = {A,C,D}）

投影依赖：

• π_{R₁}(F) = {A → B}
• π_{R₂}(F) = {C → D}（因 C,D ∈ R₂）✅
  → 似乎也保持了？

❗ 正确不可保持的例子需满足：某个 FD 的决定因素和依赖属性无法共存于同一子模式，且该 FD 不是其他子模式 FD 的逻辑结果。

✅ 标准权威反例（见《Database System Concepts》6e, Ex. 8.15）：

R(A, B, C), F = {AB → C, C → B}
候选键：AB（AB⁺=ABC），AC（AC⁺=ABC）→ 候选键为 {AB}, {AC}
检查 BCNF：C → B 中，C 不是超键（C⁺ = CB ≠ R）→ 违反
分解（用 C → B）：

• R₁ = {C, B}，F₁ = {C → B}
• R₂ = {A, C}（R − B + C = {A,C}），F₂ = ∅（因 AB→C 和 C→B 在 {A,C} 上投影均不成立：AB→C 缺 B，C→B 缺 B）
  ⇒ ∪πᵢ(F) = {C → B}，而 AB → C 完全丢失（A,B 不共存于任一子模式：R₁ 无 A，R₂ 无 B）
  ⇒ AB → C ∉ ({C→B})⁺ ⇒ 依赖未被保持。
  ✅ 验证：在 R₁ 和 R₂ 上执行自然连接恢复 R 时，可能引入额外元组（如 (a₁,c₁,b₂) 其中 b₂≠b₁），破坏 AB→C 约束。

因此：BCNF 分解确保无损连接，但为消除违反，可能将某个 FD 的全部属性拆散到不同子模式中，导致该 FD 无法在任何子模式中表达，也无法被推导，从而丢失依赖。

总结一句话：
BCNF 分解以“强制决定因素为超键”为铁律，当某 FD 的左部非超键时，分解会隔离其右部；若该 FD 的左右部又无法在后续子模式中重聚，则该依赖永久丢失——这就是依赖不能保持的本质。