數據倉庫數據庫設計方法---關係模型和多維模型比較分析

 

　　數據倉庫中普遍採用的數據庫設計模型有兩種：關係型和多維型。廣泛認爲在數據倉庫的設計方法中關係模型是「Inmon」方法而多維模型是「Kimball」方法。

先來看下關係模型，關係型數據以一種稱爲「標準化」的形式存在。數據標準化是指數據庫設計會使數據分解成很是低的粒度級，標準化數據以一種孤立模式 存在，這種狀況下對數據表裏的數據關係要求很嚴格。通常遵循3NF範式。採用關係型設計的數據庫通常具備較強的靈活性和多功能性（能夠支持數據的多種視 圖）。

再來看下多維模型，多維模型通常有星型模式、雪花模式、混雜模式（又叫星系模式）。多維模型設計的最大優勢在於訪問的高效性。

兩種模型的區別

做爲數據倉庫設計的基礎，星形鏈接和關係型結構二者之間存在不少不一樣。最重要的區別是在靈活性和性能方面。關係模型具備高靈活性，可是對用戶來講在性能方面卻不是很理想的。多維模型在知足用戶需求方面是很是高效的，可是靈活性很差。

另外一重要區別在於設計的範圍不一樣。必然地，多維設計只能在有限的範圍內進行，也就是說，數據庫設計只能在一組請求過程下獲得最優化。若是全部不一樣組請求所有加入到設計當中，最優化變得毫無心義。

當使用關係模型時，在性能方面沒有特別的優化方法。既然關係模型要求數據以最低粒度級存儲，那麼就能夠無限制地添加新數據。很顯然，添加數據到關係 模型永遠也不會中止。正由於這樣，關係模式適合大範圍數據（如一個企業模型）,而多維模型適用於小範圍數據（如一個部門或甚至一個子部門）。

區別的起源：

關係環境是經過起源數據模型設計出來的。多維模型是根據最終用戶的請求塑造的。換句話說，關係模型經過純數據模型和其餘模式設計，而多維模型經過處理請求塑造。

在適用性方面：因爲關係模型經過抽象數據造成，因此模型自身很是靈活。但這種靈活性，對於直接數據訪問的執行卻不是最優化的。若是想獲得一個高性能的關係模型，最佳方法是從模型中抽取出數據，並從新構造一種適合於快速訪問的模式。

         多維模型在直接訪問數據方面是快速而高效的。從體系結構觀點來看，在數據倉庫設計基礎方面關係模型是更好地支持數據倉庫的模式，其緣由是，數據倉庫須要根 據不一樣的議程和多種觀察數據的方式來支持許多不一樣的用戶組。也就是說，數據倉庫對於訪問已給定的用戶並非最佳的。相反，數據倉庫能夠以多種方式支持多個 不一樣的用戶。

關係模式，數據以最低粒度級和標準化形式存儲；關係表間的關係已經定義好而且包含一個含有外鍵的關鍵字表；新表能夠對關係表中的基本數據集定義新的 彙總和篩選標準；也就是說能夠很簡單以一種形式建立關係表，再以另外一種形式從新塑造這些表，這樣作對於數據倉庫環境來講是很是理想的。

此外，關係模式支持未來未知的需求、支持適度變化的需求方面具備多維模型沒法比擬的優點。

所以根據上面討論過的緣由能夠看出：關係模型對數據倉庫是理想的基礎，而星形鏈接對於數據集市是最佳的。 

 

獨立集市和從屬集市的區別：

獨立集市是指直接經過歷史應用建立的數據集市。創建獨立數據集市不須要有「全局思想」考慮。

與獨立數據集市相對應的是從屬數據集市。從屬數據集市是利用來自數據倉庫的數據創建的。它的數據源不依賴與歷史數據或操做型數據，只依賴於數據倉庫。總之，從屬數據集市要求有預先的計劃、長期的觀察、全局的分析和企業各不一樣部門對需求分析的合做與協調。

創建多個獨立數據集市後，很快用戶就會發現數據集市之間的信息不統一，也不一樣步，並且每增長一個數據集市就會出現不斷增加的細節數據冗餘的問題，須要大量的資源來創建接口程序，維護這些程序也變成了負擔。所以獨立數據集市不適合與解決企業中的信息問題。

固然，若是企業採用了從屬數據集市，並在創建任何數據集市以前先建立了一個數據倉庫，那麼，獨立數據集市固有的哪些體系結構方面的問題就不會出現了。

換句話說,獨立數據集市表示的是不須要顧及全局及全景的一個短時間的、有限範圍的解決方法。另外一方面，從屬數據集市則要求一個長期和全局的展望。可是獨立數據集市不能爲企業信息提供一個堅實的基礎，而從屬數據集市確能爲信息決策提供了一個真正的長期基礎。

 

總結：數據倉庫中數據庫設計推薦採用關係模式設計方法，而數據集市推薦採用多維模型設計方法，其中數據集市推薦採用從屬型的數據集市構建方法。