1                 介绍

凡是做过数据库设计的，只要不是大菜鸟，听到范式两个字，马上就会在脑海中浮现1NF，2NF，3NF，BCNF这些术语，但是若要大家详细的将这几个东东的专业定义描述出来。。。。。。呵呵，至少大部分人都会晕的，什么功能依赖、函数依赖，~！@＃￥%……&*，my god！反正我是记不住：）

但既然上了IT这条贼船，就无法避免和数据库设计打交道，丑媳妇总是要见公婆的：）既然无法避免，那就让我们勇敢的面对，揭开数据库范式的神秘面纱，看看到底是一个丑媳妇还是一个俊媳妇！！

2                 一句话范式

数据库范式本身的定义这里就不啰嗦了，大家随便上网搜索或者找本教材看看，保证随处可见，我在这里给大家用通俗的语言描述出来。

在详细探讨之前还是啰嗦一句：千万要注意：范式只是在设计表的时候用的原则，数据库其它的设计例如索引、视图、触发器、存储过程等都和范式没有关系。

2.1                                 第一范式1NF

1NF在数据库设计中其实很简单：“列不可再分”。

什么叫列不可再分呢？意思就是每一列只包含一个属性，所有属性的类型都是一样的。

可能有人看到这里会说：晕，这还用说，谁设计的数据库表的列还可以再分呢？其实这句话只对了一部分，下面我们详细分析为什么叫只对了一部分。

我们目前说的和用的数据库都是关系数据库，而关系数据库中是不可能设计一个列能够包含两个不同类型的属性的；但大千世界，无奇不有，除了关系数据库，还有其它的数据库，例如面向对象数据库、XML数据库，这种数据库就可以设计一个属性再包含多个子属，所以1NF在关系数据库中是天然满足的，而在其它类型数据库就不一定了。

看了上面这段话，你是不是长吁一口气，心里踏实了，以为就可以从此不管1NF了呢？非也，数据库只做了第一层保证，但你还是可以设计不符合1NF的表来。下面我们给几个简单的例子，看看我们如何不遵守1NF。

例子1：Student表有一个属性name，类型为字符串。

这个是最简单的例子，估计很多人都如此设计过，数据库也不会拒绝我们创建这样的表，但这个设计是不符合1NF的，为什么？很简单的，名字其实是“有名有姓”的，这其实就是两个属性。比如我们要查找姓“李”的同学有多少，或者查询同名（例如“狗剩”）的有哪些。这样的查询如果只有一个name列，呵呵，只能用like来查询了，这样不同的名字方式（例如中国人姓在前，美国人姓在后），like都需要修改，而且like还不能利用索引加快查询速度。

例子2：Custom表中有一个属性Address。

大家可以自己按照上面的例子自己分析一下，看看会有什么问题……..

担心一次写太多，大家会晕，故分几次来写，未完待续。。。。。。