为什么非依赖性保留 BCNF 分解仍然被认为是在 BCNF 中？
Why is a non-dependency preserving BCNF decomposition still considered to be in BCNF?
来自 数据库系统概念 教科书，对于模式 r 的集合BCNF 中要考虑的依赖项 F，对于 F+[= 中的所有依赖项53=]（即F的闭包a → b，至少有一个以下必须为真：
- a → b 是一个简单的函数依赖 (b ⊆ a)
- a 是模式 r
的超级键
教科书给出的例子是，对于一个schema dept_advisor (s_ID,i_ID,dept_name) 与功能依赖 F = {i_ID → dept_name; s_ID, dept_name → i_ID}，BCNF分解为：
- r1 (s_ID, i_ID)
- r2 (i_ID, dept_name)
这个分解满足第一个依赖关系（i_ID → dept_name）因为i_ID是 r2 的超级键，但由于它不满足第二个依赖项 (s_ID, dept_name → i_ID，因此是非依赖性保留），这个分解是否不遵守 BCNF，因为第二个依赖性是重要的但不是分解模式的超级键？
您已经正确报告了 BCNF 的定义：对于 F+ 的每个非平凡依赖项，行列式是一个超级键。
因此，在您的示例中，分解中的两个关系模式都满足此定义：在 r2 中，在唯一的非平凡依赖性 i_ID → dept_name 中，行列式是一个超级键，而在 r1 没有非平凡的依赖关系，所以仍然满足定义。所以你有两个模式都在 BCNF 中。
但是，正如您再次正确指出的那样，依赖项 s_ID, dept_name → i_ID 在分解的依赖项集中不成立（即使您对 r1 和 r2)，这意味着分解不会保留依赖关系。实际上，这意味着在分解模式中 s_ID 和 dept_name 的一对值可能对应于 i_ID 的多个值，因此丢失了一个重要的完整性约束。
这个例子能教给我们什么？我们可以分解 BCNF 中的模式，从而生成可能包含不一致数据的数据库。请注意，在这种特殊情况下，BCNF 中 no 分解可以保留依赖关系。所以BCNF并不是解决数据库设计中所有问题的灵丹妙药，实际上已经定义了其他范式，可以用来缓解数据库设计中的一些问题。例如，示例的原始模式已经是第三范式（3NF），这在实际情况下是可以接受的。
来自 数据库系统概念 教科书，对于模式 r 的集合BCNF 中要考虑的依赖项 F，对于 F+[= 中的所有依赖项53=]（即F的闭包a → b，至少有一个以下必须为真：
- a → b 是一个简单的函数依赖 (b ⊆ a)
- a 是模式 r 的超级键
教科书给出的例子是，对于一个schema dept_advisor (s_ID,i_ID,dept_name) 与功能依赖 F = {i_ID → dept_name; s_ID, dept_name → i_ID}，BCNF分解为：
- r1 (s_ID, i_ID)
- r2 (i_ID, dept_name)
这个分解满足第一个依赖关系（i_ID → dept_name）因为i_ID是 r2 的超级键，但由于它不满足第二个依赖项 (s_ID, dept_name → i_ID，因此是非依赖性保留），这个分解是否不遵守 BCNF，因为第二个依赖性是重要的但不是分解模式的超级键？
您已经正确报告了 BCNF 的定义：对于 F+ 的每个非平凡依赖项，行列式是一个超级键。
因此，在您的示例中，分解中的两个关系模式都满足此定义：在 r2 中，在唯一的非平凡依赖性 i_ID → dept_name 中，行列式是一个超级键，而在 r1 没有非平凡的依赖关系，所以仍然满足定义。所以你有两个模式都在 BCNF 中。
但是，正如您再次正确指出的那样，依赖项 s_ID, dept_name → i_ID 在分解的依赖项集中不成立（即使您对 r1 和 r2)，这意味着分解不会保留依赖关系。实际上，这意味着在分解模式中 s_ID 和 dept_name 的一对值可能对应于 i_ID 的多个值，因此丢失了一个重要的完整性约束。
这个例子能教给我们什么？我们可以分解 BCNF 中的模式，从而生成可能包含不一致数据的数据库。请注意，在这种特殊情况下，BCNF 中 no 分解可以保留依赖关系。所以BCNF并不是解决数据库设计中所有问题的灵丹妙药，实际上已经定义了其他范式，可以用来缓解数据库设计中的一些问题。例如，示例的原始模式已经是第三范式（3NF），这在实际情况下是可以接受的。