目錄(?)[+]

在從 OLTP 業(yè)務(wù)數(shù)據(jù)庫向 DW 數(shù)據(jù)倉庫抽取數(shù)據(jù)的過程中，特別是第一次導(dǎo)入之后的每一次增量抽取往往會遇到這樣的問題：業(yè)務(wù)數(shù)據(jù)庫中的一些數(shù)據(jù)發(fā)生了更改，到底要不要將這些變化也反映到數(shù)據(jù)倉庫中？在數(shù)據(jù)倉庫中，哪些數(shù)據(jù)應(yīng)該隨之變化，哪些可以不用變化？考慮到這些變化，在數(shù)據(jù)倉庫中的維度表又應(yīng)該如何設(shè)計(jì)以滿足這些需要。

很顯然在業(yè)務(wù)數(shù)據(jù)庫中數(shù)據(jù)的變化是非常自然和正常的，比如顧客的聯(lián)系方式，手機(jī)號碼等信息可能隨著顧客的所在地的更改發(fā)生變化，比如商品的價格在不同時期有上漲和下降的變化。那么在業(yè)務(wù)數(shù)據(jù)庫中，很自然的就會修改并馬上反映到實(shí)際業(yè)務(wù)當(dāng)中去。但是在數(shù)據(jù)倉庫中，其數(shù)據(jù)主要的特征一是靜態(tài)歷史數(shù)據(jù)，二是少改變不刪除，三是定期增長，其作用主要用來數(shù)據(jù)分析。因此分析的過程中對歷史數(shù)據(jù)就提出了要求，有一些數(shù)據(jù)是需要能夠反映出在周期內(nèi)的變化歷史，有一些數(shù)據(jù)缺不需要，那么這些數(shù)據(jù)應(yīng)該如何來控制。

假設(shè)在第一次從業(yè)務(wù)數(shù)據(jù)庫中加載了一批數(shù)據(jù)到數(shù)據(jù)倉庫中，當(dāng)時業(yè)務(wù)數(shù)據(jù)庫有這樣的一條顧客的信息。

顧客 BIWORK ，居住在北京，目前是一名 BI 的開發(fā)工程師。假設(shè) BIWORK 因?yàn)楸本┛諝赓|(zhì)量 PM2.5 等原因從北京搬到了三亞。那么這條信息在業(yè)務(wù)數(shù)據(jù)庫中應(yīng)該被更新了 -

那么當(dāng)下次從業(yè)務(wù)數(shù)據(jù)庫中抽取這類信息的時候，數(shù)據(jù)倉庫又應(yīng)該如何處理呢？我們假設(shè)在數(shù)據(jù)倉庫中實(shí)現(xiàn)了與業(yè)務(wù)數(shù)據(jù)庫之間的同步，數(shù)據(jù)倉庫中也直接將詞條數(shù)據(jù)修改更新。后來我們創(chuàng)建報(bào)表做一些簡單的數(shù)據(jù)統(tǒng)計(jì)分析，這時在數(shù)據(jù)倉庫中所有對顧客 BIWORK 的銷售都指向了 BIWORK 新的所在地 - 城市三亞，但是實(shí)際上 BIWORK 在之前所有的購買都發(fā)生在 BIWORK 居住在北京的時候。這是一個非常簡單的例子，它描述了因一些基本信息的更改可能會引起數(shù)據(jù)歸納和分析出現(xiàn)的問題。但是有時，這種場景的的確確可能是存在的。

為了解決類似于這樣的問題需要了解數(shù)據(jù)倉庫中的一個非常重要的概念 - 緩慢漸變維度。

緩慢漸變類型一 (Type 1 SCD)

在數(shù)據(jù)倉庫中，我們可以保持業(yè)務(wù)數(shù)據(jù)和數(shù)據(jù)倉庫中的數(shù)據(jù)始終處于一致。可以在 Customer 維度中使用來自業(yè)務(wù)數(shù)據(jù)庫中的 Business Key - CustomerID 來追蹤業(yè)務(wù)數(shù)據(jù)的變化，一旦發(fā)生變化那么就將舊的業(yè)務(wù)數(shù)據(jù)覆蓋重寫。

DW 中的記錄根據(jù)業(yè)務(wù)數(shù)據(jù)庫中的 CustomerID 獲取了最新的 City 信息，直接更新到 DW 中。

緩慢漸變類型二 (Type 2 SCD)

當(dāng)然在數(shù)據(jù)倉庫中更多是對相對靜態(tài)的歷史數(shù)據(jù)進(jìn)行數(shù)據(jù)的匯總和分析，因此會盡可能的維護(hù)來自業(yè)務(wù)系統(tǒng)中的歷史數(shù)據(jù)，能夠真正捕獲到這種歷史數(shù)據(jù)的變化。以上面的例子來說，可能需要分析的結(jié)果是 BIWORK 在 2012年的時候購買額度整體平穩(wěn)，但是從2013年開始購買額度減少了，出現(xiàn)的原因可能與所在的城市有關(guān)系，在北京的門店可能比在三亞的門店相對要多一些。像這種情況，就不能很簡單在數(shù)據(jù)倉庫中將 BIWORK 當(dāng)前所在城市直接更新，而應(yīng)該新增加一條數(shù)據(jù)來說明現(xiàn)在 BIWORK 所在地是在 Sanya。

但是如果僅僅在 DW 中新增一條新的數(shù)據(jù)仍然會出現(xiàn)新的問題，因?yàn)樵?nbsp;DW 中標(biāo)識這個顧客是通過 CustomerID 來實(shí)現(xiàn)的，這條 CustomerID 來源于業(yè)務(wù)數(shù)據(jù)庫，它是唯一的。然而在 DW 中新增一條數(shù)據(jù)來保存業(yè)務(wù)數(shù)據(jù)庫中歷史信息，就無法保證這條數(shù)據(jù)在 DW 中的唯一性了，其它的 DW 數(shù)據(jù)表關(guān)聯(lián)到這張表就無法知道應(yīng)該如何引用這個 Customer 的信息。實(shí)際上，如果 CustomerID 在 DW 中也作為主鍵來唯一標(biāo)識 Customer 的話，在插入新數(shù)據(jù)的時候就會發(fā)生失敗。

因此我們需要繼續(xù)保持 Business Key 業(yè)務(wù)鍵，因?yàn)樗顷P(guān)聯(lián)到業(yè)務(wù)數(shù)據(jù)庫的唯一紐帶。做出改變的部分就是新增加一個 Key，一個數(shù)據(jù)倉庫的鍵。在數(shù)據(jù)倉庫的術(shù)語里面，這個唯一標(biāo)識數(shù)據(jù)倉庫表記錄的鍵我們稱之為 Surrogate Key 代理鍵，通常設(shè)置為DW表的主鍵。

在上面這張表中，其中 -

CustomerID - Business Key 業(yè)務(wù)鍵，用來連接業(yè)務(wù)數(shù)據(jù)庫和數(shù)據(jù)倉庫的鍵，注意無論在業(yè)務(wù)數(shù)據(jù)庫還是數(shù)據(jù)倉庫無論任何時候都不應(yīng)該發(fā)生改變。DWID - Surrogate Key 代理鍵，一般設(shè)置為 DW 維度表的主鍵，用來在數(shù)據(jù)倉庫內(nèi)部中的維度表和事實(shí)表建立關(guān)聯(lián)。

為什么使用代理鍵，有什么好處？

什么時候可以不用代理鍵？我覺得可以結(jié)合我們的實(shí)際業(yè)務(wù)，比如像有些業(yè)務(wù)表本身的 Business Key 就已經(jīng)是整形的了，并且表中的屬性基本上不隨著時間或地理發(fā)生改變。比如像某些國家名稱，地區(qū)編號編碼等等基本上不會怎么發(fā)生改變，即使改變了也不需要維護(hù)歷史記錄這樣的情況下可以直接使用業(yè)務(wù)數(shù)據(jù)庫中的 Business Key 而不需要設(shè)置新的 Surrogate Key。

接著上面的表結(jié)構(gòu)講，光這樣設(shè)置了新的 Surrogate Key - DWID 是不夠的，因?yàn)檫€需要告訴數(shù)據(jù)倉庫哪一條信息是現(xiàn)在正在使用的。當(dāng)然可以根據(jù) DWID 的順序來查出最新的記錄，但是每次都要比較 CustomerID 然后找出最大的 DWID 這樣的查詢比較麻煩。

因此可以額外一個標(biāo)志表示這條數(shù)據(jù)是最新更改的。

另外的一種方式就是通過起始時間來標(biāo)識，Valid To 為 NULL 的標(biāo)識當(dāng)前數(shù)據(jù)。

當(dāng)然，也有將兩者都綜合的。

還有一種情況就是混合使用 Type 1 和 Type 2 的，比如說 Occupation 這個字段在業(yè)務(wù)數(shù)據(jù)庫中發(fā)生了變化，但是可以不用維護(hù)這個歷史信息，因此可能的做法是直接將最新的 Occupation 在數(shù)據(jù)倉庫中覆蓋掉。

根據(jù)實(shí)際情況，還有一種做法就是全部覆蓋掉。

緩慢漸變類型三 (Type 3 SCD)

實(shí)際上 Type 1 and 2 可以滿足大多數(shù)需求了，但是仍然有其它的解決方案，比如說 Type 3 SCD。 Type 3 SCD 希望只維護(hù)更少的歷史記錄，

比如說把要維護(hù)的歷史字段新增一列，然后每次只更新 Current Column 和 PRevious Column。這樣，只保存了最近兩次的歷史記錄。但是如果要維護(hù)的字段比較多，就比較麻煩，因?yàn)橐嗟?nbsp;Current 和 Previous 字段。所以 Type 3 SCD 用的還是沒有 Type 1 和 Type 2 那么普遍。

總結(jié)

其它的相關(guān)文章

PS 說明

在不同的工具中對 SCD 的實(shí)現(xiàn)是不一樣的，比如在微軟 SSIS SCD 控件的設(shè)計(jì)當(dāng)中對 SCD 的實(shí)現(xiàn)包括 Kimball 的書等等 :

所以和我這里介紹到的三種 Type SCD 基本類型在原型和概念實(shí)現(xiàn)上有一些區(qū)別，這一點(diǎn)希望大家不要混淆，關(guān)注的重點(diǎn)應(yīng)該是具體的實(shí)現(xiàn)方式和解決思路的原型。