【如此简单！数据库入门系列】之数据库设计基础--函数依赖

news2024/12/24 0:11:23

问题

考虑一个在线商店数据库，其中包含以下表：

【订单表】

Order_Num(订单号)	Product_ID(产品ID)	Count(数量)	Price(单价)
1	10	2	100
2	10	1	100
3	20	3	200

你觉得这张表是否存在问题？存在哪些问题？
在这里插入图片描述

应该怎么解决这两个问题呢？

【单价表】

Product_ID (产品ID，主键)	Price(单价)
10	100
20	200

【优化后的订单表】

刚才的问题通过消除冗余数据和使用外键就能解决。有没有想过，解决方案背后的原理是什么呢？

核心在于，同一个产品始终有相同的单价（只要两个元组的产品ID相同，它们的产品单价也必须相同）。

一个属性决定另一个属性，这种约束就称为函数依赖。

函数依赖（Functional Dependency，FD）

简单来说，函数依赖X→Y，可以理解为相同的X一定有相同的Y。例如，同一个产品始终有相同的单价，表示为：{产品ID} → {产品单价}。

函数依赖有什么作用？或者，为什么需要函数依赖？

例如，根据{产品ID} →{单价}，可以将订单表{#订单号，产品ID，数量，单价}，拆分成两个表：

这么做有以下作用。

1. 保证数据一致性

插入一致性：当插入一个新的产品记录时，只要产品ID已经存在，系统将不允许插入，因为这会违反函数依赖，保证每个产品的单价信息是唯一的。
更新一致性：如果需要更新产品单价信息，只需通过产品ID定位到特定的单价记录进行更新。如果没有这样的函数依赖，可能会出现同一个产品的多条记录拥有不同的信息，导致数据不一致。
删除一致性：同理，删除操作也可以通过产品ID精确地移除某个产品单价信息，而不会影响其他产品单价数据。

2. 减少数据冗余

这种设计减少了数据的冗余存储，因为单价信息只存储一次，而不是在每个订单记录中重复存储。

3. 优化查询性能

例如，想查询产品单价，直接从单价表中查询即可，性能非常好（主键等值查询）。而在原始的订单表中查询某个产品的单价，，则需要执行过滤和去重操作。

4. 设计规范化的数据库

函数依赖是数据库设计规范化的基础方法（下篇文章介绍数据库规范化内容）。

我们进一步讨论函数依赖具备的性质。

阿姆斯特朗公理（Armstrong’s Axioms）

阿姆斯特朗公理是一组规则，包括：

自反规则（Reflexive rule）：如果α是一个属性集，β是α的子集，那么α→β。例如，如果我们有属性集{A, B}，那么根据自反规则，我们可以得出函数依赖{A} → {A}和{B} → {B}，因为每个属性自己就是自己的子集。
增广规则（Augmentation rule）：如果a → b成立，并且y是一个属性集，那么ay → by也成立。也就是说，在依赖中增加属性，不会改变依赖关系。例如，如果我们有函数依赖{A} → {B}，并且我们有另一个属性C，那么根据增广规则，我们可以得出函数依赖{AC} → {BC}。
传递规则（Transitivity rule）：与代数中的传递规则相同，如果a → b成立并且b → c成立，那么a → c也成立。例如，如果我们有函数依赖{A} → {B}和{B} → {C}，那么根据传递规则，我们可以得出函数依赖{A} → {C}。

平凡函数依赖（Trivial Functional Dependency）

函数依赖可以分为三种情况：