很多报表工具只允许在报表中使用单个数据集,这类工具称为单源报表工具,常见的比如iReport,Birt,水晶报表,Style report等。很多情况下我们需要用单源报表工具展现多源数据,比如来自Mysql+Oracle的数据,或者来自MSSQL+Excel的数据。这时只有将多源数据转化为单源才能使用,但怎么实现这一步呢?经过多年的实践经验,我总结出了几种方法,供大家参考。
嵌套子报表。主流的报表工具大都支持子报表,即在一张报表中嵌入第2张报表。子报表可以嵌在subtitle或detail等位置,也可以接收来自母报表的参数。
这种方法原理清晰,易于掌握,适用于个别简单的场景。但大多数情况下并不适用于多数据源报表。首先嵌套子报表是利用报表间的位置关系来代替部分运算功能,并不能实现2种数据源间的自由运算。事实上这种方法只适合1对1或1对多的简单连接,无法表示更一般运算。
其次2张报表的合并必然涉及数据间对齐的问题。由于身处不同的报表,子报表中的数据总是难以和母报表保持稳定的位置关系。
性能也是嵌套子报表的缺陷,可以想象在多级分组或扩展次数较多的报表中使用子报表的情形,这会导致报表数量和数据库连接数量爆炸的问题。另外,无法在同一张报表中进行报表设计也导致嵌套子报表难以维护。
报表高端版本。iReport,Birt,Crystal的低端版本不支持数据源间的计算,但高端版本几乎都支持将多个数据源连接成单数据源再使用。这其中包括iReport的Virtual Data Sources,Birt的Data SourcesJoin,以及Crystal的universal。
这种方式可以解决数据源间的一般运算,是厂商所提倡的最佳方法。但其中的缺陷也值得我们注意。首先是这种方法并不通用,每种报表都有各自特殊的解决办法,因此无法替换和移植,并且维护成本很高。对于在乎耦合性和扩展性的报表开发人员来讲这种方法要慎用。
其次这种方法难以解决复杂的多数据源计算,它具有可视化的wizard,但往往缺乏灵活的计算脚本,计算能力不足。
最后,这种方式对非数据库的数据源支持不足,比如将MSSQL和EXCEL整合为单数据源的过程将非常费力。
数据源计算层。数据源计算层是指介于数据源和报表工具之间,负责统一计算来自数据源的数据,并将计算结果返回给报表工具的层次。这其中有代表性的是集算器和R language。
这种方式可以全方位的解决报表中有关数据源的计算、准备等一系列问题。其中在整合多源数据方面它的好处体现在通用上。它一般会提供与具体报表工具无关的接口,比如集算器提供了JDBC接口可以被报表工具直接使用,R提供了第3方API可以间接被JAVA调用。
这种通用性还体现在计算能力上,数据源计算层提供了更加专业的结构化数据计算脚本和IDE,比如集算器的开发比SQL更简便。可以轻松解决各种复杂计算,R支持多种预测模型。另外通用性还体现在它支持多种格式的数据源,不仅是数据库中的数据,也包括非数据库的Txt/Excel等。
数据源计算层是解决多数据源报表的通用完整的方法,但性能是这类方法的通病。数据源计算层都是全内存计算,数据量受限于内存大小。不过集算器和R都能直接支持hadoop,在分布式的环境中可以较好的支持大数据。
除了上述三种主要的方法,还有2种辅助方法:
自定义数据集。这是指对报表工具提供的API接口的统称。比如JasperReport就提供了VirtualData Source和Bean Data Source两种方法配合使用,前者以可视化的方法对2个数据源进行连接;较复杂的计算或非数据库数据源间的计算则使用后者,即用JAVA开发工具直接计算底层数据,最终以报表工具可以识别的接口返回。
这种方式开发过程复杂,计算功能不专业,不通用,性能低,因此列为辅助。
数据仓库。ETL和数据仓库可归为一类。常用的工具包括:DB2 dataware house, datastage ,SSIS,informatica,Talend。数据库仓库的优点是高性能,通用性好。缺点是巨大的成本、超长的工期,无休止的维护。事实上成功的数据仓库屈指可数,在普通报表应用中很少出现,所以这里列为辅助。
以上3种主要方法和2种辅助方法可以解除绝大部分单源报表工具的限制。