为什么认为集合绝对不规范化数据库？

Question

为了使关系在 1NF 上，它需要将所有值都作为原子，如果有一个集合，它甚至不是第一个范式：

但直觉上，我认为具有该集合的表会比不将该集合的值仅用作实体的属性的表更规范化。

例如，让我们想象这张关于绘画的表格：

绘画名称，作者，使用的技术，使用的颜色

现在，如果我们使用一组颜色，如{蓝色、绿色、黄色、黑色、白色、紫色}，我们会得到一张甚至不在 1NF 中的表格。

如果我们将表传递给 1NF，那么我们需要有 6 行，每行重复 Painting_name、Author 和 Used 技术。

这看起来比甚至不在 1NF 中的表更不规范化，而且我不明白为什么在那里有一个集合会损害任何可能的规范化，因为这些集合只会在该表中使用。

那么需要原子值才能拥有规范化表的原因是什么？

Answer 1

这篇文章的参考资料是一本很棒的书，名为Database System Concepts 6th Edition，我建议您阅读它。

在这本书第 328 页中，它指出：

如果域的元素被认为是不可分割的单元，则域是原子的。如果 R 的所有属性的域都是原子的，我们说关系模式 R 是第一范式（1NF）。

您可能想知道“但是为什么！？”，最好使用实际示例进行解释。

让我们用颜色来看看你的例子。假设我们有 2 个场景，1.) 表格不在1NF 中，2.) 表格在 1NF 中。

1.)

Id          Painting_name                  Author                         Used_colors
----------- ------------------------------ ------------------------------ ---------------
1           Some_Painting                  John                           Blue, red, Yellow
2           Monalisa                       Leonardo da Vinci              orange, black, White, red, Yellow

尽管这对您来说似乎很直观，但请考虑一下当您要查询此表时会发生什么。一，您的大小写不一致（您必须检查这两种情况的查询）二，如果used_colors不是数组，则必须将其转换为数组或使用额外的步骤来检查您需要的数据（例如string_split在 SQL Server 2014 及更高版本中使用函数）。

这会导致性能问题，并且每次您想要检查某些内容时都会很麻烦。如果您想知道是什么阻止了一个人输入black_white_yellow？这个问题在 2NF 和 3NF、外键约束等中得到了回答......

2.)

Id          Painting_name                  Author                         Used_colors
----------- ------------------------------ ------------------------------ ---------------
3           Some_Painting                  John                           Blue
4           Some_Painting                  John                           red
5           Some_Painting                  John                           Yellow
6           Monalisa                       Leonardo da Vinci              orange
7           Monalisa                       Leonardo da Vinci              black
8           Monalisa                       Leonardo da Vinci              White
9           Monalisa                       Leonardo da Vinci              red
10          Monalisa                       Leonardo da Vinci              Yellow

在这种情况下，每一行都是原子的和唯一的。我们这样做有什么收获？您不必考虑处理数组，因为现在每一行都是原子的，您可以快速有效地清楚地检查您需要的内容。

并且只是为了让您了解它可能会变得多么麻烦，这里有一些与在逗号分隔列中搜索值的问题相关的帖子：

• 如何检查逗号分隔列表中是否包含数字
• 在 Select 语句中使用逗号分隔的字符串值

还有许多不同的方法，至少可以说没有一个是真正优雅的（至少与 1NF 的问题有关）。因此，基本上通过使用 1NF，您可以从使用上面那些帖子中提到的代码变成简单的东西，例如：

SELECT * FROM Paintings WHERE Used_colors LIKE 'BLUE'

这有助于提高可读性和性能。

您需要记住一件事，1NF 只是规范化过程的起点。1NF 本身实际上从未在任何数据库中使用过，在 1NF 之后是 2NF，您必须将此表拆分为两个单独的表。Used_colors将被制作成它自己的表，称为Colors. 在这一点上，您将遇到上述书中也涵盖的基数问题。

最后一件事，在很多情况下，您会遇到在一个或多个表上破坏 1NF 的数据库，同时遵守 2NF、3NF 甚至 4NF 的规则。比如PostgreSQL的有json这立即打破了1NF规则（你可以保存多个键和值以JSON）数据类型。一般的经验法则是这样的：除非你真的知道你在做什么，否则总是遵循正常的形式。从您引入此类变量的那一刻起，您可能会导致整个数据库的不一致，并且很可能会降低性能。

此外，正如保罗在下面的评论中所说，克里斯托弗还有另一种观点。J. Date 支持（他是关系数据库理论的著名研究员和作家，也是 Ted Codd 帮助推动关系模型的人之一）。这种观点抨击了 1NF 中原子值的概念，称整个术语“原子”是模棱两可的。这背后的想法很简单，可以说在当前的 1NF 定义下几乎没有数据类型是原子的。为了解释这一点，让我们看一个例子：

假设您有一个 string Hello World。您在每个 DBMS 中都有将这个字符串分解成更小的块（如SUBSTRINGor LEFT/RIGHT函数）的函数，这意味着它string并不是真正的原子值，因为一切都可以分解。这种前景类似于数据类型，例如json，您可以分解字符串和 json，那么为什么一个被认为是原子的，而另一个则不是？这就是 CJ Date 认为 1NF 的当前定义不明确的原因，因为几乎所有数据类型都可以以一种或另一种方式分解。如果您将json或xml数据类型作为一个整体访问而不分解它们，则没有什么可说的，json或者xml数据类型不是原子的。

你可以在The Third Manifesto上找到一篇有趣的论文，他们（CJ Date 和 Hugh Darwin）公开发表了他们关于数据库、类型和关系模型的论文 The Third Manifesto。这也是一本有趣的读物，它通常会将您发送到其他有趣的文章和主题。