📄 一句话概括
实战四连开工：先把书评网站的需求清单列全，并亮出最终成品图——先看终点再走路，接下来三节就是把这张图从需求一步步推出来。
📝 本节和前面几节的关系
前面 5-4~5-15 学的全套工序（需求→实体→关系→E-R 图→范式→类型→命名），本节起在书评网站上完整走一遍。本节＝原料（需求）＋终点（成品示意图）；5-17 挑实体、5-18 定表、5-19 配列。
一、需求清单（听/看/追的产出）
书评网站要做什么：
- 用户能注册（昵称、邮箱、密码）
- 用户能写书评：给书打 0~10 分＋写正文
- 用户能浏览：看某书的全部评论、算平均分
- 用户能查人：看某用户写过的全部书评
- 管理员能上架书（书名、ISBN、作者、出版日）
- 追问异常流：评论能改吗？（保留修改时间）能匿名吗？（必须登录才能评）
二、终点预览：最终成品（5-19 完成时长这样）
users books
┌───────────────────┐ ┌──────────────────┐
│ user_id INT PK│ │ isbn CHAR(13) PK│
│ nickname VARCHAR(20) NOT NULL │ title VARCHAR(50) NOT NULL
│ email VARCHAR(50) NOT NULL UNIQUE │ author VARCHAR(30)
│ password VARCHAR(60) NOT NULL │ published DATE
└───────────────────┘ └──────────────────┘
│ 1 │ 1
│ │
│ n n │
reviews (user_id FK, isbn FK)
┌──────────────────────────────┐
│ review_id INT PK (AUTO_INCREMENT) │
│ user_id INT FK / isbn CHAR(13) FK │
│ score DECIMAL(3,1) NOT NULL │
│ body TEXT / created_at DATETIME │
└──────────────────────────────┘
三张表、两个一对多：用户 1:n 书评、书 1:n 书评——书评站在中间当「桥」。
三、为什么先给终点
设计是有方向的手艺：知道终局（三表结构），回看每一节工序就明白它在推哪一步——学习效率翻倍。5-17~5-19 会逐步「逼近」这张图，你可以随时对照。
四、动手 Demo：把需求转成动词-名词对
每条需求拆成「动作 + 涉及的数据」：
| 需求 | 动词 | 名词（数据线索） |
|---|---|---|
| 注册 | 注册 | 用户/昵称/邮箱/密码 |
| 写书评 | 打分、写正文 | 书/评分/正文 |
| 算平均分 | 聚合 | 书/评分 |
| 查人的评论 | 查询 | 用户/书评/时间 |
名词堆里挑实体，动作堆里挑功能——下一节正式挑。
五、30 秒实验
给清单补一条：作者重复出现在多本书（同一作者多本著作）——要不要把作者升格成实体？（本书示例不升格：作者只是书的属性字符串；要按作者聚合检索时再升级——设计是需求驱动的。）
六、常见误区
- 「需求一大就糊涂」：拆成「动词-名词对」清单，实体和功能自动浮出
- 「先建表再补需求」：顺序反了就是 5-3 说的「问题凑工具」
自测三问
1. 实战四连的路线？（需求→实体→表→列） 2. 书评网站几对一对多？（用户→书评、书→书评） 3. 为什么要先看成品图？（知道每步工序在推什么，学习与评审都更快）- ☐ 下一节（5-17 提取实体和属性-书评网站表格设计的示例2-理解数据之间的关系）
相关笔记
- 需求定义-整理用户需求和使用目的 —— 本节用的采集法出处
- 提取实体和属性-书评网站表格设计的示例2-理解数据之间的关系 —— 下一节：挑实体
- 🗄️ 数据库基础 · 索引 —— 全课路线图