数据库（第一范式，第二范式，第三范式）

 范式：英文名称是 Normal Form，它是英国人 E.F.Codd（关系数据库的老祖宗）在上个世纪70年代提出关系数据库模型后总结出来的，范式是关系数据库理论的基础，也是我们在设计数据库结构过程中所要遵循的规则和指导方法。目前有迹可寻的共有8种范式，依次是：1NF，2NF，3NF，BCNF，4NF，5NF，DKNF，6NF。通常所用到的只是前三个范式，即：第一范式（1NF），第二范式（2NF），第三范式（3NF）。下面就简单介绍下这三个范式。 

第一范式（ 无重复的列）

定义：数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。如果实体中的某个属性有多个值时，必须拆分为不同的属性

通俗解释：一个字段只存储一项信息

eg:班级：高三年1班，应改为2个字段，一个年级、一个班级，才满足第一范式

不满足第一范式

学号	姓名	班级
0001	小红	高三年1班

改成

学号	姓名	年级	班级
0001	小红	高三年	1班

第二范式（ 属性完全依赖于主键）

定义：满足第一范式前提， 当存在多个主键的时候，才会发生不符合第二范式的情况。比如有两个主键，不能存在这样的属性，它只依赖于其中一个主键，这就是不符合第二范式

通俗解释：任意一个字段都只依赖表中的同一个字段

eg:比如不符合第二范式

考虑一个订单明细表：【OrderDetail】（OrderID，ProductID，UnitPrice，Discount，Quantity，ProductName）。 
因为我们知道在一个订单中可以订购多种产品，所以单单一个 OrderID 是不足以成为主键的，主键应该是（OrderID，ProductID）。显而易见 Discount（折扣），Quantity（数量）完全依赖（取决）于主键（OderID，ProductID），而 UnitPrice，ProductName 只依赖于 ProductID。所以 OrderDetail 表不符合 2NF。不符合 2NF 的设计容易产生冗余数据。

订单ID	商品ID	商品单价	折扣	数量	商品名称

改成2张表如下

订单表

订单ID	商品ID	折扣

商品表

商品ID	商品单价	商品名称

第三范式（ 属性不能传递依赖于主属性）

定义：满足第二范式前提， 如果某一属性依赖于其他非主键属性，而其他非主键属性又依赖于主键，那么这个属性就是间接依赖于主键，这被称作传递依赖于主属性。

通俗理解：一张表最多只存2层同类型信息

eg:爸爸资料表，不满足第三范式

爸爸	儿子	女儿	女儿的小熊	女儿的海绵宝宝

改成

爸爸信息表：

爸爸	儿子	女儿

女儿信息表

女儿	女儿的小熊	女儿的海绵宝宝