雙子星座

首先看一下下面這個表樣.這個表樣是潤乾的一個示例表樣,接著介紹birt 是如何做的

這個表樣算是報表中最常見的一種需求了，把不同粒度的數(shù)據(jù)聚合到同一粒度上.

我們用automobile 表示汽車表, 用houseproperty 表示房產(chǎn)表, 用estate表示土地表,用others 表示其他表.他們都有customerid 來表示客戶名稱.customers 表有customerid 和customername

1. 用視圖來拼數(shù)據(jù)

   對于  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 表根據(jù)customerid 和其他四個視圖join 起來.

  select customername ,  autototal  , housetotal , estatetotal , othertotal

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

   where 四個視圖和customers的連接條件

  由于這個表樣并不涉及到以 汽車，房產(chǎn)，土地， 其他表中的任何一個客戶為主, 所以暫時也不考慮左右連接的問題.

2. 使用Birt 的Joined Data Set

   Birt 提供的Joined Data Set 跟數(shù)據(jù)庫里面的視圖是差不多的概念，使不過一個是在數(shù)據(jù)庫內(nèi)部join 數(shù)據(jù)，一個是使用Java 循環(huán)的方式j(luò)oin 數(shù)據(jù).

   跟上面創(chuàng)建視圖一樣，創(chuàng)建四個DataSet , 輸出兩個字段: customerid 和 total.

   然后創(chuàng)建一個Joint Data Set , 把customers 表和 autototal DataSet 按照customerid join起來.這時得到四個字段 customers.customername , customers.customerid  ,  auto DataSet.customerid ，auto DataSet.autotal . 最后我們把這個Joint DataSet 命名為jdataSet1 (代表的是autoDataSet 和 customers 產(chǎn)生的Joint DataSet ).

  然后繼續(xù)創(chuàng)建另一個Joint Data Set 把customers 的customerid 和前一步創(chuàng)建的jDataSet1 按照customerid join 起來得到一個第二個Joint DataSet1 ,我們命名為jDataSet2 .

  以此類推，最后我們輸出5個字段: customers.name   ,   auto.total ,  house.total  , estate.total , others.total , 實際輸出可能在customers.customerid 上重復了4次.

上面兩種方式報表的做法主要有兩點差別:

1. 性能

    如果本身數(shù)據(jù)庫單獨執(zhí)行一個視圖的sql 結(jié)果比較小，而本身的automobile 表數(shù)據(jù)量比較大（也就是說一個customer對非常多的automobile 記錄) , 那么使用數(shù)據(jù)庫視圖就會比較慢. 因為數(shù)據(jù)庫在嘗試得到4個視圖的結(jié)果進行了一些不必要的按照automobiel表的customerid和customers的customerid進 行的比較操作( 如果有索引肯定是對索引進行了多次不必要的讀) ,這時候使用Java的這種循環(huán)方式會比較快一點 . 如果本身結(jié)構(gòu)集比較大，那么還是用數(shù)據(jù)庫本身的排序和join 比較快, 這個道理比較類似于數(shù)據(jù)庫中如果結(jié)構(gòu)集大于5% 就不要走索引,直接進行全表掃描.只不過這是一個java 版的.

2. 左右連接的問題

   如果這個表的數(shù)據(jù)不是以customers里面的數(shù)據(jù)為主，而是以四個視圖其中的一個為主.這時候要情況可能會比較復雜一些.由于我不太清楚birt 里面joint data set 計算的方式是怎樣的，所以也不太好評論.不過如果不使用joint data set , 就是使用一般的編程的方式.那么按照下面這個思路會比較好:

a , b , c , d ,e  為customers , automobiles view  (后面簡寫avlist 表示這個集), housetotal view , 里面的指針.  四個view 都已經(jīng)排好了序.group by 是默認排序的. outlist 表示最后需要的輸出 , row表示最后輸出的一條數(shù)據(jù)

for ( 按照主數(shù)據(jù)循環(huán))  {

    row.customerid = customers.customerid;

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

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

           b++

     }

    四個view 同一個判斷方式, 但是每個view 的指針指的是不一樣的.

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

}

如果數(shù)據(jù)源本身的數(shù)據(jù)量也很大，需要輸出的數(shù)據(jù)也很多，則上面兩種方式都會有性能問題，這時可以考慮商業(yè)智能里面的萬金油方式: ETL

3. ETL

    從上面這個表樣看來，可能會有兩個隱含條件.一個是聚合的數(shù)據(jù)粒度在時間上是月，另一個在銷售地點粒度上是：支行086001-301 , 所以用ETL一開始就聚合數(shù)據(jù)可能會更好的解決性能問題.另外一個是如果用戶想要排序和過濾數(shù)據(jù)的話用一個單獨的ETL聚合表也比拼數(shù)據(jù)的方式好的多.

這篇文章的目的并不只是想解釋一個做表的問題，而是說明商業(yè)智能的一些問題不光需要站在一個獨立的角度思考，有些問題本身可能隨著環(huán)境的一些變化而 采取對應(yīng)的措施，比如上面為了解決排序，過濾，左右連接，性能問題都需要從不同的角度來考慮問題.有時候可能一個做表的問題不光只是要限定在sql 或某個報表軟件的本身，有時候某個ETL問題可能不關(guān)只是ETL就能解決的,隨著情況的復雜可能需要從整個商業(yè)智能的全局來進行考慮，商業(yè)智能越來越傾向 與多個解決方法的融合.

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

如果你對ETL中性能優(yōu)化問題有興趣的話，也可以查看另一篇關(guān)于在ETL中性能優(yōu)化要站在全局的角度，而不是只在數(shù)據(jù)庫角度的文章.