从数据标准到数据库设计：解决基础数据标准落地的最后一公里难题

导语

数据标准是指保障数据的内外部使用和交换的一致性和准确性的规范性约束，建立数据标准容易，落标难。本文通过对数据标准的定义，落标难点分析以及通过国内外标杆案例的讲解和对落标关键点剖析，系统的介绍数据标准通过模型驱动的标准落标整体方案，帮助企事业单位理解数据标准落地相关问题。

一数据标准概述

1.1数据标准定义

数据是由特定的环境产生的，这些环境因素包括生产者、时间、系统等，这就造成了同一个语义的数据，会有多种不同的定义方法，给后期进行数据汇集和整合带来障碍。因此，数据处理的前奏就是数据标准化，数据标准作为一个统一的数据共识，在企业的标准化中起到重要作用。数据标准是指保障数据的内外部使用和交换的一致性和准确性的规范性约束。数据标准一般包括下面几个，为了统一本文阅读共识，列出如下：

1)基础数据标准，这个标准是针对数据原始定义，一般面向原系统数据或ODS层数据。包括业务语义、管理标准、逻辑数据模型标准、物理数据模型标准、元数据标准、公共代码标准、技术规范，质量要求等。

2)指标数据标准，一般分为基础指标标准和计算指标（又称组合指标）标准。基础指标一般不含维度信息，且具有特定业务和经济含义。计算指标通常由两个以上基础指标计算得出。这个标准针对衍生型数据，一般面向集市层的报表等计算型数据。

3)标准代码，这个具体指数据标准中的枚举值和语义，可以作为基础数据标准的一部分，数据标准维度也是大部分来源于此。

4)主数据标准，这个特指主数据治理中的实体对象数据的唯一编码和规则，比如物料主数据编码。

5)业务术语词典，这个指企业数据定义过程中，从业务名词到物理表和字段的标准化翻译的词根和词素。

6)其他规范，包括数据库设计规范、元数据规范、模型规范等，具体可以在其他治理活动下定义，也是广义数据数据标准的一部分。

一般情况下，本文所述的数据标准落标主要指：（1）基础标准落标，（3）标准代码落标，（5）命名标准落标。指标体系的落标是由于在数据后期比较容易实现，故不在重点讨论中，主数据标准编码则特定于主数据治理过程中实现，不在此赘述。

1.2落标价值及意义

数据标准的落标意义在于企业由此开始进行数据驱动文化，开始从源头进行数据的标准化生产，加速数据的融合与统一的效率，节省大量数据应用和处理的成本。数据标准的落标程度可以分为基本拉通型落标和全局管控型落标。

基本拉通型落标是指设计的数据元素符合数据标准的基本语义和业务规则，物理定义符合技术规范，具体数据语义可以进行无规范的衍生。落标范围重点是核心业务系统的核心标准和交叉标准，还有数据仓库系统的。这种类型适合中小银行的上手阶段，以及没有重大系统升级机会的系统，其核心目的是减少数据融合成本，加速数据消费的效力，适合进行数据化驱动转型的企业。

全局管控型落标是指设计的数据元素符合数据标准的基本语义和业务规则，物理定义符合技术规范，具体的物理数据语义需要进行有规范的衍生，数据质量需要落地为数据库约束或者质量验核规则。落标范围是核心业务系统和重点业务系统，以及数据仓库等衍生系统。这种适合IT能力强，数据基础好的企业，其核心目标是掌控企业全局数据，做到数据快速迭代，适合致力于打造数据快速创新型企业。

1.3落标过程中的衍生

数据在落标过程中是可以进行一定程度的数据语义衍生的，比如“电话号码”衍生为“供应商电话”，如果衍生的字段有确实的细化语义，或者其他业务要求，就需要也有一些数据标准需要定义为子类标准或者同义标准。

子类标准

当一类数据标准有进行细化的必要，并带来特定的语义和业务规则，就需要在原有标准上进行衍生。比如“电话“衍生为”手机“和“座机“，这是因为这两类衍生标准带来不同的业务属性，不同的数据格式，以及不同质量检查规则。

也有一些可以不进行标准级别的衍生，比如“姓名“，具体语义的设计可能是“客户姓名”和“供应商姓名“，这两个衍生可以不作为子类标准制定，这是因为业务语义是因为数据所在的语义环境变化，本质并没有不同。

同义词

同一类语义标准，在不同的业务口径中或者不同的人群中，会有不同的名词，比如保单号和保单代码是同一语义的名词。这时候需要将两者定义为同义词，并在每一个定义时，标注清楚使用语境。

1.4落标难点分析

我国企事业单位的数据治理已经开展十几年，在有数据监管驱动和自身数据价值挖掘的驱动下，大部分行已经进行了数据标准框架定义和梳理，发布了各个板块的数据标准指导文件，有的甚至落实了数据标准流程和人员角色，然而数据标准的落标在大部分普通银行仍然不是很理想。现在数据标准梳理和发布是比较容易的事情，各咨询厂商手里也积攒了大量各个行积累的数据标准，可以比较全面的提交给各个银行，可是落标不理想的原因笔者认为有以下几个问题：

1)存量数据大，积重难返

根据破窗常理，没人在乎再多一块破窗户。数据业务系统绝大部分已经建设完成，木已成舟，不标准也没法修改了。

2)开发设计规范不重视

开发团队的责任和考核点主要是系统上线，支撑业务，在开发团队的很多人看来，数据标准化的设计是一个可选项，影响上线时间才是大事。

3)标准落标不方便，影响效率

很多家咨询公司的数据标准，技术规范普遍缺失。这说明标准开始就没有认真考虑落标问题，这就造成落标很不方便，先在Excel里查找，再手工拷贝，再类型翻译，确实影响效率。

4)监管与激励缺失，落与不落都一样

现在的数据结构和字典中，落标与不落标是没有量化跟踪的，这直接造成激励与认责无法落地执行。

5)人力与关注点缺失，没人管

普通银行并不像四大行那样人财雄厚，数据治理工作普遍是3-4个人兼职完成，日常被大部分其他工作排满，不可能把这项工作量化起来，也无从着手。

二国内外落标案例介绍

为了认真的研究这个命题，笔者决定调查几个国内落标的典型案例，看看能从中学习点什么。调查从总体看思路，细节不符之处在所难免，望读者不吝指出共同完善。

2.1国内企业落标典型案例

建设银行从2014年新一代项目时，开始大力度的进行彻底的和全方位的数据标准落地工程。建行师从IBM的四层模型法，通过九大银行业概念设计了企业级逻辑模型，依托于此企业级逻辑模型，打造了企业级数据字典。通过设立数据标准处和架构处，进行了流程和规范管制，进行强力度的模型和数据的落标管理。具体请看笔者画的一个示意图。

                                             

建行落标示意图

从示意图看出，建行采用了源头控制的方法，基于建行的得天独厚的逻辑模型优势，打造了一个企业级的数据字典，由于业务系统从C模型继承开发，所以存量问题基本得到解决。

从模型开发设计阶段开始，模型团队就要根据现有标准进行落标的设计，沟通方式可以是电话或邮件，通过长期工作，效率基本不影响开发进度。缺失的标准通过标准组来进行更改和维护。

测试阶段，需要提交数据字典映射到企业级数据字典，每一个新数据项的增加都可以说明这是或者不是标准，都会记录在案。

核检阶段，现在主要是送数过程中进行检查，不通过将不能向后台送数。近期要进行上线核检，提高落标的早期检查力度。

2.2国外企业落标概况

作为Erwin的开发者，在外企的数据管理领域工作多年，对国外数据管理有较多认识，接触过很多国外银行业客户，如SunTrust、苏格兰皇家银行、citibank等。今年5月份有幸参加了国外的EDW大会，笔者发现国外确实数据发展阶段与我国有很大不同。

国外普遍比较重视数据建模工作，业务系统成熟多年，数据的修改全部由模型工具控制。会有专业的建模师和架构师来贯彻落标工作，同时，模型工具也已经标准化和全局推广了，在EDW大会上很少听到讨论落标的话题，在他们的意识里，落标已经固化在建模过程中完成，甚至元数据管理也较少话题，因为也已经成为广泛共识。相反，他们非常多的谈的是Business Glossary，国内却很少提及。

总结一下，国外的系统建设期，因为在建模理论和系统化设计思维方面的优势，再加上企业管理制度的方面比较成熟，银行业的数据建模工具的使用率非常高，使得数据的早期落标得到较彻底的执行，同时，早期的数据标准问题也基本到现在有了成熟的解决路径。

2.3落标关键点剖析

根据笔者的经验与实践，数据标准的落标需要重点考虑以下三大问题：

问题1：什么数据需要制定哪些标准？

问题2：什么系统落什么标准？

问题3：什么人与什么时间执行？

如果这三个问题没有想清楚，基本数据标准的梳理会停留在Excel层面，标准的政策会停留在墙上，无法走入每个设计者的头脑和每个系统的每个字段。

先来说第一个问题，什么数据需要制定标准？首先回到数据标准所要解决问题的初衷，数据标准主要解决数据在共享、融合、汇集应用中的不一致问题。好的，那么看看哪些数据会出现在这个这三个环节中，以及哪些容易出现问题。

对于与一个企事业组织来说，按照价值链，一般关注三大要素：客户、产品、大运营。IBM和TD将银行业划分为九大概念数据，也是围绕客户与产品的大运营活动细分。那么有如下几类数据会在数据应用过程中，会更多出现融合和汇总的机会，需要格外注意。

表1 数据类型及范例表

序号	数据类型	示例
1	基础通用型数据	国家通用标准、行业通用标准、企业基础标准等
2	主数据类数据	客户、产品、渠道等主要经营数据
3	类型和维度类数据	分类码、标准码、维度码等
4	报送类数据	报送类模型和数据

第二个问题和第三个问题是实际工作中非常困扰的，落标的大多数困难与此有关，因此放在一起来说明，笔者将系统与数据分列如下列表所示。

表2 系统与数据落标时机选择表

系统	落标强度	剖析	负责人	时机选择
核心业务系统数据	强	核心系统存储了企业经营最核心的数据，数据标准可以从核心系统定义中梳理，核心系统的数据的标准化会直接影响下游系统，数据流动链很长而系统改动难。因此尽量促成“我就是标准“这件事	开发团队或套装开发商	1.建设期强落标 2.维护期谨慎落标
重要业务系统数据	中	重要系统存储了核心系统的补充数据，重点是标准要与核心对齐	开发团队或套装开发商	1.建设期强落标 2.维护期谨慎落标
一般系统数据	弱	一般系统适合采用拉通型落标，重点在一些核心数据引用和类型类数据	开发团队或套装开发商	1.建设期选择重点落标   2.维护期可以不落标
报送和对外共享数据	强	遵从报送标准，和共享标准	报送团队	遵从报送和共享标准
DW初始汇集层	强	一般企业落标最容易着手之处，数据需要进行模型建模，汇集落标，需要进行ETL数据处理	数仓团队	尽早进行管控型强落标
DW汇总层数据	强	如果没有初始汇集层，可以在此针对具体主题进行落标，需要进行ETL数据处理	数仓团队	全局规划后，应用开发时
Mart集市与报表数据	强	主要参照落标指标体系和维度体系，汇集落标，需要进行ETL数据处理	报表团队	每一次开发时

通过这个表格的内容，不难看出数据标准从源头落地，会减少数据的处理成本，提高数据应用的效益，缺点是对于存量系统和外购系统存在较大改动风险和成本。如果从数据的仓库层进行落标，比较容易着手处理，落标后的下游数据系统则自动统一数据标准，然而数仓层的报表应用与业务系统的报表存在口径不一致性在所难免，仍然需要源数据层进行必要调整。无论从哪一层入手，模型的优良设计环节都是必要条件，否则整个落标过程会没有抓手，流程也不顺畅。

2.4落标整体方案

无论是原系统数据还是数仓数据，都是不同的开发团队负责，遵循软件开发标准的流程包括设计、开发、测试、上线、维护等环节，因此我们需要在这个过程中，将数据标准这个优良的炮弹送到最前线，同时，管理团队需要参与这个过程的关键节点中，这需要企业在数据管理上提高管理和执行水平。

鉴于企业当前的数据基础水平，数据的落标同样受到人力和财力的制约，所以一个自动化水平非常高的落标方案是非常切合我国普通银行的发展阶段的。因此，落标方案的关键思想是在开发阶段由模型设计人员进行落标，标准管理和架构管理人员进行评审和核准，同时，自动检测能力来提高执行水平和激励环节的落地。

自动化落标方案

2.4.1标准的定位

这里主要是在系统的需求设计和准备过程中，对数据标准需要准备好一些前提条件。

1）标准的技术规范已经准备好

数据标准已经具有详细的技术规范，包括物理数据类型，可以直接应用的物理层上，并已经准备好逻辑数据类型到不同数据库的类型映射。这里数据类型在DDM中是逻辑数据类型，具备自动类型转换能力。

2）标准的主题已经准备好

标准的主题其实是标准的应用范围和检索目录，对于具备条件的银行应该设计出逻辑模型，对数据标准进行业务组织。这样在落标过程中，这是重要的选择依据。

3）标准已经权威发布

标准已经经过讨论，进行了公开发布，具有流程上的正式性和权威性。

2.4.2模型设计中的落标

数据模型是一个更好的数据字典，其向上承接业务语义，向下实现物理数据，它不但包含了数据字典，更重要的是包含了业务的主题、业务主对象、数据关系以及数据标准的映射。所以模型及其工具的运用不但是企业数据管理是否成熟的重要标志，也是数据标准落标的重要依托。不进行模型设计和管理，落标操作则事倍功半，因为失去了管理的最佳时机。通过创新一个模型工具，在开发阶段，自动管理数据字典和模型，实现下面三个落标操作。

1）建立标准和数据的映射

标准落地的属性继承

一般情况下，数据字段落地标准时要引用标准中上述内容，另还包含数据的标准代码，其中强制性一致的是标准中的技术规范。

物理字段的落地衍生

对于一个标准落地的物理字段，如果语义本质是相同的，并且业务规则没有变化，不过满足系统环境，而加上特定限定环境。比如“电话”在供应商的表里叫“供应商电话”，这是一种落地衍生情况，并不需要创建一个新的标准。

2）建立代码的标准引用

对字段中的数据类型的引用进行标准化，坚决杜绝Comment里手工写枚举代码的情况。

3）标准化命名

2.4.3模型的评审

在模型的开发基本完成后，在系统的测试阶段，我们加入模型的评审环节，这个作为系统上线的前奏，避免上线前的修改造成时间紧张等情况。模型评审前需要创建模型基线，评审包含以下几个内容。

1）标准的落标引用

模型工具应该自动提供报告，重点检查是否有重要的标准没有引用和落地，通过自动化的工具，智能发现落标的潜在问题。

2）自定义标准与词典的评审和转化

DDM模型工具具备自定义数据标准和词典等能力，通过与开发团队评审，提高自定义标准的转化率，完善标准库。

3）元数据的充足率

模型工具应该自动提供报告，列出中文名称没有填写的字段。

4）其他模型质量

比如检查模型主题覆盖率等。

2.4.4上线的核准

一般情况下，系统的上线过程需要一个更加标准的流程，提交设计、文档、测试报告、升级步骤等内容，有专业的团队和流程工具来审核。在这个过程中，并不主张此环节进行落标的核准，因为此环节已经太晚，笔者推荐在评审环节完成落标工作，在此环节中，只需要提交落标和模型报告作为过审文档。模型核准环节包含以下几个工作要做。

1）模型生产库基线与封板

根据评审时建立的模型分支，建立模型的生产库基线，并进行封板操作。

2）模型基线报告

提供模型标准数据字典，标准落标报告，模型质量报告。

2.4.5自动监测变化

对于已经发布的模型，随着进入维护期，某些升级的情况下，可能会有徒手修改库表结构的情况发生，为了保证模型与生产库的一致，在自动检测阶段，主要负责定期发现不一致的情况，并发出预警邮件，过程如下。

2.5新增和变更流程

在实际落标过程中，需要新增或修改标准的情况是必然出现的。因此在设计阶段或者模型评审阶段，进行变更流程。

2.6角色与人力安排

根据银行当前的组织结构，需要有建立“标准和架构组”，至少2人编制，可以是虚拟组织结构和兼职角色。

数据架构师（1人），由企业资深（10+年数据开发经验）数据设计人员或管理人员担任，熟悉行业数据模型和企业主流业务逻辑模型，比较熟悉各系统模型情况。主要负责模型管控，落标评审，模型质量等工作。

标准管理员（1人），由高级（5+年数据管理经验）数据标准设计和管理人员担任，比较熟悉标准和企业业务逻辑模型。 主要负责标准维护，标准评审，模型质量提高等工作。

2.7存量数据如何落标

存量系统的落标是很多企业进行标准化第一障碍，前面也进行了痛点分析，那么如何解决落标问题呢？笔者建议遵循以下方法。

1)存量系统先管理好数据模型和字典，这作为未来统一数据标准的基础。

2)摸清模型存量系统不符标准的情况，尤其是那些标准代码，编码规则，存储格式等严重影响数据指标和拉通汇集的情况。

3)根据非标问题的影响程度，制定未来的落标计划，选择合适的升级版本时机，进行逐项的落标。

4)未落标前，可以先落标ODS层或API层，这样可以纠正后期应用的标准化问题。

2.8标准代码的多标准处理

企业里存在多套标准是非常有可能的，比如一个客户类型的代码，原系统一套标准，数仓一套标准，报送EAST模型可能又是一套标准，那么怎么管理这多套标准呢？

1)建议对标准进行有效范围的定义，以明确每套标准的用途，比如原系统的标准作为地方标准，数仓的作为中央标准，EAST模型的标准作为对外标准。

2)建立标准之间的映射管理，做好数据拉通的依据解决。这样设计标准的维护和变更就可以重点选择哪里进行新增，以及如何进行统一等。

三成功案例-中国人寿

我们为中国人寿提供的数据治理整体解决方案的重要组成部分数据标准的落标。中国人寿在全国范围内有26个分支机构，为了保障公司级别系统的一致性和统一性，中国人寿采用Datablau的建模工具基于已有系统提取了基线模型并将标准落在数据模型的字段级别，并将实际的生产元数据跟基线模型绑定，每次系统发版通过比对功能发现生产系统与基线模型的差异，从而快速定位字段级差异并自动发送差异报告通知相关干系人，整个过程无需太多人工干预，治理效果直观有效。

依托建模工具的数据标准的强落地也使得全公司范围的数据标准推广及实施得以顺利进行，各部门的数据标准都汇集到一处，由专人统一管理数据标准的开发，审核，发布以及撤销的全生命周期，各部门只需从数据标准库里面选取对应的标准搭建数据模型。这种强管控的方式也使得数据标准的落地不再是纸上谈兵。

作者简介

王琤:北京数语科技有限公司（以下简称“数语科技”）创始人兼CEO王琤曾任职erwin全球研发总监，拥有超过十年以上数据建模和数据管理的从业经验。Datablau DDM数据建模产品和Datablau DAM数据资产管理平台两大部分组成，全部拥有软件著作权和知识产权，一站式全面满足中国企业的数据治理需求。其中数据建模产品DDM是Datablau填补国内空白的重量级产品，帮助中国客户摆脱国外产品的垄断现状。