【数据库原理】（17）关系模型的规范化

在关系数据库设计中，规范化是一个关键的过程，用于减少数据冗余并避免更新异常。规范化是通过应用一系列称为“范式”的标准来完成的，它们定义了关系模式的不同级别的规范化要求。

关系数据库中的关系是要满足一定规范化要求的,对于不同的规范化程度,可以用“范式”来衡量,记为 xNF。范式是表示关系模式的级别,是衡量关系模式规范化程度的标准，达到范式的关系才是规范化的。满足最低要求的为第一范式,简称 1NF。在第一范式的基础上,进一步满足一些要求的为第二范式,简称 2NF,…,依此类推,各种范式之间的联系是

$5NF?4NF?BCNF?3NF?2NF?1NF$

规范化的目的：

• 减少数据冗余: 避免同一数据在数据库中多次出现，减少存储空间的浪费。

• 避免更新异常: 更新、删除或插入操作时防止数据不一致性。

• 提高查询效率: 通过适当的分解，可以提高查询的效率和灵活性。

规范化过程

低一级范式的关系模式通过分解可以转换为若干个高一级范式的关系模式集合。这个过程称为规范化，其目标通常是达到第三范式或BCNF，以确保数据模型的有效性和高效性。

选择适当的范式

虽然更高级别的范式提供了更好的规范化，但过度规范化可能导致过多的表联结操作，影响数据库性能。因此，根据实际情况和应用需求选择合适的规范化级别至关重要。

一.第一范式

第一范式（1NF）是关系数据库模式设计中的最基本要求。它确保了数据库的基础结构是规范的，并避免了复杂的数据组织形式。

定义

• 第一范式（1NF） 规定了关系模式的所有属性都必须是不可分的基本数据项，即每一列的值都是原子的，不可再分。

例子分析

关系模式 R(SNO, CNO, SDEPT, SLOC, CNAME, GRADE) 存在以下问题：

1. 数据冗余:

   • 如有1000个学生在相同系，系的住址（SLOC）会重复1000次，导致大量冗余。
   • 同样，如果一门课程被多个学生选择，课程名称（CNAME）也会重复，增加数据冗余。

2. 插入异常:

   • 如果一个学生还未选课，即没有课程号（CNO），那么这个学生的信息无法被插入关系R中。
   • 这是因为在1NF中，每个元组必须有一个完整的主键值，而没有课程号就不能构成完整的主键。

3. 删除异常:

   • 如果一个学生退选了所有课程，其课程号将变为空，导致该学生的整个记录被删除。
   • 这样，关于该学生的其他信息（如姓名、系别等）也将丢失，造成了删除异常。

4. 修改异常:

   • 如果一个学生更换系别，需要更新所有相关记录的系别和住址信息。
   • 如该学生选修了多门课程，需要在多个记录中重复修改，增加了维护的复杂度。

第一范式的实现

为了使关系模式R满足第一范式，应进行如下操作：

1. 消除非原子属性:

   • 确保每个属性都包含最小的数据单位，不可再分。

2. 分解关系模式:

   • 分解R为几个关系模式，如R1、R2和R3，使每个新关系模式都符合1NF。
   • 例如，将学生基本信息、课程信息和选课信息分别放入不同的表中。

3. 减少冗余:

   • 通过分解和重新组织数据，减少冗余数据的存储。

二.第二范式

第二范式（2NF）在第一范式（1NF）的基础上，进一步减少数据冗余和更新异常。

定义

• 第二范式（2NF） 要求关系模式R不仅满足1NF，而且所有非主属性完全函数依赖于任何候选键。

重要概念

• 完全函数依赖：如果属性A对候选键K的函数依赖是完全的，意味着A不能仅通过K的一部分属性就能确定。

例子分析

• 原关系模式R：(SNO, CNO, SDEPT, SLOC, CNAME, GRADE)

  • 问题：非主属性SDEPT、SLOC、CNAME对码(SNO, CNO)是部分函数依赖。

• 分解为2NF关系模式：

  • SC(SNO, CNO, GRADE)
  • C(CNO, CNAME)
  • S(SNO, SDEPT, SLOC)
  • 这样的分解解决了非完全函数依赖问题。

其他例子

• 库存关系模式：库存(零件号, 仓库号, 零件数量)

  • 分析：唯一非平凡函数依赖是 (零件号, 仓库号) -> 零件数量。这是2NF，因为非主属性零件数量完全函数依赖于码。

• 学生关系模式：学生(学号, 姓名, 系名, 系主任, 课程号, 成绩)

  • 问题：姓名、系名、系主任是部分函数依赖于码(学号, 课程号)。
  • 分解：
    • 学生记录(学号, 姓名, 系, 系主任)
    • 成绩(学号, 课程, 成绩)
  • 这种分解使得每个关系都是2NF。

2NF分解的方法

• 通过投影分解，将部分函数依赖的属性从原关系中分离出来，形成新的关系。
• 分解得到的新关系应保持原有的函数依赖关系。

重要性

• 第二范式的目标是减少数据冗余和更新异常。
• 它通过确保非主属性依赖于整个候选键来实现。
• 2NF关系模式有助于简化数据库的维护工作，提高数据的准确性和完整性。

通过实现2NF，数据库设计可以避免大量的数据重复，减少插入、删除和更新操作中的问题，使数据库管理更为高效。在实际应用中，通常要求数据库至少达到2NF。

三.第三范式

第三范式（3NF）进一步减少数据冗余和更新异常，是数据库设计中非常重要的一个规范化阶段。

定义

• 第三范式（3NF） 要求关系模式R不仅满足2NF，而且每个非主属性既不部分函数依赖于码也不传递函数依赖于码。

重要概念

• 传递函数依赖：如果一个非主属性依赖于另一个非主属性，且这个非主属性依赖于码，那么存在传递函数依赖。

例子分析

• 原关系模式S：(SNO, SDEPT, SLOC)

  • 函数依赖：SNO->SDEPT, SDEPT->SLOC, SNO->SLOC
  • 问题：存在非主属性SLOC对码SNO的传递函数依赖。

• 分解为3NF关系模式：

  • SD(SNO, SDEPT)
  • DL(SDEPT, SLOC)
  • 这种分解解决了传递函数依赖问题。

分解的过程

• 目的：消除非主属性对码的传递函数依赖。
• 方法：通过将原关系模式进一步分解，把具有传递函数依赖的属性分离到不同的关系模式中。

解决问题

• 减少数据冗余：非主属性不再重复存储。
• 避免插入异常：每个实体的固有信息可以独立存储，无需依赖其他实体。
• 避免删除异常：删除一个实体的信息不会导致与其相关的其他信息丢失。
• 简化修改操作：不再需要跨多个记录的复杂修改。

3NF的重要性

• 3NF关系模式使得数据结构更加合理，更容易维护。
• 在大多数实际应用中，3NF是一个理想的目标，它足以消除大部分的数据冗余和更新异常。
• 达到3NF的数据库具有更高的查询效率和数据一致性。

总的来说，3NF是关系数据库规范化设计中的一个重要里程碑，它通过确保数据的独立性和减少冗余，提高了数据库的整体质量和效率。在数据库设计实践中，通常建议至少将数据库规范化到第三范式。

四.BC 范式

BCNF（Boyce-Codd Normal Form）是第三范式（3NF）的加强版，用于解决3NF中仍然存在的某些问题。

定义

• BCNF：若关系模式R∈1NF，并且对于R的每个函数依赖 X->Y（$Y?X$），X都包含码，则R∈BCNF。

关键概念

• 函数依赖：X->Y表示Y的值依赖于X的值。
• 码：唯一标识关系中元组的属性集。

例子分析

• 原关系模式ORDER：(C, F, P)

  • 函数依赖：(C, P)->F, (C, F)->P, F->P
  • 问题：存在主属性P对码的部分函数依赖。

• 分解为BCNF关系模式：

  • CF(C, F)
  • PF(F, P)
  • 分解消除了主属性对码的部分函数依赖。

解决的问题

• 数据冗余：减少因为主属性对码的部分依赖而造成的数据冗余。
• 更新异常：简化了因为冗余数据而导致的复杂更新操作。
• 插入异常：允许独立地插入实体信息。
• 删除异常：避免因删除一个实体信息而导致与其相关的其他重要信息丢失。

与3NF的区别

• BCNF是3NF的特例，但3NF不一定是BCNF。
• 3NF允许非主属性对码的传递依赖，而BCNF则不允许。

重要性

• BCNF更严格地处理了函数依赖，使得关系模式的结构更加合理，减少数据冗余和更新异常。
• 达到BCNF的关系模式在许多情况下能提供更好的性能和数据完整性。

实际应用中的考虑

• 有时为了实用性和查询效率，某些关系模式可能不需要完全规范化到BCNF。
• BCNF的设计可能会导致过度分解，影响查询性能。

总的来说，BCNF是关系数据库规范化设计中更高级的范式，它通过消除主属性对码的部分函数依赖，使数据库设计在结构上更加合理和稳健。在数据库设计中，通常需要权衡规范化的程度和数据库的性能，根据具体情况决定是否要完全遵循BCNF。

五.多值依赖和第四范式

1. 多值依赖（Multivalued Dependency, MVD）

• 定义：在关系模式R(U)中，若存在属性子集X、Y和Z（其中Z = U - X - Y），那么多值依赖X->->Y成立当且仅当R中的任一关系r里，X值对应的Y值组合仅依赖于X值，与Z值无关。
• 特点：多值依赖关注的是属性间值的独立关系，而非函数依赖。

2. 第四范式（4NF）

• 定义：若关系模式R(U,F)属于1NF，并且对于R的每个非平凡多值依赖X->->Y（$Y?X$），X都包含码，则R(U,F)属于4NF。
• 目的：4NF的设计旨在解决非平凡且非函数依赖的多值依赖带来的问题，如数据冗余和更新异常。

例子分析

• 关系模式STORE(W,S,C)：

  • 存在的问题：数据冗余、更新复杂。
  • 多值依赖：W->->S和W->->C都是非平凡的多值依赖。
  • 不满足4NF：因为W不是码，而全码是(W,S,C)。

• 分解为4NF关系模式：

  • WS(W,S)和WC(W,C)
  • 分解消除了非平凡且非函数依赖的多值依赖。

实际应用中的考虑

• 平衡规范化与性能：过度的规范化可能导致过多的关系分解，增加了查询时的连接操作，可能影响性能。
• 实际需求：在实际应用中，可能需要根据具体情况来决定是否完全遵循4NF。

结论

• 4NF是关系数据库规范化的更高级别，主要用于处理多值依赖引起的问题。
• 达到4NF的关系模式在许多情况下能提供更好的数据一致性和减少冗余。
• 设计时需考虑规范化和性能之间的平衡，特别是在数据量大和查询复杂的情况下。

六.连接依赖和第五范式

1. 连接依赖（Join Dependency）

• 定义：设有关系模式R(U)和其属性子集的序列$X_1,X_2,...,X_n$（满足$X_1\cup X_2\cup ...\cup X_n=U$）。若对于R的任一实例r，总有$r=r(X_1)?r(X_2)?...?r(X_n)$，则称R具有连接依赖，记作$?(X_1,X_2,...,X_n)$。

• 类型：

  • 平凡连接依赖：当每个$X_i$等于U时，即$?i,X_i=U$。
  • 非平凡连接依赖：当至少一个$X_i$不等于U时。

• 性质：多值依赖可以视为连接依赖的特例。一般的连接依赖不易直接从数据语义中推断，通常在数据库设计中较少考虑。

2. 第五范式（5NF）

• 定义：若关系模式R(U,F)属于4NF，且除了由超键形成的连接依赖外，没有其他连接依赖，则R(U,F)属于5NF。即，R中的每个连接依赖都由R的候选码隐含。
• 关键点：在5NF中，连接属性必须是R的候选码。

例子分析

• 非5NF的例子：

  • 关系模式“提供(供应商号,零件号,工程号)”：
    • 唯一码为全码{供应商号,零件号,工程号}。
    • 可分解为“供应(供应商号,零件号)”，“需要(工程号,零件号)”，“承接(供应商号,工程号)”，无候选码，因此不属于5NF。

• 5NF的例子：

  • 关系模式“学生(学号,姓名,性别,年龄,来自地区,入学成绩)”：
    • 唯一码为{学号}。
    • 所有连接依赖的连接属性都是学号，故属于5NF。

结论

• 5NF的重要性：在5NF中，通过对关系模式的投影分解，可以无损地重构原关系模式，消除非必要的连接依赖，从而减少数据冗余和更新异常。
• 设计考虑：达到5NF的关系模式相对于投影和连接操作来说是最高的规范化程度，但在实际设计中，需要平衡规范化程度和性能，特别是在数据量大和查询复杂的场景下。

七.规范化过程小结

规范化的概念

• 定义：规范化是一个将低级别范式的关系模式转换为高级别范式的关系模式集合的过程。
• 目的：主要解决关系模式中的插入、删除、修改异常以及数据冗余等问题。

规范化的基本思想

• 原则：“分离”和“一事一地”。即，让一个关系模式专注于描述一个概念、一个实体或实体间的一种联系。对于包含多个概念的情况，则需要将其分离为多个关系模式。
• 实质：通过规范化，实现概念的单一化和简化。

规范化的步骤

• 分解：将低级别范式的关系模式分解为若干个高级别范式的关系模式。
• 注意：这种分解并不唯一，不同的分解策略可能导致不同的高级别范式关系模式。

规范化的范式级别

• 第一范式（1NF）：确保每个字段都是不可分的基本数据项。
• 第二范式（2NF）：在1NF的基础上，消除非主属性对主键的部分依赖。
• 第三范式（3NF）：在2NF的基础上，消除非主属性对主键的传递依赖。
• BCNF：在3NF的基础上，消除主属性对主键的部分依赖和传递依赖。
• 第四范式（4NF）：在BCNF的基础上，消除非平凡的多值依赖。
• 第五范式（5NF）：在4NF的基础上，消除所有非平凡的连接依赖。

规范化的应用和考虑

• 权衡：在进行规范化时，需要在减少数据冗余和操作异常与维护查询性能之间做出权衡。
• 实际应用：在实际数据库设计中，通常会根据具体需求和性能要求来决定达到哪个级别的范式。完全规范化并非总是最佳选择，特别是在需要频繁进行大量连接操作的场景中。