📄 一句话概括
实体翻成表：users / books / reviews 三张表定案——一对多关系靠外键直连，本例不需要额外中间表，因为书评自己就是那座桥。同时用 1NF~3NF 全体检一遍。
📝 本节和前面几节的关系
5-17 挑好了实体和关系，本节翻成逻辑层的表清单（只列表名/列名/主外键，不配类型——那是 5-19 的事）。本节也回答了一个常见疑问：什么时候才需要中间表？
一、表清单（逻辑模型）
users (user_id PK, nickname, email, password)
books (isbn PK, title, author, published)
reviews (review_id PK, user_id FK→users, isbn FK→books, score, body, created_at)
外键落位规则：一对多关系，外键永远塞在「多」的那一方——书评是两对关系里的「多」，所以它揣着两把外键。
二、中间表什么时候才需要
| 情形 | 结构 |
|---|---|
| 关系只是「连一下」、无附加数据 | 一对多直连即可（本例） |
| 多对多、或关系自带属性 | 造中间表（学生选课、订单明细） |
假想需求升级：「用户想标记读过某书（不写评）」——用户↔书变成多对多，这时才加第四张表 reads(user_id, isbn, read_at)。需求变了结构才变，不提前造空表。
三、三范式体检
- 1NF：每格一值 ✅（书评独立成表，没有评1/评2）
- 2NF：单列主键，无部分依赖 ✅
- 3NF：reviews 里没有「非主键抱团」（书名不在评论里抄）✅——书的信息只存 books 一处
四、动手 Demo：画关系连线图
users ──1:n── reviews ──n:1── books
(用户) (书评=桥) (书)
外键：reviews.user_id → users.user_id
reviews.isbn → books.isbn
三表两外键——对照 5-16 的终点图，逻辑层已完全对齐，只差配类型和约束。
五、30 秒实验
若需求要求「评论可以修改」，reviews 要加什么列？（updated_at 修改时间——5-4 说的「异常流程长出列」的实证。）
六、常见误区
- 「一对多也要中间表」：不用；外键落在多方即可，中间表是多对多和关系属性的专属
- 「表定完就开始 CREATE TABLE」：还差 5-19 的类型/约束/属性——跳步建出来的表，回头改是 5-1 说的伤筋动骨
自测三问
1. 外键塞在关系哪一方？（「多」的那一方） 2. 本例为什么不需要中间表？（书评自己承担了桥的角色；两对关系都是一对多） 3. 什么需求出现才加中间表？（用户↔书多对多时——比如标记「读过」）- ☐ 下一节（5-19 确定数据类型、约束条件、属性-书评网站表格设计的示例4-排列表和列）
相关笔记
- 关系、一对多、多对多、一对一-思考数据之间的关系 —— 中间表判据的出处
- 确定数据类型、约束条件、属性-书评网站表格设计的示例4-排列表和列 —— 下一节：收官
- 🗄️ 数据库基础 · 索引 —— 全课路线图