在從 oltp 業務資料庫向 dw 資料倉儲抽取資料的過程中，特別是第一次匯入之後的每一次增量抽取往往會遇到這樣的問題：業務資料庫中的一些資料發生了更改，到底要不要將這些變化也反映到資料倉儲中？在資料倉儲中，哪些資料應該隨之變化，哪些可以不用變化？考慮到這些變化，在資料倉儲中的維度表又應該如何設計以滿足這些需要。
很顯然在業務資料庫中資料的變化是非常自然和正常的，比如顧客的****，手機號碼等資訊可能隨著顧客的所在地的更改發生變化，比如商品的**在不同時期有**和下降的變化。那麼在業務資料庫中，很自然的就會修改並馬上反映到實際業務當中去。但是在資料倉儲中，其資料主要的特徵一是靜態歷史資料，二是少改變不刪除，三是定期增長，其作用主要用來資料分析。因此分析的過程中對歷史資料就提出了要求，有一些資料是需要能夠反映出在週期內的變化歷史，有一些資料缺不需要，那麼這些資料應該如何來控制。
假設在第一次從業務資料庫中載入了一批資料到資料倉儲中，當時業務資料庫有這樣的一條顧客的資訊。
顧客 biwork ，居住在北京，目前是一名 bi 的開發工程師。假設 biwork 因為北京空氣質素 pm2.5 等原因從北京搬到了三亞。那麼這條資訊在業務資料庫中應該被更新了 -
那麼當下次從業務資料庫中抽取這類資訊的時候，資料倉儲又應該如何處理呢？我們假設在資料倉儲中實現了與業務資料庫之間的同步，資料倉儲中也直接將詞條資料修改更新。後來我們建立報表做一些簡單的資料統計分析，這時在資料倉儲中所有對顧客 biwork 的銷售都指向了 biwork 新的所在地 - 城市三亞，但是實際上 biwork 在之前所有的購買都發生在 biwork 居住在北京的時候。這是乙個非常簡單的例子，它描述了因一些基本資訊的更改可能會引起資料歸納和分析出現的問題。但是有時，這種場景的的確確可能是存在的。
為了解決類似於這樣的問題需要了解資料倉儲中的乙個非常重要的概念 -緩慢漸變維度。
在資料倉儲中，我們可以保持業務資料和資料倉儲中的資料始終處於一致。可以在 customer 維度中使用來自業務資料庫中的 business key - customerid 來追蹤業務資料的變化，一旦發生變化那麼就將舊的業務資料覆蓋重寫。
dw 中的記錄根據業務資料庫中的 customerid 獲取了最新的 city 資訊，直接更新到 dw 中。
當然在資料倉儲中更多是對相對靜態的歷史資料進行資料的彙總和分析，因此會盡可能的維護來自業務系統中的歷史資料，能夠真正捕獲到這種歷史資料的變化。以上面的例子來說，可能需要分析的結果是 biwork 在 2023年的時候購買額度整體平穩，但是從2023年開始購買額度減少了，出現的原因可能與所在的城市有關係，在北京的門店可能比在三亞的門店相對要多一些。像這種情況，就不能很簡單在資料倉儲中將 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 就已經是整形的了，並且表中的屬性基本上不隨著時間或地理發生改變。比如像某些國家名稱，地區編號編碼等等基本上不會怎麼發生改變，即使改變了也不需要維護歷史記錄這樣的情況下可以直接使用業務資料庫中的 business key 而不需要設定新的 surrogate key。
接著上面的表結構講，光這樣設定了新的 surrogate key - dwid 是不夠的，因為還需要告訴資料倉儲哪一條資訊是現在正在使用的。當然可以根據 dwid 的順序來查出最新的記錄，但是每次都要比較 customerid 然後找出最大的 dwid 這樣的查詢比較麻煩。
因此可以額外乙個標誌表示這條資料是最新更改的。
另外的一種方式就是通過起始時間來標識，valid to 為 null 的標識當前資料。
當然，也有將兩者都綜合的。
還有一種情況就是混合使用 type 1 和 type 2 的，比如說 occupation 這個欄位在業務資料庫中發生了變化，但是可以不用維護這個歷史資訊，因此可能的做法是直接將最新的 occupation 在資料倉儲中覆蓋掉。
根據實際情況，還有一種做法就是全部覆蓋掉。
實際上 type 1 and 2 可以滿足大多數需求了，但是仍然有其它的解決方案，比如說 type 3 scd。 type 3 scd 希望只維護更少的歷史記錄，
比如說把要維護的歷史字段新增一列，然後每次只更新 current column 和 previous column。這樣，只儲存了最近兩次的歷史記錄。但是如果要維護的字段比較多，就比較麻煩，因為要更多的 current 和 previous 字段。所以 type 3 scd 用的還是沒有 type 1 和 type 2 那麼普遍。
在不同的工具中對 scd 的實現是不一樣的，比如在微軟 ssis scd 控制項的設計當中對 scd 的實現:
所以和我這裡介紹到的三種 type scd 基本型別在原型和概念實現上有一些區別，這一點希望大家不要混淆，關注的重點應該是具體的實現方式和解決思路的原型。
資料倉儲 緩慢漸變維 拉鍊表
緩慢漸變維 維度會隨著時間發生緩慢的變化。處理方式 全量快照 拉鍊表全量快照很簡單，今天我們來看看拉鍊表。拉鍊表是處理緩慢漸變維的一種方式，它區別於正常的表而言，會多兩個字段，start date和end date，代表這條資料的起始時間和結束時間。如 james同學哪天想不開了，他從男的變成了女的...
資料倉儲中，緩慢漸變維度的設計及碰到的問題
緩慢漸變維度的設計，概念其實就是通過新增兩個字段 有效開始時間，有效結束時間。設定對其某些特定列，記錄住其歷史狀態。比如拿部門表做例子，部門有其所屬的乙個部門組的關係。如下圖 我們的業務需求要求不記錄部門名稱變化，和部門組名稱的變化。所以該表中僅設定部門組no為漸變字段，僅當其內容變化時，才會產生新...
資料倉儲維度建模
雪花模型 星型模型 星座 多個事實表 問題 1 資料倉儲，不針對某乙個分析主題，而是有多個分析主題，即多個事實表，維度表怎麼設計？2 即使是同乙個分析主題，也可能存在多個事實表，維度表如何設計？多個時間維度？無論星型模型 雪花模型還是星座模型，都是針對維度上的區別而來，星座模型實質上還是星型模型，只...