原文位址：http://c.raqsoft.com.cn/article/1597195841742?r=CGQ
潤乾報表、帆軟報表、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(數量 * 單價, 産品 ID in ds4.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 基因較強，對複雜報表的邏輯了解還不夠深刻，模型就差了很多，能力當然也會差很多，這兩家産品的複雜報表隻能算是入門階段，和其它三家相比不在一個檔次。
- 潤乾和帆軟的使用都較為流暢，但風格也仍有不同。潤乾制作過程中提倡手寫表達式，而帆軟則更多用可視化界面。看起來後者會對使用者更友好，這也是業界常常說用潤乾難帆軟易的現象。但對于熟手來講，手寫表達式的效率更高，而且可以随意靈活組合；使用界面編輯對生手門檻低，熟手卻會嫌煩，還犧牲靈活性。比如此例中帆軟需要先定制資料集把表達式邏輯化成字段才行，而潤乾對于表達式和字段是同一套規則，無需專門處理。
- 從這個意義上，潤乾和帆軟的擴充模型雖然都一樣，但底層運算模型還是有差異。潤乾的抽象程度更深，資料計算能力也就更強，初期掌握難度略大，但一旦掌握就會發現能夠橫掃一切；而帆軟考慮的情況要簡單，在簡單情況下更順手，但碰到特殊情況時還要再用特殊手段，反而進一步提高學習成本。結果的表現是：初次使用且沒碰到複雜情況時帆軟的效率更高（選型考察産品時常常是這樣的），長期反複使用時（總會碰到複雜情況了）潤乾的效率就會明顯占優。