书评 -- Professional SQL Server 2005 Reporting Services

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

＠小标：信息发送平台

以往的报表随附在应用程序内，使用者要看什么样的报表，就开该应用程序。因此运算力凭借的是各系统的计算机，安全由该应用程序控管，数据凭专属的方式取得。而在我们需要广泛地分析，大量的报表，整合的数据来源，统一地管理维护时，这种分散的报表开发与部署方式并不合用[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)所提供的报表规格，在验收时可能已经不适用了。一则是使用报表的习惯变，例如：将原本所列出的各单位业绩金额，修改为只列出入帐的金额。此种简单的过滤条件增减，以及增加金额小计、总计的格式修改倒还好。另一是较令人头痛的结构变更；例如：企业组织调整。当组织结构一改，所有的报表就要重新检验。先前，组织内的五大体系合并，而造成报表开发时程延误的原因之一是处理”报表共享”耗时过多。原本帮主体系做了六、七十支的报表，之后为了让其它体系共享，改利用某个属性的过滤条件捞取需要的组织数据。其中，若是没有牵扯组织结构的报表内容，还好修改。但若碰上需要逐一呈现组织阶层、隶属单位或是人员的话，在制作的过程上还是遇到许多困难的地方需要克服。最主要的原因是每个体系的组织阶层不同，以及同一个组织内其业务员所隶属的阶层单位不同，为了要将这些业务员的数据呈现在报表上，花费了不少脑力。所幸这些问题都已获得解决，未来只要跟着既有规则走，就可以较轻松地开发报表了。」

＠小标：当问题无解时，回去念理论

针对前文所讨论的难处，先引用不晓得在哪本杂志上读到的，华硕董事长<personname w:st="on" productid="施崇棠">施崇棠</personname>先生常对该企业员工说的话：「回去把电磁学再念二、三十遍，念到不只 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 完后，传递给 RS，RS 还要再进一步地汇总与绘制，这过程让效率如何能好？

[3] Reporting Services 企业版是可以透过多台报表服务器存取同一台存放中继数据的 SQL Server 数据库，以建构负载平衡的解决方案。

[4]通常撰写这些模块，必须遵照两端的标准，例如，既有的数据库存取方式，并满足 RS 结构定义，其要注意的细节往往不简单。