熱點推薦:
您现在的位置: 電腦知識網 >> 操作系統 >> Windows系統管理 >> 正文

數據倉庫邏輯建模

2013-11-11 21:39:45  來源: Windows系統管理 

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