数据库设计三大范式！！
转载自：没腿的鸟
为什么要谈及范式？
这也是为了数据库设计做准备，对于表设计而言，我们需求何种程度的设计，这完全取决你数据的规模，好比你建房子，要是建个一两层，基本上不需要什么设计，直接开工就行，要是建个这样的房子还找设计公司的话，这无疑是大材小用，浪费；但是，对建一座大厦来说，不做规划，不请教不咨询设计公司，后果难以想象了。当然，为了设计结构合理的数据库，必须遵循一定的规则，在关系数据库中这种规则就称为范式，范式是符合某一种设计要求的总结
1.第一范式（1NF）无重复列
通俗理解：列不可分
在任何一个关系数据库中，满足第一范式是关系数据库的基本要求。
所谓的第一范式是指数据库表的每一列都是不可划分的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。
如果数据库表中的所有字段值都是不可再分解的原子值，即无重复列，就说明该数据库表满足第一范式。
注意的是：第一范式的合理逻辑通常是根据实际需求来定的。比如某些数据库系统中需要用到“地址”这个属性，本来直接将“地址”属性设计成一个数据库表的字段就行（表一所示）。但是如果系统经常会访问“地址”属性中的“城市”部分，那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储，这样在对地址中某一部分操作的时候将非常方便（表二所示）。这样设计才算满足了数据库的第一范式。
2.第二范式（2NF）属性完全依赖于主键
通俗理解：不能部分依赖。即，候选码是组合键时（联合主键），非主属性要完全依赖于组合键，而不能依赖于组合键的部分属性。
换句话来说就是一个表中的数据只能保存一种且必须与主键相关。
第二范式是在第一范式的基础上建立起来的。第二范式需要确保数据表中的每一列和主键相关，而不能只与主键的某一部分相关（主要针对联合主键）。
下表所示快递单号与商品编号为联合主键，但是在该表中商品名称，数量，价格（单价）并不是与联合主键直接关联，所以不符合第二范式。
然而，把上表进行拆分，得到下列表，这样就完全符合第二范式设计要求。
3.第三范式（3NF）属性不能传递依赖于主键（减少数据冗余，这样就可以通过主外键进行表之间连接）
通俗理解:不能存在传递依赖。 除了主键外，其他字段必须依赖主键
传递依赖：如果某一属性依赖于其他非主属性，而其他非主属性又依赖于主键，那么这个属性间接依赖于主键，这称为依赖传递于主属性
满足第三范式必须先满足第二范式，第三范式要求一个数据数据库表中不包含已在其他表中已包含的非关键字信息，数据表如果不存在非关键字属性对任一候选关键字段的传递依赖则符合第三范式
因为上表的玩具车与玩具枪属于儿子，因此不符合第三范式，对上表进行拆分
