BI 系統(tǒng)中容易被忽視的數(shù)據(jù)源功能

用戶在選購 BI 解決方案的時候，常常會更關注界面環(huán)節(jié)的功能指標，比如美觀性、操作的流暢性、移動端支持等等。畢竟，BI 是要給業(yè)務人員使用的，這些看得見的內容一般不容易被遺漏。

然而，有些與數(shù)據(jù)源有關的后臺功能點就可能被忽略掉。如果在項目實施時才發(fā)現(xiàn)就會非常麻煩，可能造成上線延遲，或者有些功能只能繞路而行。在選購 BI 系統(tǒng)時反而要特別注意這些功能點。

1. 對大清單報表的支持

OLAP 分析時鉆取到明細數(shù)據(jù)是個基本功能，而明細數(shù)據(jù)很可能非常大，常常需要分頁顯示。我們在前面文章《大清單報表應當怎么做》中討論過這個分頁功能的實現(xiàn)手段。需要提請注意的是，絕大多數(shù) BI 解決方案都在使用該文中所說的數(shù)據(jù)庫的分頁取數(shù)機制，而沒有實現(xiàn)文中建議的雙線程方案。這些內容我們在那篇文章中已經(jīng)詳細解釋，這里就不再贅述了。

2. 對更換數(shù)據(jù)庫的支持

BI 涉及的源數(shù)據(jù)大多在關系數(shù)據(jù)庫中，需要用 SQL 來取數(shù)。而 OLAP 分析涉及的 SQL 語法形式非常簡單，都是標準 SQL 的內容。這樣，理論上講，BI 系統(tǒng)更換后臺數(shù)據(jù)庫應當是很容易的事。

但并沒有這么簡單，取數(shù)用的 SQL 主體確實是通用的，但總會涉及到一些用于條件和計算的函數(shù)，特別是與日期相關的運算 ，各家數(shù)據(jù)庫相差很大。而且，上面說的分頁語法也是標準 SQL 之外的東西，也和使用的數(shù)據(jù)庫相關。這樣，在更換后臺數(shù)據(jù)庫時，這些語法要根據(jù)使用的數(shù)據(jù)庫來做調整。

那么問題來了，這些調整是可以簡單配置就好的？還是需要有廠家程序員再編碼實現(xiàn)的？作為用戶，我想肯定會想當然地認為都叫 BI 產(chǎn)品了，這些應當能配置一下就好了吧。然而，并不是！很有一些 BI 廠商需要現(xiàn)場再開發(fā)代碼才能實現(xiàn)數(shù)據(jù)庫的切換。只不過，許多用戶常常只有一種數(shù)據(jù)庫，在廠商部署系統(tǒng)時就已經(jīng)準備好，也就感覺不到更換數(shù)據(jù)庫竟然還會是個問題。

3. 對存儲過程的支持

單純的多維分析一般不會直接用到存儲過程，特別是直接基于數(shù)據(jù)庫的 ROLAP，本身運算也是由數(shù)據(jù)庫完成的，要拼 SQL 實現(xiàn)，不可能使用存儲過程作為數(shù)據(jù)源。不過，BI 系統(tǒng)常常也都有自己的分析運算能力，可以針對任意一個給定的數(shù)據(jù)集做分析，這時候就可能接入存儲過程(以及其它外部程序數(shù)據(jù)源)來實現(xiàn)一些復雜或高效的數(shù)據(jù)準備工作。

存儲過程的訪問有業(yè)界標準，JDBC/ODBC 接口都對此有明確的規(guī)定，按說支持起來應當不是太難的事情。然而，再一次的并不是！有些廠商不支持或只能有限地支持存儲過程，不能通用地支持符合 JDBC/ODBC 標準的調用接口，這包括某個國際大牌廠商(這里就不點名了)。存儲過程參數(shù)和返回值都比較復雜，也沒有元數(shù)據(jù)信息來獲取數(shù)據(jù)結構，要全面支持確實也有點麻煩。

總結

以上是生活随笔為你收集整理的bi 存储过程方案_BI 系统中容易被忽视的数据源功能的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。