3. 从业务流程到概念模型：用“名词法”和“动词法”提取核心实体与关系
很多刚入行的同事问我：“数据模型到底怎么开始？”
我的回答通常很简单——别急着画表，先看懂业务在干什么。
概念模型是数据架构的第一张蓝图。它不关心字段类型，不关心主键设计，只关心两件事：业务里有哪些“东西”，以及这些“东西”之间怎么关联。
我个人习惯用两种方法从业务流程里“挖”出这些东西——名词法和动词法。说白了，一个帮你找实体，一个帮你找关系。
3.1 名词法：从业务描述中抓出核心实体
什么是实体？
实体就是业务里那些独立存在、可以被识别、有业务意义的对象。比如客户、订单、产品、仓库。
名词法的操作很简单：
拿一段真实的业务流程描述，把里面的名词全部圈出来，然后筛选。
举个例子，这是一段典型的电商下单流程：
“顾客在网站上浏览商品，将商品加入购物车。确认后提交订单，系统扣减库存，生成发货单。仓库人员根据发货单拣货、打包，交由物流公司配送。顾客收到商品后可以确认收货并评价。”圈出名词：
- 顾客、网站、商品、购物车、订单、库存、发货单、仓库人员、物流公司、收货、评价
然后做筛选——去掉那些只是状态或动作的名词，比如“收货”其实是动作，“网站”只是渠道。剩下的是：
| 候选名词 | 是否实体 | 理由 |
|---|---|---|
| 顾客 | ✅ 是 | 独立业务主体，有属性（姓名、地址） |
| 商品 | ✅ 是 | 核心业务对象，有SKU、价格 |
| 购物车 | ⚠️ 视情况 | 如果只是临时容器，可以归为订单的一部分 |
| 订单 | ✅ 是 | 交易核心，有状态、金额 |
| 库存 | ✅ 是 | 商品的数量维度，可独立管理 |
| 发货单 | ✅ 是 | 物流环节的核心单据 |
| 物流公司 | ✅ 是 | 外部合作伙伴，有独立属性 |
| 评价 | ✅ 是 | 顾客对商品的反馈记录 |
3.2 动词法：从业务动作中提炼实体关系
实体找到了，它们之间怎么连？
这时候看动词。
动词法就是：把业务流程里的动作找出来，每个动作往往对应一个关系。
还是刚才那段流程：
- “顾客浏览商品” → 顾客和商品之间是浏览关系
- “顾客提交订单” → 顾客和订单之间是创建关系
- “订单扣减库存” → 订单和库存之间是影响关系
- “仓库人员生成发货单” → 发货单和订单之间是关联关系
- “物流公司配送发货单” → 物流公司和发货单之间是承运关系
- “顾客评价商品” → 顾客和商品之间是评价关系
把这些动词翻译成数据模型里的关系，通常就是：
| 源实体 | 动词 | 目标实体 | 关系类型 | 基数 |
|---|---|---|---|---|
| 顾客 | 提交 | 订单 | 一对多 | 1个顾客 → N个订单 |
| 订单 | 包含 | 商品 | 多对多 | 1个订单 → N个商品 |
| 订单 | 扣减 | 库存 | 一对多 | 1个订单 → N个库存记录 |
| 订单 | 生成 | 发货单 | 一对一 | 1个订单 → 1个发货单 |
| 发货单 | 承运 | 物流公司 | 多对一 | N个发货单 → 1个物流公司 |
| 顾客 | 评价 | 商品 | 一对多 | 1个顾客 → N个评价 |
3.3 合并与去重：从候选到最终概念模型
名词法和动词法做完后，你会得到一堆候选实体和候选关系。接下来要做的是合并、去重、抽象。
我一般按这几步走：
- 合并同义词：比如“顾客”和“客户”是同一个东西，保留一个。
- 剔除临时对象：比如“购物车”如果只是会话级别的临时容器，可以不作为独立实体。
- 抽象共性：比如“发货单”和“退货单”如果结构相似，可以抽象成“单据”。
- 确认关系基数：每个关系都要问一句“一个A对应几个B？”
最终，我们得到这样一个概念模型：
- 顾客（Customer）
- 商品（Product）
- 订单（Order）
- 订单明细（OrderItem）
- 库存（Inventory）
- 发货单（Shipment）
- 物流公司（Carrier）
- 评价（Review）
3.4 概念模型的可视化：用SVG画一张关系图
光有文字清单不够。我习惯把概念模型画出来，这样业务方和开发都能一眼看懂。
下面这张图展示了我们刚才推导出的电商核心概念模型：
3.5 避坑指南：我踩过的三个坑
方法讲完了，说点实在的。这些年我用名词法和动词法做过不下几十个模型，踩过不少坑。
我曾经在一个项目中，把“商品颜色”单独做成了一个实体。结果发现它除了颜色值什么都没有，纯粹是商品的一个属性。后来重构时合并回去了。
判断标准： 如果一个“名词”只有一两个属性，且只被一个实体引用，它大概率是属性，不是实体。
有一次我对着一个复杂的审批流程做动词法，找出了30多个关系。后来发现一半都是“审核”、“驳回”、“转交”这类动作，其实它们只是状态流转，不是实体之间的静态关系。
我的做法： 只保留那些在数据层面有持久化意义的关系。临时动作交给状态机，别塞进概念模型。
订单和商品之间看起来是多对多——一个订单包含多个商品，一个商品出现在多个订单里。但如果你直接画多对多，后面逻辑模型会很难做。
解决方案： 引入“订单明细”作为中间实体，把多对多拆成两个一对多。这是概念模型阶段就该做的。
3.6 小结：概念模型的价值
概念模型做得好不好，直接决定后面逻辑模型和物理模型的质量。我个人觉得，花在概念模型上的时间，至少占整个数据建模工作的30%。
为什么？
因为概念模型是业务和技术之间的翻译器。业务方看不懂ER图，但看得懂“顾客-订单-商品”这种关系。你拿着这张图去跟业务确认，他们能直接说“不对，我们还有退货流程”。这时候改，成本最低。
记住一句话：概念模型错了，后面全是白做。