2.5 从业务到模型：一次完整的抽象演练
2.5 从业务到模型：一次完整的抽象演练
本节摘要：本节把前四节的工具串成一条流水线：从华彩商贸老板娘的原话出发，经过需求拆解、实体识别、关系梳理、规范检查、字典登记五个步骤，最终交付五张表的关系模型。全程展示每一步的思考过程而非只给结论。
前四节是单件兵器，这一节打一场完整战役。场景还原：华彩商贸启动会上，老板娘的完整原话是这样的——
"我们现在是这样运作的：销售小王接客户电话下单，记在订单本上；仓库老李按单发货，自己在库存本上划掉数量；月底财务要把三本账凑起来对销售提成和应收款。另外公司有一台打印机、两台电脑和一辆送货电动三轮，坏了就报修，谁修的、停了几天都没个记录。我就想要一个东西，把这几本账变成一本账。"
十分钟通话，里面藏着多少结构信息？我们逐步榨取。
一、第一步：从动词和名词里找实体
通读原话，圈出反复出现、需要独立记录信息的名词：客户、订单、货品（隐含在发货里）、库存记录、维修设备、维修单、员工（小王、老李要算提成）。再筛一遍——"库存本"其实是货品的属性延伸还是独立事实？讨论后确认：入库与出库是随时间发生的事件流，应当单独成表（库存流水），货品表只保留当前快照式的静态属性。
于是得到候选实体六个：客户、订单、订单明细、货品、库存流水、维修单、设备、员工——数一下是八个。新手常见的偏差在这里发生两个方向：一是只建客户和订单两张表，把明细列塞进订单表的备注；二是把"销售提成"也建成实体（它是计算结果不是事实来源）。识别阶段的纪律是：事件做成表，状态留作字段，推算结果不入库。
图题：从原话到八实体两阶段的提炼过程
二、第二步：口头需求翻译成业务规则
实体之后是规则。原话里至少埋着四条硬规则，逐条显式化：
- "仓库老李按单发货" → 出库必须以已确认的订单为依据，不能凭空扣减；
- "月底对销售提成和应收款" → 每笔订单要有归属员工与收款状态两个字段；
- "坏了就报修，谁修的停几天没记录" → 维修单记录报修、接单、完工三个时点；
- "把几本账变一本" → 所有对象共用一个库，靠外键关联而不是各记各的。
规则写成表格贴在项目群里让委托方逐条确认，这一步花二十分钟，能省掉将来返工的两个星期。沟通成本永远是最便宜的成本。
三、第三步：画出全库关系图并落地
按图落地五张核心表加三张辅助表的关系窗口设置：客户到订单一对多启用参照完整性；订单到明细一对多并级联删除（删整张测试单时明细跟着消失，此处级联反而安全）；货品与供应商是多对多，架进货连接表消化；维修单另立三个日期字段承载状态推进。
联接字段类型逐一核对长整型后启用完整性约束，接着用查找不匹配项查询自检了一遍，确认历史导入数据里没有孤儿行——旧 Excel 迁移阶段最容易混进这类脏数据，先查后禁是稳妥顺序。
四、第四步与第五步：规范检查与字典登记
对照第二范式第三范式过了一遍字段清单：发现最初草案里订单表混进了"客户等级"，它其实依赖客户而不依赖订单，剔除回客户表；库存流水里的"货品名称"同理删除，只留货品 ID，需要名字时联接查询现取。这一步专门排查放错位置的字段，把每列归位到它真正依赖的那张表。
最后把十九个核心字段的定义逐行录入数据字典，重点写清四个易误解项：
易误解字段说明摘录 成交单价 下单时刻的价格快照 与货品表现价无关 订单状态 枚举 待确认 已确认 已发货 已完成 已作废 应收余额 冗余快照 每日由对账查询刷新 刷新时间见备注 停机天数 由完工日期减报修日期计算 不手工填写
至此模型定稿：八张表、十来条关系、一本字典。回头对比 2.2 节开头那张混乱的大宽表示例，你会看到结构化思维到底值多少钱。这套五步法——圈名词、立规则、画关系、过范式、录字典——值得作为你日后每个新项目的固定开场仪式。
变式自测：换一家店你来走一遍
五步法是不是真会了，换道题就知道。题目如下：一家六间房的民宿要建小系统，老板的口头需求是"客人预订房间，到店付钱，有的客人是回头客想给点优惠，月底想知道每间房赚了多少"。建议先自己画完再往下看参考骨架。
合理的拆法：客人、客房、预订单三张实体表，客单价优惠规则先不建表（只有"回头客九五折"一条时做默认值即可，规则多起来才值得立一张价目规则表）；"付钱"落成收款流水表挂在预订单下（一次预订可能分两次付款）；"每间房赚多少"是查询问题，不进结构。最容易走错的是把"回头客"建成独立实体——它只是客人表上的一个标记字段。
对照检查三问：每张表有没有资格独立存在（有主键、有自身生命周期）？多对多消化了没有（一间房多次被订、一位客人多次订房，靠预订单天然解开）？推算指标是否都没进表（入住率、营收留给查询）？三问全过，说明你已经能把这套方法论搬到自己的业务上了——这比看懂华彩案例重要得多。
一页纸检查卡：贴在显示器边上的五步法
为方便跟练，把本章流程压成一页卡片，做完一项划一项：
建模五步检查卡 口1 圈名词 名词清单列全了吗 同义词合并了吗 口2 立规则 业务规则让委托方书面确认了吗 争议项标记了吗 口3 画关系 每条关系都回答了基数三问吗 类型配对核对了吗 口4 过范式 每列都问过依赖谁吗 冗余快照登记字典了吗 口5 录字典 核心字段都有用途解释吗 易误解项单独备注了吗 使用约定 前四格没全勾之前 不许打开表设计器
这张卡在团队里的最大价值不是提速而是刹车——它把"先想后建"从美德变成了流程。华彩第二个项目（第 8 章 8.4 的报修台账）依然在用这页卡，你可以对照那一节看看它在真实小项目上的样子。
本节要点回顾
常见卡点速答
跟练时读者最常卡在三处，提前给出处置。卡在第一步多半是名词清单不敢删——记住草图允许粗糙，先落笔再修剪，完美主义是建模阶段最贵的成本；卡在第三步多是基数判断犹豫，此时回到业务规则逐字读，"一个客户可以下多笔单吗"这类问题委托方一句话就能裁决；卡在第四步通常是纠结范式纯度——回看 2.2 的取舍课，有名有姓的冗余合法，困扰只属于无名无姓的妥协。
本节要点回顾
- 实体识别的分流口诀：事件做成表，状态留作字段，推算结果永不落库。
- 业务规则要在动工前书面确认，沟通成本是全流程最便宜的投入。
- 规范化检查能在动工前揪出放错位置的字段；迁移旧数据前先跑不匹配项体检。
- 五步法循环可用：这是本章所有小节的合龙点，也是下一章查询舞台的地板。