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->克。

HT-> r被打折的，因为我们没有吨余热锅炉 CS - > g的折扣，因为我们没有下，在余热锅炉

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

Answer 1

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

每个FD总是表达一些业务规则。所有声明的业务规则总是适用，无论它们是在数据库模式的单表版本上执行还是在其分解版本上执行。然而，表达他们作为FD要求所有参与FD属性出现在同一relvar（因为这是他们是如何发明：为表达一个应用于规则的一种方式关系模式（请注意，它不说“数据库模式”在这里）。合乎逻辑的结果是，FD的只是不能表达的规则，即“跨越”不仅仅是一个关系模式。的合乎逻辑的结果那是，它是正常的“分解关系模式”可能会导致一些FD变得难以形容（而不是“不适用”）在新版本中。 （1）通过将FD的LHS声明为关系模式的关键字，可以“实施”FD仍然可以在分解/归一化到BCNF之后被表达的FD。 （2）已经在分解的模式中变得不可表达的FD将不得不在数据库约束的形式下在整个数据库设计中恢复。这个“数据库约束”与（1）中对应于这些FD的关键约束非常相似，因为这些数据库约束也是一类的“关键”，它们不是数据库模式中关系的关键，相反，它们是可以在数据库模式中定义的“虚拟”关系（又称“视图”）的关键。该视图是所涉及的关系模式的JOIN（s）（因此，“从分解的部分重新构建”）的投影（正好在FD的任一侧提及的属性）。

这是很多单词，也许很难遵循，但程序是（对于cs-> g）：将分解后的关系模式（在HR之后，给我们一个关系HRCSG再次回来），向下投影到涉及FD的属性（因此，向下投影到CSG），并且在这个关系中，CS必须是关键。

请注意，我在这里说“关键”，因为不允许相同的CS值组合以不同的G值出现。不是说这是你可以对任何DBMS执行这样的规则的声明。如果数据库管理系统能够有效地做到这一点，那么数据库设计将会容易得多:-)意义规则的执行，并看到没有数据会违反这个规则，现在取决于你。

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