什么是三大范式?
简单点说就是设计数据表结构的原则和参考标准。
l 一范式就是属性不可分割。属性是什么?就是表中的字段。不可分割的意思就按字面理解就是最小单位,不能再分成更小单位了。
l 二范式就是要有主键,要求表中其他字段都依赖于主键,什么是主键,主键就是标识一行数据的唯一性,没有唯一性在集合中就定位不到这行记录。
l 三范式就是要消除传递依赖,方便理解,可以看做是“消除冗余”。

有以下用户信息表(user)
姓名 | 性别 | 身份证号 | 手机号 | 住址 |
张三 | 男 | 421126197801048526 | 13963635263 | 湖北武汉 |
李四 | 男 | 421126197801048526 | 13852456235 | 湖北武汉 |
(表一)
表一中,姓名、性别、身份证号、手机号、住址都是最小单位不可分割。满足数据库设计一范式。
表一种,记录没有唯一标识,因此不满足二范式。
用户id | 姓名 | 性别 | 身份证号 | 手机号 | 住址 |
A0001 | 张三 | 男 | 421126197801048526 | 13963635263 | 湖北武汉 |
A0002 | 李四 | 男 | 421126197801048526 | 13852456235 | 湖北武汉 |
(表二)
表二中有主键作为一条记录的唯一标识,满足二范式。
订单表(order)
订单id | 姓名 | 手机号 | 订单编号 | 收货地址 |
B0001 | 张三 | 13963635263 | AB0001 | 湖北武汉xxx |
B0002 | 李四 | 13852456235 | AB0002 | 湖北武汉xxxx |
(表三)
订单表中包含用户的信息,包含订单的信息,由于用户姓名、手机号与用户表中重复、信息冗余,间接关联。这种情况不满足第三范式原则。
满足第三范式原则,应该这样设计:
订单编号 | 用户id | 订单id | 收货地址 |
AB0001 | A0001 | B0001 | 湖北武汉xxx |
AB0002 | A0002 | B0002 | 湖北武汉xxxx |
订单中用户信息是通过用户的唯一标识,用户id来进行关联的,确保数据不会有冗余。(表中的每一列只能依赖于主键)




