数据仓库

按照 W. H. Inmon,一位数据仓库系统构造方面的大神的说法,“数据仓库是一个面向主题的、集成的、时变的、非易失的数据集合,支持管理决策制定”。数据仓库的目的是构建面向分析的集成化数据环境，为企业提供决策支持。

除供企业内部使用外，像Google Analytics和淘宝数据魔方等提供继承数据和多维分析的应用也属于数据仓库类型。

事实和度量

事实（Fact）是可以被量化的最详细的业务信息。例如：一次网站的点击；购物网站上一个客户的一次购买行为；Github上一个程序员的一次提交。我们可以量化下面的数据：

• 网站点击：点击次数、停留时间。
• 网上购物：销售额、利润、购买产品数量。
• 提交代码：commit数量、修改代码行数、删除代码行数。
  

这些可以量化的属性，如点击数、利润、提交数量，我们称之为度量（measures），是我们关注的业务过程的衡量指标。

在数据仓库中，我们更关心的是汇总后的度量，例如：网站3月的点击量是多少；05年销售额是多少；本周commit数量是多少。

维度

维度（Dimension）是指分析的各个角度。例如我们希望按照时间,或者按照地区,或者按照产品进行分析,那么这里的时间、地区、产品就是相应的维度。基于不同的维度,我们可以看到各量度的汇总情况,也可以基于所有的维度进行交叉分析。

维度为事实提供上下文：

• 订单什么时候创建的？
• 哪里的客户创建的订单？
  

维度是分析的过滤条件：

• 2014年有多少订单？
• 3月份温哥华的销售额是多少？
  

维度层次

我们可能已经非常熟悉Web网站的面包屑导航和层级菜单了。当你在某个类目浏览的时候，接下来更可能要去浏览当前类目的子类目或回退到你来的位置。与此类似，我们在分析的时候按年聚合之后可能更想要分析按月聚合的数据；分析了国家的数据之后想要分析各个省的数据。也就是说，维度是有层次(Hierarchies)关系的。

下钻（Drill-down）

在维的不同层次间的变化，从上层降到下一层，或者说是将汇总数据拆分到更细节的数据，比如通过对2010年第二季度的总销售数据进行钻取来查看2010年第二季度4、5、6每个月的消费数据，如下图；当然也可以钻取Quebec省来查看Montreal、Lachine等城市的销售数据。

1. ^                                    
   
2. |                                    
   
3. |        +----------------+           
   
4. |        |     190        |           
   
5. |        |                |           
   
6. |        |                |           
   
7. +--------+----------------+---------->
   
8.                 Q2                    
   
9. 
   
10.                  +                    
    
11.                  |                    
    
12.                  |                    
    
13.                  |                    
    
14.                  v                    
    
15. 
    
16. ^               +---+                 
    
17. |               | 80|                 
    
18. |               |   |    +---+        
    
19. |      +---+    |   |    | 70|        
    
20. |      | 40|    |   |    |   |        
    
21. |      |   |    |   |    |   |        
    
22. +------+---+----+---+----+---+------->
    
23.         M4       M5        M6         

复制代码

上卷（Roll-up）

下钻的逆操作，即从细粒度数据向高层的聚合，如将Montreal、Lachine等的销售数据进行汇总来查看Quebec地区的销售数据。

切片（Slice）

选择维中特定的值进行分析，比如只选择电子产品的销售数据，或者2010年第二季度的数据。

切块（Dice）

选择维度中特定区间的数据或者某批特定值进行分析，比如选择2010年第一季度到2010年第二季度的销售数据，或者是电子产品和日用品的销售数据。

OLTP vs OLAP

分析型系统和操作型系统具有完全不同的目的。操作型系统支持业务的执行过程，而分析型系统支持对业务过程的评价。因此，指导种系统的设计原则也不同。

操作型系统直接支持业务过程的执行。它通过获取业务的事件和细节来构建业务的活动记录。例如，销售系统的订单、发货、支付等；人力系统的雇员雇佣和升迁信息；代码托管系统的commit和pull request信息等。由这些系统记录的活动通常成为事务，而这类系统本身通常成为联机事务处理（OLTP）系统，或简称为事务系统。

操作型系统关注执行过程，因此在事情发生改变时可能需要更新相关数据，并在数据操作有效期结束后清除或归档数据。例如，当一个客户地址发生变动时，地址数据被简单的重写了。

在关系数据库设计领域，广泛被认可的最佳操作型系统模式设计方法是第三范式。

与操作型系统关注业务执行过程不同，分析型系统主要支持对业务过程的评价。

• 本月订单趋势与上个月相比有何不同？
• 与本季度的目标相比，这种趋势说明什么问题？
• 某一个营销策略对销售有何影响?
• 谁是我们的最佳客户？
  

这些问题涉及到对整个订单流程的度量，无法从单个订单中获得答案。

在分析系统中，不需要创建或修改信息。在操作型系统中不再使用的历史数据对分析型系统来说仍然很重要，这一点之后要提到的缓慢变化维度问题中会有更详细的解释。

下面表格是对OLTP和OLAP主要差别的总结：

	操作型系统	分析型系统
目的	执行业务过程	度量业务过程
交互类型	插入、更新、查询、删除	查询
交互范围	单个事务	聚合事务
时间关注	当前的	当前的和历史的
设计优化	更新并发性	高性能查询
设计原则	基于第三范式（3NF）的实体-关系（ER）设计	维度设计（星型模型）

星型模式（Star Schema）

针对关系型数据库的维度设计被称为星型模式。相关的维度组合成维度表中的列，事实则存储在事实表的各个列中。星型模式的这个称谓来自于其表现形式：当与置于中心位置的事实表连线时，整个模式看起来像星状物，如图：

在星型模型基础上，将维度表做规范化设计，又衍生出了雪花模型，如图：

招数据分析师，地点待遇优，知名公司，请联系QQ:2891075438
知名集团公司招聘

酒店式公寓

5天8小时，周末双休

一年两次探亲假，一次12天以上，包往返机票

入职签证和机票公司报销，

节假日红包等等

工作签证，入职公司帮忙办理工作签证。

公司每年有医疗报销