對象數據庫，商業智能和倉儲

Question

對不起，這似乎是一個新手問題，但我是數據倉庫和商業智能領域的新手。

從我讀過的內容可以看出，由於關係模型的侷限性，需要多維數據庫。任何你需要處理多維數據庫的事情都可以在一個普通的關係數據庫上完成，這個數據庫具有非常複雜的查詢和較慢的性能連接和聚合操作。

當我們談論對象數據庫的商業智能時，我們是否需要相同的概念（多維數據庫 - 數據倉庫等）？對象數據庫沒有連接，因爲對象之間的關係是通過直接引用來維護的。

Answer 1

多維度是數據倉庫的一個基本特徵。

它是而不是對於關係模型的侷限性的「解決方法」。對於需要對多個非平凡維度進行任意「切片和切塊」事實分析的數據建模來說，這是最好的方法。

星型模式查詢不是很複雜。他們其實很簡單，因爲他們幾乎總是SELECT SUM(MEASURE) FROM FACT JOIN DIM1 ON ... JOIN DIM2 ON ... WHERE...的形式。

加入操作通常很慢。但是，連接可以在面向對象的代碼中完成，而不是在SQL倉庫中完成。

在很多情況下，大多數尺寸實際上都很小，完全適合記憶。分析查詢可以轉換爲簡單提取維度屬性的內存查找之後的所有事實。

在其餘案例中，我們有一個雪花模式，其維度（通常是客戶，患者或成員維度）幾乎與相關事實數據表一樣大。在這種情況下，數據庫中的關係連接是有幫助的。

「對象數據庫沒有連接，因爲對象之間的關係是通過直接引用維護的。」

並非完全正確。對象數據庫具有從對象到對象的導航。如果您檢索一組對象以及它們的相關對象，則實際上會執行一個連接操作。

「問題是當我們談論對象數據庫的商業智能時，我們是否需要相同的概念（多維數據庫 - 數據倉庫等）？」

是的。多維性是至關重要的。絕對。對象數據庫與關係數據庫相比可以表現得更好（或者更好）。但是，無論哪種模式都必須表示度量及其維度的基本事實。

Answer 2

也許你可能會好好看看所謂的文檔數據庫。 CouchDB是流行的，開源的（免費獲取和檢索）和簡單易懂的。 CouchDB將所有數據存儲爲JSON（易於解析的JavaScript對象表示法）文檔，並且僅使用REST（僅適用於HTTP，如果您是新手）與外部世界進行通信。其中一個比較有趣的CouchDB功能是，您可以使用MapReduce範例來選擇數據來處理和聚合數據。

看一下CouchDB可能會給你一些關於非關係數據庫的一些可能性的概念。知道CouchDB主要關心的是存儲數據文檔而不是整個對象。有些數據庫是真正的對象數據庫，只要它們將給定對象的狀態存儲在程序中即可。比較db4o。

Answer 3

可能你應該考慮Object-Relational Mapping而不是直接切換到對象數據庫。

有人已經成功地通過映射Django的ORM relationnal數據庫的BI目的here

希望對大家有所幫助！