📄 一句话概括
对着需求清单挑实体、列属性、认关系：用户、书、书评三实体浮出水面，两对一对多关系定型——书评既是实体又是「桥」，这是本例最妙的一步。
📝 本节和前面几节的关系
5-5（挑实体）和 5-6（认关系）的手法在此实战首秀。产出物：三实体清单＋关系判定，下一步 5-18 直接翻成表定义。
一、名词筛选：谁够格当实体
| 名词 | 判定 | 理由 |
|---|---|---|
| 用户 | 实体 ✅ | 要单独记住（登录身份） |
| 书 | 实体 ✅ | 要单独记住（上架信息） |
| 书评 | 实体 ✅（弱实体） | 有自己的属性（评分/正文/时间），且连接用户和书 |
| 昵称、ISBN、评分 | 属性 | 各归各主 |
| 平均分 | 不存 | 可算出来的数据不落地（否则改动两处、必然穿帮——1NF 后的「一份事实」原则） |
二、属性分配
- 用户：昵称、邮箱、密码（主键候选：邮箱天然唯一）
- 书：书名、ISBN、作者、出版日（主键候选：ISBN 天然唯一 ✅）
- 书评：评分、正文、评论时间（无天然主键 → 造自增 id，4-11 上场）
三、关系判定
| 关系 | 形状 | 判定理由 |
|---|---|---|
| 用户—书评 | 1 : n | 一人多评、一评一人 |
| 书—书评 | 1 : n | 一书多评、一评一书 |
| 用户—书 | 无直接关系 | 靠书评间接相连——不造多余中间表 |
E-R 图（5-7 的画法）：
┌──────┐ 1 n ┌──────┐ n 1 ┌──────┐
│ 用户 │────◇写◇──│ 书评 │──◇评◇────│ 书 │
└──────┘ └──────┘ └──────┘
四、动手 Demo：反例教学
假如把书评当「书的属性」塞进 books 表：books(isbn, title, 评1, 分1, 评2, 分2, ...)——重复列（1NF 违规）＋ 书评数上限天定。一路规范化的检查点全部亮红灯，反着推一遍更能信服三实体方案。
五、30 秒实验
追问需求第 6 条「必须登录才能评」：哪个实体承担这个约束？（书评表 user_id NOT NULL——设计决策此刻就要定，5-19 写成约束。）
六、常见误区
- 「书评挂书下面就行」：书评还连着用户；两对关系决定它是独立实体
- 「平均分存一列更方便」：可算数据存库＝一份事实存两处，改分忘改和分，报表穿帮
自测三问
1. 三个实体各自的主键方案？（邮箱或自增 id / ISBN / 自增 id） 2. 用户和书为什么不直接连？（靠书评间接关联，中间表多余） 3. 为什么平均分不存？（可算数据不落地——一份事实只存一处）- ☐ 下一节（5-18 表的定义、中间表-书评网站表格设计的示例3-确定需要使用的表）
相关笔记
- 实体、属性-思考需要保存的数据 —— 手法出处
- 表的定义、中间表-书评网站表格设计的示例3-确定需要使用的表 —— 下一节：翻成表
- 🗄️ 数据库基础 · 索引 —— 全课路线图