数据字典是什么？
在系统开发中，最容易被忽视、也最容易踩雷的，是“字段”。
“这个字段到底是啥？”
“跟数据库里的这个字段一样吗？”
“它是可空的吗？”
“单位是人民币还是美元？”
“长度是多少？”
当这些问题频繁冒出来的时候，就说明——你需要一份真正完整的 Data Dictionary。
它不是文档，而是项目里最容易被低估、却最值得你投入的“数据说明书”。
什么是 Data Dictionary？
它不是技术人的“数据库表结构”，也不是需求说明书的附件。
它是：
- 明确每一个数据字段的定义、类型、单位、规则、示例的规范性文档
- 是业务与技术之间传递数据含义的桥梁
- 是测试、开发、数据分析、培训所有环节的共同“解释器”
换句话说： 不是“数据库里写了啥我们就认了”，而是“大家共同定义每一个字段该是啥”。
常用的 Data Dictionary 内容结构
- 字段名称（Field Name）
- 业务名称（Display Name）
- 定义（Definition）
- 数据类型（Data Type，如字符串、日期、布尔等）
- 单位（如果适用，如元、次、百分比）
- 是否必填（Mandatory or Optional）
- 来源（系统录入 / 外部接口 / 计算字段）
- 规则说明（如长度限制、唯一性、格式校验等）
- 示例值（Example）
- 使用场景（出现在哪个功能或报告里）
每一个字段，最好都能回答三个问题：
这个值从哪来？要去哪？为什么重要？
我的 Data Dictionary 制作流程
- 识别核心对象 从流程、页面、报告中提取关键实体，如客户、订单、交易、发票等。
- 提取字段 每个实体有哪些字段？字段名称是否一致？有没有多义？
- 定义字段 和业务方一起澄清每个字段的业务含义、输入来源、是否必填等细节。
- 结构化整理 按照数据表格式统一整理（我一般用 Excel 或 Notion，方便协作和版本控制）。
- 持续维护 项目过程中字段会变，Data Dictionary 也要同步更新。建议纳入变更控制流程。
一个真实案例
在一个电商平台的订单系统优化项目中，我们遇到严重的数据不一致问题。
前端页面显示的“支付金额”，跟财务系统、报表系统里完全对不上。原因是：
- 一个叫“pay_amount”
- 一个叫“paid_amount”
- 一个叫“actual_pay”
定义完全不同，有的是“应付金额减优惠”，有的是“实际到账金额”，有的是“支付前的估算”。
我主导建立了统一的 Data Dictionary，把订单相关的 40+ 字段全部重新定义：
- 确定字段含义 + 公式
- 明确来源系统 + 接口
- 补充示例 + 业务用法
- 和财务、市场、运营等关键部门逐一确认定义
整理完后，相关部门在开发、测试、分析阶段都明显提效。甚至连客服团队都开始用这份字段表作为培训材料。
Data Dictionary 的价值
- 降低沟通成本：大家说的“支付金额”终于是一个意思了
- 提高开发效率：字段定义清晰，开发不用反复问业务含义
- 支持测试与验收：字段规则明确，可直接用于测试用例设计
- 提升数据一致性：数据接口与报表统一，减少错漏
- 可复用与传承：项目团队换人也不会陷入“字段黑洞”
我的经验建议
- 字段不要想当然：即使是“手机号”这种看似通用的字段，也可能存在长度、校验规则等差异
- 业务+技术共同参与：Data Dictionary 不是 BA 一个人能写完的，需要业务确认 + 技术配合
- 保持版本控制：字段变更需记录日期、原因、修改人
- 越早开始越好：尽早梳理字段，可以在设计阶段就避免“信息断裂”
- 可视化比表格更有力：如果能结合 Concept Model 或 ER 图展示字段间关系，理解更高效
最后的共勉
我们 BA，不只是流程专家，更是数据翻译官。
Data Dictionary 是我们手里的说明书，也是我们守住“数据真相”的最后一张底牌。
别让一个字段，毁了一个系统。
