3

这个分解示例是在课堂上给出的，但是解决方案令人困惑，因为它似乎留下了一些 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 不适用？谢谢

4

1 回答 1

2

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

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

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

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

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

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

Fortunately, in practice these cases are not too numerous, and most of the time you will notice that the vast majority of the FD's in your original version, end up simply as keys declared on BCNF tables.

于 2012-06-06T12:52:10.340 回答