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

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

Answer 1

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

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

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

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

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

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

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