1.3 什么是數據倉庫

1.3.1 數據倉庫的定義

W.H.Inmon在1992年出版的《Building the Data Warehouse》一書中，將數據倉庫（Data Warehouse，DW）定義為一個面向主題的（Subject Oriented）、集成的（Integrated）、相對穩定的（Non-Volatile）、反映歷史變化（TimeVariant）的數據集合，用于支持管理決策和信息的全局共享。

商業數據處理大致可以分成兩大類：聯機事務處理OLTP（On-Line Transaction Processing）、聯機分析處理OLAP（On-Line Analytical Processing）。OLTP是傳統的關系型數據庫的主要應用，主要進行基本的、日常的事務處理，例如銀行交易。OLAP是數據倉庫系統的主要應用，支持復雜的分析操作，側重決策支持，并且提供直觀、易懂的查詢結果。從面向事務處理到面向分析處理的系統使用中，如何將面向事務系統中的數據與數據倉庫中的數據建立聯系是建立數據倉庫必須解決的問題。

OLTP包含巨量數據的更新，并提供對重要數據的近實時訪問，包括讓企業更有競爭力的數據。OLAP提供近乎實時的虛擬數據倉庫；對主數據管理的負載均衡更新，能提升企業信息化架構的靈活度。

OLTP與OLAP的對比分析如表1-3所示。

表1-3 OLTP與OLAP的對比分析

續表

1.3.2 數據倉庫的特點

數據倉庫主要有以下特點。

1.面向主題

數據倉庫面向不同的主題域進行組織，一個主題通常與多個操作型信息系統相關。例如一個數據倉庫可以包含“客戶”“產品”“收入”等主題。

2.集成性

數據倉庫中的數據從建立時開始，面向整個企業的分析處理，數據倉庫中的數據是已經集成的統一數據源或者是經過綜合和計算后的數據。

3.相對穩定

若將某個數據記錄存入數據倉庫，則不能再對其進行修改或刪除的操作。數據需要定期加載，加載后的數據極少更新。

4.反映歷史變化

數據倉庫中的數據能夠反映歷史變化，許多商業分析要求對發展趨勢做出預測，對發展趨勢的分析需要訪問歷史數據。

1.3.3 數據倉庫的建模

數據倉庫的星型模式、雪花模式描述了數據倉庫主題的邏輯實現，即每個主題對應了關系表的關系模式定義。

1.星型模型

（1）星型模型（Star Schema）的定義。星型模型是最常見的模型范例，其中包括了一個包含大批數據和不含冗余的中心表，即事實表；還包括了一組小的附屬表，即維表；維表圍繞事實表，并顯示在中心射線上，如圖1-10所示。在實際應用中，隨著事實表和維表的增加和變化，星型模型會產生多種衍生模型，包括星系模型、星座模型、二級維表和雪花模型。

星型模型的特點：簡化了用戶分析所需的關系，從支持決策的角度去定義數據實體，更適合大量的復雜的查詢。每個維表有自己的屬性。維表和事實表通過關鍵字相關聯。維表的本質是多維分析空間在某個角度上的投影，多個維表共同建立一個多維分析空間。

圖1-10所示的星型模式中，位于中心的sales稱為事實表，其把各種不同的維表連接起來。它共有四維，分別是time維表、item維表、branch維表和location維表。sales事實表包含了四個維的關鍵字和兩個度量（unit_sold、dollars_sold）。每個維表都分配有一個代理鍵（Surrogate Key，SK）。作為維表的唯一標識符，代理鍵沒有內在的含義，通常表現為一個整數。

圖1-10 sales數據倉庫的星型模型

（2）星型模型事實表的特征。事實表的特征歸納為：主鍵是所有維表主鍵連接起來的組合鍵，數據粒度小，有求和計算的關鍵指標，屬性個數與記錄條數相比數量非常少，存在稀疏數據。詳細描述如下。

① 事實表的主鍵是所有維表主鍵連接起來的組合鍵。例如，在圖1-10中，sales事實表中的主鍵是四個維表主鍵的組合。

② 事實表中的一條記錄應與所有維表中的記錄相關。例如，在圖1-10中，sales事實表中的一條記錄對應了某個產品在某個日子、某個經銷商、某個地區的具體銷售數據。

③ 事實表數據粒度小。數據粒度是事實表中關鍵指標的細節程度。事實表中應保存級別盡可能低的細節數據，因為這樣可以從OLTP中抽取出數據而不進行匯總，讓用戶通過數據倉庫可以下鉆到最低層次的細節數據，另外很多數據挖掘應用程序需要最低粒度的細節數據。

④ 事實表應滿足已有關鍵指標計算和衍生指標計算的需求。

⑤ 事實表中的屬性個數較少，而記錄條數較多。

⑥ 維表屬性的一些組合查詢方式可能會造成事實表中關鍵指標值為空的情況，形成稀疏數據存在的情況。

（3）星型模型維表的特征。維表的特征歸納為：維表主鍵唯一確定一條記錄、有大量的屬性、大多為文本格式的屬性、有非直接相關的屬性、為非規范化的表、具有上鉆/下鉆功能、具有多層次結構、記錄條數比事實表少。詳細描述如下。

① 維表的主鍵應唯一確定該維表的一條記錄。

② 維表有大量的屬性。一個維表可以有相當多的屬性。例如，有些維表屬性個數會超過50個。

③ 維表中的屬性一般是文本格式的。這是由商業需求及所分析的問題決定的。這些屬性代表了商業維度中的組成部分的文本描述，用戶可利用這些描述構造查詢需求。

④ 維表中的一些屬性可不與其中的其他屬性直接相關，例如，item表中的brand與type不是直接相關的，但兩者都是維表的屬性。

⑤ 維表是非規范化的。維表中的一個屬性可作為一個約束條件直接應用于事實表中的關鍵指標查詢，以使查詢效率更高，即最好直接從維表中獲得一個屬性，然后直接查詢事實表，不需要通過其他中間表。但是如果維表規范化了，就需要建立中間表，從而使查詢效率低。

⑥ 維表具有上鉆/下鉆功能。維表中的屬性應具有獲取從高層次匯總數據及到低層次細節數據的功能，例如，location表中包含屬性street、city、province_or_state、country。用戶可以查詢country總量，可下鉆到province_or_state，也可進一步下鉆到city、street。

⑦ 維表中的屬性可具有多種多級的層次結構，例如，在item表中，市場部可以按自己的分類方法將產品歸類到產品目錄及產品部門中，財務部可以按自己的分類方法將產品歸類到產品目錄及產品部門中。

⑧ 維表中的記錄條數通常都比中心事實表中的記錄條數少，例如，在圖1-10中，time維表、item維表、branch維表和location維表中的記錄數是有限的，數量相對穩定，不像事實表隨著交易的產生，會不停地增加記錄。

（4）星型模型的優勢。星型模型能夠將用戶決策思維問題準確地轉換為邏輯上的一個中心事實表和多個維表，并以二維表結構的屬性描述方式直觀地進行呈現，其優勢表現在如下3個方面。

① 用戶容易理解星型模型。維表包含了決策者經常查詢和分析的屬性，而中心事實表又包含了決策者衡量職能部門業績的指標。這些指標表明了職能部門任務的完成情況。因此，決策者很容易理解數據倉庫的星型模型。這就使得數據倉庫開發人員能非常方便地與決策者就業務需求進行交流。

② 優化瀏覽方式。關系表的結構提供了操作數據倉庫數據的能力，運用表之間的連接路徑，可很快地從一個表轉移到另一個表，以加速查詢瀏覽的過程。

③ 適用于查詢處理。星型模型的查詢處理實際上是使用一些簡單的參數過濾維表的過程，以得到一些維表的結果，再從中心事實表中得到相應的結果集。在維表與中心事實表之間存在簡單且清晰的連接，使得星型模型適用于以查詢為中心的操作環境，適合于追蹤查詢多條件限制的關鍵指標。

2.雪花型模型

（1）雪花模型（Snowflake Schema）的定義。雪花模型是由星型模型進一步演化而形成的。它將星型模型中的某些維表進行了規范化，并將數據進一步分解到附加表中。如圖1-11所示，該圖表示了sales數據倉庫從星型模型到雪花模型的分解狀態。

圖1-11 sales數據倉庫的雪花模型

雪花模型和星型模型的主要不同之處在于，雪花模型的維表可能是規范化的，以減少冗余。這種表易于維護，并可節省存儲空間。由于在執行查詢的過程中，需要進行更多的連接操作，所以，在數據倉庫的初步設計過程中，若采用雪花模型，則會降低查詢結果的反饋性能，并將直接影響到系統的性能。

（2）雪花模型的特點。雪花模型是對星型模型維表的進一步層次化，是將某些維表擴展成事實表。這樣既可以應付不同級別用戶的查詢，也可以將源數據通過層次間的聯系向上綜合，從而最大限度地減少數據存儲量，因而提高了查詢功能。

雪花模型的維度表是基于范式理論的，是界于第三范式和星型模型之間的一種設計模型。通常情況下，部分數據組織采用第三范式的規范結構，部分數據組織采用星型模型的事實表和維表結構。在某些情況下，星型模型在組織數據時，為減少維表層次和處理多對多關系而對數據表進行規范化處理后形成了雪花模型。

雪花模型比較復雜，用戶不容易理解，瀏覽內容相對困難；額外的連接將使查詢性能下降。在數據倉庫中，通常不推薦“雪花化”，因為數據倉庫需要更加優良的查詢性能，而雪花模型會降低數據倉庫系統的查詢性能。在雪花模型中，有些數據需要連接才能獲取，可能效率較低；規范化操作較復雜，導致設計及后期維護復雜。

實際應用中，可以采取上述兩種模型的混合體，比如，中間層使用雪花模型以降低數據冗余度，數據集市部分采用星型模型以方便數據提取及分析。

1.3.4 數據集市的定義

數據集市（Data Mart，DM）也稱為數據市場，是一個從操作的數據和其他的為某個特殊的專業團體服務的，在數據源中收集數據的倉庫。數據倉庫是企業級的，能為整個企業各部門的運行提供決策支持手段。數據集市是部門級別的，一般只能為某個局部范圍內的管理人員服務，也稱為部門級的數據倉庫。數據倉庫與數據集市的區別如表1-4所示。

表1-4 數據倉庫與數據集市的區別

1.3.5 數據倉庫的體系結構

構建一個數據倉庫體系結構，完成對數據的集成、整合、加工、質量等多方面的基礎管理，從而滿足分析利用型需求的不斷變化、擴展，保證應用系統長久的生命力。構建數據倉庫體系結構，往往是項目過程中最難的一項工作。它包括建模、ETL、數據質量、元數據等不同領域的銜接和配合。

圖1-12所示的體系架構的重點放在目標端需求，以及對目標端需求的預測和評估上。通過理解不同數據集市層的需求來規劃、抽象數據倉庫的核心主題，并規劃每一個主題下的度量，以及度量對應的最細顆粒度的維度和維度層次、成員。這種架構方法便于快速捕捉業務、理解業務，從而構建出數據模型。但是，在數據倉庫的ETL開發時的主要難點在于，將分散在不同數據庫的符合第三范式的事務級數據聚合和組織到維度格式的數據倉庫模型中。

圖1-12 數據倉庫的體系架構

1.3.6 數據倉庫的數據及組織

數據倉庫中存儲兩類數據：元數據和業務數據。

元數據又稱中介數據、中繼數據，為描述數據的數據，主要是描述數據屬性的信息，用來支持如指示存儲位置、歷史數據、資源查找、文件記錄等功能。在數據倉庫領域中，元數據按用途分成技術元數據和業務元數據。技術元數據是關于數據倉庫系統技術細節的描述數據，是數據倉庫開發人員和管理人員需要使用的重要信息，主要包括數據倉庫結構的描述等，主要服務對象是技術人員。業務元數據是從業務角度描述數據倉庫中的數據。它提供了介于使用者和實際系統之間的語義層定義，使得不懂計算機技術的業務人員也能夠理解數據倉庫中的數據，主要用戶是商務人員。

業務數據又分為細節數據和綜合數據。元數據經過抽取、轉換后，首先進入當前細節級，再根據具體需要進行進一步的綜合，從而進入輕度綜合級乃至高度綜合級。老化的數據進入早期細節級。業務數據的級別劃分如圖1-13所示。

圖1-13 業務數據的級別劃分

粒度是衡量數據倉庫中數據綜合程度高低的一個度量。數據粒度是數據倉庫的重要概念。粒度越小，細節程度越高，綜合程度越低。在數據倉庫中，多重粒度是必不可少的。確定粒度是數據倉庫開發者需要面對的一個重要的設計問題。如果數據倉庫的粒度確定合理，則設計和實現中的其余方面就可以非常順暢地進行。

不同的情況組織數據的粒度會不同。例如，在銷售數據中，細節數據——記錄每一筆銷售情況；輕度綜合數據——記錄每天的銷售情況；高度綜合數據——記錄每月的銷售情況。