现在的位置: 首页 > 综合 > 正文

书评 — Professional SQL Server 2005 Reporting Services

2013年10月02日 ⁄ 综合 ⁄ 共 4135字 ⁄ 字号 评论关闭

大多数的信息系统都输出报表,而每个企业也都存在着各式报表。随着商业竞争日益激烈,信息系统需要提供随手可得、实时而正确的数据。若要让数据说话,就必须正确地引用数据,套上商业逻辑后,有条理而直观地呈现。但当企业具一定规模后,要做到此并不容易。

@小标:信息发送平台

以往的报表随附在应用程序内,使用者要看什么样的报表,就开该应用程序。因此运算力凭借的是各系统的计算机,安全由该应用程序控管,数据凭专属的方式取得。而在我们需要广泛地分析,大量的报表,整合的数据来源,统一地管理维护时,这种分散的报表开发与部署方式并不合用[1]

随着商业智慧(Business Intelligence BI)概念的流行,大型资料仓储、累积且集中的多方数据、广泛而多样的分析方式...种种需求让分析变成独立的系统,而统筹各式报表的报表平台应运而生,微软 2004 年一月推出的 Reporting Services 是一个很好的范例。它的诉求在完整的报表生命周期管理,从开发、管理、派送三个面向,满足对报表平台大部分的需求。

然而,真的要好好设计与照顾报表平台并不容易,就笔者个人的经验,主要的难度有以下面向:

l           正确:数据来源广泛,商业逻辑复杂,参与人员来自不同单位。例如,在报表的生命过程中,参与者有报表检视者、需求分析人员、报表设计者、提供数据来源之交易系统的操作者、转至数据仓储或超市的数据转换过程...等等。冗长的流程让报表设计与除错上必须小心翼翼。笔者就曾与同事为了上百笔纪录汇总后达 1 亿多的金额,但短少 300 元而忙了一天,最后发现是输入者选错了员工部门。开发的初期,更不知多少次,在资料海中比对了半天后,才发现数据转换的过程中有误。

l           呈现:数据呈现方式因人的好恶而难以设计,现今报表的制作还多少需要一点美术概念。报表设计需要能让信息以最有效的方式传达,这里面有着许多文化因素,例如,报表工具大都是英语体系国家发明的,而中文的呈现往往有些细微差异,例如直书/横书、中文大写数字、日期时间的呈现...等等。最麻烦的是用新的工作做出与旧格式完全相同的报表。毕竟开发工具不同,例如以往是用 Clipper Office 系列产品,搭配徒手撰写程序,因此许多用程序所造成的打印效果,而今要改用 Web 呈现,这是用铁锤打苍蝇。

l           效率:报表平台的数据量大,使用人数多,公式计算与绘制报表的逻辑;让产生报表变得双重复杂。实做过程中,随时要考虑到如何有效地切割与分散运算,限制使用者的存取[2]

l           安全:当报表数量与使用人数皆多时,认证与授权设计的复杂度就会倍增,你可以想象数百人存取数百张报表,不同人可存取的报表不同,不同人存取相同报表时,呈现的内容也要不同。但这些人平日的工作执掌还会有许多的变动。另外,加密数据的维护也造成系统备份/还原上需要多花一点心思。

l           发送:使用者要如何方便地看到报表。由于集中在报表平台,最方便的方式当然是让使用者以浏览器浏览,但若使用者人数庞大,大家都挤到 Web Server 看报表,这会造成效率瓶颈[3],安全也难以管控。
Reporting Services 预设提供周期性;批次地以电子邮件派送报表。或是自动产生报表后存放到共享数据夹,你可以再搭配 FTP 等方式来提供存取机制。或是以 .NET 程序语言整合 Report Viewer Control,乃至于以 URL 连结某份报表,或直接呼叫 Reporting Services web service,都是让使用者可以存取报表的方式。选项多,事前规划就变得重要。设计得好,既可减轻运算负担,也简化安全的复杂性。

l           弹性:由于企业体内早已存在行之有年的安全架构、数据存放与管理机制、信息呈现的前端平台( Enterprise Information Portal EIP),因此,要新加入一个报表平台,很有可能要与上述的架构整合。这必须要能够让 RS 的使用者或开发者自行扩充各种需求,例如安全的认证方式,数据提取的方式,以及整合进既有的应用程序来呈现报表。大家须自行依照需求,打造延伸功能的模块[4]

当报表从交易型系统的附属品摇身变成分析系统的主要角色之一时,其重要性与专业性已大幅提升。

就自己实际任职顾问的企业,以 Reporting Service 为报表平台,负责开发报表者仅有一人,花了约一年半的时间,制作了七十多张报表,至今五十多张报表上线使用。就她表示:开发工具很方便,可以很容易地做出报表来,只是数据验证要花时间,大部分碰到的问题都是从数据库内数千个数据表间,厘清用途与报表逻辑的问题。

另一个较麻烦的问题是使用者需求变更,由于开发时程较长,一年半前系统分析人员(SA)所提供的报表规格,在验收时可能已经不适用了。一则是使用报表的习惯变,例如:将原本所列出的各单位业绩金额,修改为只列出入帐的金额。此种简单的过滤条件增减,以及增加金额小计、总计的格式修改倒还好。另一是较令人头痛的结构变更;例如:企业组织调整。当组织结构一改,所有的报表就要重新检验。先前,组织内的五大体系合并,而造成报表开发时程延误的原因之一是处理报表共享耗时过多。原本帮主体系做了六、七十支的报表,之后为了让其它体系共享,改利用某个属性的过滤条件捞取需要的组织数据。其中,若是没有牵扯组织结构的报表内容,还好修改。但若碰上需要逐一呈现组织阶层、隶属单位或是人员的话,在制作的过程上还是遇到许多困难的地方需要克服。最主要的原因是每个体系的组织阶层不同,以及同一个组织内其业务员所隶属的阶层单位不同,为了要将这些业务员的数据呈现在报表上,花费了不少脑力。所幸这些问题都已获得解决,未来只要跟着既有规则走,就可以较轻松地开发报表了。」

@小标:当问题无解时,回去念理论

针对前文所讨论的难处,先引用不晓得在哪本杂志上读到的,华硕董事长 施崇棠先生常对该企业员工说的话:「回去把电磁学再念二、三十遍,念到不只 know how,还要 know why。」面对错综复杂的问题时,唯有追本溯源,提纲挈领才能企求釜底抽薪地解决问题。所以,多看书是必要的第一步J

在此介绍一本讲述微软 Reporting Services 不错的书:「Professional SQL Server 2005 Reporting Services」,出版商为 Wrox。你可以在以下的网页取得该书的第七章试阅:http://www.microsoft.com/technet/prodtechnol/sql/2005/technologies/rch7rptslnpatternrecipes.mspx。这一章相当不错,可以当作各种小技巧的模板。若没时间阅读该书,单靠此章就可以提升不少功力J

相对于上述整体报表平台架构性的问题,本书着墨不多,它就是平实地解释各项功能,并提供各种设计范例。适合初学者按部就班地了解 Reporting Services 各个面向。但若要完整处理报表平台,这就不仅仅是 Reporting Services 本身的问题了,例如 Windows 平台的目录服务、数据库的管理维护、使用者存取报表的应用程序整合...等等,这需要广泛涉猎各种技术,并充分了解使用者需求才行。

该书是从前一版描述 Reporting Services 2000 的内容改写而来,由于 Reporting Services 2000 2005 的兼容性很高,因此若你仍在用 2000 版本,此本书仍有参考价值。

@小标:阅读建议

该书是 Reporting Services 2005 的入门书,地毯式地描述各项功能。其英文文字平易近人,让读者不会因为语文本身造成艰涩难懂。

本书分五个部份介绍 Reporting Services,其中第二部份介绍报表设计(从第四章到第七章),第四部份讨论报表服务管理(第十、十一章),这两部份需要熟悉。另外,第一部分的简介,其第三章的架构说明最好也要熟读。至于其它部分,例如第三部份之 Report Model Report Builder 的使用,以及第五部份的将报表平台与应用程序整合,就看你是否有此需求了。

@小标:相关阅读

l           http://msdn.microsoft.com/sql/bi/reporting/default.aspx 此处有很多关于 Reporting Services 的资源,特别是有一些微软已经建立好的报表模板,让你可以分析一些应用系统的执行状况。另有许多录制的在线研讨会,也可以引导你入门。微软的在线讨论区 Reporting Services 版区也有非常多的问题解析: http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=82&SiteID=1

l           介绍一本繁体中文书:SQL Server 2005 Reporting Services 报表服务实务应用,博硕出版社出版,作者:姚巧玫、尹相志、许致学。这三位作者在 SQL Server 领域都钻研已久,本书融合他们的技术与实务经验而成,是一本不错的参考书。

另外,报表设计的主轴有二,一是数据来源,另一是布置呈现方式。对 Reporting Services 来说,要强化上述的两部份,你还需要熟悉 SQL VB.NET 两种语言。SQL 用在处理数据,例如将复杂的数据逻辑在数据库端以预存程序(stored procedure)撰写,然后喂给报表。而在报表版面设计时,所有预设功能外的加值,都是靠撰写 VB.NET




[1] 不过,我并不是说哪一种报表应用模式会取代哪一种,Visual Studio 2005 所提供 Report Viewer Control 也提供了不需要报表平台(Reporting Services),让个别报表存放在应用程序自身中,随着应用程序散布的模式。

[2] 笔者在教授 Reporting Services 的课程中,遇到一位朋友抱怨效率不佳,我问她资料来源多大,她回答:一百万笔纪录 Join 另外一百万笔!你可以想见,当数据库缓慢地 Join 完后,传递给 RSRS 还要再进一步地汇总与绘制,这过程让效率如何能好?

抱歉!评论已关闭.