緩慢變化維（Slowly Changing Dimension）就是變化相對緩慢（相對與快速變化的事實表來說）的維度。

在維度建模理論中，有8種處理方式，包括基礎的5種以及混合的3種。 再加上大數(shù)據(jù)時代的2種極限型，共10種

1、基礎型

1.1、類型0: 保留原始值

維度屬性值不做更改，保留原始值。
此方式什么也不做，所以稱之為方式0。

eg.比如商品上架售賣時間：一個商品上架售賣后可能由于缺貨下架，補充庫存后又再次上架，此種情況產(chǎn)生了多個商品上架售賣時間。如果重點關注的是商品首次上架售賣時間，則采用方式0。

1.2、類型1: 直接覆蓋

修改維度屬性為最新值，直接覆蓋，不保留歷史信息。

eg.比如商品屬于哪個品類：當商品品類發(fā)生變化時，直接重寫為新品類，如果業(yè)務只關心最新的品類。

1.3、類型2: 增加新行（需要增加代理鍵）

在維度表中增加新的一行，新行中采用新的屬性值。此種方式需要借助代理鍵，需要為新行分配新的代理鍵，將其作為事實表的外鍵。

采用此方式，一般會在維度行中額外增加3列：行生效時間，行失效時間以及當前行標識（或者不使用當前行標識，由行失效時間來判斷是否是當前行）

此方式及其變種是處理緩慢變化維的主要技術。

1.4、類型3: 增加新屬性列

在維度表中增加新的一列，原先屬性列存放上一版本的屬性值，當前屬性列存放當前版本的屬性值。

1.5、類型4: 增加微型維度

當某維表是一個大型維度表，采用類型2(增加新行)時，如果某些維度屬性變化相對較快，會導致該維表變得越來越大，導致存儲壓力和性能壓力。

將某些維度屬性從該大型維表中抽離出來，單獨構建RFM微型維度。并在相關事實表中增加RFM鍵作為外鍵。

類型4:微型維度

2、混合型

2.1、類型5: 微型維度與類型1支架維度

a.該方式是類型1和類型4的結合，即建立微型維度后，微型維度的主鍵不僅作為事實表的外鍵，也作為主維度的外鍵。
b.在主維度中，此微型維度屬性以類型1處理，即當該屬性發(fā)生變化時，直接覆蓋，不保留歷史信息。
c.這種情況下的微型維度被稱之為支架。

類型5: 支架維度

2.2、類型6: 將類型1屬性增加到類型2維度

此種方式復雜，在少數(shù)特定迫切的場景下才會使用。如商品的品類變化

該方式是類型1（直接覆蓋）、2（增加新行）、3（增加新列）的結合，即同時增加維度行和維度列，并以類型1(直接覆蓋)處理新加的維度列（當前屬性）。

類型6: 將類型1屬性增加到類型2維度

2.3、類型7：雙重外鍵并且類型1與類型2結合

在類型2（增加新行）的基礎上，不僅是維度的代理鍵作為事實表外鍵，維度的自然鍵（如果自然鍵會被重新分配，發(fā)生變化，應該使用持續(xù)性超自然鍵）也同時作為事實表外鍵。

事實表通過代理鍵連接維表獲取歷史維度屬性，通過自然鍵連接維表獲取當前維度屬性。

類型7：雙重外鍵并且類型1與類型2結合

3、極限型

3.1、類型8: 快照維度

此種方式比較暴力，每天保留全量維度屬性的快照數(shù)據(jù)，自然鍵及日期鍵作為事實表的外鍵。

此方式依托的是當前存儲成本遠低于計算成本，以空間換時間的理念。
如商品快照維度表

類型8: 快照維度

3.2、類型9：歷史拉鏈維度

此方式是類型2（增加新行）的閹割版，同樣是增加維度行。
但舍棄了代理鍵，因為如MapReduce之類的分布式計算引擎，維護全局唯一的代理鍵難度大，成本高。

類型9：歷史拉鏈維度

優(yōu)點是此方式相比方式8，大大降低了存儲（當然前提是不包含變化頻率很高的維度屬性，如果有，請考慮進行垂直拆分）。
缺點是和事實表連接時會有一些不足。如事實表只能以時間切片的方式和維度表進行連接，如果事實表要多個時間切片同時與維度表關聯(lián)，需要一定的技術改造。

————————————————
版權聲明：本文為CSDN博主「qq_36039236」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權協(xié)議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/qq_36039236/article/details/107819326