緩慢變化維解決方案
緩慢變化維解決方案
緩慢變化維解決方案 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 | |
| 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)來代替空值, 這樣資料還能被索引識别到.
混合模式：這種模式是以上幾種模式的混合體，相對而言此種方法更全面，更能應對錯綜複雜且易變化的使用者需求，也是較為常用的。
| 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 |
此種方法有以下幾條優點：
- 能用簡單的過濾條件選出次元目前的值。
- 能較容易的關聯出曆史任意一時刻事實資料的值。
- 如果事實表中有一些時間字段(如：Order Date, Shipping Date, Confirmation Date)，那麼我們很容易選擇哪一條次元資料進行關聯分析。
其中
Row_Key和
Current Indicator字段是可有可無的，加上去更友善，畢竟次元表的資料都不大，多點備援字段不占太大空間但能提高查詢效率。
這種設計模式下事實表應以
Supplier_key為外鍵，雖然這個字段不能唯一辨別一條次元資料，進而形成了事實表與維表多對多的關系，是以在做事實和次元做關聯時應加上時間戳字段(或
Indicator字段)。
三. 不同字段儲存不同值
這種方法用不同的字段儲存變化痕迹，但是不能象第二種方法一樣儲存所有變化記錄,它隻能儲存兩次變化記錄.适用于變化不超過兩次的次元。
| 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_key | Supplier_Name | Supplier_State | Create_Date |
| 001 | Phlogistical Supply Company | CA | 22-Dec-2004 |
這種方法僅僅記錄一下變化曆史痕迹，其實做起統計運算來還是不友善的。
五. 保證事實表和維表的參照完整性
次元表如果儲存多條記錄，事實表需要做相應處理，來保證參照完整性
方案一 : 複合主鍵參照次元表
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 |
| 001 | ABC001 | Phlogistical Supply Company | IL | 15-Jan-2007 | 1-Jan-2099 |
(為描述清晰，同樣不使用代理鍵辨別次元)
| Delivery_Key | Supplier_key | Supplier_version_number | Quantity | Product | Delivery_Date | Order_Date |
| 1 | 001 | 132 | Bags | 22-Dec-2006 | 15-Oct-2006 | |
| 2 | 001 | 324 | Chairs | 15-Jan-2007 | 1-Jan-2007 |
Version_Number和Supplier_key可作為複合主鍵在兩實體間建立連結，可解決事實表和維表多對多關系問題
方案二：在事實表參照次元表的代理鍵，解決參照完整性
Supplier Dimension:| Surrogate_key | Version_Number | Supplier_key | Supplier_Code | Supplier_Name | Supplier_State | Start_Date | End_Date |
| 1 | 1 | 001 | ABC001 | Phlogistical Supply Company | CA | 22-Dec-2004 | 15-Jan-2007 |
| 2 | 001 | ABC001 | Phlogistical Supply Company | IL | 15-Jan-2007 | 1-Jan-2099 |
| Delivery_Key | Supplier _Surrogate_key | Quantity | Product | Delivery_Date | Order_Date |
| 1 | 1 | 132 | Bags | 22-Dec-2006 | 15-Oct-2006 |
| 2 | 1 | 324 | Chairs | 15-Jan-2007 | 1-Jan-2007 |