數(shù)據(jù)倉庫邏輯建模

申請免費(fèi)試用、咨詢電話：400-8352-114

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