-1

我有一个明天应该提交的作业我通常知道规范化概念，但在某些问题上我有困难。我应该如何将其标准化为 BCNF？你能显示步骤吗？

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

FD 集是

A->D
AE->H
DF->BC
E->C
H->E

对于这个问题，我必须找到密钥并标准化为 BCNF。如果我标准化为 2NF，我会失去一些不适合 3NF 的关系。所以我很困惑。任何帮助将不胜感激..

谢谢

4

3 回答 3

0

从这个开始。

R(ABCDEFH), keys {AEF, AFH}
移除部分键依赖 A->D 和 E->C。

R1(ABEFH), 按键 {AEF, AFH}
R2( A D)
R3( E C)

R1、R2 和 R3 在 2NF 中。

从 R 中删除部分键依赖会导致 R1。功能依赖 DF->BC 不适用于 R1，因为 R1 不包含属性 D。但 DF->BC 仍然适用于整体设计。这就是让你感到困惑的地方。

在这里，我继续 Mike 的评论。

您必须注意，即使 R1 不包含属性 D，R1 包含 A。因为 AF->DF->BC，依赖关系 DF->BC 仍然在 R1 中成立。

对于 3NF，我们需要去除传递依赖 DF->B 和 DF->C，我们得到：

R1(AEFH), 按键 {AEF, AFH}
R2( A D)
R3( E C)
R4( DF BC)

所有关系都在 3NF 中。

于 2013-04-18T12:13:59.393 回答
0

数据库要采用第三范式有两个基本要求：

  • 已经满足1NF和2NF的要求
  • 删除不完全依赖于主键的列。

如果你在 2NF 中标准化，你不会失去任何关系，而是会得到另一个关系。好的，现在让我们做你的功课。

让我们首先假设您的关系已经在 1NF 中。现在为 2NF

R1 = AE -> {H}(AE->H)
R2 = DF -> {B, C}(DF->BC)
R3 = A  -> {D}(A->D)
R4 = E -> {C}(E->C)

上述关系在 2NF 中，没有一个非主属性部分依赖于候选键。而且在 3NF 中也是因为关系中没有传递关系。

好的，现在对于 BCNF，所有关系都服从 BCNF，除了 R1，因为 H->E 关系在 R1 中成立，并且 H 不属于 R1 中的候选键。

Beeri 和 Bernstein 在 1979 年表明，例如，一组函数依赖关系 {AB → C, C → B} 不能通过保留原始表中保存的依赖关系由 BCNF 模式表示。阅读维基了解更多详情。

但是你仍然可以把它转换成BCNF，

R1 = A -> {E}
R2 = E -> {H}
R3 = DF -> {B, C}
R4 = A  -> {D}
R5 = E -> {C}

但是上面的表不包含原始关系 AE-> H，使其不一致，并且通过保留原始表中的依赖关系，这种关系是 BCNF 无法实现的。

于 2012-12-15T14:18:07.900 回答
0

要回答这个问题，而不是你对它的描述，是的，你可以从 1NF 标准化到 3NF，而不会在过程中停止在 2NF。

一个常见的误解是您可以从 1NF 中的关系开始，然后

  • 将它们归一化为 2NF且不更高，然后
  • 将它们归一化为 3NF且不更高，然后
  • 将它们归一化为 BCNF并且不更高。

这很常见，但它仍然是一个误解。您可以在任何数量的教科书中看到这种误解的反例，但您必须仔细查看它们的示例。据我所知，没有教科书明确指出这种误解，但如果你研究他们的例子，就会变得很明显。

在实践中，通常一步即可从 1NF 或 2NF 到 5NF 或 6NF。例如，从 2NF 到 5NF 仅意味着您删除了传递依赖，并且

  • 您没有发现左侧不是候选键的剩余依赖项（BCNF 需要），
  • 您发现没有剩余的多值依赖项（4NF 需要），并且
  • 您发现没有剩余的连接依赖项（5NF 需要）。

这在StackOverflow上的示例中经常发生。（即 2NF 到 5NF 或 6NF。）

在您使用的符号表示的家庭作业问题中，您应该假设起始关系在 1NF 中。您的第一项工作是识别密钥。为什么？因为除非您可以识别部分键依赖关系，否则您无法标准化为 2NF ，除非您知道所有候选键，否则您无法做到这一点。

您将密钥识别为 AEF 和 AFH 是正确的。由于依赖关系之一是 A->D，关系 R 不在 2NF 中。D 仅依赖于 A，而 A 是候选键的一部分。为了规范化到 2NF，识别所有部分键依赖关系，并通过投影消除它们。

从这个开始。

  • R(ABCDEFH), 键 { AEF, AFH }

删除部分键依赖 A->D。

  • R 1 (ABCEFH), 按键 { AEF, AFH }
  • R 2 ( A D)

R 2在 6NF 中。

从 R 中删除部分键依赖会导致 R 1。功能依赖 DF->BC 不适用于 R 1，因为 R 1不包含属性 D。但 DF->BC 仍然适用于整体设计。这就是让你感到困惑的地方。

大多数时候，功能依赖最终都是简单的键约束。这就是 FD A->D 变为 R 2时发生的情况。但是由于投影分割了 DF->BC 的左侧，因此必须以不同的方式表达这种依赖关系——作为数据库约束。（SQL 不擅长那个。CREATE ASSERTION 应该涵盖这些基础，但还没有人实现它。）

于 2012-12-15T16:30:12.410 回答