这个分解示例是在课堂上给出的，但解决方案令人困惑，因为它似乎让一些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-＆gt; r打折，因为我们在HRSG中没有 cs-＆gt; g打折，因为我们在HRSG中没有c
是否存在一条规则，即如果功能依赖的LHS包含不在关系中的属性，则FD不适用？感谢
答案 0 :(得分：2)
FD仍适用于整体数据库设计。
每个FD都是一些商业规则的表达。无论是在数据库模式的1表版本上还是在其分解版本上强制执行，所有声明的业务规则始终适用。但是，将 表示为FD 要求FD 中涉及的所有属性都出现在相同的relvar 中（因为这是他们的发明方式：作为一种表达适用于 关系 架构的规则的方式（注意它确实 不 在这里说“数据库模式”。逻辑上的结果是FD完全无法表达“跨越”超过一个关系模式的规则。 的逻辑结果是它在新版本中，“分解关系模式”将导致某些FD变得无法表达（ 不“不适用”），这不过是正常的。
（1）在对BCNF进行分解/归一化后仍然可以表达的FD可以通过将FD的LHS声明为关系模式的关键来“实现”。
（2）在分解模式中已经无法表达的FD必须在数据库约束的形式下在整个数据库设计中恢复。这个“数据库约束”非常类似于对应于来自（1）的那些FD的关键约束，因为这些数据库约束也是排序的“关键”，它们不是数据库模式中关系的关键，相反，它们是在数据库模式中可定义的“虚拟”关系（也称为“视图”）的关键。该视图是所涉及的关系模式的JOIN（s）（因此，“从分解的部分重构”）的投影（在FD的任一侧提到的确切属性）。
这是很多单词，也许很难遵循，但程序是（对于cs-＆gt; g）：将分解的关系模式连接在一起（通过HR，再次给我们一个关系HRCSG），项目向下FD中涉及的属性（因此，投射到CSG），在这种关系中，CS必须是关键。
请注意，我在这里说“key”是因为不能允许相同的CS值组合出现不同的G值。从某种意义上说，这是一个声明，您可以向任何DBMS强制执行此类规则。如果DBMS可以有效地做到这一点，那么数据库设计会更容易:-)这意味着规则的执行，并且确保没有数据会违反这条规则，现在取决于你。
幸运的是，在实践中这些情况并不是太多，而且大多数情况下您会注意到原始版本中的绝大多数FD最终只是在BCNF表上声明的键。