目的
多维OLAP数据库处在数据存取层和表示层之间，它将关系性数据仓库中的数据转换成完全实现的维度模型，从而使分析报表的创建和数据的可视化更加快速和灵活。由于不同的OLAP数据库提供的特性和物理方式不同，我们将介绍分析服务如何实现维度模型。
内容
事实表中包含数值数据的列对应维度模型中的度量值。因此，每个事实表都是一组度量值，分析服务用一种称作度量值组（measure group）的逻辑结构组织信息，度量值组与当个事实表以及相关的维度相对应。概念上，度量值组合事实表相似，但有一些显著的差异，就像事实表一样，度量值组包含了代表每个维度的列以及每个度量的列。同样，度量值组包含了每个维度中的成员的每个可能的组合所对应的行。但是与事实表有所不同的是。事实表只包含了单个级细节的数据，而维度组不但包含了单个级细节的数据，而且还包含了全部更高级细节的聚合数据。
表1.18 销售度量值组
| 州 | 产品 | 日期 | 销售量 | 销售额 |
| All | All | All | 70 | 31305 |
| WA | All | All | 46 | 21235 |
| WA | Bikes | All | 19 | 10260 |
| WA | Road-750 Black,48 | All | 13 | 7020 |
| WA | Road-750 Black,48 | 2011 | 13 | 7020 |
| WA | Road-750 Black,48 | 2011年3月 | 4 | 2160 |
表1.18中最后一行与事实表中某一行对应，该行包含了和事实表相同级的详细信息。其他的行都不会出现在事实表中，每一行都至少有一个维度层次结构中更高级别的成员。在具有更高级别成员的每一行中，通过累加低级细节数据使实时数据被整合。即使在那么小规模的度量值组中，这些行也只说明了很小一部分可能值。
你可能注意到在表1.18中，列标题和维度数据是粗体的，只有数值数据是未加粗的。这样做是故意的，其意在说明维度名和维度成员名都是元数据，也可以看到维度数据被组织成了层次结构。因为这是一个简单的例子，并不能说明分析服务实现维度数据模型的全部方法。
分析服务可以将若干相关的度量值和一套维度组合成多维数据集（cube）。并不是每一个度量值包含了所有维度的数据，但是如果一个度量值组在多维数据集中，度量值就不能包含了所有维度中的数据，但是如果一个度量值组在多维数据集中，度量值就不能够包含哪些不在多维数据集中的维度的数据。就像术语维度，术语多维数据集（cube）也是从数学中借鉴而来的。一个度量值组可能的值的数量等于该度量值组中每个维度成员数目之积，比方说立方体中单位的数量等于立方体每一边的单位之积。因此在多维数据集里，所有维度中的成员数之积是任何度量值组可能能达到的最大值。在现实世界中，术语立方体（cube）指的是三维物体。在分析服务中，多维数据集只是存储在磁盘中的事实和维度数据，并不包括多维数据集所包含的维度的数目。多维数据集可以少至一维，多至任意维度。
总结
商业智能系统用于执行多维数据分析。通过数字增加元数据，维度模型将数值数据变成了信息。元数据也称度量值，包含在由属性和层次结构组成、与数值数据相关的维度中。在关系型数据库中，数据仓库能部分的实现维度模型。但为了充分利用分析优势，维度模型必须在多维OLAP数据库中实现。