我们需要怎样的OLAP？

      OLAP是商业智能的重要组成部分.
     从字面上理解，OLAP是在线分析的意思，也就是由用户面对实时的业务数据进行分析操作。.
      但是，当前OLAP概念被严重狭义化了，仅指基于多维数据（或模拟出的类似结构）进行钻取、聚合、旋转、切片等操作，也就是多维交互分析。
      这种OLAP的应用，需要事先建好一批有针对主题的数据立方体（CUBE），然后用户可将这些数据以交叉表或图形的方式展现出来，并对其实时实施各种变换（旋转、钻取等），在过程中希望找出数据的某种规律或支撑某个结论的论据，从而达到分析目的。.
      这是我们需要的在线分析吗？
      要回答这个问题，我们需要认真考察一下在线分析的实际应用过程，从而弄清楚在线分析需要解决的技术问题到底是什么。.
       任何一个行业中有多年工作经验的从业人员一般都会对自己从事的业务产生一些猜测，如股票分析师会猜测满足某种条件的股票容易上涨；
航空公司会猜测何种人群习惯于购买哪类航班；
超市经营者也会猜测何种价位的商品更适应周边的人群；
…
      这些猜测正是预测的基础。而一个建设好的业务系统运行一段时间后也都会积累大量数据，这些猜测很可能已可由这些积累的数据去验证，证实了则可以用于预测，证伪了则再重新猜测。.
     需要注意的是，这些猜测是由用户自己做出的，而不是计算机系统！计算机应当做的，是辅助用户针对已有数据去证实或证伪猜测，也就是查询数据（包括一定的汇总运算），这就是在线分析的应用过程。之所以需要在线，是由于许多查询计算是用户看到了某个中间结果后临时想出来的。整个过程中不可能也不需要事先建模。
      我们将以上的过程称为核算过程，其目的是从历史数据中找到某些规律或结论的证据，采取的手段是对历史数据进行交互查询计算。
      可以举出一些实际要计算（或查询）的例子：
当年内销售额占了一半的前n个客户；
一个月内有连续3天涨停的股票；
超市中一个月发生三次在下午5点钟断档的商品;
本月销量比上月销量下降超过20%的商品；

……
      显然,这类计算需求在业务分析过程中普遍存在，并且都可以从历史数据库中计算出来。
     那么，狭义化的OLAP能用来完成上述核算过程吗？
       当然不能!
      当前OLAP体系有两个关键不足：
多维立方体由应用系统事先准备，用户没有临时设计和改造立方体的能力，一旦有新的分析需求则必须重建立方体；
立方体上可实施的分析动作单调。已定义的动作只有钻取、聚合、切片、旋转等少数几种，难以完成多步骤的复杂分析行为；
虽然当前OLAP产品的界面展现都很炫丽，但却没有提供多少真正称得上“在线分析”的能力。

      那么，我们需要什么样的OLAP？
      很简单，一种能够支持核算过程的在线分析体系！
     从技术上讲，核算过程的步骤可以被看成针对数据的计算（查询可以理解为过滤运算）。这种计算可由用户自由定义，并由用户根据已有的计算结果临时决定下一步计算动作，无需事先建模；另外，由于数据来源一般是数据库系统，因而要求这种计算能很好地支持批量的结构化数据，而不是简单的数值计算。
      那么，SQL（或MDX）可否充当这个角色呢？
     SQL确实是为了这个目标而发明的，它拥有完备的计算能力，并采用了类似自然语言的书写风格。
     但是，由于SQL的计算体系过于基础，用以完成复杂计算（例如前面列出的问题）时会非常困难和繁琐，对于受过专业训练的程序员都不容易，普通用户只能用SQL实现一些最基本的简单查询汇总计算（基于单表的过滤、合计等）。这个结果导致，SQL的应用已经偏离其发明初衷很远，几乎完全成为程序员的专用技术了。
      我们应当沿着SQL的思路，认真研究SQL的具体不足并找出克服方法，发展出新一代计算体系，从而实现核算过程，即真正的OLAP。