首先看一下下面这个表样.这个表样是润乾的一个示例表样,接着介绍birt 是如何做的

这个表样算是报表中最常见的一种需求了，把不同粒度的数据聚合到同一粒度上.

我们用automobile 表示汽车表, 用houseproperty 表示房产表, 用estate表示土地表,用others 表示其他表.他们都有customerid 来表示客户名称.customers 表有customerid 和customername

1. 用视图来拼数据

   对于  automobile 聚合使用一个autoview , sql 如下

   select sum(automobile price* quantity) autototal, customerid  from automobile group by customerid

  对于 houseproperty 使用如下view

   select sum( house price * quantity ) housetotal, customerid  from houseproperty group by customerid

  对于 土地和其他也是差不多类型的sql

  得到了上面这四个视图之后, 就把customers 表根据customerid 和其他四个视图join 起来.

  select customername ,  autototal  , housetotal , estatetotal , othertotal

   from  customers c , automobile a , houseproperty h , estate e , others o

   where 四个视图和customers的连接条件

  由于这个表样并不涉及到以 汽车，房产，土地， 其他表中的任何一个客户为主, 所以暂时也不考虑左右连接的问题.

2. 使用Birt 的Joined Data Set

   Birt 提供的Joined Data Set 跟数据库里面的视图是差不多的概念，使不过一个是在数据库内部join 数据，一个是使用Java 循环的方式join 数据.

   跟上面创建视图一样，创建四个DataSet , 输出两个字段: customerid 和 total.

   然后创建一个Joint Data Set , 把customers 表和 autototal DataSet 按照customerid join起来.这时得到四个字段 customers.customername , customers.customerid  ,  auto DataSet.customerid ，auto DataSet.autotal . 最后我们把这个Joint DataSet 命名为jdataSet1 (代表的是autoDataSet 和 customers 产生的Joint DataSet ).

  然后继续创建另一个Joint Data Set 把customers 的customerid 和前一步创建的jDataSet1 按照customerid join 起来得到一个第二个Joint DataSet1 ,我们命名为jDataSet2 .

  以此类推，最后我们输出5个字段: customers.name   ,   auto.total ,  house.total  , estate.total , others.total , 实际输出可能在customers.customerid 上重复了4次.

上面两种方式报表的做法主要有两点差别:

1. 性能

    如果本身数据库单独执行一个视图的sql 结果比较小，而本身的automobile 表数据量比较大（也就是说一个customer对非常多的automobile 记录) , 那么使用数据库视图就会比较慢. 因为数据库在尝试得到4个视图的结果进行了一些不必要的按照automobiel表的customerid和customers的customerid进 行的比较操作( 如果有索引肯定是对索引进行了多次不必要的读) ,这时候使用Java的这种循环方式会比较快一点 . 如果本身结构集比较大，那么还是用数据库本身的排序和join 比较快, 这个道理比较类似于数据库中如果结构集大于5% 就不要走索引,直接进行全表扫描.只不过这是一个java 版的.

2. 左右连接的问题

   如果这个表的数据不是以customers里面的数据为主，而是以四个视图其中的一个为主.这时候要情况可能会比较复杂一些.由于我不太清楚birt 里面joint data set 计算的方式是怎样的，所以也不太好评论.不过如果不使用joint data set , 就是使用一般的编程的方式.那么按照下面这个思路会比较好:

a , b , c , d ,e  为customers , automobiles view  (后面简写avlist 表示这个集), housetotal view , 里面的指针.  四个view 都已经排好了序.group by 是默认排序的. outlist 表示最后需要的输出 , row表示最后输出的一条数据

for ( 按照主数据循环)  {

    row.customerid = customers.customerid;

    if( customers.customerid == avlist[b].customerid) {

           outlist[x].autotaol = avlist[b].autotal ;

           b++

     }

    四个view 同一个判断方式, 但是每个view 的指针指的是不一样的.

    最后:   outlistSet . add (outlist[x])

}

如果数据源本身的数据量也很大，需要输出的数据也很多，则上面两种方式都会有性能问题，这时可以考虑商业智能里面的万金油方式: ETL

3. ETL

    从上面这个表样看来，可能会有两个隐含条件.一个是聚合的数据粒度在时间上是月，另一个在销售地点粒度上是：支行086001-301 , 所以用ETL一开始就聚合数据可能会更好的解决性能问题.另外一个是如果用户想要排序和过滤数据的话用一个单独的ETL聚合表也比拼数据的方式好的多.

这篇文章的目的并不只是想解释一个做表的问题，而是说明商业智能的一些问题不光需要站在一个独立的角度思考，有些问题本身可能随着环境的一些变化而 采取对应的措施，比如上面为了解决排序，过滤，左右连接，性能问题都需要从不同的角度来考虑问题.有时候可能一个做表的问题不光只是要限定在sql 或某个报表软件的本身，有时候某个ETL问题可能不关只是ETL就能解决的,随着情况的复杂可能需要从整个商业智能的全局来进行考虑，商业智能越来越倾向 与多个解决方法的融合.

本文原文在 http://www.gemini5201314.net

如果你对ETL中性能优化问题有兴趣的话，也可以查看另一篇关于在ETL中性能优化要站在全局的角度，而不是只在数据库角度的文章.