关于数据标准的定义和开发 最后更新时间：2024年07月05日 # 1. 数据标准的定义和开发 ## a) 关于数据维度元信息设计的几个问题 1. 当数据维度为年度时，这个数据的统计逻辑是什么？是当年的新增数据？还是历年来累计到当前年度的数据？ 2. 统计时的逻辑如何？以项目为例：待建设项目是否算入项目个数中？已经建设完成的项目是否计算项目个数中？还是只要带了项目两字的都算做项目个数中？ ## b) 数据分层std层的设计与标准化 对于std的建设，一直认为算是数仓建设中的较为简单的一层，只需做好一些基础的，公共的数据属性的标准化，如（法人代表、法定代表人的称呼统一为法人代表，又如身份证号码，身份证，统一标准化为公民身份号码），以及一些基本的公共的数据结构的标准（如身份证的长度，日期时间的结构），然后就是对于一些脏数据，错误数据的简单清洗。 在实际开发的过程中，忽然思考到，其实std层需要做的事情不止如此，还应当规定一定量的系统信息的标准化录入，为增量或是处理简化的一些标准化录入的设计。如数据录入时间，数据来源，标识此条数据的唯一主键，数据自身的业务主键的标准化字段，以及数据自身的唯一值计算。 整个结构数据表结构应当如下： | **字段名** | **字段注释** | **释义及作用** | | ---------- | ------------ | ------------------------------------------------------------ | | body | 来源数据本体 | 这个并非某个特定字段，而是代指来源的整行数据 | | rksj | 入库时间 | 来源数据进入到数据库的时间 | | rkly | 入库来源 | 数据从何而来 | | wyzj | 唯一主键 | 标识这条数据唯一的字段，区别于下面的唯一值。该主键好比是单一数据的指纹，完全唯一地标识了该数据的唯一性，即世界上没有绝对相同的两片叶子，两条数据也不会绝对相同。即使是在业务的属性和属性值上完全相同，存储的位置，存储的时间，也会区别出这两条数据。假设一个来源数据中有两条相同的数据，那么通过该主键即可区分两条数据的唯一性 | | ywzj | 业务主键 | 一条数据，在业务逻辑上在去重后是绝对唯一的。有，也必然有可以区分两条数据的业务值（可以是一个字段，也可是多个字段），通过这些字段组合计算得到该主键（即构成一个复合键）。既可以简化后续仓库数据的处理，也可以简化数据业务上的更新或新增的逻辑，也同时对于不同来源数据的业务主键上的一个统一和标准化 | | zswyz | 自身唯一值 | 该值为来源数据本体连同入库时间，入库来源，以及唯一主键、业务主键拼接后，做哈希后得到的唯一值。是在系统中用于区别与唯一主键连同业务相同的数据都会唯一化，该字段主要目的是标注一条数据的唯一性。 | ## c) 数据标准定义的重要性以及如何定义的思考 此前工作中长久地认为，数据标准化的定义应当聚焦于一些常用的，或是常识的内容，对其名称加以定义和标准化，如（法人代表、法定代表人的称呼统一为法人代表，又如身份证号码，身份证，统一标准化为公民身份号码），以及一些基本的公共的数据结构的标准（如身份证的长度，日期时间的结构） 可以思考下面这个问题：统计政府的重点项目中有个字段叫省市重点，初看的时候可能不会引起讨论，但是仔细深究之后就会产生一个问题，即这个重点包括市重点吗？只要是省重点就算，还是既要是省重点，也要是市重点？以及可以思考另一个问题，就是部门名称，如市场监管局，也可以称呼为市监局或者市监管局。 诸如此类的如语法歧义、标准不一致等问题，在开发过程中会产生了一定程度的阻碍，导致开发过程不得不为了理解和处理这些数据而反复沟通，从而降低了工作的效率。 标准化的重点需要放到一些习以为常的，第一时间未必能引起重视的内容之上。此外也要注意，标准化是一个持续的工作。在开发过程中第一时间未必能考虑周全，需要有一个合适的地方去记录和解释标准化的内容，以便后续可以快速的补充，维护、和交接。以此避免A解决问题后，B看到某个内容，再次产生歧义的情况。有一个统一的，舒适的地方（如台账、系统、平台）去记录和管理这些标准化内容，可以有效地降低工作阻碍，提高沟通效果。
Comments | NOTHING