润乾集算报表优化应用结构之报表数据源复用

在报表项目中,经常有多个报表的数据源计算方法有共同的部分。使用润乾集算报表,采用可挂接算法的方案时(可参考【润乾集算报表优化应用结构之可挂接算法】),可以更方便地将这些共同部分用同一个脚本来完成,从而实现算法复用。算法复用的好处是:一个算法只实现一次,不会出现同一个算法多处实现导致不一致的情况。同时也避免一个算法实现很多次的重复劳动,减轻工作量。

下面通过两个报表复用同一个算法的例子来看一下具体的实现方法。报表1是“员工绩效工资明细表”,可以按照STATE来选择不同的员工例如:STATE=="California" 或者STATE=="Texas",如下图:

报表2是“部门绩效工资汇总表”(全体员工,不按照STATE过滤),如下图:

报表1、2都要计算员工的绩效工资,算法是比较复杂的。如果两个报表都实现一遍这个计算,会有两个问题:一个是重复工作费时费力,另一个是一旦计算方法发生改变,就要修改两个地方,可能会出现不一致。使用集算报表可以用一个计算脚本来编写绩效工资算法,实现两个报表复用一个脚本。

集算报表还可以完成动态表达式解析,所以可以接收非常灵活的过滤条件或者其他表达式。集算引擎的参数定义如下图:

集算报表的计算脚本(salary.dfx)如下:

A3:判断过滤条件是否为空,如果为空就不执行过滤B3。

B3:按照条件过滤。这里使用宏来实现动态解析表达式,其中的where就是传入参数。集算器先计算${…}里的表达式,将计算结果作为宏字符串值替换${…}之后解释执行。这个例子中最终执行的是:[email protected](STATE=="California" || STATE=="Texas")。

A13单元格是将结果返回给报表页面。A4到A13之间是绩效工资的计算方法,不是本文重点,这里不详细介绍。如果where= STATE=="California" || STATE=="Texas"。A13的返回结果如下:

如果where=””,A13的返回结果如下:

报表1的模板设计如下图:

报表1数据集ds1定义如下:

其中的where参数也可以从报表1的参数中传入,实现页面上的条件选择,具体做法参见集算报表教程。

报表2的模板设计如下图:

报表2数据集ds1定义如下:

虽然报表内容、样式不同,但是两个报表的数据集都调用一个共同的脚本文件。如果将来绩效工资的计算方法发生变化,只要修改salary.dfx即可,报表1、2的模板文件不用改变。

时间: 2024-10-10 15:49:00

润乾集算报表优化应用结构之报表数据源复用的相关文章

润乾集算报表优化应用结构之混合数据源

在报表项目中,报表源数据常常会来自于多种异构数据源.例如:关系型数据库(oracle.db2.mysql),nosql数据库(mongodb),http数据源,hadoop(hive.hdfs)甚至是excel或者文本文件.通常的做法是采用ETL工具,将这些数据源都同步到数据仓库中.但是这样做的问题在于:1.配置复杂,难度较大:2.成本较高:3.数据无法实时访问,需要有较长时间的延迟:4.数据仓库的建设和管理都比较复杂:5.如果数据量很大效率会很低,而且要不断的ETL去各个应用系统同步数据:6.

润乾集算报表优化应用结构之实现T+0实时报表

在报表项目中,客户越来越关注源数据的实时性,希望看到最新发生的数据在报表中体现出来.但是,传统的报表工具+数据仓库+ETL方式很难做到这一点,往往是只能看到昨天.上周甚至是上个月的情况,也就是T+1.T+7.T+30统称T+n报表.很难实现T+0报表,也就是能体现实时信息的报表. 分析其原因在于:1.如果报表的历史数据和最新数据都从客户的生产系统读取,虽然可以实现T+0报表,但是会对生产数据库造成压力,影响客户的业务.2.如果采用数据仓库的方式,那么ETL从生产库中取出数据,需要较长的"窗口时间

润乾集算报表优化应用结构之减少存储过程

在报表应用中经常会使用存储过程实现报表的数据计算,但这会带来多方面的问题.存储过程的包只提供一层分类,无法用树形结构,容易造成代码管理混乱.有些程序员直接在现场在线修改存储过程,也不利于代码管理.升级存储过程的时候需要数据库的写权限,会对数据安全性造成影响.同时,由于SQL固有的一些问题(数据无序.缺乏集合.无法引用.分步不彻底)等,使得存储过程的编程比较困难. 很多情况下是为了提高性能而选择存储过程,但实际效果也不尽如人意.这主要是因为报表数据的计算一般都比较复杂,很难用SQL直接完成,需要通

润乾集算报表优化应用结构之可挂接算法

在报表项目中,有些报表的数据计算方法会经常改变.例如:某企业员工的实际工资是通过绩效得分计算出的,算法经常变动,需要在不改动其他代码的情况下用新算法替换旧算法.如果用Java来实现计算的话,虽然可以实现动态可挂接计算模块,但是存在缺乏基础类库.占用多余内存等问题. 采用润乾集算报表可以很好的解决这些问题,实现低耦合.热部署的动态挂接算法.集算报表挂接算法系统结合和其他报表工具+java的系统结构对比图如下: 上图可以看出,java程序必须要编译.打包才能更新.集算脚本是解释执行的,脚本文件同时也

润乾集算报表优化应用结构之报表复杂数据源的管理

在报表项目中,常常有些复杂数据计算是为一个报表专用的,其它报表用不到.可以用SQL实现写进报表数据源中,但由于SQL无法分步计算,经常会写出非常复杂难懂的长语句,不利于调试和维护.如果用Java或者存储过程来实现,计算程序会和报表模板又会分开,不利于管理.使用润乾集算报表的脚本数据集来实现报表专用计算,既可以写出简单易懂的分步骤计算脚本,又可以将脚本存放在报表模板中利于管理.系统结构的对比如下图: 下面通过一个具体的报表例子来看一下集算报表脚本数据集的用法.<年度客户销售分析报表>可以选择年份

润乾集算报表优化应用结构之数据分库存储

报表项目中,可能会出现报表源数据来自于不同数据库的情况.这是因为同一张报表可能会从多个业务系统取数据.例如:员工信息从人力资源系统中取出,销售数据从销售系统中取出.还有一种可能是,同一应用系统的数据库负载太大,不得已分成多个数据库的情况.例如:销售系统数据分成当前库和历史库. 报表工具需要连接的可能是同样类型的数据库,比如都是oracle或者db2:也可能是不同类型的数据库. 报表应用中,数据分库存储的解决办法有:1.建设专门的数据仓库:2.利用跨库访问的技术. 专门数据仓库的建设和管理比较复杂

润乾集算报表优化应用结构之本地计算

在报表项目中,常常会碰到数据库压力很大影响整个系统性能的问题.由下面的传统方案的结构示意图可以看出,全部数据存储和源数据计算都放在数据库完成.当并发访问量较大的时候,虽然每个报表的数据量不大,还是会造成数据库压力过大,成为性能的瓶颈.多数数据库厂商提供的jdbc接口传输数据比较缓慢,在并发量较大的情况,对报表系统性能的影响也非常明显. 这种情况时可以考虑采用润乾集算报表提供的本地计算方案. 所谓本地计算,是将一部分计算任务从数据库中移出到报表服务器中完成.大多数有一定规模的应用系统中,数据库和应

润乾集算报表提升性能之过程优化

报表出现性能问题需要对数据源计算进行优化时,执行路径难以确定从而被干预是阻碍报表优化的难题之一.由于数据库执行路径对开发人员不透明,报表优化需要指定执行路径时,程序员会很难甚至无法干预.而一般报表工具不具备强计算能力,大部分计算仍然要依靠数据库进行,这就导致很多报表优化效果不理想. 不同于一般报表工具,润乾集算报表内置了专门用于数据计算的集算引擎,开发人员可以通过编写集算脚本完成报表数据源准备.与数据库执行SQL路径不可控相比,集算脚本的执行过程是可控的,开发人员可根据实际情况编写或更改计算执行

用润乾集算报表实现实时报表(T+0)的方案

在报表项目中,客户越来越关注源数据的实时性,希望看到最新发生的数据在报表中体现出来.但是,传统的报表工具+数据仓库+ETL方式很难做到这一点,往往是只能看到昨天.上周甚至是上个月的情况,也就是T+1.T+7.T+30统称T+n报表.很难实现T+0报表,也就是能体现实时信息的报表. 分析其原因在于:1.如果报表的历史数据和最新数据都从客户的生产系统读取,虽然可以实现T+0报表,但是会对生产数据库造成压力,影响客户的业务.2.如果采用数据仓库的方式,那么ETL从生产库中取出数据,需要较长的"窗口时间