前言
次元表是次元模組化的靈魂所在，在次元表設計中碰到的問題（比如次元變化、次元層次、次元一緻性、次元整合和拆分等）都會直接關系到次元模組化的好壞，是以良好的維表設計就顯得至關重要，今天就讓我們就一起來探究下關于維表設計的相關概念和一些技術。
次元變化
次元表的資料通常來自于前台業務系統，比如商品次元表可能來自于 ERP 或者超市 POS 系統的商品表，但商品是會發生變化的，比如商品所屬的類目 、商品标簽價格、商品描述等，這些變化有可能是之前有錯誤需要訂正所緻的，或者是實際的業務情況變化。
不管哪種情況，次元設計過程中，确定源頭資料變化在次元表中如何表示非常重要。是以在次元模組化中，這一現象稱為緩慢變化的次元，簡稱 緩慢變化維（slowly changing dimension, SCD）。
根據變化内容的不同，下遊的分析可能要求用不同的辦法來處理
比如對于商品的描述資訊，也許業務人員對此并不敏感，或者認為無關緊要，這種情況可以直接覆寫 。
但是對于商品所屬的類目發生變化，則需要認真考慮， 因為這涉及歸類這個商品的銷售活動到哪個類目一一是全部歸到新類目，還是全部歸到舊類目？變化前歸到舊類目，還是變化後歸到新類目？這實際上也涉及了下面要分享的緩慢變化維的幾種處理辦法。
1. 重寫次元值
當一個次元值屬性發生變化時，重寫次元值方法直接用新值覆寫舊值。
該技術适用于次元模組化中不需要保留此次元屬性曆史變化的情況，常用于錯誤訂正或者次元屬性改變無關緊要的場景，比如使用者的生日之前發生輸入錯誤，不需要保留之前的生月曆史資料。
那麼采用重寫次元值的方法，就将會改變此次元屬性的所有曆史度量。
比如，分析師希望分析星座和銷售的關系，之前使用者的生日屬于白羊座，但是修改後的生日屬于雙子座，那麼次元屬性修改後，其銷售額将都屬于雙子座。是以次元設計人員隻在必要情況下使用此方法，同時需要告知下遊分析人員。
采用重寫次元值方法的次元表和事實表變化如圖：
采用重寫次元值方法處理變化維示例
2. 插入新的次元行
相比重寫次元值方法不維護次元屬性變化的特點，插入新的次元行方法則通過在次元表中插入新的行來儲存和記錄變化的情況。
屬性改變前的事實表行和舊的次元值關聯，而新的事實表行和新的次元值關聯。
采用插入新的次元行方法處理緩慢變化維示例
我們仔細觀察變化後的次元表可以發現，新複制了一行該使用者的資訊，唯一不同在于 state 的不同（之前是 AZ，之後是 CA）。同時，仔細觀察訂單事實表也會發現，過去的訂單是和舊的唯獨行關聯，而新的訂單和新的次元行關聯。
通過新增次元行，我們儲存了次元的變化，并實作了次元值變化前的 實和變化後的事實分别與各自的新舊次元值關聯。
但是這也給次元表使用者帶來了困惑，為什麼查詢會員會在次元表中發現多行記錄？盡管可以向使用者解釋，但是使用者的使用和學習成本無疑增加了， 而且資料開發人員對于次元變化的處理邏輯無疑更複雜了。
3. 插入新的次元列
在某些情況下，可能使用者會希望既能用變化前的屬性值，又能用變化後的屬性值來分析變化前後的所有事實。此時可以采用插入新的次元列這種方法。
采用插入新的次元列處理緩慢變化維示例
不同于前一種方法的添加一行，這種方法通過新增一列，比如用 region_previous 清單示之前的所屬大區，同時新增 region_current 來表示變化後的所屬大區。如果有多次變化，就需要有多個列來存儲。
實際上，這三種方法都能從不同角度解決次元變化的問題，還有通過組合這三種方法形成的其他各種技術可用于處理次元變化，這裡就不再贅述。
當然了，不管哪種技術，在大資料時代都不是完美的，而且有一定的處理複雜度和學習使用成本。
如何以一種最簡單、直接的辦法來解決次元變化呢？我們在後面會聊聊 快照技術 ，以解決大資料時代的次元變化問題。
次元層次
次元層次指的是某個次元表中屬性之間存在的從屬關系問題。比如商品的類目可能是有層次的（一級類目、二級類目、三級類目等，尤其對于寶潔、聯合利華等大的快消企業集團），同時類目、品牌和産品實際上也是有層次的。那麼次元模組化如何處理這些層次結構呢？
實際上有兩種處理辦法：
-
- 第一種是将所有次元層次結構全部扁平化、備援存儲到一個次元表中，比如商品的一至三級類目分别用三個字段來存儲，品牌等的處理也是類似的；
- 第二種是建立類目次元表，并在次元表中維護父子關系。
第一種其實就是星型架構，第二種是雪花架構。在次元模組化中，我們采用第一種來處理次元的層級問題，這樣反規範化的處理犧牲了部分存儲，但是給使用者使用帶來了便捷，也降低了學習使用成本。
次元的層次結構通常和鑽取聯系在一起，所謂鑽取即是對資訊的持續深入挖掘。
鑽取分為向上鑽取和向下鑽取，比如對于某零售商的年度銷售報表，其年度銷售總額顯示增長20%，那麼從時間上分析是哪個季度的增長率比較高呢？
此時可以向下分析各個季度的增長率，同樣可以繼續向下分析到月增長率乃至天增長率，同樣的分析也可以應用到類目 、品牌等，來分析到底是哪個類目的增長或者哪個品牌的增長導緻了年度總銷售額的增長 20% 。這就是向下鑽取。
與之相對的是向上鑽取，鑽取的實質是增加或者減少次元，增加次元（向下鑽取）從彙總資料深入到細節資料，而減少次元（向上鑽取）則從細節資料概括到彙總資料 。通過鑽取，使用者對資料能更深入地了解資料，更容易發現問題，進而做出正确的決策。
次元一緻性
在 Kimball 的次元設計理論中，并沒有實體上的資料倉庫。資料倉庫是在對多個主題、多個業務過程的多次疊代過程中逐漸建立的，這些多個問題、多個業務過程的多次疊代過程常被從邏輯上劃分為資料集市。
所謂資料集市一般由一張和多張緊密關聯的事實表以及多個次元表組成，一般是部門級的或者面向某個特定的主題。資料倉庫則是企業級的、面向主題的、內建的資料集合。
實體上的資料集市組合成邏輯上的資料倉庫， 旦資料集市的建立是逐漸完成的，如果分步建立資料集市的過程中次元表不一緻，那麼資料集市就會變成孤立的集市，不能從邏輯上組合成一個內建的資料倉庫，而次元一緻性的正是為了解決這個問題。
次元一緻性的意思是指：兩個次元如果有關系，要麼就是完全一樣的，要麼就是一個次元在數學意義上是另一個次元的子集。
不一緻既包含次元表内容的不 緻，也包含次元屬性上的不一緻。
-
- 比如對于一個電子商務公司，如果其浏覽等相關主題域的商品次元表包含了該企業的所有商品的通路資訊，但是由于某種原因其交易域的商品缺失了部分商品 （有可能是成交在其他平台完成），那麼對這些缺失商品的交易分析就無法完成 。
- 同樣如果兩的商品屬性不同，比如日期格式、類目劃分（有可能浏覽分為前天類目，成交是背景類自）等不一緻，那麼跨浏覽域和交易域的對類目和日期的交叉分析就無法進行，因為其類目劃分就不一緻。
次元一緻性對于資料集市成為資料倉庫起着關鍵作用，實際資料集市設計和開發過程中，必須保證次元一緻性，具體可以采用共享同一個次元表或者讓其中一個次元表是另外一個次元表的子集等方式來保證一緻性，進而避免孤立資料集市的出現。
次元整合和拆分
實際次元表設計中，有時候會出現同一個次元表來自于多個前台業務系統的問題，此時就會帶來次元整合和拆分問題。
前台的業務系統通常是比較複雜的，比如移動端交易系統和PC端交易系統的系統架構和底層資料庫、表結構等完全不一緻，此時就存在次元的整合問題。
在實際整合中，同一個次元整合需要考慮如下問題：
-
- 命名規範：要確定一緻和統一
- 字段類型 ：統一整合為一個字段類型
- 字段編碼和含義：編碼及含義要整合為一緻
與整合相對的是拆分
對于大的集團公司來說，以中石化為例，其主業為成品油銷售，但是同時其還有中石化加油站的快捷零售店（在此僅做說明問題使用），它們的商品表字段和屬性由于業務的不同而存在很大的差異（石油商品和零售店銷售的食品、飲料等）。
-
- 建一個基礎的次元表， 此基礎次元表包含這些不同業務的共有屬性，同時建立各自業務的單獨次元表以包含其獨特的業務屬性。比如，上述例子就可以建立一個共有的商品次元表記錄商品價格、商品描述等共有屬性字段，同時建立成品油銷售的商品次元表記錄油标号（ 92 95 97 等）等成品油獨特的商品屬性，另外建立一個零售商品次元表記錄便利店的各種商品屬性（實際操作中通常先建立兩個單獨的次元表，然後基于單獨次元表生成共有的商品次元表或者視圖）
- 拆分，即不合并，即各個業務差異獨特性的業務各自建立完全獨立的兩個次元表，各自管理各自次元表和屬性。