DBMS 中的传递依赖

让我们考虑一个关系 R(A B C)。这里 A、B 和 C 被称为关系 R 的属性。当出现以下条件时；DBMS 中就会发生传递依赖。条件是 A → B、B → C。因此，条件变为 A → C。换句话说，当依赖由两个函数依赖构成时，函数依赖就成为传递依赖。

什么是传递依赖？

考虑一个关系 R(A B C)。这里 A、B 和 C 被称为关系 R 的属性。当出现以下条件时；DBMS 中就会发生传递依赖。条件是 A → B、B → C。因此，条件变为 A → C。在传递函数依赖中，被决定项直接决定。

让我们通过以下示例来理解传递依赖。

在上表中，我们得到。

• 书 → 作者：这里，作者属性由书属性决定。如果有人知道书名，他们也能知道作者的名字。
• 作者 → 作者国籍：如果有人知道作者的名字，他们也能知道作者的国籍。
• 书 → 作者国籍：如果有人知道书名，他们也能知道作者的国籍。

如果我们仔细查看上面讨论的函数依赖，我们会发现以下模式。

• A → B 和 B → C；因此，A → CA → C。
• A → 书，B → 作者 B → 作者 和 C → 作者国籍 C→作者国籍

如果我们对上面的作者表应用第三范式 (3NF)。在这种情况下，必须删除作者表的传递依赖，将数据库的传递依赖移除的过程称为规范化过程。

如何避免传递依赖？

让我们再次考虑上面的作者表，看看在创建表时会出现什么类型的问题。

作者表

数据异常（如更新、插入和删除异常）和不一致性可能会导致作者表。当数据库中存在过多冗余时，就会发生数据异常。当更新、删除和插入新数据存在问题时，也会导致数据异常。例如，在作者表中 -

• 除非我们能往表中添加一本书，否则我们无法添加新作者。
• 除非我们完全从数据库中删除一本书，否则我们无法删除作者。
• 如果我们想删除书《微小事物之神》，作者的 ID、作者和国籍也会被删除。

上述问题会出现在任何包含传递依赖的关系中。

通过移除传递依赖的第三范式

让我们考虑具有三个属性（作者 ID、作者、作者国籍）的作者表，并尝试在此表中查找和消除传递依赖，

作者表

上面的作者表不在 3NF 中，因为它具有传递依赖。让我们看看如何

• 作者 → 作者国籍 作者 → 作者国籍
• 作者 ID → 作者

因此，以下函数依赖也存在，

• 作者 ID → 作者国籍 形成了与我们上面讨论的类似的模式。

现在为了消除传递依赖，我们只需要将作者表拆分，使得作者 ID 不再函数地依赖于作者国籍。

让我们创建两个表，一个只包含 { 作者 ID, 作者}，另一个包含 { 作者国籍}。新表将如下所示，

作者表

作者国籍表

现在新的作者表和作者国籍表不包含传递依赖，关系现在是 3NF。