为什么它被认为是一组完全不规范一个数据库？

Question

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

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

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

Painting_name，作者，用过的技术，用的颜色

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

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

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

那么，为什么需要原子值才能有一个规范化的表呢？

Answer 1

这篇文章的参考资料是一本很棒的书，名为数据库系统概念第6版，我建议你阅读。

书中第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不是数组，则必须将其转换为数组，或者使用额外步骤来检查所需的数据(比如在Server 2014及更高版本中使用string_split函数)。

这会导致性能问题，并最终在每次您想检查某件事情时都会引起麻烦。如果你想知道是什么阻止了一个人输入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

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

为了让你知道这会有多大的麻烦，这里有一些关于在逗号分隔的专栏中搜索值的帖子：

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

还有许多不同的方法，至少可以说，这些方法都不太优雅(至少与1NF问题有关)。因此，基本上，通过使用1NF，您可以从使用上面那些文章中提到的代码转到简单的东西，比如：

SELECT * FROM Paintings WHERE Used_colors LIKE 'BLUE'

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

有一件事你需要记住，1NF只是正常化过程的起点。1NF本身实际上从来没有在任何DB中使用过，在1NF之后出现了2NF，在2NF中，您必须将这个表分成两个单独的表。Used_colors将被制作成自己的表Colors。在这一点上，您将到达基数问题，这也是在书中提到的。

最后一件事是，在许多情况下，您将遇到在一个或多个表上破坏1NF的数据库，同时遵守2NF、3NF甚至4NF的规则。例如，PostgreSQL有json数据类型，它会立即破坏1NF规则(因为您可以在json中保存多个键和值)。一般的经验法则是这样的:除非你真正知道自己在做什么，否则一定要遵循正常的形式。从引入这些变量的那一刻起，您可能会在整个数据库中造成不一致，并且很可能会在性能上损失。

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

假设您有一个字符串Hello World。在每个DBMS中都有函数将这个字符串分解成更小的块(比如SUBSTRING或LEFT / RIGHT函数)，这意味着string并不是一个真正的原子值，因为所有东西都可以分解。这个outlook类似于数据类型(如json )，您可以同时分解字符串和json，那么为什么其中一个被认为是原子的，而另一个则不是？这就是为什么C.J.Date认为1NF的当前定义是模棱两可的，因为几乎所有的数据类型都可以以某种方式被分解。如果您将json或xml数据类型作为一个整体访问而不对它们进行分解，那么json或xml数据类型并不是原子的。

你可以在第三份宣言上找到一篇有趣的论文，他们(C.J. Date和Hugh达尔文)在数据库、类型与关系模型--第三份宣言上公开发表了他们的论文。这也是一个有趣的阅读，这将送你到有趣的其他文章和主题，在总体上。

Answer 2

“规范化”只是指该模型遵循关系数据库的标准约定。这并不意味着它更好或更坏。

这只是关系数据库的定义，即在“规范化”模式中不允许多值属性。

许多有用的数据建模技术允许数组作为属性，而如何正确地进行关系建模的指导原则可以被忽略。

在实践中，将一些非标量属性(通常是XML或JSON)存储在关系模式中是相当常见的，而关系模式则是规范化的。

Answer 3

原子值:它意味着一个值，不包含分隔符(如逗号)在单个行中分隔多个值。这就是为什么一行中的{蓝色、绿色、黄色、黑色、白色、紫色}不是原子的原因。因此，它不是在1NF。

如果将非原子值(如{blue、Green、黄色、黑色、白色、紫色})保持在单行中，那么在技术上您将面临许多问题。即使您得到了任何解决方案，这也会非常麻烦，而且性能也要差得多。

效率、性能是数据库世界中非常重要的因素(在其他世界也是如此)。

如果您有一个到多个关系，那么您必须创建单独的映射表。

Painting_Color_Mapping
-----------------------
PaintingID
Colorid