标签：
第一范式（1NF）
第一范式的定义是关系模式中所有的属性都是不可再分的，即为原子性。这个比较好理解，它不是为处理冗余或者插入更新异常的，就是为了满足结构化数据的基本需要。假如一个学生的关系模式中，有身高体重两个属性，如果合在一起，现在需要读取他的身高，请问该如何处理？
第二范式（2NF）
在满足第一范式的基础上，如果关系模式中的非主属性均完全依赖于主键，即不存在非主属性对主键的部分依赖，那么该关系模式满足第二范式。
部分依赖，如果仅看这个词，它有两种解读。一种是主键不能完全决定非主属性，一种是主键的一部分可以决定非主属性。实际上，有不少人取了前一种解释，这是不正确的，因为如果主键不能决定非主属性，那么主键的意义就不存在了。或者说，我们讨论关系模式时，一条记录的唯一性由它的主键决定，这是根本的原则，否则就不是关系模式。
举例说明一下部分依赖。考虑这样一个采购管理系统，一个供应商可以提供多个产品，一个产品可以从多家供应商采购，相同的产品在不同的供应商可能价格不同。建立一个货品单价表，有商品ID、供应商ID、供应商地址、单价，显然（商品ID，供应商ID）是这个表的主键。
如果一个供应商提供几十个商品，那么供应商ID、供应商地址的关系就会出现几十次，而实际上仅有一次是有意义的，这就是数据冗余。
如果这个供应商换了办公地址，那么必须要把这几十条数据都更改了，否则会出现一个供应商对应两个地址的情况，这是更新异常。
如果新增一个供应商，但还没有它的商品信息，那么是不能录入数据库的，因为缺少商品ID这个主键，这是插入异常。
如果从目前这家供应商采购的商品都不再需要了，要删除掉，但是这个供应商还有其他商品会提供，只是此时还没有录入数据，如果删除已有商品，就会把供应商信息删掉，这是删除异常。
正确的解决办法，是把供应商ID和供应商地址独立出来组建一张新的表。
实际上，第二范式都是针对联合主键而言的，如果主键是单一属性，那么满足第一范式就必然满足第二范式。
第三范式（3NF）
在满足第二范式的基础上，若非主属性之间不存在依赖关系，则该关系模式满足第三范式。另一种表达的方式是，不能存在非主属性对主键传递依赖的关系，即主键（Key）->非主属性A，A->非主属性B。
以上面的例子为基础，我们考虑一个仓库管理系统。采购过来的货品需要放在仓库中存储，一种货品只会放在一个仓库中，但一个仓库可以放多种货品，一个仓库有一个管理员。如果我们建立这样一张表，包括货品ID、仓库、管理员，主键是货品ID，它满足第二范式，但不满足第三范式，因为管理员对仓库是完全依赖关系，它会有下面这些问题：
如果一个仓库有多个货品，那么仓库、管理员关系会出现在这个仓库所有货品中，这是数据冗余。
如果仓库换管理员，必须这个仓库所有的货品记录上都更改，否则会出现仓库、管理员对应不一致的情况，这是更新异常。
新建一个仓库，但还没有决定放什么货品，这时是无法录入数据库的，因为缺乏货品ID，这是插入异常。
假如一个仓库里面所有的货品使用完后都不在采购了，但又没有新的货品放到这个仓库里，这时删除已有货品信息会把仓库、管理员对应信息也删掉，这是删除异常。
正确的解决办法是把仓库、管理员关系独立出来新建一张表。
标签：
原文地址：http://www.cnblogs.com/stubbornboy/p/5399974.html
