從早期的多維分析(OLAP)到近年來的敏捷BI，BI產(chǎn)品廠商一直在強調(diào)自助能力，宣稱可以由業(yè)務人員自己分析數(shù)據(jù)，而用戶方也常常有強烈的此類需求，雙方一拍即合，很容易形成購買行為。但是，BI產(chǎn)品的自助功能真地能讓業(yè)務用戶自己隨心所欲地分析數(shù)據(jù)嗎?

“分析”這個詞并沒有一個業(yè)界公認的嚴格定義，所以不能說這些BI產(chǎn)品是否過份宣傳了。不過，就大多數(shù)缺乏BI應用經(jīng)驗的用戶所期望的工作內(nèi)容而言，自助分析的目標就可以說遠遠達不到!從經(jīng)驗上看，***情況也就能解決30%左右的問題而已，而大多數(shù)BI產(chǎn)品連這個數(shù)也達不到，只能處理10%左右的需求。

我們分為三個層面討論這個問題。

多維分析

多維分析是指針對某個事先建好的數(shù)據(jù)集(稱為立方體)做交互操作。這是大多數(shù)BI產(chǎn)品目前能夠提供出來的分析能力，盡管新一代產(chǎn)品在界面美觀度和操作方便度上有了不小的進步，但能完成的運算功能并沒有本質(zhì)變化。

多維分析的主要問題是有個建模過程，也就是事先準備數(shù)據(jù)集。如果要分析的數(shù)據(jù)都可以限定在某個數(shù)據(jù)集中，且動作只限于產(chǎn)品提供的那些(旋轉(zhuǎn)、鉆取、切片之類)，那么沒有問題。但這是個小概率事件，實際應用中會經(jīng)常超出這個范圍。增加一個以前沒想到的數(shù)據(jù)項，和另一個數(shù)據(jù)集做一個關聯(lián)運算，都會導致再建模。而建模需要求助于技術人員，這樣業(yè)務人員的自助就無從談起了。

做到多維分析這一步，只能解決10%左右的自助需求，這是BI產(chǎn)品最常見的自助能力。

關聯(lián)查詢

為解決多維分析的局限性，有些BI產(chǎn)品開始提供關聯(lián)查詢能力。一般是在多維分析前面增加一步，能夠基于多個數(shù)據(jù)集關聯(lián)計算出新的數(shù)據(jù)集再來做多維分析，或者在多維分析過程中支持多個立方體間的某些關聯(lián)運算。這相當于允許業(yè)務用戶一定程度可以自己建模。

不過，實現(xiàn)關聯(lián)查詢并不容易，其根源是關系數(shù)據(jù)庫對關聯(lián)運算(JOIN)的定義過于簡單造成的，導致數(shù)據(jù)集之間的關聯(lián)關系看起來過于繁瑣，超出許多業(yè)務人員的理解能力。這個困境在BI產(chǎn)品的界面協(xié)助下能有一些改善，好的BI產(chǎn)品能夠讓業(yè)務人員正確處理沒有形成環(huán)的關聯(lián)關系。但是，要從根本上解決問題，就要改變數(shù)據(jù)庫層的數(shù)據(jù)組織模型。而幾乎所有的BI產(chǎn)品都不會重新定義數(shù)據(jù)庫的數(shù)據(jù)模型，其關聯(lián)查詢能力就會受限。這些較深入的技術問題我們將在后續(xù)文章中逐步談及。

一個可用于檢驗BI產(chǎn)品關聯(lián)能力的通俗例子：查詢女經(jīng)理的男員工。這個很簡單的查詢需求中涉及到同一數(shù)據(jù)集的多次關聯(lián)，大多數(shù)BI產(chǎn)品都處理不了(除非事先建模)。

有了關聯(lián)查詢能力后，BI產(chǎn)品能解決的自助需求占比能提高到20%-30%，具體程度要看產(chǎn)品提供的關聯(lián)能力的強弱。

過程計算

剩下70%左右或更多的需求，都會涉及到多步驟有過程的計算。而過程計算完全超出BI產(chǎn)品的設計目標，甚至可以不被認為是數(shù)據(jù)分析，但卻是用戶特別希望解決的問題，也就是讓業(yè)務人員能夠隨心所欲地(在其權(quán)限范圍內(nèi))獲取數(shù)據(jù)。

一個簡單辦法是使用BI產(chǎn)品導出基本數(shù)據(jù)，由業(yè)務人員自己用Excel等桌面工具去做。但是，Excel并不擅長處理多層次數(shù)據(jù)的關聯(lián)運算(我們后續(xù)會討論到)，而且數(shù)據(jù)量大了也撐不住，在許多應用場景無法勝任。

在沒有更好的交互計算技術出現(xiàn)之前，這些問題還是需要技術人員才能解決。在這個前提下，BI產(chǎn)品能做的事就不是讓業(yè)務人員自己實現(xiàn)過程計算，而是要想法提高業(yè)務人員獲取技術資源的效率，以及技術人員實現(xiàn)需求的開發(fā)效率。

具體來講有兩個方面：一是建立歷史問題庫，某些以前曾經(jīng)做過的問題，可以直接由業(yè)務人員直接調(diào)出算法改變參數(shù)執(zhí)行;即使是新需求，也可以找到類似問題以協(xié)助技術人員準確理解，技術人員和業(yè)務人員的理解不一致是造成事務延期的主要因素之一;二是提供高效且可管理的開發(fā)技術，讓技術人員能快速編寫和修改計算代碼，并可將這些代碼存入歷史算法庫中保管和再次執(zhí)行。目前業(yè)界并沒有多少適合的技術，SQL可管理性較好，但編寫繁瑣而難以處理有過程計算;存儲過程需要再編譯而不方便再次執(zhí)行;Java代碼也要再編譯而基本上不可管理;其它腳本語言的集成性又較差也難以入庫管理和再次執(zhí)行。

針對于用戶最普遍的自助數(shù)據(jù)需求，當前BI產(chǎn)品的能力實際上是相當弱的。經(jīng)常的情況是：BI廠商說的是多維分析，而用戶想的是那些需要過程計算才能解決的問題，這個錯位就會導致期望高而失望大的局面。用戶要清楚自己的自助需求：是否做到多維分析就夠了?有多少關聯(lián)查詢需求?業(yè)務人員是否會提出大量需要過程計算的問題?這樣才能設定合理的期望值，知道BI產(chǎn)品對自己的作用在哪里，不被產(chǎn)品的花哨界面和流暢操作迷惑，避免事后的遺憾。