数据模型——数据仓库的灵魂-36大数据

我是创始人李岩:很抱歉!给自己产品做个广告,点击进来看看。  

数据模型——数据仓库的灵魂-36大数据

作者:KPMG大数据挖掘

摘要: 随着数据量的爆炸式增长,数据仓库或数据平台已经是每家企业或机构不可缺少的工具,而数据模型正是数据仓库的灵魂。本期详细介绍数据模型的概念、分类和应用,相信你一定有兴趣~

随着数据量的爆炸式增长,数据仓库或数据平台已经是每家企业或机构不可缺少的工具,而数据模型正是数据仓库的灵魂。本期详细介绍数据模型的概念、分类和应用,相信你一定有兴趣~

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

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

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

为什么需要数据模型?

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

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

常见数据建模方法介绍

1. ER模型:

ER模型是数据仓库之父Inmon推崇的、从全企业的高度设计一个3NF模型的方法,用实体加关系描述的数据模型描述企业业务架构,在范式理论上符合3NF,站在企业角度面向主题的抽象,而不是针对某个具体业务流程的实体对象关系抽象。它更多是面向数据的整合和一致性治理,正如Inmon所希望达到的“single version of the truth”。

ER模型最基本的要素是实体、属性和关系:

  • 实体:具有相同属性的实体具有相同的特征和性质,用实体名及其属性名集合来抽象和刻画同类实体;
  • 关系:数据对象彼此之间的关系;
  • 属性:实体具有的某个特性,一般多个属性来刻画某个实体。

2. 维度模型:

维度模型是数据仓库领域另一位大师Ralph Kimball 所倡导的。维度建模以分析决策的需求出发构建模型,构建的数据模型为分析需求服务,因此它重点解决用户如何更快速完成分析需求,同时还有较好的大规模复杂查询的响应性能,更直接面向业务。典型的代表是我们比较熟知的星形模型,以及在一些特殊场景下适用的雪花模型。

维度模型最基本的两个要素是事实表和维度表:

  • 事实表:一般由两部分组成,维度和度量,通俗的理解为“某人在某个时间什么条件下做了什么事情”的事实记录,它拥有最大的数据量,是业务流程的核心体现。
  • 维度表:对事实表的补充说明,描述和还原事实发生时的场景,比如通过用户、商品、地址、时间等维度还原商品订单发生时的场景。

3. 案例分析:

首先来看看以上两种模型的示例:

图1:ER模型例图

数据模型——数据仓库的灵魂-36大数据

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

图2:维度模型例图

数据模型——数据仓库的灵魂-36大数据

图2所示,中间的为一张事实表,主键为包含不同的维度ID的联合主键。整体看维度建模的设计类似星型,并且一个中心的事实表对应多个一层的维表,某个维度的描述仅限一张表,这样的设计,必然会是维表有冗余,一张表描述多层的维度。

直观上看:图1主表有一个主键多个外键,层次较深;图2为多个联合主键,关联不同的维度表,一张维度表解决所有该维度属性信息。

维度模型将ER模型的层次结构平铺开来了,整个数据结构是平面化、单一层次的,数据结构很简单,但是维度表的冗余也会较多,灵活性比较差;优势则是查询简单快速,比如对产品维度的大类汇总,ER建模需要关联产品再通过关系表关联产品大类,而维度模型直接在产品维度表中就有了。

4. 应用场景

ER模型和维度模型应用场景有所不同,ER模型更偏向于基础数据仓库的建设,保证高度抽象、高度一致性,要求业务稳定;而维度模型更多应用于数据集市,偏向于直接面对业务,保证查询效率。

ER建模的构建难度决定了它面临如下挑战:1. 需要全面了解企业业务和数据;2. 实施周期非常长;3. 对建模人员的能力要求也非常高。因此对于业务比较稳定的传统金融行业,使用ER建模更多,对于业务经常变化的电商行业,由于ER建模的难度加上业务复杂和快速变化的叠加效应,则越来越多采取维度建模。

淘宝数据平台变迁 的过程正好解释了二者的不同。最初,淘宝业务单一、系统简单,主要是简单的报表系统;后期数据量越来越大,系统越来越多,尝试用ER建模的数据仓库,但是在实践中发现快速变化的业务之下,构建ER模型的风险和难度都很高,现在则主要采用基于维度建模的模型方法了。

数据模型构建方法论

维度建模通常需要选择某个业务过程,然后围绕该过程建立模型:

数据模型——数据仓库的灵魂-36大数据

ER建模则常常需要全局考虑,要对上游业务系统的进行信息调研,以做到对其业务和数据的基本了解,要做到主题划分,让模型有清晰合理的实体关系体系,需要由验证反馈机制,以及时修正模型漏洞,下面是对ER建模的方法论简要介绍:

数据模型——数据仓库的灵魂-36大数据

数据模型的价值

一个逻辑数据模型是建立商业智能的基础框架,也是建立一个灵活的强有力的数据仓库系统的第一步,是为决策层和数据使用者提供有价值数据分析的重要基础,并且能够帮助数据标准的制定、数据治理、元数据管理、数据存储等方面的工作。

附:经典数据模型

下表为最经典的数据模型——Teradata公司基于金融行业高度抽象出来的FS-LDM模型,它将金融行业高度抽象为十大主题,如下表:

FSLDM十大主题

数据模型——数据仓库的灵魂-36大数据

下图是协议主题中金融账户分类相关的实体关系示例:

数据模型——数据仓库的灵魂-36大数据

注:上图源自Teradata培训文档

FS-LDM最核心的就是主题划分和成熟的实体关系体系,有兴趣的可以参考上面的介绍对自己熟悉的公司数据进行模型构建,或许会更进一步理解数据模型的妙处。

End.

转载请注明来自36大数据(36dsj.com): 36大数据 » 数据模型——数据仓库的灵魂

随意打赏

数据仓库 大数据大数据 数据仓库大数据分析模型数据模型
提交建议
微信扫一扫,分享给好友吧。