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