關于緩慢變化次元 slowly changing dimensions

次元模組化的資料倉庫中，有一個概念叫Slowly Changing Dimensions，中文一般翻譯成“緩慢變化維”，經常被簡寫為SCD。緩慢變化維的提出是因為在現實世界中，次元的屬性并不是靜态的，它會随着時間的流失發生緩慢的變化。這種随時間發生變化的次元我們一般稱之為緩慢變化維，并且把處理次元表的曆史變化資訊的問題稱為處理緩慢變化維的問題，有時也簡稱為處理SCD的問題。本文則是探讨資料倉庫緩慢變化維的方案解決。

　　緩慢變化維定義 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表示上面例子中所屬區域，為描述清晰，不用代理鍵表示)

Supplier_key Supplier_Code Supplier_Name Supplier_State Disable
 001 ABC Phlogistical Supply Company CA Y
 002 ABC Phlogistical Supply Company IL N

　　或：

Supplier_key Supplier_Code Supplier_Name Supplier_State Version
 001 ABC Phlogistical Supply Company CA 0
 002 ABC Phlogistical Supply Company IL 1

　　以上兩種是添加資料版本資訊或是否可用來辨別新舊資料。

　　下面一種則是添加記錄的生效日期和失效日期來辨別新舊資料：

Supplier_key Supplier_Code Supplier_Name Supplier_State Start_Date End_Date
 001 ABC Phlogistical Supply Company CA 01-Jan-2000 21-Dec-2004
 002 ABC Phlogistical Supply Company IL 22-Dec-2004

　　空的End_Date表示目前版本資料，或者你也可一用一個預設的大時間 (如: 12/31/9999)來代替空值, 這樣資料還能被索引識别到.

　　三、不同字段儲存不同值

Supplier_key Supplier_Name Original_Supplier_State Effective_Date Current_Supplier_State
 001 Phlogistical Supply Company CA 22-Dec-2004 IL

　　這種方法用不同的字段儲存變化痕迹.但是這種方法不能象第二種方法一樣儲存所有變化記錄,它隻能儲存兩次變化記錄.适用于變化不超過兩次的次元。

　　四、另外建表儲存曆史記錄

　　即另外建一個曆史表來表存變化的曆史記錄，而次元隻儲存目前資料。

Supplier:
 Supplier_key Supplier_Name Supplier_State
 001 Phlogistical Supply Company IL
 Supplier_History:
 Supplier_key Supplier_Name Supplier_State Create_Date
 001 Phlogistical Supply Company CA 22-Dec-2004

　　這種方法僅僅記錄一下變化曆史痕迹，其實做起統計運算來還是不友善的。

　　五、混合模式

　　這種模式是以上幾種模式的混合體，相對而言此種方法更全面，更能應對錯綜複雜且易變化的使用者需求，也是較為常用的。

Row_Key Supplier_key Supplier_Code Supplier_Name Supplier_State Start_Date End_Date
 Current Indicator
 1 001 ABC001 Phlogistical Supply Company CA 22-Dec-2004 15-Jan-2007 N
 2 001 ABC001 Phlogistical Supply Company IL 15-Jan-2007 1-Jan-2099 Y

　　此中方法有以下幾條優點：

　　1. 能用簡單的過濾條件選出次元目前的值。

　　2. 能較容易的關聯出曆史任意一時刻事實資料的值。

　　3. 如果事實表中有一些時間字段(如：Order Date, Shipping Date, Confirmation Date)，那麼我們很容易選擇哪一條次元資料進行關聯分析。

　　其中Row_Key和 Current Indicator字段是可有可無的，加上去更友善，畢竟次元表的資料都不大，多點備援字段不占太大空間但能提高查詢效率。

　　這種設計模式下事實表應以Supplier_key為外鍵，雖然這個字段不能唯一辨別一條次元資料，進而形成了事實表與維表多對多的關系，是以在做事實和次元做關聯時應加上時間戳字段(或Indicator字段)。

　　六、非正常混合模式

　　上面說到第五種實作方式有點弊端，那就是事實表和維表不是多對一關系，而是多對多關系，這種關系不能在模組化時解決隻能在報表層面，在報表運作時解決，且在BI語意層模組化時需要添加時間過濾條件，比較繁瑣。

　　下面這種解決方案可以解決此多對多關系，但是得修改一下事實表：

Supplier Dimension:
 Version_Number Supplier_key Supplier_Code Supplier_Name Supplier_State Start_Date End_Date
 1 001 ABC001 Phlogistical Supply Company CA 22-Dec-2004 15-Jan-2007
 0 001 ABC001 Phlogistical Supply Company IL 15-Jan-2007 1-Jan-2099

　　Fact Delivery: (為描述清晰，同樣不使用代理鍵辨別次元)

Delivery_Key Supplier_key Supplier_version_number Quantity Product Delivery_Date Order_Date
 1 001 0 132 Bags 22-Dec-2006 15-Oct-2006
 2 001 0 324 Chairs 15-Jan-2007 1-Jan-2007

　　此方案中向維表中的目前資料版本号始終為0，即插入次元資料時先将老版本的資料的version_number改成1（遞增），然後再插入目前資料，此時才能保持目前資料版本号始終為0。

　　事實表中插入資料時所有的次元資料版本号始終全部為0。

　　是以此方案完全可解決事實表和維表多對多關系問題，另外還有個優點是能保證事實表和維表的參照完整性，而且我們在用ERwin,PowerDesigner等模組化工具模組化時，Version_Number和Supplier_key可作為複合主鍵在兩實體間建立連結。