📄 一句话概括
实体是系统里需要保存的「对象」（名词），属性是对象的特征——实体将来变表，属性变列。从需求里挑名词、给名词列特征，就是数据建模的第一步。
📝 本节和前面几节的关系
5-4 攒下了需求清单，本节开始翻译：清单里的名词多半是实体，名词的特征是属性。5-6 再看实体和实体怎么挂钩——这张网画完就是 5-7 的 E-R 图。
一、两个词的定义
| 概念 | 是什么 | 将来变成 |
|---|---|---|
| 实体（Entity） | 要保存的一类对象：学生、书、订单 | 一张表 |
| 属性（Attribute） | 实体的特征：姓名、书名、金额 | 表里的一列 |
判断实体的小窍门：它有自己的「身份」，需要单独记住它。学生是实体（要记住每人）；「三年级」通常不是（只是学生的一个属性值）——除非系统还要管年级本身的信息。
二、从需求到实体的翻译
需求句：「学生选课，每门课有学分，考试有成绩。」
| 需求里的词 | 判定 |
|---|---|
| 学生 | 实体 ✅ |
| 课程 | 实体 ✅ |
| 学分 | 属性（课程的特征） |
| 成绩 | 危险！——它既不是学生的特征也不是课程的特征，而是「选了这门课」这件事的特征 → 关系属性（5-6 揭晓） |
三、找主键：给实体发身份证
每个实体要选一个能唯一认出每一条的属性当主键（4-12 的正主出场）：
- 学生 → 学号 ✅（姓名会重）
- 课程 → 课程编号 ✅
- 书 → ISBN ✅（书名会重）
没有天然编号？造一个自增 id（4-11 的用武之地）。
四、动手 Demo：给书评网站挑实体
从 5-4 的需求清单挑名词：用户（注册、昵称）、书（书名、ISBN）、书评（正文、评分、时间）。 注意「书评」也是实体——它不是书的属性，是用户对书做的事，要单独保存。三个实体、将来三张表（5-16 起验证）。
五、30 秒实验
拿手机通讯录练手：实体是「联系人」，属性有哪些？哪些属性有可能重复、不能当主键？（姓名、生日都可能重——所以通讯录给每人一个记录号。）
六、常见误区
- 「名词都是实体」：看它需不需要单独记住；只是特征值的名词是属性
- 「实体=一个人/一本书」：实体是一类对象；表里的一行才是「一个人」
- 「成绩是学生的属性」：一个学生多门课多个成绩，硬塞一列就得塞重复项——5-11 第一范式专门收拾这个
自测三问
1. 实体和属性将来分别变成什么？（表/列） 2. 判定实体的窍门？（有身份、需要单独记住的对象） 3. 成绩挂在学生还是课程上？（都不是——挂在「选课」这个关系上）- ☐ 下一节（5-6 关系、一对多、多对多、一对一-思考数据之间的关系）
相关笔记
- 需求定义-整理用户需求和使用目的 —— 上一节：原料采集
- PRIMARY KEY、主关键字、主键-使记录可以进行唯一识别 —— 给实体发身份证的机制
- 🗄️ 数据库基础 · 索引 —— 全课路线图