为什么这个关系是3NF?

Wug*_*Wug 3 normalization dependencies

我有一个关系:

\n\n
R4 = {{T,U,V}, {T \xe2\x86\x92 U, U \xe2\x86\x92 T, T \xe2\x86\x92 V}}\n
Run Code Online (Sandbox Code Playgroud)\n\n

从答案中我知道这个关系在BCNF中。

\n\n

我正在经历严格确定这种关系所遵循的正常形式的过程。我很清楚为什么这种关系是在 1NF 和 2NF 中,如果我假设它是在 3NF 中,BCNF 就很容易遵循。

\n\n

然而,3NF 的定义指出:

\n\n
\n

每个非素数属性都非传递地依赖于表中的每个候选键。

\n
\n\n

但是,据我所知, 和{T}都是{U}表的候选键,{V}因此传递依赖于{U}

\n\n

维基百科上有 3NF 的替代定义:

\n\n
\n

Carlo Zaniolo 在 1982 年给出了与 Codd 等效的 3NF 定义,但表达方式不同。该定义指出,表在 3NF 中当且仅当对于其每个函数依赖项 X \xe2\x86\ x92 A,至少满足以下条件之一:

\n\n
    \n
  • X 包含 A(即 X \xe2\x86\x92 A 是平凡的函数依赖)
  • \n
  • X 是一个超级键
  • \n
  • AX 的每个元素(A 和 X 之间的集合差)都是质属性(即 AX 中的每一列都包含在某个候选键中)
  • \n
\n
\n\n

根据这个定义,这种关系显然属于 3NF(所有函数依赖关系都由“X 是超级密钥”涵盖)。

\n\n

那么为什么会出现这种差异呢?我如何误用了这个定义?请不要给我以我不想要的方式给出答案的捷径,除非你也帮助我理解为什么我的 3NF 应用(如所描述的)不准确。

\n\n\n

ype*_*eᵀᴹ 6

错误在于您对传递依赖的理解。来自维基百科:传递依赖

\n
\n

在数学中,传递依赖是凭借传递性而成立的函数依赖。传递依赖只能出现在具有三个或更多属性的关系中。令 A、B 和 C 指定关系中的三个不同的属性(或不同的属性集合)。假设以下三个条件全部成立:

\n
    \n
  1. A \xe2\x86\x92 B
  2. \n
  3. 情况并非如此 B \xe2\x86\x92 A
  4. \n
  5. B \xe2\x86\x92 C
  6. \n
\n

那么函数依赖 A \xe2\x86\x92 C (根据传递性公理从 1 和 3 得出)是传递依赖。

\n
\n

但就您而言,(2) 不成立:

\n
    \n
  1. U \xe2\x86\x92 T - 正确的
  2. \n
  3. 事实并非如此T \xe2\x86\x92 U ——错误
  4. \n
  5. T \xe2\x86\x92 V - 正确的
  6. \n
\n

因此{V}不传递依赖{U}.

\n
\n

请注意,维基百科有正确的定义,但被删除的声明是不正确的:

\n
\n

传递依赖只能出现在具有三个或更多属性的关系中。

\n
\n

必须至少有 3 个不同的集合,但这并不意味着至少有 3 个属性,它意味着至少有 2 个属性。事实上,对于属性集{X, Z}、候选键X和函数依赖{} \xe2\x86\x92 Z(所有行具有相同的 Z 值),传递依赖X \xe2\x86\x92 Z成立:

\n
    \n
  1. X \xe2\x86\x92 {} - 正确的
  2. \n
  3. 事实并非如此{} \xe2\x86\x92 X ——正确
  4. \n
  5. {} \xe2\x86\x92 Z - 正确的
  6. \n
\n

这是确定非主要属性的 CK。所以我们没有 3NF。它也是部分的,所以我们甚至没有 2NF。(这也与所有 CK 简单意味着 2NF 以及 2 个属性意味着 2NF 的常见误解相矛盾。)

\n

(感谢philipxy指出了这一点。)

\n