第一范式
1NF,强调数据中列的原子性,即列中的值不能再分割为其他列。
例如:
现在有一个用户User表,表中字段分别包括,用户名,联系方式,性别等信息。
username | sex | tel |
---|---|---|
小明 | 男 | 13112345678 0755-1234567 |
小红 | 女 | 13234567890 |
从表中可以看出,小明的数据中联系方式有两种,包括手机和固话,而小红的联系方式中只有手机。所以这样的表结构是不符合1NF的。下面我们将表结构进行进一步拆分:
username | sex | tel | phone |
---|---|---|---|
小明 | 男 | 13112345678 | 0755-1234567 |
小红 | 女 | 13234567890 |
我们将表中的联系方式字段拆成了手机和固话两个字段,现在这张表中的字段都是不可再分割的了。所以,满足了第一范式。
第二范式
2NF,首先必须满足1NF规范。另外其有两个特点:一是表必须有一个主键(可以是多个字段组成的联合主键);二是非主键列必须完全依赖于主键整体,而不能只依赖主键的一部分。
例如:
现在有一张订单详情OrderDetail表,订单表示是用户下单寄件的行为产生的一个订单,但是用户可能一次性寄出很多个不同地址的货物,每个收件地址会产生一个运单号。所以一张订单详情表中由订单ID和运单ID为联合主键,还包括了收件人姓名,收件人地址,收件人联系方式,寄件人电话,寄件人下单时间,寄件人下单,运费相关方式等等。
orderID | waybillID | shipperPhone | shipperTime | shipperSource | receiverName | receiverAddress | receiverPhone | fee |
---|---|---|---|---|---|---|---|---|
12345678 | 2345 | 13112345678 | 20170323 11:23:14 | 电话下单 | 小明 | 广州 | 13223456789 | 12 |
12345678 | 2346 | 13112345678 | 20170323 11:23:14 | 电话下单 | 小红 | 上海 | 15723416555 | 23 |
从上表可以看出,其实收件人姓名,地址,联系方式等列只与waybillID相关,不同的运单,才会有相关的收件人信息。而用户下单相关的信息也只有订单内容相关,与运单内容无关。所以这样的表设计是不符合2NF规范的。下面我们来进行拆分。
OrderDetail表
orderID | waybillID | shipperPhone | shipperTime | shipperSource | fee |
---|---|---|---|---|---|
12345678 | 2345 | 13112345678 | 20170323 11:23:14 | 12 | |
12345678 | 2346 | 13112345678 | 20170323 11:23:14 | 13 |
waybill表
waybillID | receiverName | receiverAddress | receiverPhone |
---|---|---|---|
2345 | 小明 | 广州 | 13223456789 |
2346 | 小红 | 上海 | 15723416555 |
我们将orderDetail表中的内容进行了拆分,将与运单相关的信息,分到了waybill表中,这样在订单表中只保留了与订单表相关的信息。这样,便满足了第二范式。
第三范式
同样首先必须满足2NF,另外非主键列必须直接依赖于主键,不能存在传递依赖。传递依赖的意思是,例如非主键A列依赖于非主键B列,非主键B列依赖于主键的情况。
例如:
用户下单寄件时,通过我们的官网进行下单,用户已经是我们的会员,所以我们会保存用户的一些相关信息,会员下单会有一些优惠等等。所以我们的订单表里面有下面这些信息:订单ID,订单下单时间,订单来源,会员ID,会员名称,会员联系方式等。
orderID | oderDate | orderSource | customerID | customerName | customerTel |
---|---|---|---|---|---|
1234567 | 20170303 10:28:13 | 官网下单 | 2134 | 小明 | 13212345678 |
1232146 | 20170112 23:12:01 | 微信下单 | 7251 | 小红 | 13523125647 |
从上表可以看出会员的相关具体信息是依赖于会员ID存在的,会员ID又依赖于订单ID,所以这张表的设计师不符合3NF的,现在我们来对表进行改造,让它符合第三范式。
order表
orderID | oderDate | orderSource | customerID |
---|---|---|---|
1234567 | 20170303 10:28:13 | 官网下单 | 2134 |
1232146 | 20170112 23:12:01 | 微信下单 | 7251 |
customer表
customerID | customerName | customerTel |
---|---|---|
2134 | 小明 | 13212345678 |
7251 | 小红 | 13523125647 |
我们将Order表中关于会员的信息拆分出来,做为会员customer表,这样将与订单无关的信息抽出来,就符合了第三范式。