数据库规范化

• 数据库规范化以结构化且一致的方式组织数据，消除冗余并确保关系数据库内的数据完整性。它使数据库更易于管理、查询和维护，减少错误。

• 通过遵循规范化规则，您可以设计更易于维护且不易出错的数据库。

在深入规范化之前，我们想了解关系数据库的基础知识。

• 关系数据库是一种将数据存储在表中的数据库，表的结构为行和列。 表格 - 相关数据条目的集合 行 - 记录，每一行代表一条数据 列 - 字段，每一列代表数据的一个特定属性。

主键 - 表中每一行的唯一标识符。确保每条记录都可以唯一标识。
外键 - 一个表中的字段链接到另一个表的主键，在两个表之间创建关系

我们提到标准化是为了消除冗余和不一致的依赖。那是什么？

冗余数据意味着将相同的数据存储在多个地方，这会浪费磁盘空间并造成维护问题。如果数据发生任何变化，我们必须在所有地方更新它。

不一致的依赖关系 当数据库中的数据以不可预测或不正确的方式依赖于其他数据时，就会发生。这可能会导致错误并使数据库不可靠。

• 规范形式 - 数据库规范化中的每条规则。如果数据库遵循规范化的第一条规则，则它处于“第一范式”(1NF)。如果它遵循前三个规则，则它处于“第三范式”（3NF）。

将范式视为流程中的检查点/规则，类似于驾驶考试的学习阶段、停车阶段和路考阶段。

第一范式 (1NF)

• 消除各个表中的重复组。

• 为每组相关数据创建一个单独的表。

为了标准化这些数据，我们为学生及其课程创建单独的表：

• 用主键标识每组相关数据。

第二范式 (2NF)

• 删除部分依赖 - 每个非键列必须依赖于整个主键，而不仅仅是它的一部分。

1NF仅消除重复组，而不是冗余。这就是为什么有2NF。

如果表满足以下条件，则称其为 2NF：
已经是 1NF
没有部分依赖。也就是说，所有非键属性完全依赖于主键。

第三范式（3NF）

• 通过确保非键属性仅依赖于主键来删除传递依赖关系。

• 现在我们需要理解传递依赖，这是理解3NF的关键。

当属性（列）依赖于另一个非键属性而不是直接依赖于主键时，就会发生传递依赖。

3NF 需要

1. 桌子已经是 2 NF
2. 没有传递依赖。这意味着非键 属性不应依赖于其他非关键属性。

这是 3NF 的最终结构：
没有部分依赖（因为所有属性都完全依赖于各自表中的整个主键）。
没有传递依赖（因为没有非键属性依赖于其他非键属性）。

基本键范式 (EKNF)

• EKNF 是 3NF 的更严格形式，可确保所有函数依赖关系都是基本的，这意味着它们简单明了，没有任何复杂的依赖关系。

3NF：确保没有传递依赖。
EKNF：通过确保所有函数依赖关系都是基本的来进一步完善 3NF，解决 3NF 可能无法处理的更复杂的依赖关系。

博伊斯-科德范式（BCNF）

• 如果满足以下条件，则表属于 BCNF：

  1. 它位于 3NF。
  2. 对于每个函数依赖（ A —> B ），A 必须是候选键（超级键）。

• 超级键：一组一个或多个列，可以唯一标识表中的一行。
  功能依赖：一个属性唯一确定另一个属性的关系。

第四范式（4NF）

• BCNF 之后的下一级范式。

• 其他范式涉及函数依赖关系，4NF 涉及更通用的依赖类型，称为多值依赖关系。

• 多值依赖 - 当一个属性独立于其他属性确定另一个属性的多个值时发生。

第五范式（5NF）

• 也称为项目加入范式（PJNF），是标准化的最高级别。如果表已经处于 4NF 状态并且无法在不丢失数据完整性的情况下分解为更小的表，则该表处于 5NF 状态。这意味着表中的每个重要连接依赖项都由候选键隐含。

• 如果我们将这张表分解为更小的表以消除冗余，我们必须确保我们仍然可以重建原始表而不会丢失任何信息。在 5NF 中，这种分解是以不丢失任何信息的方式完成的，并且保留所有连接依赖性。举例说明

反规范化

• 表可以进行非规范化以提高性能。

• 标准化增加了表和关系的数量。

• 跨关系访问多个表比访问单个表需要更多处理。

以上是数据库规范化的详细内容。更多信息请关注PHP中文网其他相关文章！