不保留函数依赖的分解

Question

何时BCNF分解不能保留功能依赖...我正在尝试解决这个问题，比如R =（V，W，X，Y，Z）.

- user990246

Answer 1

摘自《数据库设计与关系理论》：

R = (S, J, T)

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

这不符合BCNF，因为T -> J成立而T不是关键字。

将其分解为R1 = (T, J)和R2 = (T, S)，其中{T}和{T，S}分别是主键，符合BCNF。

然而，依赖关系{S，J} -> {T}丢失了。

- proskor

---

S 如何成为 R2 的键？难道不是因为 (T, S) 是只有在 BCNF 中才有效的关系，因为 T 和 S 之间没有依赖关系吗？ - underdisplayname

@soobster他并不是说S是R2的一个键，他是在说{T，S}作为一个整体是一个键。 - naicolas

Answer 2

BCNF分解的目的是为了消除不符合“键 -> 其他所有列”的函数依赖关系，以此来减少表中冗余数据。如果一个表有一个函数依赖关系，比如A -> B，其中A不是一个键，那么这意味着你在表中存储了冗余数据。因此，你需要创建一个新表，包括A和B两个列，其中A是键，然后将B从原始表中删除。 通过这种改变，你将不再遭受删除异常的困扰，也不必更新多行数据来更改A -> B关系。因此，举个简单的例子，假设你有一个员工表，包括以下列：

 employeeId   name   jobTitle    salary

假设 jobTitle -> salary，也就是说，每个拥有相同工作职称的人都有相同的工资。假设 "developer" 职位等价于 $90,000 的薪水。如果您的数据库中有20个开发人员，将重复存储每行的 $90,000 值是愚蠢的。因此，您可以从雇员表中删除薪水列，并创建一个新的薪水表，其中包含：

 jobTitle_[key]   salary

接下来，如果要查询员工的薪资，需要在薪资表中查找。

- Adam Rackis

---

这很有道理，但是否存在BCNF不保留依赖关系的情况？ - user990246

Answer 3

具有FDs { A->B,AC->D,BD->E}的R(a b c d e)。 在此关系中，AC是候选键，而且该关系不符合2NF，因为非主属性B对关键字(AC)部分依赖。 要将此关系转换为BCNF，请将其分解为两个关系：R1(a b ) {a->b} key = a和R2(a c d e) {ac->de} key =a。 R1和R2都符合BCNF，因为每个决定因素都是一个键，但它们不保留依赖项，因为bd->e已经丢失。

- user3747120

---

关键字应该等于“ac”，而不仅仅是“a”用于R2。 - Shubham Mittal

Answer 4

Schema R=(V,W,X,Y,Z)

Functional dependencies:

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

分解到BCNF，你会发现所有的FD都不能在单个分解中保留。

- Rayhunter

---

@stackuser 在这里提到的“分解”是指无损分解。而你的分解不是无损的。（“since”的背后逻辑是什么？） - philipxy