业务需求怎么翻译成数据模型？低代码建模的思考方法

结论先行：把业务需求翻译成数据模型（Data Model），只需要回答三个问题：什么东西要记（圈名词找实体）、它有什么属性（定字段）、它们之间什么关系（定关联）。本文用一段报销需求演示完整建模过程，全程约 40 分钟，并给出 5 个验证问题和 4 个常见错误。建模对了，后面搭页面就是体力活；建模错了，返工是必然。

很多低代码新手拿到需求就直接开始拖页面，做到一半才发现"这个数据放哪张表都不合适"。问题的根源不在工具，而在于跳过了建模这一步。

Table of Contents

为什么需求文档不能直接变成数据模型

需求说的是"人的语言"，模型是"数据的语言"，两者结构不同。需求里写"员工提交报销单，附上发票，主管审批后财务打款"，一句话里有动作、有角色、有单据，直接照着做页面，会漏掉"一张报销单对应多张发票"这样的结构关系。建模的本质，就是把叙述性的需求压缩成几张表和几条关系。这套压缩动作正是模型驱动型低代码的起点。

第一问：什么东西要记——先圈名词

把需求描述里出现的名词全部圈出来，划掉不需要系统记录的，剩下的就是候选实体（Entity）。以上面那句需求为例：员工、报销单、发票、主管、财务。其中"主管""财务"只是审批流程里的角色，不需要单独建表，划掉；留下员工、报销单、发票三个实体。

注意"审批记录"最容易被漏掉——谁在什么时候批的，这类过程信息恰恰是系统最该记的，要主动补上第四个实体。

第二问：它有什么属性——定字段的三条规则

每个实体问"它有什么属性"，属性就是字段。三条规则防止字段设计跑偏：

原子性：一个字段只存一件事。"发票信息"不算字段，"发票金额""开票日期"才是。
选对类型：金额用数字、日期用日期、状态用单选。类型决定后面能不能排序、筛选、汇总。
必填克制：只把"缺了就无法流转"的字段设为必填——报销单的"报销事由"必填，"备注"选填。

以报销单为例，核心字段是：单号（自动编号）、申请人（人员）、总金额（数字）、状态（单选：草稿、审批中、已打款、已驳回）、提交时间（日期）。

第三问：它们之间什么关系——一对多与多对多

实体之间的关系只有两种基本形态：一对多和多对多。判断口诀：数一数，一边只有一个、另一边有很多，就是一对多；两边都可能有多个，就是多对多。

一名员工可以提交多张报销单：员工与报销单是一对多；
一张报销单可以附多张发票，一张发票只属于一张单：报销单与发票是一对多；
一个项目会产生多张报销单，一张报销单也可能摊到多个项目：项目与报销单是多对多——低代码平台里通常通过中间关联表或"多选关联"字段实现。

项目与任务的典型一对多关系就是按这个口诀落地的，完整的三表模型可参考低代码搭建项目管理系统的数据模型。

用 5 个真实问题验证模型

模型画完后，用五个真实业务问题反问它，能答上来才算过关：

张三这个月提交了几张报销单？（能从报销单表按人筛出来吗）
第 2026001 号报销单总共花了多少钱？（金额能汇总吗）
财务想知道每张单的最新审批人是谁？（审批记录能按时间取最新吗）
一张发票作废了换新的，历史怎么留痕？（状态字段够用吗）
报销单被驳回后重新提交，算新单还是原单？（流转规则定了吗）

第 3、5 题最容易暴露缺口，补字段或调整状态设计即可。

四个最常见的建模错误

把过程当实体：为"审批"单独建记录表没问题，但为"提交""打款"各建一张表就错了，过程用状态字段和记录表表达。
该拆不拆：把发票信息塞进报销单的三个文本字段里，后面想统计"发票总额"就无从下手。
过度设计：需求只说报销，建模时顺手做了"预算管理""差旅标准"五张表。先做需求里有的，扩展等真有需求再说。
没有唯一编号：报销单没有单号字段，后面引用、对账、查重全都没有抓手。

FAQs

Q1：建模错了，后面发现还能改吗？

A：加字段基本随时可以；拆表和改关系的成本就高了。所以建议建模阶段多花时间验证，宁可动手前多想 20 分钟。

Q2：不会数据库理论，能做好建模吗？

A：能。低代码建模用到的概念就四个：表、字段、类型、关系，本文三问已经覆盖。数据库理论是进阶项，不是门槛。

Q3：一开始要不要把模型设计得很完整？

A：覆盖当前需求的 80% 即可，预留单号和状态这类扩展性字段。模型是随业务长出来的，但骨架（实体划分和关系）一开始就要正。