按关键词阅读:
最近工作中被代码表搞得头痛 , 正好接着之前发的行政区划代码一文接着讲讲代码表的一些知识和个人理解吧 。
本文插图
代码表有的也叫字典表 , 就是用数字或符号来替代某些具体含义的代码集合 。 像之前发的行政区划代码就是代码表的一种 , 而且是比较复杂的一种 。 通常我们所用的代码表像性别代码、民族代码就相对比较简单 , 可见下图(民族代码表):
本文插图
为什么采用代码表?
采用代码表的好处我认为主要就是规范表示 , 比如同样表达自己是汉族的 , 有的人说是汉、有的人说是汉族 , 还有的或说是han 。 当然说是没问题的 , 听者可能都会理解 , 但到了书面上 , 尤其是到了计算机系统内 , 这种不规范就会造成很多麻烦 , 也就是说数据质量有问题 。 现在经过这么多年信息化的发展 , 各项标准规范也在不断的完善 , 我们有各种国家标准、行业标准把诸如性别代码、民族代码、行政区划代码等等代码规范确定下来 , 然后我们在进行系统建设或者应用的时候就可以参照这些代码标准进行设计开发了 。
当然 , 各种代码标准规范不可能覆盖的那么全 , 比如我们工作中需要机动车车身颜色的代码表 , 这就没有国家标准 , 可能就是一个公安行业标准 , 需要相关部门制定并形成标准 。 我查了下这个代码在公安安全行标《GA 24.8-2005 机动车登记信息代码》中有规定 。 你可以想象像这样的需求不可能都能得到 , 比如我在系统中需要犯罪动机这么一个代码表 , 可能我就找不到对应的标准规范 , 或者类似的标准规范和我的需求不太匹配 , 那么我可能就会按照实际工作情况将数据进行简单的分类并形成代码表 , 供本系统或本类业务使用 。
所以久而久之 , 每一个业务系统都形成了一些自己独有的代码表 , 如果代码并没有上升成为相应的标准 , 原则上就只能本系统或者本类业务使用了 。 如果数据只是在业务系统内使用也还好 , 因为业务系统本身可以对数据及代码进行解释 。 但现在数据共享是潮流 , 我们要打破数据孤岛 , 就要把数据整合起来 。
数据整合部门的职责就是将各个前端业务系统中的数据汇集整合起来 , 那么代码表就是绕不开的一大部分 。 因为如果只是整合了数据却没有整合代码表 , 那么数据的含义是没法进行解释和翻译的 , 尤其是各系统中存在的独有的代码信息 , 所以在进行数据整合的时候一定要连同代码表一起整合 。
很多业务系统可能存在大量的代码表 , 一类信息恨不能用几十张代码表进行表示 , 这样也给数据整合部门带来了巨大的工作量 , 数据整合部门还要了解每类信息和代码表的对应关系和业务含义 , 同时基于共享的数据来对代码表进行取舍 。
在这里要说一下 , 普遍的 , 代码表在计算机系统中是单独存在的 , 比如性别代码是单独一张表 , 民族代码是一张表 。 如下图:
本文插图
这样的话有的系统会有几十张甚至上百张代码表 , 也给数据共享造成了一定的困难 。 于是也就有了整合的代码表形式 , 如下图:
本文插图
采用这样的形式可以把所有的代码放到同一个表中 , 然后在对数据进行解释翻译的时候先套用第一列中的代码类型 , 然后再找后面的代码所对应的具体含义 。 这样的好处是显而易见的 , 如对数据整合部门而言 , 原来需要整合数十张乃至上百张代码表 , 现在只需要整合一张表就可以了 。分页标题
但这种形式也存在一个问题 , 就是代码变动的问题 。 我们从前面的文章中知道行政区划代码会频繁的变动 , 如果一个代码表中整合了行政区划代码 , 会导致整个代码表会频繁变动 。 那么我们整合代码表变得不再是一劳永逸 , 可能需要频繁的变动 , 比如每天都要同步代码表 , 这样也会增加工作量 。 甚至比如某次整合任务失败 , 那么我们连最简单的性别代码也就失去了 。
所以我建议代码表的数据库设计可以是将一般不变的代码整合到一张代码表中存放 , 变化的代码表单独存放 , 这样进行数据整合时只需要及时更新变动的代码即可 。
话说回来 , 其实数据整合部门在代码上耗费最大精力的恰恰还是那些常用的代码 , 这些代码也就早有标准规范 。 拿最简单的性别代码来讲 , 国标《人的性别代码》(GB 2261-1980)中规定:
0 - 未知的性别
【埃尔法哥哥数据规范之代码表】1 - 男性
2 - 女性
5 - 女性改(变)为男性
6 - 男性改(变)为女性
9 - 未说明的性别
当然我们最常用的是1(男性)和2(女性) 。 虽然有这个标准 , 但在各业务系统中 , 性别项的表示可谓五花八门 , 有不填代码的 , 如记录里填写的就是"男"、"男性"、"女的"等等汉字 , 或者"MALE"等英文表达 , 这些是属于不用代码规范的 。 还有用独有代码表的 , 比如"F"代表女性、"M"代表男性 。 更有甚者 , 自造的代码表是"0"代表男性、"1"代表女性 。
本文插图
数据整合部门就要耗费精力来解决这些问题 。 当把上述各业务系统中数据整合起来之后 , 就不能用标准代码来对数据进行翻译 , 尤其是最后一种情况 , 如果这样操作恰恰会把数据翻译错 。 这种情况下 , 我们需要同步每个系统的代码表 , 然后基于每个系统的代码表对其数据进行翻译 , 然后再统一对应到标准代码上去 。 如下图:
本文插图
尽管有标准规范可以对照执行 , 这样的数据整合工作还是非常繁杂琐碎的 。 如果想在后期数据整合信息共享工作上轻松顺畅 , 那么我们的标准规范一定要全流程覆盖 , 也就是说标准规范肯定不只是数据整合共享工作的事 , 更是前端业务系统的事 。
前端业务系统在系统设计时就要按照相应的标准规范进行 , 在本篇中就要遵照代码标准规范 , 后面的文章还会讲其他的数据规范 。 代码该采用国标的采用国标 , 该采用行标的采用行标 。 这样不仅在本业务系统中对数据进行了规范 , 更有利于后面的数据整合和数据应用 。 因为大家都采用了同一套代码规范 , 就省却了很多的数据整合工作 。
理想很丰满、现实总是很骨感的 。 前端系统完全遵守相应标准的少之又少 , 原因也好理解 , 同样情况下这样做肯定增加了前端系统的设计及开发工作量 。 如果没有一套制度对系统建设的标准问题进行约束的话 , 很难对现状带来实质性的改变 。
所以在我看来 , 整个行业的信息化工作需要通盘考虑 , 尤其是标准规范方面 , 要做到全行业的统一 。 在数据的最前端 , 如业务系统等数据采集端就要严格遵守相应的标准规范 , 不符合标准规范就不能允许其上线运行 。 标准规范要贯穿数据的整个生命周期 , 从数据采集到数据整合再到数据应用 。
(结尾很突兀 , 因为接下来还会有类似的内容)
来源:(埃尔法哥哥)
【】网址:/a/2020/0518/1589735508.html
标题:埃尔法哥哥数据规范之代码表