[目录]
第一章(概要第二章)整体数据分层第三章)整体实现框架第四章)元数据第五章) ETL第六章)数据验证第七章)数据标准化第八章)重量级第九章)增量/总量第10章(紧固件处理第11章)分布式处理增量第12章)列存储第13章)逻辑数据模型)数仓模型)第14章)数据模型参考第15章)维度模型第16章)渐变维度第17章)数据回滚第117章) ——数据标准化数据标准化是数据仓库建设过程中的另一个企业必须建立自己的数据标准，才能建立基本统一的数据仓库模型。 数据标准有很多理论标准。 例如，国家标准有《数据元的规范与标准化》。 这里称为数据源。 不是我们之前讨论的元数据。 虽然有点近。 简而言之，这个标准是说明数据的描述方法。 它比表格和字段的说明更基础。 我以前为几家银行做了数据标准的事。 当我对这项工作有深入的了解时，我发现这是一项非常繁杂的工作。 另外，业务发展，新数据层出不穷，标准交付件的维护也非常困难。
其实，数据标准化首先是语义标准化，如果同一个“名称”可以代表同一个，不同的“名称”可以代表不同的，我想标准化将是胜利的大部分。
从构建数据仓库的角度看，数据标准化可以分为两个层次：
实体和属性命名标准化：主要是指放置在仓库中的表的名称和表字段的命名标准化。 代码标准化：代码是指区域、行业分类等代码，是数据内容之一，但多与统计分析角度相关。 现实中，往往可以自己制定适合自己，甚至更好的数据标准。 但是，约束别人一般很困难，比如购买新软件。 供应商很难按照你的标准修改自己的数据库。 那几乎都是软件的重新开发。 但是，这样的标准确实值得：
减少数据使用的模糊性。 相同的标志代表不同的东西。 例如，address可以表示地址，也可以表示办公室地址，或者在一个系统中男女用f/m表示，在另一个系统中用01/02表示，等等，在同一意义上有多种表达方式。 基本上，如果不调查元数据定义(数据词典)，就很难知道实际的意思。 降低分析系统的设计难度。 标准化后，对于基于统一数据模型的分析APP应用来说，设计简单，直接针对标准进行开发即可，无需考虑很多情况。 指导和制约自己的交易系统开发。 独自开发交易系统，利用数据标准进行指导和约束，减少数据错误的概率。 我遇到过一家银行的两个业务系统使用不同的科目表，甚至子目的水平也不同。 那是相当悲伤的事。
实体和属性标准化实际上往往是文本工作。 首先给每个表取个好名字。 我喜欢用普通号码英文名。 编号规则如下。
域号表号
域是数据模型中的主题域，一般分为参与者、协议、产品等，根据情况可分为7、8到10个。 整体号码一般不要太长，三四个人最好。 英文名直接使用反应实际意义的英语单词或一般使用的缩写。 总之目的是尽量消除歧义，容易记忆。
属性(字段)直接使用反应实际意义的英语单词或缩写。 一些字段的名称在翻译后会变长，因此会创建特定的缩写。 字段命名重要的是，对不同表中具有相同含义的字段使用相同的名称。
元数据可描述数据的数据规范化描述内容，例如标准命名、含义、数据类型、取值范围、启用时间、维护管理机构等。 大多数信息是否正确不会影响系统的运行，但如果数据有问题，跟踪并排除问题非常重要。 毕竟，每个系统的每个模块都必须找到相应的负责人来解决。
代码是地域、行业、性别、学历等各种分类代码，系统很多。 而且这些代码对统计来说非常重要，往往是现成的统计维度。 标准化代码维护是一个长期的过程，会随着业务的发展和国家标准的改变而持续进行。 代码变更对系统的影响难以预测，特别是在统计分析类系统中，部分代码的变更会引起统计口径的变更，需要对历史数据进行大幅度的修改。
由于代码更改导致的数据波动通常是不可自动化的，因此代码标准化系统应该被认为是基础数据的存储，以便于其他系统获取标准化代码。
对于新系统的建设，首先应该参考标准化系统的代码标准，尽量照搬系统中的标准化代码，而不应该自行设置代码规范自行进行维护工作。
从代码的权威性来看，代码分为两类。
权威代码：国家部委、政府机构、国际组织等权威机构发布的代码标准自定义代码：系统自行定义的代码； 一般来说，权威代码是权威的，数据也是最全面的，因此在设计系统时，应该尽量考虑采用这样的代码。 总之，在数据仓库中，创建标准代码的工作如下
使用授权代码，在源系统中存在超过授权代码的部分时进行扩展； 对于同一代码，使用所有系统中此代码的所有值的集合，并根据统一规则进行重命名。 例如，多个系统具有产品分类，重新定义一组产品分类或引用zxdrs中所有系统的分类。 如果有标准代码，接下来就是源系统代码和标准代码映射关系的维护。 制作好的数据维护工具是个不错的选择。
可以使用以下元素编写标准化代码：
代码分类代码； 性别代码等代码分类名称，SEX； 代码分类提示F/M表示男女的代码值代码业务意义有效化时间； 无效化时间； 修订者； 责任机构； 业务分类； 源系统； 应用系统； 是否有适用系统映射规则的相应权威机构
代码标准；权威机构代码标准说明等；不分代码存在归属关系，比如地区、机构、科目等。一般情况下，这种归属关系可以采用树状结构来描述。但在一些复杂的业务场景，一方面，归属关系会变化，另一方面可能存在多种归属关系。如对于地区代码来说，我们可以用行政区域归属（省、市等）来对地区进行 分类，也可以使用经济区域（东部地区，中部地区，西部地区等）来进行统计。因此，归属关系也存在一个标准化的定义：
代码归属类型编码，如地域归属，或管理归属等；代码归属类型说明；代码分类编码，如地区；当前代码；所属代码；启用时间；停用时间；修订者；当然，这里讨论的标准化的方式是比较复杂的，做起来代价是比较大的。而比建立标准更难的地方，则是如果持续的应用标准、维护标准。这基本上已经超出软件系统的范畴了。
未完待续。
上一篇：数据仓库实践杂谈（六）-数据校验
下一篇：数据仓库实践杂谈（八）-去重