week 10 - Database: Normalisation

Normalization in Database Design

一、Characteristics of Good DB Designs

1. 数据库设计中，属性的数量应尽可能少，只保留支持企业数据需求的部分。

2. 具有密切逻辑关系的属性应在同一个关系中。

3. 降低冗余，每个属性仅表示一次，外键属性除外。

 Characteristics of good database design include minimal attributes necessary, logically related attributes grouped together, and minimal redundancy.

二、Normalisation

• 规范化是一种将数据重组为多个相关表的技术，以最小化数据冗余。

• Entity-Relationship (ER)建模适用于新建数据库；而规范化则用于改进已有不良设计的数据库。

 Normalization reorganizes data into related tables to minimize redundancy, while ER modeling helps design new databases.

三、数据冗余的影响

• 数据冗余不仅会 增加内存使用，还会引发 更新异常。

Data redundancy increases storage usage and leads to update anomalies

四、更新异常的三种类型

Update Anomalies

1. 插入异常（Insert Anomalies）

• 如果没有现有员工，无法添加新的分支机构。

• 原因：staffNo 是主键，必须有员工编号才能插入记录。

• 影响：容易导致数据输入错误，增加了维护难度。

2. 删除异常（Delete Anomalies）

• 删除某分支的最后一名员工时，分支机构的信息也会被删除。

• 例如：删除 John White 后，与分支 B005 相关的所有数据都消失了。

• 影响：可能丢失分支机构的重要数据。

3. 修改异常（Modification Anomalies）

• 修改分支机构的信息时，必须更新表中所有相关的记录。

• 例如：修改 B003 的地址，需要更新 163 Main St, Glasgow 的每一条记录。

• 影响：增加了出错的可能性和操作复杂度。

五、Re-organise Tables

• 通过观察数据表，找出属性之间的关系（功能依赖）

attribute relationships and functional dependencies

• 使用常识（Common sense）对数据进行拆分，但需谨慎。

六、功能依赖（Functional Dependency）

A method for finding relationships between attributes within a table

regroup attributes based on their context and split the big table.

1. 如果属性集A能唯一决定属性集B，则称B功能依赖于A（记作A → B）。

“If A and B are attribute sets of relation R, B is functionally 

dependent on A (denoted A → B), if each value of A in R is associated with exactly one value of B in R.

2. 在功能依赖中，A被称为决定因子（determinant）。

完全功能依赖与部分功能依赖

1. Full Functional Dependency

 B 依赖于 A，但不依赖于 A 的任何子集。

一个属性（或属性集）完全依赖于候选键，而不是依赖于候选键的子集。

 示例：staffNo → branchNo。

• 如果 A 是一个复合键，只有 A 的全部属性才能唯一确定 B，则 B 是完全函数依赖于 A。

2. Partial Functional Dependency

(1) 定义：

• 如果存在函数依赖 A → B，并且 A 的某些属性可以移除，但依赖关系仍然成立，那么 A → B 是部分函数依赖。

一个属性依赖于候选键的一个子集，而不是整个候选键。

(2) 核心概念：

• 部分函数依赖意味着某些不必要的属性可以从决定属性集中删除，而不会影响依赖关系的成立。

(3) 形式化描述：

• 存在一个适当的子集 C ⊆ A，使得 C → B。

示例：staffNo, sName → branchNo，这里 branchNo 仅依赖于 staffNo。

3. 决定因素（Determinant）的作用

• 完全函数依赖中的决定因素：

决定因素（Determinant）在完全函数依赖中会成为候选键（Candidate Key）。

• 意义：

当一个表根据完全函数依赖进行分解时，决定因素将成为新表的主键。

• 部分函数依赖中的决定因素：

决定因素会成为超级键（Super Key）。

4. FDs in Normalisation

（1）在数据库规范化中，我们只关注完全函数依赖（Full FDs）。

（2） 原因：

部分函数依赖（Partial FD）可能导致候选键变得冗长，当引用外键时，需要添加额外的列，这会增加复杂性。

 （3）示例：

一个 branchNo 就足以唯一标识分支，但如果引入 (branchNo, bAddress) 这样的组合键作为外键，Staff 表中就需要额外列存储 bAddress，显得冗余且不必要。

（4）结论：

 数据库规范化旨在消除这种冗余，简化表设计。

5. 关于 Determinants（决定因素）的探讨

（1）概念解析：

 决定因素（Determinants）是函数依赖中的关键部分，决定其他属性的值。

 一个决定因素可以是单个字段，也可以是多个字段的组合。

（2） M:1 或 1:1 关系：

如果观察 Staff 表和 Branch 表，可以发现决定因素和其他属性的关系是 M:1 或 1:1。

• M:1：多个记录可能关联到同一个值。例如：

多个员工可能属于同一个分支 branchNo。

 多个员工可能拥有相同的职位 position。

• 1:1：例如，每个 branchNo 唯一对应一个 bAddress。

6. ER 模型中的关系

• ER 模型（实体-关系模型）与规范化的联系：

M:1 关系在表之间通常通过外键表示。

 如果两个属性属于同一上下文，则合并为一个表；否则，它们会分成两个表并通过外键关联。

• 示例：

 branchNo 和 bAddress 在同一个上下文，因而合并为一个表。

 branchNo 和 staffNo 分属不同上下文，因此拆分成 Branch 和 Staff 表，通过外键关联。

关系型数据库的设计核心是处理表之间的关系。

• 数据库的名称“关系型”正是因为这种对于实体间关系的强大建模能力。

• 通过规范化，减少冗余，确保数据的一致性，并增强了关系建模的逻辑性。

7. Transitive Dependency

（1） 传递依赖的定义

• 如果关系中的三个属性A , B和C满足以下条件：

1.  A->B

2.  B->c

3.  A->C是通过B 间接成立的，而不是直接依赖；

• 那么C 就对A 构成了传递依赖。

(2) 约束条件：

 A不直接决定 B或 C。

这个限制是为了确保传递依赖的独立性，否则会出现冗余。

2. 传递依赖的识别与问题

• 依赖链的观察：

• 依赖链 暗示了 bAddress 的存在冗余。

• 问题：

• 如果 branchNo 的 bAddress 发生变化，StaffBranch 表的每一行记录都需要修改，导致更新异常（Update Anomaly）。

• 这种设计会造成数据冗余和一致性问题。

3. 规范化解决传递依赖

8. 为什么需要“限制条件”

9. FD 和 TD 的关系

1. 传递依赖是函数依赖的扩展：

• 所有的传递依赖都是函数依赖，但不是所有的函数依赖都是传递依赖。

• FD 描述的是直接依赖关系，而 TD 描述的是通过中间属性的间接依赖。

2. FD 和 TD 的作用：

• FD 是数据库设计的基础，主要用于描述直接的主键和属性之间的关系。

• TD 用于标识冗余和潜在的异常（如更新异常、删除异常），从而帮助分解表以提高规范化程度。

3. 规范化的影响：

• 第一范式（1NF）和第二范式（2NF）主要处理部分函数依赖和完全函数依赖。

• 第三范式（3NF）及更高级范式通过消除传递依赖，进一步优化表结构。

• 所有的完全函数依赖都是直接依赖。

七、Normal Forms

• 在关系型数据库中，所有表都应该拥有主键（Primary Key）或至少拥有候选键（Candidate Key）。

• 主键的作用：

1. 确保表中记录的唯一性。

2. 提供其他表通过外键（Foreign Key）引用的基础。

• 关系型数据库的核心思想：

• 实体（Entity）： 同一上下文中的属性集合形成一个表。

• 关系（Relation）： 通过外键连接不同的实体。

use FDs and TDs to redesign tables

1. 1NF

single values, not sets or composite objects

Problems With unnormalised Form (UNF) 

• 更新异常（Update Anomaly）：

修改一个集合值时，需要更新所有涉及该值的记录。例如，将 T1 改为 T10，需要更新所有包含 T1 的行。

• 删除异常（Deletion Anomaly）：

 删除某个值可能导致其他重要信息丢失。例如，删除 T4 可能导致丢失与模块 M3 的讲师信息。

• 插入异常（Insertion Anomaly）：

无法添加没有主键值的记录。例如，无法添加一个新的教材（Text）而不指定模块。

Normalise to 1NF

Method 1:扁平化表结构‘（flattening’ the table）

• 将集合值（如 T1, T2）展开为单一值，每行代表一个值。

• 为新表分配主键，确保每行唯一标识。

Method 2:分离重复组

• 将重复的数据（如 Texts）分离成单独的表，建立与主表的外键关系。

Problems in 1NF 

数据冗余：重复的信息可能仍然存在，例如部门和讲师的重复。

 更新异常：如修改 D1 和 L1 时，需要更新所有涉及行。

 删除异常：如删除模块 M3 的教材 T4，会导致丢失讲师 L2 的信息。

2. 2NF

在1NF基础上，所有非键属性完全依赖主键，避免部分功能依赖。

Problems in 2NF

3. 3NF

在2NF基础上，消除传递依赖。

不存在非主键属性对主键的传递依赖（Transitive Dependency）

在3NF中，非主键属性之间的依赖被移除，每个表的非主键属性只直接依赖于主键。

• 示例中的结果：

• 表 3NFa：Dept 直接依赖于 Lecturer。

• 表 3NFb：Lecturer 直接依赖于 Module。

• 两表之间没有间接依赖，因此满足3NF。

 有些依赖不是传递依赖

优点

• 消除了更新、插入和删除异常。

• 数据库设计更简洁高效。

Normalisation: Practice

• 1NF：消除重复数据组。

• 2NF：通过移除部分依赖，将属性分组。

• 3NF：通过移除传递依赖，将关系进一步分解。

SQL对规范化的支持

SQL 提供了强大的功能来辅助规范化过程，无论是创建新的符合规范化规则的表，还是对已有数据表进行规范化。

• 使用 CREATE TABLE 和 INSERT INTO SELECT 等命令，将非规范化的表分解为多个规范化表。