資料倉庫工具箱(第3版)：維度建模權威指南（簡體書）

隨著The Data Warehouse Toolkit(1996)第1版的出版發行，Ralph Kimball為整個行業引入了維度建模技術。從此，維度建模成為一種被廣泛接受的表達資料倉庫和商業智慧(DW/BI)系統中資料的方法。該經典書籍被認為是維度建模技術、模式和最佳實踐的權威資源。

這本《資料倉庫工具箱(第3版)——維度建模權威指南》彙集了到目前為止最全面的維度建模技術。本書採用新的思路和最佳實踐對上一版本進行了全面修訂，給出了設計維度模型的全面指南，既適合資料倉庫新手，也適合經驗豐富的專業人員。

本書涉及的所有技術都基於作者實際從事DW/BI的設計經驗，通過實際案例加以描述。 主要內容 實用設計技術——有關維度和事實表的基本和高級技術 14個案例研究，涉及零售業、電子商務、客戶關係管理、採購、庫存、訂單管理、會計、人力資源、金融服務、醫療衛生、保險、教育、電信和運輸等 為12個案例研究提供了資料倉庫匯流排矩陣示例

需要避免的維度建模陷阱和錯誤 增強的緩慢變化維度(SCD)技術類型0~類型7 用於處理參差不齊的可變深度層次和多值屬性的橋接表 大資料分析的最佳實踐 與業務參與方合作、交互設計會議的指南 有關Kimball DW/BI專案生命週期方法論的概論 對ETL系統和設計思考的總結 構建維度和事實表的34個ETL子系統和技術。

Ralph Kimball博士自1982年以來，一直是資料倉庫和商業智慧行業的思想開拓者。自1996年以來，The Data Warehouse Toolkit系列書籍一直是最受讀者歡迎的暢銷書。
Margy Ross是Kimball集團總裁，她與Ralph Kimball合作撰寫了5本工具箱系列書籍。她關注資料倉庫和商業智慧已有30多年的歷史。

自Ralph Kimball於1996年首次出版The Data Warehouse Toolkit(Wiley)一書以來，資料倉庫和商業智慧(Data Warehousing and Business Intelligence，DW/BI)行業漸趨成熟。儘管初期僅有部分大型公司採用，但從那時起，DW/BI逐漸為各種規模的公司所青睞。業界已建立了數以千計的DW/BI系統。隨著資料倉庫原子資料的不斷增加以及更新越來越頻繁，資料容量不斷增長。在我們的職業生涯中，我們見證了資料庫容量從MB到GB再到TB甚至PB的發展過程，但是，DW/BI系統面臨的基本挑戰並未發生重大變化。我們的工作就是管理組織中的資料並將其用於業務用戶的決策制定過程中。總的來說，您必須實現這一目標，確保商務人士制定更好的決策，並從他們的DW/BI投資中獲得回報。
自The Data Warehouse Toolkit第1版出版以來，維度建模作為一種主要的DW/BI展現技術受到廣泛認可。從業者與學者都認識到資料展現要獲得成功，就必須建立在簡單性的基礎之上。簡單性是使使用者能夠方便地理解資料庫，使軟體能夠方便地訪問資料庫的基礎性的關鍵要素。許多情況下，維度建模就是時刻考慮如何能夠提供簡單性。堅定不移地回到業務驅動的場景，堅持以用戶的可理解性和查詢性能為目標，才能建立始終如一地服務於組織的分析需求的設計。維度建模框架將成為BI的平臺。基於我們多年來積累的經驗以及大量實踐者的回饋，我們相信維度建模是DW/BI項目成功的關鍵。
維度建模還是建立集成化的DW/BI系統的主導結構。當您使用維度模型的一致性維度和一致性事實時，可以增量式地建立具有可實踐的、可預測的、分散式的複雜DW/BI系統的框架。
儘管業界的一切始終在變化，但Ralph Kimball於17年前提出的核心維度建模技術經受住了時間的考驗。諸如一致性維度、緩慢變化維度、異構產品、無事實的事實表以及企業資料倉庫匯流排矩陣等概念仍然是全球範圍內設計論壇所討論的問題。最初的概念通過新的和互補的技術被逐漸完善並強化。我們決定對Kimball的書籍發行第3版，因為我們感到有必要將我們所收集到的維度建模經驗彙集到一本書中。我們每個人都具有30年以上的關注決策支援、資料倉庫和業務智慧的經歷。我們希望分享在職業生涯中反復利用的維度建模模式。本書還包含基於現實場景的特定的實踐性的設計建議。
本書的目標是提供維度建模技術的一站式商店。正如書名所體現的那樣，本書是一本維度設計原則和技術的工具箱。本書既能滿足那些剛剛進入維度DW/BI行業的新手的需要，也描述了許多高級概念以滿足那些長期戰鬥在這一行業的老手的需要。我們相信本書在維度建模主題方面所涵蓋內容的深度是獨一無二的。本書是權威性的指南。
預期讀者
本書面向資料倉庫和商業智慧設計人員、實踐人員和管理人員。此外，積極參與DW/BI專案的業務分析人員和資料管理者也會發現本書內容對他們來說是非常有益的。
即使您並未直接負責維度模型的開發工作，但我們相信熟悉維度建模的概念對項目組所有成員都是非常重要的。維度模型對DW/BI實現的許多方面都有影響，從業務需求的轉換開始，通過獲取、轉換和載入(ETL)過程，最後到通過商業智慧應用發佈資料倉庫的整個過程。由於涉及內容的廣泛性，無論您是主要負責專案管理、業務分析、資料結構、資料庫設計、ETL和BI應用，還是教育和支援，都需要熟悉維度建模。本書適合於方方面面的讀者。
對那些已經閱讀過本書前期版本的讀者來說，在本書中將發現一些熟悉的案例研究，然而，這些案例都被更新了，增加了更豐富的內容，幾乎每個案例都包括樣例企業資料倉庫匯流排矩陣。我們為新的主題區域(包括大資料分析)提供了相應內容。
本書內容偏向對技術的討論。主要從關聯式資料庫環境出發討論維度建模，這一環境與連線分析處理(OLAP)存在的細微差別在適當之處都進行了說明。本書假定讀者對關聯式資料庫概念有一定的瞭解，例如表、行、鍵和連接等。鑒於我們在討論維度模型時不採用某一特定的方法，所以不會就某一特定資料庫管理系統具體的物理設計和調整指導展開深入的討論。
各章預覽
本書將圍繞一系列商業場景或案例研究進行組織。我們相信通過實例來研究設計技術是最有效的方法，因為這樣做可以使我們分享非常實際的指導以及現實世界的適用經驗。儘管未提供完整的應用或業界解決方案，但這些案例可用來討論出現在維度建模中的模式。據我們的經驗來看，通過遠離自己所熟悉的複雜問題，更容易抓住設計技術的要素。閱讀過本書以前各版本的讀者對這一方法的反應非常積極。
請注意我們在第2章未採用案例研究方法。鑒於Kimball集團所發明的維度建模技術得到行業的廣泛認可，我們整理出了這些技術，並簡短地進行了描述。儘管並不指望讀者會像閱讀其他章節那樣從頭到尾仔細閱讀，但我們覺得這一以技術為中心的章節對讀者來說是一種有益的參考。
除第2章以外，本書其他章節相互關聯。我們以基本概念開始，隨著內容的展開，介紹了更高級的內容。讀者應該順序閱讀各章。例如，除非您閱讀了第16章之前有關零售、採購、訂單管理和客戶關係管理的那幾章的內容，否則很難理解第16章的相關內容。
對那些已經閱讀過本書以前版本的讀者來說，可能會忽略前面幾章。儘管對前面的事實和維度比較熟悉，但不希望讀者跳過太多的章節，否則可能會錯過一些已經更新的基本概念。
第1章：資料倉庫、商業智慧及維度建模初步
本書以資料倉庫、商業智慧及維度建模入門開始，探討了整個DW/BI結構的所有元件並建立了本書其他章節所用到的核心詞彙。消除了一些有關維度建模的神化和誤解。
第2章：Kimball維度建模技術概述
本章描述了超過75個維度建模技術以及模式。
第3章：零售業務
零售是用於描述維度建模的經典實例。我們之所以從該行業開始討論是因為該行業為大眾所熟悉。並不需要大家都對該行業有非常深入的瞭解，因為我們主要是希望通過該章的學習使大家能夠關注核心的維度建模概念。該章以設計維度模型常用的4步過程開始，對維度表開展了深入的研究，包括貫穿全書反復使用的日期維度。同時，我們還討論了退化維度、雪花維度以及代理鍵。即使您並不從事零售行業的工作，也需要仔細閱讀這一章，因為該章是其他各章的基礎。
第4章：庫存
該章是對第3章零售業討論的延伸，討論了零售業的另一個案例，但請將注意力轉移到零售業的另一個業務過程上。該章介紹了企業資料倉庫匯流排架構以及具有一致性維度的匯流排矩陣。這些概念對那些希望建立集成的、可擴展的DW/BI架構的人來說是非常關鍵的一章。我們還討論了三種基礎類型的事實表：事務、週期快照和累積快照。
第5章：採購
該章強調了在構思DW/BI環境時，企業組織的價值鏈的重要性。我們還探討了用於處理緩慢變化維度屬性的一系列基礎的和高級的技術；討論了基本的類型1(重寫)、類型2(增加行)和類型3(增加列)，並在此基礎上介紹了類型0，以及類型4～類型7。
第6章：訂單管理
在研究該案例時，我們考察了在DW/BI系統中常常需要首先考慮實現的業務過程，因為這些過程支援核心業務性能度量——我們將哪些商品以何種價格賣給哪些顧客？討論了在模式中扮演多種角色的維度。還討論了在處理訂單管理資訊時，建模人員將會面對的常見挑戰，例如，表頭/列表項考慮、多幣種或多種度量單位，以及五花八門的事務識別字的雜項維度等。
第7章：會計
該章主要討論了建模資料倉庫中的總帳資訊。描述了處理年度-日期(year-to-date)事實和多種財政日曆，以及將多個業務過程中的資料合併到事實表的適當方法。還對維度屬性層次提供了詳細的指導，從簡單的規範的固定深度層次到包含參差不齊的可變深度層次的橋接表。
第8章：客戶關係管理
大量的DW/BI系統建立在需要更好地理解客戶並向其提供服務的前提下。該章討論了客戶維度，包括標準化位址和處理多值維度屬性的橋接表。該章還討論了對複雜的客戶行為建模的模式，以及如何從多個資料來源中合併客戶資料的方法。
第9章：人力資源管理
該章討論了人力資源維度模型具有的幾種特性，包括那些維度表行為類似事實表的情況。該章討論了分析方案套裝軟體，以及對遞迴管理層次及調查問卷的處理方法。對幾種處理多值技能關鍵字屬性的方法進行了比較。
第10章：金融服務
銀行案例研究探討了那些每個業務列表項具有特定描述性屬性和性能度量的異構產品的超類和子類模式的概念。顯然，並不是只有金融服務行業需要處理異構產品。該章還討論了帳戶、客戶和家庭之間所存在的複雜關係。
第11章：電信
該章從結構上來看與前幾章有一些差別，主要是為了鼓勵讀者在執行維度模型設計評審時辯證地考慮問題。該章從乍看似乎是合理的維度設計開始。您能夠從中發現什麼問題？ 此外，該章還討論了地理位置維度的特性。
第12章：交通運輸
該章的案例考察了不同細微性級別的相關事實表，指出描述旅程或網路中區段的事實表的特性。進一步深入考察了日期和時間維度，包括特定國家日曆和跨多個時區的同步問題。
第13章：教育
該章考察了幾類無事實的事實表。此外，探討了處理學生應用和研究基金申請流水線的累積快照事實表。該章為讀者提供了瞭解教育團體中各種各樣業務過程的機會。
第14章：醫療衛生
我們所遇見的最複雜的模型來自醫療衛生行業。該章描述了處理此類複雜性的方法，包括使用橋接表建模多項診斷以及與病人治療事件相關的提供商。
第15章：電子商務
該章主要關注點擊流Web資料的細節，包括其獨有的多維性。該章還介紹了用於更好地理解包含順序步驟的任何過程的步驟維度。
第16章：保險業務
作為本書提供的最後一個案例研究，我們將書中前述的各個模式關聯到一起。可將該章看成是對以前各個章節的總結，因為這些建模技術按層次劃分。
第17章：Kimball DW/BI生命週期概述
通過前述章節的介紹，您已經熟悉了維度模型的設計方法，該章概述了在典型的DW/BI項目生命週期中將會遇到的活動。該章是對由我們與Bob Becker、Joy Mundy和Warren Thornthwaite共同編寫的The Data Warehouse Lifecycle Toolkit, Second Edition(Wiley, 2008)一書的簡短概述。
第18章：維度建模過程與任務
該章對處理Kimball生命週期中的維度建模任務提出了具體的建議。本書的前16章包含維度建模技術和設計模式；該章描述責任、操作方式，以及維度建模設計活動的發佈物。
第19章：ETL子系統與技術
在構建DW/BI環境時，ETL(獲取、轉換、載入)系統將會消耗大量的時間和精力，與其他部分工作比較，幾乎不成比例。仔細考慮的最佳實踐揭示了在幾乎所有維度資料倉庫後端都將發現的34個子系統。該章首先討論了在設計ETL系統之前必須考慮的需求和約束，然後描述了34個與獲取、清洗、一致性、發佈和管理有關的子系統。
第20章：ETL系統設計與開發過程和任務
該章深入探討了與ETL設計和開發活動有關或無關的具體技術。那些對ETL負有責任的讀者都應該閱讀本章。
第21章：大資料分析
最後一章主要關注大資料這一正在流行的主題。我們認為，大資料是對DW/BI系統的自然擴展。首先討論了幾種可選的結構，包括MapReduce和Hadoop，描述了這些可選系統如何與當前的DW/BI結構共存的問題。接著討論了針對大資料的管理、結構、資料建模和資料治理的最佳實踐。
Web資源
Kimball集團網站包含許多補充的維度建模內容和資源：
● 註冊Kimball Design Tips可收到有關維度建模和DW/BI主題的實踐指導。
● 訪問目錄可獲得300個設計技巧和文章。
● 通過學習Kimball大學公開的和現場的課程，可獲得高品質、獨立于提供商的教育，並分享我們的經驗和文章。
● 獲得Kimball集團諮詢服務以利用我們幾十年積累的有關DW/BI的寶貴經驗。
● 向Kimball論壇的其他維度設計參與者提問。
小結
本書的寫作目標是基於作者60多年來從實際業務環境中獲得的經驗和來之不易的教訓，為讀者提供正式的維度設計和開發技術。DW/BI系統必須以業務使用者的需求來驅動，如此才能真正從維度角度設計和展現。我們堅信，如果您能夠接受這一前提，將會朝建立成功的DW/BI系統邁出巨大的一步。
既然知道從何開始，請開始仔細閱讀本書。在第1章中將討論DW/BI和維度建模的基本內容，確保每個人對關鍵術語和結構性概念具有統一的認識。

第1章 資料倉庫、商業智慧及維度建模初步 1
1.1 資料獲取與資料分析的區別 1
1.2 資料倉庫與商業智慧的目標 2
1.3 維度建模簡介 5
1.3.1 星型模式與OLAP多維資料庫 6
1.3.2 用於度量的事實表 7
1.3.3 用於描述環境的維度表 9
1.3.4 星型模式中維度與事實的連接 11
1.4 Kimball的DW／BI架構 14
1.4.1 操作型源系統 14
1.4.2 獲取—轉換—載入（ETL）系統 14
1.4.3 用於支援商業智慧決策的展現區 16
1.4.4 商業智慧應用 17
1.4.5 以餐廳為例描述Kimball架構 17
1.5 其他DW／BI架構 19
1.5.1 獨立資料集市架構 19
1.5.2 輻射狀企業資訊工廠Inmon架構 20
1.5.3 混合輻射狀架構與Kimball架構 22
1.6 維度建模神話 22
1.6.1 神話1：維度模型僅包含匯總資料 23
1.6.2 神話2：維度模型是部門級而不是企業級的 23
1.6.3 神話3：維度模型是不可擴展的 23
1.6.4 神話4：維度模型僅用於預測 23
1.6.5 神話5：維度模型不能被集成 24
1.7 考慮使用維度模型的更多理由 24
1.8 本章小結 25
第2章 Kimball維度建模技術概述 27
2.1 基本概念 27
2.1.1 收集業務需求與資料實現 27
2.1.2 協作維度建模研討 27
2.1.34步驟維度設計過程 28
2.1.4 業務過程 28
2.1.5 細微性 28
2.1.6 描述環境的維度 28
2.1.7 用於度量的事實 29
2.1.8 星型模式與OLAP多維資料庫 29
2.1.9 方便地擴展到維度模型 29
2.2 事實表技術基礎 29
2.2.1 事實表結構 29
2.2.2 可加、半可加、不可加事實 29
2.2.3 事實表中的空值 30
2.2.4 一致性事實 30
2.2.5 事務事實表 30
2.2.6 週期快照事實表 30
2.2.7 累積快照事實表 30
2.2.8 無事實的事實表 31
2.2.9 聚集事實表或OLAP多維資料庫 31
2.2.10 合併事實表 31
2.3 維度表技術基礎 31
2.3.1 維度表結構 31
2.3.2 維度代理鍵 32
2.3.3 自然鍵、持久鍵和超自然鍵 32
2.3.4 下鑽 32
2.3.5 退化維度 32
2.3.6 非規範化扁平維度 32
2.3.7 多層次維度 32
2.3.8 文件屬性的標識與指示器 33
2.3.9 維度表中的空值屬性 33
2.3.10 日曆日期維度 33
2.3.11 扮演角色的維度 33
2.3.12 雜項維度 33
2.3.13 雪花維度 33
2.3.14 支架維度 34
2.4 使用一致性維度集成 34
2.4.1 一致性維度 34
2.4.2 縮減維度 34
2.4.3 跨表鑽取 34
2.4.4 價值鏈 34
2.4.5 企業資料倉庫匯流排架構 35
2.4.6 企業資料倉庫匯流排矩陣 35
2.4.7 匯流排矩陣實現細節 35
2.4.8 機會／利益相關方矩陣 35
2.5 處理緩慢變化維度屬性 35
2.5.1 類型0：原樣保留 35
2.5.2 類型1：重寫 35
2.5.3 類型2：增加新行 36
2.5.4 類型3：增加新屬性 36
2.5.5 類型4：增加微型維度 36
2.5.6 類型5：增加微型維度及類型1支架 36
2.5.7 類型6：增加類型1屬性到類型2維度 36
2.5.8 類型7：雙類型1和類型2維度 36
2.6 處理維度層次關係 37
2.6.1 固定深度位置的層次 37
2.6.2 輕微參差不齊／可變深度層次 37
2.6.3 具有層次橋接表的參差不齊／可變深度層次 37
2.6.4 具有路徑字元屬性的可變深度層次 37
2.7 高級事實表技術 37
2.7.1 事實表代理鍵 37
2.7.2 蜈蚣事實表 38
2.7.3 屬性或事實的數位值 38
2.7.4 日誌／持續時間事實 38
2.7.5 頭／行事實表 38
2.7.6 分配的事實 38
2.7.7 利用分配建立利潤與損失事實表 38
2.7.8 多種貨幣事實 39
2.7.9 多種度量事實單位 39
2.7.10 年—日事實 39
2.7.11 多遍SQL以避免事實表間的連接 39
2.7.12 針對事實表的時間跟蹤 39
2.7.13 遲到的事實 40
2.8 高級維度技術 40
2.8.1 維度表連接 40
2.8.2 多值維度與橋接表 40
2.8.3 隨時間變化的多值橋接表 40
2.8.4 標籤的時間序列行為 40
2.8.5 行為研究分組 40
2.8.6 聚集事實作為維度屬性 41
2.8.7 動態值範圍 41
2.8.8 文本注釋維度 41
2.8.9 多時區 41
2.8.10 度量類型維度 41
2.8.11 步驟維度 41
2.8.12 熱交換維度 42
2.8.13 抽象通用維度 42
2.8.14 審計維度 42
2.8.15 最後產生的維度 42
2.9 特殊目的模式 42
2.9.1 異構產品的超類與子類模式 43
2.9.2 即時事實表 43
2.9.3 錯誤事件模式 43
第3章 零售業務 45
3.1 維度模型設計的4步過程 46
3.1.1 第1步：選擇業務過程 46
3.1.2 第2步：聲明細微性 46
3.1.3 第3步：確定維度 47
3.1.4 第4步：確定事實 47
3.2 零售業務案例研究 47
3.2.1 第1步：選擇業務過程 49
3.2.2 第2步：聲明細微性 49
3.2.3 第3步：確定維度 50
3.2.4 第4步：確定事實 50
3.3 維度表設計細節 53
3.3.1 日期維度 53
3.3.2 產品維度 56
3.3.3 商店維度 59
3.3.4 促銷維度 60
3.3.5 其他零售業維度 62
3.3.6 交易號碼的退化維度 63
3.4 實際的銷售模式 63
3.5 零售模式的擴展能力 64
3.6 無事實的事實表 65
3.7 維度與事實表鍵 66
3.7.1 維度表代理鍵 66
3.7.2 維度中自然和持久的超自然鍵 68
3.7.3 退化維度的代理鍵 68
3.7.4 日期維度的智能鍵 68
3.7.5 事實表的代理鍵 69
3.8 抵制規範化的衝動 70
3.8.1 具有規範化維度的雪花模式 70
3.8.2 支架表 72
3.8.3 包含大量維度的蜈蚣事實表 72
3.9 本章小結 74
第4章 庫存 75
4.1 價值鏈簡介 75
4.2 庫存模型 76
4.2.1 庫存週期快照 76
4.2.2 庫存事務 79
4.2.3 庫存累積快照 80
4.3 事實表類型 81
4.3.1 事務事實表 81
4.3.2 週期快照事實表 82
4.3.3 累積快照事實表 82
4.3.4 輔助事實表類型 83
4.4 價值鏈集成 83
4.5 企業資料倉庫匯流排架構 84
4.5.1 理解匯流排架構 84
4.5.2 企業資料倉庫匯流排矩陣 85
4.6 一致性維度 89
4.6.1 多事實表鑽取 89
4.6.2 相同的一致性維度 89
4.6.3 包含屬性子集的縮減上卷一致性維度 90
4.6.4 包含行子集的縮減一致性維度 91
4.6.5 匯流排矩陣的縮減一致性維度 91
4.6.6 有限一致性 92
4.6.7 資料治理與管理的重要性 92
4.6.8 一致性維度與敏捷開發 94
4.7 一致性事實 94
4.8 本章小結 95
第5章 採購 97
5.1 採購案例研究 97
5.2 採購事務與匯流排矩陣 98
5.2.1 單一事務事實表與多事務事實表 98
5.2.2 輔助採購快照 101
5.3 緩慢變化維度（SCD）基礎 101
5.3.1 類型0：保留原始值 102
5.3.2 類型1：重寫 102
5.3.3 類型2：增加新行 104
5.3.4 類型3：增加新屬性 106
5.3.5 類型4：增加微型維度 108
5.4 混合緩慢變化維度技術 110
5.4.1 類型5：微型維度與類型1支架表 110
5.4.2 類型6：將類型1屬性增加到類型2維度 111
5.4.3 類型7：雙重類型1與類型2維度 112
5.5 緩慢變化維度總結 113
5.6 本章小結 114
第6章 訂單管理 115
6.1 訂單管理匯流排矩陣 116
6.2 訂單事務 116
6.2.1 事實表規範化 117
6.2.2 維度角色扮演 117
6.2.3 重新審視產品維度 119
6.2.4 客戶維度 120
6.2.5 交易維度 122
6.2.6 針對訂單號的退化維度 123
6.2.7 雜項維度 124
6.2.8 應該避免的表頭／明細模式 125
6.2.9 多幣種 126
6.2.10 不同細微性的事務事實 128
6.2.11 另外一種需要避免的表頭／明細模式 129
6.3 發票事務 130
6.3.1 作為事實、維度或兩者兼顧的服務級性能 131
6.3.2 利潤與損益事實 131
6.3.3 審計維度 133
6.4 用於訂單整個流水線的累積快照 134
6.4.1 延遲計算 136
6.4.2 多種度量單位 137
6.4.3 超越後視鏡 138
6.5 本章小結 138
第7章 會計 139
7.1 會計案例研究與匯流排矩陣 139
7.2 總帳數據 141
7.2.1 總帳週期快照 141
7.2.2 會計科目表 141
7.2.3 結帳 141
7.2.4 年度—日期事實 143
7.2.5 再次討論多幣種問題 143
7.2.6 總帳日記帳事務 143
7.2.7 多種財務會計日曆 144
7.2.8 多級別層次下鑽 145
7.2.9 財務報表 145
7.3 預算編制過程 146
7.4 維度屬性層次 148
7.4.1 固定深度的位置層次 148
7.4.2 具有輕微不整齊的可變深度層次 149
7.4.3 不整齊可變深度層次 149
7.4.4 不規則層次中的共用所有權 152
7.4.5 隨時間變化的不規則層次 153
7.4.6 修改不規則層次 153
7.4.7 其他不規則層次的建模方法 154
7.4.8 應用於不規則層次的橋接表方法的優點 156
7.5 合併事實表 156
7.6 OLAP角色及分析方案包 157
7.7 本章小結 158
第8章 客戶關係管理 159
8.1 客戶關係管理概述 160
8.2 客戶維度屬性 162
8.2.1 名字與位址的語法分析 162
8.2.2 國際姓名和地址的考慮 164
8.2.3 客戶為中心的日期 165
8.2.4 作為維度屬性的聚集事實 166
8.2.5 分段屬性與記分 166
8.2.6 包含類型2維度變化的計算 169
8.2.7 低細微性屬性集合的支架表 169
8.2.8 客戶層次的考慮 170
8.3 應用於多值維度的橋接表 171
8.3.1 稀疏屬性的橋接表 172
8.3.2 應用于客戶多種聯繫方式的橋接表 173
8.4 複雜的客戶行為 173
8.4.1 客戶佇列的行為研究分組 173
8.4.2 連續行為的步驟維度 175
8.4.3 時間範圍事實表 176
8.4.4 使用滿意度指標標記事實表 177
8.4.5 使用異常情景指標標記事實表 178
8.5 客戶資料集成方法 178
8.5.1 建立單一客戶維度的主資料管理 179
8.5.2 多客戶維度的局部一致性 180
8.5.3 避免對應事實表的連接 180
8.6 低延遲的實現檢查 181
8.7 本章小結 182
第9章 人力資源管理 183
9.1 雇員檔案跟蹤 183
9.1.1 精確的有效和失效時間範圍 184
9.1.2 維度變化原因跟蹤 185
9.1.3 作為類型2屬性或事實事件的檔案變化 185
9.2 雇員總數週期快照 186
9.3 人力資源過程的匯流排矩陣 187
9.4 分析解決方案套裝軟體與資料模型 188
9.5 遞迴式雇員層次 189
9.5.1 針對嵌入式經理主鍵變化的跟蹤 190
9.5.2 上鑽或下鑽管理層次 190
9.6 多值技能關鍵字屬性 191
9.6.1 技能關鍵字橋接表 191
9.6.2 技能關鍵字文本字串 192
9.7 調查問卷資料 193
9.8 本章小結 194
第10章 金融服務 195
10.1 銀行案例研究與匯流排矩陣 195
10.2 分類維度以避免出現維度太少的情況 196
10.2.1 家庭維度 199
10.2.2 多值維度與權重因數 199
10.2.3 再談微型維度 200
10.2.4 在橋接表中增加微型維度 202
10.2.5 動態值範圍事實 202
10.3 異構產品的超類和子類模式 203
10.4 熱可交換維度 205
10.5 本章小結 205
第11章 電信 207
11.1 電信業案例研究與匯流排矩陣 207
11.2 設計評審的一般性考慮 209
11.2.1 業務需求與實際可用資源的權衡 209
11.2.2 關注業務過程 209
11.2.3 細微性 210
11.2.4 統一的事實表細微性 210
11.2.5 維度的細微性和層次 210
11.2.6 日期維度 211
11.2.7 退化維度 211
11.2.8 代理鍵 212
11.2.9 維度解碼與描述符 212
11.2.10 一致的承諾 212
11.3 設計評審指導 212
11.4 草案設計訓練的討論 214
11.5 重新建模已存在的資料結構 215
11.6 地理位置維度 216
11.7 本章小結 216
第12章 交通運輸 217
12.1 航空案例研究與匯流排矩陣 217
12.1.1 多種事實表細微性 218
12.1.2 連接區段形成旅程 220
12.1.3 相關事實表 221
12.2 擴展至其他行業 221
12.2.1 貨物托運人 221
12.2.2 旅行服務 222
12.3 相關維度合併 222
12.3.1 服務類別 223
12.3.2 始發地與目的地 224
12.4 更多有關日期和時間的考慮 225
12.4.1 用作支架表的特定國家日曆 225
12.4.2 多時區的日期和時間 226
12.5 當地語系化概要 226
12.6 本章小結 227
第13章 教育 229
13.1 大學案例研究與匯流排矩陣 229
13.2 累積快照事實表 231
13.2.1 申請流水線 231
13.2.2 科研資助專案流水線 232
13.3 無事實的事實表 232
13.3.1 招生事件 233
13.3.2 課程註冊 233
13.3.3 設施使用 235
13.3.4 學生考勤 236
13.4 更多關於教育分析的情況 237
13.5 本章小結 237
第14章 醫療衛生 239
14.1 醫療衛生案例研究與匯流排矩陣 239
14.2 報銷單據與支付 241
14.2.1 日期維度角色扮演 243
14.2.2 多值診斷 243
14.2.3 收費的超類與子類 245
14.3 電子醫療記錄 246
14.3.1 度量稀疏事實的類型維度 246
14.3.2 自由文本注釋 247
14.3.3 圖像 247
14.4 設施／設備的庫存利用 247
14.5 處理可追溯的變化 248
14.6 本章小結 248
第15章 電子商務 249
15.1 點擊流來源資料 249
15.2 點擊流維度模型 252
15.2.1 網頁維度 252
15.2.2 事件維度 253
15.2.3 會話維度 254
15.2.4 推薦維度 254
15.2.5 點擊流會話事實表 255
15.2.6 點擊流網頁事件事實表 256
15.2.7 步驟維度 258
15.2.8 聚集點擊流事實表 258
15.2.9 Google Analytics（GA） 259
15.3 將點擊流集成到Web零售商匯流排矩陣中 259
15.4 包含Web的跨管道贏利能力 261
15.5 本章小結 263
第16章 保險業務 265
16.1 保險案例研究 266
16.1.1 保險業價值鏈 266
16.1.2 匯流排矩陣草案 267
16.2 保單事務 268
16.2.1 維度角色扮演 268
16.2.2 緩慢變化維度 268
16.2.3 針對大型和快速變化維度的微型維度 269
16.2.4 多值維度屬性 269
16.2.5 作為事實或維度的數值屬性 270
16.2.6 退化維度 270
16.2.7 低細微性維度表 270
16.2.8 審計維度 270
16.2.9 保單事務事實表 270
16.2.10 異構的超類和子類產品 271
16.2.11 輔助保險累積快照 272
16.3 保費週期快照 272
16.3.1 一致性維度 272
16.3.2 一致性事實 273
16.3.3 預付事實 273
16.3.4 再談異構超類與子類 273
16.3.5 再談多值維度 274
16.4 更多保險案例研究背景 274
16.4.1 更新保險行業匯流排矩陣 275
16.4.2 匯流排矩陣實現細節 275
16.5 索賠事務 277
16.6 索賠累積快照 278
16.6.1 複雜工作流的累積快照 279
16.6.2 時間範圍累積快照 279
16.6.3 週期而不是累積快照 280
16.7 保單／索賠合併的週期快照 280
16.8 無事實的意外事件 280
16.9 需要避免的常見維度建模錯誤 281
16.9.1 錯誤10：在事實表中放入文字屬性 281
16.9.2 錯誤9：限制使用冗長的描述符以節省空間 281
16.9.3 錯誤8：將層次劃分為多個維度 282
16.9.4 錯誤7：忽略對維度變化進行跟蹤的需要 282
16.9.5 錯誤6：使用更多的硬體解決所有的性能問題 282
16.9.6 錯誤5：使用操作型鍵連接維度和事實 282
16.9.7 錯誤4：忽視對事實細微性的聲明並混淆事實細微性 282
16.9.8 錯誤3：使用報表設計維度模型 283
16.9.9 錯誤2：希望使用者查詢規範化的原子資料 283
16.9.10 錯誤1：違反事實和維度的一致性要求 283
16.10 本章小結 284
第17章 Kimball DW／BI生命週期概述 285
17.1 生命週期路標 286
17.2 生命週期初始活動 287
17.2.1 程式／專案規劃與管理 287
17.2.2 業務需求定義 290
17.3 生命週期技術路徑 294
17.3.1 技術架構設計 294
17.3.2 產品選擇與安裝 296
17.4 生命週期資料路徑 297
17.4.1 維度建模 297
17.4.2 物理設計 297
17.4.3 ETL設計與開發 299
17.5 生命週期BI應用路徑 299
17.5.1 BI應用規範 299
17.5.2 BI應用開發 299
17.6 生命週期總結活動 300
17.6.1 部署 300
17.6.2 維護和發展 300
17.7 應當避免的常見錯誤 301
17.8 本章小結 302
第18章 維度建模過程與任務 303
18.1 建模過程概述 303
18.2 組織工作 304
18.2.1 確定參與人，特別是業務代表們 304
18.2.2 業務需求評審 305
18.2.3 利用建模工具 305
18.2.4 利用資料分析工具 306
18.2.5 利用或建立命名規則 306
18.2.6 日曆和設施的協調 306
18.3 維度模型設計 307
18.3.1 統一對高層氣泡圖的理解 307
18.3.2 開發詳細的維度模型 308
18.3.3 模型評審與驗證 311
18.3.4 形成設計文檔 312
18.4 本章小結 312
第19章 ETL子系統與技術 313
19.1 需求綜合 314
19.1.1 業務需求 314
19.1.2 合規性 314
19.1.3 資料品質 314
19.1.4 安全性 315
19.1.5 資料集成 315
19.1.6 資料延遲 316
19.1.7 歸檔與世系 316
19.1.8 BI發佈介面 316
19.1.9 可用的技能 317
19.1.10 傳統的許可證書 317
19.2 ETL的34個子系統 317
19.3 獲取：將資料插入到資料倉庫中 318
19.3.1 子系統1：資料分析 318
19.3.2 子系統2：變化資料獲取系統 319
19.3.3 子系統3：獲取系統 320
19.4 清洗與整合數據 321
19.4.1 提高資料品質文化與過程 322
19.4.2 子系統4：資料清洗系統 323
19.4.3 子系統5：錯誤事件模式 324
19.4.4 子系統6：審計維度裝配器 325
19.4.5 子系統7：重復資料刪除（deduplication）系統 326
19.4.6 子系統8：一致性系統 326
19.5 發佈：準備展現 328
19.5.1 子系統9：緩慢變化維度管理器 328
19.5.2 子系統10：代理鍵產生器 332
19.5.3 子系統11：層次管理器 332
19.5.4 子系統12：特定維度管理器 333
19.5.5 子系統13：事實表建立器 335
19.5.6 子系統14：代理鍵流水線 336
19.5.7 子系統15：多值維度橋接表建立器 337
19.5.8 子系統16：遲到資料處理器 338
19.5.9 子系統17：維度管理器系統 339
19.5.10 子系統18：事實提供者系統 339
19.5.11 子系統19：聚集建立器 340
19.5.12 子系統20：OLAP多維資料庫建立器 340
19.5.13 子系統21：資料傳播管理器 340
19.6 管理ETL環境 341
19.6.1 子系統22：任務調度器 341
19.6.2 子系統23：備份系統 342
19.6.3 子系統24：恢復與重啟系統 343
19.6.4 子系統25：版本控制系統 344
19.6.5 子系統26：版本遷移系統 345
19.6.6 子系統27：工作流監視器 345
19.6.7 子系統28：排序系統 346
19.6.8 子系統29：世系及依賴分析器 346
19.6.9 子系統30：問題提升系統 346
19.6.10 子系統31：並行／流水線系統 347
19.6.11 子系統32：安全系統 347
19.6.12 子系統33：合規性管理器 348
19.6.13 子系統34：中繼資料存儲庫管理器 350
19.7 本章小結 350
第20章 ETL系統設計與開發過程和任務 351
20.1 ETL過程概覽 351
20.2 ETL開發規劃 351
20.2.1 第1步：設計高層規劃 352
20.2.2 第2步：選擇ETL工具 352
20.2.3 第3步：開發默認策略 353
20.2.4 第4步：按照目標表鑽取資料 354
20.2.5 開發ETL規範文檔 355
20.3 開發一次性的歷史載入過程 356
20.3.1 第5步：用歷史資料填充維度表 356
20.3.2 第6步：完成事實表歷史載入 360
20.4 開發增量式ETL過程 363
20.4.1 第7步：維度表增量處理過程 363
20.4.2 第8步：事實表增量處理過程 365
20.4.3 第9步：聚集表與OLAP載入 367
20.4.4 第10步：ETL系統操作與自動化 368
20.5 即時的影響 368
20.5.1 即時分類 369
20.5.2 即時結構權衡 370
20.5.3 展現伺服器上的即時分區 371
20.6 本章小結 372
第21章 大資料分析 373
21.1 大數據概覽 373
21.1.1 擴展的RDBMS結構 374
21.1.2 MapReduce／Hadoop結構 375
21.1.3 大資料結構比較 376
21.2 推薦的應用於大資料的最佳實踐 376
21.2.1 面向大資料管理的最佳實踐 376
21.2.2 面向大資料結構的最佳實踐 377
21.2.3 應用於大資料的資料建模最佳實踐 381
21.2.4 大資料的資料治理最佳實踐 383
21.3 本章小結 384

使用事實表代理鍵作為父／子模式中的父節點。一個事實表包含的行是另外細微性更細的事實表的父指針。父表中的事實表代理鍵也會暴露在子表中。使用事實表代理鍵而不使用自然父鍵與在維度表中使用代理鍵一樣都存在爭議。自然鍵是混亂且無法預測的，然而代理鍵是明確的整數並由ETL系統分配，而不是由源系統分配。當然，除了包括父事實表的代理鍵外，低細微性事實表包括父節點的維度外鍵，因此子事實表也包括父維度的外鍵，因此子事實不必遍歷父事實表的代理鍵就可以被分片或分塊。我們將在第4章中討論，您不應當直接將事實表與其他事實表連接。
3.8 抵制規範化的衝動
本節將直接面對幾個誘使具有規範化建模背景的建模者採用規範化建模的自然衝動。我們一直在有意識地打破傳統建模規則，因為我們主要關注體現易用性和性能的價值，而不是關注交易處理的效率。
3.8.1 具有規範化維度的雪花模式
帶有重複文本的扁平非規範化維度表使來自操作型世界的資料建模者非常不舒服。讓我們回到案例研究的產品維度表。300000個產品上卷到50個不同的部門。不是冗餘地存儲20個位元組的部門描述在產品維度表中，具有規範化閱歷的建模者希望存儲2位元組部門代碼，並為部門編碼建立新的部門維度。事實上，如果原始設計中的所有描述符都被規範地放入不同的維度中，他們會感到更滿意。他們認為這樣的設計節省了空間，因為300000行維度表僅包含代碼，沒有冗長的描述符。
此外，一些建模者主張，維度表越規範則越容易管理。如果部門描述符發生變化，他們只需要更新部門維度，而不需要在原始產品維度中執行6000次重複工作。維護通常由規範化處理解決，但所有這些都發生在ETL系統後端，距離資料被載入到展現區的維度模式中已經有很長時間了。
規範化的維度表被稱為雪花模式。冗餘屬性從扁平非規範化維度表中移除，放置於不同規範化的維度表中。