開篇介紹
在從 OLTP 業務數據庫向 DW 數據倉庫抽取數據的過程中，特別是第一次導入之后的每一次增量抽取往往會遇到這樣的問題：業務數據庫中的一些數據發生了更改，到底要不要將這些變化也反映到數據倉庫中？在數據倉庫中，哪些數據應該隨之變化，哪些可以不用變化？考慮到這些變化，在數據倉庫中的維度表又應該如何設計以滿足這些需要。
很顯然在業務數據庫中數據的變化是非常自然和正常的，比如顧客的聯系方式，手機號碼等信息可能隨着顧客的所在地的更改發生變化，比如商品的價格在不同時期有上漲和下降的變化。那么在業務數據庫中，很自然的就會修改並馬上反映到實際業務當中去。但是在數據倉庫中，其數據主要的特征一是靜態歷史數據，二是少改變不刪除，三是定期增長，其作用主要用來數據分析。因此分析的過程中對歷史數據就提出了要求，有一些數據是需要能夠反映出在周期內的變化歷史，有一些數據缺不需要，那么這些數據應該如何來控制。
假設在第一次從業務數據庫中加載了一批數據到數據倉庫中，當時業務數據庫有這樣的一條顧客的信息。
顧客 BIWORK ，居住在北京，目前是一名 BI 的開發工程師。假設 BIWORK 因為北京空氣質量 PM2.5 等原因從北京搬到了三亞。那么這條信息在業務數據庫中應該被更新了 -
那么當下次從業務數據庫中抽取這類信息的時候，數據倉庫又應該如何處理呢？我們假設在數據倉庫中實現了與業務數據庫之間的同步，數據倉庫中也直接將詞條數據修改更新。后來我們創建報表做一些簡單的數據統計分析，這時在數據倉庫中所有對顧客 BIWORK 的銷售都指向了 BIWORK 新的所在地 - 城市三亞，但是實際上 BIWORK 在之前所有的購買都發生在 BIWORK 居住在北京的時候。這是一個非常簡單的例子，它描述了因一些基本信息的更改可能會引起數據歸納和分析出現的問題。但是有時，這種場景的的確確可能是存在的。
為了解決類似於這樣的問題需要了解數據倉庫中的一個非常重要的概念 - 緩慢漸變維度。
緩慢漸變類型一 (Type 1 SCD)
在數據倉庫中，我們可以保持業務數據和數據倉庫中的數據始終處於一致。可以在 Customer 維度中使用來自業務數據庫中的 Business Key - CustomerID 來追蹤業務數據的變化，一旦發生變化那么就將舊的業務數據覆蓋重寫。
DW 中的記錄根據業務數據庫中的 CustomerID 獲取了最新的 City 信息，直接更新到 DW 中。
緩慢漸變類型二 (Type 2 SCD)
當然在數據倉庫中更多是對相對靜態的歷史數據進行數據的匯總和分析，因此會盡可能的維護來自業務系統中的歷史數據，能夠真正捕獲到這種歷史數據的變化。以上面的例子來說，可能需要分析的結果是 BIWORK 在 2012年的時候購買額度整體平穩，但是從2013年開始購買額度減少了，出現的原因可能與所在的城市有關系，在北京的門店可能比在三亞的門店相對要多一些。像這種情況，就不能很簡單在數據倉庫中將 BIWORK 當前所在城市直接更新，而應該新增加一條數據來說明現在 BIWORK 所在地是在 Sanya。
但是如果僅僅在 DW 中新增一條新的數據仍然會出現新的問題，因為在 DW 中標識這個顧客是通過 CustomerID 來實現的，這條 CustomerID 來源於業務數據庫，它是唯一的。然而在 DW 中新增一條數據來保存業務數據庫中歷史信息，就無法保證這條數據在 DW 中的唯一性了，其它的 DW 數據表關聯到這張表就無法知道應該如何引用這個 Customer 的信息。實際上，如果 CustomerID 在 DW 中也作為主鍵來唯一標識 Customer 的話，在插入新數據的時候就會發生失敗。
因此我們需要繼續保持 Business Key 業務鍵，因為它是關聯到業務數據庫的唯一紐帶。做出改變的部分就是新增加一個 Key，一個數據倉庫的鍵。在數據倉庫的術語里面，這個唯一標識數據倉庫表記錄的鍵我們稱之為 Surrogate Key 代理鍵，通常設置為DW表的主鍵。
在上面這張表中，其中 -
CustomerID - Business Key 業務鍵，用來連接業務數據庫和數據倉庫的鍵，注意無論在業務數據庫還是數據倉庫無論任何時候都不應該發生改變。DWID - Surrogate Key 代理鍵，一般設置為 DW 維度表的主鍵，用來在數據倉庫內部中的維度表和事實表建立關聯。
為什么使用代理鍵，有什么好處？
- 假設我們的業務數據庫來自於不同的系統，對這些數據進行整合的時候有可能出現相同的 Business Key，這時通過 Surrogate Key 就可以解決這個問題。
- 一般來自業務數據庫中的 Business Key 可能字段較長，比如 GUID，長字符串標識等，使用Surrogate Key 可以直接設置成整形的。事實表本身體積就很大，關聯 Surrogate Key 與關聯 Business Key 相比，Surrogate Key 效率更高，並且節省事實表體積。
- 最重要的一點就是上面舉到的這個例子，使用 Surrogate Key 可以更好的解決這種緩慢漸變維度，維護歷史信息記錄。
什么時候可以不用代理鍵？我覺得可以結合我們的實際業務，比如像有些業務表本身的 Business Key 就已經是整形的了，並且表中的屬性基本上不隨着時間或地理發生改變。比如像某些國家名稱，地區編號編碼等等基本上不會怎么發生改變，即使改變了也不需要維護歷史記錄這樣的情況下可以直接使用業務數據庫中的 Business Key 而不需要設置新的 Surrogate Key。
接着上面的表結構講，光這樣設置了新的 Surrogate Key - DWID 是不夠的，因為還需要告訴數據倉庫哪一條信息是現在正在使用的。當然可以根據 DWID 的順序來查出最新的記錄，但是每次都要比較 CustomerID 然后找出最大的 DWID 這樣的查詢比較麻煩。
因此可以額外一個標志表示這條數據是最新更改的。
另外的一種方式就是通過起始時間來標識，Valid To 為 NULL 的標識當前數據。
當然，也有將兩者都綜合的。
還有一種情況就是混合使用 Type 1 和 Type 2 的，比如說 Occupation 這個字段在業務數據庫中發生了變化，但是可以不用維護這個歷史信息，因此可能的做法是直接將最新的 Occupation 在數據倉庫中覆蓋掉。
根據實際情況，還有一種做法就是全部覆蓋掉。
緩慢漸變類型三 (Type 3 SCD)
實際上 Type 1 and 2 可以滿足大多數需求了，但是仍然有其它的解決方案，比如說 Type 3 SCD。 Type 3 SCD 希望只維護更少的歷史記錄，
比如說把要維護的歷史字段新增一列，然后每次只更新 Current Column 和 Previous Column。這樣，只保存了最近兩次的歷史記錄。但是如果要維護的字段比較多，就比較麻煩，因為要更多的 Current 和 Previous 字段。所以 Type 3 SCD 用的還是沒有 Type 1 和 Type 2 那么普遍。
總結
- Type 1 SCD - 不記錄歷史數據。一切不需要維護的歷史數據都可以選擇 Type 1 ，假設地理信息中的國家名稱發生更改，像這種數據基本上不需要維護的話，那么就直接使用 Type 1 SCD 覆蓋舊的國家名稱。
- Type 2 SCD - 添加新的數據。使用的比較常見，基本上除了 Type 1 SCD 之外的情形都會優先考慮 Type 2 SCD。
- Type 3 SCD - 添加歷史列。不會追蹤所有的歷史記錄，只會追蹤上一次的歷史信息。這種情況往往介於 Type 1 和 Type 2 的時候會考慮，需要記錄歷史數據，但是又不需要記錄那么多。
其它的相關文章
- 關於在 SSIS 中如何實現 SCD 請參看 微軟BI SSIS 系列 - 數據倉庫中實現 Slowly Changing Dimension 緩慢漸變維度的三種方式
PS
在不同的工具中對 SCD 的實現是不一樣的，比如在微軟 SSIS SCD 控件的設計當中對 SCD 的實現:
- Type 0 - Fixed Attribute 不變化的屬性。
- Type 1 - Changing Attribute 可變化的屬性，會重寫數據。
- Type 2 - Historical Attribute 歷史屬性。
所以和我這里介紹到的三種 Type SCD 基本類型在原型和概念實現上有一些區別，這一點希望大家不要混淆，關注的重點應該是具體的實現方式和解決思路的原型。
更多 BI 文章請參看 BI 系列隨筆列表 (SSIS, SSRS, SSAS, MDX, SQL Server) 如果覺得這篇文章看了對您有幫助，請幫助推薦，以方便他人在 BIWORK 博客推薦欄中快速看到這些文章。