我正在努力解决Carnonical Cover，依赖保存和无损分解。
这里的方法和想法是否正确？
R(ABCDEFG)
提供的是创建规范覆盖后的以下一组依赖项。我没有自己做规范的封面，但作业说我必须假设它已经完成了。
Fc:
A -> C
E -> A
C -> ABF
F -> CDG
A+ = ABCDFG
E+ = ABCDEFG
C+ = ABCDFG
F+ = ABCDFG
E = Candidate Key.
此功能依赖项列表位于 2NF 中，因为没有部分依赖项。但是，它不在 3NF 中，因为存在传递依赖项。
然而，分解为以下 4 个关系将导致它不仅在 3NF 中，而且在 BCNF 中
R1 = {E,A}
E -> A
R2 = {A, C}
A -> C
R3 = {CABF}
C -> ABF
R4 = {FCDG}
F -> CDG
我在 R1 中使用 A 作为 R2 的外键，使用 R2 中的 C 作为 R3 的外键等。
没有传递依赖关系，并且由于所有左侧都是各自关系中的候选键，因此在 BCNF 中。
是否也是无损和依赖保留的？
分解的内容
在标题中，您说：
分解依赖关系时的正确方法是什么
但是一个不是分解依赖关系，而是分解关系模式。因此，在这种情况下，这里有一个关系架构R(ABCDEFG)，其中包含一组功能依赖项，并且必须分解该架构。
什么是分解
分解生成一组具有以下属性的关系架构：a( 原始架构的每个属性都存在于某个(可能多个(子架构中;b( 不存在其他属性。此外，当一个关系子架构包含在另一个关系子架构中时，分解是多余的。在您的情况下，对于包含在R3中的R2也是如此：不需要同时具有这两种关系，因为它意味着无用的数据冗余。
什么是好的分解
为了真正有用，分解应该满足两个重要属性：保留功能依赖关系和保留数据(无损分解(。但是另一个属性表征了一个好的分解：它应该尽可能小：在太多的子模式中分解模式是没有意义的，因为这会产生一个非自然和复杂的数据库。
实际上，您的分解是无损的，并保留了依赖项。
如何分解
所有这些东西的最终目标是产生一个分解(无损和依赖保留(，其中子模式位于BCNF或3NF中。但是，使用功能依赖项的属性进行分解的简单解决方案并不是一个好的解决方案。为此，教科书中描述的算法可以为BCNF或3NF(BCNF的所谓"分析"算法和3NF的"合成"算法(生成分解，试图产生不太多的子模式。例如，本例中的"分析"算法在 BCNF 中生成以下分解，只有两个子架构：
R1 < (A B C D F G) ,
{ F → C
F → D
F → G
C → A
C → B
C → F
A → C } >
R2 < (A E) ,
{ E → A } >
这种分解是无损的，并保留了依赖关系(对于分析算法并不总是如此(。