數(shù)據(jù)倉(cāng)庫(kù)邏輯建模

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

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