資料倉儲邏輯建模(ZT)

資料倉儲邏輯建模

[@more@]資料倉儲模型的特點
　　
　　對於傳統的OLTP系統,我們總是按照應用來建立它的模型,換言之,OLTP系統是面向應用的。而資料倉儲則一般按照主題 (Subject)來建模,它是面向主題的。何謂應用?何謂主題?讓我們來看一個簡單的例子。 在銀行中,一般都有對私 (個人儲蓄)、對公 (企業儲蓄)、信用卡等多種業務系統,它們都是面向應用的,所支援的交易型別簡單而且固定。由於實施的先後等原因,這些系統可能執行在不同的平臺上,相互之間沒有什麼關係,各系統之間的資料存在冗餘。比如每個系統中都會有客戶的資料,當針對銀行建立其資料倉儲應用時,要把上述生產系統中的資料轉換到資料倉儲中來。從整個銀行的角度來看,其資料模型不再面向個別應用,而是面向整個銀行的主題,比如客戶、產品、渠道等。因此,各個生產系統中與客戶、產品、渠道等相關的資訊將分別轉換到資料倉儲中相應的主題中,從而在整個銀行的業務介面上提供一個一致的資訊檢視。
　　
　　資料倉儲的建模方法
　　
　　邏輯建模是資料倉儲實施中的重要一環,因為它能直接反映出業務部門的需求,同時對系統的物理實施有著重要的指導作用。目前較常用的兩種建模方法是所謂的第三正規化 (3NF,即 Third Normal Form)和星型模式 (Star-Schema),我們將重點討論兩種方法的特點和它們在資料倉儲系統中的適用場合。
　　
　　什麼是第三正規化
　　
　　正規化是資料庫邏輯模型設計的基本理論,一個關係模型可以從第一正規化到第五正規化進行無損分解,這個過程也稱為規範化 (Normalize)。在資料倉儲的模型設計中目前一般採用第三正規化,它有非常嚴格的數學定義。如果從其表達的含義來看,一個符合第三正規化的關係必須具有以下三個條件:
　　
　　1. 每個屬性的值唯一,不具有多義性;
　　
　　2. 每個非主屬性必須完全依賴於整個主鍵,而非主鍵的一部分;
　　
　　3. 每個非主屬性不能依賴於其他關係中的屬性,因為這樣的話,這種屬性應該歸到其他關係中去。
　　
　　我們可以看到,第三正規化的定義基本上是圍繞主鍵與非主屬性之間的關係而作出的。如果只滿足第一個條件,則稱為第一正規化;如果滿足前面兩個條件,則稱為第二正規化,依此類推。因此,各級正規化是向下相容的。
　　
　　什麼是星型模式
　　
　　星型模式是一種多維的資料關係,它由一個事實表(Fact Table)和一組維表(Dimens ion Table)組成。每個維表都有一個維作為主鍵,所有這些維則組合成事實表的主鍵,換言之,事實表主鍵的每個元素都是維表的外來鍵。事實表的非主屬性稱為事實 (Fact),它們一般都是數值或其他可以進行計算的資料;而維大都是文字、時間等型別的資料。
　　
　　第三正規化和星型模式在資料倉儲中的應用
　　
　　一個資料倉儲的基本結構可以分成如圖所示的四層:
　　
　　
　　也有一些企業由於這樣那樣的原因,沒有建立全企業範圍的資料倉儲,而是建立基於部門應用的獨立資料集市(有關資料集市與資料倉儲的比較,請參閱本報今年第 27期上筆者編譯自 Bill Inmon的文章)。
　　
　　大多數人在設計中央資料倉儲的邏輯模型時,都按照第三正規化來設計;而在進行物理實施時,則由於資料庫引擎的限制,不得不對邏輯模型進行不規範處理 (De-Normalize), 以提高系統的響應速度,這當然是以增加系統的複雜度、維護工作量、磁碟使用比率 (指原始資料與磁碟大小的比率)並降低系統執行動態查詢能力為代價的。
　　
　　根據資料倉儲的測試標準 TPC-D規範,在資料倉儲系統中,對資料庫引擎最大的挑戰主要是這樣幾種操作:多表連線、表的累計、資料排序、大量資料的掃描。下面列出了一些 DBMS在實際系統中針對這些困難所採用的折衷處理辦法:
　　
　　1、如何避免多表連線:在設計模型時對錶進行合併,即所謂的預連線 (Pre-Join)。當資料規模小時,也可以採用星型模式, 這樣能提高系統速度,但增加了資料冗餘量。
　　
　　2、如何避免表的累計:在模型中增加有關小計資料 (Summarized Data)的項。這樣也增加了資料冗餘,而且如果某項問題不在預建的累計項內,需臨時調整。
　　
　　3、如何避免資料排序:對資料事先排序。但隨著資料倉儲系統的執行,不斷有新的資料加入,資料庫管理員的工作將大大增加。大量的時間將用於對系統的整理,系統的可用性隨之降低。
　　
　　4、如何避免大表掃描:透過使用大量的索引,可以避免對大量資料進行掃描。但這也將增加系統的複雜程度,降低系統進行動態查詢的能力。
　　
　　這些措施大都屬於不規範處理。根據上面的討論,當把規範的系統邏輯模型進行物理實施時,由於資料庫引擎的限制,常常需要進行不規範處理。舉例來說,當系統資料量很小 ,比如只有幾個 GB時,進行多表連線之類複雜查詢的響應時間是可以忍受的。但是設想一下,如果資料量擴充套件到很大,到幾百 GB,甚至上 TB,一個表中的記錄往往有幾百萬、幾千萬,甚至更多,這時進行多表連線這樣的複雜查詢,響應時間長得不可忍受。這時就有必要把幾個表合併,儘量減少表的連線操作。當然,不規範處理的程度取決於資料庫引擎的並行處理能力。使用者在選擇資料庫引擎時,除了參考一些相關的基準測試結果外,最好是能根據自己的實際情況設計測試方案,從幾個資料庫系統中選擇最適合自己企業決策要求的一種。
　　
　　不規範處理的階段
　　
　　現在來討論一下,當不得不選擇不規範處理時,應在哪個階段進行。
　　
　　由於中央資料倉儲的資料模型反映了整個企業的業務執行規律,在這裡進行不規範處理容易影響整個系統,不利於今後的擴充套件。 而且不規範處理產生的資料冗餘將使整個系統的資料量迅速增加,這將增加 DBA的工作量和系統投資。因此,當系統效能下降而進行不規範處理時,比較好的辦法是選擇問題較集中的部門資料集市實施這種措施。這樣既能有效地改善系統效能,又不至於影響整個系統。在國外一些成功的大型企業級資料倉儲案例中,基本上都是採用這種方法。
　　
　　那麼,在中央資料倉儲中是否可以採用星型模式來進行模型設計呢?我們知道,星型模式中有一個事實表和一組維表,我們可以把事實看成是各個維交叉點上的值。例如,一個汽車廠在研究其銷售情況時可以考察汽車的型號、顏色、代理商等多種因素,這些因素就是維,而銷售量就是事實。這種多維模型能迅速給出基於各個維的報表,這些維必須事先確定。
　　
　　星型模式之所以速度快,在於針對各個維作了大量的預處理,如按照維進行預先的統計、分類、排序等。在上面的例子中,就是按照汽車的型號、顏色、代理商進行預先的銷售量統計。因此,在星型模式設計的資料倉儲中,作報表的速度雖然很快,但由於存在大量的預處理,其建模過程相對來說就比較慢。當業務問題發生變化,原來的維不能滿足要求時,需要增加新的維。由於事實表的主鍵由所有維表的主鍵組成,這種維的變動將是非常複雜、非常耗時的。星型模式另一個顯著的缺點是資料的冗餘量很大。綜合這些討論,不難得出結論,星型模式比較適合於預先定義好的問題,如需要產生大量報表的場合;而不適合於動態查詢多、系統可擴充套件能力要求高或者資料量很大的場合。因此,星型模式在一些要求大量報表的部門資料集市中有較多的應用。
　　
　　小結
　　
　　上面討論了資料倉儲模型設計中常用的兩種方法。在資料倉儲的應用環境中,主要有兩種負載:一種是回答重複性的問題;另一種是回答互動性的問題。動態查詢具有較明顯的互動性特徵,即在一個問題答案的基礎上進行進一步的探索,這種互動過程常稱為資料探勘 (Data Mining)或者知識探索 (Knowledge Discovery)。對於以第一種負載為主的部門資料集市,當資料量不大、報表較固定時可以採用星型模式;對於中央資料倉儲,考慮到系統的可擴充套件能力、投資成本和易於管理等多種因素,最好採用第三正規化。