数据库范式

3.1 数据库规范化

范式是关系数据模型中关系的一种属性，它在冗余方面对其进行了表征，可能导致采样或更改数据的逻辑错误结果。范式被定义为关系（数据库中的表）必须满足的一组要求。

将数据库关系转换为符合规范形式的形式的过程称为规范化。规范化旨在使数据库的结构成为提供最小逻辑冗余的形式，而不是为了降低或提高性能，或者减少或增加数据库的物理量。

规范化的最终目标是减少存储在数据库中的信息的潜在不一致性。归一化过程的一般目的如下：

• 排除某些类型的冗余；
• 修复一些更新异常；
• 开发一个足够“高质量”地表示现实世界的数据库项目，直观且可以作为后续扩展的良好基础；
• 简化应用必要完整性约束的程序。

冗余通常通过分解关系来消除，分解关系的方式是在每个关系中只存储主要事实（即，不是从其他存储的事实派生的事实）。

虽然规范化思想对数据库设计非常有用，但它们绝不是提高数据库设计质量的通用或详尽手段。这是因为数据库结构中可能存在的错误和缺陷种类太多，无法通过规范化消除。

尽管有这些考虑，归一化理论是关系理论和实践的一项非常有价值的成就，因为它为数据库项目的质量提供了科学上严格和合理的标准，并提供了提高这种质量的形式化方法。这使得归一化理论从其他数据模型中提供的纯经验设计方法中脱颖而出。此外，可以说，在整个信息技术领域中，在形式严谨性方面，几乎没有一种方法可以与关系数据库规范化理论相媲美，用于评估和改进设计方案。

规范化有时会受到批评，理由是“这只是常识”，任何有能力的专业人员都会“自然地”设计一个完全规范化的数据库，而不必应用依赖理论。

然而，正如Christopher Date教授所指出的，归一化恰恰是指导成熟设计师心目中的常识性原则，即归一化原则是形式化的常识。同时，识别和形式化常识原则是一项非常艰巨的任务，成功解决它是一项重大成就。

3.2 第一范式

第一范式（1NF）是关系数据模型中关系的基本范式。

当且仅当在该变量的任何有效值中，每个关系元组的每个属性都恰好包含一个值时，关系变量才处于第一范式。

在关系模型中，根据关系概念的定义，关系始终处于第一范式。

至于各种表，它们可能不是关系的正确表示，因此可能不在 1NF 中。根据 Christopher Date 对这种情况的定义，当且仅当它是某种关系的直接和真实表示时，表才被规范化（等效地，处于第一范式）。更具体地说，有问题的表必须满足以下五个条件：

• 行没有从上到下的顺序（换句话说，行的顺序不传达任何信息）。
• 列没有从左到右的顺序（换句话说，列的顺序不包含任何信息）。
• 没有重复的行。
• 一行和一列的每个交叉点只包含来自相应域的一个值（没有其他任何值）。
• 所有列都是“常规”的。

表的所​​有列的“规律性”意味着表中没有“隐藏”的组件只能在调用某些特殊运算符而不是引用常规列名时访问，或者导致行的副作用或调用标准运算符时的表。

原始的非规范化（即不是某种关系的正确表示）表：

简化为 1NF 的表格，这是某些关系的正确表示：

3.3 第二范式

当且仅当关系变量处于第一范式并且每个非键属性都不可约地依赖于（每个）其候选键时，关系变量才处于第二范式。

不可约性意味着潜在的键不包含更小的属性子集，从中也可以派生出这种功能依赖性。对于不可简化的功能依赖，通常使用“完全功能依赖”的等价概念。

如果候选键很简单，即它由单个属性组成，那么对它的任何功能依赖都是不可减少的（完全的）。如果候选键是复合键，则根据第二范式的定义，关系中一定没有非键属性依赖于复合候选键的一部分。

将关系转换为第二范式的示例

让一对属性 {Company branch, Position} 形成以下关系中的主键：

假设薪水取决于部门和职位，而计算机的可用性仅取决于职位。

存在函数依赖 Position -> Having a computer，其中左边（行列式）只是主键的一部分，违反了第二范式的条件。

要减少到 2NF，原始关系应分解为两个关系：

3.4 第三范式（3NF）

当且仅当以下条件为真时，关系变量 R 在 3NF 中：

• R是第二范式。
• 没有非关键属性R不依赖于候选键的传递函数R.

定义说明：

关系 R 的非键属性是不属于 R 的任何候选键的属性。

属性集 Z 对属性集 X（写作 X → Z，发音为“x 决定 z”）的函数依赖是传递的，如果存在这样的一组属性 Y 使得 X → Y 和 Y → Z。在这个在这种情况下，集合 X、Y 和 Z 都不是另一个集合的子集，即函数依赖 X → Z、X → Y 和 Y → Z 不是微不足道的，并且也不存在函数依赖 Y → X。

3NF 的定义等同于 Codd 的定义，但措辞不同，由 Carlo Zaniolo 在 1982 年给出。根据它，一个关系变量在 3NF 中当且仅当它的每个函数依赖 X → A 至少满足以下条件之一：

• X 包含 A（即 X → A 是平凡的函数依赖）
• X - 超级键
• A 是键属性（即，A 是候选键的一部分）。

Zaniolo 的定义清楚地定义了 3NF 和更严格的 Boyce-Codd Normal Form (BCNF) 之间的区别：BCNF 排除了第三个条件（“A 是关键属性”）。

Bill Kent 给出了 Codd 的 3NF 定义的一个令人难忘的传统描述性摘要：每个非键属性“应该提供关于键、完整键的信息，并且除了键之外别无其他”。

依赖非键属性“全键”的条件保证了关系是第二范式；而他们“只依赖钥匙”的条件是他们处于第三范式。

Chris Date 将 Kent 的总结称为 3NF 的一个“直观吸引人的特征”，并观察到，稍作修改，它也可以作为更严格的 Boyce-Codd 范式的定义：“每个属性必须提供关于密钥的信息，一个完整的密钥，除了密钥之外什么都没有。

Kent 版本的 3NF 定义不如 Data 公式的 Boyce-Codd 范式版本严格，因为前者仅声明非键属性依赖于键。

主要属性（是键或它们的一部分）根本不需要在功能上依赖；他们每个人都通过提供密钥本身或其中的一部分来提供有关密钥的信息。此处应注意，此规则仅对非键属性有效，因为将其应用于所有属性将完全禁用所有复杂的替代键，因为此类键的每个元素都将违反“完整键”条件。

以关系变量 R1 为例：

每个员工只属于一个部门；每个部门都有一部电话。Employee 属性是主键。员工没有私人电话，员工的电话号码完全取决于部门。

在示例中，存在以下功能依赖项：Employee → Department、Department → Phone、Employee → Phone。

关系变量 R1 处于第二范式，因为每个属性都对潜在键 Employee 具有不可简化的函数依赖性。

关系 Employee → Phone 是可传递的，因此该关系不符合第三范式。

拆分 R1 会产生两个符合 3NF 的关系变量：

如果需要，初始关系 R1 很容易作为连接关系 R2 和 R3 的操作的结果获得。