函数依赖如何区分部分依赖与传递依赖？

Question

在数据库设计中，函数依赖用于描述关系中属性之间的依赖关系。部分依赖是指非主属性依赖于候选键的一部分，而非全部；而传递依赖是指非主属性通过另一个非主属性间接依赖于候选键。两者有何本质区别？如何通过函数依赖准确判断部分依赖与传递依赖？这是数据库规范化过程中常见的技术问题。

Answer 1

一、函数依赖的基本概念

在数据库设计中，函数依赖（Functional Dependency, FD）用于描述关系中属性之间的依赖关系。若属性集A可以唯一确定属性B的值，则称B函数依赖于A，记作A → B。

函数依赖是数据库规范化（Normalization）的基础，其核心目的是消除数据冗余、更新异常、插入异常和删除异常。

• 函数依赖分为完全函数依赖、部分函数依赖和传递函数依赖。
• 部分依赖和传递依赖是导致数据库设计不规范的主要原因。

二、部分依赖与传递依赖的本质区别

在理解部分依赖与传递依赖之前，需明确几个关键概念：

1. 候选键（Candidate Key）：能够唯一标识元组的最小属性集合。
2. 主属性（Prime Attribute）：属于任一候选键的属性。
3. 非主属性（Non-prime Attribute）：不属于任何候选键的属性。

类型	定义	示例	是否违反范式
部分依赖	非主属性依赖于候选键的某一部分，而非全部	R(A,B,C), 候选键为(A,B), C依赖于A	违反2NF
传递依赖	非主属性通过另一个非主属性间接依赖候选键	R(A,B,C,D), 候选键为(A,B), C依赖于D，D依赖于(A,B)	违反3NF

三、如何通过函数依赖判断部分依赖与传递依赖

判断依赖类型的关键在于分析函数依赖链和候选键的结构。

以下为判断步骤：

1. 确定候选键。
2. 列出所有函数依赖。
3. 判断每个非主属性是否完全依赖于候选键。
4. 若依赖于候选键的部分，则为部分依赖。
5. 若依赖于另一个非主属性，而该属性又依赖于候选键，则为传递依赖。

例如：

        函数依赖集合：
        A → B
        A,B → C
        C → D
        
        候选键为(A,B)
        分析：
        - B依赖于A，A是候选键的一部分 → 部分依赖
        - D依赖于C，C依赖于候选键 → 传递依赖
    

四、规范化中的处理方式

针对部分依赖和传递依赖，数据库设计中采用不同的范式进行处理：

• 第二范式（2NF）：消除部分依赖
• 第三范式（3NF）：消除传递依赖
• BC范式（BCNF）：进一步消除主属性对候选键的非完全依赖

处理流程如下：

            graph TD
            A[开始] --> B[确定候选键]
            B --> C[列出所有函数依赖]
            C --> D[判断是否存在部分依赖]
            D -->|是| E[分解表以消除部分依赖]
            D -->|否| F[判断是否存在传递依赖]
            F -->|是| G[分解表以消除传递依赖]
            F -->|否| H[符合3NF]
        

五、实际案例分析

假设有一个关系表 OrderDetail(OrderID, ProductID, Quantity, ProductName, Price)，其中候选键为 (OrderID, ProductID)。

函数依赖如下：

• (OrderID, ProductID) → Quantity
• ProductID → ProductName
• ProductID → Price

分析：

• ProductName 和 Price 只依赖于 ProductID，而不是整个候选键 → 部分依赖
• 没有非主属性通过另一个非主属性依赖候选键 → 无传递依赖

解决方案：

• 将 ProductName 和 Price 提取到新表 Product(ProductID, ProductName, Price)
• OrderDetail 表保留为 (OrderID, ProductID, Quantity)