數據倉庫系列4-維度表 一. 維度表技術基礎 二. 使用一致性維度集成 三. 處理緩慢變化維度屬性 四. 處理維度層次關係 五. 高級維度表技術 參考:

一. 維度表技術基礎

1.1 維度表結構

  每個維度表都包含單一的主鍵列 。維度表的主鍵可以作爲與之關聯的任何事實表的外鍵，維度錶行的描述環境應與事實錶行完全對應 。維度表通常比較寬 ，是扁平型非規範表 ，包含大量的低粒度的文本屬性 。操作代碼與指示器可作爲屬性對待 ，最強有力的維度屬性採用冗餘的描述填充。維度表屬性是查詢及BI應用 的約束和分組定義的 主要目標。 報表的描述性標識通常是維度表屬性領域值 。

1.2 維度代理鍵

  維度表中會包含一個列 ，表示唯一主鍵。該主鍵不是操作型系統的自然鍵 ，由於需要 跟蹤變化 ，因此若採用自然鍵 ，將需要多個維度行表示 。另外，維度的自然健可能由多個源系統建立 ，這些自然鍵將出現兼容性問題 難以管理 。DW/BI 系統需要聲明對所有維度的主鍵的控制，而無法採用單 一的自然鍵或附加日期的自然鍵 ，可以爲每個維度建立無語義的整型主鍵 。這些維度代理鍵是按順序分配的簡單整數 ，以值 1 開始。每當需要新鍵時， 鍵值自動加1。日期維度不需要遵守代理鍵規則 ，日期維度是高度可預測的且穩定的維度 ， 可以採用更有意義的主鍵 。

以貸款業務爲例
假設公司分線上和線下兩套業務系統，應用和數據都獨立，做數據倉庫的時候需要把兩部分數據集成到一起，假設此時需要創建一個客戶維度表。而兩套業務系統客戶表的主鍵都是ID，這個時候兩套系統集成的時候，如果沿用源系統的主鍵，就會產生衝突，分不出系統數據的來源，此時應該使用一個無意義的整型主鍵作爲代理鍵。

1.3 自然鍵、持久鍵和超自然鍵

  由操作型系統建立的自然鍵受業務規則影響 ，無法被 DW/BI 系統控制。例如 ，如果僱員辭職，然後重新工作 ，則僱員號碼（自然鍵）可能會發生變化 。數據倉庫希望爲該僱員創建單一 鍵 ，這就需要建立新的持久鍵以確保在此種情況下 ，僱員號保持持久性不會發生變化。該鍵有時被稱爲持久性超自然鍵 。最好的持久鍵其格式應該獨立於原始的業務過程 ， 並以整數 l開始進行分配 。多個代理鍵與某一個僱員關聯時 ，若描述發生變化時 ，持久鍵不會變化。

  自然鍵和持久鍵區別：舉個例子就明白了，比如說公司員工離職之後又重新入職，他的自然鍵也就是員工編號發生了變化，但是他的持久鍵身份證號是不變的。

1.4 下鑽

  下鑽是商業用戶分析數據的最基本的方法 。下鑽僅需要在查詢上增加一個行頭指針 。 新行的頭指針是 一個維度屬性 ，附加了 SQL 語言的 GROUP BY 表達式 。屬性可以來自任 何與查詢使用的事實表關聯的維度 。下鑽不需要預先存在層次的定義 ，或者是下鑽路徑 。

  比如對產品銷售情況分析時，可以沿着時間維從年到月到日更細粒度的觀察數據。從年的維度可以下鑽到月的維度、日的維度等。

1.5 退化維度

  有時 ，維度除了主鍵外沒有其他內容。例如 ，當某一發票包含多個數據項時 ，數據項 事實行繼承了發票 的所有描述性維度外鍵 ，發票除了外鍵外無其 他項 。但發票數量仍然是 在此數據項級別的合法維度鍵 。這種退化維度被放入事實表 中，清楚地表明沒有關聯的維 度表 。退化維度常見 於交易和累計快照事實表中 。

  退化維度，就是那些看起來像是事實表的一個維度關鍵字，但實際上並沒有對應的維度表，就是維度屬性存儲到事實表中，這種存儲到事實表中的維度列被稱爲退化維度。與其他存儲在維表中的維度一樣，退化維度也可以用來進行事實表的過濾查詢、實現聚合操作等。

  那麼究竟怎麼定義退化維度呢？比如說訂單id，這種量級很大的維度，沒必要用一張維度表來進行存儲，而我們進行數據查詢或者數據過濾的時候又非常需要，所以這種就冗餘在事實表裏面，這種就叫退化維度，citycode這種我們也會冗餘在事實表裏面，但是它有對應的維度表，所以它不是退化維度。

1.6 非規範化扁平維度

  一般來說 ，維度設計者需要抵制由 多年來操作型數據庫設計所帶來的對規範化設計的 要求 ，並將非規範化的多對一固定深度層次引入扁平維度行的不同屬性 。非規範化維度能 夠實現維度建模的雙重 目標：簡化及速度 。

非規範化扁平維度:

1.7 多層次維度

  多數維度包含不止一個自然層次。例如 ，日曆日期維度可以按照財務週期 層次從天到 周進行劃分 ，也可能存在從天到月再到年的層次 。位置密集型維度可能包含多個地理層次 。 所有這些情況下 ，在同一維度中可以存在不同的層次 。

1.8 文檔屬性的標識與指示器

  令人迷惑 的縮寫、真／假標識以及業務指標可以作爲維度表中文本 字詞含義的補充解 釋 。操作代碼值所包含的意義應分解成不同的表示不同描述性維度屬性的部分 。

1.9 維度表中的空值屬性

  當給定維度行沒有被全部填充時，或者當存在屬性沒有被應用到所有維度行時 ，將產 生空值維度屬性 。上述兩種情況下 ，我們推薦採用描述性字符串替代空值 。例如 ，使用 Unknown 或 Not Applicable 替換空值 。應該避免在維度屬性中使用空值 ，因爲不同的數據庫系統在處理分組和約束時 ，針對空值的處理方法不一致 。

1.10 日曆日期維度

  連接到實際事實表 的日曆日期維度 ，使得能夠對事實表 ，按照熟悉的日期 、月份 、財 務週期和日曆上 的特殊日期進行導航 。不要指望能夠用SQL 計算復活節 ，但可以在日曆日 期維度上尋找復活節 。日曆日期維度通常包含許多描述 ，例如 ，週數 、月份名稱、財務週期、國家假日等屬性 。爲方便劃分，日期維度的主鍵可以更有意義 ，例如 ，用一個整數表 示 YYYYMMDD，而不是用順序分配的代理鍵 。然而，日期維度表需要特定的行表示未知或待定的日期 。若需要更詳細的精確度，可以在事實表中增加不同的日期時間戳 。日期時間戳並不是維度表的外健，但以單獨列的形式存在 。如果商業用戶按照當天時間（ time-of­ day）屬性進行約束或分組，例如，按當天時間或其他數字分組，則需要在事實表上增加一個 “ 當天時間（time-of-day ）” 維度外鍵 。

1.11 扮演角色的維度

  單個物理維度可以被事實表 多次引用，每個 引用連接邏輯 上存在差異 的角色維度。例 如 ，事實表可以有多個日期 ，每個日期通過外鍵表示不 同的日期維度，原則上每個外鍵表 示不同的日期維度視圖 ，這樣引用具有不同的含義 。這些不同的維度視圖（唯一的屬性列名） 被稱爲角色 。

以貸款行業爲例
在申請事實表中，有註冊時間、申請時間、初審時間、審批時間、簽約時間、放款時間等不同的時間維度。

1.12 雜項維度

  事務型商業過程通常產生一系列混雜的、低粒度的標識和指示器 。與其爲每個標識或 屬性定義不同 的維度，不如建立單獨的將不同維度合併到 一起的雜項維度 。這些維度 ，通 常在一個模式 中標記爲 事務型概要維度 ，不需要所有屬性可能值的笛卡爾積 ，但應該只包含實際發生在源數 據中的合併值。

1.13 雪花維度

  當維度表中的層次關係是規範的時，低粒度屬性 作爲輔助表通過屬性鍵連接到基本維 度表 。當這一過程包含多重維度表層次 時，建立的多級層次結構被稱爲 雪花模式 。儘管雪 花模式可精確表示層次化的數據 ，但還是應該避免使用 雪花模式 ，因爲對商業用戶來說 ， 理解雪花模式並在其中查詢是非常困難 的。雪花模式還會影響查詢性能。扁平化的 、非規範的維度表完全能夠獲得 與雪花模式相同的信息 。

1.14 支架維度

  維度可包含對其他維度的引用 。例如，銀行賬戶維度可 以引用表示開戶日期的維度 。 這些被引用的輔助維度稱爲支 架維度 。支架維度可以使用，但應該儘量少用 。多數情況下， 維度之間的關聯應該由 事實表來實現。在事實表中通過兩 個維度的不同外鍵相 關聯。

Kimball的架構中不推崇雪花模型，但如果一組屬性在維度表中出現不止一次時，我們也可以採用受限的雪花模型——也就是支架表。
除了事實表，一些維度表也用到了日期維度，日期維度被多個表鎖使用，就成爲日期支架表。

二. 使用一致性維度集成

  維度建模方法最成功的方面之 一就是爲集成來自不同商業過程的數據而定義了簡單 而強大的解決方案 。

一致性維度通俗講解:
在同一個集市內，一致性維度的意思是兩個維度如果有關係，要麼就是完全一樣的，要麼就是一個維度在數學意義上是另一個維度的子集。例如，如果建立月維度話，月維度的各種描述必須與日期維度中的完全一致，最常用的做法就是在日期維度上建立視圖生成月維度。這樣月維度就可以是日期維度的子集，在後續鑽取等操作時可以保持一致。如果維度表中的數據量較大，出於效率的考慮，應該建立物化視圖或者實際的物理表。

2.1 一致性維度

  當不同的維度表的屬性具有相同列名和領域內容時 ，稱維度表具有一致性 。利用一致 性維度屬性與每個事實表關聯 ，可將來自不同 事實表的信息合併到同 一報表中 。當一致性 屬性被用作行頭（就是說 ，用作 SQL 查詢中的分組列）時 ，來自不同事實表的結果可以排列 到跨鑽報表的同一行中 。以上實現是集成企業DW/Bl 系統的基礎 。一致性維度一旦在與業 務數據管理方共 同定義後 ，就可以被所有事實表重用 。該方法可獲得分析一致性並減少未 來開發的開銷，因爲不需要重新創建。

2.2 縮減維度

  縮減維度是一種一致性維度 ，由基本維度的列與（或）行的子集構成 。當構建聚集事實表時需要縮減上卷維度 。當商業過程自然地獲取粒度級別較高的數據時，也需要縮減維度， 例如某個按月和品牌進行的預測（不需要與銷售數據 關聯的更原子 級別的數據和產品） 。另外一種情況下 ，也就是當兩個維度具有同樣粒度級別的細節數據 ，但其中一個僅表示行的 部分子集時 ，也需要一致性維度子集 。

2.3 跨表鑽取

  簡單地說 ，跨表鑽取意思是當每個查詢的行頭包含相同的一致性屬性時，使不同的查 詢能夠針對兩個或更多的事實表進行查詢 。來自兩個查詢的回答集合將針對公共維度屬性 行頭，通過執行排序 融合操作實現排列 。Bl 工具提供商對這些功能有多種不同的命名方法 ， 包括編織和多遍查詢等。

2.4 價值鏈

  價值鏈用於區分組織中主要業務過程的自然流 程 。例如 ，銷售商 的價值鏈可能包括購 買、庫存、零售額等 。一般的分類賬價值鏈可能包括預 算編制 、承付款項 、付款等 。操作 型源系統通常爲價值鏈上的每個步驟建立事務或快照 。因爲每個過程在特定時間間隔 ，採 用特定的粒度和維度建 立唯一的度量，所以每個過程通常至少建立 一個原子事實表 。

2.5 企業數據倉庫總線架構

  企業數據倉庫總線架構提供一種建立企業 DW/BI 系統的增量式方法 。這一架構通過關 注業務過程將 DW/BI 規劃過程分解爲可管理 的模塊，通過重用跨不同過程的標準化一致性 維度發佈實現集成。企業數據倉庫總線架構提供了 一種架構性框架 ，同時也支持可管理敏 捷實現對應企業數據倉庫總線矩陣 。總線架構中技術與數據庫平臺是獨立的 ，無論是關係 數據庫或者是 OLAP 維度結構都能參與其中 。

2.6 企業數據倉庫總線矩陣

  企業數據倉庫總線矩陣是用於設計並與企業數據 倉庫總線架構 交互的基本工具 。矩陣的 行表示業務過程 ，列表示維度。矩陣中的點表示維度與給定 的業務過程是否存在關聯關係 。 設計小組分析每一行，用於測試是否爲 業務過程定義好相關的候選維度 ，同時也能分析每個 列，考慮某一維度需要跨多個業務過程並 保持一致性。除技術設計細節外 ，當設計小組實現 矩陣中的某行時 ，總線矩陣還可用作輸入幫助確定優先 處理 DW/BI 項目過程管理。

2.7 總線矩陣實現細節

  總線矩陣實現細節是一個更加粒度化的總線矩陣，其中擴展每個業務過程行以展示特 定事實表或 OLAP 多維數據庫 。在此細節粒度上 ，可以文檔化精確 的粒度描述以及事實列表。

2.8 機會／利益相關方矩陣

  在確定了企業數據倉庫總線矩陣行之後，可以通過替換包含業務功能（例如 ，市場、銷 售 、財務等）的維度列規劃不同的矩陣 。通過確定矩陣點以表示哪些業務功能與哪些 業務過 程行相關 。機會／利益相關方矩陣可用於區分哪些業務過程分組應該與 過程中心行相關 。

三. 處理緩慢變化維度屬性

3.1 類型 0：原樣保留

  對類型 0，維度屬性值不會發生變化，因此事實表以原始值分組 。類型0適合屬性標 記爲 “ 原型” 的情況。例如 ，客戶原始的信用卡積分或持久型標識符 。該類型也適用於日期維度的大多數屬性 。

以貸款行業爲例:
比如在用戶維度表中，用戶註冊時使用的原始用戶名（original_user_name）。如果它發生變化，那麼變化後的值是無效的，會被拋棄。

3.2 類型 1：重寫

  對類型 1 ，維度行中原來的屬性值被新值覆蓋 。類型1屬性總是反映最近的工作 ，因此該技術破壞了歷史情況 。儘管該方法易於實現且不需要建立額外的維度行，但使用時需小心，因爲受此影響的聚集事實表和 OLAP 多維數據庫將會重複計算。

以貸款行業爲例:
此方法必須有前提條件，即你不關心這個數劇的變化。例如，某個銷售人員的英文名改了，如果你不關心員工的英文名有什麼變化則可直接覆蓋(修改)數據倉庫中的數據。

3.3 類型 2：增加新行

  對類型 2，將在維度表中增加新行 ，新行中採用 修改的屬性值。要實現該方式 需要維 度主鍵更具有一般性 ，不能僅採用自然鍵或持久鍵 ，因爲採用該方法時經常會出現多行描述同樣成員的情況 。在爲維度成員建 立新行時 ，將爲其分配新的 主代理鍵，在修改發生後， 將其作爲所有事實表的外鍵，直到後續變化產生新維度鍵並更新維度行 。
  當變化類型 2 發生時，最少需要在維度行中增加 三個額外列 ：①行有效的日期／時間戳 列：②行截止日期／時間戳列：③當前行標識 。

以貸款行業爲例:
貸款產品的費率會隨着市場行情的變化而變化，此時我們應該通過拉鍊表來記錄費率的變化，保證歷史訂單的費率信息是準確的。

3.4 類型 3：增加新屬性

  對類型 3，將在維度表上增加新屬性以保存原來的屬性值 ，新屬性值以變化類型 l 方 式重寫主屬性 。這種類型 3 變化有時稱爲替換現實 。商業用戶可以利用當前值或 替換現實 來分組或過濾事實數據 。此種緩慢變化維度技術不太 常用。

3.5 類型 4：增加微型維度

  對類型 4，當維度中的一組屬性快速變化並劃分爲微型維度時採用 。此種情況下的維度通常被稱爲快速變化魔鬼維度 。通常在包含幾百萬行的維度表中使用的屬性是微型維度設計的候選 ，即使它們並不經常變化 變化類型 4 微型維度需要自己的唯一主鍵，基維度 和微型維度主鍵從相關的 事實表中獲取。

以案例來看:
初始的維度表

在一年後變爲二年級：

1. 重寫覆蓋

   
   

2. 增加行

   
   

3. 增加新屬性保留舊屬性

   
   

4. 增加微型維度

   
   

3.6 類型 5：增加微型維度及類型 1 支架

  對類型5，用於精確保存歷史屬性 值 ，按照當前屬性值 ，增加報表的歷史事實 。類型 5 建立在類型 4 微型維度之上 ，並嵌入當前類型 l 引用基維度中的微型維度 。這樣才能確保 當前分配的微型維度屬性能夠與基維度上其他微型維度 一起被訪問 ，而不必通過事實表連 接 。邏輯上說 ，應該將基維度及微型維度支架表 示爲展現區域中的單一表。每當當前微型 維度分配發生變化時 ，ETL 小組需要重寫類型 l 微型維度引用 。

3.7 類型 6：增加類型 1 屬性到類型 2 維度

  與類型 5 類似，類型 6 也保存歷史和當前維度屬性值 。類型 6 建立在類型 2 的基礎上， 同時嵌入維度行屬性的當前類型 l版本 ，因此事實行可以被過濾或分組 ，要麼按照當度量 發生時有效的類型 2 屬性值 ，要麼按照、屬性的當前值。在此環境中 ，當屬性發生變化時 ， 類型 1屬性由系統自動重寫與特定持久鍵關聯的所有行 。

3.8 類型 7：雙類型 1 和類型 2 維度

  類型 7 是用於支持過去和現在報表的最後 一種混合技術 。事實表可以被訪 問，通過被 建模爲類型 l 維度僅僅展示最新屬性值 ，建模爲類型 2 維度展示最新歷史概要 。同樣的維 度表確保實現兩方面的觀點 。維度的持久鍵和主代理鍵同時存在事實表上 。從類型 l角度 看，維度的當前標識被約束至當前 ，通過持久鍵與事實表連接 。從類型 2 角度看 ，當前標 識無約束 ，事實表通過代理鍵主鍵連接。此兩種方法可以按照不同的視圖 部署到 BI 應用上 。

四. 處理維度層次關係

維度往往存在層次關係 。本節描述處理層次關係的方法 ，從最基本的情況開始討論 。

4.1 書中解釋

4.1.1 固定深度位置的層次

  固定深度層次是多對一關係的一種 ，例如 ，產品→品牌→類別→部門 。當固 定深度層次定義完成後，層次就具有商定的名字 ，層次級別作爲維度表中的不同位置屬性 出現。只要滿足上述條件，固定深度層次就是最容易理解和查詢的層次關係 ，固定層次也 能夠提供可預測的、快速的查詢性能 。當層次不是多對一關係 ，或層次的深度不定 ，以致 層次沒有穩定的命名時 ，就需要接下來將描述的非固定層次技術 。

4.1.2 輕微參差不齊 ／可變深度層次

  輕微參差不齊層次沒有固定的層次深度 ，但層次深度有限 。地理層次深度通常包含 3到 6 層。與其使用複雜 的機制構建難以預測的可變深度層次 ，不如將其變換爲固定深度位 置設計 ，針對不同的維度屬性確立最大深度 ，然後基於業務規 則放置屬性值 。

4.1.3 具有層次橋接表的參差不齊 ／可變深度層次

  在關係數據庫 中，深度不確定的可變深度層次非常難以建模 。儘管 SQL 擴展和 OLAP 訪問語言對遞歸父子關係提供了 一些支持 ，但方法極爲有限 。採用 SQL 擴展，在查詢時， 不能替換參差不齊層次 ，不支持對自身層次結構的共享 ，同時也不支持隨時間變化的參差 不齊層次 。以上所有問題可以通過在關係數據庫中採用構建橋接表方式建模參差不齊層次 米解決 。這樣的橋接表對每個可能的路徑保留 一行，確保能夠遍歷所有層次的形式 ，採用 標準 SQL 而不是用特定語 言擴展來實現 。

4.1.4 具有路徑字符屬性的可變深度層次

  可以在維度中採用路徑字符屬性 ，以避免使用橋接表表示可變深度層次 。對維度中的 每行 ，路徑字符屬性包含特定的嵌入文本字符 ，包含從層次最高節點到特定維度行所描述 節點的完整路徑描述 。多數標準層次分析需求可以通過標準 SQL 處理，不必採用 SQL 語 言擴展 。然而 ，路徑字符方法不 能確保其他層次的快速替換 ，也無法保證共享自身層次 。 路徑字符方法也難於構建可變路徑層次的變化 ，可能需要重新標記整個層次 。

五. 高級維度表技術

5.1 維度表連接

  維度表可以包含到其他維度表的引 用。儘管此類關係可以採用支架維度建模實現 ，但 某些情況下 ，存在於基本維度上的指向支架維度的外鍵的存在將導致 基本維度爆炸性增長 ， 因爲支架表中的類型 2 變化強制需要在基本維度中對 應處理類型 2 變化。如果通過將支架 表中的外鍵放入事實表中而不是放置在基本維度表中 ，降低維度表之間的關聯，則此類增 長通常可被避免 。該方法意味着發現維度之間的關聯 ，僅需要通過遍歷 事實表 ，這是可以 接受的 ，特別是當事實表示週期快照 ，其所有維度的所有鍵都會在每個報表週期 內出現時。

5.2 多值維度與橋接表

  經典維度模式中 ，每個與事實表關聯 的維度都有一個與事實表粒度一致的單一值。但 是某些情況下 ，維度存在合理的多值 。例如 ，某個病人接受了 一次健康體檢，可能同時出 現多個診斷。在此情況下，多值維度必須通過 一組維度鍵通過橋接表使一組中的每個診斷 與事實表一行關聯 。

5.3 隨時間變化的多值橋接表

  多值橋接表可能需要基於緩慢變 化類型 2 維度。例如 ，實現銀行賬戶與單獨客戶的多 對多關係的橋接表 ，通常必須基於類型 2 的賬戶與客戶維度 。在此情況下 ，爲防止賬戶與 客戶之間 的不正確連接 ，橋接表必須包含有效期和截止日期 ／時間戳，請求的應用必須約 束 橋接表 ，使其滿足特定時刻以產生一致的快照 。

5.4 標籤的時間序列行爲

  數據倉庫中幾乎所有的文本都是維度表中的描述性文本 。數據挖掘客戶聚類分析通常 產生文本化的行爲標籤，通常可以用作區分週期 。在此情況下 ，跨時間範圍的 客戶行爲度 量成爲由這些行爲標籤構成的一種序列 ，該時間序列應該以位置屬性被存儲在客 戶維度中， 包含可選文本串 ，構成完整的序列標籤 。行爲標籤在位置設計時建 立 ，因爲行爲標籤是復 雜併發查詢而不是數字計算的目標 。

5.5 行爲研究分組

  有時可以通過執行多次迭代分析 ，來發現複雜的客戶行爲 。在此情況下 ，將行爲分析嵌入到 BI 應用，以約束所有客戶維度的成員 ，獲取複雜的行爲 ，這樣的做法是不現實 的。 複雜行爲分析的結果 ，可以通過某些簡單表獲取 ，這些表稱爲研究分組 ，僅包含客戶的持 久鍵 。在查詞時 ，通過約束研 究組表的列與目標模式中客戶維度的持久鍵 ，該靜態表可當 成一種可應用於任何帶有客戶維度的維度模式過濾器 。可以定義多個研究組 ，導出的研究 組可以通過遍歷、聯合、設置差異等方式建立 。

5.6 聚集事實作爲維度屬性

  商業用戶通常對基於聚集性能度量的客戶維度感興趣 ，例如 ，過濾去年或整個階段所 有花費超過一定數額的客戶 。選擇聚集事實 可以放入作爲約束和作爲行標識報表的目標維 度 。度量通常表示 爲維度表中的帶狀範圍 。維度屬性表示聚集性能度量將增加 ETL 處理的 負擔 ，但是可以方便 BI 應用層的分析功能。

5.7 動態值範圍

  動態值範圍報表由 一系列報表行頭組成 ，這些報表行頭爲目標數字 化事實定義了範圍 不斷變化的集合 。例如 ，一個銀行的公共值範圍報 表包含帶有標籤的多個行 ，例如 ，“ 從 0 到10.01 到$25 的平賬” 等等 。此類報表是動態報表 ，因爲每次查詢時都 定義了特定 的行頭，而不是在 ETL 過程中定義的 。行定義可以通過在小值範圍維度表實現 ， 通過大於連接或 小於連接而與事實表實現連接 ，定義可以僅存在於 SQL CASE 語句中 。該 值範圍維度方法可 能會獲得更高 的性能，特別是針對列數據庫 ，因爲 CASE 語句方法包含 針對幾乎所有事實表 的無約束關係掃描。

5.8 文本註釋維度

  與其將自由註釋作爲事實表的文本度 量 ，不如將它們存儲於事實表之外的不同的註釋維度（或作爲維度屬性 ，每個事務一行 ，但需要註釋 的粒度滿足唯一事務的數目） ，使該注 釋維度對應事實表中的一個外鍵。

5.9 多時區

  爲在多時區應用中獲得通用標準時間以及本 地時間 ，應該在受影 響的事實表中設置雙外鍵 ，用以連接兩個不同角色的日期（和可能的 當天時間（time-oιday））維度表 。

5.10 度量類型維度

  有時 當事實表每行包含一長列稀疏存儲 的事實時，可 以建立度量類型維度 ，通過度量 類型維度將事實錶行變成單一通用事實。我們一般不推薦採用該方法 。儘管它消除 了所有空的事實表列，但按照每行中 佔用列的平均數量 ，這增加了事實表大小 ，並且使內部列的 計算更加困難 。當潛在事實的數量達到極限（幾百個），但是沒有多少需要應用 到任何給定 事實錶行時 ，可以採用該技術 。

5.11 步驟維度

  序列過程(例如,Web事件)通常在事務事實表中用不同行表示過程中的每一步。爲了告知哪個步驟滿足整個會話 ，使用步驟維度展示當前步驟的步驟 號以及完成該會話共有 多少步驟。

5.12 熱交換維度

  當同一個事實表與相同維度的不同拷貝交替搭配時 ，可使用熱交換維度 。例如 ，某事 實表包含股票行情 ，可以同時展示給不同的投資人 ，不同的投資人對不同的股 票有不同的 屬性要求 。

5.13 抽象通用維度

  一些建模者喜歡使用抽象通用維度 。例如 ，他們的模式包 含單一通用位置維度而不是 關於商店 、倉庫和客戶維度的嵌入式的地理屬性 。類似地 ，其人員維度包含 僱員、客戶和 供應商行 ，因爲儘管每種類型都包含顯然不同的屬性 ，但他們都 是人 。在維度建模時應 盡 量避免使用抽象通用維度 。與每種類型關聯的屬性集合通常存在差異 。如果屬性是通用的， 例如 ，地理州 ，應將它們唯一標識以區分商店所在州與客戶所在州 。最後 ，將所有不同的 位置 、人員、產品放入單一維度將產生大型的維度表 。數據抽象可以適 當運用於操作型源 系統或 ETL 處理 ，但對查詢性能有負面影響 ，並會對維度模型的易 讀性帶來負面影響 。

5.14 審計維度

  當事實錶行是在 ETL 之後建立時 ，建立包含當時己知的 ETL 過程元數據的 審計維度 是很好的方法 。簡單的審計維度行可包含 一個或多個數據質量的基本標識 ，也許來自對錯誤事件模式的檢驗 ，記錄數據處理是發現的數據質量問題 。另外，使用審計維度屬性可以包含描述建立事實行或 ETL 執行時間戳的 ETL 代碼版本環境變量 。這些環境變 量對審計 意圖特別有用 ，因爲它們確保 BI 工具下鑽以確定！那些行是由哪些 ETL 軟件版本建立的。

5.15 最後產生的維度

  有時來自操作型業務過程的 事實在關聯維度 內容前 ，以分鐘、小時、天或周產生 。例 如，在實時日期發佈環境下 ，訂單消耗行可能 會到來 ，顯示客戶提交的購 買特定商品的自 然鍵 。在實時 ETL 系統中 ，該行必須提交到 BI 層 ，即使客戶或產品還不能立即確定下米 。 在此情況下 ，將建立特殊的維度行 ，包含作爲屬性的 未分解的自然鍵 。當然，這些維度行必須包含通用未知值 ，用於多數描述性列 ：推測適 當的維度 內容將會從源獲得 。當這些維度內容最後獲得時 ，佔位維度行用類型 1 重寫 。當採用類型 2 維度屬性的追溯性變化 發生後，最後達到的維度數據也會 產生 。在此情況下 ，新行需要插入維度表中 ，然後需要重新 定義關聯事實行 。

參考:

1. 《數據倉庫工具箱 維度建模權威指南》第三版