Data Dictionary（数据字典）：项目共识的“数据说明书”

统一数据定义，打破认知偏差。

在系统开发中，最容易被忽视、也最容易踩雷的，是“字段”。

“这个字段到底是啥？”

“跟数据库里的这个字段一样吗？”

“它是可空的吗？”

“单位是人民币还是美元？”

“长度是多少？”

当这些问题频繁冒出来的时候，就说明——你需要一份真正完整的 Data Dictionary。

它不是文档，而是项目里最容易被低估、却最值得你投入的“数据说明书”。

---

什么是 Data Dictionary？

它不是技术人的“数据库表结构”，也不是需求说明书的附件。

它是：

• 明确每一个数据字段的定义、类型、单位、规则、示例的规范性文档
• 是业务与技术之间传递数据含义的桥梁
• 是测试、开发、数据分析、培训所有环节的共同“解释器”

换句话说： 不是“数据库里写了啥我们就认了”，而是“大家共同定义每一个字段该是啥”。

---

常用的 Data Dictionary 内容结构

• 字段名称（Field Name）
• 业务名称（Display Name）
• 定义（Definition）
• 数据类型（Data Type，如字符串、日期、布尔等）
• 单位（如果适用，如元、次、百分比）
• 是否必填（Mandatory or Optional）
• 来源（系统录入 / 外部接口 / 计算字段）
• 规则说明（如长度限制、唯一性、格式校验等）
• 示例值（Example）
• 使用场景（出现在哪个功能或报告里）

每一个字段，最好都能回答三个问题：

这个值从哪来？要去哪？为什么重要？

---

我的 Data Dictionary 制作流程

1. 识别核心对象 从流程、页面、报告中提取关键实体，如客户、订单、交易、发票等。
2. 提取字段 每个实体有哪些字段？字段名称是否一致？有没有多义？
3. 定义字段 和业务方一起澄清每个字段的业务含义、输入来源、是否必填等细节。
4. 结构化整理 按照数据表格式统一整理（我一般用 Excel 或 Notion，方便协作和版本控制）。
5. 持续维护 项目过程中字段会变，Data Dictionary 也要同步更新。建议纳入变更控制流程。

---

一个真实案例

在一个电商平台的订单系统优化项目中，我们遇到严重的数据不一致问题。

前端页面显示的“支付金额”，跟财务系统、报表系统里完全对不上。原因是：

• 一个叫“pay_amount”
• 一个叫“paid_amount”
• 一个叫“actual_pay”

定义完全不同，有的是“应付金额减优惠”，有的是“实际到账金额”，有的是“支付前的估算”。

我主导建立了统一的 Data Dictionary，把订单相关的 40+ 字段全部重新定义：

• 确定字段含义 + 公式
• 明确来源系统 + 接口
• 补充示例 + 业务用法
• 和财务、市场、运营等关键部门逐一确认定义

整理完后，相关部门在开发、测试、分析阶段都明显提效。甚至连客服团队都开始用这份字段表作为培训材料。

---

Data Dictionary 的价值

• 降低沟通成本：大家说的“支付金额”终于是一个意思了
• 提高开发效率：字段定义清晰，开发不用反复问业务含义
• 支持测试与验收：字段规则明确，可直接用于测试用例设计
• 提升数据一致性：数据接口与报表统一，减少错漏
• 可复用与传承：项目团队换人也不会陷入“字段黑洞”

---

我的经验建议

• 字段不要想当然：即使是“手机号”这种看似通用的字段，也可能存在长度、校验规则等差异
• 业务+技术共同参与：Data Dictionary 不是 BA 一个人能写完的，需要业务确认 + 技术配合
• 保持版本控制：字段变更需记录日期、原因、修改人
• 越早开始越好：尽早梳理字段，可以在设计阶段就避免“信息断裂”
• 可视化比表格更有力：如果能结合 Concept Model 或 ER 图展示字段间关系，理解更高效

---

最后的共勉

我们 BA，不只是流程专家，更是数据翻译官。

Data Dictionary 是我们手里的说明书，也是我们守住“数据真相”的最后一张底牌。

别让一个字段，毁了一个系统。