数据库设计范式
设计关系数据库时,我们需要遵从不同的规范要求,设计出合理的关系型数据库,这些不同的规范要求被称为不同的范式,各种范式呈递次规范,越高的范式数据库冗余越小。
目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,又称完美范式)。满足最低要求的范式是第一范式(1NF)。在第一范式的基础上进一步满足更多规范要求的称为第二范式(2NF),其余范式以次类推。一般说来,数据库只需满足第三范式(3NF)就行了。
第一范式(1NF)
通俗地讲,所谓第一范式(1NF)是指在关系模型中,每一个属性都应是不可再分的,即数据库表得每一列都是不可分割的原子数据项。
第一范式是为了要排除重复组的出现,所采用的方法是要求表中每个字段都只能存放单一值,而且每笔记录都要能利用一个惟一的主键来加以识别。
如下面的订单表:
姓名 |
购买数量 |
张三 |
10,20 |
李四 |
15,15 |
王五 |
12,90,3 |
这张表有明显的重复,如,张三,第一次购买10个,第二次购买20个,在购买数量这一栏,属性值不是唯一的,故应修改,修改如下:
姓名 |
购买数量 |
张三 |
10 |
张三 |
20 |
李四 |
15 |
李四 |
15 |
王五 |
12 |
王五 |
90 |
王五 |
3 |
这样修改后,虽然没有不重复,但是出现了两条一样的记录,这里不满足唯一性,故应把每条数据再加一个唯一的标识id,用来唯一标记每一条记录,再次修改如下:
ID |
姓名 |
购买数量 |
1 |
张三 |
10 |
2 |
张三 |
20 |
3 |
李四 |
15 |
4 |
李四 |
15 |
5 |
王五 |
12 |
6 |
王五 |
90 |
7 |
王五 |
3 |
这样就满足了第一范式的要求,不重复性,唯一性。
第二范式(2NF)
第二范式在第一范式的基础之上更进一层。
第二范式需要确保数据库中的每一列都和主键相关,而不能只与主键的某一部分相关(主要针对联合主键而言)。也就是说在一个数据库表中,一个表中只能保存一种数据,不可以把多种数据保存在同一张数据库表中。
如下表所示:
服务器id |
价格 |
供应商 |
供应商名称 |
供应商地址 |
1 |
1000 |
A |
阿里云服务 |
杭州 |
2 |
1500 |
B |
华为云服务 |
深圳 |
3 |
1200 |
C |
阿里云服务 |
杭州 |
这个数据表不重复,且是唯一的,故符合第一范式。这里把组件id与供应商id合在一起作为一个主键。价格是与服务器直接相关的,但是供应商名称及地址却与供应商有更多的联系,故不符合第二范式的原则,应把它拆开成两张表。
供应商ID(主键) |
供应商名称 |
供应商地址 |
A |
阿里云服务 |
杭州 |
B |
华为云服务 |
深圳 |
服务器id(主键) |
价格 |
供应商 |
1 |
1000 |
A |
2 |
1500 |
B |
3 |
1200 |
C |
第三范式(3NF)
第三范式是在满足第一范式和第二范式的基础上,再确保每一列数据都和主键直接相关,而不能间接相关。
组件号id |
制造商名称 |
制造商地址 |
1 |
华硕 |
深圳 |
2 |
微星 |
台湾 |
3 |
华硕 |
深圳 |
在这张表中,与组件号id(主键)比起来,制造商地址和制造商名称比较有关系,也就是说制造商地址比较依赖于制造商名称,故应拆开成两张表。
组件号id |
制造商名称 |
1 |
华硕 |
2 |
微星 |
3 |
华硕 |
制造商名称(主键) |
制造商地址 |
华硕 |
深圳 |
微星 |
台湾 |
这样数据表就满足了第三范式的要求。