单元 4：关系型数据库概念学习笔记
你好，未来的 IT 专家！欢迎来到精彩的数据库世界。本章对于理解现代企业如何管理海量信息至关重要——从你们学校的学生名册，到 Netflix 和亚马逊这样的大型服务平台。如果这些内容看起来有些技术性，请不要担心；我们将用简单的类比来拆解每一个概念，确保你能够自信地掌握这些核心知识点。
我们这里的目标不仅是了解什么是数据库，还要理解不同的信息片段是如何相互关联的——这就是“关系型”的含义所在！
第 1 节：关系型数据库的核心构建模块
可以将数据库想象成一个超级规整的数字档案柜。我们使用特定的结构来高效地存储数据。
1.1 表、记录和字段
关系型数据库管理系统 (RDBMS) 以二维结构存储数据，这种结构被称为表 (Table)（有时也称为关系）。
- 表 (Relation/Table)： 这是存储特定类型信息的主要结构，例如“客户”或“产品”。（类比：一个专门用于某个主题的电子表格。）
- 记录 (Tuple/Row)： 表中的单个完整条目。它包含了某一个项目或人员的所有数据。（类比：电子表格中的一行，包含了该特定客户的所有详细信息。）
- 字段 (Attribute/Column)： 表中的单个信息类别。（类比：列标题，例如“名字”、“地址”或“订单日期”。）
给学习遇到困难的同学的小贴士：
如果你看到一个表，请记住：
行 (Rows) = Records (记录)
列 (Columns) = Categories (字段/类别)
第 2 节：键 (Key) 的威力
键至关重要！它们是特殊的字段（或字段组合），用于唯一标识记录并建立表之间的链接。
2.1 主键 (Primary Key, PK)
主键 (PK) 是表中每条记录的唯一标识符。
- 它必须唯一——任何两条记录都不能拥有相同的 PK 值。
- 它不能为 NULL（它必须始终有值）。
- 示例： 在“学生”表中，学生 ID 号通常就是主键。
记忆辅助： Primary Key 就像你的 Passport Key（护照钥匙）——它唯一地识别了你！
2.2 候选键 (Candidate Key)
候选键是任何可能作为主键的字段（或字段组合），因为它满足唯一性标准。一旦你选择了一个候选键作为主键，其他的候选键就变成了候选键的替代键 (Alternate Keys)。
示例： 在“员工”表中，“员工 ID”和“国民保险号”可能都是唯一的。两者都是候选键。如果你选择“员工 ID”作为主键，那么国民保险号就是替代键。
2.3 外键 (Foreign Key, FK)
外键 (FK) 是一个表中的字段，它引用了另一个表中的主键。外键是建立关系的基础构建模块。
- 它充当了两个表之间的链接或桥梁。
- 外键字段在它自己的表中不必是唯一的（它通常会重复）。
- 它允许我们在不重复存储数据的情况下查找详细信息。
示例： 如果我们有一个“客户”表（以客户 ID 为主键）和一个“订单”表，“订单”表将包含客户 ID。在“订单”表中，这个客户 ID 字段就是外键。
关键要点： 主键确保表内部的唯一性。外键创建表之间的链接。
第 3 节：连接数据——关系
关系定义了表 A 中的记录如何与表 B 中的记录相关联。你必须掌握三种主要类型：
3.1 一对一 (1:1)
表 A 中的一条记录与表 B 中的一条记录完全对应，反之亦然。
- 使用场景： 这种情况很少见，通常用于将极其敏感或大量的数据分离到一个扩展表中。
- 示例： 一名员工对应一套唯一的安全访问权限。
3.2 一对多 (1:M)
表 A 中的一条记录可以与表 B 中的多条记录相关联，但表 B 中的每条记录只能与表 A 中的一条记录相关联。这是最常见的关系类型。
- 链接总是通过将“一”侧的主键放入“多”侧作为外键来实现的。
- 示例： 一个部门（表 A）有许多员工（表 B）。部门 ID (PK) 被放入员工表中作为外键 (FK)。
3.3 多对多 (M:M)
表 A 中的一条记录可以与表 B 中的多条记录相关联，且表 B 中的一条记录也可以与表 A 中的多条记录相关联。
- 示例： 许多学生可以选修许多课程。
- 关键点： 多对多关系不能在关系型数据库管理系统 (RDBMS) 中直接实现。
- 解决方案： 你必须通过创建一个第三个表来解决多对多关系，这被称为联结表 (Junction Table)（或链接/中间表）。
解决 M:M 的步骤：
- 创建一个新的联结表（例如，“选课表”）。
- 从第一个表中获取主键（例如，StudentID）。这在联结表中成为外键。
- 从第二个表中获取主键（例如，CourseID）。这在联结表中也成为外键。
- 联结表的主键通常是这两个外键的组合（即复合主键 (Composite Key)）。
现在，你有两个指向联结表的一对多关系，从而有效地解决了多对多问题！
关键要点： 一对多 (1:M) 是关系型设计的核心。多对多 (M:M) 总是需要一个联结表。
第 4 节：确保数据质量——参照完整性
参照完整性 (Referential Integrity) 是一套确保表之间关系一致且有效的规则。简单来说，它确保你的外键始终引用一个现有的主键。
4.1 规则
如果表 B 包含引用表 A 的外键，则表 B 中外键的每个值要么必须与表 A 中主键的值匹配，要么外键值必须为 NULL（空）。
4.2 为什么这很重要？
如果违反了参照完整性，你就会产生孤儿记录 (Orphan Records)——即无法链接到任何地方的数据。（想象一下，如果订单记录链接到一个不存在的客户 ID。你就不知道该把发票寄给谁了！）
4.3 删除/更新时的操作
RDBMS 系统提供了在记录发生更改时维持完整性的规则：
- 限制 (Restrict)： 如果存在对应的外键记录，则禁止删除或更新主键。（最安全的选项）。
- 级联 (Cascade)： 如果父表主键被删除或更新，子表中的对应外键记录也会被相应删除或更新。（需谨慎使用！）。
- 置空 (Set NULL)： 如果父表主键被删除或更新，子记录中对应的外键字段会被设为 NULL。
你知道吗？ 强制执行参照完整性是数据库自动检查数据一致性的方式，这能节省大量时间并防止错误！
第 5 节：效率与组织——范式化 (Normalisation)
在进行范式化之前，我们必须理解它所解决的问题：
- 数据冗余： 多次存储相同的数据（例如，在每个员工旁边存储完整的部门名称）。
- 更新异常： 如果需要更新冗余数据，你必须在所有地方进行更新。如果你漏掉了一个，数据就会变得不一致。
- 插入异常： 在雇佣员工之前，你可能无法插入有关新部门的数据。
- 删除异常： 删除部门中的最后一名员工会意外删除有关该部门的所有信息。
范式化 (Normalisation) 是将关系型数据库按阶段（范式）进行结构化的过程，旨在减少数据冗余并提高数据完整性。
5.1 第一范式 (1NF)
如果满足以下条件，表即处于 1NF：
- 拥有主键。
- 没有重复的数据组（例如：有三列：Item1, Item2, Item3）。
- 所有属性都是原子性的（不可再分）。（示例：“地址”字段应拆分为“街道”、“城市”、“邮编”等，而不是作为一个大块存储。）
规则： 一个单元格应仅包含一个值。
5.2 第二范式 (2NF)
如果满足以下条件，表即处于 2NF：
- 它已经处于 1NF。
- 所有非主键属性必须完全依赖于整个主键。
这仅在拥有复合主键（由两个或多个字段组成的主键）时才重要。
需要避免的常见错误： 如果你有一个复合主键（StudentID, CourseID），并且存储了学生姓名。学生姓名只依赖于 StudentID，而不是 StudentID + CourseID 的组合。这被称为部分依赖 (Partial Dependency)。为了修复它，你需要将学生姓名移动到单独的“学生”表中。
5.3 第三范式 (3NF)
如果满足以下条件，表即处于 3NF：
- 它已经处于 2NF。
- 没有传递依赖 (Transitive Dependencies)。
当一个非主键属性依赖于另一个非主键属性时，就会存在传递依赖。
示例：
| PK | 非主键 | 非主键 |
|---|---|---|
| EmployeeID | DepartmentID | DepartmentName |
在这里，DepartmentName 依赖于 DepartmentID，而 DepartmentID 并非主键。这就是传递依赖。我们通过将这种依赖关系（DepartmentID, DepartmentName）移动到其自己的“部门”表中来修复它。
别慌！ 3NF 的简单理解是：每个非主键字段只能依赖于主键，且是完整的主键，除此之外不能依赖任何东西。
关键要点： 范式化就是将一个庞大、低效的表拆解为若干个更小、高效且相互关联的表。
快速回顾框：关系型数据库精华
- RDBMS： 管理链接的表（关系）。
- PK： 唯一标识符（不能为 NULL）。
- FK： 通过引用另一个表的主键来链接表。
- 1:M： 最常见的链接类型。
- M:M： 必须使用联结表来解决。
- 参照完整性： 确保外键值与现有的主键值匹配。
- 3NF： 优秀设计的终极目标（无冗余，无传递依赖）。
你已经掌握了关系型数据库的核心概念！回去复习一下各种键的作用和范式化步骤——它们是本单元在考试中取得成功的关键。