数据库设计范式
设计关系数据库时，我们需要遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。
目前关系数据库有六种范式：第一范式（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 |
华硕 |
|
制造商名称（主键） |
制造商地址 |
|
华硕 |
深圳 |
|
微星 |
台湾 |
这样数据表就满足了第三范式的要求。
