Java報表工具功能對比

本文轉自： Java報表工具功能對比

這幾年Java報表市場很是熱鬧了一陣，先是水晶報表、Brio、Style等海外產品相繼殺入市場，而後是國內的華表、中創、數巨、和勤、潤乾、傑表等揭竿而起（這中間有的是僅支援Java的，有的是支援所有WEB環境的），一時間狼煙四起，概念戰、眼球戰、價格戰，好一番廝殺。

到如今塵埃落定，天下三分——

水晶報表、Brio分別歸入BO和Hyperion門下，倚仗BO和Hyperion在BI領域的高牆深壑，堅守最後一塊底盤；

Style Report、數巨報表、和勤報表以智能分析型報表為依託，虎踞市場腹地，並晝夜厲兵秣馬，加強BI產品功能，期待有朝一日可白衣渡江，在BO和Hyperion眼皮下虎口奪食；

華表、中創、潤乾、傑表等單一展現型報表，大多已是風流總被雨打風吹去，目前唯餘潤乾與傑表尚在廝殺，但前有Style、數巨、和勤等分析型報表打壓，後有JasperReports、Eclipse BIRT等開源產品侵擾，雖不至於勢若危卵，但總不是那麼輕鬆寫意。

市場三分，究其根源，在於產品。功能和效能——軟體永恒的話題，最終決定產品、企業未來發展的原動力。那麼，本文就來分析一下各Web報表的功能與效能。

分析對象： Style Report、水晶報表、數巨報表、潤乾報表
分析方法：抽取各個產品示範範例及說明文檔中，最具有代表性的報表，將這些報表使用其他產品進行設計，以比較功能、效能優勢。

報表1：

範例提供者：Style Report

各產品得分（滿分10分）：
Style Report：10
水晶報表：7
數巨報表：10
潤乾報表：10

評分依據：

這張報表其實在設計上，並沒有什麼特殊的要求，僅僅是繁雜。

目前的報表工具有兩種設計模式：一種是帶狀模式，以控制項在帶狀地區的擺放為設計方法，以靈活性和擴充性為主要設計優勢，缺點在於繪製複雜表格時需要消耗一定的工時，上表就是一個典型的例子。另一種為表格模型，類似Excel，以簡化表格設計複雜度為主要優勢，在繪製表格時比較方便，缺點在於靈活性及擴充性不及帶狀模型。

上表的兩個特徵：靜態表格結構繁雜、以常規方式顯示資料，故而最適合的是採用表格式而非帶狀模式。

在四個報表中，Style Report採用表格模式，水晶報表採用帶狀模型，數巨報表可同時支援表格模型和帶狀模型，潤乾報表採用表格模型。故而給予Style Report、數巨報表、潤乾報表均為10分，而水晶報表雖然採用帶狀模型，但通過一定的工作量可以完成上表設計，並且提供了多種捷徑以最佳化設計過程，故而給予7分。

報表2：

範例提供者：Style Report

各產品得分（滿分10分）：
Style Report：10
水晶報表：8
數巨報表：10
潤乾報表：10

評分依據：

這張報表是一個交叉表，左側的“鋼類”、“序號”，根據資料來源返回資料自動向下擴充；上表頭的“鋼錠”等字樣，根據據資料來源返回資料自動向右擴充。從這個角度說，這張報表不算複雜。

稍微有些複雜的第二列“序號”和第三列“合計”。顯然，序號是不可能作為一個欄位在資料來源中出現的，而合計按照標準交叉表設計模式慣例，是放置在最後一列的。這就需要對交叉表進行額外的處理。

一般採用的方式是分為多個設計片區進行處理。

在Style Report、數巨報表、潤乾報表中，都有報表分區設計的概念，可以將一個平面表分解為多個具有邏輯關聯的片區進行設計，各個片區間可以進行跨片區運算。這樣上表設計起來就非常簡單了。故而這三個產品在這個功能上都給予了10分。

但是在水晶報表中，只能採用多個子報表拼接的方式完成上述要求，在各個子報表拼接位置、邏輯關聯方面設計起來比較麻煩，故而僅給予8分。

報表3：

範例提供者：水晶報表

各產品得分（滿分10分）：
Style Report：8
水晶報表：10
數巨報表：8
潤乾報表：8

評分依據：

本張報表屬於多個交叉表的關聯組合，設計難度略大於報表二，主要原因在於：多個交叉表的組合，不僅僅是在橫向上由多組組合而成，在縱向上也是如此。

本來和報表二一樣，Style Report、數巨報表、潤乾報表，可以使用報表分區設計的方法，很容易解決這個問題，而水晶報表則需要使用子表拼接的發放，設計難度和複雜度高於前者。但是，在報表中，表頭的格內嵌入了一個圖片，將圖片和文字在同一個格中進行同步顯示，這是Style Report、數巨報表、潤乾報表所做不到的。

故而在此項評估中，水晶報表10分，其餘三個產品各8分。

報表4：

範例提供者：數巨報表

各產品得分（滿分10分）：
Style Report：0
水晶報表：10
數巨報表：10
潤乾報表：0

評分依據：

本報表看似普通，不過是甘特圖和表格的結合而已。然而，痛點就在這裡：如何做到甘特圖中的進度條分行與表格一一對應。

使用數巨報表和水晶報表來設計的話，甘特圖的進度條是使用一個填色格控制項是獨立重疊擺放的，可以根據資料行數進行自動迴圈複製，並逐行進行報表運算，根據運算資料結果來調整當前起始位置與長度，從而達到與表中其他資料行同步的顯示效果。

也就是說，要設計這樣的報表，需要報表工具做到：1. 設計控制項之間的屬性相對獨立、2. 同一控制項不同衍生執行個體的屬性相對獨立、3. 控制項執行個體在衍生過程中的屬性精密可控。

Style Report和潤乾報表不支援此類功能，故為為0分，水晶報表和數巨報表各10分。

報表5：

範例提供者：數巨報表

各產品得分（滿分10分）：
Style Report：10
水晶報表：10
數巨報表：10
潤乾報表：10

評分依據：
將某種條件下的資料，以與眾不同的色彩進行展現，已經是所有成熟報表產品的基礎功能。本功能所有產品均有對應功能解決。故均為10分。

報表6：

範例提供者：數巨報表

各產品得分（滿分10分）：
Style Report：0
水晶報表：10
數巨報表：10
潤乾報表：0

評分依據：
是很簡單的一張報表，有產品大類8個，分別是數位、運動休閑、服裝、電腦、家電、通訊、珠寶和食品飲料。需要用列表來顯示各自銷量。

設計的需求唯一特殊之處在於：出於使用者對重點產品的關心，在排序上，要求“數位”和“運動休閑”兩類產品分別放在第一、二行顯示，“食品飲料”類產品放在最行一行顯示，其他資料排序不做強制要求。

由於資料庫中資料排序不固定，無論是在資料提取時按照產品大類名稱還是銷量進行排序，均無法保證資料顯示順序一定符合要求。

數巨報表和水晶報表均提供了對資料來源資料記錄的強制排序功能，可以比較便捷地解決該問題，但Style Report和潤乾報表僅能簡單地按照資料來源順序或逆序進行排列。故而本項評分，Style Report和潤乾報表0分，數巨報表和水晶報表10分。

報表7：

範例提供者：數巨報表

各產品得分（滿分10分）：
Style Report：0
水晶報表：0
數巨報表：10
潤乾報表：0

評分依據：

上表是一個典型的分組報表，需要將銷售訂單資料按銷售地區進行分組顯示。特殊之處在於，由於資料量比較大，瀏覽者希望能象Word文檔一樣在報表封面上加上一個目錄，並且能夠在瀏覽的時候，滑鼠點擊目錄，則報表自動跳轉到該目錄對應的內容頁面。

數巨報表可為報表設計中的每一個對象，用findViewObject的方法建立運行執行個體，通過方法AddAnchor標記執行個體的當前位置，結合系統內部跳轉函數，可以很方便實現上述需求。故給予10分。

其餘三類產品均對此需求無能為力，故給予0分。

報表8：

範例提供者：數巨報表

各產品得分（滿分10分）：
Style Report：0
水晶報表：0
數巨報表：10
潤乾報表：0

評分依據：

報表要求：

1、資料篩選條件：

　　統計地區：<全國/北京/山東……>

　　文化程度：<全部/小學/初中/……>

　　性別：<全部/男/女>

　　年齡段：<全部/16歲以下/16歲~18歲/19歲~30歲/31歲~40歲/41歲~50歲/51歲~60歲/60歲以上>

2、報表建立條件：

由使用者在建立報表前選擇統計分行規則（選擇行屬性內容），行屬性分類包括：審批地區/受理地/戶口所在地/前往國或地區/申請原因類別/年齡段/文化程度。

痛點分析：

報表的痛點不在於常規的設計製作，而在於統計中行的分類方式是可變的：瀏覽者可以隨意在年齡段、審批地區、受理地等內容上進行選擇，報表按照使用者選擇進行分行統計。比如，使用者選擇“年齡段”統計，則報表中每行統計的是不同年齡段的資料；當使用者選擇為“受理地”時，每行統計的是不同受理地的資料。使用者做出不同的選擇，報表中<行屬性分類>標識處的資料內容就會發生相應的變化，同時統計資料方法也會發生根本的改變。

對產品要求：

能夠允許報表中某些資料的擷取方法根據報表建立過程中產生的中間資料計算結果進行邏輯分析，然後根據規則向資料庫請求對應的資料。

結論：

在四種產品中，只有數巨報表的“資料庫動態指令”技術，能夠滿足上述要求，故給予10分，其餘產品0分。

報表9：

範例提供者：潤乾報表

各產品得分（滿分10分）：
Style Report：8
水晶報表：8
數巨報表：10
潤乾報表：10

評分依據：

這張報表所體現的功能需求，是目前的儲存格與其上下左右儲存格進行跨行跨列運算的能力。這種運算不僅僅包含四則運算，還包含其他一些擴充性要求，比如本表要求的排名計算。

跨行列的四則運算，對於Style Report、水晶報表、數巨報表和潤乾報表來說都不是難事，唯獨在對於排名運算方面，特別是要求不僅僅對未經處理資料進行排名，同時還需要對多列運算結果進行排名，這種要求對於Style Report和水晶報表而言略顯複雜，需要進行多步迴圈運算才能實現。而在數巨報表和潤乾報表中，均可直接對儲存格資料進行排名運算。

所以本例中，給予Style Report、水晶報表各自8分，數巨報表和潤乾報表各自10分。

報表10：

範例提供者：潤乾報表

各產品得分（滿分10分）：
Style Report：8
水晶報表：8
數巨報表：10
潤乾報表：10

評分依據：

本例報表是不規則分組交叉表，其特徵表現為：

1、  同樣的資料，按照不同指標要求，重複交叉運算，形成交叉報表。

2、  值地區分組，這點和常規交叉報表不同，常規交叉表都是以欄位值為分組條件，而不是以欄位值所在地區為條件的。比如年齡：在常規交叉表中會顯示21歲、22歲、23歲……，不同的年齡是一個分組間隔。而在上表中，要求將制定段落地區的年齡作為一個分組條件。

在水晶報表中，需要通過多個子報表拼接來組合成上述樣式，缺點在於子報表之間的間距、表格線對齊等等需要反覆調試，比較麻煩。而Style Report、數巨報表和潤乾報表，可以直接在類Excel表格中，使用多個設計地區的方式進行設計，故而在此方面水晶報表表現出它的不足。

在值地區分組方面，做得比較好的是數巨報表和潤乾報表，均可以直接在儲存格中通過指令碼進行分組規則定義並展現。水晶報表可通過指令碼進行處理，略有不足，但仍不失為一種方式。Style Report在此方面的功能比較薄弱，需要預先對資料進列區域分組處理。

在本例中，數巨報表和潤乾報表均表現出完美的解決方案，故給予10分，水晶報表和Style Report在處理中各自有所不足，故給予8分。

報表11：

範例提供者：潤乾報表

各產品得分（滿分10分）：
Style Report：8
水晶報表：5
數巨報表：10
潤乾報表：10

評分依據：

本報表難度在於同期比、比上期之類的與時間相關的運算，而這些運算往往需要用到下一行的資料除上一行資料，後一列資料除前一列資料等。

針對這種涉及到行間、列間的運算，Style Report、數巨報表和潤乾報表均可直接進行儲存格位移運算。而水晶報表僅能在資料來源中進行預先處理，而後做資料填充。儘管最終報表得以實現，但過程複雜，對設計者技術要求高，故而水晶報表僅得5分。

儘管Style Report、數巨報表和潤乾報表均支援位移運算，但如遇到多個分組行數不規則的情況，比如某一年份某季度資料缺失，導致該分組只有三行資料，則在應付這種意外事件時，Style Report無能為力，僅能通過預先的資料校正來處理，故而略顯不足，給予8分。

數巨報表和潤乾報表則均由儲存格運算匹配模型，可以在運算中對位移儲存格進行匹配校正，故而本報表範例給予滿分10分。

報表12：

範例提供者：潤乾報表

各產品得分（滿分10分）：
Style Report：6
水晶報表：6
數巨報表：10
潤乾報表：10

評分依據：

這個表是個典型的橫向分區報表，資料區從左至右分成了幾片，既有固定的統計資料，也有根據資料庫記錄擴充出來的動態資料，這種固定與變動結合的報表在實際中是非常常見的。

此外，與前面談到的報表二、三不同，這張報表不僅僅涉及到多交叉表組合，還涉及到交叉表與列表之間的組合、交叉表與列表之間的跨列計算。

數巨報表、潤乾報表，可以使用報表分區設計的方法，很容易解決這個問題，而Style Report、水晶報表則需要使用子表拼接和資料來源預先處理的方法，設計難度和複雜度遠遠高於前者。

故而在此項評估中，Style Report、水晶報表各6分，數巨報表、潤乾報表各10分。

報表13：

範例提供者：潤乾報表

各產品得分（滿分10分）：
Style Report：8
水晶報表：8
數巨報表：10
潤乾報表：9

評分依據：

這張報表看起來簡單，但它的資料實際上是放在汽車、房產、土地、其他四張表中。

這張表的做法有兩種，方法之一是做一個視圖，將客戶名稱、汽車、房產、土地、其他等資料項目以外關聯形式組合起來，然後以列表形式去顯示。這種方法優點在於資料運算執行效率高（關聯運算在伺服器上執行，無疑效率要高於報表伺服器執行，特別是在大資料量的情況下），缺點在於視圖建立比較麻煩，另外考慮到額外情況，比如“其他”列資料在資料庫表中如無直接對應，需要進行歸類運算的話，則更為複雜；還有一個局限性，是如果這五張表存在不同的業務系統中（資料庫不統一），這種方法將無能為力。

方法之二是單獨寫5個SQL，將客戶名稱、汽車、房產、土地、其他等資料逐一運算出來，然後在報表設計過程中以客戶名稱進行對應關聯展現。這種方法優點在於設計過程簡單，並且適應能力強，缺點在於效率上不及第一種方法。

第三種方法是單獨寫5個SQL，將客戶名稱、汽車、房產、土地、其他等資料逐一運算出來，與第二中方法不同之處，是並非將關聯置於報表邏輯中完成，而是以SQL模式進行二次關聯運算，這步關聯運算，在報表伺服器上通過報表伺服器內建的SQL引擎完成。這種方法綜合了上述兩種方法的優點，在保證擴充性、易用性的同時，也保證了執行效率。

第一種方法四類產品都支援，第二種方法僅有數巨報表和潤乾報表支援，第三種方法僅有數巨報表支援。所以，評分結果：Style Report、水晶報表各8分，數巨報表10分，潤乾報表9分。

報表14：

範例提供者：數巨報表

各產品得分（滿分10分）：
Style Report：8
水晶報表：0
數巨報表：10
潤乾報表：0

評分依據：

聯機分析（OLAP）是由關聯式資料庫之父E.F.Codd於1993年提出的一種資料動態分析模型，它允許以一種稱為Cube的多維度結構訪問來自商業資料來源的經過彙總和組織整理的資料。

OLAP的作用，簡單來說，是允許終端使用者以自訂動作的方式，對資料進行動態群集，分析條件可以自行交叉組合，並且可對聚類資料進行逐層深入分析，直至找到資料表象的內在深層誘因。是商業智慧的最核心也是最基本的功能。

目前，支援OLAP的報表我們一般稱之為分析型報表，反之稱之為展現型報表。由於OLAP產品對於研發的技術要求比較高，國內僅有數巨報表、和勤報表等為數不多的幾家廠商具有此類功能。而潤乾報表等低端產品均未能支援。

國外的Style Report支援OLAP，而水晶報表由於併入BO家族，BO另闢產品線，故而未能支援。

如果將Style Report和數巨報表進行OLAP功能對比的話，就可以發現，數巨報表在人機互動上更加具有可操作性。數巨報表支援瀏覽端直接使用滑鼠進行維度設定，並且Cube裝載運算在用戶端完成，故而在表現力及運行效率上更為優越（無需反覆請求伺服器，並且避免了相同資料線上路中的重複傳遞）。此外，數巨報表允許OLAP離線運行，使用者可通過Email等方式分發OLAP當前模型，這樣就帶來了更為廣闊的應用空間。

綜合評定，該項指標，Style Report得8分，數巨報表10分，其餘產品0分。

報表15：
Cube建立：未經處理資料1000萬條記錄，維數量：10；度量個數：2

評估重點：Cube建立中的運算效率及系統穩定性

各產品得分（滿分10分）：
Style Report：8
水晶報表：0
數巨報表：10
潤乾報表：0

評分依據：

功能滿足：Style Report和數巨報表均具有獨立的OLAP Server，水晶報表和潤乾不支援OLAP。故而水晶報表和潤乾報表為0分。

系統穩定：運行過程中，Style Report和數巨報表均未產生錯誤。

Cube組建循環：Style Report：97分42秒  數巨報表：61分01秒

系統佔用記憶體峰值：Style Report：711MB  數巨報表：838MB

結論：Cube組建循環，Style Report所需時間，超過數巨報表50%以上，說明數巨報表在Cube演算法上優於Style Report。但在記憶體消耗上，數巨報表高於Style Report接近20%，說明在對資源消耗上，Style Report具有優勢。考慮到在實際商務應用中，效率更為關鍵，故而本環節，給予數巨報表10分，Style Report 8分。

總分合計

  Style Report  92分

  水晶報表       90分

  數巨報表       148分

  潤乾報表       87分