深入探討數據倉庫緩慢變化維的解決方案
緩慢變化維定義 Wikipedia中的定義：
Dimension is a term in data management and data warehousing that refers to logical groupings of data such as geographical location, customer information, or product information.Slowly Changing Dimensions (SCD) are dimensions that have data that slowly changes.
大意是說數據會發生緩慢變化的維度就叫”緩慢變化維”。
舉個例子就清楚了：
在一個零售業數據倉庫中，事實表保存著各銷售人員的銷售記錄，某天一個銷售人員從北京分公司調到上海分公司了，那么如何來保存這個變化呢？也就是說銷售人員維度要怎么恰當的處理這一變化。先來回答一個問題，為什么要處理，或保存這一變化？如果我們要統計北京地區或上海地區的總銷售情況的時候，這個銷售人員的銷售記錄應該算在北京還是算在上海？當然是調離前的算在北京，調離后的算在上海,但是如標記這個銷售人員所屬區域？這里就需要處理一下這個維度的數據，即我們緩慢變化維需要做的事情。
處理緩慢變化維一般按不同情況有以下幾種解決方案：
一、新數據覆蓋舊數據
此方法必須有前提條件，即你不關心這個數劇的變化。例如，某個銷售人員的英文名改了，如果你不關心員工的英文名有什么變化則可直接覆蓋(修改)數據倉庫中的數據。
二、保存多條記錄，并添加字段加以區分
這種情況下直接新添一條記錄，同時保留原有記錄，并用單獨的專用的字段保存區別。如：
(以下表格中Supplier_State表示上面例子中所屬區域，為描述清晰，不用代理鍵表示)
|
或：
|
以上兩種是添加數據版本信息或是否可用來標識新舊數據。
下面一種則是添加記錄的生效日期和失效日期來標識新舊數據：
|
空的End_Date表示當前版本數據，或者你也可一用一個默認的大時間 (如: 12/31/9999)來代替空值, 這樣數據還能被索引識別到.
三、不同字段保存不同值
|
這種方法用不同的字段保存變化痕跡.但是這種方法不能象第二種方法一樣保存所有變化記錄,它只能保存兩次變化記錄.適用于變化不超過兩次的維度。
四、另外建表保存歷史記錄
即另外建一個歷史表來表存變化的歷史記錄，而維度只保存當前數據。
|
這種方法僅僅記錄一下變化歷史痕跡，其實做起統計運算來還是不方便的。
五、混合模式
這種模式是以上幾種模式的混合體，相對而言此種方法更全面，更能應對錯綜復雜且易變化的用戶需求，也是較為常用的。
|
此中方法有以下幾條優點：
1. 能用簡單的過濾條件選出維度當前的值。
2. 能較容易的關聯出歷史任意一時刻事實數據的值。
3. 如果事實表中有一些時間字段(如：Order Date, Shipping Date, Confirmation Date)，那么我們很容易選擇哪一條維度數據進行關聯分析。
其中Row_Key和 Current Indicator字段是可有可無的，加上去更方便，畢竟維度表的數據都不大，多點冗余字段不占太大空間但能提高查詢效率。
這種設計模式下事實表應以Supplier_key為外鍵，雖然這個字段不能***標識一條維度數據，從而形成了事實表與維表多對多的關系，因此在做事實和維度做關聯時應加上時間戳字段(或Indicator字段)。
六、非常規混合模式
上面說到第五種實現方式有點弊端，那就是事實表和維表不是多對一關系，而是多對多關系，這種關系不能在建模時解決只能在報表層面，在報表運行時解決，且在BI語意層建模時需要添加時間過濾條件，比較繁瑣。
下面這種解決方案可以解決此多對多關系，但是得修改一下事實表：
|
Fact Delivery: (為描述清晰，同樣不使用代理鍵標識維度)
|
此方案中向維表中的當前數據版本號始終為0，即插入維度數據時先將老版本的數據的version_number改成1（遞增），然后再插入當前數據，此時才能保持當前數據版本號始終為0。
事實表中插入數據時所有的維度數據版本號始終全部為0。
因此此方案完全可解決事實表和維表多對多關系問題，另外還有個優點是能保證事實表和維表的參照完整性，而且我們在用ERwin,PowerDesigner等建模工具建模時，Version_Number和Supplier_key可作為復合主鍵在兩實體間建立鏈接。
【編輯推薦】
