关于关系归一化的问题

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 等中，因为传递依赖以及某些属性仅依赖于部分键。

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

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

你还需要第三个关系：

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

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

---

^* 如果标识辅助功能依赖集的 F 旨在与属性 F 相同，那么该属性的定义就有些奇怪了。我需要查看关系 R 的样本数据才能知道如何解释它。

Answer 2

我认为R的主键设置错误。如果 F 在功能上与任何东西都不相关它必须是键的一部分

所以你有 R( ABCF DE) 现在是第一个范式（F = {AB->DE, D->E}）现在你可以把它改成第二个正常形式。 DE 不依赖于整个密钥（部分依赖），因此您将其置于另一个关系中以达到第二范式：

R( ABCF ) F = {}

R1(#AB DE) F = {AB->DE}

现在这个关系没有任何传递依赖，所以它已经是第三范式了。

Answer 3

F 不依赖任何东西？

不，您只是没有在表单中获得任何明确的信息

{something -> F}

对于 C 语言也可以这样说。您应该通过应用 Armstrong 的公理来推断其他依赖项。 （可能。）

想想如何完成这个：

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

• {ABC -> ?}

[稍后。 . .我看到乔纳森·莱弗勒打破了悬念，所以我就结束了。]

{ABC -> DEF}（根据定义）因此，

{ABC -> F}（通过分解。这是 F 和 C 的来源。这是你的第三个关系。）。