關鍵字：數據倉庫建模 筆者從98年進入數據庫及數據倉庫領域工作至今已經有近八年的時間，對數據建模工作接觸的比較多，創新性不敢談，本文只是將工作中的經驗總結出來，供大家一同探討和指正。
提起數據建模來，有一點是首先要強調的，數據建模師和DBA有著較大的不同，對數據建模師來說，對業務的深刻理解是第一位的，不同的建模方法和技巧是為業務需求來服務的。而本文則暫時拋開業務不談，主要關注于建模方法和技巧的經驗總結。
從目前的數據庫及數據倉庫建模方法來說，主要分為四類。
第一類是大家最為熟悉的關系數據庫的三范式建模，通常我們將三范式建模方法用于建立各種操作型數據庫系統。
第二類是Inmon提倡的三范式數據倉庫建模，它和操作型數據庫系統的三范式建模在側重點上有些不同。Inmon的數據倉庫建模方法分為三層，第一層是實體關系層，也即企業的業務數據模型層，在這一層上和企業的操作型數據庫系統建模方法是相同的；第二層是數據項集層，在這一層的建模方法根據數據的產生頻率及訪問頻率等因素與企業的操作型數據庫系統的建模方法產生了不同；第三層物理層是第二層的具體實現。
第三類是Kimball提倡的數據倉庫的維度建模，我們一般也稱之為星型結構建模，有時也加入一些雪花模型在里面。維度建模是一種面向用戶需求的、容易理解的、訪問效率高的建模方法，也是筆者比較喜歡的一種建模方式。
第四類是更為靈活的一種建模方式，通常用于后臺的數據準備區５姆絞講瘓幸桓�，议喫烔组撹要为目的，建好抵\聿歡雜沒峁┙涌�，掇\偈北懟?
下面簡單談談第四類建模方法的一些的經驗。
數據準備區有一個最大的特點，就是不會直接面對用戶，所以對數據準備區中的表進行操作的人只有ETL工程師。ETL工程師可以自己來決定表中數據的范圍和數據的生命周期。下面舉兩個例子：
1）數據范圍小的臨時表
當需要整合或清洗的數據量過大時，我們可以建立同樣結構的臨時表，在臨時表中只保留我們需要處理的部分數據。這樣，不論是更新還是對表中某些項的計算都會效率提高很多。處理好的數據發送入準備加載到數據倉庫中的表中，最后一次性加載入數據倉庫。
2）帶有冗余字段的臨時表
由于數據準備區中的表只有自己使用，所以建立冗余字段可以起到很好的作用而不用承擔風險。
舉例來說，筆者在項目中曾遇到這樣的需求，客戶表{客戶ID，客戶凈扣值}，債項表{債項ID，客戶ID，債項余額，債項凈扣值}，即客戶和債項是一對多的關系。其中，客戶凈扣值和債項余額已知，需要計算債項凈扣值。計算的規則是按債項余額的比例分配客戶的凈扣值。這時，我們可以給兩個表增加幾個冗余字段，如客戶表{客戶ID，客戶凈扣值，客戶余額}，債項表{債項ID，客戶ID，債項余額，債項凈扣值，客戶余額，客戶凈扣值}。這樣通過三條SQL就可以直接完成整個計算過程。將債項余額匯總到客戶余額，將客戶余額和客戶凈扣值冗余到債項表中，在債項表中通過（債項余額×客戶凈扣值/客戶余額）公式即可直接計算處債項凈扣值。
另外還有很多大家可以發揮的建表方式，如不需要主鍵的臨時表等等�？偨Y來說，正因為數據準備區是不對用戶提供接口的，所以我們一定要利用好這一點，以給我們的數據處理工作帶來最大的便利為目的來進行數據準備區的表設計。
行業借鑒經驗：
數據倉庫架構經驗談
對于數據倉庫的架構方法，不同的架構師有不同的原則和方法，筆者在這里來總結一下當前常采用的架構方式及其優缺點。這些架構方式不限于某個行業，可以供各個行業借鑒使用。
首先需要說明的一點是，目前在數據倉庫領域比較一致的意見是在數據倉庫中需要保留企業范圍內一致的原子層數據。而獨立的數據集市架構（Independent data marts）沒有企業范圍內一致的數據，很可能會導致信息孤島的產生，除非在很小的企業內或只針對固定主題，否則不建議建立這樣的架構方式。聯邦式的數據倉庫架構（Federated Data Warehouse Architecture）不管是在地域上的聯邦還是功能上的聯邦都需要先在不同平臺上建立各自的數據倉庫，再通過參考（reference）數據來實現整合，而這樣很容易造成整合的不徹底，除非聯邦式的數據倉庫架構也采用Kimball的總線架構（Bus Architecture）中類似的功能，即在數據準備區保留一致性維度（Conformed Table）并不斷更新它。所以，這兩種架構方式不在討論范圍之內。下面主要討論剩下的三種架構方式。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
