设计数据模型与数据字典
本章目标：把业务对象转成清楚、稳定、可填写、可查询的数据结构，并避免照搬 Excel 造成的长期问题。
1. 数据模型不是字段越多越完整
一个好的数据模型应该：
- 能准确表达业务事实；
- 让用户知道该填什么；
- 支持规则、流程和查询；
- 避免同一信息到处重复；
- 能适应可预见的业务变化；
- 不为了未知未来过度复杂。
字段数量多并不代表分析充分。每个字段都应有明确用途、来源、责任和使用场景。
2. 从业务对象卡开始
对“采购申请”先确认：
- 谁创建；
- 何时产生；
- 包含哪些主信息；
- 包含哪些多行明细；
- 经历哪些状态；
- 哪些信息由用户输入；
- 哪些信息由应用自动得到；
- 哪些信息供审批、查询或统计使用。
然后再决定字段，而不是打开设计器边想边加。
3. 给字段分类
3.1 识别信息
用于准确找到一条记录：
- 申请编号；
- 标题或摘要。
编号应稳定、唯一且不依赖用户随意输入。具体配置参见自动编号。
3.2 业务输入
由用户提供的事实：
- 采购用途；
- 物品名称；
- 数量；
- 预计单价。
3.3 自动得到的信息
通过默认值、计算或业务动作产生：
- 申请日期；
- 行金额；
- 申请总额；
- 当前状态。
自动得到的信息应尽量避免再次要求用户重复填写。
3.4 过程信息
描述业务怎样被处理：
- 提交时间；
- 审批完成时间；
- 开始采购时间；
- 采购完成时间；
- 当前负责人；
- 作废原因。
过程信息是查询时效、责任和异常的重要依据。
3.5 管理分类
用于筛选和统计：
- 物品类别；
- 紧急程度；
- 预算归属；
- 部门。
如果管理者希望按某个维度统计，就必须保证该信息以稳定、可比较的方式记录。
4. 选择正确的数据类型
类型决定用户如何填写、怎样校验和能否正确计算。
| 业务内容 | 推荐思路 | 不推荐 |
|---|---|---|
| 数量、金额、比例 | 使用数字类字段并明确小数规则 | 用文本保存“100元” |
| 发生日期 | 使用日期字段 | 自由输入“本周五” |
| 精确时刻 | 使用日期时间字段 | 把日期和时间拆成两个自由文本 |
| 是或否 | 使用明确的选项或开关 | 填写“是/否/大概” |
| 有限类别 | 使用可控选项 | 每个人自由输入类别名称 |
| 说明和备注 | 根据长度选择合适文本 | 所有内容都用短文本 |
| 文件凭证 | 使用附件或图片 | 只填本地文件路径 |
5. 选择日期还是日期时间
问自己：
业务只关心哪一天，还是必须知道具体几点几分？
- 申请日期、采购日期通常只需要日期；
- 提交时间、审批完成时间用于计算处理时长，需要日期时间；
- 跨地区使用时，还要明确同一时刻在不同时区如何理解。
详细原则参见日期时间与时区。
6. 设计主信息与明细
采购申请主信息：
| 字段 | 来源 | 用途 |
|---|---|---|
| 申请编号 | 自动生成 | 查找和沟通 |
| 申请日期 | 默认当天 | 业务归属 |
| 申请用途 | 用户填写 | 审批判断 |
| 紧急程度 | 用户选择 | 流程和提醒 |
| 总金额 | 自动汇总 | 审批和统计 |
| 状态 | 随业务过程变化 | 跟踪和权限 |
采购明细：
| 字段 | 来源 | 用途 |
|---|---|---|
| 物品名称 | 用户填写或选择 | 确认采购内容 |
| 规格 | 用户填写 | 避免买错 |
| 数量 | 用户填写 | 计算和采购 |
| 预计单价 | 用户填写或带出 | 预算判断 |
| 行金额 | 自动计算 | 汇总总额 |
| 备注 | 用户按需填写 | 补充特殊要求 |
明细设计和操作参见明细表设计。
7. 必填、默认值和只读不是随便勾选
必填
只有在缺少该信息就无法正确保存或进入下一业务阶段时才设为必填。
有些字段在草稿阶段可空，但提交时必须有值，应在提交规则中检查，而不是让用户连草稿都无法保存。
默认值
默认值用于减少重复输入，但必须符合大多数情况，并允许用户看见其结果。
例如申请日期默认当天合理；采购完成日期不应在新建时默认当天。
只读
自动计算、状态和已确认事实通常不应被普通用户直接修改。只读的原因应与角色和业务阶段一致。
8. 区分“未知”“没有”和“零”
这些值在业务上可能完全不同：
- 预计单价为空：还不知道价格；
- 预计单价为 0：明确认为免费；
- 备注为空：没有补充；
- 数量为 0：通常是不合法输入；
- 完成日期为空：尚未完成。
不要为了页面看起来整齐，把所有空值自动变成 0 或“无”。默认值会改变业务含义。
9. 避免自由文本造成数据失控
以下内容如果要用于权限、流程、筛选或统计，不应只靠自由输入：
- 人员和部门；
- 状态；
- 物品类别；
- 紧急程度；
- 费用类别；
- 业务阶段。
“行政部”“行政”“行政部门”在人眼看来相同，统计时却可能成为三个不同值。
如果当前功能无法提供所需的稳定选择，应把它记录为能力差距并评估影响，不要在没有说明的情况下长期用文本代替。
10. 设计关系和引用时要问的问题
如果采购申请需要选择物品目录：
- 物品停用后，历史申请怎样显示；
- 目录中的名称和价格变化后，历史申请是否跟着变；
- 申请时的预计价格是否需要保留；
- 一个明细是否允许不选择目录、临时输入；
- 删除或合并物品时如何处理已有申请。
通常，历史单据需要保留业务发生时的关键事实，而不是随着基础资料变化而改变。
11. 设计状态和关键时间
从生命周期表中提取：
- 当前状态；
- 提交时间；
- 审批完成时间；
- 开始采购时间；
- 采购完成时间；
- 作废时间和原因。
不要只依赖一个“最后更新时间”代替业务时间。最后更新时间可能因为修改备注而变化，不能代表审批或采购何时完成。
12. 建立数据字典
每个字段至少记录：
| 项目 | 示例 |
|---|---|
| 业务名称 | 采购总金额 |
| 所属对象 | 采购申请 |
| 业务定义 | 所有有效明细行金额之和 |
| 类型与格式 | 金额，保留两位小数 |
| 来源 | 自动汇总 |
| 是否必填 | 提交时必须得到 |
| 是否允许修改 | 不允许手工修改 |
| 使用者 | 申请人、审批人、行政 |
| 使用场景 | 流程分支、查询、统计 |
| 空值含义 | 无有效明细，不能提交 |
| 规则编号 | BR-02 |
| 敏感性 | 普通业务信息 |
数据字典的“业务定义”和“使用场景”比字段名称更重要。
13. 变更数据设计前的影响检查
增加、修改或删除字段时检查：
- 是否已有业务记录；
- 是否影响计算和动作；
- 是否影响流程条件；
- 是否影响权限和视图；
- 是否影响导出和打印；
- 是否需要补充历史数据；
- 原有测试场景是否仍成立。
对已有数据的字段，不要因为“界面上不用了”就立即删除。先确认历史查询、统计和审计是否仍需要它。
14. 常见错误
- 直接复制旧表格的每一列；
- 同一事实在多个地方重复填写；
- 金额、日期和状态都使用自由文本；
- 把自动计算结果交给用户手工维护；
- 所有字段都设为新建必填；
- 没有区分主信息和明细；
- 为了未来想象添加大量无人使用的字段；
- 删除字段前没有检查动作、流程、视图和历史数据。
15. 本章完成标准
- [ ] 每个字段都能追溯到业务场景或管理需要；
- [ ] 主信息和明细划分清楚；
- [ ] 用户输入、默认、计算和过程信息已区分；
- [ ] 数据类型符合业务含义；
- [ ] 必填和只读规则考虑了不同状态；
- [ ] 人员、状态和分类没有被随意设计成自由文本；
- [ ] 关键日期能支持时效和统计；
- [ ] 数据字典包含业务定义、来源、规则和使用场景。
下一步
数据结构决定“记录什么”，表单体验决定“用户怎样完成工作”。下一章学习设计好填、少错、易懂的表单。