分解为第二范式
Decomposition into second normal form
我得到了以下第一范式的关系：
R(A,B,C,D,E,F) with ABC candidate key and AB->DE, C->E as functional dependencies
是否分解：
R1(A,B,E)
R2(C,E)
R3(A,B,C,F)
有没有办法防止 E 产生的冗余？ （意味着当我分解 R 使其成为第二范式时，E 在 R1 和 R2 中出现了两次）
1.关于问题
I got following Relation in first normal form...
每个关系在定义上已经是第一范式，所以没有必要指定它。
R(A,B,C,D,E,F) with ABC candidate key and AB->DE, C->E as functional dependencies.
如果 R 中的 只有 非平凡依赖项是指定的两个，则 ABC 不是候选键（因为缺少 F）。另一方面，如果 ABC 是 一个候选键，这意味着在关系中还有一些其他的依赖关系，例如从它们 plus 其他两个我们可以通过某种方式推导出 ABC -> F 的依赖关系（因此 ABC 是一个键）。但是我们不知道哪些是其他依赖项，这会阻止正确的规范化。请记住，通常规范化过程从一组函数依赖项开始，而不是从以下信息开始：“XYZ 是候选键”加上“还有其他函数依赖项 f1、f2、fn”。
明确地说，在你的情况下，例如你可以有另一个依赖 C -> F 这样键 是 ABC，或者依赖 ABC -> F，还有在这种情况下，密钥 是 ABC，但归一化的结果将完全不同。
2。关于分解
在这里，我将对您剩下的问题进行一些考虑。
你说：
is the decomposition: 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 丢失了。
我得到了以下第一范式的关系： R(A,B,C,D,E,F) with ABC candidate key and AB->DE, C->E as functional dependencies
是否分解： R1(A,B,E) R2(C,E) R3(A,B,C,F)
有没有办法防止 E 产生的冗余？ （意味着当我分解 R 使其成为第二范式时，E 在 R1 和 R2 中出现了两次）
1.关于问题
I got following Relation in first normal form...
每个关系在定义上已经是第一范式，所以没有必要指定它。
R(A,B,C,D,E,F) with ABC candidate key and AB->DE, C->E as functional dependencies.
如果 R 中的 只有 非平凡依赖项是指定的两个，则 ABC 不是候选键（因为缺少 F）。另一方面，如果 ABC 是 一个候选键，这意味着在关系中还有一些其他的依赖关系，例如从它们 plus 其他两个我们可以通过某种方式推导出 ABC -> F 的依赖关系（因此 ABC 是一个键）。但是我们不知道哪些是其他依赖项，这会阻止正确的规范化。请记住，通常规范化过程从一组函数依赖项开始，而不是从以下信息开始：“XYZ 是候选键”加上“还有其他函数依赖项 f1、f2、fn”。
明确地说，在你的情况下，例如你可以有另一个依赖 C -> F 这样键 是 ABC，或者依赖 ABC -> F，还有在这种情况下，密钥 是 ABC，但归一化的结果将完全不同。
2。关于分解
在这里，我将对您剩下的问题进行一些考虑。
你说：
is the decomposition: 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 丢失了。