数据建模：维度建模

数据建模：维度建模

一、数据建模概述

1、数据模型级别
概念数据模型：是用一系列相关主题域的集合来描述概要数据需求。概念模型仅仅包括给定的领域和职能中基础和关键的业务实体，同时也给出实体与实体之间关系的描述。

逻辑数据模型：是对数据需求的详细描述。
物理建模：描述了一种详细的技术解决方案。

2、发展阶段
简单报表阶段：通过原始数据，以及结构化查询的条件，生成一些简单的能够辅助决策的汇总数据，表现形式大多是关系型数据库和前端报表工具。

数据集市阶段：根据某个业务部门或模块的需要，进行一定的数据采集，进行多维报表的展现，能够提供对特定业务指导的数据。

数据仓库阶段：按照一定的数据模型，对整体的数据进行采集整理，并且能够按照各业务模块的需要，提供跨模块的，完全一致的业务报表数据，能够通过数据仓库生成对业务具有指导性的数据。

3、建模方法

• 范式建模：设计的目的是精确的表达业务数据，消除冗余。
• 维度建模（星型建模较为广泛）：数据组织的方式是为了优化海量数据的查询和分析。

二、维度建模

度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。

1、维度建模过程

第一步：选择业务过程
（1）通过对业务需求以及可用数据源的综合考虑，确定对哪种业务过程开展建模工作

（2）建立的第一个维度模型应该是一个最有影响的模型——它应该对最紧迫的业务问题作出回答，并且对数据的抽取来说是最容易的。

第二步：定义粒度

（1）应该先优先考虑为业务处理获取最有原子性的信息而开发维度模型。原子型数据是所收集的最详细的信息，这样的数据不能再做更进一步的细分。

（2）数据仓库几乎总是要求在每个维度可能得到的最低粒度上对数据进行表示的原因，并不是因为查询想看到每个低层次的行，而是因为查询希望以很精确的方式对细节知识进行抽取。

注：粒度是指数据仓库的数据单位中保存数据的细化或综合程度的级别，细化程度越高，粒度就越小

第三步：选定维度
一个经过仔细考虑的粒度定义确定了事实表的基本维度特性。同时，经常也可能向事实表的基本粒度加入更多的维度，而这些附加的维度会在基本维度的每个组合值方面自然地取得唯一的值。如果附加的维度因为导致生成另外的事实行而违背了这个基本的粒度定义，那么必须对粒度定义进行修改以适应这个维度的情景。

第四步：确定事实
确定将哪些事实放到事实表中。粒度声明有助于稳定相关的考虑。事实必须与粒度吻合。在考虑可能存在的事实时，可能会发现仍然需要调整早期的粒度声明和维度选择

2、维度建模的基本要素

（1）事实表
发生在现实世界中的操作型事件，其所产生的可度量数值，存储在事实表中。从最低的粒度级别来看，事实表行对应一个度量事件，反之亦然。

购买行为就可以理解为在现实中发生的一次操作型事件。
订单表就是一个事实表，每完成一个订单，就会在订单中增加一条记录。
在维度表里没有存放实际的内容，他是一堆主键的集合，这些ID分别能对应到维度表中的一条记录。

（2）维度表
每个维度表都包含单一的主键列。维度表的主键可以作为与之关联的任何事实表的外键，当然，维度表行的描述环境应与事实表行完全对应。 维度表通常比较宽，是扁平型非规范表，包含大量的低粒度的文本属性。

上图中，用户表、商家表、时间表这些都属于维度表，这些表都有一个唯一的主键，然后在表中存放了详细的数据信息。

3、维度建模过程举例

（1）业务场景
电商网站中最典型的场景就是用户的购买行为。一次购买行为的发起需要有这几个个体的参与：购买者、商家、商品、购买时间、订单金额。

（2）模型设计

零售营销方案的度量事实：

模型设计为下面这种大宽表时：

维度建模的优缺点：

• 结构清晰
• 便于做OLAP分析
• 增加使用成本，比如查询时要关联多张表
• 数据不一致，比如用户发起购买行为的时候的数据，和我们维度表里面存放的数据不一致
• 更好的应对业务变化，数据冗余多，占空间多，就是用空间换时间。

大宽表优缺点：

• 业务直观，在做业务的时候，这种表特别方便，直接能对到业务中。
• 使用方便，写sql的时候很方便。
• 数据冗余巨大，在几亿的用户规模下，他的订单行为会很恐怖
• 表的可复用性低。

（3）使用示例

求出2016年在帝都的男性用户购买的LV品牌商品的总价格。

SELECTSUM(order.money)FROMorder,
    product,date,
    address,user,WHEREdate.year='2016'ANDuser.sex ='male'AND address.province ='帝都'AND product.name ='LV'

参考文章：
[1] 维度数据建模过程及举例