信息系统的报表存取模式研究

总结性报表之一，易受主观意识影响，有遗漏潜在信息的可能；图形类报表的报表内容客观，但也易受到图形的局限性而影响分析结果的评估；而表格类报表作为报表呈现的基本形式，在关系数据库数据呈现中发挥着越来越重要的作用。另一方面是报表数据存取方式的选择，这涉及报表存取模式。本文认为表格类报表是信息系统报表呈现的主要形式，并着重比较了3种常用的报表存取模式，接着详细分析了表格类报表的设计方法、性能优化等问题，最后，以一个数据统计系统——五人制足球信息统计系统为例，讨论了表格类报表的应用。

1 报表存取模式的比较

数据存取是指数据库数据存储组织和存贮路径的实现和维护，而所谓报表存取模式是指报表的数据来源及其数据存储组织的方式。在报表开发中，报表呈现的数据来源通常有三种，分别是视图（View）、存储表（Table）、数据仓库（Data warehouse）。第一种是在数据库中通过创建视图，基于视图做过滤查询后，为前端应用程序提供数据源，输出报表；第二种是在业务数据库中创建存储表，专门存储报表数据，并在前端应用程序输出报表；第三种是从数据源提取数据，存储在数据仓库中，利用即席查询、OLAP分析、数据挖掘等访问工具输出报表。

在进一步讨论报表存取模式之前，需要了解普通视图和表的区别及执行效率问题。视图是从一个或几个基本表（或视图）导出的表。它与基本表不同，是个虚表。数据库中只存放视图的定义，而不存放视图对应的数据，这些数据仍存放在原来的基本表中。因此普通视图实际就是多表查询，显然比单表查询的效率要低些，这是视图和表的区别。

下面讨论常见的三种报表存取模式以及它们的优点与缺点，如表1所示。

通过创建视图（View）来呈现报表是一种最基本的开发模式。通常，这一开发模式仅适合于只有少数几个表的连接查询或简单计算的情形。Crystal Reports报表软件是这种报表存取模式的典型代表。其主要特点是形式多样的内容创建、支持多数据源、提供分析工具以及支持Web应用，可集成到开发者的开发环境中，如Visual Studio，.Net平台等。这种报表开发方法直观，数据基本不存在冗余，帮助开发者做出了大量报表。如果报表数据很复杂时，比如报表需要从复杂的数据源或者多个不同类型的数据源中获取数据，获取的数据可能还需要统计、格式转换或其他处理。这样的报表视图查询语句复杂，实现难度大。通过这类报表软件制作复杂报表时，会因为在视图中进行多次复杂的关系代数运算使得运行效率很低，无法高效地将数据库中的数据加载到报表中。而用户请求以最少的响应时延传送Web页面被公认为Web页面最重要的设计准则，因此这种方法仅适用于业务规则简单的报表。

物化视图（Materialized View）是视图的一种延伸。物化视图把视图结果存放在数据库中，创建一个包含视图数据的临时表，基于这个临时表再执行查询。这种处理能够在一定程度上提高报表查询的效率。但开发者还是需要一口气编写复杂的视图，难度大，也不便于开发者维护代码。

相反若以存储表（Table）的方式存取报表数据并输出，其好处是报表查询效率高。开发者只需要在业务系统中编写少量程序，控制数据流的提取、转换，保证数据的一致性，并将报表数据源存储到存储表中。这种方法在处理复杂数据源时，实现难度比视图小。当然用存储表的方式也会导致一些问题：①因需要在业务系统中自动提取转换原始数据，从而拖累业务系统，导致业务系统运行效率相对低一点；②存在一定的数据冗余，这就需要开发人员确保数据的高度一致性。这种方法适用于业务规则复杂的报表。

以数据仓库（Data warehouse）的方式开发报表，除数据仓库数据库服务器外，还需要创建分析服务器（Analysis Services），建立专门的多维数据库，不仅在服务器资源上增加了额外的开销，而且开发的成本要高很多，这种报表存取模式适用于企业级管理信息系统。

在实际开发中，对于小型常规的业务系统，多采用视图或存储表的设计方法；对于企业级管理信息系统，则更多采用创建数据仓库的方式开发报表。

2 报表呈现过程的分析与设计

2.1报表呈现过程的数据流分析

在传统的报表软件中，报表统计处理单元从数据源中提取、转换、加载数据，输出报表呈现给用户。如图1所示，数据源直接把原始数据交给报表统计处理单元处理。当原始数据复杂时，一方面，实现难度增大；另一方面，增加了报表统计处理单元的负载，使查询效率降低。

在这个过程中，如果能够把数据的提取、转换交给数据源来完成或者增加一个数据源加载处理单元来完成这部分的数据处理，会减轻报表统计处理单元的负载，如图2所示。当数据源加载处理单元能够在业务系统中运行，不在报表系统中运行，虽然会影响业务系统的运行效率，但有些情况下是值得的。

三种报表存取模式中，存储表和数据仓库结构的报表存取模式，正是通过增加一个数据源加载处理单元来提取、转换数据，使得报表统计处理单元的实现难度降低、查询效率提高。

2.2报表呈现过程的设计

在报表呈现过程的设计阶段，需要进行功能模块设计和数据库设计。本文以存储表结构的报表存取模式为例，讨论其实施步骤。

2.2.1功能模块设计

根据需求分析、数据流程以及模块划分标准设计模块并给出具体功能。从模块聚合性方面考虑，报表呈现过程的数据流是先提取、转换业务系统中的原始数据并存储在存储表中，之后再加载存储表数据，生成报表。因此整个数据流可分为原始数据的提取、转换和数据加载两个不同时间段进行。从模块耦合性方面考虑，原始数据的提取、转换和数据的加载只是通过数据交换实现，并且控制信息的传递。

因此报表呈现过程中包括两个功能模块，分别是报表统计模块和数据源加载模块。报表统计模块用于报表输出和数据加载，即设计出符合客户要求的报表样式，并设计好数据加载接口。数据源加载模块用于数据的提取、转换及存储，即在业务系统的业务流中选择适当位置设计数据源加载模块，获取流经该业务的原始数据，转换后存储在存储表中，并保持数据的一致性。

2.2.2数据库设计

报表呈现过程中，数据库设计也尤为重要，这里的数据库主要是指存储表。存储表可以违背完整性约束以及范式，比如不设置主键或者设置自增长ID作为惟一标识；允许数据存在冗余，用业务表的有关非主属性替代之间的关系或外键，其目的是达到所存储的数据跟视图基本一样。对于需要复杂计算的派生列数据项要留有对应的列接收数据。

3 实例研究

笔者以五人制足球信息统计系统中的报表设计为例，对视图和存储表两种报表存取模式及报表呈现过程的分析设计思想进一步分析与讨论。本系统开发平台为ASP.NET和SQL Server，主要完成系统管理、赛前管理、赛后管理和比赛报告等四大功能模块。系统业务中涉及的用户主要有裁判员、比赛监督员、赛区工作人员、体协管理员。主要业务描述如下：①裁判员在赛后登记裁判报告；②比赛监督员在赛后登记比赛监督报告；③赛区工作人员在赛后登记赛区工作报告；④体协管理员审核报告并做出停赛处理以及扣分罚款处理。

比赛报告模块作为本系统的核心模块，其包括裁判报告、比赛监督报告、赛区工作报告、积分榜、射手榜、停赛公告、扣分罚款统计等7张报表。在分析每张报表的数据来源时，发现裁判报告、比赛监督报告、赛区工作报告以及射手榜、积分榜的业务规则较简单，其数据源大多来自一两张表并且不需要对原始数据后续处理，容易创建视图，得出符合要求的报表。射手榜报表数据源的创建视图代码如图3所示。

从代码量我们可看出代码量极少，最终报表呈现的效果如图4所示。这类业务规则简单的报表，视图方式显然是更优的选择。

而停赛公告和扣分罚款统计的业务规则比较复杂。以停赛公告为例，其业务规则如下：当1名队员比赛时得到1张红牌或者黄牌累计达到3张时，要求停赛1次；停赛场序由体协管理员审核完赛事报告后，继续处理；如需要额外停赛，由体系管理员后续处理。报表输出还要求同一队员累加停赛场数，最终输出1张信息自上而下累加的停赛公告报表。若以创建视图的方式，查询语句极其复杂，因此存储表的存取模式是最佳的选择。

在数据库设计方面，停赛公告存储表的关系模式是停赛公告表（编号，赛事年度，赛事轮数，赛事场序，球队名称，队员名称，队员号码，停赛场序，累积黄牌，累计红牌，累计停赛，停赛原因，处理状态）。停赛公告存储表的关系模式显然不满足完整性约束和范式，更接近报表的数据源。

在功能模块设计方面，赛事审核时，设计数据源加载模块，获取红黄牌数据，转换为停赛数据，控制信息的传递，保证数据一致性，并更新停赛存储表，供用户后续处理后输出报表。处理代码如图5所示。

报表统计模块的设计相对容易，从存储表中加载数据，绑定到报表中，并输出报表。停赛公告报表呈现的效果如图6所示。

4 结语

笔者通过比较三种报表存取模式的差别及分析表格类报表的设计方法，就报表呈现过程中如何降低报表的实现难度和如何优化报表的查询性能等问题，提出解决方案，并给出实例。在设计报表呈现过程时，如果业务规则较简单，选择视图作为报表的数据来源比较合适；如果业务规则复杂且报表有特殊要求，选择存储表或数据仓库作为数据来源更合适。然而存储表这种报表存取模式实际上可以理解为一种小型的数据仓库。笔者并没有提出一种介于数据仓库和视图之间的新模式替代存储表。这是本文存在的不足，也有待进一步研究探讨。

（本文责任编辑：孙国雷）