加强数据模型建设，助力企业数字化转型 — 数据模型是什么

本文链接：https://blog.csdn.net/qingyunliushuiyu/article/details/126655144

　　在理解上文所提到“数据模型是数据样子的模仿”之前，首先来看一下数据是什么？官方的说法是：数据是指对客观事件进行记录并可以鉴别的符号。即使在没有计算机的时代里，数据就已经在那里，只是到了这个有计算机与互联网的时代，记录、存储、使用数据变的成本极低，“数据”这个词才会这么轻易地被人们经常提起。

　　由于计算机强大的数据记录和处理能力的存在，“客观”和“符号”两个概念已经被淡化，凡是能够被计算机进行记录和处理的信息都可以被称为“数据”，其形式也不局限于数字和符号，图形、音频、视频等也可以是数据。然而，大多数人类对于数据的直接使用能力是极其有限的，人们在使用数据时只会关注其中极少的关键信息，然而却不会衰减对数据的理解，这就是为什么文字小说和IMAX电影同样可以使你愉悦的原因。

　　在数据分析领域中，人们使用数据最基本的手段就是对比，如果数据的表现形式只是两个数字，对比是很容易的，而如果数据的表现形式是图形、音频、视频，那么比较起来就会很困难。这时“样子的模仿”就登场了！将人们用起来困难的数据的样子，去掉那些不关键的信息，而剩下来的信息又能满足使用需要，这就是模仿过程所带来的益处。

　　二维数据表自然的被选中做为模仿的载体，不单是因为它在计算机系统里便于实现，更重要的是它便于人们使用。从那些使用困难的非结构化数据到二维表数据的过程，就是我们常说的“结构化”的过程。按照预先设定好的“规范”，将发票票据的照片、客户谈判的录音、生产过程的视频的关键信息，用字符、枚举值、数值记录到二维表中，就实现了结构化。

　　规范的一部分是通过二维数据表的表定义来体现的，比如：字段名、字段长度、字段类型、字段描述等。表定义在某个数据库环境中，只是很宽泛的定义了基本存储要求，对数据的进入也没有多强的约束力，比如：将客户编码放到订单号上是可以的。于是，又有了数据库系统设计的通用规范，比如：三范式。另外一些规范是来自于设计团队内部的自定义规范，比如：命名规范。总之，为了能够让使用者能够“触类旁通”，首先要把规范“甩”给他们。

　　用计算机来模仿数据的样子，可以被认为是在计算机中设计二维表的过程。在设计过程中，而规范起到的是“承上启下”作用：即让计算机可以运行、让使用者可以理解。

　　随着数据库技术的不断提升，“运行”已经不再是问题，所以现在有很多数据库表设计，对于字段长度、字段类型的精确定义已经不是那么在乎了，“隐式转换”也起到推波助澜的作用，经常会见到“varchar(200)满天飞”的现象。对于这个问题，我本人不置可否，但从经验上来看，业务系统(OLTP)中数据模型还是要尽量考虑一下表设计，毕竟设计界面的人也需要参考这个信息，而数据分析系统(OLAP)中的数据模型可以稍微放宽一些限制。

　　在专业数据库设计领域中，让使用者可以理解的文案要求已经有一套成熟的标准。“从粗到细”的表现形式依次为：概念数据模型(Conceptual Data Model)、逻辑数据模型(Logical Data Model)和物理数据模型(Physical Data Model)，以及数据字典(Data dictionary)；可用的建模过程有层级(Hierarchical)、网状(Network)、面向对象(Object Oriented)、实体关系(Entity Relationship)、关系(Rational)。

　　带箭头的层级、网状的建模方式，用作概念数据模型的设计，体现的是衍生过程，目的是便于业务人员理解，可以用现在业务人员所喜欢使用的思维导图(Mind Map)来取代；不带箭头的面向对象、实体关系的建模方式，用作逻辑数据模型的设计，体现的是最终的结果，目的是便于设计者理解；包含表名、属性、主外键的“关系”建模方式，用作物理数据模型，目的是便于开发者理解，可以在各种不同的数据库环境中进行直接落地；而数据字典使用的是列表形式，目的是便于开发者查询和检索，当然前提是做数据字典的开发者有好习惯。

　　如果一个公司要花10年的时间，前仆后继的打造一款顶尖产品，这套标准的执行是不可或缺的，但是对于某个5-6个月的定制开发项目来说，不论是业务系统还是分析系统，这套标准都有些过于“沉重”了。应对的方法是：减少过程性资料，加强结果性资料的全面性。具体来讲就是将概念、逻辑、物理三个数据模型，压缩到一张“数据关系图”中，然后再给其配上详细属性和枚举的数据字典。

　　在理解数据的需求面前，数据关系图比二维表的表定义更加重要。二维表的结构决定了其中承载不了太多信息，但更重要的是由于人类的理解能力所限，单个二维表也不能承载太多信息。我们经常见到一些开发工程师，对于某个数据库系统是“一看就懂，一用就瞎”，也正是因为这个原因。更多的信息就要靠二维数据表之间的关系来体现，这实际上是软件工程上最常讲的“低耦合、高内聚”思想的运用，而能够形象的体现这种关系的“型”就是数据关系图。借助数据关系图，使用者可以将更多精力可以放在理解数据表关系上。

　　对于数据分析领域已经交付的项目而言，数据模型就是由一系列相关的物理表、物理表的数据字典、以及数据关系图构成。一个数据模型应该覆盖多少物理表的问题，就如同销售主题的报表应该有多少个的问题一样，没有固定的数量答案。但是，一个物理表和同在一个数据模型中的其他物理表一点关系都没有的话，既不是业务主题相关，又不是主外键关系相连，那么就不需要放在一个数据模型里。通过已经交付项目总结而输出的数据模型，可以是下一个类似项目的参考，但永远不会是一个可以直接复制过去使用，一劳永逸的组件。

　　敏捷bi工具要进行自助分析，那么就得提供几个大宽表的数据模型；企业要长久的使用各业务系统产生的孤岛数据，那么就要耐心的建立一个数据仓库模型；而一个页面要显示3个指标，要提供的是支持维度筛选，可以放更多指标的数据模型。“五花八门”的数据应用要求也决定了数据模型必然是“五花八门”的，不可能有一个通用数据模型满足所有的数据应用要求，不同数据应用要求之间的互斥差异，决定了同样一份数据需要有不同的模型去满足差异，因此不同数据模型之间不可避免的需要进行转换。

　数据仓库的分层架构被用来把同一类模型放在一起，以便于层到层的转换都是类似的工作，便于转换的管理，甚至是可以批量的处理一批模型的转换。作为一家14年来专注提供数字化解决方案的国内知名服务商，数聚股份集成过的业务系统不计其数。从而也总结出，最合适的传统企业的数据架构。