報表工具對比選型系列用例——多源分片報表
潤乾報表、帆軟報表、Smartbi、永洪 BI、億信 BI 這幾款國內產品都把中國複雜報表作為宣傳點。我們以常見的多源分片為報表為用例，來對比評測這些產品的處理能力（由於時間和知識限制，個別很偏的功能點可能會有遺漏）。
內容比較長，如果不想看細節，可以直接跳到最後看結論。
用例說明
報表式樣
資料結構
[訂單表]
主資料儲存在訂單表中，該表通過僱員 ID 和銷售員表關聯，通過產品 ID 和產品表關聯。
[銷售員表]
銷售員表中儲存職務、姓名，報表左下角統計資料時按照職務和姓名統計，該表通過僱員 ID 和訂單表關聯。
[產品表]
產品表中包含類別 ID 和產品 ID，並且是一對多關係，報表中需要按照類別分組，也就是要按該類別下多個產品的資訊彙總。通過產品 ID 和訂單表關聯
[類別表]
這是一箇中文字典表，通過它將類別 ID 對映成中文名稱。
假定資料都來自資料庫，可用 SQL 語句取出。
報表特點分析
1、 這是一個典型的多源分片報表，報表可以分成左上、右上、左下、右下四片區域，每片資料來自不同資料表（甚至可能不同資料庫），需要實現多個數據集之間的關聯。
2、 對欄位資料的處理，資料庫中儲存的是訂購日期，報表中需要按照年、月分組統計，需要根據日期解析出年、月，彙總區域是金額，資料庫中儲存的是單價、數量，需要對欄位進行相乘操作。
3、 上表頭中的產品類別需要按確定的次序排列，也就是維表 ID 的次序。
4、 左表頭的層次不一樣，上半兩層，下半三層。
下面看下幾款工具製作這個報表的過程和工作量。
關於工作量的評估，我們假定使用者均熟悉 SQL 語句且瞭解相應的報表工具，並只記錄實際的製作和正常除錯的時間，不包括查閱產品函式資料的時間，也就是一個熟手的完成時間。
潤乾報表
製作過程
1、 配置並連線資料來源，這個各個工具操作基本都類似，按照嚮導方式配置就行。
2、 設定資料集
潤乾報表支援多資料集，本例的資料儲存在四個表內，所以在報表中增加四個資料集，只要分別取四個表的資料（select * from …），可以通過嚮導操作。
3、 設計報表模板
多源分片報表是一個比較基礎的中國式報表，國內報表工具基本都支援，這裡看下幾個關鍵單元格的設定：
3.1、 A3 單元格表示式：=ds1.group(year( 訂購日期);year(訂購日期):1)+“年”，需求中要求按照年月分組，而資料庫中儲存的是訂購日期，所以此處先通過 year 函式取訂購日期中的年份。
3.2、 D3 單元格：=ds1.sum( 數量單價 )，報表統計項中的金額是通過單價數量這兩個欄位生成。
3.3、 E2 單元格按照類別 ID 分組統計，但是要求這個單元格顯示中文，單元格有個顯示值表示式屬性：
中文可以來自單獨的一個數據集，這樣通過內建的函式就可以將 id 對映成中文。
3.4、 E3 單元格：=ds1.sum(數量 * 單價, 產品 ID in ds4.select( 產品 ID))，多源分片最主要的要將多個數據源資料關聯在一起，函式裡邊寫入過濾條件就行，銷售額在 ds1 資料集中，E2 單元格的類別來自 ds4 資料集，ds1 和 ds4 通過產品 ID 關聯，ds4 中類別 ID 和產品 ID 是一對多的關係，所以此處關聯用 in，這樣報表右上方就能取出對應類別下的資料彙總。
3.5、 報表第四行表示式類似，主要是 ds1 和 ds3 資料集之間的關聯，這裡就不細說了。
3.6、 單元格邊框、合併單元格，這些操作和 excel 中基本一致，按照需求設定就行。
執行結果
完成後點評
1、 用時 0.5 小時。
2、 常規設定和操作 excel 類似，再加上報表內的函式，製作起來很快。
3、 函式豐富，比如=ds1.group(year( 訂購日期);year(訂購日期):1)+“年”，對訂購日期的年份進行分組，直接用 year 函式取年就行，不必對源資料集進行單獨設定；類似地，=ds1.sum( 數量 * 單價) 資料由其他欄位組合生成時，直接使用函式，不需要單獨寫 sql 語句等，這樣只關心報表中幾個函式的使用就行。
4、 多源關聯方便，比如：=ds1.sum(數量 * 單價, 產品 IDinds4.select( 產品 ID))，還是通過函式內建的一些功能實現，不用在資料集中處理，絕大多數操作都是在單元格函式中控制。
5、 產品類別用維表擴充套件（E2 格中用 ds2.group 根據類別 ID 分組），很容易保證次序，再設定顯示值就能顯示相應的中文名稱。
6、 採用類 Excel 操作，佈局、樣式設定按照以前的思維處理就行，包括一些資料彙總等等。
7、 表示式基本上都是手填，雖然有表示式編輯介面，但還不如手填來得方便。
帆軟報表
製作過程
1、 配置並連線資料來源
2、 設定資料集
帆軟報表支援單元格中的多資料集關聯，在報表中新增四個資料集，分別對應 4 個數據表。但訂單表的 SQL 特殊一點，先要用 單價 * 數量 as 銷售金額，報表中要對銷售金額彙總，金額來自單價和數量兩個欄位的乘積。因為在報表中沒找到欄位相乘彙總的辦法，所以在取數時新增一個列。
3、 設計報表模板
3.1 分別根據訂購日期的年份、月份分組，將 ds1 中的訂購日期拖拽到單元格 A3 中，在自定義分組對話方塊中設定自定義公式:year($$$)+”年”， 將 ds1 中的訂購日期欄位拖拽到 C3 中，同樣增加自定義公式分組，分組表示式為 month($$$)+”月”
3.2 D2 單元格按照城市排序，程式裡預設按照中文的 ASCII 碼排序，如果想按照拼音排序則需要在單元格屬性的擴充套件排序中設定公式，如：
使用該函式需要下載函式外掛。類別欄位是按 ID 排序，則不需要專門處理。
3.3 交叉點中的銷售金額統計，在資料集中先做了處理生成了銷售金額欄位，此處直接進行求和操作。
3.4 多資料集單元格關聯。帆軟在做多源關聯的時候，通過下拉選擇資料列，操作符和比較的物件，通過點選增加按鈕，自動生成關聯的條件表示式。
3.5 顯示值設定
對 C5 中僱員 ID 需要最終顯示出僱員的姓名，在形態中要選擇資料查詢，設定對應的顯示值欄位。
報表結果
完成後點評
1、 用時，0.5 小時。
2、 資料集設定裡直接用嚮導取數，沒有特殊的寫法，製作這樣的報表對寫 SQL 能力要求不高。
3、 到處都有視覺化介面，操作體驗對初學者非常良好。比如報表中多源關聯時，通過下拉選擇資料列、操作符和比較的物件，就能自動生成關聯的條件表示式，不需要對源資料進行關聯處理。
4、 工具採用類 Excel 操作，佈局、樣式設定按照以前的思維處理就行，包括一些資料彙總等等。
5、 運算模型把欄位和表示式分別處理的，需要增加自定義表示式才能拖拽填入，對熟手略顯囉嗦。
6、 中文排序預設是按照 ASCII 排序，並不是按照常規的首字母方式，要按首字母排序要用 StringPinyin() 函式轉換下，需要單獨下載外掛，這裡有點不方便。
7、 銷售金額來源於單價 * 數量，帆軟單元格里不能直接先對欄位相乘然後再求和，本例中是通過 SQL 語句新增欄位，文字資料來源或者 nosql 資料庫無法執行 SQL 時，只能在報表中增加隱藏行，會比較麻煩。
Smartbi
製作過程
1、 配置並連線資料來源。
2、 準備資料集
報表支援多資料集，這裡按照需要準備四個，每個資料集分別取自描述中資料結構的四個物理表。
其中訂單資料集：“select , 數量單價金額,year(訂購日期) 年,month(訂購日期) 月 from 訂單” ，因為報表內要根據訂購日期按 年和月分組，但 smartbi 沒有對應的單元格函式支援，所以需要在資料準備階段把需要分組的欄位獨立成一個欄位。彙總金額也是同樣的，在資料集已有欄位先算出“金額”。其餘資料集取出相應資料就行。
3、 設計報表模板
3.1 訂單資料集中已經處理了年、月、金額等，所以報表中直接使用處理後的欄位，用滑鼠將相應的欄位拖拽到對應單元格就行，和其他類 Excel 開發工具類似，此處就不做過細說明了。
3.2 多資料集間關聯是通過“過濾”功能，普通條件型別選擇資料列，下面的過濾條件就可以直接可以和其他資料集的欄位關聯了，如下
設計介面
執行結果
完成後點評
1、 用時：1 小時左右。
2、 Smartbi 在 excel 中進行報表開發，比較符合常規使用習慣，主要檢視下具體函式使用以及關聯操作就行。
3、 關聯直接在報表單元格中通過嚮導方式設定，簡單的關聯不需要手寫程式碼。
4、 儘管是點選方式設定過濾表示式，不過有些可複用的表示式沒法複製貼上，都必須重複點選一次。
5、 對於年、月分組的處理，沒有可用的單元格函式，需要在資料準備階段，基於“訂購日期”欄位把年、月單獨處理成獨立欄位。訂單金額同樣，需要在資料集中設定。如果資料來源是文字檔案或者是 NOSQL 資料庫，無法寫 SQL 語句處理這些欄位，這類需求就很難實現了，只能更改資料結構或者報表中增加輔助行列（本例是彙總表，需要增加大量隱藏行列），可行性不大，所以在實際應用中還是有一定限制的。
6、 在設計過程中發現，當有增刪行時，其他格子設定的主格不自動變化，這個有點費勁了，一旦有這種情況，都得檢查改一遍。
7、 沒有真實值和顯示值的分類，導致存放在不同庫的碼錶無法把名稱給顯示出來。 如果必須弄，需要藉助“轉換規則”，先建轉換規則，然後給業務資料集的欄位選擇規則，然後單元格屬性勾選“使用顯示值”這個東西是系統配置，也就是需要系統功能配合才能做到 ID 反顯名稱。
永洪 BI
製作過程
1、 配置並連線資料來源
2、 設定資料集
永洪中自由格式報表支援多資料來源，按照嚮導方式新增四個資料集，每個資料集對應資料庫中的一張表，形成銷售員、訂單、產品、類別名稱四個資料集。永洪報表單元格內支援多數劇集關聯的，但使用起來有問題，比如類別表和訂單表關聯是通過產品 ID，類別和產品 ID 是個一對多的關係，永洪單元格內關聯不支援這種 in 的形式，所以沒辦法用它的多資料集模型來實現這張報表。只能換個思路，在資料集階段將多個數據集合成一個數據集。本例中實質上是一個事實表和三個維表的關聯，還可以改用組合資料集，通過嚮導將多個數據集結果關聯形成一個單資料集：
2.1、 新建組合資料集，將已經建立好的四個資料集通過關聯欄位關聯起來，通過嚮導方式設定就行。
2.2、 訂購日期年、月的處理，在資料集設定中，可以在訂購日期上新增加統計欄位，用內建函式生成新的欄位年和月
2.3、 金額的話同樣，可以新增欄位，裡邊寫入 單價 * 數量，生成新的計算列
3、 設計報表模板
在資料集設定中，用“組合資料集”將多個數據集關聯成了一個數據集，並且對年、月、金額等資料做了處理，所以報表中設計器來就比較方便了，直接用滑鼠將欄位拖拽到對應的位置，設定擴充套件方向、合併格等就可以了。
執行結果
完成後點評
1、 報表製作用時，1 小時多。資料集多資料來源關聯需要較長時間。
2、 資料處理能力較強，提供“組合資料集”將已有的資料集（可跨庫）關聯成一個新的資料集。能夠在資料集基礎上新增統計列。
3、 多源關聯支援有一定侷限性，最好的關聯方式應該是報表內單元格間多資料集的關聯，這樣就不用考慮具體資料集的來源，永洪本身是支援單元格內做格間過濾的，但是關聯只能用“=”，而像本例中的類別和產品一對多的關聯要用 in 形式，它就不支援了，所以必須要轉成單資料集。本例是一個事實表和三個維表的關聯，還能轉換成單資料集對付，實際應用中資料集個數可能會更多，關聯會更復雜、甚至會出現多對多的關聯，就做不成單資料集了。而且即使是維表和事實表的簡單關聯，還需要考慮 left join 等關聯方式，設定工作量大增。本例製作時維表中有冗餘資料，導致資料不準確，花了較長時間才發現問題，嚴格上來說並不是一個好方案。總體來看，永洪的多源關聯能力還不夠完善。
4、 上表頭的類別排序實現困難，永洪中單元格不支援顯示值屬性的設定，要想顯示中文單元格內只能從資料集中取中文欄位，這樣就會按照中文欄位排序了，無法達到按照 ID 排序需求，倒是可以加個隱藏行，裡邊按照 ID 分組排序，然後下邊增加一行顯示中文，需要增加輔助行，有點費事了。
5、 報表中設定了表頭斜線，結果中能顯示，但是在設計模板中看不到效果，容易造成混淆。包括單元格多選，不能像 excel 那樣滑鼠選中一片，要按 ctrl 鍵，不太方便。
億信
製作過程
1、 配置並連線資料來源。
2、 設定資料集
億信支援多個數據來源，在資料集中增加多個數據集，資料集型別分為主題表和維表，主題表是報表中用到的主資料來源，也就是事實表，比如本例的訂單資訊，維表用於中文顯示值對映，也就是碼錶。按照嚮導設定，內容就是普通的 sql 語句，比如（select * from ……）。
億信報表也支援資料來自多個數據集，但是如果兩個資料集要關聯取數的話報表單元格內是無法做到的，要提前在資料集設定頁面設定表間關係。比如本例中訂單表和銷售員表是通過僱員 ID 關聯，那麼要設定一下兩個資料集間的表關聯關係：
3、報表設計頁面
億信報表的計算和其他報表工具不同，其他報表是先執行資料集取數，然後報表內根據表示式從資料集結果中取數運算，而億信是分析單元格、解析單元格表示式、查詢表間關係、拼 sql 取數返回到單元格，比如產品類別那列，第二行是 CHANPIN 資料集，第三行是 DINGDAN 資料集，
如果資料集建立階段沒有設定表間關係，那麼會解析成兩個 SQL 去資料庫取數，由於報表單元格內無法設定關聯，這兩段資料是沒有任何關聯的，本例要求取對應類別下的資料，所以在資料集處建立了 CHANPIN 和 DINGDAN 的關聯，這樣這塊就會解析成類似：select price*num from DINGDAN,CHANPIN where DINGDAN. 產品 ID=CHANPIN. 產品 ID，將這個 SQL 傳送到資料庫端然後取結果返回，這樣就能關聯展示，這裡可以看到，因為要解析成一個 SQL，所以要求兩個資料集來源必須是同一個庫。從這個意義講，億信並不能算嚴格支援多源關聯報表，關鍵運算是轉換成 SQL 丟給資料庫去做的。
億信的難點在於前期的資料整合、設定表間關聯，報表設計的具體操作和其他工具就都比較類似了，比如類別那可以取類別 ID 並按照 ID 排序，在設定顯示值，具體這裡就不一一說明了。
執行結果
完成後點評
1、 製作用時 1 小時。
2、 多源關聯時的處理，要對源資料進行資料的關聯處理，資料集多時，找表間關聯關係還要驗證關聯後的資料準確性，耗時較長。
3、 可以通過函式對資料集欄位操作，比如年、月維度的控制，銷售金額來源於 danjia*shuliang，不需要在資料集中控制。
4、 難點在資料關聯處理，資料處理完成後，這個報表格式比較簡單，實際報表製作主要通過滑鼠拖拽還是比較方便，當然這個好像多個報表工具操作都差不多。
5、 多源關聯支援是有問題的，億信的機制是報表計算時解析單元格內的表示式然後尋找表間關係再拼成 SQL 方式去資料庫取數（其實本質還是資料庫內的關聯），那麼就要求多個數據集來自同一個庫，這樣無法處理異庫資料集間的關聯，更無法支援非資料庫來源的資料。即使是同一資料庫，在設定表關聯時為保證維資料的不丟失，還要考慮 left join 等情況，實際操作起來還是有些難度的，還要避免出現多對多的情況，否則無法保證資料的正確性，當前機制下處理多源關聯類報表難度大。
總結
多源分片報表是非常典型的複雜報表，僅僅從這一個簡單例子，也能看出各家產品的風格，而且，這些風格並不只侷限於這一個報表，可以說是這些產品的基本特徵。
-
如果不糾結細節的話，各家產品都能完成這個報表，從功能上講算是都能過關的。
-
從報表開始起家的潤乾和帆軟明顯要更強，製作過程流暢性要比永洪和億信這兩家以 BI 起家的產品好很多。後兩者並不以複雜報表作為主要賣點，但受市場壓力，也要提供這種能力，基本上就是做到“可以用”的水平，但遠遠談不上好用。Smartbi 介於這兩類中間，它以 BI 起家，但年代要久遠，受到複雜報表的需求壓力也較多，能力比永洪億信要好很多，但和潤乾帆軟相比仍有一定的差距。
-
報表模型上，潤乾和帆軟基本一樣，Smartbi 也類似；永洪和億信則相差較大。這種單元格擴充套件來解決分片報表的機制先由潤乾發明，帆軟之後跟隨，擴充套件模型層面基本上全抄，只是改了術語名稱（主格改叫父格），因此是一樣的，能力也基本相當。Smartbi 之後再抄過來（延用了帆軟的術語，這裡面還有故事就不說了），結果形成了相似的模型。而永洪和億信的 BI 基因較強，對複雜報表的邏輯理解還不夠深刻，模型就差了很多，能力當然也會差很多，這兩家產品的複雜報表只能算是入門階段，和其它三家相比不在一個檔次。
-
潤乾和帆軟的使用都較為流暢，但風格也仍有不同。潤乾製作過程中提倡手寫表示式，而帆軟則更多用視覺化介面。看起來後者會對使用者更友好，這也是業界常常說用潤乾難帆軟易的現象。但對於熟手來講，手寫表示式的效率更高，而且可以隨意靈活組合；使用介面編輯對生手門檻低，熟手卻會嫌煩，還犧牲靈活性。比如此例中帆軟需要先定製資料集把表示式邏輯化成欄位才行，而潤乾對於表示式和欄位是同一套規則，無需專門處理。
-
從這個意義上，潤乾和帆軟的擴充套件模型雖然都一樣，但底層運算模型還是有差異。潤乾的抽象程度更深，資料計算能力也就更強，初期掌握難度略大，但一旦掌握就會發現能夠橫掃一切；而帆軟考慮的情況要簡單，在簡單情況下更順手，但碰到特殊情況時還要再用特殊手段，反而進一步提高學習成本。結果的表現是：初次使用且沒碰到複雜情況時帆軟的效率更高（選型考察產品時常常是這樣的），長期反覆使用時（總會碰到複雜情況了）潤乾的效率就會明顯佔優。