由于数据仓库技术的推广,许多银行开始将报表工作依附于数据仓库的建设,采用成型的商业报表工具产品进行报表的开发。但这 些产品,尤其是国外产品,在满足国内银行的特有需求上存在一些问题,在选型中应该从两个方面予以重视。
制作效率
目前金融界常用的报表工具以国外产品为主,部分国内产品也是采用国外报表模型设计的,这类产品大多数以数据仓库在 线分析(OLAP)技术为基础设计,由于这些产品的出发点是交互式的在线分析而并非复杂的统计报表,其报表制作能力先天较弱。银行业的大部分统计报表具有 很强的中国特色,其复杂程度远远超过基于OLAP机制设计的表格。但用户常常被这些工具友好方便的交互式界面吸引,把复杂报表制作和在线分析的需求混为一 谈,导致选购误区。
事实上,复杂报表制作和在线分析的需求是截然不同的,采用后者的机制开发的报表工具在中国式报表开发上有如下两方 面的严重不足: 首先,国内的统计报表常常是多数据源,整表规则不统一,分片规则,相互间有关联但并不强; 不完全划分和固定行列非常普遍;行列要求对称,交叉表很多; 跨行组运算也是家常便饭。而基于在线分析技术的报表工具所采用的统计模型却不能满足这些要求,如果不借助于编码(或存储过程),大部分报表都无法完成,即 使加入了编码,仍有部分报表做不出来,只能通过多个表拼接而成。其次,分析查询类的需求对表格样式格线不是很在意,许多报表根本就没有线,它们更加看重数 据元素,因此这类产品都采用了控件式的绘制方案,把数据元素和界面元素紧密结合起来。而中国的报表却对格线样式有着非常严格的要求,几乎见不到没有格线的 报表。采用控件式方案虽然也可以画出格式,而且看起来能无限灵活,但事实上绘制起来非常繁琐,对齐也很困难,修改时工作量非常大。
运行效率
绝大多数银行的报表都没有很强的实时性,如各种月报、周报都只要在指定时间内生成即可,而且在较长的周期内不会变 动。这类报表为了提高运行效率可以采用离线生成的方案,即在指定时刻启动任务,自动循环各种参数,批量生成所有报表。这种方案要求报表产品具有调度管理分 发的功能,并且配有较多种的时间与参数方案,同时提供相关的API,允许程序人员进行进一步的任务定制。目前市场上的高端报表产品均有此项功能,而且差别 不大。
而对于要求实时生成的报表,可分为数据量大和访问人数多两种情况。因数据量大导致效率低下时,一般采用中间表的方 案,把报表制作用的数据在数据库层进行汇总形成中间结果,报表的运算建立在数据量已大幅减少后的中间表上,从而满足效率的要求。这种方法要求实施人员有较 强的业务知识,中间表的设计要非常合理,与报表工具无关。
访问人数多导致的效率问题一般采用服务器集群方案,多台服务器同时运行可以分担访问量从而解决性能问题,这时要注 意报表产品的集群能力和集成性,许多产品常常带有服务器自行解决集群问题,但这种方法会浪费应用服务器的能力且不能与应用共享连接池,相比之下,采用纯 Java的产品就可以很好地与应用服务器集成,充分利用其平衡负载的能力,并统一管理数据库连接。(北京润乾软件公司供稿)
(来源:CCW)
[@more@]银行报表选型的两大因素
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/16396910/viewspace-1033914/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/16396910/viewspace-1033914/