数据建模师都应该知道的「数据标准化」

发布日期:
2024-04-28

浏览次数:

“标准”这个词一出现,就会给人一种“权威、规范、统一”的感觉。“标准”后面加一个“化“字就变成了动词“标准化”,它的意思就是把一些杂乱无章、没有基准的东西,按照某种基准或规则,让他们变得具备代表性、一致性和准确性的过程。

由此可知,数据标准化(DS:Data Standardization)的关键就是按照一定的基准或规则,让不一致的数据变得一致的过程。

乍一看这个词可能还是有点搞不懂什么叫“让不一致的数据变得一致”,以及怎么才能让数据达到标准化的要求。

简单来说,数据标准化要做到三个一致,名称一致、含义一致、域一致。

比如,每个中国人都有自己的“身份证号码”,也可以叫“身份证号”。在设计模型的时候,为了保持一致,可以限制只允许使用“身份证号码”这个词,这就保证了名称的一致。

对于中国人来说,只要看到这个词,都会知道身份证号码是什么意思,也都会知道它长什么样,有什么用,这就是含义的一致。不管是谁的身份证号码,都是由十八位数字或字母构成的,这就是域的一致。“域(Domain)”这个概念暂且可以理解为它就是对数据类型和格式等的约定和限制,就是定义这个数据是文本还是数字,长度是多少等等。如果展开来说的话,域还包含了这十八位数字或字母的详细规则,比如:“第一、二位是户口所在省、自治区或直辖市的编码”等等。

有了一个对数据标准化的初步认识以后,接下来我们就来聊聊与数据标准化相关的几个常见话题。

数据标准化是建模师工作的一部分

无论是概念、逻辑模型还是物理模型,建模师在设计的过程中,都要保证实体和属性命名的规范性,不能一会叫“XX名称”,一会叫“XX名字”、“XX名”、“XX称呼”之类的。特别是对有命名“洁癖”的人来说,很难接受这样的做法。

数据的域也是一样,就拿“日期”的数据类型来说,有的是8位或10位的文本类型(8位:“20231001”,10位:“2023/10/01”),有的是一串数字(“1696089600”,这是一个Unix时间戳)。这样会导致的直接问题就是在处理数据的时候,每次都需要让它们先变成统一,所以,格式转换和处理的成本就会增加。

所以,建模师在设计数据模型的过程中,也必须要把名称和格式等都考虑清楚。尤其是在设计的过程中要使用组织内预先定义好的这些规范,这样数据模型也会变得更加专业化,避免每个建模师都按照自己喜好设计,也避免同一个建模师一会一个想法,搞得前后不一致。

数据建模的过程中不单单要考虑中文名称的规范,还要考虑英文缩写的规范。逻辑模型设计过程中实体和属性的名称都是中文的,而物理模型设计的过程中还需要考虑英文缩写和数据库里使用的数据类型。

在物理模型和数据库里使用英文缩写的这个事情,算是行业的默认规范吧。在数据库里的表、字段的名称一般都是用英文字母和数字组合起来的,而且一般也都会用英文的缩写,不会用全称,因为太长了。(也有特殊情况,请忽略~)

数据类型也是一样,在逻辑模型里看到的文本型、数字型,在数据库里使用的是 Varchar、Number、Integer等物理数据类型,不同的数据库,用法上还有一些不同。

所以,数据标准化这项工作不仅是数据建模师工作的一部分,也是建模师必须考虑的设计模式(时刻要先判断概念是不是一致、名称是不是一致、格式是不是一致)。不过,规模大一些的组织会把一部分工作独立出来,比如,维护一个词库或命名规范库把一些事前工作都准备好,让建模师将更多的精力集中在业务需求和模型设计中。

当然,数据建模工具里提供了很多功能,可以让这个工作做起来更高效、更便捷。

数据标准化的关键是保持一致性

一般来说,搞数据的人对名字都比较敏感,因为名字不一样,很可能含义就不一样,而且,还要追求一定程度上的“权威性”。

数据标准化本来并不是一件多么复杂的事情,但是,方方面面考虑得多了,就容易陷入思考的焦虑,最终搞得这也不行、那也不合适。

勿忘初心!我想说的是:数据标准化的关键是保持一致性(不喜勿喷~)。

为啥呢?原因就是语言的“博大精深”啊。

我可以分享几个比较“纠结”的场景和我的解决办法:

首先,越是想保持一致,越会使用一些通用性很强的词汇,而越是通用性强,可能描述得就越不精确。

比如,通用参考模型里有个词叫“参与人/当事人(Party)”的概念,你可以将这个概念理解为参与组织业务活动的所有角色。注意这个角色不仅是自然人,也包含了法人、团队等等。这个词通用性强、抽象程度高,但是对于不了解的人不容易理解,在建模这个领域里的人都知道原因是在这个范围内已经达成了一致。

再比如,订单里的“发货地址”和“收货地址”如果都只叫“地址”或“位置”的话,那怎么分得清到底是什么用途的地址呢?“地址“是电子邮件的地址,还是物理的地理位置?是单位的还是家里的?

所以,在这个时候,先要在组织范围内达成理解和使用方式的一致,然后再根据业务场景添加修饰词让它描述得更准确。但是,要注意组织范围越大,就越不容易达成一致,你可以想想这是为什么。

其次,有些词会有那种“叫这个也对,叫那个也不错”的情况,越是这样的时候,越是容易导致使用时候的不一致。

比如,“员工”、“职员”、“雇员”这样的词,往往很难分清楚在什么时候使用哪一个最精准,在选择的时候就会开始纠结这几个词到底在什么情况下有什么不同。不仅很纠结,而且如果定义得不好就很容易出现在同一个系统里同时存在这三种叫法。

从数据标准化的角度来说,没必要太“纠结”,选择一个,其他的禁止使用就好了。

最后,数据标准化不是一劳永逸的,也不是一蹴而就的,就好像模型也是要随着业务的发展进行调整一样,数据标准化的工作也要迭代着做。

正因是个持续的过程,所以,可能有些词在一开始定义的时候感觉很合理、很合适,随着模型的变化和调整,发现这些词又不那么合适了。

此时就有三种选择,第一种是把之前定义的全部改掉,第二种是以前的就不管了,重新定义一个新的,以后使用新的,第三种是继续使用之前的,“将错就错”、“继续错下去”。

理想的选择是第一种,但是,第一种可能会影响的范围很大,并不是任何时候都可行。那第二种选择怎么样呢?如果两个含义是一样的,那就变成名称不一致了,从数据标准化的角度来说,不应该这么做。建议选择第三种,所谓的“错”也不见得是不对,起码保证在同一个组织或系统范围内,含义、名称和域都是一致的。

一般来说要么“忍痛”选择第一种,要么“忍耐”着选择第三种。前期虽然容易纠结,但慎重的思考是必须的,如果后期维护的过程中,出现了这种情况,时刻以“如何能够保持一致性”为第一原则来处理。