数据模型——数据仓库的灵魂

前言

越来越多的业务，越来越多的信息化系统，让很多公司拥有了海量数据，但是分散的数据、隔离的系统，又形成了一个个数据孤岛。于是，为了利用好数据，各大公司纷纷建设了数据仓库，或者是最近升级为大数据平台之类的，但是，不同条线不同场景的数据又要如何整合到同一个仓库呢？

数据模型就此应运而生，通过高度抽象的数据模型，整合各个源系统的数据，最终形成统一、规范、易用的数据仓库，进而提供包括数据集市、数据挖掘、报表展示、即席查询等上层服务。

数据模型究竟是干什么的，该怎么构建呢？笔者接下来为大家做一些入门的概念普及。

为什么需要数据模型

数据模型能够促进业务与技术进行有效沟通，形成对主要业务定义和术语的统一认识，具有跨部门、中性的特征，可以表达和涵盖所有的业务。

无论是操作型数据库，还是数据仓库都需要数据模型组织数据构成，指导数据表设计。或许Linux的创始人Torvalds说的一句话——“烂程序员关心的是代码，好程序员关心的是数据结构和他们之间的关系”最能够说明数据模型的重要性。只有数据模型将数据有序的组织和存储起来之后，大数据才能得到高性能、低成本、高效率、高质量的使用。

常见数据建模方法介绍

ER 模型
ER模型是数据仓库之父Inmon推崇的、从全企业的高度设计一个3NF模型的方法，用实体加关系描述的数据模型描述企业业务架构，在范式理论上符合3NF，站在企业角度面向主题的抽象，而不是针对某个具体业务流程的实体对象关系抽象。它更多是面向数据的整合和一致性治理，正如Inmon所希望达到的“single version of the truth”。
ER模型最基本的要素是实体、属性和关系：
实体：具有相同属性的实体具有相同的特征和性质，用实体名及其属性名集合来抽象和刻画同类实体；
关系：数据对象彼此之间的关系；
属性：实体具有的某个特性，一般多个属性来刻画某个实体。
维度模型
维度模型是数据仓库领域另一位大师Ralph Kimball 所倡导的。维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能，更直接面向业务。典型的代表是我们比较熟知的星形模型，以及在一些特殊场景下适用的雪花模型。
维度模型最基本的两个要素是事实表和维度表：
事实表：一般由两部分组成，维度和度量，通俗的理解为“某人在某个时间什么条件下做了什么事情”的事实记录，它拥有最大的数据量，是业务流程的核心体现。
维度表：对事实表的补充说明，描述和还原事实发生时的场景，比如通过用户、商品、地址、时间等维度还原商品订单发生时的场景。
案例分析
首先来看看以上两种模型的示例：
图1：ER模型例图

图1所示，每一张矩形图是一个实体，实体之间独立性强，高度抽象，需要通过外键或者关系表进行关联，整张图靠实体和关系构建起来。与主键直接相关、且不能再延伸的属性才会在一个实体中出现，否则会通过关系实体再延伸一个实体出来，保证满足范式要求。
图2：维度模型例图

图2所示，中间的为一张事实表，主键为包含不同的维度ID的联合主键。整体看维度建模的设计类似星型，并且一个中心的事实表对应多个一层的维表，某个维度的描述仅限一张表，这样的设计，必然会是维表有冗余，一张表描述多层的维度。
直观上看：图1主表有一个主键多个外键，层次较深；图2为多个联合主键，关联不同的维度表，一张维度表解决所有该维度属性信息。
维度模型将ER模型的层次结构平铺开来了，整个数据结构是平面化、单一层次的，数据结构很简单，但是维度表的冗余也会较多，灵活性比较差；优势则是查询简单快速，比如对产品维度的大类汇总，ER建模需要关联产品再通过关系表关联产品大类，而维度模型直接在产品维度表中就有了。
应用场景
ER模型和维度模型应用场景有所不同，ER模型更偏向于基础数据仓库的建设，保证高度抽象、高度一致性，要求业务稳定；而维度模型更多应用于数据集市，偏向于直接面对业务，保证查询效率。
ER建模的构建难度决定了它面临如下挑战：1. 需要全面了解企业业务和数据；2. 实施周期非常长；3. 对建模人员的能力要求也非常高。因此对于业务比较稳定的传统金融行业，使用ER建模更多，对于业务经常变化的电商行业，由于ER建模的难度加上业务复杂和快速变化的叠加效应，则越来越多采取维度建模。
淘宝数据平台变迁的过程正好解释了二者的不同。最初，淘宝业务单一、系统简单，主要是简单的报表系统；后期数据量越来越大，系统越来越多，尝试用ER建模的数据仓库，但是在实践中发现快速变化的业务之下，构建ER模型的风险和难度都很高，现在则主要采用基于维度建模的模型方法了。