首先說一下概念，緩慢變化維（Slowly Changing Dimensions）指的是：維度表里面的數據並非是始終不變的，總會隨着時間發生變化：
假設我們有一張我們公司的銷售員維度表如下，記錄了每個銷售員的一些基本信息，那么隨着時間的變化銷售員可能會在各省公司間調崗，如將周傑倫調入北京分公司，針對這種變化，業務系統會直接將業務數據庫中周傑倫的地址直接update為北京，而不會考慮歷史變化，不過在數據倉庫中由於有時我們需要進行歷史變化分析，或者防止銷售數據記錄錯誤，所以需要對這種變化進行相應的處理，主要有以下三種辦法：
1、TYPE1
與業務數據保持一直，同樣為直接update。這樣就難以記錄歷史變化，如果周傑倫於15年7月調入北京，那么我們想要知道北京銷售員在15年的銷售數據時，就會將周傑倫的業績算入北京分公司下，實際上周傑倫7月份以前的銷售數據均應算在台北，所以為了避免這樣的問題就有了TYPE2的處理方式。
2、TYPE2
保留歷史變化，如下圖：
不過帶來一個問題，當事實表中的銷售數據與此維度表進行關聯時，由於存在customer_id的數據有兩條100的，所以會關聯出兩個數據，這樣是有問題的，那么就引入了一個代理鍵的概念，相當於數據倉庫為維度表分配一個主鍵，而不用當初業務數據庫中的主鍵，如下：
不過此時又帶來了另外一個問題，當業務事實表中有新的銷售業績數據插入的時候，需要在外鍵列中插入維度表的dw_customer_id，那么此刻需要先找到維度表中的customer_id，然后再找到最大的dw_customer_id插入進去（因為主鍵往往是自增的，最大的肯定是最新的），但是某些情況下如果向事實表中插入歷史數據的情況，就無法判斷具體是哪個台北周傑倫還是北京周傑倫的業績了，所以往往在維度表中同樣加入時間列，如2000/1/1-2015/7/1來記錄周傑倫在台北，而周傑倫在北京時間字段起始為2015/7/2，末尾時間字段可以記錄空值或用9999/9/9替代，有新變化再進行更新。
3、TYPE3
有時需求中並非所有字段的變化都進行記錄並且不需要每次變化都記錄，比如我們可能只關心address（所在地）的最近兩次變化，那么可以這樣記錄：
這樣做只可以記錄少量的變化次數，需要的話也可以相應加上時間列，這種方式一般用到的比較少，多數均為TYPE1，TYPE2，根據是否有必要記錄歷史變化進行選擇。