数据标准的制定落地

目录

什么是数据标准

基本定义

目的

数据标准体系分类

从内容层面分类

从管理视角分类

从面向的对象分类

从数据结构的角度分类

数据标准价值

业务价值

技术价值

管理价值

数据标准和数据治理的关系

数据标准在数据治理各项任务中的作用

数据标准与主数据

数据标准与元数据

数据标准与数据质量

数据标准分类框架

基础数据标准

主题

一、二级分类

指标数据标准

数据标准内容框架

业务属性

技术属性

管理属性

数据标准系统落地

落标范围确认

数据字典收集

数据标准完善

落标分析

落标执行

落标检查与管控

实际项目元数据标准制定流程

定义数据元要素

全量采集标记元数据

计算元数据近似重用率

相近排序全部元数据

过滤公共数据元

过滤非核心业务元数据

初步定义数据元

样例数据抽取补充

排重合并数据元

异义新增数据元

数据元审定

元数据标准实际制定示例

归集所有元数据

新元数据标准制定筛查

根据筛查结果合并确定新数据元的定义

---

什么是数据标准

基本定义

数据治理是数字化转型基础的前提，数据标准体系的建立是数据治理的基础性工作。

对于企业而言，数据标准就是对数据的名称、数据类型、长度、业务含义、计算口径、归属部门等定义一套统一的规范，保证各业务系统对数据的统一理解、对数据定义和使用一致。

数据标准是通过一整套的数据规范、管控流程和技术工具来确保企业的各种重要星系，包括产品、客户、组织、资产等在全企业内外的使用和交换都一致、准确，是组织内与数据标准制定、发布、修订、复审、落地相关的涉及组织架构、人员职责、规范流程、系统该站、技术工具支撑等工作体系。

用通俗一点的话来讲，我们需要在组织内定义一套关于数据的规范，好让我们都能理解这些数据的含义。比如在银行业，对于“客户”这个字段，往往不同部门的理解都会出现偏差，可能客户部就认为“客户”就是办了他们银行的卡的人，而网银部认为是在他们的银行网站注册过、或者通过这个银行转账的人都属于客户。就这样没有统一标准的话，不仅增加沟通成本，而且项目实施、交付、信息共享、数据集成、协同工作往往会出现各种问题，这些花了大代价的数据就体现不出应有的价值。

而数据标准管理就是将这一套数据标准，通过各种管理活动，推动数据进行标准化的一个过程，是数据标准落地必不可少的过程。

数据标准是一经制定、发布就相对稳定的静态数据资产。

目的

为了实现在组织内部对数据的理解和使用的统一，为此进行数据业务属性（中文名称、业务规则）、技术属性（数据类型、数据格式）、管理属性（数据定义者、管理者）、安全定级（安全等级）等的权威定义。

数据标准体系分类

数据标准的分类是从更有利于数据标准的编制、查询、落地和维护的角度进行考虑的。

从内容层面分类

业务术语

业务术语是面向业务部门的，明确业务部门在经营管理活动中使用的业务定义、业务规则、统计口径。例如定义“资产”这一业务术语：“资产是指由企业过去的交易或事项行程的、由企业用友或控制的、预取会给企业带来经济利益的资源”。

业务数据标准

是数据管理部门基于业务术语进行的标准化规范，相较于业务术语，建立标准索引、设置业务主题归类、对照进行数据安全分类分级、设置必要的质量规范定义。

业务数据标准又分为基础数据标准和指标数据标准。

基础数据标准是基于业务开展过程中直接产生的数据制定的标注化规范，例如各种枚举值编码标准。

指标数据标准是按使用场景分类，针对为满足内部分析管理需要以及外部监管需求，对基础类数据加工产生的指标数据制定的标准化规范。

技术数据标准

是面向技术开发部门的，是业务数据标准的开发实施参照与依据，规范了标准、字段的命名规则等。

从管理视角分类

业务角度

根据不同的业务主题进行细分，例如财务数据标准等。

根据数据类型又可以细分为代码标准、编码标准、日期标准等。

根据标准来源可以分为国家标准、监管标准、行业标准等。

技术角度

分为业务术语标准、参考数据和主数据标准、数据元标准、指标数据标准。

从面向的对象分类

内部数据标准

企业内部的业务流程和经营产生的数据，例如客户欣喜、交易记录等。

制定内部数据标准时需要从源头上把我数据质量。

外部数据标准

为了实现从公共领域获取的数据和购买的数据等的融合，制定的统一的数据标准。

从数据结构的角度分类

结构化数据标准

信息项分类、类型、长度、定义等。

非结构化数据标准

文件名称、格式等。

数据标准价值

业务价值

数据在企业有一个全局的定义，减少各部门各系统的沟通成本，实现业务管理的规范化，提升企业业务处理的效率。

又主语数据统一、规范管理，方便数据的共享，另一方面对于业务人员来讲，可以更轻松获取数据，理解数据进行数据分析，为业务创新提供可能。

技术价值

消除数据跨系统的非一致性，从根源解决数据定义和使用的不一致问题，为企业数据建设带来好处：

1. 保证数据定义和使用的一致性，促进企业级单一数据视图的形成，促进信息资源共享。
2. 评估已有系统的标准建设情况，及时发现系统标准问题，支持系统改造，减少数据转化，促进系统集成，提高系统间的交互效率。
3. 作为新建系统的参考一句，减少系统建设工作量，保障新建系统符合标准。

提升企业的数据需求开发质量，为经营决策提供准确、全面的数据。数据标准化清晰定义数据质量规则、数据的来源和去向、校验规则，提升数据质量。

管理价值

使得数据质量校验有据可依，为企业数据质量的提升和优化提供支持。

提升数据处理和分析效率。

对经过处理的高质量数据资产进行统一管理，涉及体系化的数据资产目录，提供全生命周期的管理，并建立各类业务应用的数据资产视图，方便数据的展示和数据共享，更好支持经营决策、精细化管理、为数字化转型打基础。

数据标准和数据治理的关系

数据标准在数据治理各项任务中的作用

数据标准与主数据

数据标准包括模型数据标准、主数据标准、参考数据标准、指标数据标准等，主数据是数据标准的一个子集。

数据标准与元数据

元数据是制定数据标准的基础，在制定数据标准的时候要先明确数据业务属性、技术属性和管理属性。

元数据通常由标识符、中文名称、英文名称、缩写名、定义、数据类型、值域、约束/条件、最大出现次数和备注构成，如下：

a) 标识符：用于唯一表示元数据的字符串。

b) 中文名称：元数据的中文名称。

c) 英文名称：元数据的英文名称。

d) 缩写名：元数据的英文名称缩写。

e) 定义：元数据含义的解释。

f) 数据类型：元数据的有效值得类型。

g) 值域：元数据所允许值得集合。

h) 约束/条件：说明元数据是否选取的描述符。分为必选、可选和条件必选。

i) 最大出现次数：元数据可以出现的最大次数，只出现一次的用“1”表示，多次重复出现的用“N”表示。

j) 备注：对元数据的进一步补充说明。

元数据可以为数据说明其元素或属性（名称、大小、数据类型），结构（长度、字段、数据列），相关数据（位于何处、如何联系)。

数据标准与数据质量

数据标准是衡量数据质量的重要依据。数据标准可以明确归口部门和责任主体。

数据标准分类框架

基础数据标准

基础数据标准是指企业日常业务开展过程中，对直接产生和采集的、未经过加工和处理的原始信息制定的标准化规范。

主题

根据业务归属把基础数据标准划分为不同主题，例如：

客户主题：与企业有联络、与企业有关系，以及企业希望保留的所有相关客户信息项。

内部机构主题：设置在企业内部，负责处理企业对内、对外工作的组织机构及员工信息项。

产品主题：企业及其关联的当事人提供给市场，能满足客户的某种需求，企业可从中赚取各种实际或潜在收益的货物与服务信息项。

事件主题：满足客户的服务需求或自身的管理需求，进行实现价值转移、服务提供的活动信息项。

协议主题：两个或两个以上当事人之间潜在或实际的约定，在协议中正式明确与协议目的相关的各项规则和协议各方义务的信息项。

渠道主题：渠道是指企业为客户提供各种服务的途径，包括电子渠道(如微信、支付宝等)和非电子渠道(如客户经理等) 信息项。

财务主题：描述企业科目组织、总账以及预算管理等数据信息项。

资产主题：企业拥有、管理、使用的，或企业关心的其他当事人拥有的，有形或无形的有价值的东西，如房屋、商品、土地、现金等信息项。

公共信息主题：其他主题中具有一定共享性的内外部标准，如币种、行业、国家地区等内容信息项。

一、二级分类

对已经确定了主题后的数据标准进行细化，制定每个主题下的一、二级数据标准框架，例如：

标准主题	一级分类	二级分类
产品	产品个性信息	存款产品
产品	产品个性信息	贷款产品
产品	产品个性信息	组合产品

指标数据标准

通常讲指标数据标准划分为业务管理、风险管理、客户管理、运营管理、财务管理等类型，和基础数据标准类似的是可以结合实际情况，对刚刚的几个类再进行细分，形成指标数据标准框架，例如：

一级分类	二级分类
业务管理	信用业务
业务管理	经济业务
财务管理	财务分析

数据标准内容框架

通常通过业务属性、技术属性、管理属性来制定标准内容框架。

业务属性

包括标准中文名称、英文名称、业务定义、业务规则、制定依据等。

技术属性

包括英文缩写、数据类型、数据格式、计量单位、权威系统等。这里将英文名称作为技术属性主要是因为以便基于它形成物理模型的表名和字段名。

管理属性

描述数据标准与数据管理相关联的特性，包括标准编号、标准主题分类、发布日期、标准状态、信息维护者、版本信息、数据主管部门、数据生产部门、数据使用部门等。

数据标准系统落地

落标范围确认

落标范围遵守如下原则：

不宜太广，以重要系统为主，逐步扩大范围。

数据字典收集

收集的信息巷主要包括表级信息、字段级信息、字段代码信息等，还要进行关键信息项的采集、补全，字段中文名称必须完整。

通过校验规则对整理好的数据字典进行校验，进行整改。

数据标准完善

将梳理好的数据字典按照使用频率、重要性等维度进行提取，将提取的数据项合并至基础数据标准中，补充业务属性、管理属性、技术属性等。

落标分析

针对字段中英文名称、类型长度、字段码值进行对标。

落标执行

对于已建系统，通过建立数据字典和数据标准之间的映射，优先进行字段中文名称改造，然后选择合适的实际，例如再系统升级改造时对数据类型、长度、码值进行改造。针对已建系统的新增表字段执行落标。

对于新建系统，强制按照数据标准进行数据库涉及，尤其是数据类系统，如数仓、中台、数据集市等。

落标检查与管控

针对已建系统和新建系统采取不同的落标方案、检查和管控方案。

实际项目元数据标准制定流程

定义数据元要素

数据元要素:

• *数据元编号：DE00001
• *数据元名：XBDM
• *中文简称：性别代码  
• 类型长度：nvarchar2(50)    
• *类型：C..
• *长度：50
• 代码集编号    
• 代码集名称    
• 值空间    
• 解释/举例

全量采集标记元数据

• 全量：尽量覆盖90%以上的系统数据库库表字段；
• 采集：归集所有库表字段和接口参数、文件资源信息项的五要素到数据集。其中五要素包含：元数据名称、中文注释、数据类型、数据长度、数据代码集。
• 标记：将元数据的来源部门、系统代号、敏感级别标记上。
• 元数据：所有库表字段和接口参数、文件资源信息项，可反向通过数据资源目录提取。

计算元数据近似重用率

• 重用率：相同的元数据出现的次数，大于100%视为有被重复使用，具备定义数据元的必要性。
• 近似重用率：根据元数据的名称、类型进行比较判断，计算相近含义数据元的重用率。
• 意义：近似重用率能有效反应元数据重用概率的真实情况。

相近排序全部元数据

• 相近：即根据上一步骤的近似重用率的计算，将含义相近元数据进行分别汇聚。
• 排序：以相近特征进行排序，实现元数据的分类汇聚。

意义是便于人工排查处理。

过滤公共数据元

• 公共数据元：通过各种渠道收集确定的国标中的数据元：如人员性别、婚姻、职业等相关数据元。
• 过滤公共数据元实质是过滤元数据中已经与公共数据元重复的元数据。

意义是避免数据元重复定义。

过滤非核心业务元数据

• 非核心元数据：通过全量采集标记元数据时对数据来源（委办局）、业务系统、敏感级别的标记，确定其属于非核心范围。
• 过滤非核心元数据，实质是过滤没有作为数据元价值的元数据，保证数据元的权威性。

意义是守住数据元定义的底线。

初步定义数据元

• 按照定义数据元要素对相关要素的定义，使用现有数据元的相关属性匹配填充相关要素内容。
• 根据不同的数据库导出的数据库库表结构情况，需要适配不同数据数据类型进行转换。

一般通过程序实现较为合理，能简化相当一部分的工作量。

样例数据抽取补充

• 根据初步定义的数据元的元数据信息（来源）提取当前数据元的样例数据，便于查证鉴别。
• 样例数据包括：最大长度、最大值、最小长度、最小值、代码值域等。
• 最大长度和值利于确定相近数据元的最大数据长度、数据类型。

最大小值和代码值域利于确定当前数据元是否存在中文和代码值同时使用的情况。

排重合并数据元

• 根据样例数据对比相近数据元是否重复，如果是重复数据元，则合并为单独的数据元。
• 合并时：数据元类型应以多个同类近义数据项的设计类型和数据值实际类型比较确定，应以实际数据值的数据类型为第一优先级。数据长度应以合并中的各数据元中的最大值长度为准。数据元名称应该以无二义性为根本原则。
• 样例情况如：审批标识、审批标志、审核状态等，可以根据实际代码值进行判断，如果代码值共同包含了待审核、通过、不通过、驳回等，那么视同为同一个数据元，应当予以合并。其中要与“是否审核”这样的数据元进行区分，是否审核的代码值一般为是、否，与前面的情况截然不同。

该环节建议人工执行。

异义新增数据元

• 相近或相同名称数据元因为业务含义确实不一致的情况，视为新数据元进行新增定义。
• 样例情况如：登记类型在不同业务流程中登记类型其码值和业务含义都完全不一样，应当根据业务场景下的具体含义进行重新定义，可以定义为社保卡登记类型、养老待遇申请登记类型、工伤待遇申请登记类型、机动车登记类型等等。

该环节建议人工执行。

数据元审定

• 审定制定的数据元是否合理合规。
• 审定一般遵循以下原则：数据元名称是否重复是否合规（是否符合命名规则）、数据元数据类型似符合数据值实际使用需求、数据长度是否满足数据值的实际需要，数据类型长度是否符合国家规定的要求。
• 审定常见的问题：
• 数据元名称和已有数据元名称重复；
• 数据名称命名不合理，如“性别”，其合规命名为’性别代码’。
• 数据元类型长度不合理，如numeric(12)无法满足numeric(12,2)实际情况。
• 数据元类型不合理，如：有代码集的数据元，其类型应建议使用char，而非varchar或者nvarchar类型，日期类型建议使用date，时间类型建议使用timestamp(6)，另外’c代表char，c..代表nvarchar2，d代表date，t代表timestamp(6)，n代表numeric(x)，n..()代表numeric(x,y)’

元数据标准实际制定示例

上面说的还是比较偏理论，下面举一个比较实际的例子。

归集所有元数据

方法很多，下面举一个例子，直接使用SQL去读取数据库中，表的元数据。

SELECTA.OWNER,A.TABLE_NAME AS TABLE_NAME_EN        --英文表名,B.COMMENTS   AS TABLE_NAME_CN        --中文表名,A.COLUMN_ID                          --字段序号,A.COLUMN_NAME AS COLUMN_NAME_EN      --字段名称,C.COMMENTS AS COLUMN_NAME_CN         --字段注释,A.DATA_TYPE               --字段类型,A.CHAR_LENGTH             --字段长度,A.DATA_LENGTH             --数据长度,A.DATA_PRECISION           --数据精度,A.DATA_SCALE              --小数位FROM ALL_TAB_COLUMNS A          --表与字段信息LEFT JOIN ALL_TAB_COMMENTS B   --表名信息ON B.OWNER = A.OWNERAND B.TABLE_NAME = A.TABLE_NAMELEFT JOIN ALL_COL_COMMENTS C   --字段名信息ON C.OWNER = A.OWNERAND C.TABLE_NAME = A.TABLE_NAMEAND C.COLUMN_NAME = A.COLUMN_NAME--WHERE OWNER='ZZGA_ZYZH'--  AND A.TABLE_NAME IN ('JG_VIO_PZGL','T_WP_CAR')ORDER BY A.OWNER,A.TABLE_NAME,A.COLUMN_ID

新元数据标准制定筛查

将归集的元数据中筛选出“出生日期”类元数据。

根据搜索可以发现，相同的字段在不同库表的数据类型和长度是可能完全不一致的。

比如有date和varchar等类型，字符串类型也是各种长度都有。

根据筛查结果合并确定新数据元的定义

如下：

数据元标识符：DE0008数据元名称：CSRQ数据元中文：出生日期类型长度：date类型：d长度：无注：名称使用拼音；类型使用date符合数据实际类型，便于数据统一使用。