关系数据库传递依赖的合理定义探讨：Codd定义修正可行性

Codd原定义的矛盾点 #

Codd在《Further normalization of the data base relational model》中给出的传递依赖定义如下：

对于三个distinct属性集合A、B、C，当满足以下条件时，称传递依赖A -> B -> C成立：

1. 函数依赖A -> B和B -> C成立；
2. 函数依赖B -> A不成立。

但这个定义会产生明显不合理的判定：
假设a、b、c为三个不同属性，A={a}是主键，B={b,c}不是超键，C={c}。此时A、B、C是distinct的属性集合，完全符合Codd的定义条件，会被判定为存在传递依赖，进而认为该表不满足3NF。但实际场景中（比如游戏表：a为游戏ID，b为玩家1ID，c为玩家2ID），这个表显然是符合3NF要求的，不存在冗余或异常问题。

另外Codd提到“假设A、B、C是关系R的三个distinct属性集合（因此R的度≥3）”，这个推论也不成立——哪怕只有2个属性a、b，也能生成3个非空的distinct集合{a,b}、{a}、{b}，显然和“度≥3”的结论矛盾。这说明Codd大概率是误将“disjoint（不相交）”写成了“distinct”。

合理的传递依赖定义 #

目前被广泛认可的合理传递依赖定义，需要在Codd的基础上补充关键限制：

• 函数依赖A→B、B→C均为非平凡函数依赖（即B不包含于A，C不包含于B）；
• C不包含于A；
• B↛A（即B不依赖于A）。

简单来说，传递依赖的核心是：C依赖于B，B依赖于A，但C不直接依赖于A，且B不能反向决定A，同时所有依赖关系都不是“子集决定自身”的平凡情况。

关于替换“distinct”的可行性 #

将Codd定义中的“distinct”替换为“非空且不相交”是可行的，这能直接避免你举的那种包含子集的不合理案例。但更严谨的做法是同时明确排除平凡函数依赖的情况——因为即使集合不相交，若存在平凡依赖，也不能算作传递依赖。

内容的提问来源于stack exchange，提问作者opus26