一、三样东西：类、属性、关系

概念类：业务里的名词（读者、书、借阅记录、罚款）——4 个。 属性：每个概念类要记住的信息——合计 11 个。 关系：类与类之间的数量关系——3 条。 方法一个都不写，技术类（仓储、服务）一个都不出现。

二、关系是概念模型里最重要的一行

实测三条：读者 1 对多借阅记录、书 1 对多借阅记录、借阅记录 1 对 1 罚款。 它决定了将来外键放在哪张表上——1 对多时外键放在【多】的那一侧。 关系写错，表结构必然错，而且改起来比重画模型贵十倍。

三、为什么不用写方法

这个阶段还没决定【怎么做】——写方法等于提前锁定实现。 只有属性，业务方就能看懂：他们看的是【记住了哪些信息】。 技术类也不出现：仓储、服务这些是设计阶段的产物。

四、判断模型好坏的两条

一个技术词都没有 → 说明没跑到设计阶段去。 每条关系都能说出 1 对多还是 1 对 1 → 说明关系想清了，不是画着好看。 这两条都过了，模型就能交给设计阶段用了。

五、动手 Demo：用概念模型表示图书馆系统的信息

列 4 个概念类的属性，再写它们之间的关系。 数属性总数，并确认没有方法、没有技术类。

model = [("读者", "姓名／证号／限额", "－"),
         ("书", "书名／ISBN／在架", "－"),
         ("借阅记录", "借出日／应还日／实际还日", "读者 1 对多，书 1 对多"),
         ("罚款", "金额／是否已缴", "借阅记录 1 对 1")]

attrs = sum(len(r[1].split("／")) for r in model)
print(len(model), attrs, 3, 0)   # 4 11 3 0

实跑输出：

--------------------------------------------------------------------
用概念模型表示图书馆系统的信息
--------------------------------------------------------------------

  概念模型 ＝ **概念类 ＋ 属性 ＋ 关系**，不写方法。实测：

  概念类       属性                         关系
  -----------------------------------------------------------------
  读者         姓名／证号／限额             －
  书           书名／ISBN／在架             －
  借阅记录     借出日／应还日／实际还日     读者 1 对多，书 1 对多
  罚款         金额／是否已缴               借阅记录 1 对 1

      概念类                      4 个
      属性合计                    11 个
      关系                        3 条
      方法                        0 个（概念模型不写）
      出现技术类（仓储／服务等）  0 个

  **注意【读者 1 对多】这条关系**——它是概念模型里最重要的一行，
  **因为它决定了将来表里的外键放在哪。**
  **概念模型里一个技术词都不该有**：出现了，说明已经跑到设计阶段去了。

实测：4 个概念类、11 个属性、3 条关系、方法 0 个、技术类 0 个。 关系里最重要的一句是【1 对多】——它决定外键放在哪一侧。 出现技术词就说明跑偏了：那是设计阶段的东西。

30 秒实验

1. 给你的概念模型逐条关系标上 1 对 1 还是 1 对多。
2. 检查模型里有没有出现仓储、服务这类技术词。

常见误区

1. 以为概念模型也该写方法。写了就等于提前锁定实现。
2. 把关系画成一条线了事。不说清 1 对几，外键就没法定。

• ☐ 9.10 在业务应用程序中，数据结构反映现实世界

相关笔记

• 使用用例图来表示图书馆业务 — 上一阶段的产物
• UML的使用方法之二：表示归纳整理法的成果 — 概念类图的通用说明
• 在业务应用程序中，数据结构反映现实世界 — 落到表结构
• 🧩 面向对象是怎样工作的 · 索引