6.2 规范化

思维导图：

 

 

6.2 规范化

关键概念

• 依赖关系: 探讨属性间的依赖性质及其对关系合适性的影响。
• 范式等级: 根据属性间的依赖情况，将关系规范化程度区分为1NF、2NF、3NF、和BCNF。
• 错误的设计示例: 通过表6.2中的错误设计，直观理解依赖关系对设计的影响。

依赖和范式

• 函数依赖(Functional Dependency, FD):

  • 定义: 如果在关系模式R中，属性集X的值能够唯一确定属性集Y的值，则称Y函数依赖于X，表示为X→Y。
  • 非平凡依赖: X→Y, 且Y不是X的子集。
  • 平凡依赖: X→Y, 且Y是X的子集。
  • 决定属性组: 引起函数依赖的属性集，称为决定因素。
  • 互相依赖: 如果X→Y且Y→X，则表示为X-→Y。
  • 完全函数依赖: 如果X→Y并且不存在X的真子集X'使得X'→Y。
  • 部分函数依赖: 如果X→Y但存在X的真子集X'使得X'→Y。

• 传递函数依赖(Transitive Dependency, TD):

  • 定义: 如果存在属性集X→Y, Y→Z且Y不函数依赖于X，Z也不是Y的子集，则称Z对X传递函数依赖。
  • 标记: X+Y表示Y不依赖于X；X=Y表示Z对X传递函数依赖。

设计错误分析

• 例子: 表6.2中Sno→Sdept不成立，显示了设计中的错误（相同的Sno对应不同的Sdept）。

设计原则

• 函数依赖应基于现实世界的语义。
• 在设计中可以强制性规定某些依赖，以维持数据的一致性。

术语记号

• X→Y: X函数决定Y。
• X-→Y: X和Y互相函数依赖。
• X+Y: Y不函数依赖于X。
• X=Y: Z对X传递函数依赖。

范例分析

• 完全函数依赖: (Sno,Cno)→Grade。
• 部分函数依赖: (Sno,Cno)→Sdept，因为Sno→Sdept已经成立。

 我的理解：

规范化（Normalization）

规范化是数据库设计中的一种技术，目的是为了避免数据中的冗余和确保数据的一致性。通过规范化处理，可以将一个大的、可能导致数据问题的表分解成小的、互相连接的多个表。

范式（Normal Forms）

范式是衡量数据库结构规范化程度的级别。每个级别都有其规则，满足这些规则的数据库表可以减少数据冗余和避免不良的数据操作。

• 第一范式（1NF）：表的每个字段都是不可分割的基本数据项，即表中的所有字段都是原子性的。
• 第二范式（2NF）：在1NF的基础上，表必须确保所有非关键字段完全依赖于主键。
• 第三范式（3NF）：在2NF的基础上，表中的非主键字段不能依赖于其他非主键字段。
• BCNF范式：是3NF的加强版，要求主键外的任何字段都不能决定其他字段。
• 第四范式

函数依赖（Functional Dependency）

这是理解规范化过程中的核心概念。

• 函数依赖：在数据库中，如果一个属性的值可以决定另一个属性的值，则称后者函数依赖于前者。
• 完全函数依赖：如果A是一个属性集，B是依赖于A的属性，那么B对A的依赖称为完全函数依赖，当且仅当B不依赖于A的任何真子集。
• 部分函数依赖：如果B函数依赖于A的一部分（真子集），而不是整个A，那么这种依赖称为部分函数依赖。
• 传递函数依赖：如果有三个属性A、B、C，其中A函数决定B，B函数决定C，但C不直接依赖于A，这种情况下，C对A的依赖称为传递函数依赖。
• 例题：
• 

关系不规范的问题

如果关系（表）设计不规范，会产生以下问题：

• 插入异常（Insertion Anomalies）：无法添加必要数据或者添加数据时需要添加无关数据。
• 删除异常（Deletion Anomalies）：删除某些信息可能导致意外删除更多的数据。
• 更新异常（Update Anomalies）：更新操作需要更改多行来保持数据的一致性。

如何理解？

理解这些概念，最好的方式是通过实例。例如，考虑学生和课程的情况，如果所有信息都放在一个大表中，那么学生的姓名和选的课程可能多次出现，造成数据冗余。函数依赖帮助我们识别哪些字段应该在一起，哪些应该分开，从而设计出既不冗余也能表示所有必要信息的数据库表结构。

通过不断地应用规范化的原则和检查函数依赖，我们可以设计出既高效又符合逻辑的数据库结构，这样的结构可以优化查询，减少错误，并使数据库更易于维护。

我能学到什么？

从这节内容中，关于数据库规范化和函数依赖的讨论，我们可以学习到很多重要的概念和技能，这些不仅在数据库设计中至关重要，也能够被应用到数据科学和软件工程等多个领域。下面是一些关键的学习点：

数据库设计理念

1. 数据冗余的问题：理解数据冗余可能导致的问题，如更新异常、插入异常和删除异常。
2. 数据完整性：保持数据的准确性和可靠性是数据库设计的关键目标。

关系模式和函数依赖

1. 关系模式：了解表结构（关系模式）的定义和它在数据库设计中的重要性。
2. 函数依赖：掌握函数依赖的基本概念，包括函数依赖的定义、完全函数依赖、部分函数依赖、传递函数依赖等。

规范化理论

1. 范式理论：了解不同的范式（1NF、2NF、3NF、BCNF等）及其对数据库设计的影响。
2. 设计分解：学会如何通过规范化过程将一个有缺陷的模式分解成多个符合范式要求的较小模式。

数学与逻辑应用

1. 集合论与逻辑：应用集合论和逻辑推理来分析和解决数据库设计问题。
2. 逻辑推理能力：培养通过逻辑分析来判断函数依赖是否存在以及它们如何影响数据库设计的能力。

实际操作技能

1. 识别并消除异常：通过规范化理论来识别潜在的数据异常并采取措施消除它们。
2. 优化查询：理解规范化如何影响查询性能，以及如何在规范化和查询优化之间找到平衡。

批判性思维

1. 权衡决策：认识到过度规范化可能会导致性能下降，因此在设计时要做出权衡。
2. 应用场景分析：分析不同的业务场景，如何选择合适的范式。

扩展知识

1. 数据模型理论：探索范式理论如何与其他数据模型理论相交叉，如ER模型、维度模型等。
2. 新兴技术适应性：了解规范化在非关系型数据库（如NoSQL）设计中的适用性。

综合来看，这节内容不仅教会我们如何设计结构良好、无冗余的数据库，而且也增强了我们逻辑思维、问题解决和批判性分析能力。

从证明中我们能学到了什么？

这一节中的证明主要涉及逻辑推理、集合理论和关系代数，这些是数据库规范化的数学基础。我们可以从这些证明中学习以下数学思想和技巧：

数学思想

1. 分治思想：将复杂的问题（如大表的设计问题）分解成若干个更小、更易于管理的子问题（如范式分解）。

2. 抽象思维：用函数依赖这种抽象的概念来描述和理解实体之间的关系和约束。

3. 规约：将一个复杂问题转化为一个已知或者更易解决的问题（如通过分解规范化的步骤解决数据冗余问题）。

数学思维

1. 逻辑推理：通过逻辑推导确定属性之间的依赖关系，并据此制定数据库设计规则。

2. 归纳与演绎：从特定的函数依赖关系出发，归纳出一般的规范化原则；或者从一般原则演绎出具体的数据库设计步骤。

3. 条件与结论：理解函数依赖的定义和使用这些定义来判断数据库设计是否满足特定的范式要求。

数学方法

1. 集合理论：用集合理论的语言来描述和处理属性集、函数依赖集等。

2. 证明方法：使用直接证明、反证法等证明方法来验证函数依赖的属性或规范化过程的正确性。

3. 关系演算：使用关系演算的方法来表达和计算函数依赖，以及推导更高范式的设计。

数学处理技巧

1. 构造性方法：在设计数据库时，从基本范式开始，逐步构造出满足更高范式的设计。

2. 反例分析：通过找到违反函数依赖的例子来理解和解决设计问题。

3. 分解与合成：对于不符合要求的关系模式进行分解，达到规范化的要求，再通过适当的方式将分解后的模式重新组合。

通过这些数学的思想、思维、方法和技巧，我们不仅能够更好地理解和实施数据库规范化，而且还能够提高我们解决各种逻辑和结构性问题的能力。在数据库规范化的证明过程中，这些数学工具帮助我们确保数据库设计可以达到既定的数据一致性和完整性标准，同时也促进了我们逻辑思维和问题解决能力的提高。

6.2.2 码 (Key)

定义与概念

• 码 (Key): 关系模式中属性或属性组，能唯一标识关系中的一个元组。
• 候选码 (Candidate Key): 最小的属性集，使得在关系模式中不存在两个元组在这些属性上的值相同。
  • 完全函数依赖: 属性组U在候选码K上是完全函数依赖，而非部分函数依赖。
• 超码 (Superkey): 若属性集K使得U在K上至少是部分函数依赖，则K是超码。
• 主码 (Primary Key): 若一个关系模式中有多个候选码，选定其中一个作为主码。
• 全码 (All-key): 整个属性组作为码。

属性分类

• 主属性 (Prime Attribute): 包含在任一候选码中的属性。
• 非主属性 (Non-Prime Attribute or Non-Key Attribute): 不包含在任何候选码中的属性。

术语对照

• 码 也可称作“键”或“键码”。

例子

• 例6.2: 在关系模式 S(Sno, Sdept, Sage) 中，Sno 是候选码。
• 例6.3: 关系模式 R(P, W, A)，其中 P 表示演奏者，W 表示作品，A 表示听众，码为 (P, W, A)，即全码。

外部码 (Foreign Key)

• 定义: 关系模式R中的属性组X不是R的码，但在另一个关系模式中是码。
• 例: 在 SC(Sno, Cno, Grade) 中，Sno 是外部码，因为它是关系模式 S(Sno, Sdept, Sage) 的码。

关系间联系

• 联系表现: 主码和外码用来表示不同关系模式间的联系，例如 S 和 SC 通过 Sno 关联。

 我的理解：

1. 码 (Key)：码是用来在一个数据库表中唯一标识一条记录的一个或一组字段。它是关系数据库设计中的一个基础概念。

2. 候选码 (Candidate Key)：一个或一组属性，它能够确保在一个关系模式中的所有数据实例都是唯一的。换句话说，使用候选码的任何两个元组都不会在所有的候选码属性上具有完全相同的值。

3. 完全函数依赖：如果属性集U在候选码K上完全函数依赖，这意味着U的值可以被K唯一确定，而且不能通过K的任何子集来确定。

4. 超码 (Superkey)：超码是包含了候选码的属性集。换言之，超码可能包括额外的属性，即使去掉这些额外的属性，剩下的属性仍然能唯一标识元组。

5. 主码 (Primary Key)：如果有多个候选码，选择其中一个作为主码，它是被数据库设计者选中用来在关系中唯一标识元组的码。

6. 全码 (All-key)：当一个关系的所有属性集合作为码时，称之为全码。

7. 主属性 (Prime Attribute)：如果一个属性包含在至少一个候选码中，它就被称为主属性。

8. 非主属性 (Non-Prime Attribute)：不包含在任何候选码中的属性被称为非主属性。

9. 外部码 (Foreign Key)：是指一个关系中的属性或属性组，它自己在本关系中不是候选码，但是作为另一个关系的候选码。它用来建立两个关系之间的联系。

理解这些概念的关键在于认识到它们是如何帮助我们在数据库设计中建立结构化和有组织的数据存储。通过使用码来确保数据的唯一性和完整性，我们可以更容易地进行数据检索，维护数据一致性，以及实现关系之间的连接。

更加形象的理解：

让我们用一些生活中的比喻来形象化这些数据库规范化的概念。

1. 码 (Key)：想象一下每个人都有一个独一无二的身份证号码，不管有多少人同名同姓，身份证号都能准确找到对应的个人。在数据库中，码就是那个身份证号码，确保每一行记录的唯一性。

2. 候选码 (Candidate Key)：这就像是一个人可能有多种方法可以被唯一识别：身份证号、护照号、或驾驶证号等等。这些都是候选码，因为它们每一个都能独立识别一个人。

3. 完全函数依赖：这好比一个人的身高是完全依赖于那个人的身体，而不是身体的某个部分。在数据库中，如果一个属性集U完全依赖于候选码K，那么没有K的一部分就能确定U的值。

4. 超码 (Superkey)：可以想象为一个超级身份证，它包含了普通身份证的所有信息加上更多额外的信息（比如：足球队会员号），即使这些额外信息并不是识别个人必需的。

5. 主码 (Primary Key)：在多个可以用来识别的选项（如身份证号、护照号等）中，主码就是我们选择来作为“正式身份证明”的那个号码。

6. 全码 (All-key)：这就像是一个超级详细的档案，它用一个人的所有特征来识别他们——不只是名字和生日，还包括了发色、眼睛颜色、身高、体重等等。在数据库中，全码含有所有可能的属性。

7. 主属性 (Prime Attribute)：这些是包含在任何身份验证方法中的信息，比如你的姓名可能会同时出现在你的身份证和驾驶证上。

8. 非主属性 (Non-Prime Attribute)：这类似于你的喜好或者穿鞋的尺码，这些信息并不是身份验证时考虑的，它们不会出现在身份证或驾驶证上。

9. 外部码 (Foreign Key)：就像你的工作证件上可能打印有你的身份证号码一样，工作证件并不能证明你的身份，但它通过身份证号码与你的身份联系起来。在数据库中，外部码建立不同表之间的逻辑联系。

6.2.3 范式 (Normalization Forms)

基础定义:

• 范式: 关系数据库结构的优化级别，通过消除冗余数据和不一致性来提升数据库的逻辑一致性。
• E.F. Codd: 范式理论的创始人。

范式等级:

1. 第一范式 (1NF): 每个列的值必须是原子的，不能再分解。
2. 第二范式 (2NF): 满足1NF，并且每个非主属性完全函数依赖于任何一个候选键。
3. 第三范式 (3NF): 满足2NF，并且所有的非主属性都不传递依赖于候选键。
4. BCNF (Boyce-Codd Normal Form): 满足3NF，并且对于任何非平凡的函数依赖 �→�X→A，X都是超键。
5. 第四范式 (4NF): 满足BCNF，并且没有多值依赖。
6. 第五范式 (5NF): 满足4NF，并且从理论上讲，任何多对多的关系都被分解为多个一对多关系。

范式关系图解:

1NF < 2NF < 3NF < BCNF < 4NF < 5NF

规范化过程:

• 模式分解 (Schema Decomposition): 将低级别范式的关系模式分解成多个高级别范式的关系模式。
• 规范化的目的: 减少数据冗余，避免更新异常，提高数据完整性。

笔记图解:

5NF
 │
4NF
 │
BCNF
 │
3NF
 │
2NF
 │
1NF

重要性:

• 性能和维护: 高级别范式通常意味着更好的数据库性能和更容易的维护。
• 规范化和反规范化: 规范化有利于减少数据冗余，而反规范化则可能为了优化查询性能而适当增加冗余。

当你学习这些概念时候，确保理解每个范式的定义和它们之间的区别。理解规范化是一个逐步的过程，每一个更高级别的范式都在上一个范式的基础上增加了新的约束。而且，了解规范化并不总是绝对的目标，有时为了查询性能考虑，可能会有意识地选择较低级别的范式。

 我的理解：

范式的目的

范式是关系数据库设计中用来评价表结构的一种标准。目的是通过分解表结构，减少数据冗余和改善数据完整性，避免更新操作时出现问题，如插入异常、删除异常和更新异常。

基本范式概念

• 第一范式 (1NF): 表的每一列都是不可分割的基本数据项，实际上就是确保表中的字段值都是原子的。
• 第二范式 (2NF): 在1NF的基础上，非键字段必须完全依赖于主键。换言之，表中不存在对主键的部分依赖。
• 第三范式 (3NF): 在2NF基础上，非键字段只依赖于主键，即不存在传递依赖。
• BCNF (Boyce-Codd Normal Form): 在3NF基础上，加强了对依赖的要求，即任何非平凡的依赖 X→A 中，X 必须包含候选键。
• 第四范式 (4NF): 在BCNF基础上，表中不应存在多值依赖。
• 第五范式 (5NF): 是更进一步的优化，确保任何关联依赖都是由候选键导出的。

理解范式的过程

• 规范化: 这是数据库设计中的一个过程，涉及将一个表分解成多个表，以此来满足更高级别的范式，减少数据冗余。
• 分解: 在保持数据依赖的同时，将一个低级范式的表分解成多个高级范式的表，这通常涉及到识别功能依赖并应用它们来分解表。

直观比喻

• 想象你有一个大衣橱，里面放满了衣服（数据）。如果没有好的组织（1NF），找到一件衣服可能需要翻过每一件。
• 当你把衣服按类别挂好（2NF），你不需要查看每一件就能找到你想要的类型。
• 进一步，如果衣服不仅分类，而且颜色也整理好（3NF），找到特定的衣服就更快了。
• BCNF就像确保你的衣橱每个部分都很容易访问，没有任何衣服被其他衣服遮挡。
• 4NF和5NF的概念可以比作确保衣橱里没有不必要的重复衣服，每件衣服都有其特定的位置和目的。

理解这些范式有助于你在设计数据库时，可以根据实际需求和性能考虑，选择适当的范式以达到数据结构的最优化。

6.2.4 二级范式（2NF）

范式定义

• 2NF: 当一个关系模式R位于1NF并且它的每个非主属性完全函数依赖于任何一个候选码时，R处于2NF。

关系模式例子

• 关系模式: S-L-C(Sno, Sdept, Sloc, Cno, Grade)
• 候选码: (Sno, Cno)
• 函数依赖:
  • (Sno, Cno) -> Grade （成绩依赖于学号和课程号）
  • Sno -> Sdept （学系依赖于学号）
  • Sdept -> Sloc （住址依赖于学系）

2NF违反示例

• Sdept和Sloc并不完全函数依赖于码(Sno, Cno)，所以S-L-C不满足2NF。

设计问题

• 插入异常: 无法插入尚未选课的学生信息。
• 删除异常: 删除选了单一课程的学生时会丢失该学生的其他信息。
• 修改复杂: 学生转系时需要重复修改多个元组中的系和住址信息。

解决方案：分解

• 分解为SC和S-L:
  • SC(Sno, Cno, Grade): 处理学生和课程的关系。
  • S-L(Sno, Sdept, Sloc): 处理学生和系及住址的关系。

函数依赖图

• SC: Grade 完全函数依赖于 (Sno, Cno)。
• S-L: Sdept 和 Sloc 完全函数依赖于 Sno。

通过分解，每个非主属性对于码都实现了完全函数依赖，满足2NF要求，同时解决了插入异常、删除异常和修改复杂的问题。

我的理解：

二级范式（2NF）的概念涉及到关系数据库设计中的数据整理方法，旨在减少数据的冗余和提高数据的一致性。下面通过一系列比喻来帮助理解这一节的概念：

1. 基本定义的理解：

   • 关系模式：想象一本组织各种信息的目录，其中每个项目（如学生信息）都有多个部分（如姓名、系别、住址等）。
   • 候选码：就像是每个学生的独一无二的识别号码组合，可以确保你指向的是正确的人。
   • 完全函数依赖：如果要了解学生的某项信息（比如成绩），你需要知道他们的完整识别信息（即所有候选码）。如果你只用部分信息就能确定（如只用学号），这就说明那部分信息对其他信息有一个不完整的控制，这就不是完全函数依赖。

2. 2NF违反示例的理解：

   • 把上述的目录比作一个大档案柜，每个学生的所有信息都存放在一个文件夹里。
   • 如果学生的系别和住址信息仅仅依赖于学号而不是整个识别号码（学号和课程号的组合），这就像是把某些信息（系别和住址）放错了地方，它们并不需要整个文件夹的所有标签来被找到，而只需要一个（学号）。
   • 这种情况下，如果你要添加一个新学生但还没有课程号，就像是你有文件夹的一部分标签但没有全部，这就使得文件夹不完整，导致无法正确存档（插入异常）。
   • 删除或修改也有类似问题，如果你只想修改学生的系别或住址，你可能需要无谓地触及和修改很多其他不相关的信息，因为它们都混在一起（修改复杂）。

3. 分解的理解：

   • 解决上述问题的方法是分解。你可以创建两个分开的档案柜：一个用于学生和课程的关系（SC），另一个用于学生和他们系的关系以及住址（S-L）。
   • 这样做的好处是每个档案柜都有它专门的标签系统，可以独立地添加、删除或修改信息，而不会影响到其他档案柜里的信息。
   • 通过这种方法，你确保了每个信息片段（属性）都是完全依赖于正确的标识号码的，没有混乱和不必要的冗余。

6.2.5 三级范式 (3NF)

定义6.7

• 一个关系模式R<U,F>处于1NF；
• 不含传递依赖：不存在这样的情况，即一个非主属性Z通过一个非码属性组Y传递依赖于某个码X；
• 形式化地说，如果存在X→Y且Y→Z成立，但Y不包含X（Y+X），则不满足3NF；
• 满足3NF要求的关系模式，其非主属性不会部分依赖于码也不会传递依赖于码。

推论

• 3NF的关系模式也一定是2NF的。

示例

• 在图6.4的关系模式SC中，不存在传递依赖，因为非主属性与码之间的依赖是直接的；
• 然而在图6.5的关系模式S-L中，Sdept是非主属性且存在传递依赖：Sno→Sdept 且 Sdept→Sloc，形成了传递依赖Sno→Sloc；
• 因此，SC满足3NF，而S-L不满足3NF。

存在的问题

• 如果一个关系模式不是3NF的，会出现数据冗余，导致插入异常、删除异常和修改异常。

解决方案

• 分解关系模式：将S-L分解为S-D和D-L。
  • S-D (Sno, Sdept) 处理学生和系的直接关系；
  • D-L (Sdept, Sloc) 处理系和系所在地的直接关系；
• 分解后的关系模式不再包含传递依赖，有助于维护数据的一致性和减少冗余。

我的理解：

三级范式（3NF）是数据库规范化设计的一部分，其目的在于减少数据冗余，提高数据的逻辑一致性。我们可以通过一个简单的日常类比来理解这个概念：

假设我们有一个大学的数据表，这个表格记录了学生的ID、学生所在的系和该系的位置。现在我们希望对这些信息进行规范化处理，以确保每部分信息都是有序且清晰的。

第一级范式 (1NF)

首先，我们确保每个单元格内只有单一的信息，没有任何的列表或者重复的信息。这就像确保你的笔记本上每一行只记录一件事情，而不是把多件事情挤在一起。这是数据规范化的基础，称为第一级范式（1NF）。

第二级范式 (2NF)

然后，我们进一步看这个表格，并确保所有非关键信息都完全依赖于主键。如果学生的ID是主键，那么每个学生的系（Sdept）和住址（Sloc）都应该只依赖于那个学生的ID。这就像是当你在笔记本上记录朋友的生日时，你不会仅仅因为他们住在同一个城市就将他们的生日归在一起。每个生日必须明确地与一个朋友的名字相对应。这种设计思想称为第二级范式（2NF）。

第三级范式 (3NF)

接着，我们要进一步确认没有任何非主要信息仅仅依赖于另外的非主要信息。在我们的例子中，如果系的位置（Sloc）总是随着系（Sdept）变化而变化，那么系的位置就不应该直接存储在学生的记录中，因为这不是直接依赖于学生的ID。这就像是你不会在记录朋友地址的同时，仅仅因为他们来自相同的国家就记录他们的国家特色菜肴。学生的系和系的位置应该分别记录在不同的表中。这就是第三级范式（3NF）。

综上所述，3NF的目标是确保数据表中的每一项信息都是直接与主键相关联的，并且不存在不必要的间接关联。这使得数据库更加清晰、有效，减少了数据更新异常的风险。

三级范式（Third Normal Form, 3NF）是数据库规范化设计中的一个关键概念。在学习这一节时，可以应用和理解多种数学思想和方法。以下是从三级范式学到的数学思想和方法，以及在处理数据库设计时可用的技巧：

学到了什么？

数学思想：

1. 抽象和泛化：

   • 在考虑3NF之前，必须理解函数依赖（FD）和传递依赖（TD），这需要将现实世界的数据关系抽象成数学上的关系和依赖。
   • 泛化是从特定的例子中提炼出一般规则的过程。理解1NF和2NF的设计要求，并从中泛化出3NF的更一般性要求。

2. 逻辑推理：

   • 分析数据依赖，并推导出是否满足3NF的条件，这需要扎实的逻辑推理能力。
   • 识别不仅是直接依赖，还包括间接或传递性的数据依赖。

3. 批判性思维：

   • 考虑不同设计选择的影响，评估分解到3NF所带来的利弊。

数学方法：

1. 集合论：

   • 数据库设计中广泛使用集合论概念，比如属性集、候选键集等。
   • 识别和应用键集的概念，确定属性之间的函数依赖关系。

2. 关系理论：

   • 使用关系模型来表示数据和依赖，这是一种基于集合的数学理论。
   • 了解和应用函数依赖、候选键、主键以及它们之间的关系。

数学处理技巧：

1. 正规化/规范化：

   • 学习如何将关系模式从低级范式（如1NF或2NF）转换到3NF。
   • 应用规范化的步骤和过程，比如消除传递依赖。

2. 分解：

   • 通过分解非3NF的关系模式，以达到减少数据冗余和更新异常的目的。
   • 分解的同时，确保分解后的模式能够无损连接，即可以保留原有的数据信息。

3. 映射和函数：

   • 在考虑依赖时，需要识别属性之间的映射关系。
   • 理解属性如何通过函数依赖映射到其他属性，并使用这种理解来重构数据模型。

应用这些思想和技巧的例子：

• 在确定是否需要进一步分解关系模式时，使用抽象化的函数依赖集来检测潜在的更新异常。
• 分析给定关系模式，使用集合论方法来识别所有候选键，并检查它们是否满足3NF条件。
• 当一个属性依赖于另一个非候选键属性时，用逻辑推理来识别并消除传递依赖。

学习3NF时的一个重要的数学技巧是能够在抽象层面上理解和操作数据结构，同时要有能力将这些抽象的概念应用到具体的数据库设计实践中。通过精通这些方法和技巧，数据库设计者可以创建既能准确反映现实世界情况又高效灵活的数据库模式。

定义6.7证明中学到的：

在证明三级范式（3NF）的定义及其与其他范式的关系时，我们会涉及到一系列数学思想、思维方式、方法和处理技巧。通常，这些证明会基于定义6.7，这里假定定义了什么构成3NF，并可能涉及如何将关系模式分解成3NF。下面是通过这类证明过程所能学到的：

数学思想：

1. 形式化定义：

   • 证明中会使用精确的数学语言来形式化定义3NF。这要求一个关系模式中的每个非主属性不仅非传递依赖于候选键。

2. 规范化的重要性：

   • 规范化是为了减少数据冗余和避免更新异常，以及插入和删除异常的过程。它展示了数学在数据结构优化中的应用。

数学思维：

1. 逻辑推理与证明：

   • 在进行数学证明时，你会使用逻辑推理来展示数据结构为何要遵循特定的规则（如3NF）。
   • 运用归纳和演绎推理来验证关系模式是否满足3NF的定义。

2. 批判性分析：

   • 分析关系模式中数据依赖的本质，并批判性地考虑它们是否满足3NF的要求。

数学方法：

1. 集合论与关系理论：

   • 应用集合论来处理属性集、候选键集和数据依赖集。
   • 关系理论提供了一组工具和术语来描述和处理这些集合和它们之间的关系。

2. 映射与函数：

   • 在证明中，函数依赖是一种特殊的映射，其属性值决定了其他属性值。证明过程需要准确理解和表述这些映射。

数学处理技巧：

1. 分解与重构：

   • 证明分解为3NF是否会导致信息的无损失。这涉及到将关系模式分解为多个较小的模式，并能够将这些小的模式重组回原始的模式。

2. 分析与构造：

   • 分析给定的关系模式和函数依赖，构造证明以展示模式是否在3NF中，或如何转化成3NF。

3. 问题简化：

   • 证明可能涉及将复杂问题简化为更易于管理的子问题，例如通过处理单一函数依赖而不是整个依赖集合。

通过这样的证明过程，我们学会了如何运用数学理论和方法系统地分析和构建数据库模式。这些技能不仅适用于数据库设计，还适用于任何需要精确和系统分析的领域。在数据库设计中，这些技能帮助确保数据模式的健壮性、效率和可维护性。

6.2.6 BCNF (Boyce-Codd Normal Form)

定义和背景

• BCNF 是数据库规范化的一个阶段，由Raymond F. Boyce和Edgar F. Codd提出。
• 它是3NF的加强版，有时被称为3NF的扩展或修正。

形式化定义（定义6.8）

• BCNF条件：关系模式 �<�,�>R<U,F> 处于1NF中，对于每一个非平凡的函数依赖 �→�X→Y，若 �⊆�Y⊆X，则 �X 至少包含一个候选键。

特点

• 所有非主属性对每个候选键都是完全函数依赖。
• 所有主属性对任何不包含它的候选键也是完全函数依赖。
• 不存在任何属性完全函数依赖于非候选键的属性集。

与3NF的关系

• BCNF vs 3NF：
  • 所有BCNF的关系模式也属于3NF。
  • 但并非所有3NF的关系模式满足BCNF。

示例分析

• 例6.5：关系模式 C(Cno, Cname, Pcno)

  • 分析：由于没有属性对候选键 Cno 部分或传递依赖，因此 C 属于3NF和BCNF。

• 例6.6：关系模式 S(Sno, Sname, Sdept, Sage)

  • 分析：假设 Sname 具有唯一性，形成两个单属性码，满足3NF和BCNF。

• 例6.7：关系模式 SJP(S, J, P)

  • 分析：(S, J) 和 (J, P) 都是候选键，没有传递依赖和部分依赖，所以模式满足BCNF。

• 例6.8：关系模式 STJ(S, T, J)

  • 分析：尽管 STJ 是3NF，但由于 T 是决定因素并且不包含任何候选键，它不符合BCNF。

为何BCNF重要

• BCNF旨在进一步减少数据冗余并消除更新异常。
• 与3NF相比，BCNF在消除某些类型的依赖方面更为严格。

将关系模式转化为BCNF

• 对于不满足BCNF的关系模式，可以通过分解来实现BCNF。
• 分解应该是无损连接，并保持函数依赖。

总结

• BCNF是一种旨在提高数据模型质量的设计方法。
• 它帮助理解关系模式中属性间的依赖性，指导如何组织数据结构以减少异常和提高数据完整性。
• 尽管BCNF在某些情况下可能难以实现或可能导致过度分解，但它是数据库设计中一种重要的范式。

我的理解：

1. 数据库规范化的目的

数据库规范化是为了减少数据的冗余和避免各种异常（插入、删除和更新异常）。在规范化的过程中，设计者会通过一系列范式（1NF, 2NF, 3NF, BCNF等）对关系模式进行改造，以达到更合理的数据库设计。

2. 理解函数依赖

• 函数依赖是理解BCNF的核心。简单来说，如果通过一组属性（如A）的值，我们可以确定另一组属性（如B）的值，那么就称B对A函数依赖，表示为A → B。
• 候选键是能够唯一标识实体的属性集合。在函数依赖中，左边的部分如果是候选键，就有了特殊的意义。

3. 对比3NF和BCNF

• 3NF（第三范式）要求一个关系模式内，没有任何非主属性对主键的部分依赖和传递依赖。
• BCNF则更加严格，它要求对于任何非平凡的函数依赖X → Y，X必须是一个超键（即X包含了一个候选键）。

4. 案例分析和转化

通过具体的例子（如例6.5到例6.8）来理解BCNF和3NF的差异，以及如何识别和调整不满足BCNF的关系模式。例如，通过分解可以将不满足BCNF的关系模式转化为满足BCNF的几个关系模式。

5. 高级概念的实际应用

了解BCNF在实际数据库设计中的应用和它解决的具体问题（比如消除更新异常），有助于更深入地理解这一概念。

理解BCNF的一些技巧：

• 图示化：用图来表示属性之间的函数依赖关系，这可以帮助直观地理解哪些属性组合形成候选键。
• 举例证明：通过构建例子来展示特定的关系模式是否符合BCNF。
• 反例分析：识别不符合BCNF的关系模式，并理解为什么它们不符合条件。

6.2.7 多值依赖

多值依赖（MVD）在数据库设计中是一个重要的概念，它扩展了函数依赖的概念。当关系模式中存在非平凡的多值依赖时，仅仅满足BCNF也不能消除数据冗余。

定义

• 多值依赖 �↠�X↠Y 在关系模式 �(�)R(U) 中成立，当且仅当对于 �(�)R(U) 的任一关系 �r，对于给定的一对 (�,�)(x,z) 值，存在一组 �Y 的值，这组值仅由 �x 决定而与 �z 无关。

例子

考虑关系模式 ����ℎ���(�,�,�)Teaching(C,T,B)，其中 �C 是课程，�T 是教师，�B 是参考书。在 ����ℎ���Teaching 中 �↠�C↠T 表示给定课程 �C，可能有多个教师 �T 关联，且这个教师集合仅由课程 �C 确定，与参考书 �B 无关。

特点

• 传递性: 若 �↠�X↠Y 且 �↠�Y↠Z，则 �↠�−�X↠Z−Y。
• 对称性: 若 �↠�X↠Y，则 �↠�X↠Z，其中 �=�−�−�Z=U−X−Y。

非规范化与规范化

• 非规范化的关系可能会有重复数据，导致增删改操作上的不便利和数据冗余。
• 规范化过程中，我们尝试将关系模式分解，以减少数据冗余，并提高数据操作的效率。

解决方法

通过进一步的规范化来处理多值依赖，可以将关系模式分解为较小的多个关系模式，通常是采用第四范式（4NF）来确保所有的多值依赖都被合理地处理。

实际应用例子

关系模式 ���(�,�,�)WSC(W,S,C)：

• �W 是仓库，�S 是保管员，�C 是商品。
• �↠�W↠S 表示每个仓库 �W 有固定的保管员集合 �S，与存储的商品 �C 无关。
• �↠�W↠C 表示每个仓库 �W 存储固定的商品集合 �C，与保管员 �S 无关。

结论：满足BCNF的关系模式可能仍然存在多值依赖，进而导致数据冗余。处理多值依赖需要进一步的规范化至4NF，以确保数据操作的方便性和数据的完整性。

我的理解：

理解这一节的概念，我们可以从多值依赖（MVD）的基础理论入手，并通过具体的例子来加深理解。

多值依赖（MVD）的基本概念：

• 定义: 在一个关系模式中，如果属性集 �X 确定了属性集 �Y 的一组值（而这组值不依赖于其他属性），则称 �X 对 �Y 有多值依赖。形式上表示为 �↠�X↠Y。

• 对称性: 如果 �↠�X↠Y 成立，那么对于除 �X 和 �Y 之外的其他所有属性集合 �Z，�↠�X↠Z 也成立。

• 传递性: 如果 �↠�X↠Y 和 �↠�Y↠Z 成立，那么 �↠�X↠Z（减去 �Y 中已经由 �X 确定的部分）也成立。

例子理解：

例子1：教学场景

• 在教学关系模式 ����ℎ���(�,�,�)Teaching(C,T,B) 中，一个课程 �C 被多个教师 �T 讲授，而每个教师可能教授多个课程，并且不同课程可能使用相同的参考书 �B。

• 举例来说，如果李勇老师和王军老师都教授物理课，并使用同样的参考书，那么当我们知道了课程是物理时，教师集合（李勇，王军）就已经确定，无论参考书是什么。

例子2：仓库场景

• 在关系模式 ���(�,�,�)WSC(W,S,C) 中，每个仓库 �W 有特定的保管员 �S 和存储的商品 �C。

• 对于一个仓库来说，它可能存储多种商品，同时有多个保管员。因此，知道了仓库 �W 之后，我们可以确定一个完整的保管员集合和商品集合，而这两个集合互相独立。

数据冗余与操作不便的问题：

• 在非规范化关系中，当需要增加或删除某个信息（如增加一个讲授物理的教师）时，可能需要操作多个元组，因为该教师可能与多个课程和参考书有关联。

• 这种重复数据增加了存储空间的需求，也使得数据更新更复杂，因为更新一条数据可能需要在多个地方同时进行。

规范化的解决方法：

• 通过将关系模式分解为更小的，符合4NF的模式，可以减少数据冗余，并确保每种类型的信息只在数据库中表示一次。这样，数据的增加、删除和修改都会变得更简单，而且错误的风险也会减少。

函数依赖作为多值依赖的特例

1. 函数依赖到多值依赖的转化：
   • 如果存在函数依赖 �→�X→Y，则也存在多值依赖 �↠�X↠Y。
   • 原因：函数依赖意味着对于X的每个值，Y有一个确切的值相对应，这符合多值依赖的定义。

多值依赖的属性

1. 多值依赖的传递性：

   • 如果 �↠�X↠Y 且 �↠�X↠Z，则 �↠��X↠YZ 也成立。
   • 如果 �↠�X↠Y 且 �↠�X↠Z，则 �↠�∩�X↠Y∩Z 也成立。

2. 多值依赖的差异性：

   • 如果 �↠�X↠Y 且 �↠�X↠Z，则 �↠�−�X↠Y−Z 与 �↠�−�X↠Z−Y 都成立。

多值依赖与函数依赖的区别

1. 依赖的有效性：

   • 多值依赖的有效性依赖于属性集的整体范围，而函数依赖仅依赖于其直接相关的属性集。
   • 嵌入型多值依赖：在更大的属性集 �U 上成立的多值依赖可能在子集 �W 上不成立。

2. 依赖的适用性：

   • 函数依赖 �→�X→Y 在 �(�)R(U) 上成立，则对于任何 �′⊆�Y′⊆Y 均有 �→�′X→Y′ 成立。
   • 多值依赖 �↠�X↠Y 在 �(�)R(U) 上成立，则不能断言对于任何 �′⊆�Y′⊆Y 有 �↠�′X↠Y′ 成立。

例子解释

1. 例子：
   • 给定关系 �(�,�,�,�)R(A,B,C,D)，存在多值依赖 �↠��A↠BC 和 �↠�A↠D。
   • 关系实例表明，尽管 �↠��A↠BC 成立，但 �↠�A↠B 单独可能不成立。

笔记总结：

• 多值依赖可以包含函数依赖，但它们在适用性和传递性方面有显著差异。
• 函数依赖具有较强的约束力，即如果某个属性集可以确定另一个属性集，则这种确定性适用于任何子集。
• 多值依赖允许属性集有多个独立的值，但这种独立性不一定在属性集的所有子集中成立。
• 数据库设计时，理解并正确应用这些依赖关系对于减少数据冗余和避免更新异常至关重要

总结：

理解多值依赖的关键是识别属性间的关系不仅仅是一对一的（如函数依赖），而可以是一对多的。多值依赖考虑了这种一对多的关系，并通过进一步的规范化，将数据结构化成更高效、更少冗余的形式。

6.2.8 第四范式 (4NF)

定义 6.10 - 第四范式 (4NF) 的关系模式

一个关系模式 �<�,�>R<U,F> 处于第一范式 1��1NF，且对于 �R 的每一个非平凡多值依赖 �↠�X↠Y（�≠�Y=X），若 �X 包含一个键（码），则 �R 被认为处于第四范式 4��4NF。

4NF 的核心要点:

• 非平凡多值依赖: �↠�X↠Y 是非平凡的，若 �Y 不是 �X 的一部分，也不是由 �X 导出的其他属性。
• 关键性质: 4NF 限制了非平凡且非函数依赖的多值依赖的存在。
• 关系模式的优化: 4NF 目标是减少数据冗余，并避免多值依赖所导致的更新异常。

与 BCNF 的关系:

• 每个 4NF 的关系模式也一定是 BCNF，但反之不一定。
• BCNF 关注消除函数依赖的冗余，而 4NF 进一步消除非函数依赖的冗余。

例子: WSC 关系模式

• 关系模式 ���WSC 有非平凡的多值依赖 �↠�W↠S 和 �↠�W↠C。
• �W 不是码，实际的码是全键 (�,�,�)(W,S,C)。
• 尽管 ���WSC 可能是 BCNF，由于 �W 的多值依赖，它不满足 4NF。

规范化至 4NF:

• 分解: 将 ���WSC 分解为 ��(�,�)WS(W,S) 和 ��(�,�)WC(W,C) 来消除非平凡的多值依赖。
• 结果: 分解后的模式 ��WS 和 ��WC 都满足 4NF。

关于数据依赖:

• 函数依赖: 是特殊的多值依赖。
• 多值依赖: 是特殊的连接依赖。
• 进一步规范化: 考虑连接依赖可以进一步规范化至 5NF。

结语:

• 虽然此节不深入探讨连接依赖和 5NF，但理解函数依赖和多值依赖的关系是重要的。对于想深入了解的读者，推荐阅读专业书籍。

我的理解：

第四范式（4NF）是关系数据库范式之一，它建立在第一范式（1NF）的基础上，主要目的是进一步减少数据冗余和更新异常，特别是处理那些涉及到多值依赖的情况。下面我会解释关键概念和如何理解这一节的内容。

关键概念解释：

• 关系模式：是对数据库中表结构的描述，包括表中的列（属性）和这些列之间的关系（依赖关系）。

• 多值依赖：在关系模式中，如果属性Y的值依赖于属性X，而与其他属性无关，即使X不是唯一标识记录的键，那么这种依赖被称为多值依赖（用符号 �↠�X↠Y 表示）。多值依赖意味着如果确定了X的值，Y可以有多个独立的值。

• 非平凡多值依赖：如果Y不是X的子集，并且Y不完全由X决定，则存在非平凡多值依赖。

• 码（键）：一组属性，这组属性的组合可以唯一标识表中的一个记录。

如何理解：

• 4NF的定义：一个关系模式满足4NF，当且仅当它处于1NF，并且它的每一个非平凡多值依赖都是基于它的一个码。也就是说，4NF要求表内不能有基于非键属性集的非平凡多值依赖。

• 为什么需要4NF：非平凡多值依赖可能会导致数据冗余和更新异常。例如，如果一个仓库中有多个物品和多个保管员，而这些保管员和物品之间的关系是独立的，那么在没有规范化的表中可能会出现每个物品都重复列出所有保管员，反之亦然。这会造成大量冗余数据，且在添加、删除物品或保管员时可能会导致数据不一致。

• WSC案例：在WSC这个例子中，W代表仓库，S代表物品，C代表保管员。虽然WSC可能满足BCNF，但因为存在非平凡多值依赖（W对S和C），它不满足4NF。这意味着WSC关系模式中有过多的冗余信息，需要进一步的规范化。

• 如何达到4NF：要使WSC达到4NF，我们可以将其分解为两个关系模式：WS（仓库和物品）和WC（仓库和保管员）。这样，每个保管员和每种物品就不会再和所有的仓库条目重复关联，从而减少了数据冗余。

• 与BCNF和5NF的关系：如果一个关系模式只考虑函数依赖，BCNF是理想的目标。但当涉及到多值依赖时，需要达到4NF以进一步减少冗余。还有一个更高级的范式——第五范式（5NF），它处理更复杂的连接依赖关系，但这超出了本节的讨论范围。

总结：

理解4NF的关键是要明白多值依赖和如何它们会影响数据库的结构和完整性。通过将关系模式分解为满足4NF的多个模式，我们可以最大限度地减少数据的冗余和更新时可能出现的问题。

6.2.9 规范化小结

规范化概述

• 目的：解决关系模式的插入、删除异常和更新问题，减少数据冗余。
• 基本要求：满足第一范式（1NF），即每个字段都是不可分割的最小数据单位。

规范化原则

• 设计原则：“一事一地”，一个关系模式描述一个概念或实体。
• 过程：逐步消除不合适的数据依赖，实现关系模式的“分离”。
• 结果：规范化是将概念单一化的过程。

规范化的逐步深化

• 2NF：消除非主属性对码的部分函数依赖。
• 3NF：消除非主属性对码的传递函数依赖。
• BCNF：消除主属性对码的部分和传递函数依赖。
• 4NF：消除非平凡且非函数依赖的多值依赖。

规范化过程

• 分解：将低一级的关系模式分解为多个高一级的关系模式。
• 等价性问题：分解后的关系模式应与原关系模式等价，保留信息不丢失。
• 分解算法：分解的方法不唯一，算法的选择会影响分解结果的质量。

规范化的意义

• 避免异常：正确的规范化避免了插入、删除和更新操作引起的数据异常。
• 减少冗余：通过分解关系模式，减少数据冗余，提高数据一致性。

图解规范化

• 图6.8：提供了规范化过程的视觉概要，展示了从1NF到4NF各范式之间的转变和它们各自解决的问题。

笔记总结：

• 规范化是数据库设计中关键的过程，通过它能实现结构化和有序的数据存储。
• 理解每个范式解决的特定类型的数据依赖问题是理解规范化的关键。
• 分解必须谨慎进行，以确保数据完整性和查询效率。
• 规范化过程并非总是线性的；根据实际需要，有时可能需要在不同范式之间权衡。

总结：

重点

1. 函数依赖（FDs）理解：理解和识别函数依赖是规范化的基础。
2. 关键字和超键：分辨候选键、主键和超键的概念及其在规范化中的应用。
3. 范式理论：了解不同范式（1NF, 2NF, 3NF, BCNF等）的定义和要求。
4. 范式分解：掌握如何将关系模式分解为满足特定范式的较小关系模式，而不会丢失信息或产生错误。

难点

1. 理解和应用范式的标准：不同范式对函数依赖的要求有细微的差别，理解这些差别并正确应用到具体情况可以是复杂的。
2. 分解过程：分解为满足更高范式的过程可能涉及复杂的决策，尤其是在保持数据依赖和避免数据丢失方面。
3. 平衡规范化与性能：在实际应用中，完全规范化的数据库可能会影响性能，需要在规范化与查询效率之间找到平衡。

易错点

1. 部分函数依赖和传递函数依赖的混淆：特别是在2NF和3NF的区别上，学生常常混淆部分依赖和传递依赖。
2. 过度分解：在试图消除数据冗余时，有可能过度分解关系模式，导致查询效率低下。
3. 错误地识别候选键：有时可能会遗漏某些候选键或错误地将非候选键视为候选键，这将影响范式的判定。
4. BCNF与3NF的差异：在BCNF和3NF之间的区别是微妙的，但至关重要，这常常是理解难点和易错点。

在复习6.2规范化时，要确保掌握每个范式的定义和它们之间的差异，并且要通过练习多个例子来加深理解。同时，应该意识到在实际的数据库设计中，过分的规范化可能会带来性能上的折衷，因此需要根据具体情况做出合理的设计决策。