企业经常需要把数据集成到很多操作系统中，可以通过以下两个技术实现：

　　· 提取、转换和加载过程(ETL)：采用这种方法，企业首先要建立一个集中式数据仓库，然后为利益相关的数据构建一个全局模式。对于每一个操作系统，企业将采用某种形式的ETL过程把数据实例转换成全局模式，然后再把他们加载到集中式数据仓库中。

　　· 数据联合(Federate)：这是数据集成的另一种方法，企业也需要像ETL方法所述的那样构建一个全局模式，只是把数据保留在它原来的存储位置。企业会采用MetaMatrix或Aqualogics这样的数据联合器，而不再自己构建一个集中式数据仓库。查询(包括更新)可以提交给联合器进行处理。反过来，联合器会计算出哪些查询或更新操作需要运行在哪个操作系统，才能对提交的命令反馈回来正确的结果。

　　接下来，我们来看看这两种处理方法都有哪些优缺点，而我们应该采用哪一种方法才能高效达到我们的目的。

　　数据元素: ETL更适合频繁查询的“热数据”

　　如果使用ETL过程进行数据集成，当一个数据元素被提取出来时，数据转换过程才开始了。而在数据联合过程中，数据转换是发生在查询时间里。如果某个数据元素经常要被查询，只进行一次转换的成本显然要低的多，所以用ETL过程更合适。反过来，如果某个数据元素从来不会被查询或者查询的次数很少时，使用联合过程择更明智。总之，对于经常发生查询更新的“热数据”最好采用ETL的解决方案。

　　索引：数据联合更难优化

　　联机事务处理对于数据索引的要求往往与数据仓库对查询索引的要求明显不同。因此，在ETL处理方法中，数据仓库作业负荷的优化可以与联机事务处理的优化分离开，在不同的硬件上进行。而数据联合处理方法中，数据库管理员必须在同一个数据库中平衡两者的作业负荷，这要比分别优化各自的作业负荷更复杂。

　　资源管理：想要商业智能查询响应更快捷就用ETL过程

　　在数据仓库中，商业智能用户可以享用到专门用于优化索引查询的工具。相比之下，数据联合技术对联机处理事务执行的优先程度没有那么高，这导致了对商业智能查询的反应很慢，建议你在等待某个查询结果时可以先出去喝杯茶吃个饭。

　　模式转换的复杂性：ETL过程的连接处理更少

　　很多数据仓库都采用星型模式或雪花模式。而大部分的联机事务处理系统都采用非雪花模式。因此，全局模式随着操作模式的不同而发生显著变化。这种情况下，全局模式中的某个记录很可能时来自操作模式中的几个不同的记录。因此，联接器必须在每次查询的时候都执行该连接。而ETL系统则只是在加载时进行一次连接。所以，在模式映射过程变得复杂的时候，ETL处理方法表现更优异。

　　并发控制：数据联合冲突面临挑战

　　在ETL系统中，必须定期从操作系统抽取数据元素。这些数据元素一旦加载到中央数据仓库，其存储属性就变为只读了。因此，在ETL过程中基本上不会有锁争用的情况发生。而数据联合过程会在操作系统中把商业智能查询和事务处理混合起来执行，其结果就是导致出现锁争用和其他资源冲突。

　　时效性：ETL过程必须处理过时数据问题

　　数据仓库加载过程有一半时间其数据基本都是过时的。而联合器却能够随时更新信息。为了解决这个缺陷，一些新的数据仓库系统(如，Vertica)允许数据加载过程和查询过程并行处理，这个程序称为trickle loading。

　　映射：数据联合无法处理某些转换

　　对于操作型数据库来说，常常要获取客户信息，例如客户姓名等。在ETL过程中，无论你什么时候需要某个客户资料，你总能在某个包含了从操作系统名到全局模式名映射的稳定增长表中找到其资料。如果某个客户名不存在，就可以添加关于该客户的新记录。因此，姓名映射是由一个映射表所支持的一种全局性操作。不过，这难以保证能够把相同的映射应用到每个操作系统，除非各个系统保留和更新相同的映射表。而联合器没有相应的工具进行来对状态信息来说必须的映射功能。因此，很难同时执行某些转换。

　　总结：ETL过程在很多情况下更胜一筹

　　总而言之，几乎所有企业都使用ETL方法来进行数据集成。数据联合市场相对来说要小得多。当数据源非常多(例如，有超过5000个数据源)而且商业智能用户在任何特定时间里只会用到其中很小的一部分时，数据联合应用才显出优势。在极端情况下，凭据每个数据元素在更新或删除之前的访问量为零，这时我们最好让数据保留在它来源地。相反，当大部分的数据元素都会被利用若干次时，这也是更常见的情形，ETL过程还是我们的首选。

        所谓报表工具，最核心最本质的功能，就是它的制表能力，即是否能够不写代码而制作出自己需要的各种报表工具。但用户在考察报表工具时往往很注重打印输出、绘制方案、管理调度等外围因素，而忽视了报表工具最本质的制表能力。当然不可否认这些外围的功能对一个报表工具来说也是很重要的衡量标准，但是报表工具的主要用途是制作报表，而且事实上，市场上的主流产品在处理复杂报表时确实存在明显缺陷，并不能很好地制作出我们需要的报表，半数以上报表仍需编写代码准备数据，导致工具失去意义。因此，考察制表效率对于选择报表工具是至关重要的。

扔掉条子
        报表绘制的方法一般有 网格式 和 控件拖拽式 两种，前者采用和EXCEL类似的方案，用网格线围出报表；而后者则是用矩形框等元素拼出报表。国内报表对样式要求非常复杂而且严格，绘制方案是报表工具相当重要的指标，它决定了报表样式的复杂度和绘制效率，特别是对于格线比较多的表。

        传统的报表绘制，大多数是呈条带状，用的拖拽式，拿部件拖来拽去。表格线需要靠矩形边框重合摆放拼接出来，常见的复杂多层表头画起来非常繁琐，数据区某些纵向合并格甚至无法绘制出来(或者需要特定程序控制才能实现)，拼出的格线还与分辨率相关，屏幕上对齐的表在打印时或在WEB上显示时又可能不整齐。

        网格式在这方面有明显的优势，能够画出样式很复杂的报表，绘制效率也比控件拖拽式高出许多。由于MS Excel软件的普及，在大多数人心中画表软件就是Excel，对于Excel软件的操作也都很熟悉。这样也能节省许多学习成本。

        所以，类EXCEL的方法明显优于拖拽式，或者说，画报表就应该是用象Excel那样的方法。大概稍有点常识的人，都会拿Excel画表吧。所以，类Excel是必然的方向。

        因为Excel很早就已普及了。所以提及报表工具，自然首先都会想到用类Excel方式，而为什么控件拖拽式的报表工具会这么多呢？
        这是因为Excel虽然具有强大的绘表能力，但数据处理能力非常弱，除非用“A2+B3=D4”这样的公式将单元格联系起来，否则单元格之间是相互独立的，没有任何关系的。如果要从数据库或数据文件中取数，需要程序员一个单元格一个单元格去定义，工作量相当繁重。需要靠程序员编程来实现动态行列报表的制作。

        因为报表格式只是报表工具要解决的一部分问题。我们用报表工具的目的，是要能从数据库中读出数据，从而自动产生报表，数据才是报表要解决的核心问题。报表格式用Excel可以解决得很好，但是Excel没有良好的从数据库中进行数据汇总方案，除非编程序往格子里填数据，基本上没法从数据库中读出数据自动产生报表。因此这种报表几乎都只能做静态报表。

        而拖拽式的格式虽然解决得一般，但从数据库中取数进行数据统计能力方面要比Excel强得很多，两害相权取其轻，堆框虽费劲，慢慢堆就行了，但统计汇总不行的话那就没办法了。

        报表工具软件和其它软件一样都是国外先做出来的，而国外的报表的样式非常规整，没有格线，表头非常简单，没有斜线表头、没有分层分组。一张报表提供的信息有限，如果要看所有信息，就只能几张表对照着看了。因而国外的报表工具采用控件拖拽式能弱化报表样式绘制能力弱的缺点。而国内的报表工具基本上都是学习国外的报表工具模型来设计的。而中国式报表的样式相当复杂，所以很多报表工具都被迫再辅以大量的程序代码来处理中国式报表，这也使得用户在买了报表工具后，做报表的工作量还是很大。

多源分片
        多源是指一个报表的数据来源来自多个物理数据表，甚至是多个物理数据库。这里的“多个”指的两个以上的物理数据库。
        传统的报表工具只支持单源报表，即使是数据来自于多个物理数据表或者物理数据库，也需要在报表设计前将多源转化成单源处理。两三个源尚可写SQL语句完成，但多到五六个源以上时，一方面对应的SQL语句过于复杂难以维护，另一方面其运行效率降低，这时常常要编写存储过程或其它代码来准备数据了。这还只是单数据库的情况，如果多源来自多库，则更为复杂，无法直接写出复杂SQL或存储过程，需要架构专门的数据库桥后才可以完成。
        某些传统报表工具也声称可支持多源，实际上指的是多数据库支持，只是把数据库桥功能集成进入报表工具中，但真正到报表设计时仍然是单源的。和我们所说的多源有很大差别。
        多源往往带来分片，正是由于分片，使得报表设计必须直接基于多源进行，而不能先将多源转成单源进行。有相当一部分分片报表无论如何也不可能换成单源处理，部分能转成单源的报表处理也非常繁琐。
        分片是指报表的纵向或横向或双向同时被分成了多个区域，每个区域重复规则不同，而又可能相互运算。
        传统工具能够处理的上下格式一致和列方向固定的分片报表(即可由多源转成单源的报表)，但会迫使用户编写复杂的SQL（UNION+JOIN）和代码准备数据，导致工作量大且维护困难；而且对于横向分片数较多报表，由于必须采用JOIN方式准备数据，导致运算性能极低，复杂度为O(Nk)，k为分片数。

不规则划分

        几乎所有的报表工具都支持独立的分组报表格式，即传统的通过一个绑定数据的过程来完成分组报表的设计，这种分组是完全规则划分的，即划分标准一致且有规则（一般都按某个字段或表达式），所有字段都必须出现且只出现一次，分组值次序与原数据记录次序一致。
        但是与完全划分相对应的，在报表汇总中却常常需要不规则划分，即划分标准看不出规律（常常只能穷举），所有事实不一定全部出现在分组结果中、个别事实还可能重复出现，次序也与原数据记录无关。固定分组是不规则划分的常见表现。
        例如下面这张报表。年龄段的分组就是个不规则划分，划分规律不明确，只能穷举出来；分组不完全，50岁以上的则被整合到一个组内。

        这个报表用传统工具实现很困难，虽然报表格式并不复杂，但由于出现了不规则划分，无法直接用报表工具的分组功能完成，只能编程把数据准备成一个单层的二维表数据源，即加大了工作量，又很难体现数据之间的层次关系。

动态格间运算

        所有的报表工具都会提供一些计算列的功能，在原始数据基础上再计算出一些别的列值或统计值，这是报表展现中是不可缺少的功能。
        传统工具一般只提供同行内的格间运算和针对某组（或全体）的集合运算，对于常见的跨行组运算则相当困难。个别传统工具提供了简单的跨行能力，如可以引用上一行数据，而跨组则无能为力；对于集合运算只提供个别固定的函数，如取第一名、算累计值等，无法组合出的通用集合运算则无计可施，如取第二名、算累计的乘积等。某些带条件的运算更是无法可想，如计算语文成绩在90分以上的同学的数学成绩总和。
        除了有规律的跨行组运算外，报表中还可能会有一些随意的独立格运算，其值可能是报表中的任意几个其它格运算出来，甚至还可能会引用到报表外的数据（比如和数据库中的数据再次运算等）。由于传统工具没有很好的运算后报表数据项命名机制（传统工具只能用列名命名设计的数据单元），很难精确描述数据引用关系，只能写出规律性很强的表达式，但随意的独立格运算会就使传统工具无法处理，而报表外的数据引用更是只能借助脚本或外围应用程序，导致代码极为混乱。
        下面这张报表是个典型的跨行组运算报表，其中有比上期（跨行）和比去年同期（跨组）运算，这种报表在传统工具中常常又必须编程准备数据。这个报表的样式并不复杂，但这些格间运算会让传统工具非常为难。只能再次依靠程序代码，把数据事先计算好直接往报表里填。

        另外，所有以上的讨论中还贯穿了一点，即行列对称。纵方向上拥有的自动复制扩展的能力需要完全实现在横方向上。报表可以横向分组、横向分片，对于横向变化的报表可以定义跨列组运算等。
        我们知道，报表的上述复杂性常常是混合在一起的，同一张报表中很可能包含了所有的问题，这要求我们给出完整的解决方案，而不能单独分别处理。当这几种困难交织到一起时，整个问题的复杂度要远比解决几个单个问题的总和要大得多。
        由此可见，只有采用支持上述特点的报表工具，才能真正提高制表的效率。

1. 范围 本文将主要分析目前市场上主流的基于JAVA的报表工具。

2. 本文目的 本文主要对JAVA报表做一个分析对比研究 ，为J2EE项目选择报表提供参考依据。

3. 运行环境 Winxp＋jdk1.4＋ant1.62＋tomcat5＋mysql4.1.7

4. 假设与约定

 5. 主流 报表工具分析

        国内市场上可用于JAVA环境的报表工具大约有二三十种，比较活跃的也有十多种。面对这些绘乱杂陈的产品，很难仅从某一个方面就将它们都分类阐述清楚，更无法简单地分别打分评出优劣，必须分别从多个角度把各产品放在一起加以比较讨论才能对其在市场中所处地位有较深入清晰的认识。下面主要讨论支持 B/S 应用的产品，具体范围主要集中在如下 16 种产品（这里是按字母次序、排名不分先后）： actuate 、 bo 、 brio 、 cognos 、 crystalreport 、 jasperreport 、 mstr 、 stylereport 、博易智软、和勤、杰表、如意报表、润乾报表、数巨报表、用友华表、中创 inforreport 。

        这些是市场上比较活跃的产品。其它产品或应用量太少或未采用商品化的运作模式，缺乏影响力，在讨论中不再重点陈述。

5.1 产品产地

        从产地上可以简单地分作 国外产品 和 国内产品 两类，这个看起来似乎没什么意思，但其实这两类产品还是有较明显的差别，而且这样分类后在以下的讨论中也能比较方便地讲述。

        从产品名称上很容易就区分出这两个类别（上述列表中全英文名的是国外的），这里就不再重复罗列了。

        国外产品一般都价格较为昂贵（常被称作高端产品），而国内产品则普遍比较便宜，个别报价较贵的，也能被砍得很便宜；国外产品大多数都带有 BI 色彩，而国内产品则大多是纯报表产品；

        当然，也有个别特例，比如国外产品 stylereport 的报表部分就比较便宜，比国内产品润乾报表的企业版便宜许多；而国内产品博易智软与和勤都有较强烈的 BI 色彩，国外产品 crystalreport （水晶报表）的 BI 色彩则不太浓（ BO 公司有更适合于主打 BI 的产品）。

        另外，国外产品是从简单的西方报表模型抽象出来的，处理中国复杂报表的能力都较差，而且一般不会提供任何变通的手法，而国内产品中无论自创的还是抄国外的，大多数对复杂报表解决也不够好，但针对个别问题一般都会有些变通手法，因此对国内应用适应性更强一些；国外产品的历史大都很久，做工非常精细，除了模型算法不太适应国内需求外，常识性的细节都会搞得很好（如编辑器中的 UNDO 、统计图绘制的美观度等），而国内产品历史积累较短，个别厂商技术能力也较差，导致产品较粗糙和细节不完整。

5.2 实现技术及原创程度

        目前 J2EE 技术在国内的 B/S 应用开发中占主导地位，对 JAVA 的支持也是报表工具的一个重要考查指标。从这个意义上讲，报表工具可以分为 纯 JAVA 和 非纯 JAVA 两种 ，注意所有声称支持 B/S 应用的报表工具都能支持 JAVA ，所以不必再区别这一点。

        相比之下，纯 JAVA 产品具有明显的优势。产品能够与 J2EE 应用完全无缝结合以达到最高的运行效率、安装部署很轻松简单（其机制与应用本身完全一致）；同时还可充分利用 J2EE 应用服务器强大的集群平衡负载及共享管理的能力，适合支持用户数众多的大型应用系统；由于 JAVA 的跨平台能力，还能让整个应用系统轻松地从低端体系向高端体系迁移，系统容量变大时只要更换硬件、操作系统及数据库等系统部件而无需或很少需要重写软件。

        而非纯 JAVA 产品则相反，经常只能在 Windows 下运行（个别国外产品宣称支持 UNIX 但部署极为复杂，和不能用差不多）、同样的应用在不同规模下可能需要两套解决方案，或在大型应用中除了 UNIX 主服务器外还必须专门部署 Windows 作为报表服务器 , 显得体系结构非常古怪；产品也不能和 J2EE 的应用无缝结合、沟通需要沟通额外的网络协议导致运行效率较低，而且由于不能享受应用服务器的集群机制（国外产品常常有自己的集群机制但显然没有 J2EE 应用服务器搞得专业），难以支持多用户的大型应用。

        国外产品中 stylereport 是纯 JAVA 的，而常见的 crystalreport （水晶报表） , bo, brio, cognos, mstr, actuate 都不是纯 JAVA 的，开源产品 jasperreport 也是纯 JAVA 的。国内产品中润乾报表、博易智软、和勤、杰表是纯 JAVA 的，而如意报表、数巨报表、中创 InforReport 、用友华表都不是纯 JAVA 的。

        除了采用的技术外，其技术的原创程度也是个较重要的指标，它能够在某种程度上体现公司的研发能力以及产品的后续升级能力。手中不掌握原创技术的厂商无法对产品有完全的控制，其产品发展将严重受制于人，显然不适合与之长期合作。

        所有国外产品都是原创技术的，国内产品中润乾报表、中创 InforReport 、用友华表都有原创技术，可以放心长期应用；和勤是引进的技术，但应已消化吃透，也基本没大问题；但如意报表和数巨报表则是采用了第三方控件，长期合作则可能有技术风险。

5.3 绘制方案

         从绘制方案上分一般有 网格式 和 控件拖拽式 两种，前者采用和 EXCEL 类似的方案，用网格线围出报表；而后者则是用矩形框等元素拼出报表。

        国内报表对样式要求非常复杂而且严格，绘制方案是报表工具相当重要的指标，它决定了报表样式的复杂度和绘制效率，以及导出 EXCEL 的能力（这是用户很强调的功能）。

        网格式在这方面有明显的优势，能够画出样式很复杂的报表，绘制效率也比控件拖拽式高出 10 倍以上，而且导出 EXCEL 时格式上不会失真，个别产品还可以直接读入 EXCEL 画好的表以进一步提高效率。相反，控件拖拽式则显得非常笨拙，表格线需要靠矩形边框重合摆放拼接出来，常见的复杂多层表头画起来非常繁琐，数据区某些纵向合并格甚至无法绘制出来，拼出的格线还与分辨率相关，屏幕上对齐的表在打印时或在 WEB 上显示时又可能不整齐，生成 EXCEL 时经常丧失格式或导致格线太多太细而无法应用，读入 EXCEL 格式则更是完全不可能有的功能。

        国外产品中除 actuate 中提供的 spreadsheet 是采用网格式外，其它全部采用控件拖拽式（从另一侧面能反映国外产品对国内需求的不适应），开源产品 jasperreport 也采用控件拖拽式。国内产品中润乾报表、中创 InforReport 、杰表、用友华表、久其报表采用网格式，而博易智软、和勤、如意报表、数巨报表则采用控件拖拽式。

5.4 数据统计模型

        数据统计模型则是报表工具最重要的指标，它决定了报表工具的制表能力和效率，一般可分作 电子表格 和 传统工具 两类， 润乾报表 则不属于任何一类，是新一代报表模型。

        电子表格类工具完全模拟 EXCEL ，没有真正意义的数据统计模型，数据须由程序员自行编程取出并运算后写入表格中，也就是没有任何自动化处理的能力，严格意义上讲电子表格类产品并不能称作报表工具，但有时也会混在一起讨论。用友华表是电子表格类产品的优秀代表作，几年前还有个国外的 formula1 比较流行，后来被 actuate 收购后改造成 spreadsheet 后拥有了数据处理能力。

        传统工具目前还是报表市场上的主流，其基本特征是单数据源、条带式编辑与统计方案，在不编码的情况下只能完成简单地行式（分组）报表和单片交叉报表，稍有复杂的中国报表都需要另行编写代码准备数据，导致报表制作效率低下甚至不能完成。

        除上述提到的电子表格类以及润乾报表和中创 InforReport 外，其它产品，无论控件式还是网格式，都采用同样的数据统计模型，都是传统工具，处理中国报表时都会有类似困难。

        润乾报表采用了完全不同的数据统计模型，比较彻底地解决了中国复杂报表中的多源分片、不规则分组、动态格间运算和行列对称等困难问题，比传统工具的制表能力和效率有大幅度提高。

        中创 InforReport 要另类一些，从表面上看起来也是采用了自己独特的数据统计模型，比某些其它传统工具处理复杂报表时有优势，但仔细深究，其实是传统工具是另一种变形，并没有从根本上解决了上述中国报表的困难。

5.5 前端展现方案

        在浏览器中展现一般有 HTML 和 控件 两种方案，某些产品两种方案都提供。有时还可以 EXCEL 和 PDF 的方式嵌入在浏览器中展现，但不是重点，这里不作讨论。

        HTML 的优势是客户端完全无须安装程序，也不会有安全（病毒或泄密）问题，但由于 HTML 的先天不足，其交互操作和精确打印能力性要弱一些；控件则弥补了这方面的不足，但又需要下载从而带来安全问题（病毒等木马），而且只能支持 IE ，某些应用环境直接不允许安装任何控件。

        HTML 方案还可再分为 纯标准 HTML 和 支持 IE 的 DHTML 两种，前者可以展现在任何浏览器上（ IE 和 Netscape ，这样客户端可以是 Linux ），后者则只能在 IE 上工作。

        统计图的展示也是个需要关注的环节，一般可分为 纯 HTML 图片 和 控件 两种形式，有些工具虽然可以提供 HTML 的报表展现，但统计图部分却只能采用控件，这里需要特别关注的。 HTML 图片方式应用非常简单，但交互能力略差，控件则反之，交互能力强些但有下载等安全类问题。

        另外，打印是个非常重要的展现环节，一般会有 HTML 打印 、 控件打印 、 JavaApplet 打印 和 生成 EXCEL/PDF 打印 几种方式。 HTML 打印不够精确，一般用于信息输出是可以，但很难用作正式格式的文件；控件和 JavaApplet 都能够实现精确打印，与控件相比， JavaApplet 从协议上没有安全问题，但又不能一次下载，若不大还可接受，否则也很不方便；生成 EXCEL/PDF 再打印能保证精确度，但要求客户端事先安装好相应程序，解决方案也不一致，有时也不是很方便。

        所有的纯 JAVA 产品（无论国内国外的）都提供 HTML 报表展现、 HTML 图片的统计图方案和 JavaApplet 打印机制；国外产品中除 stylereport （纯 JAVA 的）都能提供 HTML 和控件两种形式展现和打印形式，但几乎全是仅支持 IE 的 DHTML ，某些产品（如 bo ）的统计图还只能以控件形式提供；国内产品中，如意报表、数据报表可提供仅支持 IE 的 DHTML 和控件两种，但 DHTML 实际上很少用，用友华表和中创 inforreport 只提供控件。

5.6 后台集成方案

        后台集成方案主要有 完全嵌入 、 独立服务器 和 控件数据服务 三种。

        完全嵌入指报表运算服务不单独存在、而与用户应用程序结合成一体，主程序对报表服务的无缝调用，这样可以达到最高的运行效率和最深入的控制，同时可以享受应用系统的集群部署与数据连接共享能力以及不必专门处理权限门户的事务，是最经济高效的集成方案，但必须是报表工具与应用程序基于同种技术实现才可以做到。

        独立服务器指报表运算在物理上独立存在（有时甚至会是一台专门的机器），用户应用程序通过网络协议调用报表服务，效率受到影响且控制力度不深，并且不能共享应用系统的集群和负载平衡能力，还迫使应用程序必须采用报表服务器的门户权限机制，导致多余的工作量。独立服务器的优点在于对宿主应用程序的技术体系没有要求，采用不同技术的应用可以同样的方案集成起来。

        控件数据服务则专指以控件作为前端方案的产品在后台的集成方案，运算接口都在前端的控件中，需要把复杂的程序写到页面的 JavaScript 中；后台则几乎没有运算，只是将数据取出送给前端，程序简单可完全嵌入但并没什么接口，这种方式无法发挥后台服务器的强大计算能力，而且有关处理代码将在前端暴露出来造成安全隐患，不适合大型应用。

        除了报表运算本身的集成外，还要考查有生成的统计图（及 EXCEL/PDF ）等二进制数据的引用方案，一般有 数据流服务 和 临时文件 两种。前者是将这类运算在后台组织成一个服务（在 J2EE 中是 servlet ），将结果以数据流（如 JPG 图像流）的形式返回给前端显示或下载，后台服务器上并不会真地产生一个文件；而后者则会将统计图（或 EXCEL/PDF ）物理地在后台服务器中产生成一个临时文件，浏览器上的图片或下载链接指向该文件，采用最传统的 http 机制完成图片显示和下载文件。

        相比之下临时文件方案有明显的劣势，必须操作系统放开对硬盘某处的写权限（这在某些系统下可能导致是严重的安全问题），创建临时文件会占用硬盘空间而且降低访问速度，而且这些文件的命名（不得重名）及删除都需要较复杂的管理（有些产品只会创建而不会自动删除）。

        纯 JAVA 的产品在 J2EE 机制下理论上都可提供出完全嵌入的方案，但 stylereport 、博易智软、和勤等产品仍以独立服务器方式提供，润乾报表和开源的 jasperreport 均提供完全嵌入的方案；而在非 J2EE 机制下，这些 JAVA 产品都只能以独立服务器方式存在。除 stylereport 外，其它国外产品在任何环境下都仅提供独立服务器方式。国内以控件为展现方式的产品均只有控件数据服务方式，如数巨报表、如意报表、用友华表。

        纯 JAVA 产品均可提供数据流服务来引用二进制数据，而非 JAVA 的独立服务器产品（都是国外产品）大多采用古老的临时文件方案提供这项服务。

5.7 BI 色彩

        事实上，有许多作为报表工具销售的产品其实是 OLAP 前端工具，并非纯正的报表工具。这些产品虽多少有些报表的功能，但处理得很不专业，处理复杂的中国报表固然差得很远，就算是简单的西方报表也在细节处理上大不如人意，其绘制方案、集成方案、展现方案等都很不适合国内报表的需求。但由于国内市场上 OLAP 的应用面尚比较狭小，这些产品凭借自己在 BI 领域的声望也来抢夺客户。

        国外产品中 crystalreport 和 stylereport 是主要为报表服务的，其它产品如 bo 、 brio 、 cognos 、 mstr 、 actuate 则都是 BI 类产品。 actuate 的 spreadsheet 可算作报表工具， cognos 最近推出的 reportnet 也加强了报表的能力。国内产品中博易智软与和勤都是 BI 类的产品，其它如润乾报表、杰表、如意报表、数巨报表等都是纯正的报表工具。

5.8 填报能力

        填报是国内报表应用中非常关注的能力，有时甚至是必不可少的关键功能。但绝大多数报表工具完全没有填报的能力。所有国外产品、有 BI 色彩的产品、采用传统数据统计模型、控件式编辑的产品一律没有填报功能，生成的报表只能显示，不能填写。支持填报的产品非常少，常见的有润乾报表、用友华表、武汉新连线、久其报表几家，而用友华表由于没有数据模型，表格可以填写，但需要大量编程才能完成数据入库的工作；久其报表和武汉新连线的数据模型过于死板简单，只能填出固定的数据结构，对于复杂的入库要求依然需要编码完成。润乾报表的填报方案则相对完整。

5.9 开源产品的优点与缺点

        开源的JAVA报表工具，象JASPER、BIRT等。

优点如下：

        优点之一：免费

        优点之二：JAVA报表共同的优点

        优点之三：有源代码，自己可以随心所欲

开源报表工具缺点也很明显：

        缺点之一：功能有限。这些开源工具普遍功能弱于哪怕是很初级的JAVA报表产品（道理很简单，否则人家也不会拿出来卖）。

        缺点之二：没有支持。虽然有社区、资料，但这和厂商的支持是根本没法比的。大家都是爱好者，谁对谁的支持都靠不住。

        缺点之三：学习、使用成本高。虽然不用花钱，但要投入大量的学习成本，这还可以算是一次性的。更重要的是，如果使用起来，由于其功能的不足和存在的缺陷，要在报表的设计、部署等方面持续花大量的时间，这种使用成本，除非只是做极少量的报表，否则根本没省下钱来。

        价值评估：开源报表工具，对于学习应该说是非常有用的。但是如果作为商业应用，需要根据项目综合考虑。

5.10 价格与商业模式

        大多数报表工具都是以收取 授权使用 费用形式销售的，即应用部署一次即收取一次费用。产品的价格大体可分成 高端 和 低端 两类。

        高端产品一般会按服务器 CPU 或用户数 (name user ，不是并发用户 ) 计费，其价格很不透明，很难给出明确价位，一般在几万元至十几万元之间，以前还有高达几十万上百万的销售记录，但近期由于竞争的激烈已经比较少了，有时附加上 BI 功能后仍可能卖得很高；低端产品一般在几千元（ 3000-6000 ）左右，一般只按装机量计费。

        所有国外产品和有 BI 色彩的产品都可以算是高端产品，国产的润乾报表（除普及版）也是高端产品；如意报表和数巨报表、杰表和润乾报表普及版则属于低端产品。有些产品的产品线较长，在询价时要确定地知道需要的版本和组件，否则差距可能非常大，如 crystalreport 的单机版只有几千元、而企业版（全面支持 WEB 功能）很可能要十几万甚至更多， stylereport 的报表部分只有两三万元、但加上部分 BI 能力了就会高达十几万元，润乾报表的普及版报价只有 3000 元、但企业版则要 25 万元， … 。

        还有的产品是以 开发工具 方式销售的，即用户一次购买后就可以无限重复使用，对于有较多次重复应用开发的开发商而言显然是最便宜的方式。活跃产品中目前只有用友华表采用这种商业模式，还有个国产报表 finereport 也采用这种方式，但很少有应用。

        除了作为独立产品销售的，而在国内市场上还有一类报表产品是以项目服务形式提供的，比较著名的有广州菲奈特的 BI.Office 和久其报表，不知是产品化程度不够还是对这种商业模式偏号，这些产品一向很少由第三方开方商采用，而都是由自己直接承接相关项目，把产品在项目中应用起来，近一两年内菲奈特的产品才开始有些第三方采用，但仍不多。这些产品在业界的名声尚可，在终端客户的投标中很可能碰到，但在开发商选型时却几乎从不出现。

5.11 总结

        根据以上分析，在不同的项目中采用的方案会有很大的不同。在商业产品中，润乾报表比较适合国内的情况，更适合做中国式的报表，性价比教高。在开源产品中，jasperreport属于做的比较好的，网上也能找到一些资料，但开源产品没有正在商业化，存在各种问题，用用在真正项目中需要做很多改进，在项目中可能会花费很多时间。

        企业经过多年的信息化建设，积累了大量的数据，很多企业这时就开始开展单个系统或者部门级的商业智能的应用，比如在ERP之上实现统计报表和分析。但是如此以来，很多有价值的信息隐藏在企业的应用系统、数据集市、或者电子表格中，很难获得真正的整体信息。

        在过去的十年里，商业智能（BI）技术从各种形形色色的信息源中获得知识，但是这些应用大部分是部门级或者基于项目的应用，没有企业级的整体应用或者企业战略应用，其结果是企业没有自己的统一平台和工具、产品交叉、应用雷同，分析的结果还不一致。

        为什么会出现商业智能的支离破碎的应用呢？主要来自两方面的原因:一是商业智能经常被附加到其他的应用中，比如企业资源规划（ERP）项目、客户关系管理(CRM)项目等。每个这样的系统都希望有一些报表，但是这样就会产生一些信息“烟囱”，这些信息不可能被其他部门、其他应用来分享，这就使得跨部门的分析非常困难。

        商业智能支离破碎的第二个原因是:商业智能应用概念的混乱和应用的不同。例如你的用户需要典型的报表、即席查询、分析、仪表盘和数据挖掘。在过去，可能有很多的不同工具来实现这些应用。很多工具重复购买，不同部门的工具有不同的人在维护，成本高，维护不方便，应用还有很多的问题。

        作为IT的管理人员，为了增加企业的业务价值和统一的试图，应该将注意力投入到商业智能的标准架构，建立跨部门的商业智能应用方面来,建立商业智能的标准化，这样可以节约成本、充分利用资源、建立统一的平台和架构，容易维护、统一培训，统一界面,从而提交深层次的商务分析和决策。

        Gartner建议:在你的公司中，马上启动一个商业智能工具标准化的项目，立刻整合那些非标准的工具。这样可能需要几年的时间可以达到预期的利益。但是，如果为了在三年之内就完成战略部署，确保投入产出，现在就开始实施商业智能标准化的项目吧。

        没有商业智能标准化，随着商业智能需求的增加，整个商业智能布局的增加，成本也会越来越大。

商业智能标准化定义

        有时我们发现“商业智能标准化”会得到一个负面的作用。因为人们会认为要做商业智能仅仅选择一家的软件就可以了，或者将原有的业务部门已经熟悉的工具或者界面换掉，仅仅使用统一的平台，我们这里强调的不是这样的意思。

        按照Forrester的统计，全球2000家大公司中，每家大约有5到15个分离的报表和分析解决方案在使用。商业智能标准化的目标就是尽量减少这些工具的数量和重复购买，建立一个尽量少的重叠产品组合。在图1中，可以看到将5个有重叠的产品合并成为3个独立的标准产品。

        和我们合作的大多数企业已经增加了标准化的水平,他们在使用商业智能技术时，已经越来越成熟。不管你今天在什么程度的标准上，只要你将商业智能标准化提高一个层次，你就可以节省开支、提高企业分析的能力。

商业智能标准化的益处

节约成本

        首先，在实施商业智能项目时，商业智能标准化最明显、最清楚的益处就是省钱。你可以避免不必要的重复评估、购买、布局、实施和维护多个商业智能系统。

        评估成本:商业智能解决方案的选择，从最初的各个产品供应商的对比，到最后的概念证明验证需要花费很长的时间和成本，整个过程需要几周，甚至几个月，而且评估需要设计到IT部门和业务应用部门。按照当前商业智能布局情况，在很多情况下，都有很多不同层次、不同部门不必要的重复。

        购买成本:在企业中不同部门、不同项目中，商业智能需求越来越多，首席信息官已经开始认识到需要一个企业级的平台，而不是每个项目的独立购买。

        维护成本:随着各种不同商业智能产品拼凑成的方案，不但使得购买成本增加，而且由于产品和技术的复杂性，使得学习的成本、产品管理的成本、各种技术整合的成本大大增加。

        培训成本:依赖于用户的需求，很多技术人员或者用户需要培训几个不同商业智能工具。在一些情况下，由于使用各种不同的商业智能工具，信息来自于各种不同的离散系统，这样用户不得不依赖于IT人员来解决数据的整合、架构的设计、做出很多没有必要的工作。

        在企业中已经使用了很多不同商业智能的产品，你能将商业智能标准化，你的企业就可以节约更多的成本。Gartner估计:拒绝整合商业智能工具的公司是不可能战略性布局商业智能的，对于每个多余的工具，将需要项目50%以上的成本（这样情况出现的概率是80%）。

增加用户的满意度，实现深度的业务洞察力

        企业已经在信息化建设上花费了数百万美金，然而从这些信息中获得价值就需要访问这些数据，并且从数据中获得信息，从信息中获得知识，从知识中获得决策，从决策中获得行动，从行动中获得效益，这就意味着商业智能系统的价值所在。

        商业智能是在企业IT架构中最重要、最容易出效益的系统。用户经常认为他们的服务器和运营系统在正常地运行,但是企业的领导、决策者、分析师、业务人员和外部的用户想了解企业的整体状况确实很困难的。业务运营系统很难帮助企业提升自己的绩效，只有用好商业智能才能给企业快速带来真正的效益。

        另一方面，用户不能获得他们希望获得的信息或者快速地收集需要的决策依据，这给决策带来延误或者获得了错误的信息，这时他们就会责备IT部门。

        作为一个IT部门的决策者，其角色就是为你的内部客户和外部客户提供快速的、容易的、整体一致的访问业务信息的工具和应用。商业智能为决策者获得所有软件投入中最大的投入产出。2002年IDC的研究报告表明商业智能项目在仅仅一年多的时间就会获得高于430%的投入产出比。IDC还表明商业智能的最大益处就是业务流程优化了，使用商业智能揭示出来的信息改变了业务工作的方法。

        事实上，在现在竞争非常激烈的时代，非常清楚的是具有更多信息的公司将更具有竞争优势。亚里士多德认为，传说中的商人和希腊船运的亿万富翁成功的秘密是:“商务成功的秘密是知道一些其他人不知道的东西”。

        所以商业智能标准化看起来是关于节省成本的，其实质是商业智能标准化可以为企业带来更快、更好、更准确的信息。商业智能标准化其结果在于通过发现问题和新的收入机会，对企业产生指数级的绩效增长。
更大的控制，降低风险

        商业智能标准化的第三个益处就是在信息和信息利用方面有更多控制，特别是在企业布局了跨系统的统一商业智能标准，可以帮助孤立的业务用户获得全面的信息。

         今天的企业是有很多不同业务应用、通过合并、收购、或者很多不同的业务单元组成的。很多企业的各种已有系统是相互分离的、新系统建设是离散的、部门级也有很多的应用。

        如果你的用户利用各种不同的商业智能工具在访问不同的系统时，他们将不可避免出现信息孤岛、信息无法共享、维护困难、使用不便等的问题。如果实现了商业智能标准化，用户就很容易的获得整体的信息架构，看到统一的报表和企业绩效仪表盘。

        由于萨班斯-奥克斯利法案 、其他一些法律准则和审计的要求，使得数据的质量、安全、保密、准确性等提到了议事日程，商业智能项目的成功为企业的安全性提供了保障。

        如果没有统一的商业智能架构，就会出现多个不同的统计和分析结果。例如:“某个产品为公司的贡献度是多少”可能会得到很多不同的版本，它依赖于贡献的定义和数据的准确性。用户很难在一个协同的环境下进行沟通和交流，由于他们的工具不同、术语不同，甚至概念不同。

        商业智能标准化提供一个统一平台、统一管理，通过元数据管理，更多的实现信息的控制，实现信息的透明、存储、比较和协同。有了标准的系统，可以利用元数据很容易跟踪影响分析，也就是当运营系统的一个数据发生变化时，它会影响到统计分析、决策部门、应用部门的那些报表发生了变化，那些指标发生了变化。

        也可以利用元数据管理实现在应用的报表中某项指标是如何计算出来，公式是什么、都使用了那些数据，这些数据来自那些系统，从而给决策者，特别是增强了财务总监在签字时的信心，他们可以透明的获得信息的来源，从而保证了签字正确性和信息的准确性，减低了他们的风险。

        商业智能标准化也可以帮助企业减少对老的商业智能工具的以来和对厂商的依赖。由于行业越来越成熟，那些实施了标准化的商业智能厂商，他们的产品将更值得信赖的，企业和他们建立长期的合作也会实现双赢。

        正像Gartner指出的:在大多数的公司，片段的和离散的商业智能工具的使用在过去的两年中更加严重了。

         面对着商业智能片段和离散的问题，企业已经加大了标准化的步伐。在TDWI（数据仓库学会）的研究报告中指出32%的企业表明在将来的12个月到24个月中开始商业智能标准化项目的实施。

        商业智能标准化涉及到成本的降低、管理水平的提升,但是美国专业研究机构AMR研究报告指出:商业智能标准化工具正在建立公司长期战略的运动。

        BI应用到今天，有两大发展趋势：一方面向纵深发展，前端展现和表示不再成为惟一的焦点;另一方面则向横向扩展，BI应用不仅辅助企业高层进行战略决策，而且还延伸到企业的“神经末梢”，就连最为基层的公司员工也可以利用BI来完成日常工作。

　　纵向深入应用

　　BI自进入国内，一开始就被当作企业高层决策的有力工具而受到垂青。不过，企业决策者并不直接使用BI工具。从不同的数据源收集数据，经过抽取 (Extract)、转换(Transform)和加载(Load)，送入到数据仓库或数据集市，然后使用合适的查询与分析工具、数据挖掘工具和联机分析处理工具对信息进行处理，将信息转变成辅助决策的报表、仪表盘等信息，并最后将它们呈现于企业决策者面前，这是企业专业业务分析人员利用BI工具的过程，企业决策者看到的只是报表、仪表盘等直观的信息，也就是最终结果。

　　完整的BI有四大技术，即 ETL(数据的提取、转换与加载)技术和数据仓库与数据集市技术、OLAP技术、数据挖掘技术、前端展现与表示技术，但企业决策者看到的最终结果是前端展现与表示技术呈现出来的东西。由于老板看到的是最终结果，这就很容易导致BI提供商和服务商们产生一种“老板关心的是结果而不是过程”心理，所以，截至目前，市场上前端展现与表示工具之类的产品仍然占据大多数。

　　结果很重要，但是这并不意味着过程不重要。没有一个良好的过程，很难保证有一个良好的结果。“国内的BI厂商主要力量在于报表和仪表盘等前端展现和表示工具，但如果抱着这个不放的话，势必就会走进死胡同”，随着企业数据环境的复杂化，用户对BI产品的要求也随之提高，他们对于前端展现和表示工具的需求已经到了尽头，要求进行更深入的应用。只有真正融合了数据仓库、数据挖掘等深度技术的BI产品，才能获得用户新的青睐。

　　这也能解释2007年BI领域发生三大并购案的原因：被收购方在数据仓库、数据挖掘方面的力量都不强，而收购方都是ERP方面的强手，收购之前，他们从ERP的角度上已经获得了较高的数据仓库、数据挖掘能力，正好可以互为补充。

　　因此，从前端展现和表示工具逐渐纵深，加强数据仓库、数据挖掘的能力是国内BI努力的方向。
横向扩展范围

　　BI通常被理解为将企业中现有的数据转化为知识，帮助企业做出明智决策的软件解决方案。BI的出现，使管理决策者有了真实可靠而又及时的依据来进行战略调整和业务决策，而不是像过去那样只能依靠经验或者过时的信息。这对于在适应瞬息万变的市场环境中求生存、求发展的现代企业来说意义重大。

　　然而，正是因为BI与决策的紧密相关，使得BI的应用走到了一个狭窄的小胡同中——BI在企业中的应用局限于为企业经营决策者提供最终的报表上，只有企业的“大脑”才能享受BI带来的成果。

　　说起决策，似乎只是关键人物，如企业高层、政府领导等要做的事情，但其实，任何人在生活和工作中都面临决策问题，简单的一件小事都需要我们根据经验或是环境等信息来进行判断，尽管这种过程可能很短。

　　而在一个企业中，决策是多层面的，不仅企业高层、中层管理者，而且连基层管理人员和一般职员都需要就自己职责范围内的事情进行决策。但是，除了企业高层，人们在做决策的同时通常没有意识到这是一种决策行为。

　　那么，人们通常都是怎么来进行决策的呢?有个小例子可以很好地展现这一过程。

　　比如，孙悟空与二郎神要打架了，有朋友和你打赌谁会赢。由于你记得这两人在各种场合打斗过15次，其中孙悟空赢10次。另外，孙悟空斗牛魔王，8战6胜，而二郎神斗牛魔王，8战3胜。于是你根据这些简单的信息赌孙悟空极有可能赢。

　　但如果怕赌输了，你就干脆什么都不做，让计算机来分析，自动找到了出身、教育、经验、单身四个因素，计算机通过分析发现贫苦出身的孩子一般比皇亲国戚功夫练得刻苦;打架经验丰富的人因为擅长利用环境而机会更多;在都遇得到明师的情况下，贫苦出身的孩子功夫可能会高些;单身的人功夫总比同样环境非单身的高。孙悟空遇到的名师不亚于二郎神，而打架经验绝对丰富，并且单身，所以这次打架，你的赌注是孙悟空赢。

　　第一个场景显示了人们在做小事情的决策方法：凭记忆，甚至凭感觉，而后一场景则是利用了BI的数据挖掘技术，使得决策的依据更加可靠。

转自：中国商业智能网

        所谓报表工具，最核心最本质的功能，就是它的制表能力，即是否能够不写代码而制作出自己需要的各种报表。但用户在考察报表工具时往往很注重打印输出、绘制方案、管理调度等外围因素，而忽视了报表工具最本质的制表能力。当然不可否认这些外围的功能对一个报表工具来说也是很重要的衡量标准，但是报表工具的主要用途是制作报表。目前市场上的主流产品能够处理处理复杂报表的只有FineReport（http://www.finereport.com）和润乾报表(http://www.runqian.com.cn)。
        通过对这两个产品的研究，我们认为，报表工具对复杂报表的处理能力应该体现在如下几个方面：
首先是多源分片。
        传统的报表工具只支持单源报表，即使是数据来自于多个物理数据表或者物理数据库，也需要在报表设计前将多源通过写SQL，存储过程等转化成单源处理。
        多源往往带来分片，正是由于分片，使得报表设计必须直接基于多源进行，而不能先将多源转成单源进行。有相当一部分分片报表无论如何也不可能换成单源处理，部分能转成单源的报表处理也非常繁琐。
其次，是不规则划分机制。
         传统的分组是完全规则划分的，即划分标准一致且有规则（一般都按某个字段或表达式），所有字段都必须出现且只出现一次，分组值次序与原数据记录次序一致。
但是与完全划分相对应的，在报表汇总中却常常需要不规则划分，即划分标准看不出规律（常常只能穷举），所有事实不一定全部出现在分组结果中、个别事实还可能重复出现，次序也与原数据记录无关。
然后，还有动态格间运算的能力。
        所有的报表工具都会提供一些计算列的功能，在原始数据基础上再计算出一些别的列值或统计值，这是报表展现中是不可缺少的功能。
        一般的报表工具一般只提供同行内的格间运算和针对某组（或全体）的集合运算，对于常见的比如累计，取第一名等跨行组运算则相当困难。
         除了有规律的跨行组运算外，报表中还可能会有一些随意的独立格运算，其值可能是报表中的任意几个其它格运算出来，甚至还可能会引用到报表外的数据（比如和数据库中的数据再次运算等）。所以运算后报表数据项命名机制就很重要，传统工具只能用列名命名设计阶段的数据单元，随意的独立格运算会就使传统工具无法处理，而报表外的数据引用更是只能借助脚本或外围应用程序，导致代码极为混乱。
        另外，所有以上的讨论中还贯穿了一点，即行列对称。纵方向上拥有的自动复制扩展的能力需要完全实现在横方向上。报表可以横向分组、横向分片，对于横向变列的报表可以定义跨列组运算等。
        上面我们提到目前市场上的主流产品能够处理处理复杂报表的只有FineReport（http://www.finereport.com）和润乾 (http://www.runqian.com)。其它的产品都没有这种无编码处理复杂报表的能力。

选自：51CTO

        对于许多从未接触过报表工具的非程序人员而言，EXCEL的功能已相当强大，编制报表并不麻烦，为什么还需要别的报表工具呢？这些报表工具与EXCEL有什么差别和关系？
        EXCEL和报表工具是两个不同方向的产品，相互之间不能替代。相对于报表工具，EXCEL的不足之处主要有两点：
        一是在自动计算报表方面。EXCEL能够绘制出非常复杂多样的报表，也可以在表内定义复杂的数据关系，但原始数据及表的样式都只能是确定的，每张报表都需要临时手工制作，而不能根据业务系统数 据库中的数据自动计算出相应的统计报表；报表工具则可以制作出体现数据与报表之间规律的报表模板，在应用时只要输入参数即可根据当前数据库中的数据实时自 动计算出报表。
         二是在程序集成方面，EXCEL是面向终端业务人员的产品，本身未提供丰富的程序集成接口，特别是面向B/S应用时更为麻烦。而现实中我们需要的许多报表都需要集成在业务系统中展现；报表工具则通常面向程序人员，有丰富的程序接口供调用，可以将报表集成展现在业务系统中。
        报表工具在处理报表有上述优势，但作为专业的报表软件来说，对应用人员要求也相对较高，业务人员很难直接使用，而且大多数报表工具在表样处理上远不如EXCEL方便，故而也不能取代EXCEL，两种产品会在较长时期内相辅相成。
         一个好的报表工具应当在展现方面与EXCEL尽量兼容，不仅应能够将计算出的报表不失真地导出成EXCEL的格式以方便业务人员进行后期处理，而且最好还能够读取EXCEL的表样以充分利用业务人员在EXCEL上的丰富积累。国内出现的润乾、快逸等基本上可以满足。

商业智能应用同用户的业务和流程越来越紧密相关，企业中使用商业智能的对象不再只是高级管理人员，而是包括了企业中各个级别的管理人员和业务人员。“随着商业智能应用的进一步深入，操作型商业智能应用将是未来的发展趋势。”惠普软件部商业智能(BI)部门总经理Ben Barnes说，操作型商业智能更关注于管理，并优化企业日常的业务运行，将正确的信息在正确的时间推送给正确的业务人员，然后快速响应，以便能够帮助用户解决商业问题与满足新的业务需求。

　　实时性决定决策价值

　　要满足用户的日常管理和决策，操作型商业智能的实时性要求就成为必然。对于实时性的重要性，Ben Barnes以日常的大型商业活动中的采购应用举例说，在一张图上设两个轴，横轴代表时间，纵轴代表采取决策带来的价值。在某一刻，有一个客户想要购买的商品断货，若我们在较短的时间内迅速做出反应，企业的减损就相对较少; 反之，我们用来决策的时间越长，它所对应的价值就越低。

　　简而言之，就是随着决策时间的延长，企业的利润及客户满意度都在不断地减少，所以，在正确的时间、用正确的数据做出正确的决策，有效地调取企业的数据信息对于确保公司的正常运营以及公司利润的增长至关重要。

　　由于实时的运营决策对企业运营非常重要，并且这些普通的用户对商业智能系统提供服务的实时性要求越来越高，越来越多的企业将决策流程与实时信息进行了更紧密的连接。

　　统一数据仓库与报表

　　要满足操作型商业智能中实时性应用的需求，公司需要从更多的数据源中加载更多的数据，并对其进行更加频繁的更新。对一般商业智能应用而言，它包括三大组成部分: 数据转换操作(ETL)、数据仓库、决策信息的提供和展示，数据仓库仍是其中最重要的部分之一。在加载数据仓库时，要支持实时的数据加载、更新和抽取，并可以在数据库保持联机时，同时操作多个表，因为停止用户访问数据库将造成不可估量的损失。

　　对数据仓库，需要将更多的数据集市进行统一集成。具体就是利用虚拟化和无共享大型并行数据库技术，通过大量商业化组件将众多数据集市转换为只有一个数据库实例的单一企业数据仓库平台。对于这样的架构，在存储海量数据的同时，可以提高访问数据仓库和在数据仓库内查询的速度。“ 而要完成这样的任务需要一个整合了硬件、软件平台的整体解决方案。”Ben Barnes说，惠普的Neoview就是能够提供完整解决方案的平台，能够支持100倍于Teradata的数据，并且能够为1024个处理器服务。

　　Neoview在亚洲的一个运营商应用中，就整合了运营商之前所用的三个系统，并且和呼叫中心的一些相关业务整合，整体数据仓库有720亿条呼叫数据，后来又增加32亿条新数据。如果使用之前的系统来录入、上载的话，需要9个多小时; 而用操作型的解决方案，时间大约只是两个半小时，利用这样的平台可以大大减少决策报表时间。

　　同时，数据仓库等的运营和监控要求能够进行实时运营的决策，必须保证7×24小时全天候可以随时应用，进行实时的运营决策支持。

　　在报表方面，公司必须能够为更多的不同类型的用户提供支持，这些用户需要更加快捷地获取信息，他们的问题可能更加难以预测，需要随时随地得到问题的答案。所以，要求下一代操作型商业智能允许企业做出迅速反应，最好使用单一报表事件。比如，公司的某个高层想要了解企业创造的业务利润、合作的供应商等信息，这些信息都能够整合在同一个单一的事件当中来呈现，从呼叫中心到客户服务、再到供应商，三者能够整合为一个统一单一的视图来呈现，从而建立起企业与客户及合作伙伴快捷高效的合作关系。

转自：商业智能网