下面是肖对三范式的简单理解：第一范式：每列具有不可再分割的原子性第二范式：每表必须有主键列，且其余各列均必须与该主键列具有内在的逻辑关系第三范式：当建立表间关系时，子表中有且只有主键列作为父表的外键列下图是我对三范式的简单理解:第一范式（1NF）：要求HYPERLINK"http://baike.baidu.com/view/68347.htm"关系模式R的所有属性都是不可分的基本HYPERLINK"http://baike.baidu.com/view/178581.htm"数据项，指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。例如：比如某些数据库系统中需要用到“地址”这个属性，本来直接将“地址”属性设计成一个数据库表的字段就行。但是如果系统经常会访问“地址”属性中的“城市”部分，那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储，这样在对地址中某一部分操作的时候将非常方便。这样设计才算满足了数据库的第一范式，如下表所示。用户信息表编号姓名性别年龄联系电话省份城市详细地址1张红欣男260378-23459876河南开封朝阳区新华路23号2李四平女320751-65432584广州广东白云区天明路148号3刘志国男210371-87659852河南郑州二七区大学路198号4郭小明女270371-62556789河南郑州新郑市薛店北街218号上表所示的用户信息遵循了第一范式的要求，这样在对用户使用城市进行分类的时候就非常方便，也提高了数据库的性能。第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）首先要求数据库表中首先必须有主键。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。其次要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。采用投影分解法将一个1NF的关系分解为多个2NF的关系，可以在一定程度上减轻原1NF关系中存在的插入异常、删除异常、数据冗余度大、修改复杂等问题。比如要设计一个订单信息表，因为订单中可能会有多种商品，所以要将订单编号和商品编号作为数据库表的联合主键，如下表所示。订单信息表订单编号商品编号商品名称数量单位商品价格0011挖掘机1台1200000￥0022冲击钻8个230￥0033铲车2辆980000￥这样就产生一个问题：这个表中是以订单编号和商品编号作为联合主键。这样在该表中商品名称、单位、商品价格等信息不与该表的主键相关，而仅仅是与商品编号相关。所以在这里违反了第二范式的设计原则。而如果把这个订单信息表进行拆分，把商品信息分离到另一个表中，就非常完美了。如下面这两个所示。订单信息表订单编号商品编号数量001110022800332商品信息表商品编号商品名称单位商品价格1挖掘机台1200000￥2冲击钻个230￥3铲车辆980000￥这样设计，在很大程度上减小了数据库的冗余。如果要获取订单的商品信息，使用商品编号到商品信息表中查询即可。第三范式3NF是第二范式（2NF）的一个子集，即满足第三范式必须满足第二范式。第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关，即任何非主属性不得传递依赖于主属性。简而言之，就是要求一个关系中不包含已在其它关系已包含的非主关键字信息。（不满足时常采用投影分解法解决）比如在设计一个订单数据表的时候，可以将客户编号作为一个外键和订单表建立相应的关系。而不可以在订单表中添加关于客户其它信息(比如姓名、所属公司等)的字段。如下面这两个表所示的设计就是一个满足第三范式的数据库表。订单信息表订单编号订单项目负责人业务员订单数量客户编号001挖掘机刘明李东明1台1002冲击钻李刚霍新峰8个2003铲车郭新一艾美丽2辆1客户信息表客户编号客户名称所属公司联系方式1李聪五一建设132536610152刘新明个体经营13285746958这样在查询订单信息的时候，就可以使用客户编号来引用客户信息表中的记录，也不必在订单信息表中多次输入客户信息的内容，减小了数据冗余。