【IT168 技术文档】
数据你好，请Report给我看
SQL Server 2005中的报表服务笔者认为已经具有了一个企业报表环境的特质，这个版本中不仅提供了对于关系数据库的支持，而且对分析服务的多维数据也提供了支持。面向用户可以用HTML、PDF、TXT、Excel等多种格式导出报表，而且通过扩展机制几乎可以涵盖所有的数据源类型、所有的文本呈现类型和所有的报表方式。
通过报表服务可以可视化的完成报表设计过程的交互工作，并且可以在Web上完成绝大多数的报表管理工作。在本次的版本中，还增加了对于多维数据的Drill down，并且可以在运行时进行对于报表内容的筛选。
报表服务的整体架构
图7：报表服务的整体架构
上图是报表服务的整体架构，这其中，报表服务特别强调了扩展机制，主要包括如下4个方面。
Authentication extension：通过认证的扩展机制，可以从很多方面把来自企业的各种认证机制进行集成，包括传统应用中的“账号/口令”认证，Windows平台的基于活动目录的认证，不同信任域或者异构平台的证书认证，甚至于通过Speech SDK开发的声音认证、通过生物技术认证等等。
Rendering extension：通过扩展该机制，可以把报表内容通过更多的介质方式保存，例如可以面向企业用户提供电子邮件的支持。
Delivery extension：提供扩展该机制可以提供更多样的分发方式。
Data Processing extension：扩展该机制可以把更多的数据源，尤其是非关系数据库或者是不具有二维表格结构的数据加入到报表引擎中。
叩开业务人员自主开发Ad Hoc报表的大门
以往的报表工具更多面对的是开发技术人员，即使是非常简单的报表都要经开发人员之手再呈现给用户，但是报表服务提供了Report Model的机制，通过该机制可以把技术上的数据源信息以业务人员友好的方式，让他们在自己熟悉的Office环境中完成一些简单实用报表的DIY工作。同一个Report Model在不同的群体眼中有两个不同的角色：
对于业务人员，Report Model就是一个可以用来加工各种报表的平台，里面有他们所熟悉的业务语言描述的各种数据资源。Report Model向业务人员屏蔽了数据源连接、访问认证、表达式、原始数据内容筛选、执行参数等很多技术细节。
对于Report Model设计的技术人员而言，他们面对的是一堆数据对象实体、关系和属性。
笔者认为，如果您从事的是行业性开发或者是面向固定的大型企业应用开发，那么储备Report Model开发积累一方面可以让您快速的适应新的应用，另一方面可以简化很多技术性处理工作，最主要的是如果培训和宣传到位，它可以把业务人员的主动性也调动起来，这对于节省IT日常维护成本也有直接的利益。
通过扩展机制建立“企业报表环境”
随着信息技术的广泛应用，在许多政府和企业内部常常存在数个，甚至数十个信息系统。基于成本和运行维护费用的考虑，许多信息系统都在做不同方式的集中，无论是服务器整合、数据库整合、统一存储结构、单点登录和认证、应用系统间基于中间件和Web Service的互联等等。从整体的角度来看，都是根据技术功能进行合并。反观报表作为非常通用的业务功能和技术手段，其中不少表单在本政府序列或本行业的很多信息系统中无论数据内容还是数据格式都是一致的，但是在各个信息系统实施的时候，由于开发平台、开发工具、报表工具的变化，又往往被反复的设计、开发、部署，这往往造成成本、人力、时间的浪费。
同时，为了满足业务需求的变化，报表又往往是信息系统中修改较为频繁的部分：
对于报表的内容条目、格式的变更数量往往和界面的变更数量持平，对于新增的业务项目，报表的变更数量还可能数倍于对原始数据维护界面的变更数量。
从获取方式上，某个业务刚上线时可能只需要本地打印、Web访问；随着该业务逐步融为基本业务流程后，又常常会出现邮件报表的要求；伴随移动设备的普及，提供精简的移动报表的需求也常常会被提出；随着政府内部和企业内部各个信息系统间、各政府信息系统之间、各企业信息系统间互联的要求不断深化，来自不同信息系统间的归并报表也将会逐步浮出水面。
作为某个政府序列或一个企业而言，报表往往是其非常重要的信息资产，如果在每个信息系统内部都作针对本系统或本企业人员的报表访问控制，还是存在一个重复建设的问题。
报表的集中存储管理（存储、备份、恢复等）如果分散到不同的信息系统中，设备、存储管理人员也难免往往会出现重复投资的情况。
报表内容修改的不一致性，例如业务变更时，对报表内容和数据布局的修改往往需要在多个信息系统中重复修改。
那么SQL Server 2005的报表服务器是从整个技术流程上为您进行这种企业报表集成提供可能：
图8：报表服务扩展机制的过程化支持
