数据仓库实践杂谈（七）——数据标准化

数据标准化是数据仓库建立过程中的另一个难点和重点。可以说如果企业没有建立自己的数据标准，基本上是无法建立统一的、整合的数据仓库模型的。数据标准有很多理论标准的，比如，国家标准有一个叫《数据元的规范与标准化》。这里叫数据元，不是我们前面讨论的元数据，虽然有点接近。简单的来说，这个标准就是描述了如何描述一个数据。比起对表和字段的描述更基础了一层。本人之前有一段时间专门为几个银行做了数据标准的事情。对此工作深有体会，发现这是一个非常繁琐的工作，而且业务不断发展，不断会有新的数据进入，标准交付物维护难度也非常高。

其实我认为，数据标准化首先是语义上的标准化，能做到同一个“名称”表示同一个事物，不同的“名称”表示不同的事物，标准化就胜利一大半了。

从数据仓库建立的角度，数据标准化可以分成两个层面：

实体和属性的命名标准化：主要指放到仓库里面的表的名字和表中字段的命名规范化。
代码标准化：代码指的是类似地区、行业分类等代码，是数据内容之一，但往往跟统计分析的角度关联。

现实的情况往往是你可以自己建立一套适合自己，甚至很好的数据标准。但你一般很难约束别人遵守，比如采购一套新的软件。供应商很难按照你的标准去修改自己的数据库，那几乎就是重新开发一套软件了。但是这样的标准确实是有价值的：

减少数据使用的歧义。同一个标志符表示不同的东西，比如address有些地方表示住址，有些地方表示办公地址；或者同一个内涵多种表示方式，比如某系统用f/m来表示男女，另一些用01/02表示。基本上，不去查元数据定义（数据字典）很难知道其实际含义。
降低分析系统的设计难度。标准化之后对于整合数据模型基础上的分析应用来说，设计简单了，针对标准直接开发即可，不需要考虑多种情况。
指导和约束自有交易系统开发。如果自行开发交易系统，利用数据标准进行指导和约束，减少数据错误的几率。

曾经碰到过一个银行两套业务系统使用了不同的科目表，连子目层次都不一样，那是相当的难过。

实体及属性标准化其实更多是一个文字工作。首先把每张表都有一个良好的命名。我一般喜欢用编号+英文名。编号规则为：
域编号+表编号

所谓域，是数据模型中的主题域了，一般分为参与方、协议、产品等，根据实际情况，能分出七八个到十几个不等。整个编号一般别太长，三四位最好。英文名直接用反应实际意思的英文单词或者约定俗成的缩写。总之目的是尽量消除歧义，容易记忆。

属性（字段）直接用反应实际含义的英文单词或者缩写。有一些字段的名字翻译过来会很长，就创建一个特定缩写。字段命名很重要的地方是不同表里面同样内涵的字段要使用同样的名字。

至于数据元规范中对一个数据的规范性描述内容，比如标准命名，含义，数据类型，取值范围，启用时间以及维护管理机构等信息，都可以在元数据中描述。虽然大部分信息是否正确并不影响系统的运行，但如果数据有问题的时候，溯源追踪排查问题很重要。毕竟，每个系统每个模块都是得找到对应的负责人才好解决的。

所谓代码，如地区、行业、性别、学历等各种分类代码，系统会有很多。而且这些代码对于统计来说非常重要，往往就是现成的统计维度。标准化代码的维护是一个长期的过程，随着业务发展和国家标准的变更会持续的进行。代码的变更对系统的影响是难以预计的，尤其是统计分析类系统，部分代码的变更会引起统计口径的变更，需要对历史数据进行大量的修改工作。

由于代码变更引起的数据变动通常无法自动化的进行，因此，应该把代码标准化系统看作是一个基础数据的存储，能够以方便的形式被其他系统获取标准化的代码。

对于新系统的建设，应该首先参考标准化系统的代码标准，尽可能直接采用系统中的标准化代码，而不应该自行设立代码规范并各自进行维护工作。

从代码的权威性来看，代码分为两大类：

权威代码：由国家部委、政府机构、国际组织等权威机构所颁布的代码标准；
自定义代码：由系统自行定义的代码；

一般来说，权威代码具有权威性，数据也最为全面，在设计系统的时候，应该尽量考虑采用此类代码。可以总结出来，在数据仓库，建立标准代码的工作是：

使用权威代码，如果源系统有超过权威代码的部分，则扩展进来；
对于同一个代码，采用所有系统的此代码所有值的合集，并按统一规则重新命名，比如多个系统都有产品分类，重新定义一套（或者参考其中最完备的一套）产品分类，容纳所有系统的分类。

有了标准的代码，剩下就是源系统代码和标准代码的映射关系的维护了。做一个好的数据维护工具是不错的选择。

标准化代码可以通过如下要素来描述：

代码分类编码；
代码分类名称，比如性别代码，叫SEX；
代码分类提示说明；
代码值，如F/M代表男女；
代码业务含义；
启用时间；
停用时间；
修订者；
负责机构；
业务归类；
来源系统；
应用系统；
应用系统的映射规则；
是否有对应的权威机构代码标准；
权威机构代码标准说明等；

不分代码存在归属关系，比如地区、机构、科目等。一般情况下，这种归属关系可以采用树状结构来描述。但在一些复杂的业务场景，一方面，归属关系会变化，另一方面可能存在多种归属关系。如对于地区代码来说，我们可以用行政区域归属（省、市等）来对地区进行分类，也可以使用经济区域（东部地区，中部地区，西部地区等）来进行统计。因此，归属关系也存在一个标准化的定义：

代码归属类型编码，如地域归属，或管理归属等；
代码归属类型说明；
代码分类编码，如地区；
当前代码；
所属代码；
启用时间；
停用时间；
修订者；

当然，这里讨论的标准化的方式是比较复杂的，做起来代价是比较大的。而比建立标准更难的地方，则是如果持续的应用标准、维护标准。这基本上已经超出软件系统的范畴了。

未完待续。

上一篇：数据仓库实践杂谈（六）-数据校验

下一篇：数据仓库实践杂谈（八）-去重

数据仓库实践杂谈（七）——数据标准化相关推荐

数据仓库实践杂谈-（二）-数据分层
[目录] 第一章:概述第二章:整体数据分层第三章:整体实现框架第四章:元数据第五章:ETL 第六章:数据校验第七章:数据标准化第八章:去重第九章:增量/全量第十章:拉链处理第十一章: ...
数据仓库实践杂谈（十七）——数据回滚
[目录] 第一章:概述第二章:整体数据分层第三章:整体实现框架第四章:元数据第五章:ETL 第六章:数据校验第七章:数据标准化第八章:去重第九章:增量/全量第十章:拉链处理第十一章: ...
数据仓库实践杂谈（六）-数据校验
[目录] 第一章:概述第二章:整体数据分层第三章:整体实现框架第四章:元数据第五章:ETL 第六章:数据校验第七章:数据标准化第八章:去重第九章:增量/全量第十章:拉链处理第十一章: ...
数据仓库实践杂谈（八）——去重
[目录] 第一章:概述第二章:整体数据分层第三章:整体实现框架第四章:元数据第五章:ETL 第六章:数据校验第七章:数据标准化第八章:去重第九章:增量/全量第十章:拉链处理第十一章: ...
金融数据仓库系列-统一指标数据标准化
在工作经常会碰到与业务或者运营人员沟通需求的时候,自己理解和需求得出的数据不一致.这一部分是由于对产品对业务理解的不够透彻另一方面也存在数据源口径不一致的问题,因此在做数据治理或者数据仓库标准化的实时 ...
Hive数据仓库实践——日期维度数据装载
本文涉及技术:Linux.Java.Hive.MySQL.Shell.Kettle.JavaScript.HDFS.存储过程. 需求:统计各商品的日销售额,月销售额,季度销售额以及年销售额: 在操作型 ...
Greenplum 实时数据仓库实践（6）——实时数据装载
目录 6.1 建立数据仓库示例模型 6.1.1 业务场景 1. 操作型数据源 2. 销售订单数据仓库模型设计 6.1.2 建立数据库表 1. 在MySQL主库中创建源库对象并生成测试数据 2. 在Gr ...
数据缺失，数据异常，数据标准化的处理方法
数据缺失一.缺失值产生的原因缺失值的产生的原因多种多样,主要分为机械原因和人为原因.机械原因是由于机械原因导致的数据收集或保存的失败造成的数据缺失,比如数据存储的失败,存储器损坏,机械故障导致某段 ...
2021爱分析･数据智能平台实践报告—重构数据智能时代的数据基础设施
报告编委报告指导人黄勇爱分析合伙人&首席分析师报告执笔人洪逸群爱分析高级分析师莫业林戴甜爱分析爱分析分析师分析师外部专家(按姓氏拼音排序) 方磊九章云极董事长 ...

数据仓库实践杂谈（七）——数据标准化

数据仓库实践杂谈（七）——数据标准化

数据仓库实践杂谈（七）——数据标准化相关推荐

最新文章

热门文章