OLAP报表模型

联机分析（OLAP）是由关系数据库之父E.F.Codd于1993年提出的一种数据动态分析模型，它允许以一种称为多维数据集的多维结构访问来自商业数据源（如数据仓库）的经过聚合和组织整理的数据。以此为标准，OLAP作为单独的一类产品同联机事务处理（OLTP）得以明显区分。OLAP最基本的概念其实只有三个：多维观察、数据钻取、CUBE运算。

1、从动态的多维角度分析数据
　　我们在平时工作中，会遇到各种问题，在分析问题的时候，同样的现象，我们会从多个角度去分析考虑，并且有时候我们还会从几个角度综合起来进行分析。这就是OLAP分析最基本的概念：从多个观察角度的灵活组合来观察数据，从而发现数据内在规律。
　　OLAP将数据分为两种特征，一种为表现特征，比如性别、成本中心、工资组等；还有一种为角度特征，比如集团、分公司、部门、职位等。前者是被观察的对象，OLAP术语称之为"度量数据"，后者为观察视角，OLAP术语称之为"维数据"。
如果建立这样一个模型，我们就可以根据业务需求，从分公司角度去观察各个分公司的性别分布数据（以分公司为维、以性别为度量）；或者我们还可以从部门的角度去观察各个部门的性别分布数据（以分公司和部门为维、以性别为度量）。


在报表工具的OLAP模型中，每个模型最多可以设定255个维、1024个度量，也就是说，我们可以从255个角度或者角度组合，去同时观察1024个数据对象的变化。

2、对数据进行钻取，以获得更为精确的信息
　　　在分析过程中，我们可能需要在现有数据基础上，将数据进一步细化，以获得更为精确的认识。这就是OLAP中数据钻取的概念。
　　比如，在人事数据分析中，当我们以分公司为维、以性别为度量进行分析的时候，可能希望进一步观察不同分公司下的不同部门人员性别的分布，这时我们就可以在分公司这个数据维下面，再加上一个部门维，从而获得相应的信息。

3、创建数据CUBE
　　那么，要满足上述运算，需要什么样的前提呢？
　　我们可以想像，和报表不同，OLAP分析所需的原始数据量是非常庞大的。一个分析模型，往往会涉及数百万条、数千万条、甚至更多；而分析模型中包含多个维数据，这些维又可以由浏览者作任意的提取组合。这样的结果就是大量的实时运算导致的时间延滞。我们可以设想，一个对于1000万条记录的分析模型，如果一次提取4个维度进行组合分析，那么实际的运算次数将达到4的1000次方的数量：这样的运算量将导致数十分钟乃至更长的等待时间。如果用户对维组合次序进行调整，或者增加减少某些维度的话，又将是一个重新的计算过程。
　　从上面分析，我们可以得出结论，如果不能解决OLAP运算效率问题的话，OLAP将是一个毫无实用价值的概念。那么，作为一个成熟产品是如何解决这个问题的呢？这就是OLAP中一个非常重要的技术：数据CUBE预运算。
　　一个OLAP模型中，度量数据和维数据我们应该实现确定，一旦两者确定下来，那么我们可以对数据进行预先的处理，在正式发布之前，将数据根据维进行最大限度的聚类运算，运算中会考虑到各种维组合情况，运算结果将生成一个数据CUBE，并保存在服务器上。这样，当最终用户在调阅这个分析模型的时候，就可以直接使用这个CUBE，在此基础上根据用户的维选择和维组合进行复运算，从而达到实时响应的这么一个效果。
　　作为一个成熟的产品，报表工具的OLAP模型无论是在CUBE创建还是后续的浏览操作，效率都是非常高的。测试结果表明：原始数据行数在3200万条记录的时候，包含10个维数据组合、2个度量数据的CUBE，创建周期为132分钟，装载效率是12.5秒。这样的成绩对比世界上任何一个高端OLAP同类产品，都不逊色。


4、即插即用的OLAP技术
OLAP实施可以分为三个步骤进行，读者有兴趣可以尝试一下，看看能否在10分钟内完成从软件安装调试到OLAP设计部署的过程。
第一步、设计数据源
　　OLAP 分析所需要的数据需要以某种方式从数据库中提取出来，比如使用 SQL 语句，或者使用一个存储过程。这个 SQL 或者存储过程称之为一个数据源。
　　这个过程包括：
　　1、在报表工具的设计器中建立与多个数据库的连接参数；
　　2、按照数据提取需求，根据向导提示，选择并创建适当类型的数据源，并以图形化方式创建SQL等数据提取方法；
　　3、如果涉及多个异构数据库，还需要将这些异构数据库的数据以虚拟数据源形式建立关联整合，将其整合为一个在结构、逻辑上统一的数据源。
第二步、设计OLAP模型
　　在报表工具中，OLAP设计过程非常简单，通过向导创建一个OLAP模型，然后为该模型指定上一步设计的数据源，指定数据源返回信息中的维数据和度量数据即可。如果度量数据定义并非简单的聚类求和运算，还可以进一步设定度量数据的计算方法。
第三步、发布OLAP设计成果
　　报表工具提供了一个功能完整的Portal，最终用户就是通过这个Portal进行报表浏览和OLAP调用的。在报表工具中，OLAP和报表是在项目中一体化维护发布的，所有只要针对项目发布即可。
　　完成报表工具的项目发布后，还需要做两件事情，其一是OLAP使用授权，这在Portal的授权体系中可以得到定义；其二是OLAP的CUBE运算，我们在前面曾经谈到CUBE预运算的必要性，所以在部署项目后，我们还需要在Portal的任务定义模块中，定义CUBE运算创建的任务时间。
　　好了，通过以上三个步骤，一个新的OLAP模型不仅已经创建，并且已部署发布了。如果操作者是一个熟练的数据库管理员的话，这个过程完全可以控制在10分钟以内完成。相对于传统产品动辄3个月半年的实施效率，实在是天壤之别了。

5、OLAP的脱机与分发
想像一下这样几个应用场景（注，这些场景是报表工具在实际应用中发生过的真实场景）：
　　场景一：某投资顾问公司为客户提供了VIP服务，VIP用户可以定期收到顾问公司发来的外汇、证券等分析数据，并可以使用OLAP方式对这些数据进行分析。考虑到数据安全性要求，顾问公司不打算在互联网上提供操作平台，而是直接将数据及分析模型发送到各个VIP客户的电子邮箱中，用户只能对收到的数据进行分析操作，以这样手段限制用户的访问范围，从而达到保证数据安全的目的。
　　场景二：某企业老总经常出差，在旅途中并不方便随时接入互联网以连接公司IT系统。更多时候是在有条件上网的时候，不方便详细观察分析业务数据，等到有空来做这些事情，又未必有网络条件了。

1、报表工具的解决方案
　　上面两个场景，都涉及到OLAP的脱机分发与使用。
　　报表工具通过浏览端的一个小插件完成这些功能。在标准的运行过程中，工具的服务器，将创建好的数据CUBE进行加密和压缩后，发送给浏览端，而后由浏览端进行自动的校验、解密、解压缩，并允许用户进行多维度的OLAP分析。
　　报表工具具有世界上最先进的的CUBE创建算法，从而保证了CUBE数据在浏览端进行多维复运算的高效率和低运算负荷，在普通的PC上，可以达到秒级的响应指标。这样，报表工具就完全具备了脱机运行的条件，用户在分发的时候只要单独提取CUBE文件进行分发即可，剩余的事情由浏览端插件负责完成。
　　额外提一句，在报表工具的Portal中，已经提供了定时Mail的功能，只要系统管理员设定，就可以自动完成Mail分发的功能。