1.確定主題
即確定數據分析或前端展現的主題。例如：我們希望分析某年某月某一地區的啤酒銷售情況，這就是一個主題。主題要體現出某一方面的各分析角度（維度）和統計數值型數據（量度）之間的關係，確定主題時要綜合考慮。我們可以形象的將一個主題想象爲一顆星星：統計數值型數據（量度）存在於星星中間的事實表；分析角度（維度）是星星的各個角；我們將通過維度的組合，來考察量度。那麼，“某年某月某一地區的啤酒銷售情況”這樣一個主題，就要求我們通過時間和地區兩個維度的組合，來考察銷售情況這個量度。從而，不同的主題來源於數據倉庫中的不同子集，我們可以稱之爲數據集市。數據集市體現了數據倉庫某一方面的信息，多個數據集市構成了數據倉庫。2.確定度量
在確定了主題以後，我們將考慮要分析的技術指標，諸如年銷售額之類。它們一般爲數值型數據。我們或者將該數據彙總，或者將該數據取次數、獨立次數或取最大最小值等，這樣的數據稱爲度量。
度量是要統計的指標，必須事先選擇恰當，基於不同的度量可以進行復雜關鍵性能指標（KPI）等的設計和計算。
3.確定事實數據粒度
在確定了度量之後，我們要考慮到該度量的彙總情況和不同維度下度量的聚合情況。考慮到度量的聚合程度不同，我們將採用“最小粒度原則”，即將度量的粒度設置到最小。
例如：假設目前的數據最小記錄到秒，即數據庫中記錄了每一秒的交易額。那麼，如果我們可以確認，在將來的分析需求中，時間只需要精確到天就可以的話，我們就可以在ETL處理過程中，按天來彙總數據，此時，數據倉庫中度量的粒度就是“天”；反過來，如果我們不能確認將來的分析需求在時間上是否需要精確到秒，那麼，我們就需要遵循“最小粒度原則”，在數據倉庫的事實表中保留每一秒的數據，以便日後對“秒”進行分析。在採用“最小粒度原則”的同時，我們不必擔心海量數據所帶來的彙總分析效率問題，因爲在後續建立多維分析模型（CUBE）的時候，我們會對數據提前進行彙總，從而保障產生分析結果的效率。關於建立多維分析模型（CUBE）的相關問題，我們將在下期欄目中予以闡述。
4.確定維度
維度是指分析的各個角度。例如我們希望按照時間，或者按照地區，或者按照產品進行分析，那麼這裏的時間、地區、產品就是相應的維度。基於不同的維度，我們可以看到各度量的彙總情況，也可以基於所有的維度進行交叉分析。這裏我們首先要確定維度的層次（Hierarchy）和級別（Level）,我們在時間維度上，按照“年-季度-月”形成了一個層次，其中“年”、“季度”、“月”成爲了這個層次的3個級別；同理，當我們建立產品維度時，我們可以將“產品大類-產品子類-產品”劃爲一個層次，其中包含“產品大類”、“產品子類”、“產品”三個級別。那麼，我們分析中所用到的這些維度，在數據倉庫中的存在形式是怎樣的呢？我們可以將3個級別設置成一張數據表中的3個字段，比如時間維度；我們也可以使用一張表，分別保存產品大類、產品子類、產品三部分數據，比如產品維度.
另外，值得一提的是，我們在建立維度表時要充分使用代理鍵。代理鍵是數值型的ID號碼,它唯一標識了每一維度成員。更重要的是，在聚合時，數值型字段的匹配、比較、JOIN效率高。同時，代理鍵對緩慢變化維度有着重要的意義，在原數據主鍵相同的情況下，它起到了對新數據與歷史數據的標識作用。
在此，我們不妨談一談維度表隨時間變化的問題，這是我們經常會遇到的情況，我們稱其爲緩慢變化維度。比如我們增加了新的產品，或者產品的ID號碼修改了，或者產品增加了一個新的屬性，此時，維度表就會被修改或者增加新的記錄行。這樣，我們在ETL的過程中，就要考慮到緩慢變化維度的處理。對於緩慢變化維度，有三種情況：
a).緩慢變化維度第一種類型：歷史數據需要修改。這種情況下，我們使用UPDATE方法來修改維度表中的數據。例如：產品的ID號碼爲123，後來發現ID號碼錯了，需要改寫成456，那麼，我們就在ETL處理時，直接修改維度表中原來的ID號碼爲456。b).緩慢變化維度第二種類型：歷史數據保留，新增數據也要保留。這時，要將原數據更新，將新數據插入，我們使用UPDATE / INSERT。比如：某一員工2005年在A部門，2006年時調到了B部門。那麼在統計2005年的數據時就應該將他定位到A部門；而在統計2006年數據時就應該定位到B部門，然後再有新的數據插入時，將按照新部門（B部門）進行處理，這樣我們的做法是將該維度成員列表加入標識列，將歷史的數據標識爲“過期”，將目前的數據標識爲“當前的”。另一種方法是將該維度打上時間戳，即將歷史數據生效的時間段作爲它的一個屬性，在與原始表匹配生成事實表時將按照時間段進行關聯，這種方法的好處是該維度成員生效時間明確。
c).緩慢變化維度第三種類型：新增數據維度成員改變了屬性。例如：某一維度成員新加入了一列，該列在歷史數據中不能基於它瀏覽，而在目前數據和將來數據中可以按照它瀏覽。那麼此時我們需要改變維度表屬性，即加入新的字段列。我們將使用存儲過程或程序生成新的維度屬性，在後續的數據中將基於新的屬性進行查看。
5.創建事實表
在確定好事實數據和維度後，我們將考慮加載事實表。
在公司的大量數據堆積如山時，我們想看看裏面究竟是什麼，結果發現裏面是一筆筆生產記錄，一筆筆交易記錄… 那麼這些記錄是我們將要建立的事實表的原始數據，即關於某一主題的事實記錄表。
我們的做法是將原始表與維度表進行關聯，生成事實表。注意在關聯時有爲空的數據時（數據源髒），需要使用外連接，連接後我們將各維度的代理鍵取出放於事實表中。事實表除了各維度代理鍵外，還有各度量數據，它將來自原始表。事實表中將存在維度代理鍵和各度量，而不應該存在描述性信息，即符合“瘦高原則”，即要求事實表數據條數儘量多（粒度最小），而描述性信息儘量少。
如果考慮到擴展，可以將事實表加一唯一標識列，以便日後擴展，例如將該事實作爲雪花型維度。不過不需要時，一般建議不用這樣做。事實數據表是數據倉庫的核心，需要精心維護。在JOIN後將得到事實數據表，一般記錄條數都比較大，我們需要爲其設置複合主鍵和索引，以實現數據的完整性和基於數據倉庫的查詢性能優化。事實數據表與維度表一起放於數據倉庫中，如果前端需要連接數據倉庫進行查詢，我們還需要建立一些相關的中間彙總表或物化視圖，以方便查詢。
說明：本文截取了原文中的一個片段，原片段名稱爲“構建企業級數據倉庫五步法”，但我認爲有些文不對題，或許改成“構建星型數據倉庫五步法”更合適。
