SSAS中Cube的结构

在SSAS（SQL Server Analysis Services）中构建Cube和编写MDX的时候，我们很容易被一些名词弄糊涂，比如：Dimension（维度），Measures Dimension（度量维度），Measure（度量），Hierarchy（层次结构），Attribute hierarchy（属性层次结构），Level（级别），Cell（单元），Member（成员），Member Property（成员属性），Set（集），Turple（元组）等等。要想弄清楚这些名词，就必须理解Cube的结构。
上述名词的解释详见：http://msdn2.microsoft.com/en-us/library/ms144884.aspx Cube、Dimension和Measure Cube就象一个坐标系，每一个Dimension代表一个坐标轴，要想得到一个点，就必须在每一个坐标轴上取的一个值，而这个点就是Cube中的Cell。见下图（来源于http://msdn2.microsoft.com/zh-cn/library/ms144884.aspx）：  
上图很好的说明了Cube、Dimension、Measure之间的关系。这里需要注意的是：其实Measure也属于一个维度，即Measures Dimension。所有的Measure构成了Measures Dimension，这个维度的只有一个Hierarchy，而且这个Hierarchy只有一个层次（Level）。
Hierarchy、Level和Memeber 在上节的图中，每个Dimension只有一个Hierarchy，而在实际的环境中，一个Dimension往往有很多Hierarchy。因此，上一小节中关于“Cube就象一个坐标系，每一个Dimension代表一个坐标轴”这句话其实不够准确，准确的说应该是每一个Hierarchy代表了一个坐标轴，而Hierarchy中每一个Member代表了坐标轴上的一个值。下图以时间维度为例展示了Dimension的内部结构。
此外，我们需要说明的是：

1) 上图中说明的是一般Dimension的结构，在实际的模型中，其实可以做很多自定义的工作。比如：我们可以修改Hierarchy的默认Member。 
2) 一般情况下，SSAS中Hierarchy的默认Member是All（在你的模型中，可能叫其他名称）。换句话说在MDX中[时间].[财政]等价于[时间].[财政].[All]，[时间].[财政].Children等价于[时间].[财政].[All].Children。
3) Dimension_Name.Hierarchy_Name.Level_Name等价于Dimension_Name.Hierarchy_Name.Level_Name.Members。比如：[时间].[财政].[半年]等价于[时间].[财政].[半年].Members。Level的Members是该级别的所有元素（对于[时间].[财政].[半年].Members={[上半年]，[下半年]，[上半年]，[下半年]}，其中前两个是2001年下的，后两个属于2002年），而Hierarchy的Members包含了该Hierarchy下所有的内容。
4) 当且仅当一个Dimension下只有一个Hierarchy，则Dimension_Name等价于Dimension_Name.Hierarchy_Name纬度。比方说：时间维度只有一个财务Hierarchy，则[时间]等价[时间].[财务]。
5) Attribute Hierarchy中Members的层次是两层（MSDN的说法更加准确，这里简化了一些）：第一层：All，第二层：叶子节点。也就是说它和多层的Hierarchy相比，两者结构完全相同，这是统一维度模型（Unified Dimensional Model）一个方面的体现。 
      注意：采用Attribute Hierarchy能够使编写MDX更加容易，但同时也增加了Cube的容量，加大了Cells的个数，对性能有负面影响。因此，在建模的时候，我们可以把一些Attribute Hierarchy的AttributeHierarchyEnabled属性设置成False，同时在编写MDX时，以Member Property的方式来引用，这样可以在满足需求的前提下提高性能。
6) Measures Dimension是一个特殊的维度，它的Members中没有All这个成员，它的默认Member可以在建模时指定。
7)对于一般的维度，其第一层Level的默认是“（All）”。
Turple和Set 如果说Cube好像一个坐标系，那么Turple、Set的关系就好比点和面的关系。Turple由Cube中每个Hierarchy的一个Member组成。由于Hierarchy的个数非常多，所以一般不可能在Turple表达式中把所有的Member都明确指定，故此，为了简化开发，所有没有明确指定Member的Hierarchy，用该Hierarchy的默认Member代替。也就是说：([时间].[财政].[2001].[上半年]) 等价于（[时间].[财政].[2001].[上半年]，[时间].[日历].[All]）。另外我们需要注意的：

1) 有的说法认为：Turple是“Cube 上的一个子集（不断开的子Cube），这个看法是不准确的，因为Turple只是一个点，不是面，它仅仅由每个Hierarchy的一个Member组成的。

2) 外面（）起来的表达式不一定是Turple。比如：（[时间].[财政].[半年].Members，[时间].[日历].[2001].[上半年]）就不是一个Turple，而是一个Set，其原因在于，Turple是点，它仅仅由每个Hierarchy的一个Member组成，如果在任何一个Hierarchy上有两个成员，则其就变成Set了。

      注意：（[时间].[财政].[半年].Members，[时间].[日历].[2001].[上半年]）等价于Crossjoin（[时间].[财政].[半年].Members，[时间].[日历].[2001].[上半年]）或{[时间].[财政].[半年].Members}*{[时间].[日历].[2001].[上半年]}，在SSAS的MDX中，我们可以在（）中定义多个用逗号分隔开的表达式，编译器会进行分析，如果发现是Set的话，就把它转化成多个Set相乘的形式。

3) Set中的Turple可以重复。比如：{[时间].[日历].[2001].[上半年]，[时间].[日历].[2001].[上半年]}并不等于{[时间].[日历].[2001].[上半年]}，因为前者有两个Turple，后者只有一个。

4) SSAS能够根据上下文的需要，自动把Turple变成Set，单个Member变成Turple，多个Member变成Set。这也是我们常常混淆Turple和Set的原因。详细的例子如下：

a）上下文需要Set时，（[时间].[日历].[2001].[上半年]）自动转化成{[时间].[日历].[2001].[上半年]}。  b）上下文需要Turple时，[时间].[日历].[2001].[上半年]自动转化成（[时间].[日历].[2001].[上半年]）。 c）上下文需要Set时，[时间].[日历].[2001].Children自动转化成{[时间].[日历].[2001].Children}。

维（Dimension）

　　维是用于从不同角度描述事物特征的，一般维都会有多层（Level），每个Level都会包含一些共有的或特有的属性（Attribute），可以用下图来展示下维的结构和组成：

　　以时间维为例，时间维一般会包含年、季、月、日这几个Level，每个Level一般都会有ID、NAME、DESCRIPTION这几个公共属性，这几个公共属性不仅适用于时间维，也同样表现在其它各种不同类型的维。其中ID一般被视为代理主键（Agent），它只被用于作为唯一性标志，并且是多维模型中关联关系的代理者，在业务层面并不具有任何意义；NAME一般是业务主键（Business），在业务层面限制唯一性，一般作为数据装载（Load）时的关联键；而DESCRIPTION则记录了详细描述信息，在多维展示和分析时我们都会选择使用DESCRIPTION来表述具体含义。这3个属性一般是所有Level都会共用的，而比如用于描述星期几的属性weekid可能只会用于“日期”这层，因为年月都不具备这一信息。所以图中我将Attributes放到了一个层面上，就如同是不同的Level从底层的多个Attributes中选取自身所需的属性，Attributes层是包含着各个Level的共有和特有属性的集合。

Hierarchy

　　因为不知道怎么翻译好，所以还是用英文吧。Hierarchy（等级、层级的意思），中文的OLAP相关文档中普遍翻译为“层次”，而上面的Level被普遍翻译为“级别”，我经常会被这样的翻译搞混淆，所以我上面也一直用Level，至少对我来说这样看起来反而清晰点   。

　　因为上面这个结构的维是无法直接应用于OLAP的，我前面的文章有介绍，其实OLAP需要基于有层级的自上而下的钻取，或者自下而上地聚合。所以每一个维必须有Hierarchy，至少有一个默认的，当然可以有多个，见下图：

　　有了Hierarchy，维里面的Level就有了自上而下的树形结构关系，也就是上层的每一个成员（Member）都会包含下层的0个或多个成员，也就是树的分支节点。这里需要注意的是每个Hierarchy树的根节点一般都设置成所有成员的汇总（Total），当该维未被OLAP中使用时，默认显示的就是该维上的汇总节点，也就是该维所有数据的聚合（或者说该维未被用于细分）。Hierarchy中的每一层都会包含若干个成员（Member），还是以时间维，假设我们建的是2006-2015这样一个时间跨度的时间维，那么最高层节点仅有一个Total的成员，包含了所有这10年的时间，而年的那层Level中包含2006、2007…2015这10个成员，每一年又包含了4个季度成员，每个季度包含3个月份成员……这样似乎顺理成章多了，我们就可以基于Hierarchy做一些OLAP操作了。

　　每个Hierarchy都包含了一个树形结构，但维中也可以包含多个Hierarchy，正如上图所示，维中的Hierarchy相互独立地构建了自己的树形结构。还是以时间维为例，时间维可以根据日历（Calendar）时间组建日历的Hierarchy，也可以根据财务（Fiscal）时间组建财务的Hierarchy，而其中财务季度的划分可能并不与日历一致，基于这种多样的Hierarchy，我们在组建多维模型时可以按需选择合适的，比如给财务部的数据分析模型选用财务Hierarchy，而其他部门的分析人员显然希望看到日历样式的Hierarchy，这样就完美地满足了不同的需求。多种的Hierarchy划分同样适用于产品维，根据产品类型、产品规格等划分 Hierarchy，对于按多种条件的产品筛选和检索是十分有效的，实例可以参见淘宝搜索商品界面和太平洋电脑中产品报价界面分类筛选模块，这里不再截图了。

立方（Cube）

　　这里所说的立方其实就是多维模型中间的事实表（Fact Table），它会引用所有相关维的维主键作为自身的联合主键，加上度量（Measure）和计算度量（Calculated Measure）就组成了立方的结构：

　　度量是用于描述事件的数字尺度，比如网站的浏览量（Pageviews）、访问量（Visits），再如电子商务的订单量、销售额等。度量是实际储存于物理表中的，而计算度量则没有，计算度量是通过度量计算得到的，比如同比（如去年同期的月利润）、环比（如上个月的利润）、利率（如环比利润增长率）、份额（如该月中某类产品利润所占比例）、累计（如从年初到当前的累加利润）、移动平均（如最近7天的平均利润额）等，这些计算度量在Oracle中都可以借助分析函数直接计算得到，相信大部分的OLAP组件都会提供类似在时间序列上的分析功能。而这些计算度量往往对于分析而言更具意义，立方中借助与各个维的关联关系从不同的角度和层面来展现这些度量。