信息系统业务报表的开发与分析

　　在所有系统中业务报表的统计数据大部分由以下几种数据库的操作方式获取：

　　　　A、SUM（），汇总某一个数据表的字段，我暂且称之为报表的统计指标；

　　　　B、COUNT（），统计某一个数据表的记录数；

　　　　C、其它字段之间的逻辑运算等；

　　以上几种操作方式得出来的数据虽然在一定程度上满足了一部分的统计报表需求，但现实中往往报表除了简单的数据外，还有很多对统计的数据范围（即口径）有很多的限定，如只统计2006-6-1至2006-6-30之间所有部门的某种产品的出库总量的detail，这就不是一条简单的SUM（）就OK的。我们一起来详细地分析下这个限定条件。

　　该限定条件有三个（时间，组织机构、产品），我们暂且称之为维度。在业务报表中称了以上所列的三个维度外还有更多的，有些甚至是不确定的（这就看业务需求分析人员需求分析的深度及广度啦，能不能找出业务中隐含的可能将来为统计维度的情况）。所以我们在开发业务系统时，往往统计报表这一块是变化最大的，而报表往往跟管理是息息相关的，在一个企业或公司管理就更加善变啦，那我们作为系统开发人员和DBA如何来应付这种情况。

　　再看看这个问题描述的根本点（统计指标）——出库总量，在数据库的操作上就是( select sum(出库量)　from 表)即得出，但如果考虑前面的三个限定条件就没如此的简单。首先是时间：大家肯定想到的就是在这句SQL语句后面加个where条件不就OK啦，其实不然。我们又来看另一种对时间要求的情况，系统运行几个月后，可能有一天客户又提出想看看这几个月某个产品每个的出库量情况，采用前面的处理方式就肯定行不通。是不是加一个GROUP BY就OK啦呢？也不尽然。你也不知道客户的管理要求将来会怎么要求，所以看到很多朋友在做信息系统时只看到了客户当前的报表或某一个局部的报表要求，没有放眼将来和全局分析和考虑问题想法，经常看到说今天客户又把需求改成什么什么啦。

　　综合以上分析，我们在做信息系统分析、数据库设计及系统开发时，可以考虑采取纳入统计指标和统计维度的概念来分析与设计，首先把业务系统的数据库结构设计的健壮点，如果这点没做好，将来改结构有的你受的；其次是系统开发人员在报业务报表时，基本上都采用动态SQL，站在用户的角度多考虑考虑，把一个数据表字段的各种可能性组合尽可能地想到（如分组、范围条件等等）；当然最根本、最重要的还是需求分析人员多与客户交流，引导客户提出其报表需求，并不是一个简单的报表格式，需求包括报表的详细的统计指标和统计口径的说明，使用、查看报表的部门等等信息。这样才尽可能地减少系统在统计报表开发过程中的返工，甚至于推翻重做。