Question

假设我们具有从主键外部的属性到主键内的属性的功能依赖性。我们怎样摆脱这种依赖（我直觉地认为这很糟糕）？

特别是，假设我们具有以下功能依赖性：

CS -> T
T  -> C

其中CS是主键。在我的例子中，幸运的是，TS最初也可能是主键，因此情况转换为：

TS -> C
T  -> C

这实际上是我们没有进入密钥依赖关系的情况，但我们有一个部分依赖，可以通过将我们的表拆分为两个表来轻松解决，如下所示

| T | C |

和

| T | S |

但如果TS也不是主键怎么办？我们怎样才能摆脱最初的进入密钥依赖/异常？

Answer 1

首先，关于术语的说明：“主键”是用于关系的术语由...管理关系数据库管理系统，而在规范化理论中通常使用的术语是“超级键”和“候选键”，或简称为“键”。

其次，在您的示例中，您要问：

我们如何摆脱这种依赖（我直觉地认为它很糟糕）？

重点是依赖性实际上是不好的，因为你与异常有关系（在这种情况下是冗余），但你不能摆脱这个异常没有另一个异常，就是失去了功能依赖。

实际上，您可以在BCNF中转换模式，并进行以下分解架构：

R1＆lt; （C T）， {T→C}＆gt;

R2＆lt; （S T）， {}＆gt;

但是，正如您所看到的，依赖关系CS→T不再保留，因为没有 subschema包含所有三个属性。而且比这更糟糕冗余，因为您可能会在数据库中引入不一致性是违反这种依赖的情况。

实际上，这是架构已经存在的经典示例在第三范式（3NF）中，根据定义，允许来自a的依赖不是键的属性集，属于键的一部分的属性（称为“素数”属性）。

因此，这种异常是普遍接受的，并且这种关系不会被分解。

Answer 2

在将关系分解为Boyce-Codd Normal Form（BCNF）时，将删除给定关系R中的任何“到关键”依赖关系。

BCNF确保所有依赖关系“来自完整密钥”。

查看here了解如何分解为BCNF表格。

修改

从完整密钥：从完整主键到密钥外部。

进入密钥依赖：从密钥外部进入密钥。

为了完整起见，另外两种类型的依赖项 - 部分依赖项通过分解为2NF而被删除，传递依赖项通过进一步将其分解为3NF而被删除。因此，通过进一步分解为BCNF，您基本上删除了所有三种类型的依赖项（部分，传递，进入密钥）

如何摆脱关键依赖？

2 个答案: