顧名思義，緩慢變化維（Slowly Changing Dimension）就是變化相對緩慢（相對與快速變化的事實表來說）的維度。
在維度建模理論中，有8種處理方式，包括基礎的5種以及混合的3種。
再加上大數據時代的2種極限型，共10種，具體如下：
1 基礎型
1.1 方式0：保留原始值
維度屬性值不做更改，保留原始值。
此方式什麼也不做，所以稱之爲方式0。
- 比如商品上架售賣時間：一個商品上架售賣後可能由於缺貨下架，補充庫存後又再次上架，此種情況產生了多個商品上架售賣時間。如果重點關注的是商品首次上架售賣時間，則採用方式0。
- 比如商品所屬供應商：a商品的供應渠道是某供應商，隨着時間推移可能轉款到b供應商（由b供應商來供貨），此種情況如果關注的是原始最初供應的供應商，則採用方式0。
1.2 方式1：直接覆蓋
修改維度屬性爲最新值，直接覆蓋，不保留歷史信息。
- 比如商品屬於哪個品類：當商品品類發生變化時，直接重寫爲新品類，如果業務只關心最新的品類。
1.3 方式2：增加新行
在維度表中增加新的一行，新行中採用新的屬性值。此種方式需要藉助代理鍵，需要爲新行分配新的代理鍵，將其作爲事實表的外鍵。
採用此方式，一般會在維度行中額外增加3列：行生效時間，行失效時間以及當前行標識（或者不使用當前行標識，由行失效時間來判斷是否是當前行）
此方式及其變種是處理緩慢變化維的主要技術。
比如
維度屬性值變化前：
| 商品鍵(代理鍵) | 商品唯一鍵（自然鍵） | 品類 | 行生效時間 | 行失效時間 | 當前行標識 |
|---|---|---|---|---|---|
| 1 | SPU001 | 科技 | 2020-01-01 | 9999-12-31 | 1 |
維度屬性值變化後：
| 商品鍵(代理鍵) | 商品唯一鍵（自然鍵） | 品類 | 行生效時間 | 行失效時間 | 當前行標識 |
|---|---|---|---|---|---|
| 1 | SPU001 | 科技 | 2020-01-01 | 2020-01-31 | 0 |
| 3 | SPU001 | 教育 | 2020-02-01 | 9999-12-31 | 1 |
1.4 方式3：增加新屬性列
在維度表中增加新的一列，原先屬性列存放上一版本的屬性值，當前屬性列存放當前版本的屬性值。
比如
維度屬性值變化前：
| 商品唯一鍵 | 品類 |
|---|---|
| SPU001 | 科技 |
維度屬性值變化後：
| 商品唯一鍵 | 當前品類 | 原先品類 |
|---|---|---|
| SPU001 | 教育 | 科技 |
1.5 方式4：增加微型維度
當某維表是一個大型維度表，採用方式2時，如果某些維度屬性變化相對較快，會導致該維表變得越來越大，導致存儲壓力和性能壓力。
此時引入微型維度是一個不錯的選擇，將某些維度屬性從該大型維表中抽離出來，單獨構建微型維度。
比如將用戶最近消費時間、消費頻率、消費金額從用戶維表中剝離出來，並結合業務以區間段形式表現，單獨構建成RFM微型維度，並在相關事實表中增加RFM鍵作爲外鍵
RFM微型維度：
| RFM鍵 | 最近一次消費 | 消費頻率 | 消費金額 |
|---|---|---|---|
| 1 | 7天內 | >=月均5次 | >=10000 |
| 2 | 30天內 | >=月均5次 | >=10000 |
| 3 | 超過一個月 | >=月均5次 | >=10000 |
| 4 | 7天內 | >=月均1次 | >=10000 |
| 5 | 30天內 | >=月均1次 | >=10000 |
| 6 | 超過一個月 | >=月均1次 | >=10000 |
| … | … | … | … |
相關事實表：
| 日期鍵 | 用戶鍵 | RFM鍵 | 其他外鍵 | 事實 |
|---|---|---|---|---|
| 20200501 | 00001 | 1 | XXX | 10 |
2 混合型
2.1 方式5：微型維度與方式1支架表
該方式是方式1和方式4的結合，即建立微型維度後，微型維度的主鍵不僅作爲事實表的外鍵，也作爲主維度的外鍵。
在主維度中，此微型維度屬性以方式1處理，即當該屬性發生變化時，直接覆蓋，不保留歷史信息。
這種情況下的微型維度被稱之爲支架。
如方式4中的例子，我們再將RFM鍵添加至主維度（用戶維度表）中作爲外鍵，以方式1進行更新，即爲方式5
用戶維度表：
| 用戶鍵 | 用戶名稱 | 其他屬性 | RFM鍵 |
|---|---|---|---|
| 00001 | 張三 | … | 1 |
2.2 方式6：將方式1屬性增加到方式2維度
該方式是方式1、2、3的結合，即同時增加維度行和維度列，並以方式1處理新加的維度列（當前屬性）。
此種方式複雜，在少數特定迫切的場景下才會使用。
如商品的品類變化
品類變化前：
| 商品鍵(代理鍵) | 商品唯一鍵（自然鍵） | 歷史品類 | 當前品類 | 行生效時間 | 行失效時間 | 當前行標識 |
|---|---|---|---|---|---|---|
| 1 | SPU001 | 科技 | 科技 | 2020-01-01 | 9999-12-31 | 1 |
品類變化後：
| 商品鍵(代理鍵) | 商品唯一鍵（自然鍵） | 歷史品類 | 當前品類 | 行生效時間 | 行失效時間 | 當前行標識 |
|---|---|---|---|---|---|---|
| 1 | SPU001 | 科技 | 教育 | 2020-01-01 | 2020-01-31 | 0 |
| 14 | SPU001 | 教育 | 教育 | 2020-02-01 | 9999-12-31 | 1 |
品類再度變化後：
| 商品鍵(代理鍵) | 商品唯一鍵（自然鍵） | 歷史品類 | 當前品類 | 行生效時間 | 行失效時間 | 當前行標識 |
|---|---|---|---|---|---|---|
| 1 | SPU001 | 科技 | 教材 | 2020-01-01 | 2020-01-31 | 0 |
| 14 | SPU001 | 教育 | 教材 | 2020-02-01 | 2020-03-31 | 0 |
| 235 | SPU001 | 教材 | 教材 | 2020-04-01 | 9999-12-31 | 1 |
2.3 方式7：雙重外鍵並且方式1與方式2結合
在方式2的基礎上，不僅是維度的代理鍵作爲事實表外鍵，維度的自然鍵（如果自然鍵會被重新分配，發生變化，應該使用持續性超自然鍵）也同時作爲事實表外鍵。
事實表通過代理鍵連接維表獲取歷史維度屬性，通過自然鍵連接維表獲取當前維度屬性。
如以商品維度爲例
方式2維度表（包含歷史信息）
| 商品鍵(代理鍵) | 商品唯一鍵(自然鍵) | 品類 | 其他屬性 | 行生效時間 | 行失效時間 | 當前行標識 |
|---|---|---|---|---|---|---|
| 1 | SPU001 | 科技 | xxx | 2020-01-01 | 2020-01-31 | 0 |
| 3 | SPU001 | 教育 | xxx | 2020-02-01 | 9999-12-31 | 1 |
相關事實表
| 日期鍵 | 商品鍵(代理鍵)(外鍵) | 商品唯一鍵(自然鍵)(外鍵) | 其他外鍵 | 事實 |
|---|---|---|---|---|
| 20200111 | 1 | SPU001 | XXX | 10 |
| 20200501 | 3 | SPU001 | XXX | 10 |
方式1維度表（當前信息）(可以基於方式2維度表建立視圖形式產生，篩選當前行標識=1的記錄即爲當前信息)
| 商品唯一鍵(自然鍵) | 當前品類 | 其他屬性 |
|---|---|---|
| SPU001 | 教育 | xxx |
3 極限型
3.1 方式8：快照維度
此種方式比較暴力，每天保留全量維度屬性的快照數據，自然鍵及日期鍵作爲事實表的外鍵。
此方式依託的是當前存儲成本遠低於計算成本，以空間換時間的理念。
如商品快照維度表
| 日期鍵 | 商品唯一鍵(自然鍵) | 品類 | 其他屬性 |
|---|---|---|---|
| 20200101 | SPU001 | 科技 | xxx |
| 20200102 | SPU001 | 科技 | xxx |
| … | … | … | … |
| 20200201 | SPU001 | 教育 | xxx |
| … | … | … | … |
| 20200501 | SPU001 | 教材 | xxx |
3.2 方式9：歷史拉鍊維度
此方式是方式2的閹割版，同樣是增加維度行。
但捨棄了代理鍵，因爲如MapReduce之類的分佈式計算引擎，維護全局唯一的代理鍵難度大，成本高。
優點是此方式相比方式8，大大降低了存儲（當然前提是不包含變化頻率很高的維度屬性，如果有，請考慮進行垂直拆分）。
缺點是和事實表連接時會有一些不足。如事實表只能以時間切片的方式和維度表進行連接，如果事實表要多個時間切片同時與維度表關聯，需要一定的技術改造。
| 商品唯一鍵（自然鍵） | 品類 | 行生效時間 | 行失效時間 |
|---|---|---|---|
| SPU001 | 科技 | 2020-01-01 | 2020-01-31 |
| SPU001 | 教育 | 2020-02-01 | 9999-12-31 |
4 結語
以上就是針對緩慢變化維的10種處理方式了。
隨着數據技術的發展，維度建模方法也不是一成不變的，需要結合當前技術的特點進行靈活轉變。
總之，沒有最牛x的建模方法論，只有最適合的。