范式:英文名称是 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 的设计容易产生冗余数据。
因为我们知道在一个订单中可以订购多种产品,所以单单一个 OrderID 是不足以成为主键的,主键应该是(OrderID,ProductID)。显而易见 Discount(折扣),Quantity(数量)完全依赖(取决)于主键(OderID,ProductID),而 UnitPrice,ProductName 只依赖于 ProductID。所以 OrderDetail 表不符合 2NF。不符合 2NF 的设计容易产生冗余数据。
订单ID | 商品ID | 商品单价 | 折扣 | 数量 | 商品名称 |
改成2张表如下
订单表
订单ID | 商品ID | 折扣 |
商品表
商品ID | 商品单价 | 商品名称 |
第三范式(
属性不能传递依赖于主属性)
定义:满足第二范式前提,
如果某一属性依赖于其他非主键属性,而其他非主键属性又依赖于主键,那么这个属性就是间接依赖于主键,这被称作传递依赖于主属性。
通俗理解:一张表最多只存2层同类型信息
eg:爸爸资料表,不满足第三范式
爸爸 | 儿子 | 女儿 | 女儿的小熊 | 女儿的海绵宝宝 |
改成
爸爸信息表:
爸爸 | 儿子 | 女儿 |
女儿信息表
女儿 | 女儿的小熊 | 女儿的海绵宝宝 |