这是一个困惑!其实我们可以从E.F.Codd博士定义的OLAP概念中找一找这个困惑的答案。OLAP是关系数据库之父E.F.Codd于1993年提出的一种数据动态分析模型,它允许以一种称为多维数据集的多维结构,访问来自商业数据源经过聚合和组织整理的数据。以此为标准,OLAP作为单独的一类产品同联机事务处理(OLTP)得以明显区分。
我们在平时工作中,会遇到各种问题,在分析问题的时候,同样的现象,我们会从多个角度去分析考虑,有时我们还会从几个角度综合起来进行分析。这就是OLAP分析最基本的概念–从多个观察角度的灵活组合来观察数据,从而发现数据内在规律。
OLAP将数据分为两种特征,一种为表现特征,比如一个销售分析模型中的销售额、毛利等;还有一种为角度特征,比如销售分析中的时间周期、产品类型、销售模式、销售区域等。前者是被观察的对象,OLAP术语称之为”度量数据”,后者为观察视角,OLAP术语称之为”维数据”。
如果建立这样一个模型,我们就可以根据业务需求,从产品类型角度,去观察各个销售地区的销售额数据(以产品类型和销售地区为维、以销售额为度量);或者我们还可以从销售模式的角度,去观察各个销售地区的销售额数据(以销售模式和销售地区为维、以销售额为度量)。
关于数据钻取
在分析过程中,我们可能需要在现有数据基础上,将数据进一步细化,以获得更为精确的认识。这就是OLAP中数据钻取的概念。
比如,在销售分析中,当我们以产品类型和销售地区为维、以销售额为度量进行分析的时候,可能希望进一步观察某类产品的不同销售模式在各个销售地区的表现,这时我们就可以在产品大类这个数据维下面,再加上一个销售模式维,从而获得相应的信息。
关于CUBE运算:
OLAP分析所需的原始数据量是非常庞大的。一个分析模型,往往会涉及数百万、数千万条数据,甚至更多;而分析模型中包含多个维数据,这些维又可以由浏览者作任意的提取组合。这样的结果就是大量的实时运算导致时间的延滞。
我们可以设想,一个1000万条记录的分析模型,如果一次提取4个维度进行组合分析,那么实际的运算次数将达到4的1000次方的数量。这样的运算量将导致数十分钟乃至更长的等待时间。如果用户对维组合次序进行调整,或增加、或减少某些维度的话,又将是一个重新的计算过程。
从上面的分析中,我们可以得出结论,如果不能解决OLAP运算效率问题的话,OLAP将是一个毫无实用价值的概念。那么,一个成熟产品是如何解决这个问题的呢?这涉及到OLAP中一个非常重要的技术–数据CUBE预运算。
一个OLAP模型中,度量数据和维数据我们应该事先确定,一旦两者确定下来,我们可以对数据进行预先的处理。在正式发布之前,将数据根据维进行最大限度的聚类运算,运算中会考虑到各种维组合情况,运算结果将生成一个数据CUBE,并保存在
服务器上。
这样,当最终用户在调阅这个分析模型的时候,就可以直接使用这个CUBE,在此基础上根据用户的维选择和维组合进行复运算,从而达到实时响应的效果。
从以上OLAP三点基本概念出发,我们可以在实践中发现问题的所在,OLAP概念没有错,用户也没有错,错在目前业内的OLAP产品的设计思路上!
从OLAP产品来看,由于”多维角度”的变化来自于用户部门,而IT部门采用的OLAP产品使”多维角度”转化成数据库设计,但为了实现”CUBE运算”,”度量数据”和”维数据”需要提前固化,这样限制了业务部门对”多维角度”快速变化的要求,使BI项目变成了日常统计报表项目,使OLAP分析变得无法实现。
OLAP产品需要新一代工具
新一代OLAP工具设计的思想,不应该关注报表工具本身功能:IT部门不要制作报表,仅关注OLAP的功能,不需要做OLAP的报表展现,报表完全由业务部门来实现。主要基于以下两点:
一.从桌面报表的使用能力和使用量来描述,业务部门的人员已经远远超过IT部门的人员,因此,IT部门目前不太可能提供出一个报表工具,来取代业务部门使用的桌面报表工具。
二.报表本身的含义需要业务部门用精湛的业务知识来诠释,如果报表由IT部门来制作的话,会出现知识传递过程中的误差,这是OLAP实施中最大的问题。
基于以上两点,新一代OLAP工具设计思想就是:如何使OLAP工具和Excel报表工具能够无缝交流,应该有一个”分析角度”的技术,来实现业务部门和IT部门对”多维角度”的各自表述。让业务部门自己来做”分析角度”,自己来做报表,让IT部门利用OLAP概念来设计基础数据。