如前所说，Mondrian是OLAP的核心引擎，负责从关系数据库中计算、缓存数据，响应来自表现层的使用MS家 MDX语法的查询。具体表现形式呢，就是一个jar，随Tomcat启动。

看完那个FoodMart的Sample之后, 该自己动手了。

首先第一步是设计OLAP的数据库结构。

因为和业务数据库相比，OLAP需要冗余一些数据达到更快的查询。
设计前可以先参拜一下那本经典的《完全维度设计指南》，中文版的几下就能翻个大概。
其实说白了就是去除与报表无关的列，把订单、订单明细两个表合并成一个销售事实表，把产品，产品分类两个表合并成一个产品维表这几个动作。
设计完之后，应该会有几个装有统计数据和维表外键的事实表，和几个用于分类，排序，过滤的维表。

第二步是把业务数据库里的数据导过来。

有不少ETL的工具，弄出一大堆映射文件，转换类来。不过我还是喜欢直接写SQL快捷，可能我面对的不是一天一个G的数据库吧。

第三步是把刚才设计的数据库结构定义成Schema

schema元模型包括 维度（Dimensions）、层次（Hierarchies）、级别（Levels）、和成员（Members）等。Mondrian要根据它来从关系数据库中聚合数据响应MDX语法的查询。

在这一步之前记得先装一个中文版的SQL Server2000，里面的Help文件有详细的解释。
另外jprovit有一个子项目，是这个schema的Eclipse Plug-in。即使不用这个Plug-in，有了它的DTD，在其他XML编辑器里也能避免拼写错误引起的冤枉时间。
用Sample中的FoodMart.xml做蓝本，两下就能Copy Paste出自己的schema来。
最后，注意Oracle的列名必须全大写。

下篇
JProvit应用（待写，JProvit升级太快了）

穷人的通用OLAP方案I                                    

缘起

从前到现在，用户需要从IT系统中获取信息的变化无常与程序员从传统数据库中制作报表的代价是一个永恒的矛盾。

这边厢程序员为了应付客户忽然而至的报表需求痛苦不已, 客户只想要他想知道的东西,不会管查询语句有多么复杂，优化从海量数据中提取报表的速度有多么困难。

那边厢客户为了等程序员做一个报表，快则半天，慢则一周，事情都过去了。明明只想知道一样很简单的东西, 程序员却要抱怨查询是多么复杂，数据结构是如何制约。有时候出一个报表要呆在屏幕前等半天。

而OLAP是唯一一种真正让用户获得自己所需要的报表而且不用付出巨大实现代价的方法。它能够让用户自由的定制自己的查询条件，观察、累计的维度，最后从海量数据中快速生成它。

方案

经过几年的发展，各大数据库供应商都有了自己的OLAP方案。不过我们一来不想把产品绑定在某个数据库上，二来没钱，所以还是要寻求穷人们自己的免费且底层数据库通用的方案。

从AgileJava的Blog上，看到了Mondrian + JPivot。再加上CloverETL，方案就成了：

CloverETL

CloverETL是一个数据ETL框架，负责把业务数据提取出来，转化为OLAP所需要的型式，依旧保存到关系数据库中。典型的，父子关系的Order,OrderItem表，就需要转换为一个事实表，在OrderItem中大量冗余Order的数据如日期，顾客，分店等以方便统计。看上去这在CloverETL的框架下只是几行代码，三个表结构定义的事情。

Mondrian

蒙德里安，OLAP核心引擎，负责从关系数据库中计算、缓存数据，响应来自表现层的使用MS家 MDX语法的查询。这个微软家的MDX语法，学起来并不难，SQL Server的书也统统有教。
在这一层要做的事情就是定义一个schema元模型，包括 维度（Dimensions）， 层次（Hierarchies），级别（Levels），和成员（Members）等。Mondrian要根据它来从关系数据库中聚合数据响应MDX语法的查询。

JPivot

OLAP JSP custom tag library。提供OLAP Navigator与多 维数据的显示，并支持图表生成和Export to Excel。Mondrian的御用表现层。

初遇

Mondrian用了MS家著名的FoodMart数据作例子，Access作底层数据库，JPivot做表现层，让你几分钟之内就能把Example跑起来，感受一下OLAP报表是什么样子的。跑完一遍之后，我就发现做个客户自定制的OLAP报表如此简单.....