解决复杂多数据源报表的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種輔助方法可以解除絕大部分單源報表工具的限制。
轉載于:https://blog.51cto.com/report5/1382424
總結
以上是生活随笔為你收集整理的解决复杂多数据源报表的5种通用办法的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Linux 指令的分类 (man pag
- 下一篇: dotConnect for Oracl