【问题标题】:3NF Normalization Algorithm Step: Relation with SuperKey3NF 归一化算法步骤:与 SuperKey 的关系
【发布时间】:2017-05-23 18:31:27
【问题描述】:

我想知道 3NF 归一化算法的最后一步,它指出:

4) 如果前面步骤中获得的关系中没有一个包含 R 的超键,则添加一个新的关系,其模式是 R 的键。

我的具体问题是,这种关系的语义会发生什么?为什么只有一个关系而不是多个单属性关系(键的每个属性一个)?

我发现在某些示例中,额外的关系是有意义的,但在其他示例中,它似乎“混合”了不相关的属性......

【问题讨论】:

  • 如果你有一个 CK 的每个属性的组件,当你加入它们时,你会从每个属性的所有可能的值组合中获得所有可能的元组。通常只有一些元组出现在关系中——那些在保持 CK 的组件中。因此,将 CK 的属性保持在某个组件中是必要且足够的,并且鉴于此,将投影包含在单独的属性上是多余的。但是如果这些CK属性可以被分成所有出现元组组合的子集,你可以分解,但是这不是必需的对于3NF
  • PS 你需要放弃“具体”&语义&“有意义”&“混合”&恐吓引语&“信息”&“独立”等等,都无可救药的模糊,说什么实际上,您的意思是,就关系和投影/组件和元组和连接等而言。您可能会发现 (characteristic) predicate (of a set) 的概念很有帮助。(来自情况的映射和真值的元组;我们将给定元组放入或排除关联关系主体的标准。)因为如果两个关系加入一个关系,则参数的谓词与结果的谓词。
  • 例如:组件不“有意义”或“混合”不相关的属性是什么意思? (原始关系包含其值以某种方式相关的元组 - 比如说,它们是满足 p(A,..) 的 元组。因此,投影出 X,... 的组件包含元组满足 EXISTS X,... p(A,...)--即,其值如此相关的元组。)

标签: database-normalization 3nf


【解决方案1】:

需要3NF归一化算法的最后一步,保证算法生成的分解是无损的。

事实上,有一个定理表明,如果分解保留了依赖关系,并且分解的模式之一是原始关系的超键,那么分解也是无损的。

该算法与前面的步骤一起保证每个函数依赖都存在于某些分解的关系中。如果某个其他关系中不存在任何键,则引入包含键的关系可确保算法生成的分解同时保留数据和依赖关系。

已添加

这是一个简单的示例,说明了最后一步的必要性。假设关系 R(A, B, C, D),A->B,C->D,(键为 A,C)的一个实例是:

R
A | B | C | D
-------------
1   2   2   3
1   2   3   4
2   3   2   3

R1(A,B), R2(C,D) 中的分解是第三范式,但有损(加法)。事实上,将该实例投影到分解上会产生:

R1          R2
A | B       C | D
-----       -----
1   2       2   3
2   3       3   4

如果我们对分解的关系进行自然连接,这种分解的加性特性就很清楚了,它会产生一个不同于原始实例的实例:

R1 ⨝ R2 =
A | B | C | D
-------------
1   2   2   3
1   2   3   4
2   3   2   3
2   3   3   4

如果将 R 分解为 R1(A,B)、R2(C,D)、R3(A)、R4(C),情况不会改变:实际上,用 R1 ⨝ R2 ⨝ R3 ⨝ R4 重新组合产生与上面完全相同的关系,有 4 行:

R1          R2          R3     R4       R1 ⨝ R2 ⨝ R3 ⨝ R4 =
A | B       C | D       A      C        A | B | C | D
-----       -----       --     ---      --------------
1   2       2   3       1      2        1   2   2   3
2   3       3   4       2      3        1   2   3   4
                                        2   3   2   3
                                        2   3   3   4

相反,情况随着 R1(A,B)、R2(C,D)、R3(A,C) 中的分解而完全改变。当您使用自然连接重构时,您将获得原始实例:

R1          R2           R3          R1 ⨝ R2 ⨝ R3 =
A | B       C | D        A | C       A | B | C | D
-----       -----        ------      --------------
1   2       2   3        1   2       1   2   2   3
2   3       3   4        1   3       1   2   3   4
                         2   2       2   3   2   3

因此,总而言之,在前两种情况下,您有信息丢失(未获得原始实例),而在第三种情况下,您有 3NF 无损(非加法)分解。

【讨论】:

  • 对,但我很难理解如何不丢失信息。例如,如果 R=(A, B, C, D),key 是 (A, C) 并且 F = {A->B, C->D},算法将产生 R1=(A,B) ; R2=(C,D) 和 R3=(A,C)。 R3中的属性存储在其他...
  • 如果密钥是AC,那么单独存储A和C不会保存信息。例如,假设您有订单行,由订单号和行号标识。如果您有一组订单行,并通过分别放置订单号和行号来分解它们,那么有关存储的实际订单行的信息就会丢失。事实上,在进行自然连接重构原始关系时,会产生太多行,而不是原始订单行。
  • 即使在我之前的示例中(A 和 C 是独立的),你会丢失信息吗?
  • @John 我会尽可能发布答案。但这没关系。 (就像我刚才说的:) 3NF 算法摆脱了某些不良的 FD/JD。如果有 其他不良 FD/JD,它们就是您可以通过更高的 NF 算法摆脱的那种。这不是 3NF 算法的错。您的困惑可能是您希望所有异常都被 3NF 移除。 3NF仍然有问题。所有基表都应标准化为 5NF。它们不是这样的唯一原因是当前的 SQL DBMS 不能使必要的约束易于表达或执行。而且规范化在学术和工业上的教学很差。
  • @John,我已经更新了答案,以通过为键的属性设置单独的表来说明为什么您会丢失信息。
猜你喜欢
  • 2016-09-27
  • 2011-08-26
  • 2016-07-22
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-12-09
  • 2013-03-21
  • 2016-08-18
相关资源
最近更新 更多