Reporting Services 3: 报表模型项目

    由开发人员设计的报表不可能涵盖组织所有需要展示的内容，终端用户往往需要自己设计报表，但他们又面临着不了解业务数据库的结构的困难。在这种情况下，很自然地，在开发人员和终端用户之间需要有一种分工：由开发人员提供一个针对业务数据库结构的解释（或翻译）；在解释（或翻译）的基础上，终端用户得以创建满足自己需要的即席(Ad hoc)报表。

    首先来看一下开发人员如何完成对业务数据库结构的解释或翻译。

    对业务数据库结构的解释或翻译是通过报表模型项目来完成的。报表模型项目可以看作是一个容器，它由一个或多个数据源、数据源视图和报表模型组成：

    1）数据源用于提供对业务数据库的连接信息，数据源文件在报表模型项目中的扩展名是.ds；

    2）数据源视图（Data Source View，DSV）可以被看作上一个业务数据库的“视图”，就是说在数据源视图中，可以使用业务数据库中对象的结构并在此基础上作一定的修改以满足报表展示的需要，例如定义表间关系和主键、创建命名查询和计算列等，数据源视图文件在项目中的扩展名是.dsv；

    3）报表模型是一个语义模型(Semantic Model)，是对数据源视图所引用的数据库的元数据的说明，是报表模型项目的最主要组成部分。报表模型文件在项目中的扩展名是.smdl，SMDL是Semantic Model Definition Language（语义模型定义语言）的缩写，和RDL一样，SMDL也是基于XML语法的。

    需要注意的是：此处数据源只能是SQL Server 2000/2005或Analysis Services 2005，这是因为报表服务器处理报表模型这种语义模型时使用的查询翻译器需要将针对语义模型的操作转换为相应的SQL语句，将来其它的数据源也可能会被支持；另外，每个报表模型只能引用一个数据源或数据源视图。

    图1和图2是一个报表模型文件的实例。一个模型中可以存在一个或多个实体、文件夹和透视。实体是由角色、属性组成的。角色描述了该实体与其它实体间的关系。属性有多种表现形式：若Binding属性指定为DSV中的一个列名，则该属性被称为源字段；若属性是由其Expression属性决定，则该属性被称为表达式，如向导会为不同日期组成部分的日期属性创建变体、为数值属性创建Sum、Avg、Min和Max聚合；若属性的IsFilter属性为True并且Filter属性为一个返回逻辑值的表达式，则该属性被称为筛选器。

图1 报表模型中包含的对象

图2 报表模型实体中包含的对象

    BIDS为报表模型项目的开发提供了非常易用的向导，向导使用一个数据源视图作为输入，经过计算表行计数、计算列唯一性、计算列宽度、生成表和列以及关系的处理规则的过程输出一个报表模型文件。报表模型文件将直接展示在终端用户的面前，所以其中的实体、角色、属性等都应该具有唯一且容易由之联想到具体业务的名称。

    可以这么说，数据源视图是报表模型和业务数据库之间的中间层，而报表模型又是业务数据库和终端用户使用的报表设计器的中间层。

    需要注意的是，每个实体的IdentifyingAttributes属性集合中必须至少存在一个成员，就是说每个实体都需要有具有辨识该实体的属性集合，否则会出现编译错误。

    报表模型项目创建完毕后，需要部署之以便报表服务器的访问。

图3 报表模型项目的部署选项

    接着，来看一下终端用户如何利用报表模型创建即席报表。

    终端用户创建即席报表，首先要求在客户端存在一个报表设计器。

    SQL Server 2005 Reporting Services Report Builder即是一个客户端的报表设计器，这是一个可以从报表服务器访问的易于集中管理的ClickOnce Windows应用程序。Report Builder在服务器上的物理路径是X:\Program Files\Microsoft SQL Server\MSSQL.3\Reporting Services\ReportServer\ReportBuilder\ReportBuilder.application，在客户端可以通过类似http://(ServerName)/ReportServer$(InstanceName)/reportbuilder/reportbuilder.application的URL访问，并下载到客户端类似C:\Documents and Settings\Administrator\Local Settings\Apps\2.0\LCQC7WWZ.25Z\VPHJ3NW5.ADG的物理路径中。

    终端用户使用上述URL启动报表设计器、在三种可用报表布局（模板）[表格（纵览式）、矩阵（交叉表）和图表]中的一种并选择以报表模型名称或透视名称显示的数据源后，就会出现图4所示的Report Builder界面：资源管理器管理着上述报表模型的实体及字段，在设计报表状态下，用户可以自己进行简单的报表定制。

图4 报表设计器Report Builder

    在图4中，我们可以看到，报表存在一个筛选器选项，此处的筛选器和报表模型中的筛选器有什么联系呢？在报表模型中，源字段以及作为派生字段的表达式都比较容易理解，它们最终将出现在报表设计器的字段列表中，而对于筛选器一开始从名称上先入为主将筛选器理解为：开发人员在报表模型中定义“筛选器”，该筛选器规定不同角色、权限的终端用户只能浏览自己的被允许的数据。事实上并非如此，报表模型只是DSV中与业务相关的对象在终端用户眼里的反应，不具备对不同用户组进行筛选数据的功能（如果需要为不同用户组筛选数据，可以通过在DSV中创建命名查询并以建立不同透视显示给终端用户）。在上面已经提到过，报表模型中的筛选器是属性的一种变体，它的IsFilter属性为True而且其Filter属性是一个返回逻辑值的表达式，如果其Hidden属性不为True，那么在报表设计器中也会和其它属性一样显示出来。事实上，这正为终端用户提供一种更好筛选数据的方式：例如，我们规定可能离职的员工需要满足的条件是——[雇员.生日>=1980-1-1（年轻人可能更愿意尝试不同的工作）] || [雇员.婚姻状况=False（没有人能拴住他，呵呵……） AND 雇员.性别='M'（既然是他，当然为男性）]，这是一个比较复杂的逻辑（当然我举的例子可能不是很恰当），终端用户可能并不清楚这种逻辑，这就需要开发人员在报表模型中将上述表达式设置为一个筛选器“Filter_是否可能离职”。而报表设计器中的筛选器选项正是为了限定报表中要显示的数据，终端用户只要为报表设置筛选器为“Filter_是否可能离职=True”就可以在报表中只显示可能离职的员工的数据，而“Filter_是否可能离职”在报表模型中表现为筛选器，而在报表设计器中表现为一个报表可用字段，即报表模型中的筛选器是为了方便终端用户在报表设计器中更容易地筛选数据而存在的。

图5 报表模型设计器和报表设计器中的筛选器

    终端用户使用Report Builder设计好报表后，使用“运行报表”预览报表的执行情况，将报表保存在报表服务器上，在应用程序指定正确的报表路径就可以使用这个服务器端的报表来展示数据了（图6）。由于这种即席报表是由终端用户设计的，终端用户并不负责完成在应用程序中引用该报表的工作，这项工作应该由应用程序自动来完成，在以后的随笔中将介绍如何实现这项工作。

图6 在Web项目中显示的即席报表（点击小图看大图）