Database design and normalisation techniques

欢迎来到数据库设计！

你有试过在乱七八糟的抽屉里找某只特定的袜子吗？那种感觉真的很让人挫折，对吧？设计数据库就像整理那个抽屉一样。如果你只是随手把东西丢进去，你永远找不到需要的东西，最后甚至会发现剩下三只左脚袜子，却一只右脚的都没有。在这章节中，我们将学习如何利用规范化 (Normalization)，设计出整洁、高效且不出错的数据库。别担心，即使一开始看起来好像有很多「数学」，其实它只是利用逻辑来让一切保持井然有序！

第一步：蓝图 (实体关系模型)

在建立数据库之前，我们需要一个规划。这被称为数据模型 (Data Model)。你可以把它想象成在盖房子砖块砌上去之前的建筑图纸。

实体与属性

实体 (Entity) 就是我们想要存储数据的「对象」（例如：学生 (Student)、书本 (Book) 或 汽车 (Car)）。每个实体都有属性 (Attributes)，也就是具体的细节（例如：学生姓名 (StudentName) 或 出生日期 (DateOfBirth)）。

实体关系 (ER) 图

我们使用图表来显示这些对象之间的关联。例如，一个顾客 (Customer) 可以下多个订单 (Orders)。在考试中，你可能会被要求用简单的方框和线条画出这些关系。
记忆小撇步：永远问自己「一个『A』能否拥有多个『B』？」来找出它们的关系。

实体描述

为了清楚地写下设计，我们使用标准格式：写下实体名称，然后在括号中列出属性。我们将主键 (Primary Key)（唯一的标识码）加上下划线。
示例：Student(StudentID, FirstName, LastName, CourseID)

重点摘要：良好的设计始于一个清晰的蓝图，说明我们正在收集什么数据，以及系统中不同的「对象」是如何彼此链接的。

第二步：关系数据库基础

关系数据库 (Relational Database) 是由一组相互链接的表格所组成的。为了让这些链接发挥作用，我们使用特殊的「键 (Keys)」：

1. 主键 (Primary Key)：表格中每笔记录的唯一标识码。想象成你的身份证号码或学生编号——没有两个人会拥有相同的号码。
2. 复合主键 (Composite Primary Key)：有时候，单一字段不足以成为唯一标识码。当我们使用两个或多个字段组合来建立唯一 ID 时，这就称为复合主键。例如，在「课程 (Lesson)」表格中，教室号码 (RoomNumber) 和 课节编号 (PeriodNumber) 组合起来可能就是唯一主键。
3. 外键 (Foreign Key)：这是「桥梁」。它是某个表格中的一列，且该字段是另一个表格的主键。这就是我们如何将学生 (Student) 链接到其老师 (Teacher) 的方式。

快速回顾箱：
- 主键 (Primary Key)：当前表格的唯一标识 ID。
- 外键 (Foreign Key)：链接到不同表格中的主键。
- 属性 (Attribute)：表格中的一列/标题。

第三步：什么是规范化？

规范化 (Normalization) 是整理数据库的过程。我们这样做主要有两个原因：
- 消除数据冗余 (Data Redundancy)（在多个地方存储相同的信息）。
- 维持数据完整性 (Data Integrity)（确保数据准确且易于更新）。

现实示例：如果某位学生更改了电话号码，而你在五个不同的表格中都记录了它，你就必须更新五次。如果你漏掉了一次，你的数据就错了！规范化确保你只在一个地方存储该号码。

你知道吗？规范化是由 E.F. Codd 在 1970 年代发明的。他建立了一套称为「范式 (Normal Forms)」的规则，以确保数据库在逻辑上是完美的。

第四步：规范化的三个层次

要让数据库达到第三范式 (3NF)，我们必须经历三个阶段。学生通常觉得这有点困难，但只要遵守这些简单规则即可：

第一范式 (1NF)

如果表格中没有重复的属性组，该表格就符合 1NF。这意味着表格中的每个「单元格」必须仅包含单个值（必须是原子性 (Atomic) 的）。
常见错误：有一列名为「科目」，然后把「数学、物理、计算机科学」全部塞在同一个格子里。在 1NF 中，这些必须是分开的记录。

第二范式 (2NF)

要符合 2NF，表格必须先符合 1NF。接着，你必须移除部分函数依赖 (Partial Dependencies)。
这仅适用于你拥有复合主键的情况。每个非键属性必须依赖于整个复合主键，而不是只依赖其中一部分。
示例：如果你的主键是 (StudentID, CourseID)，而你有一列是 学生地址 (StudentAddress)，该地址仅依赖于 StudentID。它与 CourseID 无关。这就是部分函数依赖！你必须将地址移动到独立的 Student 表格中。

第三范式 (3NF)

要符合 3NF，表格必须先符合 2NF。接着，你必须移除传递依赖 (Transitive Dependencies)。
这意味着「没有非键属性应该依赖于另一个非键属性」。所有属性应仅依赖于主键。
类比：想象一个表格 FootballTeam(PlayerID, Name, ClubName, ClubManager)。其中的 ClubManager 是依赖于 ClubName，而不是直接依赖于 PlayerID。这就是传递依赖。你应该将球队信息移动到它自己的表格中。

黄金口诀：
要记住 3NF 的规则，数据库专家常说：「数据必须依赖于主键 (1NF)，依赖于整个主键 (2NF)，且除了主键之外不依赖其他 (3NF)。」

重点摘要：当你达到 3NF 时，表格中的每一项信息都严格与该表格的主键相关，除此之外别无其他。这会让你的数据库精简、快速且可靠。

快速总结检查清单

- 1NF：单元格中没有列表。数据具有原子性。
- 2NF：没有部分函数依赖（留意复合主键！）。
- 3NF：没有传递依赖（非键属性不应依赖于其他非键属性）。
- 目标：最小化重复并保持数据准确性。

最后鼓励：规范化需要练习！如果你觉得很吃力，试着把表格画在纸上，并圈出哪些信息片段是「属于」哪个键的。你很快就会掌握诀窍了！