Boyce Codd 分解后的剩余函数依赖关系？

Question

这个分解示例是在课堂上给出的，但是解决方案令人困惑，因为它似乎留下了一些 FD 未解决的问题。请确认3）下面是BCNF，还是不能放入BCNF？

Let R be a relation schema, with schema(R) = {C,T,H,R,S,G}

set of FDs F over R :
C->T
HR->C
HT->R
CS->G
HS->R

分解：

1) C T H R S G
2) C T      C H R S G
3) C T      H R C       H R S G 
end. (Not further decomposed.)

在 3) HRSG 包含属性 R 和 G，但似乎不满足 ht->r 或 cs->g。

ht->r 打折，因为我们在 HRSG 中没有 t cs->g 打折，因为我们在 HRSG 中没有 c

如果函数依赖的 LHS 包含不在关系中的属性，是否有规则不适用 FD？谢谢

Answer 1

FD 仍然适用于整个数据库设计。

每个 FD 始终是某些业务规则的表达。所有规定的业务规则始终适用，无论它们是在数据库模式的 1 表版本还是在其分解版本上强制执行。但是，将它们表示为 FD 要求 FD 中涉及的所有属性出现在同一个 relvar 中（因为这就是它们的发明方式：作为一种表达适用于 relation 模式的规则的方式（请注意，它确实 not 在这里说“数据库模式”）。逻辑结果是 FD 根本无法表达“跨越”多个关系模式的规则。that 的逻辑结果是它在新版本中，“分解关系模式”将/可能导致某些 FD 变得无法表达（不是“不适用”）是正常的。

(1) 在分解/归一化为 BCNF 后仍可表达的 FD，可以通过将 FD 的 LHS 声明为关系模式的键来“实现”。

(2) 在分解的模式中变得无法表达的 FD 必须以数据库约束的形式在整个数据库设计中恢复。这个“数据库约束”与对应于（1）中的那些 FD 的键约束非常相似，因为这些数据库约束也是某种“键”，它们只是不是数据库模式中关系的键，相反，它们是可在数据库模式中定义的“虚拟”关系（也称为“视图”）的关键。此视图是所涉及的关系模式的 JOIN（因此，“从分解的部分重新组合”）的投影（恰好在 FD 任一侧提到的属性上）。

这是很多话，可能很难理解，但过程是（对于 cs->g）：将分解的关系模式重新连接在一起（通过 HR，再次给我们一个关系 HRCSG），项目向下FD中涉及的属性（因此，向下投影到CSG），在这种关系中，CS必须是一个关键。

请注意，我在这里说的“关键”是指不能允许相同的 CS 值组合以不同的 G 值出现。从某种意义上说，这是您可以对任何 DBMS 做出的声明以强制执行此类规则。如果 DBMS 能够有效地做到这一点，那么数据库设计会容易得多 :-) 这意味着规则的执行，并确保没有任何数据会违反此规则，现在由您来决定。

幸运的是，实际上这些情况并不多，而且大多数时候您会注意到原始版本中的绝大多数 FD 最终只是作为 BCNF 表上声明的键。