数据规范化

规范化数据库的外观以及为什么表结构很重要。

数据规范化是在数据库中构建信息以减少冗余并使该数据库更高效的过程。将规范化视为一种确保数据库中的每个字段和表都按逻辑组织的方式，以便您可以避免数据异常插入、更新或删除记录时。此过程根据具体情况进行规则这决定了表格应如何组织。
规范化是更大的数据清理和标准化过程的一部分，该过程还涉及确认数据是否准确、完整且不包含重复记录，以及确保选择了适当的数据数据类型用于您的字段。如果从非规范化表开始，规范化过程将涉及创建其他较小的表，这些表可以是加入通过外键.也许您已经感到沮丧，因为在单个值更改后，您必须在数据库中的多个位置更新相同的信息，或者发现在删除记录时丢失了有价值的数据。在这两种情况下，规范化表都会有所帮助。
我们将在本课中介绍的原则适用于关系数据库管理系统（RDBMS）。如果您使用的是 NoSQL 或基于文档的数据库与MongoDB一样，以下信息将不适用。

简化和减少存储：规范化数据的好处

规范化就是要提高数据效率，以便您的团队可以找到并使用他们需要的信息。一旦您对数据库的工作原理有所了解，这些好处和规则可能看起来像是常识，但从长远来看，了解数据库中每个表和字段的显式用途是值得的。规范化数据的好处包括：

• 简化事务查询。使用规范化数据时，对客户地址的查询只需在存储这些地址的单个字段中查找。如果您多次将客户地址存储在数据库中的不同位置，甚至在同一字段中保留多个地址，则该查询将需要更长的时间来执行。
• 减小数据库的大小。如果您在数据库中的多个位置重复客户数据，则意味着您已经腾出空间来多次存储该信息。如果您的数据库只包含几个表，这可能不是一个主要问题，但是如果您正在处理更大的规模，则磁盘空间可能非常宝贵。减少重复信息意味着降低存储成本，无论您是运行本地服务器还是依赖云托管的数据库。
• 使数据库维护更轻松。想想在数据库中多次存储的同一客户数据。每次客户更改其地址时，都需要在字段的每个实例中更新地址，这为错误留下了很大的余地。如果数据已规范化，则只有一个字段，该字段将联接到其他相关表，如 。Customer Address Customer Address Orders

  数据异常

  数据异常是信息在数据库中的存储方式不一致。每当在更新、添加或删除记录时出现问题时，数据库结构的这些缺陷就会变得明显。幸运的是，遵守规范化规则可以首先防止这些异常的发生。

  更新异常

  更新异常源于数据冗余。例如，假设您的数据库将客户地址信息存储在多个表中的字段中。客户更改其地址可能会导致仅更新其中一个字段以包含新信息，从而留下不一致的数据。

  插入异常

  如果某些字段包含数据（可能尚不存在的数据），则无法创建记录，则会发生插入异常。例如，非规范化数据库的结构可能使客户帐户无法创建，除非该客户已下订单。规范化该数据库将通过创建单独的表来解决此问题，并且没有规则禁止空值。Orders Customers

  删除异常

  意外的信息丢失是删除异常的结果。假设数据库中的一个表包含有关大学课程和参加这些课程的学生的信息。如果一门课程由于入学率低而被取消，您可能会通过删除该课程记录而无意中丢失有价值的学生信息。与插入异常一样，将数据分解为多个特定表可以防止此问题。

  规范化规则

  这些规范化数据的规则或属性（每个规则或属性都称为一种形式）于 20 世纪 70 年代初首次引入，它们相互依存。这意味着，如果不首先遵循第一范式，您的数据就不可能实现第二范式。虽然除了下面列出的三种形式之外，还有几种其他正常形式，但对于大多数用例而言，前三种形式就足够了。
  正如我们在数据库简介里介绍的，数据库中的表应包含实体键，也称为主键。此字段根据唯一 ID 区分表中的每一行，在联接表时非常有用。在我们进入第一个范式之前，您的表需要有一个实体键字段。

  第一范式 （1NF）

  第一个范式 （1NF） 规定表中的每个字段只能存储一个值，并且表不应包含多个存储类似信息的字段，如标题为 Address1 和 Address2 的列。
  下面是一个表的示例，我们将根据第一个范式对其进行规范化。此表包括有关大学课程以及教授这些课程的人员的信息。

  教授表

  | 教授编号 | 教授姓名 | 课程名称 | | —- | —- | —- | | P001 | 吉恩·沃森 | 哲学导论;伦理学 | | P002型 | 梅丽莎·金 | 量子力学 | | P003型 | 埃罗尔·泰森 | 宏观经济 学 | | P004型 | 玛丽·雅各布森 | 图画小说 |

我们注意到，虽然我们的领域是不同的，但一位教授正在教授两门课程，并且这些信息目前存储在单个单元格中。如果我们根据1NF规范化此表，则需要将数据分解为多个表：

规范化教授表

标准化课程表

我们将这些数据分成两个表，因为我们的表与我们的表有一对多的关系，因为一个教授可以教授许多课程。此新表结构满足第一范式，并通过外键 field 连接两个表。Professor Course Professor ID

第二范式 （2NF）

第二种正常形式是关于减少冗余并确保每个字段都描述有关实体键标识的内容的内容。要满足 2NF 要求，表中所有不是实体键的字段都必须完全依赖于表的实体键，该实体键可能是由两个字段组成的复合键。让我们看一个新示例 — 一个包含员工生日信息的表。

员工生日表

此表符合 1NF，因为每列都是不同的，并且每个单元格中只包含一个值。但是，此表具有复合键：+ 组合组成表的实体键。此表在当前状态下不符合 2NF，因为该字段仅部分依赖于复合键，因为员工的部门不依赖于其生日，而仅依赖于其员工 ID。为了解决这个问题，我们将此信息分解为两个表：Employee ID Birthday Department

规范化员工生日表

规范化员工部门表：

第三范式 （3NF）

如果表（除了满足 2NF 之外）不包含任何传递依赖关系，则表满足第三范式，这意味着一列依赖于实体键以外的另一个字段。如果您的表包含从属信息，并且您希望根据 3NF 进行规范化，则任何从属信息都必须依赖于实体键，而不是任何非键字段。

订单表

此表不是第三范式形式，因为该字段依赖于 ，而 不是此表的实体键。我们目前的结构可能导致不必要的信息丢失;如果客户 C032 退回了他们的订单，而我们需要删除此记录，我们将无意中丢失他们的邮政编码信息。如果客户 C004 曾经移动并且他们的邮政编码发生了变化，我们还必须在两个地方更新它，因为他们已经下了多个订单。为了将这张表放入3NF中 - 你猜对了 - 我们将把它分成两个表。Customer zip code Customer ID

规范化订单表

规范化客户表

规范化的缺点：何时非规范化

一旦达到更高级别的规范化，数据库可能会以较慢的速度执行某些分析查询，尤其是那些需要获取大量数据的查询。由于规范化数据要求数据库利用多个表来执行查询，因此这可能需要更长的时间，尤其是在数据库复杂性增加时。权衡是规范化数据占用的空间更少。