Question

我有一份应该明天提交的作业我正常地了解规范化概念，但在某些问题上我遇到了困难。我应该如何将其标准化为BCNF？你能告诉我们这些步骤吗？

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

FD set

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

对于这个实现我必须找到键并标准化为BCNF .. 如果我归一化到2NF，我会松开一些不适合3NF的关系。所以我很困惑。任何帮助将不胜感激..

谢谢

Answer 1

数据库有三种基本要求，处于第三范式：

如果你在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来说，除了R1之外，所有关系都遵循BCNF，因为H-> E关系在R1中保持，而H不属于R1中的候选键。

例如，Beeri和Bernstein在1979年表明，通过保留原始表中所包含的依赖关系，BCNF模式不能表示一组功能依赖性{AB→C，C→B}。请阅读wiki了解更多详情。

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

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

但上述表格不符合原始关系AE-> H，使它不一致，并且通过保留原始表中保存的依赖关系，这种关系是BCNF无法实现的。

Answer 2

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

一个常见的误解是你可以从1NF和

中的关系开始

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

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

这在StackOverflow的示例中发生了 lot 。（2NF到5NF或6NF，即。）

在您使用的乐谱中表达的作业问题中，您应该假设起始关系是1NF。你的第一份工作是识别钥匙。为什么？因为除非你能识别出部分密钥依赖关系，否则你无法规范化为2NF，除非你知道所有候选密钥，否则你不能那个。

将钥匙识别为AEF和AFH是正确的。由于依赖性之一是A-> D，因此关系R不在2NF中。 D仅取决于A，A是候选键的部分。要标准化为2NF，请标识所有部分键依赖关系，并通过投影消除它们。

从这开始。

删除部分密钥依赖关系A-＆gt; D.

R ₂是6NF。

从R中删除该部分密钥依赖关系导致R ₁。函数依赖性DF-> BC不适用于R ₁，因为R ₁不包含属性D.但是DF-> BC仍然适用于整体设计。这是令你困惑的一点。

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

Answer 3

从这开始。

R（ABCDEFH），键{AEF，AFH}
删除部分密钥依赖性A-＆gt; D和E-＆gt; C。

R1（ABEFH），键{AEF，AFH}
R2（ A D）
R3（ E C）

R1，R2和R3为2NF。

从R中删除该部分密钥依赖关系会导致R1。功能依赖性DF-> BC不适用于R1，因为R1不包含属性D.但DF-> BC仍然适用于整体设计。这是令你困惑的一点。

在这里，我继续迈克的评论。

您必须注意，即使R1不包含属性D，R1也包含A.如AF-＆gt; DF-＆gt; BC，依赖DF-> BC仍保留在R1中。

对于3NF，我们需要删除传递依赖性DF-＆gt; B和DF-＆gt; C，我们得到：

R1（AEFH），键{AEF，AFH}
R2（ A D）
R3（ E C）
R4（ D F B C）

所有关系都在3NF。