范式备忘录

1. 每个分量必须是不可分的数据项。按我的理解，就一个字段就是一种值，而不用自己再去对里面的值根据特殊符号进行解析得出更多的值来。
2. 每一个非主属性完全依赖于码，而不是部分依赖于码中的某个属性。毕竟一个码可能由几个属性组成。
3. 可以决定任意属性的因素（属性）都包含码，即每个决定因素都是码，不存在不是码但又能决定某个字段值的字段存在。

3大范式全部针对一张表（一个关系模式）。

附：
第一范式没那么玄乎，只要表的每个字段能对应成一个属性就算满足了。这点可能因为有点太基本，很多人反而不好理解。例如，一个个人资料表里面有个儿女字段，如果保存是按"张三id、李四id”；取出时自己再根据顿号分割得到两个id，那么这种情况违反第一范式，因为儿女这个字段可以再分。
至于主键，在极端情况下就是all-key，也就是全部属性合在一起构成主键。如果两行数据完全相同，那根本就算不上关系数据库了。
所以说，金融、电信类的大项目里，虽然问题很多，但基本还是符合第一范式的。因此可以算满足范式的基本要求。虽然一个字段里需要自己再根据特殊符号进行解析的事情是存在的。

范式主要还是为了解决插入和删除的异常，一般只要不是没法插入或者删除时会把共用信息也给删除，写代码的和维护的都会接受。前者在需要给出主键的值而又给不出来的时候会遇到，后者就靠冗余来补救了。至于字段很多，那估计是逐步逐步演化成那样的。用写dao的技术，形成这种局面是正常的，毕竟操作一张表即使字段和值多一些，也不一定比操作几张表来的麻烦。ms sql的update支持对联和后的表进行修改，得到很多程序员的赞许，也是因为这个道理，虽然语句长一点、字段多一点，但是一条语句就搞定了。

应该说，程序员基本遵守了第一范式，这样保证数据库可以做的下去；而弱化了主键的概念来减少自己在insert时的麻烦；delete的异常一个靠冗余，另一方面通过设置isdelete=true来解决，这样就不会真的发生删除异常；update反正更新几张表和更新多条记录比起来，在写dao的情况下，也还算凑合；至于select，冗余的查起来可能还方便。

不过有了ORM，情况就变了。agile web那本书里面并没有直接给出以数据库为主还是以object为主，但实际上由于activcerecord这个中间层存在，个人认为从哪个角度出发已经都无所谓了。而她所提供的save和分几步查询的这种方式，使得设计朝第三范式靠拢的意义变大。

从我的角度来说，我实在搞不懂什么样对象模型设计才是漂亮的，但我能鉴别的是第三范式的数据库设计确实比只符合第一范式的要漂亮。我想，这也是表驱动的一个原因。


The ubiquity of both these models (RDBMS and OOP) and the "impedance mismatch" between
them has led many people to try to bridge this gap. The software bridge that accomplishes
this is called an Object-Relational Mapper (ORM).

The   library for Ruby is named after Martin Fowler's "Active Record" design
pattern. In essence, it ties database tables to classes so that the data can be manipulated
intuitively without SQL. To be more specific, it "wraps a row in a database table or view,
encapsulates the database access, and adds domain logic on that data"

Besides being a stand-alone ORM package for Ruby, Active Record is also the model part of the web-application framework Rails. Rails and Active Record are both projects conceived by DavidHeinemeierHansson and improved upon by a number of Contributors.
http://wiki.rubyonrails.org/rails/pages/ActiveRecord