筆者從98年進入

 筆者從98年進入數據庫及數據倉庫領域工作至今已經有近八年的時間，對數據建模工作接觸的比較多，創新性不敢談，本文只是將工作中的經驗總結出來，供大家一同探討和指正。

　　提起數據建模來，有一點是首先要強調的，數據建模師和DBA有著較大的不同，對數據建模師來說，對業務的深刻理解是第一位的，不同的建模方法和技巧是為業務需求來服務的。而本文則暫時拋開業務不談，主要關注于建模方法和技巧的經驗總結。 

　　從目前的數據庫及數據倉庫建模方法來說，主要分為四類。 

　　第一類是大家最為熟悉的關系數據庫的三范式建模，通常我們將三范式建模方法用于建立各種操作型數據庫系統。 

　　第二類是Inmon提倡的三范式數據倉庫建模，它和操作型數據庫系統的三范式建模在側重點上有些不同。Inmon的數據倉庫建模方法分為三層，第一層是實體關系層，也即企業的業務數據模型層，在這一層上和企業的操作型數據庫系統建模方法是相同的；第二層是數據項集層，在這一層的建模方法根據數據的產生頻率及訪問頻率等因素與企業的操作型數據庫系統的建模方法產生了不同；第三層物理層是第二層的具體實現。 

　　第三類是Kimball提倡的數據倉庫的維度建模，我們一般也稱之為星型結構建模，有時也加入一些雪花模型在里面。維度建模是一種面向用戶需求的、容易理解的、訪問效率高的建模方法，也是筆者比較喜歡的一種建模方式。 

　　第四類是更為靈活的一種建模方式，通常用于后臺的數據準備區??５姆絞講瘓幸桓瘢?閱藶?閾枰??康模?ê玫謀聿歡雜沒?峁┙涌冢?轡?偈北懟?

　　下面簡單談談第四類建模方法的一些的經驗。 

　　數據準備區有一個最大的特點，就是不會直接面對用戶，所以對數據準備區中的表進行操作的人只有ETL工程師。ETL工程師可以自己來決定表中數據的范圍和數據的生命周期。下面舉兩個例子： 

　　1）數據范圍小的臨時表 

　　當需要整合或清洗的數據量過大時，我們可以建立同樣結構的臨時表，在臨時表中只保留我們需要處理的部分數據。這樣，不論是更新還是對表中某些項的計算都會效率提高很多。處理好的數據發送入準備加載到數據倉庫中的表中，最后一次性加載入數據倉庫。 

原文轉自：http://www.anti-gravitydesign.com