java报表工具比较
这几年Java报表市场很是热闹了一阵，先是水晶报表、Brio、Style等海外产品相继杀入市场，而后是国内的华表、中创、数巨、和勤、润乾、杰表等揭竿而起（这中间有的是仅支持Java的，有的是支持所有WEB环境的），一时间狼烟四起，概念战、眼球战、价格战，好一番厮杀。
到如今尘埃落定，天下三分——
水晶报表、Brio分别归入BO和Hyperion门下，倚仗BO和Hyperion在BI领域的高墙深壑，坚守最后一块底盘；
Style Report、数巨报表、和勤报表以智能分析型报表为依托，虎踞市场腹地，并昼夜厉兵秣马，加强BI产品功能，期待有朝一日可白衣渡江，在BO和Hyperion眼皮下虎口夺食；
华表、中创、润乾、杰表等单一展现型报表，大多已是风流总被雨打风吹去，目前唯余润乾与杰表尚在厮杀，但前有Style、数巨、和勤等分析型报表打压，后有JasperReports、Eclipse BIRT等开源产品侵扰，虽不至于势若危卵，但总不是那么轻松写意。
市场三分，究其根源，在于产品。功能和性能——软件永恒的话题，最终决定产品、企业未来发展的原动力。那么，本文就来分析一下各Web报表的功能与性能。
分析对象： Style Report、 水晶报表、 数巨报表、 润乾报表
分析方法：抽取各个产品演示样例及说明文档中，最具有代表性的报表，将这些报表使用其他产品进行设计，以比较功能、性能优势。
报表1：
样例提供者：Style Report
各产品得分（满分10分）：
Style Report：10
水晶报表：7
数巨报表：10
润乾报表：10
评分依据：
这张报表其实在设计上，并没有什么特殊的要求，仅仅是繁杂。
目前的报表工具有两种设计模式：一种是带状模式，以控件在带状区域的摆放为设计方法，以灵活性和扩展性为主要设计优势，缺点在于绘制复杂表格时需要消耗一定的工时，上表就是一个典型的例子。另一种为表格模型，类似Excel，以简化表格设计复杂度为主要优势，在绘制表格时比较方便，缺点在于灵活性及扩展性不及带状模型。
上表的两个特征：静态表格结构繁杂、以常规方式显示数据，故而最适合的是采用表格式而非带状模式。
在四个报表中，Style Report采用表格模式，水晶报表采用带状模型，数巨报表可同时支持表格模型和带状模型，润乾报表采用表格模型。故而给予Style Report、数巨报表、润乾报表均为10分，而水晶报表虽然采用带状模型，但通过一定的工作量可以完成上表设计，并且提供了多种快捷方式以优化设计过程，故而给予7分。
报表2：
样例提供者：Style Report
各产品得分（满分10分）：
Style Report：10
水晶报表：8
数巨报表：10
润乾报表：10
评分依据：
这张报表是一个交叉表，左侧的“钢类”、“序号”，根据数据源返回数据自动向下扩展；上表头的“钢锭”等字样，根据据数据源返回数据自动向右扩展。从这个角度说，这张报表不算复杂。
稍微有些复杂的第二列“序号”和第三列“合计”。显然，序号是不可能作为一个字段在数据源中出现的，而合计按照标准交叉表设计模式惯例，是放置在最后一列的。这就需要对交叉表进行额外的处理。
一般采用的方式是分为多个设计片区进行处理。
在Style Report、数巨报表、润乾报表中，都有报表分片设计的概念，可以将一个平面表分解为多个具有逻辑关联的片区进行设计，各个片区间可以进行跨片区运算。这样上表设计起来就非常简单了。故而这三个产品在这个功能上都给予了10分。
但是在水晶报表中，只能采用多个子报表拼接的方式完成上述要求，在各个子报表拼接位置、逻辑关联方面设计起来比较麻烦，故而仅给予8分。
报表3：
样例提供者：水晶报表
各产品得分（满分10分）：
Style Report：8
水晶报表：10
数巨报表：8
润乾报表：8
评分依据：
本张报表属于多个交叉表的关联组合，设计难度略大于报表二，主要原因在于：多个交叉表的组合，不仅仅是在横向上由多组组合而成，在纵向上也是如此。
本来和报表二一样，Style Report、数巨报表、润乾报表，可以使用报表分片设计的方法，很容易解决这个问题，而水晶报表则需要使用子表拼接的发放，设计难度和复杂度高于前者。但是，在报表中，表头的格内嵌入了一个图片，将图片和文字在同一个格中进行同步显示，这是Style Report、数巨报表、润乾报表所做不到的。
故而在此项评估中，水晶报表10分，其余三个产品各8分。
报表4：
样例提供者：数巨报表
各产品得分（满分10分）：
Style Report：0
水晶报表：10
数巨报表：10
润乾报表：0
评分依据：
本报表看似普通，不过是甘特图和表格的结合而已。然而，难点就在这里：如何做到甘特图中的进度条分行与表格一一对应。
使用数巨报表和水晶报表来设计的话，甘特图的进度条是使用一个填色格控件是独立重叠摆放的，可以根据数据行数进行自动循环复制，并逐行进行报表运算，根据运算数据结果来调整当前起始位置与长度，从而达到与表中其他数据行同步的显示效果。
也就是说，要设计这样的报表，需要报表工具做到：1. 设计控件之间的属性相对独立、2. 同一控件不同衍生实例的属性相对独立、3. 控件实例在衍生过程中的属性精密可控。
Style Report和润乾报表不支持此类功能，故为为0分，水晶报表和数巨报表各10分。
报表5：
样例提供者：数巨报表
各产品得分（满分10分）：
Style Report：10
水晶报表：10
数巨报表：10
润乾报表：10
评分依据：
将某种条件下的数据，以与众不同的色彩进行展现，已经是所有成熟报表产品的基础功能。本功能所有产品均有对应功能解决。故均为10分。
报表6：
样例提供者：数巨报表
各产品得分（满分10分）：
Style Report：0
水晶报表：10
数巨报表：10
润乾报表：0
评分依据：
是很简单的一张报表，有产品大类8个，分别是数码、运动休闲、服装、计算机、家电、通讯、珠宝和食品饮料。需要用列表来显示各自销量。
设计的需求唯一特殊之处在于：出于用户对重点产品的关心，在排序上，要求“数码”和“运动休闲”两类产品分别放在第一、二行显示，“食品饮料”类产品放在最行一行显示，其他数据排序不做强制要求。
由于数据库中数据排序不固定，无论是在数据提取时按照产品大类名称还是销量进行排序，均无法保证数据显示顺序一定符合要求。
数巨报表和水晶报表均提供了对数据源数据记录的强制排序功能，可以比较便捷地解决该问题，但Style Report和润乾报表仅能简单地按照数据源顺序或逆序进行排列。故而本项评分，Style Report和润乾报表0分，数巨报表和水晶报表10分。
报表7：
样例提供者：数巨报表
各产品得分（满分10分）：
Style Report：0
水晶报表：0
数巨报表：10
润乾报表：0
评分依据：
上表是一个典型的分组报表，需要将销售订单数据按销售地区进行分组显示。特殊之处在于，由于数据量比较大，浏览者希望能象Word文档一样在报表封面上加上一个目录，并且能够在浏览的时候，鼠标点击目录，则报表自动跳转到该目录对应的内容页面。
数巨报表可为报表设计中的每一个对象，用findViewObject的方法建立运行实例，通过方法AddAnchor标记实例的当前位置，结合系统内部跳转函数，可以很方便实现上述需求。故给予10分。
其余三类产品均对此需求无能为力，故给予0分。
报表8：
样例提供者：数巨报表
各产品得分（满分10分）：
Style Report：0
水晶报表：0
数巨报表：10
润乾报表：0
评分依据：
报表要求：
1、数据筛选条件：
统计区域：<全国/北京/山东……>
文化程度：<全部/小学/初中/……>
性别：<全部/男/女>
年龄段：<全部/16岁以下/16岁~18岁/19岁~30岁/31岁~40岁/41岁~50岁/51岁~60岁/60岁以上>
2、报表创建条件：
由用户在创建报表前选择统计分行规则（选择行属性内容），行属性分类包括：审批地区/受理地/户口所在地/前往国或地区/申请原因类别/年龄段/文化程度。
难点分析：
报表的难点不在于常规的设计制作，而在于统计中行的分类方式是可变的：浏览者可以随意在年龄段、审批地区、受理地等内容上进行选择，报表按照用户选择进行分行统计。比如，用户选择“年龄段”统计，则报表中每行统计的是不同年龄段的数据；当用户选择为“受理地”时，每行统计的是不同受理地的数据。用户做出不同的选择，报表中<行属性分类>标识处的数据内容就会发生相应的变化，同时统计数据方法也会发生根本的改变。
对产品要求：
能够允许报表中某些数据的获取方法根据报表创建过程中产生的中间数据计算结果进行逻辑分析，然后根据规则向数据库请求对应的数据。
结论：
在四种产品中，只有数巨报表的“数据库动态指令”技术，能够满足上述要求，故给予10分，其余产品0分。
报表9：
样例提供者：润乾报表
各产品得分（满分10分）：
Style Report：8
水晶报表：8
数巨报表：10
润乾报表：10
评分依据：
这张报表所体现的功能需求，是当前单元格与其上下左右单元格进行跨行跨列运算的能力。这种运算不仅仅包含四则运算，还包含其他一些扩展性要求，比如本表要求的排名计算。
跨行列的四则运算，对于Style Report、水晶报表、数巨报表和润乾报表来说都不是难事，唯独在对于排名运算方面，特别是要求不仅仅对原始数据进行排名，同时还需要对多列运算结果进行排名，这种要求对于Style Report和水晶报表而言略显复杂，需要进行多步循环运算才能实现。而在数巨报表和润乾报表中，均可直接对单元格数据进行排名运算。
所以本例中，给予Style Report、水晶报表各自8分，数巨报表和润乾报表各自10分。
报表10：
样例提供者：润乾报表
各产品得分（满分10分）：
Style Report：8
水晶报表：8
数巨报表：10
润乾报表：10
评分依据：
本例报表是不规则分组交叉表，其特征表现为：
1、 同样的数据，按照不同指标要求，重复交叉运算，形成交叉报表。
2、 值区域分组，这点和常规交叉报表不同，常规交叉表都是以字段值为分组条件，而不是以字段值所在区域为条件的。比如年龄：在常规交叉表中会显示21岁、22岁、23岁……，不同的年龄是一个分组间隔。而在上表中，要求将制定段落区域的年龄作为一个分组条件。
在水晶报表中，需要通过多个子报表拼接来组合成上述样式，缺点在于子报表之间的间距、表格线对齐等等需要反复调试，比较麻烦。而Style Report、数巨报表和润乾报表，可以直接在类Excel表格中，使用多个设计区域的方式进行设计，故而在此方面水晶报表表现出它的不足。
在值区域分组方面，做得比较好的是数巨报表和润乾报表，均可以直接在单元格中通过脚本进行分组规则定义并展现。水晶报表可通过脚本进行处理，略有不足，但仍不失为一种方式。Style Report在此方面的功能比较薄弱，需要预先对数据进行区域分组处理。
在本例中，数巨报表和润乾报表均表现出完美的解决方案，故给予10分，水晶报表和Style Report在处理中各自有所不足，故给予8分。
报表11：
样例提供者：润乾报表
各产品得分（满分10分）：
Style Report：8
水晶报表：5
数巨报表：10
润乾报表：10
评分依据：
本报表难度在于同期比、比上期之类的与时间相关的运算，而这些运算往往需要用到下一行的数据除上一行数据，后一列数据除前一列数据等。
针对这种涉及到行间、列间的运算，Style Report、数巨报表和润乾报表均可直接进行单元格位移运算。而水晶报表仅能在数据源中进行预先处理，而后做数据填充。尽管最终报表得以实现，但过程复杂，对设计者技术要求高，故而水晶报表仅得5分。
尽管Style Report、数巨报表和润乾报表均支持位移运算，但如遇到多个分组行数不规则的情况，比如某一年份某季度数据缺失，导致该分组只有三行数据，则在应付这种意外事件时，Style Report无能为力，仅能通过预先的数据校验来处理，故而略显不足，给予8分。
数巨报表和润乾报表则均由单元格运算匹配模型，可以在运算中对位移单元格进行匹配校验，故而本报表样例给予满分10分。
报表12：
样例提供者：润乾报表
各产品得分（满分10分）：
Style Report：6
水晶报表：6
数巨报表：10
润乾报表：10
评分依据：
这个表是个典型的横向分片报表，数据区从左至右分成了几片，既有固定的统计数据，也有根据数据库记录扩展出来的动态数据，这种固定与变动结合的报表在实际中是非常常见的。
此外，与前面谈到的报表二、三不同，这张报表不仅仅涉及到多交叉表组合，还涉及到交叉表与列表之间的组合、交叉表与列表之间的跨列计算。
数巨报表、润乾报表，可以使用报表分片设计的方法，很容易解决这个问题，而Style Report、水晶报表则需要使用子表拼接和数据源预先处理的方法，设计难度和复杂度远远高于前者。
故而在此项评估中，Style Report、水晶报表各6分，数巨报表、润乾报表各10分。
报表13：
样例提供者：润乾报表
各产品得分（满分10分）：
Style Report：8
水晶报表：8
数巨报表：10
润乾报表：9
评分依据：
这张报表看起来简单，但它的数据实际上是放在汽车、房产、土地、其他四张表中。
这张表的做法有两种，方法之一是做一个视图，将客户名称、汽车、房产、土地、其他等数据项以外关联形式组合起来，然后以列表形式去显示。这种方法优点在于数据运算执行效率高（关联运算在服务器上执行，无疑效率要高于报表服务器执行，特别是在大数据量的情况下），缺点在于视图建立比较麻烦，另外考虑到额外情况，比如“其他”列数据在数据库表中如无直接对应，需要进行归类运算的话，则更为复杂；还有一个局限性，是如果这五张表存在不同的业务系统中（数据库不统一），这种方法将无能为力。
方法之二是单独写5个SQL，将客户名称、汽车、房产、土地、其他等数据逐一运算出来，然后在报表设计过程中以客户名称进行对应关联展现。这种方法优点在于设计过程简单，并且适应能力强，缺点在于效率上不及第一种方法。
第三种方法是单独写5个SQL，将客户名称、汽车、房产、土地、其他等数据逐一运算出来，与第二中方法不同之处，是并非将关联置于报表逻辑中完成，而是以SQL模式进行二次关联运算，这步关联运算，在报表服务器上通过报表服务器内置的SQL引擎完成。这种方法综合了上述两种方法的优点，在保证扩展性、易用性的同时，也保证了执行效率。
第一种方法四类产品都支持，第二种方法仅有数巨报表和润乾报表支持，第三种方法仅有数巨报表支持。所以，评分结果：Style Report、水晶报表各8分，数巨报表10分，润乾报表9分。
报表14：
样例提供者：数巨报表
各产品得分（满分10分）：
Style Report：8
水晶报表：0
数巨报表：10
润乾报表：0
评分依据：
联机分析（OLAP）是由关系数据库之父E.F.Codd于1993年提出的一种数据动态分析模型，它允许以一种称为多维数据集的多维结构访问来自商业数据源的经过聚合和组织整理的数据。
OLAP的作用，简单来说，是允许最终用户以自定义操作的方式，对数据进行动态的聚类分析，分析条件可以自行交叉组合，并且可对聚类数据进行逐层深入分析，直至找到数据表象的内在深层诱因。是商业智能的最核心也是最基本的功能。
目前，支持OLAP的报表我们一般称之为分析型报表，反之称之为展现型报表。由于OLAP产品对于研发的技术要求比较高，国内仅有数巨报表、和勤报表等为数不多的几家厂商具有此类功能。而润乾报表等低端产品均未能支持。
国外的Style Report支持OLAP，而水晶报表由于并入BO家族，BO另辟产品线，故而未能支持。
如果将Style Report和数巨报表进行OLAP功能对比的话，就可以发现，数巨报表在人机交互上更加具有可操作性。数巨报表支持浏览端直接使用鼠标进行维度设置，并且Cube装载运算在客户端完成，故而在表现力及运行效率上更为优越（无需反复请求服务器，并且避免了相同数据在线路中的重复传递）。此外，数巨报表允许OLAP脱机运行，用户可通过Email等方式分发OLAP当前模型，这样就带来了更为广阔的应用空间。
综合评定，该项指标，Style Report得8分，数巨报表10分，其余产品0分。
报表15：
Cube创建：原始数据1000万条记录，维数量：10；度量个数：2
评估重点：Cube创建中的运算效率及系统稳定性
各产品得分（满分10分）：
Style Report：8
水晶报表：0
数巨报表：10
润乾报表：0
评分依据：
功能满足：Style Report和数巨报表均具有独立的OLAP Server，水晶报表和润乾不支持OLAP。故而水晶报表和润乾报表为0分。
系统稳定：运行过程中，Style Report和数巨报表均未产生错误。
Cube生成周期：Style Report：97分42秒 数巨报表：61分01秒
系统占用内存峰值：Style Report：711MB 数巨报表：838MB
结论：Cube生成周期，Style Report所需时间，超过数巨报表50%以上，说明数巨报表在Cube算法上优于Style Report。但在内存消耗上，数巨报表高于Style Report接近20%，说明在对资源消耗上，Style Report具有优势。考虑到在实际商务应用中，效率更为关键，故而本环节，给予数巨报表10分，Style Report 8分。
总分合计
Style Report 92分
水晶报表 90分
数巨报表 148分
润乾报表 87分
到如今尘埃落定，天下三分——
水晶报表、Brio分别归入BO和Hyperion门下，倚仗BO和Hyperion在BI领域的高墙深壑，坚守最后一块底盘；
Style Report、数巨报表、和勤报表以智能分析型报表为依托，虎踞市场腹地，并昼夜厉兵秣马，加强BI产品功能，期待有朝一日可白衣渡江，在BO和Hyperion眼皮下虎口夺食；
华表、中创、润乾、杰表等单一展现型报表，大多已是风流总被雨打风吹去，目前唯余润乾与杰表尚在厮杀，但前有Style、数巨、和勤等分析型报表打压，后有JasperReports、Eclipse BIRT等开源产品侵扰，虽不至于势若危卵，但总不是那么轻松写意。
市场三分，究其根源，在于产品。功能和性能——软件永恒的话题，最终决定产品、企业未来发展的原动力。那么，本文就来分析一下各Web报表的功能与性能。
分析对象： Style Report、 水晶报表、 数巨报表、 润乾报表
分析方法：抽取各个产品演示样例及说明文档中，最具有代表性的报表，将这些报表使用其他产品进行设计，以比较功能、性能优势。
报表1：
样例提供者：Style Report
各产品得分（满分10分）：
Style Report：10
水晶报表：7
数巨报表：10
润乾报表：10
评分依据：
这张报表其实在设计上，并没有什么特殊的要求，仅仅是繁杂。
目前的报表工具有两种设计模式：一种是带状模式，以控件在带状区域的摆放为设计方法，以灵活性和扩展性为主要设计优势，缺点在于绘制复杂表格时需要消耗一定的工时，上表就是一个典型的例子。另一种为表格模型，类似Excel，以简化表格设计复杂度为主要优势，在绘制表格时比较方便，缺点在于灵活性及扩展性不及带状模型。
上表的两个特征：静态表格结构繁杂、以常规方式显示数据，故而最适合的是采用表格式而非带状模式。
在四个报表中，Style Report采用表格模式，水晶报表采用带状模型，数巨报表可同时支持表格模型和带状模型，润乾报表采用表格模型。故而给予Style Report、数巨报表、润乾报表均为10分，而水晶报表虽然采用带状模型，但通过一定的工作量可以完成上表设计，并且提供了多种快捷方式以优化设计过程，故而给予7分。
报表2：
样例提供者：Style Report
各产品得分（满分10分）：
Style Report：10
水晶报表：8
数巨报表：10
润乾报表：10
评分依据：
这张报表是一个交叉表，左侧的“钢类”、“序号”，根据数据源返回数据自动向下扩展；上表头的“钢锭”等字样，根据据数据源返回数据自动向右扩展。从这个角度说，这张报表不算复杂。
稍微有些复杂的第二列“序号”和第三列“合计”。显然，序号是不可能作为一个字段在数据源中出现的，而合计按照标准交叉表设计模式惯例，是放置在最后一列的。这就需要对交叉表进行额外的处理。
一般采用的方式是分为多个设计片区进行处理。
在Style Report、数巨报表、润乾报表中，都有报表分片设计的概念，可以将一个平面表分解为多个具有逻辑关联的片区进行设计，各个片区间可以进行跨片区运算。这样上表设计起来就非常简单了。故而这三个产品在这个功能上都给予了10分。
但是在水晶报表中，只能采用多个子报表拼接的方式完成上述要求，在各个子报表拼接位置、逻辑关联方面设计起来比较麻烦，故而仅给予8分。
报表3：
样例提供者：水晶报表
各产品得分（满分10分）：
Style Report：8
水晶报表：10
数巨报表：8
润乾报表：8
评分依据：
本张报表属于多个交叉表的关联组合，设计难度略大于报表二，主要原因在于：多个交叉表的组合，不仅仅是在横向上由多组组合而成，在纵向上也是如此。
本来和报表二一样，Style Report、数巨报表、润乾报表，可以使用报表分片设计的方法，很容易解决这个问题，而水晶报表则需要使用子表拼接的发放，设计难度和复杂度高于前者。但是，在报表中，表头的格内嵌入了一个图片，将图片和文字在同一个格中进行同步显示，这是Style Report、数巨报表、润乾报表所做不到的。
故而在此项评估中，水晶报表10分，其余三个产品各8分。
报表4：
样例提供者：数巨报表
各产品得分（满分10分）：
Style Report：0
水晶报表：10
数巨报表：10
润乾报表：0
评分依据：
本报表看似普通，不过是甘特图和表格的结合而已。然而，难点就在这里：如何做到甘特图中的进度条分行与表格一一对应。
使用数巨报表和水晶报表来设计的话，甘特图的进度条是使用一个填色格控件是独立重叠摆放的，可以根据数据行数进行自动循环复制，并逐行进行报表运算，根据运算数据结果来调整当前起始位置与长度，从而达到与表中其他数据行同步的显示效果。
也就是说，要设计这样的报表，需要报表工具做到：1. 设计控件之间的属性相对独立、2. 同一控件不同衍生实例的属性相对独立、3. 控件实例在衍生过程中的属性精密可控。
Style Report和润乾报表不支持此类功能，故为为0分，水晶报表和数巨报表各10分。
报表5：
样例提供者：数巨报表
各产品得分（满分10分）：
Style Report：10
水晶报表：10
数巨报表：10
润乾报表：10
评分依据：
将某种条件下的数据，以与众不同的色彩进行展现，已经是所有成熟报表产品的基础功能。本功能所有产品均有对应功能解决。故均为10分。
报表6：
样例提供者：数巨报表
各产品得分（满分10分）：
Style Report：0
水晶报表：10
数巨报表：10
润乾报表：0
评分依据：
是很简单的一张报表，有产品大类8个，分别是数码、运动休闲、服装、计算机、家电、通讯、珠宝和食品饮料。需要用列表来显示各自销量。
设计的需求唯一特殊之处在于：出于用户对重点产品的关心，在排序上，要求“数码”和“运动休闲”两类产品分别放在第一、二行显示，“食品饮料”类产品放在最行一行显示，其他数据排序不做强制要求。
由于数据库中数据排序不固定，无论是在数据提取时按照产品大类名称还是销量进行排序，均无法保证数据显示顺序一定符合要求。
数巨报表和水晶报表均提供了对数据源数据记录的强制排序功能，可以比较便捷地解决该问题，但Style Report和润乾报表仅能简单地按照数据源顺序或逆序进行排列。故而本项评分，Style Report和润乾报表0分，数巨报表和水晶报表10分。
报表7：
样例提供者：数巨报表
各产品得分（满分10分）：
Style Report：0
水晶报表：0
数巨报表：10
润乾报表：0
评分依据：
上表是一个典型的分组报表，需要将销售订单数据按销售地区进行分组显示。特殊之处在于，由于数据量比较大，浏览者希望能象Word文档一样在报表封面上加上一个目录，并且能够在浏览的时候，鼠标点击目录，则报表自动跳转到该目录对应的内容页面。
数巨报表可为报表设计中的每一个对象，用findViewObject的方法建立运行实例，通过方法AddAnchor标记实例的当前位置，结合系统内部跳转函数，可以很方便实现上述需求。故给予10分。
其余三类产品均对此需求无能为力，故给予0分。
报表8：
样例提供者：数巨报表
各产品得分（满分10分）：
Style Report：0
水晶报表：0
数巨报表：10
润乾报表：0
评分依据：
报表要求：
1、数据筛选条件：
统计区域：<全国/北京/山东……>
文化程度：<全部/小学/初中/……>
性别：<全部/男/女>
年龄段：<全部/16岁以下/16岁~18岁/19岁~30岁/31岁~40岁/41岁~50岁/51岁~60岁/60岁以上>
2、报表创建条件：
由用户在创建报表前选择统计分行规则（选择行属性内容），行属性分类包括：审批地区/受理地/户口所在地/前往国或地区/申请原因类别/年龄段/文化程度。
难点分析：
报表的难点不在于常规的设计制作，而在于统计中行的分类方式是可变的：浏览者可以随意在年龄段、审批地区、受理地等内容上进行选择，报表按照用户选择进行分行统计。比如，用户选择“年龄段”统计，则报表中每行统计的是不同年龄段的数据；当用户选择为“受理地”时，每行统计的是不同受理地的数据。用户做出不同的选择，报表中<行属性分类>标识处的数据内容就会发生相应的变化，同时统计数据方法也会发生根本的改变。
对产品要求：
能够允许报表中某些数据的获取方法根据报表创建过程中产生的中间数据计算结果进行逻辑分析，然后根据规则向数据库请求对应的数据。
结论：
在四种产品中，只有数巨报表的“数据库动态指令”技术，能够满足上述要求，故给予10分，其余产品0分。
报表9：
样例提供者：润乾报表
各产品得分（满分10分）：
Style Report：8
水晶报表：8
数巨报表：10
润乾报表：10
评分依据：
这张报表所体现的功能需求，是当前单元格与其上下左右单元格进行跨行跨列运算的能力。这种运算不仅仅包含四则运算，还包含其他一些扩展性要求，比如本表要求的排名计算。
跨行列的四则运算，对于Style Report、水晶报表、数巨报表和润乾报表来说都不是难事，唯独在对于排名运算方面，特别是要求不仅仅对原始数据进行排名，同时还需要对多列运算结果进行排名，这种要求对于Style Report和水晶报表而言略显复杂，需要进行多步循环运算才能实现。而在数巨报表和润乾报表中，均可直接对单元格数据进行排名运算。
所以本例中，给予Style Report、水晶报表各自8分，数巨报表和润乾报表各自10分。
报表10：
样例提供者：润乾报表
各产品得分（满分10分）：
Style Report：8
水晶报表：8
数巨报表：10
润乾报表：10
评分依据：
本例报表是不规则分组交叉表，其特征表现为：
1、 同样的数据，按照不同指标要求，重复交叉运算，形成交叉报表。
2、 值区域分组，这点和常规交叉报表不同，常规交叉表都是以字段值为分组条件，而不是以字段值所在区域为条件的。比如年龄：在常规交叉表中会显示21岁、22岁、23岁……，不同的年龄是一个分组间隔。而在上表中，要求将制定段落区域的年龄作为一个分组条件。
在水晶报表中，需要通过多个子报表拼接来组合成上述样式，缺点在于子报表之间的间距、表格线对齐等等需要反复调试，比较麻烦。而Style Report、数巨报表和润乾报表，可以直接在类Excel表格中，使用多个设计区域的方式进行设计，故而在此方面水晶报表表现出它的不足。
在值区域分组方面，做得比较好的是数巨报表和润乾报表，均可以直接在单元格中通过脚本进行分组规则定义并展现。水晶报表可通过脚本进行处理，略有不足，但仍不失为一种方式。Style Report在此方面的功能比较薄弱，需要预先对数据进行区域分组处理。
在本例中，数巨报表和润乾报表均表现出完美的解决方案，故给予10分，水晶报表和Style Report在处理中各自有所不足，故给予8分。
报表11：
样例提供者：润乾报表
各产品得分（满分10分）：
Style Report：8
水晶报表：5
数巨报表：10
润乾报表：10
评分依据：
本报表难度在于同期比、比上期之类的与时间相关的运算，而这些运算往往需要用到下一行的数据除上一行数据，后一列数据除前一列数据等。
针对这种涉及到行间、列间的运算，Style Report、数巨报表和润乾报表均可直接进行单元格位移运算。而水晶报表仅能在数据源中进行预先处理，而后做数据填充。尽管最终报表得以实现，但过程复杂，对设计者技术要求高，故而水晶报表仅得5分。
尽管Style Report、数巨报表和润乾报表均支持位移运算，但如遇到多个分组行数不规则的情况，比如某一年份某季度数据缺失，导致该分组只有三行数据，则在应付这种意外事件时，Style Report无能为力，仅能通过预先的数据校验来处理，故而略显不足，给予8分。
数巨报表和润乾报表则均由单元格运算匹配模型，可以在运算中对位移单元格进行匹配校验，故而本报表样例给予满分10分。
报表12：
样例提供者：润乾报表
各产品得分（满分10分）：
Style Report：6
水晶报表：6
数巨报表：10
润乾报表：10
评分依据：
这个表是个典型的横向分片报表，数据区从左至右分成了几片，既有固定的统计数据，也有根据数据库记录扩展出来的动态数据，这种固定与变动结合的报表在实际中是非常常见的。
此外，与前面谈到的报表二、三不同，这张报表不仅仅涉及到多交叉表组合，还涉及到交叉表与列表之间的组合、交叉表与列表之间的跨列计算。
数巨报表、润乾报表，可以使用报表分片设计的方法，很容易解决这个问题，而Style Report、水晶报表则需要使用子表拼接和数据源预先处理的方法，设计难度和复杂度远远高于前者。
故而在此项评估中，Style Report、水晶报表各6分，数巨报表、润乾报表各10分。
报表13：
样例提供者：润乾报表
各产品得分（满分10分）：
Style Report：8
水晶报表：8
数巨报表：10
润乾报表：9
评分依据：
这张报表看起来简单，但它的数据实际上是放在汽车、房产、土地、其他四张表中。
这张表的做法有两种，方法之一是做一个视图，将客户名称、汽车、房产、土地、其他等数据项以外关联形式组合起来，然后以列表形式去显示。这种方法优点在于数据运算执行效率高（关联运算在服务器上执行，无疑效率要高于报表服务器执行，特别是在大数据量的情况下），缺点在于视图建立比较麻烦，另外考虑到额外情况，比如“其他”列数据在数据库表中如无直接对应，需要进行归类运算的话，则更为复杂；还有一个局限性，是如果这五张表存在不同的业务系统中（数据库不统一），这种方法将无能为力。
方法之二是单独写5个SQL，将客户名称、汽车、房产、土地、其他等数据逐一运算出来，然后在报表设计过程中以客户名称进行对应关联展现。这种方法优点在于设计过程简单，并且适应能力强，缺点在于效率上不及第一种方法。
第三种方法是单独写5个SQL，将客户名称、汽车、房产、土地、其他等数据逐一运算出来，与第二中方法不同之处，是并非将关联置于报表逻辑中完成，而是以SQL模式进行二次关联运算，这步关联运算，在报表服务器上通过报表服务器内置的SQL引擎完成。这种方法综合了上述两种方法的优点，在保证扩展性、易用性的同时，也保证了执行效率。
第一种方法四类产品都支持，第二种方法仅有数巨报表和润乾报表支持，第三种方法仅有数巨报表支持。所以，评分结果：Style Report、水晶报表各8分，数巨报表10分，润乾报表9分。
报表14：
样例提供者：数巨报表
各产品得分（满分10分）：
Style Report：8
水晶报表：0
数巨报表：10
润乾报表：0
评分依据：
联机分析（OLAP）是由关系数据库之父E.F.Codd于1993年提出的一种数据动态分析模型，它允许以一种称为多维数据集的多维结构访问来自商业数据源的经过聚合和组织整理的数据。
OLAP的作用，简单来说，是允许最终用户以自定义操作的方式，对数据进行动态的聚类分析，分析条件可以自行交叉组合，并且可对聚类数据进行逐层深入分析，直至找到数据表象的内在深层诱因。是商业智能的最核心也是最基本的功能。
目前，支持OLAP的报表我们一般称之为分析型报表，反之称之为展现型报表。由于OLAP产品对于研发的技术要求比较高，国内仅有数巨报表、和勤报表等为数不多的几家厂商具有此类功能。而润乾报表等低端产品均未能支持。
国外的Style Report支持OLAP，而水晶报表由于并入BO家族，BO另辟产品线，故而未能支持。
如果将Style Report和数巨报表进行OLAP功能对比的话，就可以发现，数巨报表在人机交互上更加具有可操作性。数巨报表支持浏览端直接使用鼠标进行维度设置，并且Cube装载运算在客户端完成，故而在表现力及运行效率上更为优越（无需反复请求服务器，并且避免了相同数据在线路中的重复传递）。此外，数巨报表允许OLAP脱机运行，用户可通过Email等方式分发OLAP当前模型，这样就带来了更为广阔的应用空间。
综合评定，该项指标，Style Report得8分，数巨报表10分，其余产品0分。
报表15：
Cube创建：原始数据1000万条记录，维数量：10；度量个数：2
评估重点：Cube创建中的运算效率及系统稳定性
各产品得分（满分10分）：
Style Report：8
水晶报表：0
数巨报表：10
润乾报表：0
评分依据：
功能满足：Style Report和数巨报表均具有独立的OLAP Server，水晶报表和润乾不支持OLAP。故而水晶报表和润乾报表为0分。
系统稳定：运行过程中，Style Report和数巨报表均未产生错误。
Cube生成周期：Style Report：97分42秒 数巨报表：61分01秒
系统占用内存峰值：Style Report：711MB 数巨报表：838MB
结论：Cube生成周期，Style Report所需时间，超过数巨报表50%以上，说明数巨报表在Cube算法上优于Style Report。但在内存消耗上，数巨报表高于Style Report接近20%，说明在对资源消耗上，Style Report具有优势。考虑到在实际商务应用中，效率更为关键，故而本环节，给予数巨报表10分，Style Report 8分。
总分合计
Style Report 92分
水晶报表 90分
数巨报表 148分
润乾报表 87分