本文介绍数据仓库中维度数据建模的过程描述，并举一个示例以加深对相关概念的理解。
维度模型是数据仓库领域大师Ralph Kimall所倡导，他的《数据仓库工具箱》，是数据仓库工程领域最流行的数仓建模经典。维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。
1、通过对业务需求以及可用数据源的综合考虑，确定对哪种业务过程开展建模工作
2、建立的第一个维度模型应该是一个最有影响的模型——它应该对最紧迫的业务问题作出回答，并且对数据的抽取来说是最容易的。
注：粒度是指数据仓库的数据单位中保存数据的细化或综合程度的级别，细化程度越高，粒度就越小
1、应该先优先考虑为业务处理获取最有原子性的信息而开发维度模型。原子型数据是所收集的最详细的信息，这样的数据不能再做更进一步的细分。
2、数据仓库几乎总是要求在每个维度可能得到的最低粒度上对数据进行表示的原因，并不是因为查询想看到每个低层次的行，而是因为查询希望以很精确的方式对细节知识进行抽取。
一个经过仔细考虑的粒度定义确定了事实表的基本维度特性。同时，经常也可能向事实表的基本粒度加入更多的维度，而这些附加的维度会在基本维度的每个组合值方面自然地取得唯一的值。如果附加的维度因为导致生成另外的事实行而违背了这个基本的粒度定义，那么必须对粒度定义进行修改以适应这个维度的情景。
确定将哪些事实放到事实表中。粒度声明有助于稳定相关的考虑。事实必须与粒度吻合。在考虑可能存在的事实时，可能会发现仍然需要调整早期的粒度声明和维度选择
维度建模中有一些比较重要的概念，理解了这些概念，基本也就理解了什么是维度建模。
额，看了这一句，其实是不太容易理解到底什么是事实表的。
比如一次购买行为我们就可以理解为是一个事实，下面我们上示例。
图中的订单表就是一个事实表，你可以理解他就是在现实中发生的一次操作型事件，我们每完成一个订单，就会在订单中增加一条记录。
我们可以回过头再看一下事实表的特征，在维度表里没有存放实际的内容，他是一堆主键的集合，这些ID分别能对应到维度表中的一条记录。
我们的图中的用户表、商家表、时间表这些都属于维度表，这些表都有一个唯一的主键，然后在表中存放了详细的数据信息。
下面我们将以电商为例，详细讲一下维度建模的建模方式，并举例如果使用这个模型（这点还是很重要的）。
假设我们在一家电商网站工作，比如某宝、某东。我们需要对这里业务进行建模。下面我们分析几点业务场景：
好，基于这几点，我们来设计我们的模型。
下面就是我们设计出来的数据模型，和之前的基本一样，只不过是换成了英文，主要是为了后面写sql的时候来用。
我就不再解释每个表的作用了，现在只说一下为什么要这样设计。
首先，我们想一下，如果我们不这样设计的话，我们一般会怎么做？
如果是我，我会设计下面这张表。你信不信，我能列出来50个字段！其实我个人认为怎么设计这种表都有其合理性，我们不论对错，单说一下两者的优缺点。
先说我们的维度模型：
再说我们这张大款表的优缺点：
数据模型的建立必须要为更好的应用来服务，下面我先举一个例子，来切实地感受一下来怎么用我们的模型。
需求 ：求出2016年在帝都的男性用户购买的LV品牌商品的总价格。
实现 ：
维度建模是一种十分优秀的建模方式，他有很多的优点，但是我们在实际工作中也很难完全按照它的方式来实现，都会有所取舍，比如说为了业务我们还是会需要一些宽表，有时候还会有很多的数据冗余。