开源OLAP引擎：Mondrian
OLAP
Created 星期四 20 十月 2016
为了满足业务管理和决策的报表系统（包括传统报表、数据仓库、OLAP等）也被创建出来，企业主管通过报表了解企业的总体运行状态。
但是，随着企业间竞争的加剧和市场节奏的进一步加快，企业的日常管理需要对关键业务指标的更加实时的监控和反馈。比如：制造业需要更及时的仓库调度、金融业需要更实时的风险防范、电信业需要更及时的服务指标监控。于是，越来越多的企业提出实时企业的要求，传统的ERP等信息系统和报表系统无法满足这些需求。实时业务监控解决方案旨在更好支撑客户此类需求。
http://www.tuicool.com/articles/67ZBZv3
当今的数据处理大致可以分成两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。
OLAP技术非常多的特性，概括起来主要有如下几点特性：
- OLAP技术是面向分析人员、管理人员的；
- OLAP技术对数据访问通常是只读的，并且一次访问大量数据；
- OLAP技术是面向主题的多维数据分析技术。
OLAP（On-Line Analysis Processing）在线分析处理是一种共享多维信息的快速分析技术；
OLAP利用多维数据库技术使用户从不同角度观察数据；OLAP用于支持复杂的分析操作，侧重于对管理人员的决策支持，可以满足分析人员快速、灵活地进行大数据复量的复杂查询的要求，并且以一种直观、易懂的形式呈现查询结果，辅助决策。
上面是OLAP的一些不同的解释，本文将从以下几个方面介绍OLAP。
OLAP的基本概念
http://www.huqiwen.com/2012/06/15/olap-abstruct-and-mondrian-quick-start/
二、 OLAP的基本概念
（1）度量、指标）
是数据度量的指标，是数据的实际意义，即描述数据"是什么"。像上面示例中的人数。
（2）维度
维度是描述与业务主题相关的一组属性，单个属性或属性集合可以构成一个维。如上面示例中的学历、民族、性别等都是维度。
（3）维的层次
一个维往往可以具有多个层次，例如时间维度分为年、季度、月和日等层次，地区维可以是国家、地区、省、市等层次。这里的层次表示数据细化程度，对应概念分层。后面介绍的上钻操作就是由低层概念映射到高层概念。概念分层可除根据概念的全序和偏序关系确定外，还可以通过对数据进行离散化和分组实现。
（4）维的成员
若维是多层次的，则不同的层次的取值构成一个维成员。部分维层次同样可以构成维成员，例如"某年某季度"、"某季某月"等都可以是时间维的成员。
（5）多维数组
多维数组用维和度量的组合表示。一个多维数组可以表示为（维1，维2，……，维n，变量），例如（部门，职系、民族、性别，人数）组成一个多维数组。
（6）数据单元（单元格）
多维数组的取值。当多维数组中每个维都有确定的取值时，就唯一确定一个变量的值。数据单元可以表示为（维1成员，维2成员，……，维N成员，变量的值），例如（人事教育部，技能，回族，男，1人）表示一个数据单元，表示人事教育部职系是技能的回族男性有1人。
（7）事实
事实是不同维度在某一取值下的度量，例如上述人事教育部职系是技能的回族男性有1人就表示在部门、职系、民族、性别四个维度上企业人数的事实度量，并且在为人数事实中包含部门维度人事教育部这一个维度层次，如果将人数事实的所有维度考虑在内，就构成有关人数的多维分析立方体。
三、 OLAP的特点
电子数据表与OLAP相比，不具备OLAP的多维性、层次、维度计算以及结构与视图分离等特点。
多维。维是OLAP的核心概念，多维性是OLAP的关键属性，这与数据仓库的多维数据组织正好相互补充。为了使用户能够从多个维度、多个数据粒度查看数据，了解数据蕴含的信息，
系统需要提供对数据的多维分析功能，包括切片、旋转和钻取等多种操作
四、 OLAP的操作
OLAP比较常用的操作包括对多维数据的切片与切块、上钻（drill-up）与下钻（drill-down）以下旋转（rotate）等。此外，OLAP还能对多维数据进行深加工。
OALP的这些操作使用户能够从多个视角观察数据，并以图形、报表等多种形式展示，从而获取隐藏在数据中的信息。
（1）切片与切块。
选定多维数组的一个维成员做数据分割的操作称为该维上的一个切片。通常把多维数组中选定一个二维子集的操作视为切片，假设选定的维i上的某个维成员Vi，则此多维数组子集可以定义为（维V1……，维Vi，维N,变量）。当某维只取一个维成员时，便得到一个切片，而切块则是某一维取值范围下的多个切片的叠合。通过对数据立方体的切片或切块分割，可以从不同的视角得到各种数据。
（2）钻取
钻取包括上钻和下钻。争取能够帮助用户获得更多的细节性数据，逐层的分析问题的所在和原因。
上钻又称为上卷（roll-up）。上钻操作是指通过一个维的概念分层向上攀升或者通过维归约在数据立方体上进行数据汇总。例如在上面的示例中，可以按学历汇总数据，如把各种学历的都归约为所有学历，便可以得到沿学历维上钻的数据汇总。
下钻是上钻的逆操作，通过对某一汇总数据进行维层次的细分（沿维的概念分层向下）分析数据。下钻使用用户对数据能够获得更深入的了解，更容易发现问题本质，从而做出正确的决策。
钻取使用户不会再被海量的数据搞得晕头转向：上钻让用户站在更高层次观察数据，下钻则可以细化到用户所判决的详细数据。钻取的尝试与维度与维所划分的层次相对应，根据用户关心的数据粒度合理划分。
（3）旋转
旋转又称转轴，是一种视图操作，通过旋转变换一个报告或页面显示的维度方向，在表格中重新安排维的位置，例如行列转换。这种对立方体的重定位可以得到不同视角的信息。
（4）其他OLAP操作
除以上常用多维操作外，还有其他多维操作。
钻过（drill-across）。钻过操作涉及多个事实表的查询并把结果合并为单个数据集，一个典型的例子就是预测数据与当前数据的结合：通常预测数据与当前数据存在于不同的表中，当用户比较预测销售与当月销售时，需要跨多个事实表查询。
钻透（drill-through）。钻透使用关系SQL,查询数据立方体的底层，一直到后羰的关系表。
五、 OLAP的分类
OLAP分类
按处理方式分类
Server OLAP:绝大多数的OLAP系统都属于此类，Server OLAP在服务端的数据库上建立多维数据立方体，由服务端提供多维分析，并把最终结果呈现给用户
Client OLAP：所相关立方体数据下载一本地，由本地为用户提供多维分析，从而保证在网络故障时仍然能正常工作。
按存储方式分类
ROLAP。ROLAP使用关系数据库或扩充关系数据库（XRDBMS）存储管理数据仓库，以关系表存储多维数据，有较强的可伸缩性。其中维数据存储在维表中，而事实数据和维ID则存储在事实表中，维表和事实表通过主外键关联。
MOLAP。MOLAP支持数据的多维视图，采用多维数据组存储数据，它把维映射到多维数组的下标或下标的范围，而事实数据存储在数组单元中，从而实现了多维视图到数组的映射，形成了立方体的结构。大容量的数据使立方体稀疏化，此时需要稀疏矩阵压缩技术处理，由于MOLAP是从物理上实现，故又称为物理OLAP（Physical OLAP）。
DOLAP。DOLAP是属于单层架构，它是基于桌面的客户端OLAP，主要特点是由服务器生成请求数据相关的立方体并下载到本地，由本地提供数据结构与报表格式重组，为用户提供多维分析，此时无需任何的网络连接，灵活的存储方式方便了移动用户的需求，但支持数据有限，使用范围有限。
开源OLAP引擎：Mondrian
~/Desktop/Mondrian数据分析学习.pdf
http://mondrian.pentaho.com/documentation/
http://www.cnblogs.com/panfeng412/archive/2012/03/25/mondrian-aggregate-table.html
数据立方体：cube
在Mondrian里面的cube是以XML的形式定义的。(MDX)
Mondrian本身是不存储数据的，通过MDX语句（一个类似于SQL的查询语言）来获取数据，Mondrian 运行的时候要连数据库，并且还要有一个数据模型配置文件（Mondrian叫schema），其实就是一个取数据的规则；由此可知Mondrian只不过是把MDX 翻译成了SQL然后从数据库中把数据拿出来给用户
Mondrian是一个开放源代码的Rolap服务器，使用java开发的。它实现了xmla和jolap规范，而且自定义了一种使用mdx语言的客户端接口。Mondrian是olap服务器，而不是数据仓库服务器，因此Mondrian的元数据主要包括olap建模的元数据，不包括从外部数据源到数据库转换的元数据。也就是说Mondria的元数据仅仅包括了多维逻辑模型，从关系型数据库到多维逻辑模型的映射，存取权限等信息。在功能上，Mondrian支持共享维和成员计算，支持星型模型和雪花模型的功能。
Mondrian 是一个开源项目，是开源项目Pentaho的一部分，是一个用Java写成的OLAP引擎。它实现了MDX语言、XML解析、JOLAP规范。
它从RDBMS和其它数据源读取数据并把数据聚集在内存缓存中，然后经过Java API用多维的方式对结果进行展示，同时可以不写SQL就能分析存储于SQL 数据库的庞大数据集，可以封装JDBC数据源并把数据以多维的方式展现出来。
整体的项目架构，四个大部分Schema manager、Session Manager、Dimension Manager、Aggregate Manager
- l Schema Manager：与初始化紧密相关。主要是一些重要的数据结构如缓存池的构建以及多维模型的生成。
- l Session Manager：最为重要的一个部分。接受MDX查询、解析MDX，返回结果。
- l Aggregate Manager：实现了对聚集表的管理。主要是对OLAP缓存的管理，属于性能优化的部分。
- l Dimension Manager：维度的管理。实现多维模型中维度和关系数据库表中列的映射，在Schema Manager也有部分功能处理这些映射。
Mondrian通过Schema来定义一个多维数据库，它是一个逻辑概念上的模型，其中包含Cube（立方体）、Dimension（维度）、Hierarchy（层次）、Level（级别）、Measure（度量），这些被映射到数据库物理模型。Mondrian中Schema是以XML文件的形式定义的。
- Cube（立方体）由维度构建出来的多维空间，是一系列Dimension和Measure的集合区域，它们共用一个事实表。
- Dimension（维度）观察数据的一种角度，维度可以理解为立方体的一个轴。是一个Hierarchy的集合，维度一般有其相对应的维度表，它由Hierarchy（层次）组成，而Hierarchy（层次）又是由组成Level（级别）的。
- Hierarchy（层次）是指定维度的层级关系的，如果没有指定，默认Hierarchy里面装的是来自立方体中的真实表。
- Level（级别）是Hierarchy的组成部分，使用它可以构成一个结构树，Level的先后顺序决定了Level在结构树上的位置，最顶层的 Level 位于树的第一级，依次类推。
- Measure（度量）是我们要进行度量计算的数值，支持的操作有sum、count、avg、distinct-count、max、min等。
在多维分析中，关注的内容通常被称为度量(Measure)，而把限制条件称为维度(Dimension)。
多维分析就是对同时满足多种限制条件的所有度量值做汇总统计。包含度量值的表被称为事实表(Fact Table)，描述维度具体信息的表被称为维表(Dimension Table)
Ø 立方体：由维度构建出来的多维空间，包含了所有要分析的基础数据，所有的聚合数据操作都在立方体上进行。
Ø 维度：就是观察数据的一种角度。在这个例子中，路线，源，时间都是维度，
Ø 维度成员：构成维度的基本单位。对于时间维，例如它的成员分别是：第一季度、第二季度、第三季度、第四季度。
Ø 层次：维度的层次结构，要注意的是存在两种层次：自然层次和用户自定义层次。对于时间维而言，(年、月、日)是它的一个层次，(年、季度、月)是它的另一个层次，一个维可以有多个层次，层次可以理解为单位数据聚合的一种路径。
Ø 级别：级别组成层次。对于时间维的一个层次(年、月、日)而言，年是一个级别，月是一个级别，日是一个级别，显然这些级别是有父子关系的。
Ø 度量值：要分析展示的数据，即指标。如图1中一个cell中包含了两个度量值：装箱数和截至时间，可以对其进行多维分析。
Ø 事实表：存放度量值的表，同时存放了维表的外键。所有的分析用的数据最终都是来自与事实表。
Ø 维表：一个维度对应一个或者多个维表。一个维度对应一个维表时数据的组织方式就是采用的星型模式，对应多个维表时就是采用雪花模式。雪花模式是对星型模式的规范化。简言之，维表是对维度的描述。
l MDX查询：多维模型的查询语言MDX(MDX是微软发布的多维查询语言标准),它的语法与SQL有很多相似之处：select {[Measures].[Salary]} on columns, {[Employee].[employeeId].members} on rows from CubeTest对于这条语句，COLUMNS 和 ROWS都代表查询轴，其中COLUMNS代表列轴，ROWS代表行轴。COLUMNS又可以写成0，ROWS又可以写成1，当只有两个查询轴时，可以理解为结果的展现格式是一个平坦二维表。这条语句的含义就是查询名字为CubeTest的立方体，列显示Measures维度的salary，行显示 Employee维度employeeId级别的所有成员，那么得出的结果就是employeeId所有成员的salary，也就是所有员工的薪酬。具体语法规范和帮助文档可以参考微软的用户文档。
百万级事实数据：按照Mondrian文档中所描述的内容可以看出，只基于操作系统环境和数据库环境的优化，Mondrian Server在百万行级别数据量的事实表（关系数据库）仍能够运行良好。当然这需要我们自己来评测和证实。
千万级事实数据：当事实表数据立方体的数据量达到千万行以上时，Mondrian建议采用"汇总表"或者是由数据库支持的类似Oracle数据库的"物化视图"功能来优化OLAP查询的性能。
Mondrian缓存设置：由于Mondrian会将查询过的数据缓存起来，所以Mondrian建议缓存的大小根据具体项目的实际情况判断，当然是缓存越大越好
Mondrian缓存控制
为了提高海量数据下的查询响应速度，Mondrian自动将首次查询的结果缓存到内存中，之后的查询如果命中缓存内容，则不再访问数据库。这种实现方式有点自不必说，
但是在实现实时OLAP时会存在问题，实时OLAP中数据变化频繁导致缓存中的数据不是最新的。
缓存控制接口：为了做到不重启OLAP Server也能更新缓存，Mondrian提供了一系列的刷新缓存的接口，支持指定清除指定schema的元数据缓存、查询结果缓存；清除动作可以是全部清除 也可以是 部分清除（可以指定清除某个维度下某级别成员的相关内容）。
数据变化监听： Mondrian提供了缓存控制接口（被动响应），但对于实现我们的目标"实时OLAP"来说我们就需要自己实现一个数据变更监听的模块，来监听数据变化，一旦数据有变化就发起变更事件，更新Mondrian引擎的缓存。目前初步考虑实现方案为ETL工具在数据处理结束后通知OLAP引擎。引擎收到数据变更通知后做清理缓存的动作。
Jpivot：简单说是一个展示工具，有人说是个标签库，类似于struts。只是用来显示mondrian传来的xml数据，将其渲染成我们熟悉的html。对于层次性很强的报表，XML渲染的确有他的魅力，免去了繁杂的js痛苦。总之mondrian是用来研究和提取数据，jpivot是用来显示数据。至于jpivit是如何显示数据，主要是通过xls+xml。 Jpivot本身的界面是很难看的。
Pentaho、Saiku、Jpivot都用到了Mondrian做为其多维数据处理的服务器，网上的很多关于Mondrian的文章也都是以Jpivot来进行分析的，
不过Jpivot已经被抛弃了作者也不再更新了，并且Jpivot只能支持到Mondrian3.5 所以对于新版本的Mondrian一定是不能用Jpivot了（不过Jpivot有一个替代品Pivot4j这个还在持续维护），
这里还是推荐大家用Saiku或者Pivot4j
如果我们不想用Saiku、pivot4j 这样现成的东西（毕竟有很多东西我们用不到）那么可以把Mondrian 集成到我们自己的应用中去
模型配置文件编写
http://mondrian.pentaho.com/documentation/schema.php
personDemo.xml
<Dimension name="部门" foreignKey="USERID" >
<Hierarchy hasAll="true" primaryKey="USERID" allMemberName="所有部门" >
<Level name="部门" column="DEPARTMENT" uniqueMembers="true" />
<Measure name="人数" column="USERID" aggregator="distinct count" />
对应表：
CREATE TABLE `person` (
`userid` varchar(100) ,
`department` varchar(100) ,
`username` varchar(100),
`sex` varchar(100) ,
`nationality` varchar(100),
`post` varchar(100),
`zyjslb` varchar(100),
`zyjsdj` varchar(100) ,
`zhixi` varchar(100),
`xueli` varchar(100) ,
`age` int(10) ,
PRIMARY KEY (`userid`)
)
MDX查询语句：select NON EMPTY {[Measures].[人数]} on columns, NON EMPTY {([部门].[所有部门], [职系].[所有职系], [专业技术资格类别].[所有专业技术资格类别], [专业技术资格等级].[所有专业技术资格等级], [学历].[所有学历], [民族].[所有民族], [性别].[所有性别])} ON rows from Person
模型配置文件XML元素分析
http://www.biaodianfu.com/olap-mondrian.html
Schema
Schema 定义了一个多维数据库。包含了一个逻辑模型，而这个逻辑模型的目的是为了书写 MDX 语言的查询语句。这个逻辑模型实际上提供了这几个概念：
- Cubes: 立方体
- Dimensions: 维度
- Hierarchies: 层次
- Levels: 级别
- Members: 成员
而一个schema 文件就是编辑这个 schema 的一个xml 文件。在这个文件中形成逻辑模型和数据库物理模型的对应。
Cube
一个 Cube 是一系列维度 (Dimension) 和度量 (Measure) 的集合区域。在 Cube 中， Dimension 和 Measure 的共同地方就是共用一个事实表。 Cube 中的有以下几个属性：
- name: Cube 的名字。
- caption: 标题 , 在表示层显示的。
- cache: 是否对 Cube 对应的实表用 mondrian 进行存储 , 默认为 true。
- enabled: 是布尔型的 , 如果是被激活 ,Cubes 就执行 , 否则就不予理睬，默认为 true。
- Cube 里面有一个全局的标签定义了所用的事实表的表名。
Dimension
他是一个层次（ Hierarchies ）的集合 , 维度一般有其相对应的维度表 . 他的组成是由层次(Hierarchies)而层次(Hierarchies)又是有级别(Level)组成 . 其属性如下：
- name: Dimension 的名称。
- type: 类型，有两个可选的类型： StandarDimension 和 TimeDimension ，默认为StandardDimension。
- caption: 标题 , 在表示层显示的UsagePrefix加前缀 , 消除歧义。
- foreignKey: 外键，对应事实表中的一个列，它通过
元素中的主键属性连接起来。
Hierarchy
你一定要指定其中的各种关系,如果没有指定,就默认 Hierarchy 里面装的是来自立方体中的真实表 . 属性如下：
- name: Hierarchy 的名称，该值可以为空，为空时表示 Hirearchy 的名字和 Dimension 的名字相同。当一个 Dimension 有多个 Hierarchy时，注意 name 值要唯一。
- hasAll: 布尔型的 , 决定是否包含全部的成员 member。
- allMemberName: 所有成员的名字 , 也就是总的标题 , 例如： allMemberName= "全部产品"。
- allLevelName: 所有级别的名字，它会覆盖其下所有的 Member 的 name 和所有的 Level 的 name 属性的值。
- allMemberCaption: 例如 : allMemberCaption= "全部产品"这个是在表示层显示的内容。
- PrimaryKey: 通过主键来确定成员，该主键指的是成员表中的主键，该主键同时要与 Dimension 里设置的 foreignKey 属性对应的字段形成外键对应关系。
- primaryKeyTable: 如果成员表不只一个，而是多个表通过 join 关系形成的，那么就要通过这个属性来指明 join 的这些表中，哪一个与Dimension 里设置的foreignKey 属性形成外键关系。通过该属性来指明主表。
- caption: 标题 , 在表示层显示的。
- defaultMember
- memberReaderClass 设定一个成员读取器，默认情况下 Hierarchy 都是从关系型数据库里读取的，如果你的数据不在 RDBMS 里面的话，你可以通过自定义一个member reader 来表现一个 Hierarchy 。
Level
级别 , 他是组成 Hierarchy 的部分。属性很多，并且是 schema 编写的关键，使用它可以构成一个结构树， Level 的先后顺序决定了 Level在这棵树上的的位置，最顶层的 Level 位于树的第一级，依次类推。 Level 的属性如下：
- name: 名称
- table: 该 Level 要使用的表名
- column: 用上面指定的表中某一列作为该 Level 的关键字
- nameColumn: 用来显示的时候使用，如果不定义，那么就采用上面的 column 的值来进行显示。
- oridinalColumn: 定义该 Level 上的成员的显示顺序，如果不指定，那么采用 column 的值。
- parentColumn: 在一个有父 – 子关系的 Hierarchy 当中，当前 Level 引用的是其父成员的列名。好比是一张部门表，在一张表里表现部门的上下级关系，一个是主键，肯定还有一个字段为连接到该主键的外键的列名，这里的 parentColumn 指的就是这个列名。
- nullParentValue: 如果当前的 Level 是有上下级关系（设置了 parentColumn 属性），如果该 Level 又处于顶级，我们需要将顶级的数据取出来，这里指的是位于顶级的父成员的值，有些数据库不支持 null, 那么也可以使用0或-1 等，这就表示顶级的成员的父 ID 为0 或为-1 。
- type: 数据类型，默认值为 string 。当然还可以是 Numeric 、 Integer 、 Boolean 、 Date 等。
- uniqueMembers: 该属性用于优化产生的 SQL ，如果你知道这个级别和其父级别交叉后的值或者是维度表中给定的级别所有的值是唯一的，那么就可以设置该值为 true ，否则为 false 。
- levelType: 该 Level 的类型，默认为 regular （正常的），如果你在其 Dimension 属性 type 里选择了 TimeDimension 那么这里就可以选择 TimeYears 、 TimeQuarters 、 TimeMonth 、 TimeWeeds 、 TimeDays 。
- hideMemberIf: 在什么时候不隐藏该成员，可选的值有三个： Never 、 IfBlankName 、 IfParentName
- approxRowCount: 该属性可以用来提高性能，可以通过指定一个数值以减少判断级别、层次、维度基数的时间，该属性在通过使用 XMLA 连接Mondrian 很有用处。
- caption: 标题 , 在表示层显示的。
- captionColumn: 用来显示标题的列。
- formatter: 该属性定义了 Member.getCaption() 方法返回的动作值，这里需要是一个实现了 mondrian.olap.MemberFormatter 接口的类，用来对Caption地值进行格式化。
Join
对于一个 Hierarchy 来说，有两种方式为其指定：一种是直接通过一个 Table 标签指定；一种是通过 Join 将若干张表连接起来指定。一旦采用 Join 的话，那么就要在 Hierarchy 里的 primaryKeyTable 属性指定主表。
Measure
- Measure 就是我们要计算的数值，操作的核心。它的属性如下：
- name: 名称。
- aggregator: 要采用的计算函数。
- column: 要计算的列名。
- formatString: 计算结果的显示格式。
- visible: 是否可见。
- datatype: 数据类型，默认为 Numeric
- formatter: 采用类来对该 Measure 的值进行格式，具体参考 Level 的 formatter 属性。
- caption: 标题，用来显示时使用。
概括总结一下：在多维分析中，关注的内容通常被称为度量(Measure)，而把限制条件称为维度(Dimension)。多维分析就是对同时满足多种限制条件的所有度量值做汇总统计。包含度量值的表被称为事实表(Fact Table)，描述维度具体信息的表被称为维表(Dimension Table)，同时有一点需要注意：并不是所有的维度都要有维表，对于取值简单的维度，可以直接使用事实表中的一列作为维度展示。
什么是聚合表（Aggregate Table）
下描述了一个数据库的结构。该数据库中共有五张表，分别是Sales表，Customer表，Time表，Product表和Mfr表。这个数据库的作用是存储每一笔交易：包括这笔交易发生在什么时间，交易的产品类型，进行交易的客户信息，交易方式，交易了多少件产品以及成交金额是多少。
模型中有一张事实表（Sales），两个度量列（units和dollars），四个维度表（Product, Mfr, Customer, Time）。在这个星型模型的最顶层，我们创建了以下多维模型：
- [Sales]立方体包含[Unit sales]和[Dollar sales]两个度量值；
- [Product]维度包含[All Products]，[Manufacturer]，[Brand]，[Prodid]四个级别；
- [Time]维度包含[All Time]，[Year]，[Quarter]，[Month]，[Day]五个级别；
- [Customer]维度包含[All Customers]，[State]，[City]，[Custid]四个级别；
- [Payment Method]维度包含[All Payment Methods]，[Payment Method]两个级别。
假设现在我们要对交易做一些统计，例如，某一件特定产品在某一个时间段内以某种特定方式总共卖出多少件或多少钱，这时成交产品数和成交金额是我们最终关注的内容，其他的因素例如时间、产品、方式等都只是对我们最终关注内容进行统计的限制条件。
在上面的例子中，限制条件有时间、产品类型、用户类型和交易方式，
有时我们并不需要同时使用所有的限制条件，例如，当我们只想知道指定产品的成交总金额时，那么除了产品类型之外其他三个限制条件都是多余的，而在查询时，需要在整个事实表中执行查询，找出产品类型为指定类型的所有产品然后再做统计，为了提高查询效率，我们可以新建一张表，这张表按照产品类型把事实表中的行合并到一起，合并的方式是抛弃其他维，把度量值按特定的方式（max，min，sum，count或avg）整合到一起。这种表被叫做聚合表(Aggregate Table)。
聚合表的应用场景
事实表中的行构成了一个集合，每一维（或若干维）按照其取值的不同可以将事实表这个全集划分成若干个不相交的子集。聚合表所做的工作实际上就是把划分出的子集归为数据库表中的一行，这样做一方面可以减少数据库表的行数，另一方面也省去了查询时所需要做的一些统计工作，从而提高查询时的效率。
- 使用Mondrian做大数据量（如>100W行）的OLAP分析时，考虑是否可以使用聚合表进行优化。
- 然而Mondrian的优化方式又不限于聚合表这一种，是否要进行聚合表优化，要根据实际情况来决定。
- Mondrian目前并不提供对聚合表的数据同步机制，如果要做实时OLAP，需要自己实现聚合表和事实表中的数据同步。
聚合表的定义见：http://www.cnblogs.com/panfeng412/archive/2012/03/25/mondrian-aggregate-table.html
Schema-workspace图形化配置模型文件
http://sourceforge.net/projects/mondrian/files/schema%20workbench/
http://blog.csdn.net/athenaer/article/details/7947193
其他参考：http://blog.csdn.net/zhangzhongzhong/article/details/50685654
http://blog.csdn.net/xiaolang85/article/details/45248289
http://wushexu.iteye.com/blog/1960252