深入浅出分析数据库设计的三大范式以及背后的原因_数据库设计三范式

1、前言

        数据库设计三范式是关系型数据库设计的一种标准化过程，目的是消除数据冗余，提高数据存储和查询的效率。它包括第一范式（1NF）、第二范式（2NF）和第三范式（3NF）。

• 第一范式（1NF）

        确保每一列都具有原子性，即每一列的数据都是不可分割的。这说明每个单元格中的数据都是最基本的单位，不能再细分为更小的部分。

• 第二范式（2NF）

       所有 非主键列必须完全依赖于整个主键，而不是主键的一部分。这里有两层含义：一是整个表必须存在一个主键，而是其他非主键列都必须完全依赖主键，不存在部分依赖现象。

• 第三范式（3NF）

        表中的任何非主键列都不应该依赖于其他非主键列，即不存在传递依赖。换句话说，任何非主键属性都应该完全依赖于主键，而非通过其它非主键属性间接依赖于主键。

        数据库三大设计范式是层层递进的，即要满足第二范式，首先必须要满足第一范式；满足第三范式，前提是先满足第二范式。

        下面通过具体的例子来说明数据设计的三大范式，以及需要遵循这些设计范式的原因。

2、第一范式

        第一范式要是数据表中的每个字段都是不可分割的原子值。

2.1 第一范式设计案例

        考虑下面一个表设计：

如果是按照上面设计格式，显然这个表就不符合设计的第一范式，因为显然地址这个字段还能够进一步分割为省份和地区，所以可以按下表的设计：

2.2 遵循第一范式的好处

        遵循第一范式可以提高数据库存储的效率以及减少一些额外的操作。

        假如按照表格2-1设计，首先如果地址一列只是地区变化，但是省份不变，要更新数据的话，还需要对字符进行额外拼接处理；另外，如果查询时想要获取地址数据中的地区，也需要对查询的结果再进行额外的处理。

3、第二范式

        第二范式要求所有的非主键必须完全依赖整个主键，而不能依赖主键的一部分。

3.1 第二范式设计案例

        对于上面的订单详情表，因为一个订单中可能包含多种商品，因此仅仅是订单ID或者商品ID都无法确定商品的下单数量，因此可以将（订单ID，商品ID）设置为主键，下单数量是完全依赖于主键的。但是商品名称和商品单价只依赖于商品ID， 即存在部分依赖，所以上面的表不符合第二范式。

        正确的做法应该是将商品名称和商品单价单独拆分出一个新表，新表的主键是商品ID。

3.2 遵循第二范式的好处

        遵循第二范式的好处是可以减少数据冗余。

        第二范式主要是针对主键为多列的情况，即主键为多列才存在部分依赖。

        主键为多列字段，说明主键中仅仅某一个字段不具有唯一性（比如订单ID和商品ID），也即是说明对于每一行数据（记录），订单ID或商品ID可能存在重复。

        如果商品ID存在重复，但是商品名称和商品单价又完全依赖于商品ID，因此主要商品ID重复了，那么每行中的商品名称和商品单价都是完全一样的，即数据冗余了（表3-1中红色部分）。

4、第三范式

        第三范式要求任何非主键非列都不应该依赖于其它非主键列，即不存在依赖传递。

4.1 第三范式设计案例

        假如有下面一个学生信息表。学号是主键。

        从上面的表可以看出，实际上班主任年龄直接依赖于班主任姓名，通过班主任姓名间接依赖于学号，因此存在依赖传递，不符合第三范式。

正确做法也是将表进行拆分，将班主任年龄单独拆分出一个表，并以班主任姓名为主键（假定姓名不会重复）：

4.2遵循第三设计范式的好处

        遵循第三设计范式的好处是可以减少数据冗余，提高数据查询速度。

        在表4-1中，红色部分就是数据冗余，如果仅仅是查询/更新班主任相关信息，显然在表4-3中操作更快，同时避免对学生信息的影响，减少了数据异常的可能。

5、数据库设计需要综合考虑

        总的来说，遵循数据库三大设计范式，能够减少数据冗余和更新异常的风险，但是并非所有的场景下都需要严格遵守数据库设计三大范式，有时候适度的数据冗余可以提高查询性能（比如拆分成多个表，查询不同的表中的字段是需要联合查询，性能不如查询单表快）。因此，在实际运用中，设计者通常会根据业务需求和系统性能权衡是否严格按照设计范式进行设计。