自定义报表应用的关键问题

http://blog.runqian.com.cn/?p=1468

 自助报表产品的目标是让业务人员自助制作所需报表。但是，在实际应用中，目前的自主报表产品都没有真正实现“自助”。

  自助报表的实质是数据查询，而不是报表的格式。对于业务人员来说，用Excel画报表其实更顺手。他们的面临的问题是：如何从数据库中自由查询出符合一定业务规则的数据？

  要解决这个问题，大家首先会想到数据库的通用查询语言SQL。实际上，几乎所有自助报表厂商都在做这样的工作：开发可视化的SQL编辑界面。具体实现方式是：在对话框中列出数据库表及字段，用户拖拽后配上条件，即可生成相应的SQL语句，查询出数据。但是，这个界面交付给客户之后，业务人员往往没办法用起来，最终束之高阁。究其原因，主要是业务人员无法理解多表关联的查询。

  对于单个表来说，业务人员能够拖拽出字段、配上条件实现查询。虽然分组汇总稍难理解，但也可以接受，这个操作方式和业务人员习惯的Excel差别并不大。

  然而，有意义的查询经常是多表关联的。比如：查询储蓄余额10万元以上的储户中本地人的比例；看一下某月回款额与发票额的对比等等。

  数据之间的关联将使数据表及其关系以网状的形式呈现出来，如下图。查询时要指定关联字段，有时还有自关联、递归关联以及子查询再关联等复杂情况。一个查询中如果涉及到三五个表，出现的数据关联关系就会让业务人员头脑发晕而无从下手了。

  因此，必须把多表关联的难题解决掉，才能让业务用户顺利完成查询。目前，自主报表厂商都采用按照需求建立模型的方式，来解决这一问题。也就是说：分析业务人员的查询需求之后，在原始数据中抽取需要的表和字段，建立逻辑或者物理的宽表。这样做可以把表间关联关系固化在宽表中，多表关联查询转化为针对一个宽表的查询交给业务人员使用。

  这种按需建模的宽表模型一定程度上可以解决业务人员无法理解多表关联的问题。但是，这种方案本身的诸多问题还是会导致自助报表无法真正“自助”。

  首先，按需建模的最大问题就是需求变更。要让业务人员自助完成数据的查询，自然会出现各种不同的需求。按照事先调研的需求来建模，肯定要面对不断出现的新需求。然而，业务人员是不会建宽表的，当有些查询在现有模型中无法描述时，就需要再找技术人员去更新模型。这种按需建模的方法，已经失去了自助报表的灵活性。

  第二，宽表容易出现错误的数据。例如：订单和订单明细是一对多的主子表（如下图），因为主表订单中有数值类型字段运货费，所以形成宽表容易产生错误汇总数据。

  如果按照汇总的方式建立宽表（如下图），那么想查询订单明细信息就无法实现了。

  如果按照明细的方式建立宽表（如下图），可以看到运货费本来是每个订单只有一个的，现在重复了多个，容易被错误的汇总。

  第三，宽表还存在其他技术问题。

  对于物理宽表也就是用物理表来实现宽表的情况，上图中的“客户”、“发货日期”等字段会出现冗余，造成数据库空间的浪费。

  对于逻辑宽表，也就是用视图来实现宽表的情况，虽然不会出现数据冗余，但是会造成查询性能问题。例如：发货统计、签单统计、回款统计三个物理表形成的逻辑宽表“客户统计”如下图：

  这时候，针对“客户统计”的查询SQL：

     SELECT 客户,月份,回款金额   FROM 客户统计

  将等价于针对三个物理表的查询SQL，势必降低查询的速度：

     SELECT 回款统计.客户,回款统计.月份,回款统计.回款金额  

     FROM 回款统计,签单统计,发货统计

     WHERE 回款统计.客户=签单统计.客户

           AND 回款统计.客户=发货统计.客户

           AND 回款统计.月份=签单统计.月份

           AND 回款统计.月份=发货统计.月份