数据库设计范式

    设计关系数据库时，我们需要遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。

    目前关系数据库有六种范式：第一范式（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	华硕

 

制造商名称（主键）	制造商地址
华硕	深圳
微星	台湾

      这样数据表就满足了第三范式的要求。