空值情况下的功能依赖关系答案

【问题标题】：Functional dependencies in case of nulls空值情况下的功能依赖关系
【发布时间】：2017-10-26 13:54:04
【问题描述】：

假设我们有一个包含 3 列 A、B 和 C 的表

A      B      C
---------------
1      2      3
2      4      5
4      6      7
n      5      n

这里的“n”表示空值。

我们可以说 A -> B 和 A -> C 吗？我知道函数依赖的定义，但我只是对空值感到困惑。

【问题讨论】：

在存在空值的情况下未定义功能依赖关系。所有关于 FD 主题的经典科学文献，以及所有威胁 FD 的数据库书籍，都清楚地表明，关系理论已被定义为忽略空值。也许您可以在一篇相对较新的论文中为您的问题找到一些有趣的东西：Badia、A. 和 D. Lemire。 “具有空标记的功能依赖关系。”计算机杂志，2014 年 5 月 15 日。doi.org/10.1093/comjnl/bxu039.
What to do with null values when modeling and normalizing?的可能重复
查看我对重复问题的回答。如果你真的在处理 FD，那么“null”必须是 = & join 的另一个值，你必须询问你的导师如何将它们应用到 SQL 设计中。（至少，直到我写下另一个答案，在链接上重新组织我的答案。）

标签： database database-normalization functional-dependencies

【解决方案1】：

如果 null 被认为是一个值，那么答案是肯定的。 A -> B, C 保存在给定的数据中。然而，要成为一个价值，有一定的要求。适用于域的所有运算符（例如整数），如相等、加法、小于等，必须在存在空值时进行良好定义。

如果 null 不是一个值，那么答案就更复杂了。严格来说，函数依赖适用于关系。如果一个表代表一个关系，那么我们可以引用表中的函数依赖关系。但是，表示缺少值的符号是元数据，而不是数据。它允许多个联合不兼容的关系由单个表表示。在这种情况下，我们不能将函数依赖的概念应用于表，因为我们不清楚我们在谈论哪种关系。

更令人困惑的是，SQL DBMS 不能始终如一地处理空值。在某些情况下，它们会像值一样被处理，而在其他情况下，它们就像值的缺失一样。如果您想从逻辑上理解和描述一个表，最好的选择是将其分解为一组无空关系，然后分别独立分析这些部分。

在您的示例表中，如果 null 不是值，我们就会遇到问题。最后一行没有唯一标识符（它不能是B:4，因为另一行也有B:4），我们无法确定任何信息缺乏。如果不丢弃该行，则无法将示例分解为一组关系。

如果我们将最后一行改为B:5，那么我们将其分解为两个关系：R1 = {(A:1, B:2, C:3), (A:2, B:4, C:5), (A:4, B:6, C:7)} 和R2 = {(B:2), (B:4), (B:6), (B:5)}。我们可以说A -> B, C 在 R1 中成立，但在 R2 中不成立。

【讨论】：

先生，实际上我在尝试合并两个表时遇到了这个问题。我与 A->C 和 R2(B) 有关系 R1(AC)，两者都与 R1 侧完全参与和 R2 部分参与相关。在原始 R1(AC) 中，A -> C 成立。但是在结合这两个关系之后，我很困惑 A->C 是否仍然成立。
另外，如果 B 的最后一行是 5，那么 B 列可以作为合并表的主键（即 B -> AC ）对吗？
无论你如何获得你的表，当涉及非值空值时，函数依赖不适用。
实际上问题是关系处于 1NF 和 3NF 所需的最少表数。所以对于1NF，我合并了两个表，因为两个表最初都没有空值，并将B作为PK。对于3NF，由于我们在检查3NF时将FD纳入图片，所以合并后获得空值存在问题跨度>
如果空值不是值，那么它们就不是任何类型的值，更不用说原子值了。 BTW atomic 具有误导性，一个值可以是我们想要的简单或复杂，只要它不是变量。