超详细：数据库的三大范式与反范式设计_数据库反范式设计-优快云博客

本文链接：https://blog.youkuaiyun.com/2301_78884095/article/details/143805863

学习目标

三大范式
反范式设计
三大范式与反范式设计有什么区别

三大范式

数据库的三大范式是数据库设计中的重要概念，它们分别是第一范式（1NF）、第二范式（2NF）和第三范式（3NF）。这些范式旨在规范数据库表的设计，以减少数据冗余、提高数据的一致性和完整性。

设计数据库的时候需要遵循它的一些规范，目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。

我们正常情况下只要我们满足前面三个范式就可以设计一个较规范的数据库。

第一范式

第一范式（1NF）是对关系模型中的属性提出的原子性约束，以下是关于第一范式的详细介绍：

员工编号	姓名	年龄
001	张三	23
002	李四	24
003	小五	25

一、定义
第一范式（1NF）要求关系型数据库中的每个列都必须是原子的，即每列的值不能再分解成其他几列。也就是说，数据库表的每一列都是不可分割的原子数据项，而不能是集合、数组、记录等非原子数据项。

二、特点

无重复的域：在符合第一范式的表中，每个域值只能是实体的一个属性或一个属性的一部分。这意味着每个列中不能包含多个值或多个重复的值，如果存在多个值，应该拆分成多个列或多个表。
原子性：第一范式要求属性具有原子性，不可再分解。这是数据库设计的基本要求，一般设计中都必须满足第一范式。

三、实现方法

拆分列：如果某个属性包含多个值，应该将这些值拆分到不同的列中。例如，如果一个员工有多个电话号码，可以将这些电话号码拆分成多个列，或者创建一个新的表来存储电话号码。
创建新表：如果某个属性包含多个相关的数据项，可以创建一个新的表来存储这些数据项，并通过外键与原表建立关联关系。例如，如果一个订单包含多个商品，可以创建一个商品表，并将商品信息与订单信息通过订单ID进行关联。

四、意义
满足第一范式可以避免数据冗余和更新异常等问题。例如，如果某个属性包含多个值而没有进行拆分，那么在更新某个值时可能会影响到其他值，导致数据不一致。而通过将多个值拆分到不同的列或表中，可以更容易地更新和管理数据。

第一范式是数据库设计中的基础规范之一，它要求关系型数据库中的每个列都必须是原子的、不可再分解的。通过遵循第一范式，可以建立结构合理的数据库，提高数据存储和使用的性能。

第二范式

第二范式（2NF）建立在第一范式（1NF）的基础上，要求数据库表不仅满足1NF，而且要求表中的非主键属性完全依赖于主键。换句话说，一个表必须满足以下条件才能称为满足第二范式：

学号	姓名	年龄	课程	成绩	学分
001	张三	23	Java	203	43
002	李四	24	Spring Boot	204	44
003	小五	25	MyBatis	205	45
002	李四	24	Java	204	43
003	小五	25	Spring Boot	205	44

我们来看看这上面表结构来分析一下：

就是如果学号是这表的唯一主键，那么可以用学号来确定姓名和年龄，但是却不能保证确定课程和成绩。
就是如果课程是这表的唯一主键，那么可以用课程来确定学分，但是却不能保证确定姓名、年龄和成绩。
但是我们可以通过学号和课程联合主键，可以确定除联合主键外的所有的非主键值，但是这两个描述是不符合第二范式的要求滴！

那我们应该如何调整表的结构来让它能不能复合第二范式的要求嘞？

那我们可以基于上面说讲的三种主键可能、然后我们拆分成 3 张表、保证一张表只描述一件事情。

学生表 - 学号做主键

学号	姓名	年龄
001	张三	23
002	李四	24
003	小五	25

课程表 - 课程做主键

课程	学分
Java	43
spring Boot	44
MyBAtis	45

成绩表 - 学号和课程做联合主键

学号	课程	成绩
001	Java	203
002	Spring Boot	204
003	MyBatis	205
002	Java	204
003	Spring Boot	205

满足第一范式（1NF）：
表中的每一列都是原子的，即每一列中的数据都是不可分割的基本数据项。
表中的非主键属性完全依赖于主键：
消除部分依赖。在2NF中，要求表中的每一个非主键属性都完全依赖于整个主键，而不是主键的一部分。如果存在部分依赖，则需要将表拆分成多个表。

优点

减少数据冗余：通过将表拆分成多个表，可以避免在单个表中存储重复的数据。
提高数据一致性：如果数据存储在多个表中，更新和删除操作可以更加精确，从而保持数据的一致性。
提高查询效率：通过适当的表拆分，可以优化查询性能，因为可以只查询所需的表而不需要加载整个大表。

那这时候我们就会想我们为什么要遵循第二范式嘞？我们不遵守第二范式会发生什么嘞？
因为它有助于减少数据冗余、提高数据一致性和完整性，以及优化数据库性能。如果不遵循第二范式，可能会导致以下后果：

数据冗余：
- 如果存在部分依赖，即表中的某些非主键属性只依赖于主键的一部分而不是整个主键，那么这些属性可能会在表中重复出现。这会导致数据冗余，浪费存储空间，并增加数据维护的复杂性。
更新异常：
- 当需要更新表中的某个非主键属性时，如果该属性在表中多次出现（由于部分依赖导致的冗余），则必须更新所有相关的行。这不仅增加了更新操作的复杂性，还可能导致数据不一致，因为可能会遗漏某些需要更新的行。
删除异常：
- 如果某个主键值对应的行被删除，而该主键值的部分依赖属性在表中还有其他非主键行中存储，则这些非主键行中的部分依赖属性将变成孤立的、无意义的数据。这可能导致数据丢失或不一致。
插入异常：
- 在某些情况下，如果表中的非主键属性依赖于主键的一部分，并且这部分主键值在表中还不存在，则可能无法插入新的行，直到相关的主键值被插入。这限制了数据的插入顺序，并可能导致插入操作失败。
查询效率降低：
- 数据冗余可能导致查询性能下降。例如，如果需要在多个表中查找相同的数据（由于数据冗余），则可能需要执行多个查询或联接操作，这会增加查询的复杂性和执行时间。

总结
通过遵循第二范式，我们可以将表拆分成更小的、更专业的表，每个表只包含与特定实体相关的属性。这样，每个表都可以更好地反映其代表的实体，并且可以减少数据冗余、提高数据一致性和完整性。此外，更小的表通常更容易优化和维护，从而可以提高数据库的整体性能。
因此，在数据库设计中遵循第二范式是非常重要的，它有助于确保数据库的结构合理、数据准确且易于维护。

第三范式

数据库的三大范式中的第三范式（3NF）是在第二范式（2NF）的基础上提出的进一步规范化要求。以下是关于第三范式的详细解释：
一、第三范式的定义

第三范式要求，在一个数据库中，如果某个表已经满足了第二范式，那么该表中的非主键列必须不依赖于其他非主键列，即消除传递依赖。

二、传递依赖与第三范式的关系

传递依赖：在数据库表中，如果一个非主键列依赖于另一个非主键列，而这个非主键列又依赖于主键，则形成了传递依赖。例如，在一个员工信息表中，如果部门名称（非主键列）依赖于部门编号（非主键列），而部门编号又依赖于员工编号（主键），则存在传递依赖。
第三范式的要求：为了消除传递依赖，需要将依赖于其他非主键列的非主键列抽取出来，形成新的表，并通过外键与原表关联。这样，每个表都只包含直接依赖于主键的属性，从而避免了传递依赖。

三、第三范式的作用

减少数据冗余：通过消除传递依赖，可以将冗余的数据分离到不同的表中，从而减少数据冗余。
提高数据一致性：当数据被拆分成更小的、更专业的表时，每个表都更容易维护和管理，从而提高了数据的一致性。
优化查询性能：虽然范式化设计可能会增加查询时的表连接操作，但在大多数情况下，这种设计可以更有效地利用数据库索引和查询优化技术，从而提高查询性能。

我们举个例子吧，如下：

学号	姓名	班级	班主任
001	张三	1班	李老师
002	李四	2班	高老师
003	王五	3班	张老师

我们看看这个表，我们是不是可以用学号来查找学生、班级、以及这位学号的班主任，那非主键中，是不是可以用班级来查找到班主任，那它是不是不属于第三范式

那我们该怎么设计这个表嘞？怎么设计才能符合第三范式嘞？

学生表

学号	姓名	班级
001	张三	1班
002	李四	2班
003	王五	3班

班级表

班级	班主任
1班	李老师
2班	高老师
3班	张老师

明确业务需求
- 首先，深入了解你的业务需求，包括数据之间的关系、数据的完整性要求以及数据的查询需求。
- 确定哪些数据是实体，哪些数据是属性，以及它们之间的关系。
确定主键
- 在每个表中确定一个唯一标识每条记录的主键。
- 主键可以是单个字段，也可以是多个字段的组合（复合主键）。
设计表结构
- 满足第一范式（1NF）：确保表中的每个字段都是原子的，即不可再分的。
- 满足第二范式（2NF）：在满足第一范式的基础上，确保表中的非主键字段完全依赖于主键，而不是依赖于主键的一部分。
- 满足第三范式（3NF）：在满足第二范式的基础上，进一步确保非主键字段不依赖于其他非主键字段（这些非主键字段又依赖于主键），即消除传递依赖。

具体步骤可能包括：

将具有多值属性的字段拆分成单独的表，并通过外键与主表关联。
将依赖于其他非主键字段的字段也拆分成单独的表，并通过外键与主表或其他相关表关联。
确保每个表中的字段都直接依赖于主键，没有冗余的字段。

验证设计
- 通过检查表的依赖关系，确保设计符合第三范式。
- 验证数据的完整性约束，如主键约束、外键约束、唯一性约束等。
- 考虑查询性能，必要时可以对表结构进行优化，如添加索引、分区等。
迭代改进
- 在实际应用中，根据数据的增长和查询需求的变化，可能需要调整表结构。
- 监控数据库性能，及时发现并解决潜在的问题。

总结
第三范式（3NF）是在满足第二范式（2NF）的基础上，进一步要求非主键列必须直接依赖于主键，不能存在传递依赖。也就是说，非主键列不能依赖于其他非主键列，而这些非主键列又依赖于主键。这是对字段冗余性的约束，旨在确保数据表中的字段没有冗余，每个字段都直接且仅依赖于主键。

反范式设计

反范式设计（Denormalization）是数据库设计中一种有意引入数据冗余的技术，旨在提高查询性能。与范式设计（Normalization）相反，反范式设计通过减少表之间的关系和连接操作，来简化查询过程。然而，这种设计也会带来一些潜在的问题，如数据不一致性和更新开销的增加。以下是对反范式设计的详细探讨：

一、反范式设计的定义
反范式设计是与范式设计（Normalization）相反的一种数据库设计方法。范式设计旨在通过分解表、消除冗余数据来提高数据的完整性和一致性，而反范式设计则通过增加冗余数据来减少表之间的关系和连接操作，从而提高查询性能。

二、反范式设计的优点

提高查询性能：
- 反范式设计通过减少表之间的连接操作，可以显著提高查询速度。
- 冗余的数据使得查询过程更加直接和高效，减少了查询的复杂度。
简化数据库设计：
- 反范式设计减少了表之间的关系，使得数据库结构更加简单和直观。
- 降低了数据库设计的复杂性，减少了开发和维护的工作量。
优化数据读取：
- 在高频读取、低频更新的场景中，反范式设计可以通过引入冗余数据来提高读取性能。
- 避免了在查询时需要多次关联多个表的情况，减少了查询的响应时间。

三、反范式设计的缺点

数据冗余：
- 反范式设计会导致数据在多个表中重复存储，增加了存储空间的占用。
- 冗余的数据可能导致数据不一致性，增加了数据管理的难度和复杂性。
更新开销增加：
- 当需要修改数据时，可能需要在多个地方进行更新，增加了更新的复杂性和开销。
- 可能导致更新异常，如遗漏更新或更新错误，影响数据的准确性和一致性。
数据一致性维护困难：
- 冗余的数据使得数据一致性的维护变得更加困难。
- 需要采取额外的措施来确保数据的一致性，如使用触发器、存储过程或应用逻辑等。

四、反范式设计的常见技术

合并表（Table Merging）：
- 将多个相关的表合并成一个表，以减少表之间的关系和连接操作。
- 例如，将订单表和产品信息表合并成一个表，以便快速查询订单中的产品信息。
增加冗余字段：
- 在表中增加冗余字段，以存储可能需要频繁访问的相关数据。
- 例如，在订单表中增加用户姓名字段，以避免在查询时需要连接用户表。
预计算与存储：
- 在数据插入或更新时，预先计算并存储可能需要的结果。
- 例如，在销售数据分析中，可以预先计算并存储每个月的销售总额和平均销售额等结果。

五、反范式设计的适用场景

数据仓库和报表生成：
- 在数据仓库和报表生成场景中，通常需要处理大量的历史数据和统计数据。
- 通过反范式设计，可以将常用的聚合数据冗余存储，加速复杂的报表生成过程。
实时大数据处理：
- 在实时大数据处理场景中，需要快速响应查询请求并处理大量数据。
- 反范式设计可以减少连接操作的复杂性，提高系统的响应速度和吞吐量。
复杂查询和分析需求：
- 如果业务需要进行复杂的查询和分析操作，而传统的规范化设计会导致繁琐的连接操作。
- 反范式设计可以简化查询操作，提高查询效率，使查询操作更加直观和简便。

六、注意事项

权衡利弊：
在使用反范式设计时，需要权衡其带来的性能提升和数据冗余、更新开销增加之间的利弊。
根据具体的业务需求和性能要求来判断是否采用反范式设计，以及何时采用反范式设计。
数据一致性维护：
- 需要采取额外的措施来确保数据的一致性，如使用触发器、存储过程或应用逻辑等。
- 定期检查和清理冗余数据，以避免不必要的存储空间浪费和性能下降。
定期评估：
- 随着业务需求和数据量的变化，需要定期评估反范式设计的效果。
- 根据实际情况进行调整和优化，以确保数据库的性能和数据的准确性。

简单的来说如果需要高频读取、低频更新的性能优化，可以考虑采用反范式设计来提高查询速度！！！

总结
数据库的反范式设计是一种在特定场景下可以提高查询性能的数据库设计方法。然而，它也会带来一些潜在的问题，如数据冗余和更新开销的增加。因此，在使用反范式设计时，需要仔细权衡其利弊，并采取额外的措施来确保数据的一致性和完整性。

三大范式与反范式设计有什么区别

数据库的反范式设计与三大范式（第一范式、第二范式和第三范式）在核心理念、设计目标、数据结构以及适用场景等方面存在显著的区别。

一、核心理念与设计目标

三大范式：
- 核心理念：通过分解表、消除冗余数据来提高数据的完整性和一致性。
- 设计目标：确保数据表中的每个字段都是原子的、不可再分的，并且每个非主键字段都完全依赖于主键，避免传递依赖关系。
反范式设计：
- 核心理念：有意地违反数据库范式规则，通过引入数据冗余来提高查询性能或简化查询操作。
- 设计目标：减少表之间的关系和连接操作，从而提高查询速度，优化数据读取性能。

二、数据结构

三大范式：
- 数据结构清晰、规范，每个表中的数据都是原子性的，并且每个非主键字段都直接依赖于主键。
- 避免了数据冗余和不必要的连接操作，但可能增加了查询时的表关联数量。
反范式设计：
- 数据结构相对复杂，通过在表中增加冗余字段或合并相关表来减少查询时的表关联数量。
- 提高了查询性能，但增加了数据冗余和更新时的复杂性。

三、适用场景

三大范式：
- 适用于需要高数据完整性和一致性的场景，如事务处理系统、在线交易系统等。
- 在这些场景中，数据的准确性和一致性至关重要，因此需要遵循三大范式来确保数据的规范化。
反范式设计：
- 适用于需要高频读取、低频更新的场景，如数据仓库、报表生成、实时大数据处理等。
- 在这些场景中，查询性能是首要考虑因素，因此可以通过引入冗余数据来提高查询速度。

四、优缺点对比

三大范式：
- 优点：数据结构清晰、规范，避免了数据冗余和不必要的连接操作，提高了数据的完整性和一致性。
- 缺点：可能增加了查询时的表关联数量，导致查询性能下降。
反范式设计：
- 优点：减少了表之间的关系和连接操作，提高了查询性能，优化了数据读取速度。
- 缺点：增加了数据冗余和更新时的复杂性，可能导致数据不一致性和额外的更新开销。

数据库的反范式设计与三大范式在核心理念、设计目标、数据结构以及适用场景等方面存在显著差异。在实际应用中，需要根据具体的业务需求和性能要求来选择合适的设计方法。如果需要高数据完整性和一致性，可以遵循三大范式来确保数据的规范化；如果需要高频读取、低频更新的性能优化，可以考虑采用反范式设计来提高查询速度。