我在1NF形式的DBMS中读过类似下面的内容。
有一句话如下：
＆＃34;每列都应该是原子的。＆＃34;
任何人都可以通过一个例子向我解释一下吗？
答案 0 :(得分：6)
Atomicity和1NF ......不是关于原子事务，而是关于定义和列内容。
＆＃34;原子＆＃34;意味着＆＃34;不能分割或拆分成更小的部分＆＃34;。应用于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列是方便的。但我已经看到了......并且有充分的理由：用例是司法部门数据库的生日。他们不得不处理很多或几乎没有文件的移民。有时你只知道一个人出生在某一年，但你不会知道一天或一个月或出生。您无法使用单个日期列处理该类型的信息。
答案 1 :(得分：6)
重新＆＃34;原子＆＃34;
在Codd的原始1969年和1970论文中，他将关系定义为连续每个属性的值。价值可以是任何东西，包括关系。这没有使用＆＃34; atomic＆＃34;的概念。他解释说＆＃34; atomic＆＃34;意味着不是关系价值的（即不是表值）：
到目前为止，我们已经讨论了定义的关系的例子 简单域 - 其元素是原子的（不可分解的）域 值。可以在关系中讨论非原子值 框架。因此，某些域可能具有关系作为元素。
他使用＆＃34;简单＆＃34;，＆＃34; atomic＆＃34;和＆＃34;不可分解＆＃34;作为非关系非正式说明性概念。他理解一个关系有一些行，每列都有一个相关的名称和值;属性是通过定义＆＃34;单值＆＃34 ;;价值是任何类型。关系重要的唯一结构性质是关系。它也只是一个值，但你可以查询它。然后他使用＆＃34; nonsimple＆＃34;等意思关系价值。
到1990年Codd的书The Relational Model for Database Management: Version 2：
时从数据库的角度来看，数据可以分为两种类型： 原子和化合物。原子数据不能分解成更小的 DBMS的部分（不包括某些特殊功能）。复合 由原子数据的结构化组合组成的数据可以是 由DBMS分解。
在关系模型中，只有一种类型的复合数据： 关系。定义每个关系的域中的值 对于DBMS，要求是原子的。关系 数据库是各种程度关系的集合。全部 查询和操纵操作符是关系，所有这些操作符 产生关系作为结果。为什么只关注一种化合物 数据？主要原因是任何其他类型的复合数据 在不增加功率的情况下增加复杂性。
＆＃34;在关系模型中，只有一种类型的复合数据：关系。＆＃34;
可悲的是，＆＃34;原子=非关系＆＃34;不是你会听到的。 （不幸的是，Codd并不是最聪明的作家，而且他的说明性评论与他的底线相混淆。）几乎所有关系模型的演示都没有比Codd仅仅作为垫脚石的更多。他们提出了一个无益的混淆模糊概念，将其标准化/册选为＆＃34; atomic＆＃34;确定＆＃34;标准化＆＃34;。有时他们错误地使用它来定义实现。而Codd每天使用＆＃34;非原子＆＃34;引入定义关系＆＃34;非原子＆＃34;作为关系价值和定义＆＃34;标准化＆＃34;没有关系价值的域名。
（也不是＆＃34;不是重复的团体＆＃34;有用的＆＃34;原子＆＃34;，将其定义为甚至不是关系概念的东西。确实在1970年Codd说＆＃ 34;当前数据库术语中的术语属性和重复组大致类似于简单域和非简单域，分别为＃34;。
例如：这种误解在很早的时候就被Chris Date，尊贵的早期关系解释者和传教士推广了很长一段时间，主要是在他的开创性的当前着作“数据库系统简介”中。现在（2004年第8版）幸运地提出了有用的关系导向的扩展概念，即区分关系，行和＆＃34;标量＆＃34; （非关系非行）域：
该定义仅表明所有[关系变量]均为1NF
例如：迈尔斯＆＃39;经典The Theory of Relational Databases (1983)：
原子的定义是模糊的;一个应用程序中的原子值在另一个应用程序中可能是非原子的。对于一般准则，如果应用程序仅处理值的一部分，则值是非原子的。
例如：关于First NF（普通表格）部分的当前维基百科文章实际上引用了上面介绍性部分。然后忽略的确切含义。 （然后它说了一些关于非原子龟应该停止时无法理解的事情。）：
Codd声明每个域中的＆＃34;值 定义的关系必须是相对于的原子 DBMS＆＃34。 Codd将原子值定义为无法分解的原子值 由DBMS分成小块（不包括某些特殊功能）＆＃34; 意思是一个字段不应该被分成多个部分 其中的数据类型使得一部分对DBMS的意义取决于它 在同一领域的另一部分。
重新＆＃34;标准化＆＃34;和＆＃34; 1NF＆＃34;
当Codd使用＆＃34;标准化＆＃34;在1970年，他的意思是从关系数据库中消除关系价值（＆＃34;非简单＆＃34;）域名：
由于这个原因（和下面引用的其他人）的可能性 消除非简单域名似乎值得研究。有， 事实上，我们将称之为一个非常简单的消除程序 正常化。
后来更高的NF＆＃34;＆＃34;更高的NF＆＃34; （涉及JD（加入依赖关系））出现并且＆＃34;规范化＆＃34;具有不同的含义。由于Codd的原始规范化论文归一化理论总是给出适用于所有关系的结果，而不仅仅是Codd的1NF中的那些关系。因此，人们可以＆＃34;规范化＆＃34;从原始意义上说，从正义关系转变为标准化＆＃34; /＆＃34; 1NF＆＃34;形式没有关系值列，一个可以＆＃34;标准化＆＃34;在规范化理论意义上来自正义关系又名＆＃34; 1NF＆＃34;更高的NF而忽略域是否是关系。并且＆＃34;规范化＆＃34; （ill-）用于设计非关系型数据库的关系版本（无论是关系和/或某种意义上的＆＃34; 1NF＆＃34;）。
关系精神是避开具有相同含义的多个列或具有有趣部分的域，以支持另一个基表。但我们必须始终做出非正式符合人体工程学的决定，关于何时停止表示零件，并且将列视为＆＃34; atomic＆＃34; （非关系价值的）vs＆＃34;非原子的＆＃34; （关系值）。
答案 2 :(得分：1)
“每列都应该是原子的。”
Chris Date说，“请非常仔细地注意，不仅仅是像整数3这样的简单事物是合法的值。相反，值可以是任意复杂的;例如，一个值可能是几何点，或多边形，X射线，XML文档，指纹，数组，堆栈，列表或关系（等等）。“[1] < / p>
他还说，“当且仅当在该relvar的每个合法值中，每个元组都包含每个属性的一个值时，relvar在1NF中。”[2]
他通常不鼓励使用 atomic 这个词，因为它含有令人困惑的内涵。 单值可能是一个更好的术语。
例如，像'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是非常关系的。
答案 3 :(得分：-1)