数据仓库知识点梳理(3)

nxcjh

2020-04-25

在上一篇文章中由业务分析方法引入维度建模，同时介绍了维度建模的基本组成——事实表和维度表，维度建模下的数据组织形式：星型模型。本篇介绍维度建模的另一个数据展现形式——数据立方体(data cube)，以及数据立方体的操作方式。

01 定义与基本元素

在计算系统中，数据立方体(OLAP cube)是用于存储数据值的多维数组，叫立方体只是在用3D的概念理解3个维度的数组。广义概念上，数据立方体可以是2维，3维……n维。在具体的数据仓库场景下，数据立方体的维度是由分析主题的属性确定，立方体中通过维度值分割出的单元用于存储属性组合下的测度。我们可以回忆下在「星型模型」中，维度表存储测度，而事实表存储属性。

那么数据立方体和星型模型有什么联系呢？

两者实际上是维度建模理论下数据组织形式的不同方式。星型模型是建立在关系型数据库(RDBMS)上，数据以表的形式存储，属性和测度之间通过表的主键和外键联系起来。数据立方体或者更准确的说OLAP立方体，是存储在维度数据库(multidimensional database, MDB)上的维度模型。数据立方体同样存储维度属性和对应的测度，相对于RDBMS中的SQL语言，多数MDB产品使用了XMLA或者MDX等包含更多分析功能的查询语言。

虽然MDB不像RDBMS有统一的标准，但是MDB中的数据立方体都是由三个基本元素组成的。这三个基本元素分别是：研究主题的属性(Dimensions)、属性的分类成员(Members)、属性组合下的测度值(Measures)。如果有一个3维的数据立方体，可以通过图片方式表示出来，那么Members就是坐标轴上的标尺，Measures就是每一小格(cells)中存放的统计值。

为了更好地理解上述定义，我们可以从需要分析的主题中截取一部分来绘制出一个立方体。如下图所示，将电脑硬件产品销售的三个维度位置放在一个真正的立方体透视图中。其中，「地址」、「产品」和「日期」是销售主题的三个属性，组成了立方体的维度。地址维度下的「江苏」、「浙江」等省区是地址的分类成员，即Members。在三个维度下，通过具体的离散分类值确定的格子(cell)中存放了一个测度，此处的测度是销售件数。

数据仓库知识点梳理(3)

同时，维度下的分类成员具有层级的概念。比如，在上图中地址维度采用的省级分类，其实向下还可以细分成城市分类，向上还可以聚合从国家的分类。

在维度向下细分的过程中，立方体中的部分cells可能存在空值的情况，比如粒度降到街道级别后，在具体的某一天，可能不存在显示器的订单，那么对应的测度值为空。

02 立方体的操作

相较于于关系数据库中的sum、group by等分析统计操作，在数据立方体中，常见的分析操作包括切片(Slice)、切块(Dice)、下钻(Drill down)、上卷(Roll up)和旋转(Pivot)。

切片：固定维度值为一个确定的分类成员，比如将日期固定为1/1/2019，那么得到单日的销售数据。
切块：取一个或者多个维度的部分分类成员，比如地址限制两个省份，日期取其中两天，从而获取一个缩小的立方体。
下钻：按照维度分类的层级获取更加细节的分类，比如地址可以再细分到城市级别
上卷：下钻的反向操作，向当前维度分类的粗粒度分类聚合(测度值求和)，比如把键盘和鼠标整合为键鼠大类。
旋转：将维度的位置进行调换，用不同的角度来分析数据，比如将地址和产品的位置互换得到下图。

03 MDX语言

上文提到数据立方体是存储在MDB中的，常见的MDB商业方案如SQL Server Analysis Services，IBM Congos 和Oracle BIEE等，开源方案有Pentaho BI，Mondrian，Apache Kylin等。

在MDB中，对数据立方体的操作可以通过MDX(Multidimensional Data Expressions)语言实现。下面的语句便是一个提取销售金额的语句，维度上使用的是日期(选择2002和2003财年)，并且通过WHERE实现了区域维度上的切片，FROM关键词跟着的对象是在系统中建立的立方体。

SELECT  
    { [Measures].[Sales Amount],   
        [Measures].[Tax Amount] } ON COLUMNS,  
    { [Date].[Fiscal].[Fiscal Year].&[2002],   
        [Date].[Fiscal].[Fiscal Year].&[2003] } ON ROWS  
FROM [Adventure Works]  
WHERE ( [Sales Territory].[Southwest] )

初看MDX的语法，似乎与关系数据库中的SQL很相似，但实际上它们在操作对象上是完全不同的。