这是一篇技术文档

《数据管理能力成熟度评估模型》（GB/T 36073-2018）国家标准已于2018年发布，随后工业和信息化部也推出了《工业和信息化数据资源管理办法》。数据管理也是学校信息化建设的基础，近年来，学校先后发布过《关于进一步规范人员编码和加强电子身份管理的通知》、《北京理工大学楼宇房屋编码规范》等若干规范学校各信息系统编码的文件，但文件的制定与发布无法跟得上变化的步伐，比如人员细分类别的编号、新建楼宇、新改房间的，因此有必要建立一个动态的标准发布机制。

数据现状

目前，学校中心数据库已经通过Kettle实现对近40个业务系统数据库的ETL，对于一些核心数据也做了API封装，可以说基本的数据互联互通已经实现，但我们还很难做到数据统计的准确和完备。这里面的原因我分析主要有四点。

1. 业务系统内部数据不准确、不及时
   业务系统在设计之初主要考虑的是实现管理流程，对数据的重视程度不高，尤其缺乏数据对外共享的责任意识。比如有两个单位，因为觉得自己业务系统不靠谱，于是把Excel作为管理数据的工具，而把业务系统当成了备胎时不时才上去照着手里的Excel更新一下。

2. 业务系统数据不完备
   同样因为业务系统建设出发点是实现自己部门的管理流程，自己部门用不到的数据项，就不会去采集和维护。所以当学校在做高基报表、教基报表以及其他上级部门要求大报表时候，发现数据采集要求的无法落实到业务系统里面，有的领域甚至还没有业务系统。

3. ETL自身的缺陷
   ETL（抽取、转换、加载）是把一个数据库里面的数据抽取并加工之后，推送到另一个数据库里面，通常以定时任务来实现。比如人事系统里新增加一个员工，一般在两个小时以内，这个员工的基本信息会从人事系统中抓出出来，进入学校中心数据库，并且推送到教务部、研究生院等业务系统里。这里面可能的缺陷是我们在做ETL时候，通常只做增量和更新，不做删除。比如我们不会因为人事系统里删掉了一个员工记录，而去把教务部、研究生院的系统里这个人的相关信息都删除，当然如果人事系统里把这个员工标记为离职，那么从技术上，我们是可以把相关系统里这个人都更新为离职。但不得不吐槽人事系统的脑残设计，这个系统里在职、离职等不同状态的人员，物理上存储在不同的表里，所以当我第一次听说人事系统里有一个操作叫“移库”时，我真是惊呆了，这种不合理的设计，人为给数据管理造成了巨大困难。

4. 数据字典、规范、管理办法不健全
   网络中心在建设学校共享库的时候，也就是在做ETL打通各业务系统的时候，已经在着手整理相关文档，但好几年下来没有对外发布。

健全字典与规范

我去年在网络中心工作时把文档接手过来，但对于这样一个内容复杂的文档，想写好并发布出来确实是很困难的。只好转变思路，成熟一点发布一点，把大文档拆成三部分：

• 数据字典
• 数据规范
• 管理办法

数据字典

中心数据库在抽取业务系统内的数据时，是首先要对照字典进行转换然后才存储。这里面使用的字典包括国标、校标以及网络中心自定的标准，比如：

政治面貌代码国家标准 机构代码学校标准 自定义标准

相对来说，字典是最好整理和发布出来的内容。

数据规范

数据规范是指各业务系统应对中心数据库提供的数据表、视图的结构。比如

学生表结构

数据规范比字典复杂一点，规范的制定一方面要结合业务系统内部的数据现状，另一方面要参考学校和上级部门对数据统计的需求。理想情况下，如果业务系统都能够按照数据规范提供原始数据，那么各类数据统计就不需要单独上报了。

管理办法

管理办法是最难以正式发布的内容，这里面应该规定各业务部门对数据产生、管理和共享的责任义务，甚至应该包括出现问题时的追责，所以，我把这部分内容先跳过去，集中清理先做前两部分更为客观的内容。

持续交付的文档

数据字典和规范都不断变化的文档，而且需要记录不同版本之间的差异变化，因此我们使用持续交付方式来管理和发布文档。

1. 使用Sphinx撰写
2. 使用Git管理项目，并视情况发布版本
3. 使用Jenkins持续交付，生成HTML文档
4. 使用微信企业号面向所有人发布

信息化建设栏目

后记
微信企业号内的“信息化建设”是信息化办公室最近新增的一个栏目，学校信息化是一项涉及师生以及管理部门全员的复杂系统工程，需要沉下心来从最基础工作的做起，从提升管理人员的信息化工作素养做起。