在過去幾年里，有各種關于“NoSQL商務智能”的短評和出版物。然而，我一直沒搞清楚它吸引人關注的到底是什么，我的疑問可以歸結為“你想從中得到什么東西?”最近，我將這個話題拋向了一些主流NoSQL公司。得到結果讓我感到更加困惑了。下面是我真正搞清楚的一些方面。

正如我不久前在一篇關于數據模型的文章中提到的，許多數據庫都可以看作是一些對的集合——特別是SQL和NoSQL數據庫。

1.在關系數據庫中，一條記錄就是一組對和一些特定且預定的名稱序列(例如，來自表定義)。而且，一條記錄通常有一個標識碼(通常是前面的其中一個值)。

2.與之類似的可以稱為結構化文檔存儲(如JSON或XML)，它們的區別在于各個文檔所包含的名稱序列可能各不相同。而且，通常這些名稱之間存在一種層次關系。

3.為此，像Cassandra或HBase這樣的“寬列”NoSQL存儲很大程度上可以視為一種結構化文檔存儲，盡管它們有不同的性能優化、特性及不同類型的DML(Data Manipulation Language)。

因此，NoSQL數據通常可以看作是一個表或一組表，但是：

1.NoSQL數據庫很可能有更多的空值。

2.如果單純轉換為關系型結構，NoSQL數據庫可能會出現重復值。因此完整轉換時可能需要用到額外的數據表。

如果能夠編寫腳本提取NoSQL數據庫，然后根據需要進行轉換或匯總，那么也可以直接完成數據處理。但是，如果一定要使用一些交互界面來實現，則有一定的難度。順便指出的是，前面這種情況只適用于BI和ETL(Extract/Transform/Load)。事實上，我曾經和多個人談論過合并BI和ETL的話題，而且他們可能有理由這樣做。

另一些問題出現在性能方面。許多NoSQL系統都使用了索引，因此也有一些過濾功能。其中一些(如MongoDB)還有匯總框架。所以，如果有了數據，也有了BI工具、ETL工具或ODBC/JDBC驅動程序，那么你有沒有利用這些現成的功能呢?或者說，你是否只是選擇做一些最簡單和最緩慢的事情，即提取數據，然后在其他位置處理這些數據?這些問題的答案現在還沒有定論，至多還處于尋找過程中。

既然明確了NoSQL數據結構會給BI帶來問題，那么我們來看看有什么解決方法。是否有一些方法能讓它們真正發揮作用呢?我想說的是“NoSQL數據通常都采用層次結構，而層次非常適合向上匯總/向下分析。”但是，描述NoSQL數據的層次并不一定與BI匯總時所使用的層次相同，而且我很懷疑這兩個分類并沒有太多的重疊部分。

除了層次之外，我認為有一些用例適合完全非扁平化的BI。例如，考慮下面的場景，現在它通常都采用NoSQL來實現：

1.你的數據已經多到無法保存了(可能是機器生成的數據)。

2.所以你總是按時間片進行匯總。

3.你還會有選擇性地保存細節信息，即那些出現時被認為有一定特殊用處的數據。

面向表格的傳統BI工具很難正確實現這些數據的可視化。所以，最終可能需要借助于運行在NoSQL數據存儲的面向NoSQL的BI工具。事件序列BI工具在操作得當的前提下也能很好地處理非扁平化數據。也就是說，我不確定現在最好的事件序列所使用的實際數據結構。

以上是我個人的一些見解，歡迎大家留言討論。