【数据库范式】实际案例分析

范式】实际案例分析"/>

【数据库范式】实际案例分析

前言
在日常业务研发过程中，我们常常需要与数据库表打交道。设计范式是数据表设计的基本原则，对于数据表的设计范式，我们特别容易忽略它的存在。很多时候，当数据库运行了一段时间之后，我们才发现数据表设计上有问题。然后重新调整数据表的结构，需要做数据迁移，还有可能影响程序处理的业务逻辑，甚至系统的正常服务运行。
其实在数据库表结构设计的初期时候，我们就需要重视数据表的设计。

什么是设计范式

关系型数据库模型的时候，需要对关系内部各个属性之间联系的合理化程度进行定义，这就有了不同等级的规范要求，这些规范要求被称为范式（NF）。
范式简单理解即为：一张数据表的设计结构需要满足的某种设计标准的级别。

目前关系型数据库一共有 6 种范式，按照范式级别，从低到高分别是：1NF（第一范式）、2NF（第二范式）、3NF（第三范式）、BCNF（巴斯 - 科德范式）、4NF（第四范式）和 5NF（第五范式，又叫做完美范式）。

数据库的范式设计越高阶，冗余度就越低，同时高阶的范式一定符合低阶范式的要求，比如满足 2NF 的一定满足 1NF，满足 3NF 的一定满足 2NF，依次类推。

这么多的范式级别，那是不是都要符合呢？

一般来说只要符合前 3 个范式，就足够了但也不绝对，有时候为了提高某些查询性能，我们还需要破坏范式规则，也就是反规范化。

第一范式

数据库表中的所有字段都是原子性的，不可再分。

案例一：用户表中的联系方式

上面的：联系方式是一个复合属性，这是在数据库中无法创建出来的。可以进行拆分。

这样拆分后，每一列都无法再分了，满足了第一范式的要求。通常来讲，第一范式的表都是标准的【二维表】。
下面我们讲讲第二范式，它是在第一范式的基础上定义的。

第二范式

第二范式：表中必须存在业务主键，并且非主键的所有列 全部依赖于 业务主键。
理解第二范式可以从以下两个关键点入手：

• 业务主键：每个表必须有一个业务主键，它是用来唯一标识表中的每一行数据的。通过业务主键，我们可以定位到唯一的一行数据。例如，在一个学生表中，学生的学号可以作为业务主键。

• 非主键依赖：除了业务主键之外的所有列都必须完全依赖于业务主键。这意味着，表中的每个非主键列的值都必须由业务主键来决定，而不能只依赖于其他非主键列。这样可以确保数据的一致性和完整性。例如，在学生表中，学生的姓名、年龄、性别等信息都应该完全依赖于学生的学号。

如果表中使用的是复合主键，即由多个列组成的主键，那么除了这些列之外的所有列都必须完全依赖于这些复合主键的所有列。这样可以确保表中的数据不会出现冗余和不一致的情况。

订单表为例来详细说明

让我们以一个订单表为例来详细说明第二范式的要求。

假设我们有一个订单表，其中包含以下列：订单号（OrderID）、产品ID（ProductID）、产品名称（ProductName）、客户ID（CustomerID）、客户姓名（CustomerName）、订单日期（OrderDate）、订单金额（OrderAmount）。

在这个例子中，我们可以将订单号和产品ID作为复合主键，因为一个订单可以包含多个产品，而每个产品在同一个订单中的位置是唯一的。

根据第二范式的要求，除了订单号和产品ID之外的所有列都必须完全依赖于这两个复合主键的所有列。

在这个例子中，订单号和产品ID决定了订单中的每个产品的唯一性。因此，订单表中的其他列，如产品名称、客户ID、客户姓名、订单日期和订单金额，都必须完全依赖于订单号和产品ID。

换句话说，如果我们知道订单号和产品ID，我们就能确定产品名称、客户ID、客户姓名、订单日期和订单金额。但是，如果我们只知道其中一部分信息，比如只知道订单号，那么我们无法确定产品名称或其他列的值。

这样设计的好处是，避免了数据冗余和不一致性。如果某个非主键列只依赖于复合主键的一部分，那么在更新数据时可能会导致数据不一致。而且，如果数据冗余，会增加数据存储的开销和维护的复杂性。

因此，根据第二范式的要求，我们应该将订单表拆分为两个表：一个是订单表，包含订单号和产品ID作为复合主键；另一个是产品表，包含产品ID和其他与产品相关的信息。这样可以确保数据的一致性和完整性，并提高数据库的性能和可维护性。

第三范式

什么是第三范式

表中的非主键列之间不能相互依赖

课程案例

理解第三范式可以从以下几个关键点入手：

• 主键：每个表必须有一个主键，它是用来唯一标识表中的每一行数据的。主键可以由一个或多个列组成。在上述例子中，【主标题】可以作为主键。

• 非主键列之间的依赖：根据第三范式的要求，非主键列之间不能相互依赖。这意味着，表中的每个非主键列的值都应该独立于其他非主键列的值。在上述例子中，【讲师职位】依赖于【讲师名称】,毕竟先有讲师，才能给讲师对应的职位，他们之间有了相互依赖。这违反了第三范式的要求。

解决方案

要解决这个问题，就是将有冲突的列独立出去，比如这里独立为一个( 讲师表 )