我在1NF形式的DBMS中读过类似下面的内容。
有一句话如下：
“每列都应该是原子的。”
任何人都可以通过一个例子向我解释一下吗？
“每列都应该是原子的。”
Chris Date说：“请仔细注意，不仅仅是整数3之类的简单事物是合法的值。相反，值可以是任意复杂的;例如，值可能是几何点，或多边形，或X射线，XML文档，指纹，数组，堆栈，列表或关系（等等）。“[1]
他还说，“当且仅当在relvar的每个合法值中，每个元组对每个属性只包含一个值时，relvar在1NF中。”[2]
他一般不鼓励使用原子这个词，因为它含有令人困惑的内涵。单值可能是一个更好的术语。
例如，像'2014-01-01'这样的日期是单个值。这不是不可分割的;相反，它显然是可分割的。但dbms使用具有部分的单个值执行两项操作之一。 dbms要么返回这些值作为整体，要么dbms提供操作部件的函数。 （客户端不必编写代码来操作部件。）[3]
在日期的情况下，SQL可以
SELECT CURRENT_DATE），EXTRACT(YEAR FROM CURRENT_DATE)），CURRENT_DATE + INTERVAL '1' DAY），CURRENT_DATE - DATE '2014-01-01'），等等。在这个（狭义）方面，SQL是非常关系的。
原子性和1NF ......不是关于原子事务，而是关于定义和列内容。
“原子”是指“不能分割或分成较小的部分”。应用于1NF这意味着列不应包含多个值。它不应该组成或组合具有自己意义的值。
这通常涉及数据库设计者犯下的两个非常常见的错误：
包含值列表的列，通常以空格或逗号分隔，如此博客帖子表：
id title date_posted content tags
1 new idea 2014-05-23 ... tag1,tag2,tag3
2 why this? 2014-05-24 ... tag2,tag5
3 towel day 2014-05-26 ... tag42
或者这个联系人表：
id room phones
4 432 111-111-111 222-222-222
5 456 999-999-999
6 512 888-888-8888 333-3333-3333
这种非规范化很少见，因为大多数数据库设计者都认为这不是一件好事。但你确实找到了这样的表格。它们通常来自对数据库的修改，而扩展列并使用它来填充多个值而不是添加规范化的相关表（通常会破坏现有应用程序）似乎更简单。
在这种情况下，一列包含不同的信息位，可以设计为一组单独的列。
典型示例是全名和地址列：
id fullname address
1 Mark Tomers 56 Tomato Road
2 Fred Askalong 3277 Hadley Drive
3 May Anne Brice 225 Century Avenue - apartment 43/a
这些类型的非规范化是非常常见的，因为绘制线条很困难，什么是原子的，什么不是。根据应用的不同，多部分色谱柱在某些情况下可能是最佳解决方案。它结构较少，但更简单。
在许多原子列中构造地址可能意味着需要更复杂的代码来处理输出结果。另一个复杂性来自于不适合所有类型地址的结构。使用一个单一的VARCHAR列不会造成这个问题，但可能会造成其他问题......通常是关于搜索和排序。
多部分列的极端情况是日期和时间。大多数RDBMS提供日期和时间数据类型，并提供处理日期和时间代数以及提取各种位（月，小时等等）的函数。很少有人会认为在关系数据库中有单独的年份，mont，day列是方便的。但我已经看到了......并且有充分的理由：用例是司法部门数据库的生日。他们不得不处理很多或几乎没有文件的移民。有时你只知道一个人出生在某一年，但你不会知道一天或一个月或出生。您无法使用单个日期列处理该类型的信息。
重新“原子”
在Codd最初的1969年和1970论文中，他将关系定义为连续的每个属性都有一个值。价值可以是任何东西，包括关系。这没有使用“原子”的概念。他解释说“原子”意味着没有关系价值（即没有表值）：
到目前为止，我们已经讨论了在简单域上定义的关系的示例 - 域的元素是原子（不可分解）值。可以在关系框架内讨论非原子值。因此，某些域可能具有关系作为元素。
他使用“简单”，“原子”和“不可分解”作为非关系的非正式说明性概念。他理解一个关系有一些行，每列都有一个相关的名称和值;属性是通过定义“单值”;价值是任何类型。关系重要的唯一结构性质是关系。它也只是一个值，但您可以查询它。然后他使用了“非简单”等意义上的关系价值。
到了Codd 1990年出版的书The Relational Model for Database Management: Version 2：
从数据库的角度来看，数据可以分为两种类型：原子和复合。 DBMS不能将原子数据分解成更小的部分（不包括某些特殊功能）。由原子数据的结构化组合组成的复合数据可由DBMS分解。
在关系模型中，只有一种类型的复合数据：关系。定义每个关系的域中的值需要相对于DBMS是原子的。关系数据库是各种程度关系的集合。所有的查询和操作操作符都是关系，所有这些操作符都会产生关系作为结果。为什么只关注一种复合数据？主要原因是任何其他类型的复合数据都会增加复杂性而不增加功率。
“在关系模型中，只有一种类型的复合数据：关系。”
可悲的是，“原子=非关系”不是你将要听到的。 （不幸的是，Codd并不是最聪明的作家，而且他的说明性评论与他的底线相混淆。）几乎所有关系模型的演示都没有比Codd仅仅作为垫脚石的更多。他们提出了一个无益的混淆模糊概念，规范化/封为“原子”决定“规范化”。有时他们错误地使用它来定义实际情况。而Codd使用日常的“非原子”来定义关系“非原子”作为关系值，并将“规范化”定义为没有关系值域。
（“不是一个重复的群体”也不像“原子”那样有用，将其定义为甚至不是关系概念的东西。确实，1970年Codd说“当前数据库术语中的术语属性和重复群体大致类似于简单域和非简单域，分别为“。”
例如：这种误解在很早的时候就被Chris Date推广，这是一种荣耀的早期关系解释者和传教士，主要是在他开创性的当前着作“数据库系统简介”中。现在（2004年第8版）谢天谢地提出了区分关系，行和“标量”（非关系非行）域的有用的面向关系的扩展概念：
该定义仅表明所有[关系变量]均为1NF
例如：Maiers的经典The Theory of Relational Databases (1983)：
原子的定义是模糊的;一个应用程序中的原子值在另一个应用程序中可能是非原子的。对于一般准则，如果应用程序仅处理值的一部分，则值是非原子的。
例如：关于First NF（Normal Form）部分的当前维基百科文章实际上引用了上面的介绍部分。然后忽略了确切的含义。 （然后它说了一些关于非原子龟应该停止时无法理解的事情。）：
Codd声称，“定义每个关系的域中的值必须是相对于DBMS的原子值”。 Codd将原子值定义为“DBMS不能将其分解为较小的部分（不包括某些特殊功能）”，这意味着不应将字段分成具有多种数据的部分，这样一部分意味着DBMS依赖于同一领域的另一部分。
重新“标准化”和“1NF”
当Codd在1970年使用“normalize”时，他意味着从关系数据库中消除关系值（“非简单”）域：
出于这个原因（以及下面引用的其他内容），消除非简单域的可能性似乎值得研究。事实上，有一个非常简单的消除过程，我们称之为规范化。
后来出现了“更高的NF”（涉及JD（连接依赖））的概念，并且“规范化”具有不同的含义。由于Codd的原始规范化论文归一化理论总是给出适用于所有关系的结果，而不仅仅是Codd的1NF中的那些关系。因此，人们可以在原始意义上“规范化”，从正义关系转变为没有关系值列的“规范化”/“1NF”形式，并且可以在规范化理论意义上“规范化”从仅仅关系“1NF” “更高的NF，而忽略域名是否是关系。并且“规范化”也（用于）设计非关系数据库的关系版本（无论是关系和/或某种“1NF”意义）。
关系精神是避开具有相同含义的多个列或具有有趣部分的域，以支持另一个基表。但是我们必须总是做出一个非正式的人体工程学决定，关于何时停止表示零件，并将列视为“原子”（非关系值）与“非原子”（关系值）。