📄 一句话概括
概念模型落到库里:关系变外键、属性变字段——实测 4 张表 17 个字段、3 个外键,概念类与表一一对应。
📝 本节和前面几节的关系
9.9 画了概念模型,这一节看它落到数据库时长成什么样。
一、三样东西各自落到哪
概念类 → 表:一一对应,一个类一张表。 属性 → 字段:名字可以改(中文变英文),含义不能变。 关系 → 外键:1 对多时,外键放在【多】的那张表上。
二、实测:4 张表 17 个字段 3 个外键
readers 4 个字段、books 4 个、loans 5 个、fines 4 个——合计 17 个。 外键 3 个:loans.reader_id、loans.book_id、fines.loan_id。 这 3 个外键就是概念模型那 3 条关系的落地,一个不多一个不少。
三、为什么说【改表结构=改现实理解】
表里多一个字段,意味着你认为业务里多了一个要记的事实。 所以表难改,是因为理解难改——不是数据库不灵活。 这也是为什么 9.9 的关系必须先想清:外键放错位置,后续所有查询都要绕。
四、从表反推业务的三步
看表名 → 业务里有哪些名词被认真对待了。 看外键 → 哪些东西之间有数量关系、谁是主体。 看字段 → 这个业务认了哪些事实、忽略了哪些。 这三步能在一张陌生的库上,反推出它理解的现实。
五、动手 Demo:在业务应用程序中,数据结构反映现实世界
把 4 张表的字段列出来,标出哪些是外键。 数字段总数与外键总数,检查与概念模型的对应。
tables = {
"readers": ["id", "name", "card_no", "limit_n"],
"books": ["id", "title", "isbn", "on_shelf"],
"loans": ["id", "reader_id", "book_id", "out_date", "due_date"],
"fines": ["id", "loan_id", "amount", "paid"],
}
total = sum(len(v) for v in tables.values())
fks = sum(len([c for c in v if c.endswith("_id")]) for v in tables.values())
print(len(tables), total, fks) # 4 17 3
实跑输出:
--------------------------------------------------------------------
在业务应用程序中,数据结构反映现实世界
--------------------------------------------------------------------
概念模型落到数据库,**关系就变成外键,属性就变成字段**。实测:
表 字段数 外键
------------------------------------------
readers 4 —
books 4 —
loans 5 reader_id/book_id
fines 4 loan_id
表 4 张
字段合计 17 个
外键合计 3 个
概念类 → 表的对应 一一对应
**3 个外键就是概念模型那 3 条关系的落地**:借阅记录连着读者和书。
**所以【改表结构】其实是【改现实理解】**——表难改,是因为理解难改。
**这也是 9.10 那句【数据结构反映现实世界】的真正含义。**
实测:4 张表、17 个字段、3 个外键,与概念模型的 4 类 3 关系一一对应。 3 个外键就是那 3 条关系——1 对多时外键放在多的一侧。 改表结构其实是改现实理解,所以表难改,是因为理解难改。
30 秒实验
- 拿一张陌生的表,从表名、外键、字段反推它理解的业务。
- 检查你的库里有没有一个外键指向了错的一侧。
常见误区
- 以为表结构是技术细节。它是业务理解的落地。
- 把外键放在 1 的那一侧。1 对多时外键放多的一侧。
自测三问(点开对答案)
1. 概念模型三样各落到哪? —— 概念类→表,属性→字段,关系→外键(1 对多时放多的一侧)。 2. 实测数字是多少? —— 4 张表、17 个字段、3 个外键,与 4 类 3 关系一一对应。 3. 为什么改表结构很难? —— 因为改表就是改对现实的理解,不是数据库不灵活。- ☐ 9.11 嵌入式软件替代现实世界的工作
相关笔记
- 用概念模型表示图书馆系统的信息 — 上一阶段的产物
- 业务应用程序记录现实中的事情 — 字段从现实来
- 嵌入式软件替代现实世界的工作 — 换一类软件看
- 🧩 面向对象是怎样工作的 · 索引