4

什么时候 BCNF 分解不能保留功能依赖性...我试图弄清楚这个说 R=(V,W,X,Y,Z)

4

4 回答 4

10

取自数据库设计和关系理论：

R = (S, J, T)

{S, J} -> {T}
{T} -> {J}

这不在 BCNF 中，因为T -> J它持有并且T不是密钥。

将其分解为键R1 = (T, J)和键。导致 BCNF。R2 = (T, S){T}{T, S}

但是，依赖关系{S, J} -> {T}丢失了。

于 2013-07-26T13:15:15.020 回答
2

BCNF 分解的重点是消除不属于形式的函数依赖key -> everything else

因此，如果一个表有一个 FD，比如 A -> B，这样 A 不是键，这意味着您在表中存储了冗余数据。结果，您创建了一个包含列 A 和 B 的新表，其中 A 是键，然后从原始表中删除 B。

由于此更改，您将不再遭受删除异常的困扰，也不必为了更改 A -> B 关系而更新多行。

因此，对于一个简单、幼稚的示例，假设您有一个包含列的员工表：

 employeeId   name   jobTitle    salary

假设也就是说jobTitle -> salary，每个拥有相同职位的人总是获得相同的薪水。假设“开发人员”的职位名称相当于 90,000 美元的薪水。如果您的数据库中有 20 个开发人员，那么为每行存储 90,000 美元的相同冗余值将是愚蠢的。因此，您从员工表中删除薪水列，并创建一个新的薪水表：

 jobTitle_[key]   salary

然后，要获得员工的薪水，您可以在薪水表中查找。

于 2011-11-15T21:13:05.100 回答
1

R(abcde) 与 FD { A->B,AC->D,BD->E}。在这种关系中，AC 是候选键，并且这种关系不在 2NF 中，因为非素数 B 部分依赖于键（AC）。将此关系转换为 bcnf 分解为两个关系： R1(ab ) {a->b} key = a R2(acde) {ac->de} key =a R1 和 R2 都在 bcnf 中，因为每个行列式都是一个 key ，但它们不是依赖保留，因为 bd->e 丢失了。

于 2014-08-18T04:07:23.647 回答
0 
Schema R=(V,W,X,Y,Z)

Functional dependencies:

V,W -> X
Y,Z -> X
  W -> Y

分解为 BCNF，您将看到所有 FD 都不能保存在一次分解中。

于 2013-05-17T23:23:15.823 回答