原文鏈接:https://www.cnblogs.com/biwork/p/3363749.html
假設(shè)在第一次從業(yè)務(wù)數(shù)據(jù)庫(kù)中加載了一批數(shù)據(jù)到數(shù)據(jù)倉(cāng)庫(kù)中抱虐，當(dāng)時(shí)業(yè)務(wù)數(shù)據(jù)庫(kù)有這樣的一條顧客的信息闰挡。
顧客 BIWORK 惜傲，居住在北京逐哈，目前是一名 BI 的開(kāi)發(fā)工程師促绵。假設(shè) BIWORK 因?yàn)楸本┛諝赓|(zhì)量 PM2.5 等原因從北京搬到了三亞缓艳。那么這條信息在業(yè)務(wù)數(shù)據(jù)庫(kù)中應(yīng)該被更新了 -
那么當(dāng)下次從業(yè)務(wù)數(shù)據(jù)庫(kù)中抽取這類(lèi)信息的時(shí)候，數(shù)據(jù)倉(cāng)庫(kù)又應(yīng)該如何處理呢芳撒？我們假設(shè)在數(shù)據(jù)倉(cāng)庫(kù)中實(shí)現(xiàn)了與業(yè)務(wù)數(shù)據(jù)庫(kù)之間的同步邓深，數(shù)據(jù)倉(cāng)庫(kù)中也直接將詞條數(shù)據(jù)修改更新。后來(lái)我們創(chuàng)建報(bào)表做一些簡(jiǎn)單的數(shù)據(jù)統(tǒng)計(jì)分析笔刹，這時(shí)在數(shù)據(jù)倉(cāng)庫(kù)中所有對(duì)顧客 BIWORK 的銷(xiāo)售都指向了 BIWORK 新的所在地 - 城市三亞芥备，但是實(shí)際上 BIWORK 在之前所有的購(gòu)買(mǎi)都發(fā)生在 BIWORK 居住在北京的時(shí)候。這是一個(gè)非常簡(jiǎn)單的例子舌菜，它描述了因一些基本信息的更改可能會(huì)引起數(shù)據(jù)歸納和分析出現(xiàn)的問(wèn)題萌壳。但是有時(shí)，這種場(chǎng)景的的確確可能是存在的酷师。
為了解決類(lèi)似于這樣的問(wèn)題需要了解數(shù)據(jù)倉(cāng)庫(kù)中的一個(gè)非常重要的概念 - 緩慢漸變維度讶凉。
緩慢漸變類(lèi)型一 (Type 1 SCD)
在數(shù)據(jù)倉(cāng)庫(kù)中染乌，我們可以保持業(yè)務(wù)數(shù)據(jù)和數(shù)據(jù)倉(cāng)庫(kù)中的數(shù)據(jù)始終處于一致山孔。可以在 Customer 維度中使用來(lái)自業(yè)務(wù)數(shù)據(jù)庫(kù)中的 Business Key - CustomerID 來(lái)追蹤業(yè)務(wù)數(shù)據(jù)的變化荷憋，一旦發(fā)生變化那么就將舊的業(yè)務(wù)數(shù)據(jù)覆蓋重寫(xiě)台颠。
DW 中的記錄根據(jù)業(yè)務(wù)數(shù)據(jù)庫(kù)中的 CustomerID 獲取了最新的 City 信息，直接更新到 DW 中。
緩慢漸變類(lèi)型二 (Type 2 SCD)
當(dāng)然在數(shù)據(jù)倉(cāng)庫(kù)中更多是對(duì)相對(duì)靜態(tài)的歷史數(shù)據(jù)進(jìn)行數(shù)據(jù)的匯總和分析串前，因此會(huì)盡可能的維護(hù)來(lái)自業(yè)務(wù)系統(tǒng)中的歷史數(shù)據(jù)瘫里，能夠真正捕獲到這種歷史數(shù)據(jù)的變化。以上面的例子來(lái)說(shuō)荡碾，可能需要分析的結(jié)果是 BIWORK 在 2012年的時(shí)候購(gòu)買(mǎi)額度整體平穩(wěn)谨读，但是從2013年開(kāi)始購(gòu)買(mǎi)額度減少了，出現(xiàn)的原因可能與所在的城市有關(guān)系坛吁，在北京的門(mén)店可能比在三亞的門(mén)店相對(duì)要多一些劳殖。像這種情況，就不能很簡(jiǎn)單在數(shù)據(jù)倉(cāng)庫(kù)中將 BIWORK 當(dāng)前所在城市直接更新拨脉，而應(yīng)該新增加一條數(shù)據(jù)來(lái)說(shuō)明現(xiàn)在 BIWORK 所在地是在 Sanya哆姻。
但是如果僅僅在 DW 中新增一條新的數(shù)據(jù)仍然會(huì)出現(xiàn)新的問(wèn)題，因?yàn)樵?DW 中標(biāo)識(shí)這個(gè)顧客是通過(guò) CustomerID 來(lái)實(shí)現(xiàn)的玫膀，這條 CustomerID 來(lái)源于業(yè)務(wù)數(shù)據(jù)庫(kù)矛缨，它是唯一的。然而在 DW 中新增一條數(shù)據(jù)來(lái)保存業(yè)務(wù)數(shù)據(jù)庫(kù)中歷史信息帖旨，就無(wú)法保證這條數(shù)據(jù)在 DW 中的唯一性了箕昭，其它的 DW 數(shù)據(jù)表關(guān)聯(lián)到這張表就無(wú)法知道應(yīng)該如何引用這個(gè) Customer 的信息。實(shí)際上碉就，如果 CustomerID 在 DW 中也作為主鍵來(lái)唯一標(biāo)識(shí) Customer 的話盟广，在插入新數(shù)據(jù)的時(shí)候就會(huì)發(fā)生失敗。
因此我們需要繼續(xù)保持 Business Key 業(yè)務(wù)鍵瓮钥，因?yàn)樗顷P(guān)聯(lián)到業(yè)務(wù)數(shù)據(jù)庫(kù)的唯一紐帶筋量。做出改變的部分就是新增加一個(gè) Key，一個(gè)數(shù)據(jù)倉(cāng)庫(kù)的鍵碉熄。在數(shù)據(jù)倉(cāng)庫(kù)的術(shù)語(yǔ)里面桨武，這個(gè)唯一標(biāo)識(shí)數(shù)據(jù)倉(cāng)庫(kù)表記錄的鍵我們稱之為 Surrogate Key 代理鍵，通常設(shè)置為DW表的主鍵锈津。
在上面這張表中呀酸，其中 -
CustomerID - Business Key 業(yè)務(wù)鍵，用來(lái)連接業(yè)務(wù)數(shù)據(jù)庫(kù)和數(shù)據(jù)倉(cāng)庫(kù)的鍵琼梆，注意無(wú)論在業(yè)務(wù)數(shù)據(jù)庫(kù)還是數(shù)據(jù)倉(cāng)庫(kù)無(wú)論任何時(shí)候都不應(yīng)該發(fā)生改變性誉。DWID - Surrogate Key 代理鍵，一般設(shè)置為 DW 維度表的主鍵茎杂，用來(lái)在數(shù)據(jù)倉(cāng)庫(kù)內(nèi)部中的維度表和事實(shí)表建立關(guān)聯(lián)错览。
為什么使用代理鍵，有什么好處煌往？
- 假設(shè)我們的業(yè)務(wù)數(shù)據(jù)庫(kù)來(lái)自于不同的系統(tǒng)倾哺，對(duì)這些數(shù)據(jù)進(jìn)行整合的時(shí)候有可能出現(xiàn)相同的 Business Key，這時(shí)通過(guò) Surrogate Key 就可以解決這個(gè)問(wèn)題。
- 一般來(lái)自業(yè)務(wù)數(shù)據(jù)庫(kù)中的 Business Key 可能字段較長(zhǎng)羞海，比如 GUID忌愚，長(zhǎng)字符串標(biāo)識(shí)等，使用Surrogate Key 可以直接設(shè)置成整形的却邓。事實(shí)表本身體積就很大硕糊，關(guān)聯(lián) Surrogate Key 與關(guān)聯(lián) Business Key 相比，Surrogate Key 效率更高腊徙，并且節(jié)省事實(shí)表體積癌幕。
- 最重要的一點(diǎn)就是上面舉到的這個(gè)例子，使用 Surrogate Key 可以更好的解決這種緩慢漸變維度昧穿，維護(hù)歷史信息記錄勺远。
什么時(shí)候可以不用代理鍵？我覺(jué)得可以結(jié)合我們的實(shí)際業(yè)務(wù)时鸵，比如像有些業(yè)務(wù)表本身的 Business Key 就已經(jīng)是整形的了胶逢，并且表中的屬性基本上不隨著時(shí)間或地理發(fā)生改變。比如像某些國(guó)家名稱饰潜，地區(qū)編號(hào)編碼等等基本上不會(huì)怎么發(fā)生改變初坠，即使改變了也不需要維護(hù)歷史記錄這樣的情況下可以直接使用業(yè)務(wù)數(shù)據(jù)庫(kù)中的 Business Key 而不需要設(shè)置新的 Surrogate Key。
接著上面的表結(jié)構(gòu)講彭雾，光這樣設(shè)置了新的 Surrogate Key - DWID 是不夠的碟刺，因?yàn)檫€需要告訴數(shù)據(jù)倉(cāng)庫(kù)哪一條信息是現(xiàn)在正在使用的。當(dāng)然可以根據(jù) DWID 的順序來(lái)查出最新的記錄薯酝，但是每次都要比較 CustomerID 然后找出最大的 DWID 這樣的查詢比較麻煩半沽。
因此可以額外一個(gè)標(biāo)志表示這條數(shù)據(jù)是最新更改的。
另外的一種方式就是通過(guò)起始時(shí)間來(lái)標(biāo)識(shí)吴菠，Valid To 為 NULL 的標(biāo)識(shí)當(dāng)前數(shù)據(jù)者填。
當(dāng)然，也有將兩者都綜合的做葵。
還有一種情況就是混合使用 Type 1 和 Type 2 的占哟，比如說(shuō) Occupation 這個(gè)字段在業(yè)務(wù)數(shù)據(jù)庫(kù)中發(fā)生了變化，但是可以不用維護(hù)這個(gè)歷史信息酿矢，因此可能的做法是直接將最新的 Occupation 在數(shù)據(jù)倉(cāng)庫(kù)中覆蓋掉榨乎。
根據(jù)實(shí)際情況，還有一種做法就是全部覆蓋掉瘫筐。
緩慢漸變類(lèi)型三 (Type 3 SCD)
實(shí)際上 Type 1 and 2 可以滿足大多數(shù)需求了蜜暑，但是仍然有其它的解決方案，比如說(shuō) Type 3 SCD严肪。 Type 3 SCD 希望只維護(hù)更少的歷史記錄史煎，
比如說(shuō)把要維護(hù)的歷史字段新增一列，然后每次只更新 Current Column 和 Previous Column驳糯。這樣篇梭，只保存了最近兩次的歷史記錄。但是如果要維護(hù)的字段比較多酝枢，就比較麻煩恬偷，因?yàn)橐嗟?Current 和 Previous 字段。所以 Type 3 SCD 用的還是沒(méi)有 Type 1 和 Type 2 那么普遍帘睦。
總結(jié)
- Type 1 SCD - 不記錄歷史數(shù)據(jù)袍患。一切不需要維護(hù)的歷史數(shù)據(jù)都可以選擇 Type 1 ，假設(shè)地理信息中的國(guó)家名稱發(fā)生更改竣付，像這種數(shù)據(jù)基本上不需要維護(hù)的話诡延，那么就直接使用 Type 1 SCD 覆蓋舊的國(guó)家名稱。
- Type 2 SCD - 添加新的數(shù)據(jù)古胆。使用的比較常見(jiàn)肆良，基本上除了 Type 1 SCD 之外的情形都會(huì)優(yōu)先考慮 Type 2 SCD。
- Type 3 SCD - 添加歷史列逸绎。不會(huì)追蹤所有的歷史記錄惹恃，只會(huì)追蹤上一次的歷史信息。這種情況往往介于 Type 1 和 Type 2 的時(shí)候會(huì)考慮棺牧，需要記錄歷史數(shù)據(jù)巫糙，但是又不需要記錄那么多。
