解决复杂多数据源报表的5种通用办法

很多报表工具只允许在报表中使用单个数据集，这类工具称为单源报表工具，常见的比如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种辅助方法可以解除绝大部分单源报表工具的限制。