DBMS 规范化：1NF、2NF、3NF 数据库示例

什么是数据库范式？

范式是一种数据库设计技术，它能减少数据冗余并消除诸如插入、更新和删除异常等不良特性。范式规则将较大的表划分为较小的表，并使用关系将它们链接起来。SQL中范式的作用是消除冗余（重复）数据，并确保数据以逻辑方式存储。

关系模型数据库的发明者Edgar Codd在引入第一范式时就提出了数据范式理论，并继续将理论扩展到第二范式和第三范式。后来他与Raymond F. Boyce合作，发展了 Boyce-Codd 范式理论。

DBMS 中的范式类型

以下是 SQL 中范式列表

1NF (第一范式): 确保数据库表组织得当，使得每一列都包含原子（不可分割）值，并且每一条记录都是唯一的。这消除了重复组，从而将数据结构化为表和列。
2NF (第二范式): 基于 1NF，我们需要从表中移除应用于多个行的冗余数据，并将它们放入单独的表中。它要求所有非键属性都完全依赖于主键。
3NF (第三范式): 扩展了 2NF，确保所有非键属性不仅完全依赖于主键，而且彼此独立。这消除了传递依赖。
BCNF (Boyce-Codd 范式): 3NF 的改进，解决了 3NF 未能处理的异常。它要求每个决定因素都是候选键，从而更严格地遵守范式规则。
4NF (第四范式): 处理多值依赖。它确保记录中没有关于实体的多个独立的多值事实。
5NF (第五范式): 也称为“投影-连接范式” (PJNF)，它涉及从较小、排列不同的数据片段重建信息。
6NF (第六范式): 理论上的，并未广泛实现。它通过进一步分解表来处理时间数据（处理随时间的变化），以消除所有非时间冗余。

MySQL 服务器中的数据范式理论仍在进一步发展。例如，甚至还有关于第 6 范式的讨论。但是，在大多数实际应用中，范式在第 3 范式达到最佳效果。下面说明了 SQL 理论中范式的演变——

数据库范式

带示例的数据库范式

可以通过案例研究轻松理解数据库范式示例。假设一个视频库维护着一个电影租赁数据库。在没有任何数据库范式的情况下，所有信息都存储在一个表中，如下所示。让我们通过范式示例及解决方案来理解范式数据库

这里您看到“租赁的电影”列有多个值。现在我们进入第一范式

第一范式 (1NF)

每个表单元格都应包含单个值。
每条记录都需要是唯一的。

上表转换为 1NF-

1NF 示例

在我们继续之前，让我们先了解一些事情——

SQL 中的 KEY 是什么

SQL 中的 KEY 是用于唯一标识表中记录的值。SQL KEY 是单个列或多个列的组合，用于唯一标识表中的行或元组。SQL KEY 用于标识重复信息，还有助于建立多个表之间关系。

注意：表中不用于唯一标识记录的列称为非键列。

什么是主键？

主键是用于唯一标识数据库记录的单个列值。

它具有以下属性

主键不能为 NULL
主键值必须是唯一的
主键值应很少更改
插入新记录时必须为主键指定一个值。

什么是复合键？

复合键是由多个列组成的主键，用于唯一标识记录

在我们的数据库中，有两个人同名 Robert Phil，但他们住在不同的地方。

因此，我们需要全名和地址来唯一标识记录。这就是复合键。

让我们进入第二范式 2NF

第二范式 (2NF)

规则 1- 满足 1NF
规则 2- 单列主键，它不函数性地依赖于任何候选键关系子集

很明显，除非我们划分上面的表，否则我们无法使我们的简单数据库进入第二范式。

我们将 1NF 表划分为两个表，即表 1 和表 2。表 1 包含成员信息。表 2 包含租赁电影的信息。

我们引入了一个名为 Membership_id 的新列，它是表 1 的主键。可以使用 Membership ID 在表 1 中唯一地标识记录。

数据库 – 外键

在表 2 中，Membership_ID 是外键

外键引用另一个表的主键！它有助于连接表

外键可以与其主键具有不同的名称
它确保一个表中的行在另一个表中也有对应的行
与主键不同，它们不必是唯一的。大多数情况下都不是。
外键可以为 NULL，尽管主键不能。

为什么需要外键？

假设一个新手在表 B 中插入一条记录，例如

您只能将值插入到外键中，这些值存在于父表中的唯一键中。这有助于实现参照完整性。

通过将表 2 中的 Membership_id 声明为表 1 中的 Membership_id 的外键，可以解决上述问题

现在，如果有人尝试在 Membership ID 字段中插入父表中不存在的值，就会显示错误！

什么是传递函数依赖？

传递函数依赖是指更改非键列可能会导致任何其他非键列发生更改

考虑表 1。更改非键列 Full Name 可能会更改 Salutation。

让我们进入 3NF

第三范式 (3NF)

规则 1- 满足 2NF
规则 2- 没有传递函数依赖

为了将我们的 2NF 表移至 3NF，我们需要再次划分我们的表。

3NF 示例

以下是 SQL 数据库中的 3NF 示例

我们再次划分了表，并创建了一个新表来存储称谓。

没有传递函数依赖，因此我们的表处于 3NF 状态。

在表 3 中，Salutation ID 是主键，在表 1 中，Salutation ID 是表 3 中主键的外键。

现在我们的例子达到了无法进一步分解以获得更高范式类型的 DBMS 范式水平。事实上，它已经处于更高的范式水平。通常需要在复杂的数据库中单独努力才能进入 DBMS 范式的下一个级别。然而，我们将在以下内容中简要讨论 DBMS 范式的下一级别。

Boyce-Codd 范式 (BCNF)

即使数据库处于第 3 范式，如果它有不止一个候选键，仍然会存在异常。

有时 BCNF 也被称为3.5 范式。

第四范式 (4NF)

如果没有任何数据库表实例包含描述相关实体的两个或多个独立的多值数据，那么它就处于第 4 范式。

第五范式 (5NF)

仅当表处于 4NF 并且在不丢失数据的情况下无法将其分解为任意数量的较小表时，该表才处于第 5 范式。

第六范式 (6NF) 提议

第六范式尚未标准化，但数据库专家已经讨论了很长时间。希望在不久的将来，我们将有一个清晰且标准化的第六范式定义……

范式的好处

提高数据一致性：范式确保每个数据只存储在一个地方，减少了数据不一致的可能性。更新数据时，只需在一个地方进行更新，即可确保一致性。
减少数据冗余：范式通过将数据划分为多个相关表来帮助消除重复数据。这可以节省存储空间，还可以提高数据库效率。
提高查询性能：范式化的数据库通常更容易查询。由于数据是逻辑组织的，因此可以优化查询以运行得更快。
使数据更有意义：范式涉及以有意义且直观的方式对数据进行分组。这可以使数据库更容易理解和使用，特别是对于那些没有设计数据库的人而言。
降低异常发生的可能性：异常是添加、更新或删除数据时可能出现的问题。范式可以通过确保数据以逻辑方式组织来降低这些异常发生的可能性。

范式的缺点

增加了复杂性：范式可能导致复杂的关联。大量带有外键的表可能难以管理，从而导致混淆。
灵活性降低：由于范式规则严格，在存储不符合这些规则的数据方面可能灵活性较低。
存储需求增加：虽然范式减少了冗余，但可能需要分配更多存储空间来容纳额外的表和索引。
性能开销：连接多个表在性能方面成本很高。数据范式化程度越高，所需的连接就越多，这会减慢数据检索速度。
丢失数据上下文：范式将数据分解到单独的表中，这可能导致业务上下文丢失。需要检查相关表才能理解数据的上下文。
需要专家知识：实施范式化数据库需要对数据、数据之间的关系以及范式规则有深入的了解。这需要专家知识，并且可能非常耗时。

SQL 范式就是这些了！！！

结论

数据库设计对于成功实现满足企业系统数据需求的数据库管理系统至关重要。
DBMS 中的范式是一个过程，有助于生成具有成本效益且具有更好安全模型的数据库系统。
函数依赖是规范化数据过程的重要组成部分。
大多数数据库系统都已在 DBMS 中规范化到第三范式。
主键唯一标识表中的记录，并且不能为 NULL。
外键有助于连接表并引用主键。