3、数据字典与元数据管理：建立数据字典、字段级映射、元数据版本控制
说实话，做了这么多年ERP迁移项目，我见过太多团队在数据迁移上栽跟头。原因是什么？说白了，就是连自己系统里到底有哪些数据、长什么样都没搞清楚，就敢直接开干。你想想看，这跟闭着眼睛开车有什么区别？
所以这一章，咱们聊聊数据字典和元数据管理。我个人习惯用Excel+Python脚本做初版，后面再上专业工具。为什么？因为快，而且灵活。等初版跑通了，再考虑要不要上商业的元数据管理平台。
3.1 数据字典：你的数据“户口本”
数据字典是什么？我把它比作系统的“户口本”。每个字段叫什么名字、什么类型、多长、能不能为空、默认值是什么，都得清清楚楚写下来。
我在一个制造企业的ERP迁移项目中遇到过这种情况：源系统的“客户编码”字段叫CUST_ID，长度是20位；目标系统的叫CUSTOMER_CODE，长度只有10位。如果不建数据字典，这种坑你根本发现不了。等数据跑起来才发现，那就晚了。
一个标准的数据字典，至少应该包含这些列：
| 字段 | 说明 | 示例 |
|---|---|---|
| 表名 | 所属数据表 | t_customer |
| 字段名 | 字段英文名称 | CUST_ID |
| 字段中文名 | 业务含义 | 客户编码 |
| 数据类型 | 数据库类型 | VARCHAR(20) |
| 是否必填 | Y/N | Y |
| 默认值 | 无则留空 | NULL |
| 备注 | 特殊说明 | 主键，不可重复 |
3.2 字段级映射：从源到目标的“翻译官”
数据字典建好了，接下来就是字段级映射。说白了，就是告诉系统：源系统的A字段，对应目标系统的B字段。如果字段名一样，那叫直连映射。如果不一样，就得做转换。
我习惯用Excel做映射表，结构大概是这样的：
| 源表名 | 源字段 | 目标表名 | 目标字段 | 转换规则 | 状态 |
|---|---|---|---|---|---|
| t_old_cust | CUST_ID | t_new_customer | CUSTOMER_CODE | 直接映射 | 已确认 |
| t_old_cust | GENDER | t_new_customer | SEX | 0→男, 1→女 | 待确认 |
| t_old_order | ORDER_DATE | t_new_order | CREATE_TIME | 格式转换: yyyyMMdd→yyyy-MM-dd HH:mm:ss | 已确认 |
嗯，这里要注意。字段映射不是简单的“一对一”。有时候是“多对一”，比如源系统把“家庭电话”和“手机号”分开存，目标系统只用一个“联系电话”。有时候是“一对多”，比如源系统的“地址”字段，目标系统要拆成“省、市、区、详细地址”四个字段。
3.3 元数据版本控制：别让数据字典“过期”
数据字典和映射表不是一次性产物。系统在变，业务在变，元数据也得跟着变。我见过最惨的案例：项目做了半年，数据字典还是初版，结果迁移时发现源系统已经改了三次表结构了。
我的做法是用Git来管。Excel文件虽然不能直接diff，但可以用Python脚本把Excel转成CSV，然后丢进Git里做版本对比。每次改完，commit一下，写上备注：比如“2024-03-15 新增客户表字段VIP_LEVEL”。
Python脚本长这样：
import pandas as pd
import os
def export_dict_to_csv(excel_path, output_dir):
"""把数据字典Excel导出为CSV，方便Git做版本对比"""
df = pd.read_excel(excel_path, sheet_name='数据字典')
csv_path = os.path.join(output_dir, 'data_dict.csv')
df.to_csv(csv_path, index=False, encoding='utf-8-sig')
print(f'已导出: {csv_path}')
def compare_dicts(old_csv, new_csv):
"""对比两个版本的数据字典差异"""
old_df = pd.read_csv(old_csv)
new_df = pd.read_csv(new_csv)
# 找出新增的字段
added = new_df[~new_df['字段名'].isin(old_df['字段名'])]
# 找出删除的字段
removed = old_df[~old_df['字段名'].isin(new_df['字段名'])]
if not added.empty:
print(f'新增字段: {len(added)} 个')
print(added[['表名', '字段名', '字段中文名']])
if not removed.empty:
print(f'删除字段: {len(removed)} 个')
print(removed[['表名', '字段名', '字段中文名']])
# 使用示例
export_dict_to_csv('数据字典_v1.xlsx', './dict_versions/')
export_dict_to_csv('数据字典_v2.xlsx', './dict_versions/')
compare_dicts('./dict_versions/data_dict_v1.csv', './dict_versions/data_dict_v2.csv')核心要点： 元数据版本控制不是搞形式主义。每次变更都要有记录、有审批、有通知。我建议每周五下午花半小时，把本周的元数据变更汇总一下，发邮件给项目组所有人。别嫌麻烦，等出问题的时候你就知道这半小时值不值了。
3.4 我的实战流程总结
说了这么多，总结一下我个人的标准流程：
- 第一步： 从源系统和目标系统导出表结构，用Python脚本生成初版数据字典Excel。
- 第二步： 拉着业务人员过一遍字段含义，把中文名和备注补全。
- 第三步： 做字段级映射，重点标注有转换规则的字段。
- 第四步： 把Excel丢进Git仓库，建好版本分支。
- 第五步： 每周更新一次，用脚本对比差异，发变更通知。
你可能会问：为什么不用现成的元数据管理工具？我的回答是：工具是死的，流程是活的。初版用Excel+Python，成本低、上手快。等数据字典稳定了、团队也习惯了这套流程，再考虑上商业工具也不迟。
好了，这一章就聊到这儿。下一章咱们讲讲数据质量评估——说白了，就是看看你的数据到底有多“脏”。