📄 一句话概括
实体之间只有三种关系：一对多（最常见的班级↔学生）、多对多（要靠中间表拆解的学生↔课程）、一对一（一张表拆两半的场景）——认对关系形状，表才拆得对。
📝 本节和前面几节的关系
上一节挑出了实体，本节看实体之间怎么挂钩。这一节是本章技术的最高峰：多对多必须造中间表——5-18 书评网站的「表的定义、中间表」直接等着用。外键（4-13）从本节起有了设计学的身位。
一、三种关系形状
| 关系 | 例子 | 摆法 |
|---|---|---|
| 一对多 | 一个班级 : 多个学生 | 「多」那方塞外键 class_id |
| 多对多 | 学生 ↔ 课程（互选） | 造中间表 选课(学号, 课程号, 成绩) |
| 一对一 | 人 ↔ 指纹 | 任意一方塞外键 + UNIQUE，或直接并一表 |
二、关系属性挂在中间表上
5-5 埋的问题在此揭晓：成绩既不是学生的也不是课程的，是「选课」这件事的属性——所以它住在中间表里：
students(学号, 姓名) ← 学生实体
courses(课程号, 课程名, 学分) ← 课程实体
选课(学号, 课程号, 成绩) ← 中间表：两实体各出主键 + 关系属性
口诀：关系自己有数据时，关系就是一张表。
三、多对多的火眼金睛
听到这些说法立刻警觉中间表：
- 「一个用户能写多篇评论，一篇评论只属于一个用户」→ 一对多（不用中间表）
- 「学生选多门课，课程被多个学生选」→ 多对多（要中间表）
- 「订单里的商品」→ 一订单多商品、一商品进多订单 → 多对多，中间表＝订单明细
四、动手 Demo：书评网站的关系盘点
- 用户 ↔ 书评：一人多评、一评一人 → 一对多
- 书 ↔ 书评：一书多评、一评一书 → 一对多
- 用户 ↔ 书（谁读过哪些书）：互为多 → 若需求要记「读过」，造中间表 阅读(用户id, 书id, 时间)
用户和书本身不直接挂钩——它们靠书评间接关联，这也是书评系统不需要「用户-书」中间表的原因：书评表本身就是那个中间角色。
五、30 秒实验
判断关系：①作者↔书（一书多作者、一作者多书）②配偶↔配偶 ③仓库↔货架（一货架只属一仓、一仓多货架）。答案：多对多（中间表＝著作表）；一对一；一对多。
六、常见误区
- 「多对多在两张表里互相塞外键就行」：不行——一列装不下多个值（5-11 第一范式的铁律）；必须第三张表
- 「一对一关系最好合并一张表」：多数情况对；拆开只为主键列太多、或部分字段访问频次悬殊
自测三问
1. 三种关系各举一例？（班级-学生/学生-课程/人-指纹） 2. 多对多怎么落表？（中间表：双方主键＋关系属性） 3. 成绩住在哪张表？（选课中间表——关系属性）- ☐ 下一节（5-7 E-R图-使用图表表现数据之间的关系）
相关笔记
- 实体、属性-思考需要保存的数据 —— 上一节：实体挑好了
- FOREIGN KEY、外键-与其他表进行关联 —— 关系落地的机制
- JOIN-合并多个表获取数据 —— 查询侧沿着关系走
- 🗄️ 数据库基础 · 索引 —— 全课路线图