database - 关于关系规范化的问题

Question

例如，让我们考虑以下关系:

R (A,B,C,D,E,F)

其中粗体表示是主键属性

与

F = {AB->DE, D->E}

现在，这看起来是第一范式。它不能是第三范式，因为我有传递依赖，它不能是第二范式，因为并非所有非键属性都依赖于整个主键。

所以我的问题是:

1. 我不知道 F 和 C 是什么。我没有关于它们的任何功能依赖信息! F 不依赖于任何东西？如果是这样的话，我想不出任何解决方案来让 R 进入第二范式而不将其取出!

2. C 呢？ C 还存在未在函数依赖项列表中引用的问题。怎么办？

我试图让 R 进入第二范式是这样的:

R(A,B,D)

R' (D,E)

但如前所述，我不知道如何处理 C 和 F。它们是多余的吗，所以我只是将它们删除，上面的尝试是我将其转换为第二种形式所要做的全部(和第三!)？

谢谢

Answer 1

给定 R 的定义，{ A, B, C } 是主键，那么本质上存在函数依赖:

• ABC → ABCDEF

也就是说，A、B 和 C 的值本质上决定或控制 D、E 和 F 的值，以及它们决定自己的值这一微不足道的事实。

您有一些额外的依赖项，由集合 F 标识(它不同于属性 F - 表示法不是很恰当，可能会引起混淆^*):

• AB → DE
• D → E

正如您正确诊断的那样，系统处于 1NF 状态(因为 1NF 实际上意味着“它是一张表”)。它不在 2NF 或 3NF 或 BCNF 等中，因为传递依赖并且因为一些属性只依赖于 key 的一部分。

你是对的，你最终会得到以下两个关系作为分解的一部分:

• R₁(D, E)
• R₂(A，B，D)

你还需要第三个关系:

• R₃(A、B、C、F)

根据这些，您可以使用连接重新创建原始关系 R。关系集{R₁, R₂, R₃ }是原始关系R的无损分解。

---

^* 如果标识附属函数依赖集的 F 打算与属性 F 相同，那么该属性的定义就有些奇怪了。我需要查看关系 R 的示例数据，以便有机会了解如何解释它。