什么是数据库中的传递依赖

避免传递性依赖性来帮助确保标准化

数据库中的传递依赖关系是同一个表中引起函数依赖关系的值之间的间接关系。 要达到第三范式（3NF）的标准化标准，您必须消除任何传递依赖。

就其性质而言，传递依赖需要三个或更多属性（或数据库列），它们之间具有函数依赖关系，这意味着表中的列A依赖于列B通过中间列C.

让我们看看这可能如何工作。

传递依赖例子

作者

在上面的AUTHORS示例中：

• Book → Author ：这里， Book属性决定了Author属性。 如果你知道书名，你可以学习作者的名字。 但是， 作者不确定Book ，因为作者可以写多本书。 例如，仅仅因为我们知道作者的名字奥森斯科特卡，我们仍然不知道书名。
• Author → Author_Nationality ：同样， Author属性决定了Author_Nationality ，但不是相反; 仅仅因为我们知道国籍并不意味着我们可以确定作者。

但是这张表引入了传递依赖：

• Book → Author_Nationality：如果我们知道书名，我们可以通过作者栏确定国籍。

避免传递性依赖

为了确保第三范式，我们删除传递的依赖关系。

我们可以从Authors表中删除Book列并创建一个单独的Books表：

图书

作者

这是否解决了它？ 现在我们来看看我们的依赖关系：

书桌 ：

• Book_ID → Book： Book取决于Book_ID 。
• 此表中没有其他依赖关系存在，所以我们没问题。 请注意，外键Author_ID通过其主键Author_ID将此表链接到AUTHORS表。 我们创建了一种关系来避免传递依赖关系，这是关系数据库的关键设计。

作者表 ：

• Author_ID → 作者： 作者依赖于Author_ID 。
• 作者 → 作者 国籍：国籍可以由作者确定。
• Author_ID → Author_Nationality：通过Author属性可以从Author_ID确定国籍。 我们仍然有传递依赖。

我们需要添加第三个表来规范化这些数据：

COUNTRIES

作者

现在我们有三个表格，利用外键来链接表格：

• BOOK表的外键Author_ID将一本书链接到AUTHORS表中的作者。
• AUTHORS表的外键Country_ID将作者链接到COUNTRIES表中的国家。

• COUNTRIES表没有外键，因为它不需要链接到此设计中的另一个表。

为什么传递依赖是数据库设计不好的原因

避免传递依赖来帮助确保3NF的价值是什么？ 让我们再次考虑我们的第一个表格，并查看它创建的问题：

作者

这种设计可能会导致数据异常和不一致，例如：

• 如果您删除了“Mind of Children”和“Ender's Game”这两本书，您将从数据库中完全删除作者“Orson Scott Card”和他的国籍。

• 除非您还添加书籍，否则不能将新作者添加到数据库; 如果作者尚未发布或者您不知道她撰写的书籍的名称，该怎么办？
• 如果“奥森斯科特卡”改变了他的国籍，你将不得不在他出现的所有记录中改变它。 拥有同一作者的多条记录可能会导致数据不准确：如果数据录入人员没有意识到他有多个记录并且只将数据更改为一条记录，该怎么办？
• 在不删除作者的情况下，您不能删除“女仆的故事”这样的书。

这些只是正常化的一些原因，并且避免了传递依赖性，保护数据并确保一致性。