我如何完成一本企业数据字典的编写？

发布时间:[2017-02-15] 来源:作者：傅一平编辑：杜绍森点击量:

数据字典应该是数据管理领域非常核心的东西，如果说，语言是人类世界沟通的方法，数据字典则是数据世界沟通的语言，任何数据都需要通过看得懂的方式表达出来，只有懂这个数据什么意思，才有基于数据创造的可能，才能实现数据知识的传承。

但很多企业没做数据字典这个事，或者也不重视，为什么？

一是非眼前事，以后做也成，不做暂时也没影响。

二是难度比较高，产出却遥遥无期，做个取数好歹有个工单，搞本数据字典有啥业务产出，想不明白。

三是不够显性化，数据字典这种练内功的事情，很难引起领导重视，BI创造亮点和业务价值才是正事。

有幸主导了所在企业数据字典的编写工作，因此来谈谈编写的心路历程，可能会有些启示。当企业的数据字典成为公司数据采集、开发、分析及应用的必备工具后，才感觉到这个工作完成实际迟到了很多年。

如何启动数据字典梳理这个事情？

企业数据字典的梳理是个浩大的工程，如果让一个人去启动这个事情，大多第一反应肯定是工作量巨大，有点茫然，这也是笔者当时的感觉。

但看似不可能完成的任务，真的花功夫去研究了，发现还是有可能做的，我当时作了初步判断，基于手头的公司各源系统给的各类PDM等文档，结合实际的统计，公司核心系统的重要的表，大概不到3万张，而真正有业务价值的表，估计不到1万张，假如我花100天，每天搞定100张表，这是个能突击完成的任务。

当然后来深入到表字段的分析，发现根本处理不了这么多，因此，决定先完成基于表级的梳理，搞清楚每张表的业务含义和获取方式，事实上，正是由于这个决定，才能尽快的完成一个阶段性成果，也正是有了表级的指导，后续才可以将字段级的梳理要求清晰的分配下去，8个人理2个月也基本完成了。

一个企业，肯定有一拨或几号人，其业务和数据的沉淀到了一定水平，能够干这活，但起头的确非常不易，毕竟梳理数据字典，也是讲究一定方法和套路的。

做这事的还有一个原因，是公司要建设大数据平台，如果没有完整的数据字典，那这个工程能否如期保质完成是个未知数，不能想着拿原来的BI的那点数据接口来应付，也不能期望他人（有谁比你更懂呢），还是要靠自己，利用一切机会把公司的资产梳理清楚。

作为一个BI老鸟，你不上，就没人能上了，还是要有这个觉悟。以下是我当初回顾PPT写得一段话：

“通过梳理XX公司全景数据，建立起大数据基线版本，明确大数据的分布，理解数据蕴含的意义，判断出这些数据的价值，指导未来大数据引入和建模等工作，并通过运营机制的建立盘活公司大数据的资产。”

“本次梳理以大数据营销及变现为驱动力，重点考虑B域及O域，后续在条件成熟时会逐步扩展到完整的M域，梳理的基准数据粒度是域-系统-表（或对应的数据实体），不对每个字段（或属性项）做具体描述。”

那采用什么样的方法和步骤呢？

一是确定规划目录：原则上应该自顶向下梳理，先通过调研确定总体结构分类，然后分主题进行，由于本次梳理的范围较大，暂时以源系统方式梳理开始，不强调目录分类的科学性，仅强调梳理的便捷性，以下是B域的目录示例。

二是确定参考材料：从源系统负责人搜刮到的BOSS/CRM等系统所有现存的PDM，SVN上存在的所有概要设计文档为依据，梳理的参考材料会按照系统分门别类保存，作为输出物，方便后来人参考，算是梳理的副产品，的确没有一个地方有完整的源系统资料。

三是确定干系人：很多知识都留在开发人员脑子里，现有的资料不足以解释当前的实际业务和数据，因此确定了干系人名单，这个工作也很重要，以下示例了各个系统对应的合作伙伴和联系人，有问题就直接真人PK。

做数据的，有必要跟源系统的开发等人员混熟，否则涉及一些深层次的问题，没人能够解答，必须要开发人员出马，以为文档很理想，但现实很骨干，国内的IT文化是代码写得快，领导说100天搞定就搞定，但文档就乏善可陈了。

四是理解逻辑视图：系统的逻辑模型对于理解数据的业务意义和价值至关重要，因此首先需要从PDM或概要设计找到模型去理解业务，这个是最艰难的，梳理数据字典不是拿着PDM来直接抄就可以了，要把业务理解清楚，才能写出很好的说明，反映出各种实体的关系。以下列出了产品系统中涉及的相关表，务必要搞清楚各个子主题及各表之间的关系，表的关系图在PDM，因此不罗列。