Question

您好我正在学习将在11天后进行的考试。我正在努力解决Carnonical Cover，Dependency Preservation和Lossless Decomposition。我对正常形式和上述提到的主题也有点模糊，每当我做运动时，我似乎都搞砸了。我的问题是这里的方法和想法是否正确：

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中。

它是否也没有无损和依赖保留？

Answer 1

什么是分解

在标题中你说：

分解依赖项时的正确方法是什么

但是一个不分解依赖关系，而是分解关系模式。因此，在这种情况下，这里有一个关系模式grep -Ff patterns file，它具有一组功能依赖关系，并且必须分解该模式。

什么是分解

分解产生一组具有以下属性的关系模式：a）原始模式的每个属性都存在于某些（可能不止一个）子模式中; b）不存在其他属性。此外，当关系子模式包含在另一个中时，分解是多余的。在您的情况下，R(ABCDEFG)包含在R2中，这是正确的：不需要同时存在这两种关系，因为它意味着无用的数据冗余。

什么是良好的分解

要真正有用，分解应满足两个重要属性：保留功能依赖性并保留数据（无损分解）。但是另一个属性表征了一个好的分解：它应该尽可能小：在太多子模式中分解模式没有意义，因为这会产生一个非自然和复杂的数据库。

实际上，您的分解是无损的，并保留了依赖关系。

如何分解

所有这些东西的最终目标是产生一个分解（无损和依赖保留），其中子模式是BCNF或3NF。通过使用函数依赖项的属性进行分解的简单解决方案是 not ，但是，这是一个很好的解决方案。为此，在教科书中描述的算法产生BCNF或3NF的分解（BCNF的所谓“分析”算法和3NF的“合成”算法），试图产生不太多的子模式。例如，在这种情况下，“分析”算法在BCNF中产生以下分解，只有两个子模式：

R3

这种分解是无损的，并保留了依赖关系（分析算法并不总是如此）。

分解依赖项时的正确方法是什么

1 个答案: