百科的东西是有多不靠谱啊。下面内容将摘自《SQL Server 2008数据库设计与实现》人民邮电出版社，2009年11月。地址book*51cto#com/art/200910/157200@htm。。

　　忘记说了，专心看书的时候被碍事儿的家伙找事果然很令人火大呢。

·类、对象和属性的形式：第一范式
　所有属性必须是原子的，也就是说，在单个对象（当然，属于一个类）的单个属性中，应该只有单个的值。
　一个类的所有对象必须包含相同数量的值。（很多地方都用了这样的表达，而不是“类必须有确定的属性结构，所有对象其属性结构必须与所属的类相符”）
　一个类中的所有对象必须不同。
　　关于这三条，都会有详细说明——

　　第一范式的三个要求呢，后面两个比较好理解：
　②相同的对象结构。一张表（关系数据库中一个关系就表现为一张表）每一行的列数不同，或者虽然列数相同，但是同一列在不同的行有不同的含义和数据（或者对象）类型，不同的数据类型有不同的的存储方式、适用函数、接口等，无论是存储还是操作都有很大的麻烦。当然可以用一个自定义的类来管理一些完全不同的数据类型从而放在一个列中，这个类指导了系统如何存储共用一个列的不同数据类型，也提供了不同数据类型共用的接口，在形式上，这个列还是只有一种数据类型（自定义的管理类），表中的对象结构依旧保持一致。至于说一个列被拆分的情形，这时把拆分的列看作单列，在①中讨论。
　③所有对象必须不同。在设计角度，是要求同一个客观对象在一个关系中不应有多条记录；在实现角度，是要求一个类中不应有多个各项属性对应相同的对象。设计角度而言，一个对象被重复记录，会存在冗余和影响统计两个问题；实现角度而言，由于SQL是基于集的语言，属性相同的对象总会被同时搜索到并执行相同的操作（DBMS中经常有那么几个函数会不符合这一点，比如first什么的，注意这样的函数很可能不是SQL标准函数，而是某个DBMS所独有的），因为它们永远不会被区分，那还留着干啥。如果有一批对象，它们客观上不是同一个，但录入在数据库中的属性都相同（数据是对客观对象的抽象，而不可能是完整的再现），比如你拿到了两个苹果，在属性的误差范围内重量、大小、颜色等全都相等，这时候你需要人为地进行类似于编号的工作，即设置一个“代理键”。
　①那么，原子性，这算是解释起来最复杂的一个吧。


　　今天，我们来讨论原子性。
　　原子性的要求前面已经说过了，单个属性单个值。这里单个值并不是要求为基本数据类型，在设计层面，基本数据类型和各种自定义类是平等的。
　　作者对此的解释为，对属性值的使用是将属性值作为一个整体使用，而不取其分量。比如一个坐标对象，如果总是传输整个坐标，比较两个坐标是否相同或计算其距离，则一个坐标对象就有原子性；如果经常存取它的x或者y分量，那么这个坐标对象就不具有原子性，应该将x和y分作两个属性。当然这个也不是绝对的，因为分量操作可以看作是用一个函数操作整体的坐标对象。
　　此外，作者还讨论了多值属性的情形。多值属性的三种实现形式：多值类，分列存储，属性对象。多值类方案与上一段的分量情形类似，其原子性是需要商榷的。分列存储方案欲严格满足原子性，要求分列数量确定，且列之间不可交换信息（两个列表示同一个含义，值可以相互复制，作为一个表看着也不合理嘛），详细见后。属性对象方案是将多值属性处理成多对多关系（一个属性值可能多个对象都拥有不是么），这个方案很好地保证了原子性。
　　分列存储方案，举个例子，对多个电话号码的管理。一个人可能有住宅固话、办公固话、手机等电话号码。采用分列存储方案，如果分成住宅固话、办公固话、手机三列，那么没有明显问题；如果分成号码1、号码2、号码3三列，那么问题很明显，号码1、2、3的顺序是否重要，删除号码1之后号码2、3是否需要位移，比较两人是否有相同电话号码时会不会发生跨列比较（其实住宅固话、办公固话、手机划分方法也存在此问题）。至于万一某人有第四个号码或者住宅、办公、手机之外的号码种类这种问题，在分列存储方案里提都不要提。你会发现，除了第四个号码这一点外，多值类方案也会面临这种问题，只不过把这些问题的处理封装到类中，不在数据库里表现。
　　事实上，原子性这一条，有很大的抽象概念性和相对性，偶还是抽空看看SQL国际标准吧。在软件实现方面绕开规则判断建立数据库是可以的，但是使用这样的数据库时可能带来很复杂的编程。它指导着我们认真进行需求分析和扩展性等多方面的考虑。