Question

我以第一范式获得了以下关系：具有ABC候选键且AB-> DE，C-> E的R（A，B，C，D，E，F）作为功能依赖性

分解是： R1（A，B，d，E） R2（C，E） R3（A，B，C，F）

有没有办法防止E产生的冗余？分解是否正确（1NF - > 2NF）？

@philipxy意味着当我分解R以使其成为第二范式时，E在R1和R2中出现两次

@philipxy好的，我通过使用以下依赖关系来指定候选键（在这种情况下只有一个）AB-＆gt; DE，C-＆gt; E，ABC-＆gt; DEF（来自ABC beeing候选键）可能有还写了ABC-＆gt; ABCDEF 通过删除每个属性并创建属性闭包，我接收ABC作为候选键，那么为什么你认为它不是候选键？

BCDEF->FD+ BCDEF
ACDEF->FD+ ACDEF
ABDEF->FD+ ABDEF
ABCEF->FD+ ABCDEF
ABCF->FD+ ABCDEF
ABC->FD+ ABCDEF

=＆gt; ABC是候选键

我没有消息来源，只是有人问我如何确定这个案子的第二个正常形式而且我卡住了 - 不能帮助自己，这就是我在这里问的原因。

@philipxy只是因为你不理解这个问题并不意味着这个问题是不可理解的。如果这是你的意见downvote。当给出ABC作为候选键时，FD ABC-> DEF是牵连的并且将是多余的。这就是为什么没有理由明确提及它。

Answer 1

<强> 1。关于这个问题

我以第一范式获得了以下关系......

根据定义，每个关系已经处于第一范式，因此没有必要指定它。

R（A，B，C，D，E，F）具有ABC候选键并且AB-> DE，C-> E作为功能依赖性。

如果R中的仅非平凡依赖项是指定的两个，那么ABC不是候选键（因为F缺失）。另一方面，如果ABC 是候选键，这意味着在关系中存在一些其他依赖关系，使得从它们 plus 我们可以在某些依赖关系中得到ABC的方式 - ＆gt; F（以及ABC是关键）。但我们不知道哪些是其他依赖项，这会阻止正确的规范化。请记住，通常标准化过程从一组函数依赖开始，而不是从信息开始：“XYZ是候选键”加上“还有其他功能依赖关系f1，f2，fn。”

明确地说，在你的情况下你可以有另一个依赖C - ＆gt; F，以便键是 ABC，或依赖ABC - ＆gt; F，在这种情况下，键是 ABC，但规范化的结果将完全不同。

<强> 2。关于分解

在这里，我将对您的其余问题进行一些考虑。

你说：

是分解：R1（A，B，E）R2（C，E）R3（A，B，C，F）

您提供的分解不正确分解，因为缺少D，并且分解必须包含原始关系的所有属性。由于这个原因，不可能说分解是任何正常形式（换句话说：它不是任何正常形式，因为它不正确）。
第二种正常形式不是一个重要的分解，它主要出于历史原因在数据库教科书中出现。没有正式的算法来生成它。在实践中最常用的是第三种正常形式和Boyce-Codd正常形式。还有第4和第5种常规形式，但它们在实践中并不经常使用，尽管对于某些人来说应该是这样。
您似乎认为，如果某个属性在分解的关系中出现多次而不是冗余。除非特殊情况，否则任何（重要的）正常形式的关系分解将总是产生存在于多个关系中的属性：实际上这是唯一的方式产生正确的分解（这是外键的用途！）。在此过程中没有任何“冗余”（相反，标准化过程用于消除或至少减少数据的冗余）。

<强>已更新

假设我们从三个函数依赖项（或任何等效的函数依赖集）开始：

A B -> D E
C -> E
A B C -> D E F

分解：

R1（A，B，D，E）R2（C，E）R3（A，B，C，F）

是Boyce-Codd的正常形式（因此它也在3NF和2NF中）（并保留了依赖关系）。

最后，我们可以注意到BCNF中的其他分解是可能的，例如使用“分析”算法我们可以产生以下分解，其中不复制属性E：

R1（A B D E）R2（A B C F）

但在这种情况下，依赖关系C - > E迷失了。

分解成第二范式

1 个答案: