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 cs-> g打折，因为我们在HRSG中没有c

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

Answer 1

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

每个FD都是一些商业规则的表达。 无论是在数据库模式的1表版本上还是在其分解版本上强制执行，所有声明的业务规则始终适用。 然而，表达他们作为FD要求所有参与FD属性出现在同一relvar（因为这是他们是如何发明：为表达适用于一个关系模式的规则的一种方式（请注意，它不说“数据库模式”在这里）。合乎逻辑的结果是，FD的只是不能表达的规则，即‘跨越’不仅仅是一个关系模式。 那合乎逻辑的结果是，它并不比正常的更是‘分解关系模式’，将/可能导致一些FD在新版本中变得无法表达（ 不是 “不适用” ）。

（1）在对BCNF进行分解/归一化之后仍然可以表达的FD可以通过将FD的LHS声明为关系模式的关键来“实现”。

（2）在分解模式中已经无法表达的FD必须在数据库约束的形式下在整个数据库设计中恢复。 这个“数据库约束”非常类似于对应于来自（1）的那些FD的关键约束，因为这些数据库约束也是排序的“关键”，它们不是数据库模式中关系的关键，相反，它们是在数据库模式中可定义的“虚拟”关系（也称为“视图”）的关键。 该视图是所涉及的关系模式的JOIN（s）（因此，“从分解的部分重构”）的投影（完全是在FD的任一侧中提到的属性）。

这是很多单词，也许很难遵循，但程序是（对于cs-> g）：将分解的关系模式（通过HR，再次给我们HRCSG关系）重新连接起来，投射到涉及的属性FD（因此，投射到CSG），在这种关系中，CS必须是关键。

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

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