資料倉庫建設
1.資料倉庫概要
1.1.資料倉庫起因
在建設資料倉庫之前，資料散落在企業各部門應用的資料儲存中，它們之間有著複雜的業務連線關係，從整體上看就如一張巨大的蜘蛛網：結構上錯綜複雜，卻又四通八達。在企業級資料應用上單一業務使用方便，且靈活多變；但涉及到跨業務、多部門聯合應用就會存在：①資料來源多樣化，管理決策資料過於分散；②資料缺乏標準，難以整合；③資料口徑不統一，可信度低；④缺乏資料管控體系，資料質量難以保證。如下圖：
如果企業在資料建設方面沒有一個整體的規劃，而採取自然演化的方式，那麼在未來資料應用的過程中，將不得不面對以下問題：
- 資料缺乏可信性：缺乏統一的維度；資料演算法上存在差異；抽取的多層次；外部資料問題；無起始的公共資料來源；
- 生產率低：需要根據全部資料生成企業報表；定位資料需要瀏覽大量檔案；抽取程式很多，並且每個都是定製的，不得不克服很多技術上的障礙。
- 資料轉化為資訊的不可行性：資料沒有整合化；缺乏將資料轉化為資訊所需的歷史資料。
基於以上這些的問題，就產生了建立企業級資料倉庫的必要性。
1.2.資料倉庫發展
資料倉庫的萌芽階段：MIT（麻省理工學院）在20世紀70年代進行了大量研究，經過一系列測試論證，最終提出將業務系統和分析系統分開，將業務處理和分析處理分成不同的層次。也就是如下結論：分析系統和業務系統，只能採用完全不同的架構和設計方法分別處理。
資料倉庫的原理、架構和規範的探索階段：1988年IBM提出了“Information Warehouse”，目標就是為解決企業資料整合問題，在設計上能夠實現“一個結構化的環境，能支援終端使用者管理其全部的業務，並支援資訊科技部門保證資料質量”。但是IBM只是將這種先進的概念用於市場宣傳，而沒有付諸實踐的架構設計。
資料倉庫正式提出：1991年Bill Inmon出版了資料倉庫的第一本書《Buildingthe Data Warehouse》，提出了資料倉庫的概念，闡述了為什麼要建立資料倉庫，並且也給出了建設資料倉庫的方式。
1.3.資料倉庫定義
資料倉庫是一個面向主題的、整合的、相對穩定的、反映歷史變化的（隨著時間流逝發生變化）的資料集合。它主要支援企業管理人員決策分析。資料倉庫收集了企業相關的內部和外部各個業務系統資料來源、歸檔檔案等一系列歷史資料，最後轉化成企業需要的戰略決策資訊。
1.3.1.資料倉庫特點
- 面向主題的：普通的操作型資料庫主要面向事務性處理，而資料倉庫中的所有資料一般按照主題進行劃分。主題是對業務資料的一種抽象，是從較高層次上對資訊系統中的資料進行歸納和整理。面向主題的資料可以劃分成兩部分----根據原系統業務資料的特點進行主題的抽取和確定每個主題所包含的資料內容。例如客戶主題、產品主題、財務主題等；而客戶主題包括客戶基本資訊、客戶信用資訊、客戶資源資訊等內容。分析資料倉庫主題的時候，一般方法是先確定幾個基本的主題，然後再將範圍擴大，最後再逐步求精
- 整合性：面向操作型的資料庫通常是異構的、並且相互獨立，所以無法對資訊進行概括和反映資訊的本質。而資料倉庫中的資料是經過資料的抽取、清洗、切換、載入得到的，所以為了保證資料不存在二義性，必須對資料進行編碼統一和必要的彙總，以保證資料倉庫內資料的一致性。資料倉庫在經歷資料整合階段後，使資料倉庫中的資料都遵守統一的編碼規則，並且消除許多冗餘資料。
- 穩定性：資料倉庫中的資料反映的都是一段歷史時期的資料內容，它的主要操作是查詢、分析而不進行一般意義上的更新（資料整合前的操作型資料庫主要完成資料的增加、修改、刪除、查詢），一旦某個資料進入到資料倉庫後，一般情況下資料會被長期保留，當超過規定的期限才會被刪除。通常資料倉庫需要做的工作就是載入、查詢和分析，一般不進行任何修改操作，是為了企業高層人員決策分析之用。
- 反映歷史變化：資料倉庫不斷從操作型資料庫或其他資料來源獲取變化的資料，從而分析和預測需要的歷史資料，所以一般資料倉庫中資料表的鍵碼（維度）都含有時間鍵，以表明資料的歷史時期資訊，然後不斷增加新的資料內容。通過這些歷史資訊可以對企業的發展歷程和趨勢做出分析和預測。資料倉庫的建設需要大量的業務資料作為積累，並將這些寶貴的歷史資訊經過加工、整理，最後提供給決策分析人員，這是資料倉庫建設的根本目的。
1.3.2.資料倉庫優勢
- 資料整合後資訊流簡化
- 共享資料利用率提高
- 資料集中管理，來源唯一
- 形成業務單一檢視，資料標準化
- 資料管控體系，資料質量得以保證
1.3.3.資料倉庫組成
- 多種多樣的資料來源
- 資料抽取、轉換、匯入（ETL）
- 操作型的資料和分析型的資料
- 主題模型
- 資料集市
- 報表、查詢、EIS工具(主管資訊系統---服務於組織的高層經理的一類特殊的資訊系統能夠迅速、方便、直觀（用圖形）地提供綜合資訊)
- OLAP工具
- 資料探勘工具
- 元資料
- 資料質量管理
- 資料標準化
- 資訊釋出
1.3.4.資料倉庫進化階段
1.3.5.資料倉庫建設特徵要素
- 資料倉庫專案不是技術主導型專案，是一個大的整合專案，更注重方法和流程
- 資料倉庫專案需要持續的建設
- 資料倉庫專案需要持續的持續的成熟評估和改進的建議
- 不同階段的實施方法需要技術和業務緊密結合的組織架構的支撐
- 資料倉庫專案需要堅持不懈的推動業務的參與
- 資料倉庫這種長週期大型專案需要建立有效的管理機制
1.4.資料倉庫與其它資料管理系統的區別
1.4.1.資料倉庫和資料庫的區別
資料倉庫和資料庫的不同：資料庫是面向應用的、事務型的資料處理，一般來說具有實時性較高，資料檢索量較小，只儲存當前資料，訪問頻率高，要求的響應時間短，面對多為普通使用者，且數量較大的特點。而資料倉庫主要是面向主題的、分析型的資料處理，具有實時性要求不高，資料檢索量較大，儲存大量歷史資料和當前資料，訪問頻率中低，響應時間較長，主要針對特殊使用者群體，使用者量較小的特點。其中事務型和分析型處理資料是有區別的：
- 事物型處理資料一般來說對效能要求較為嚴格，資料是事務驅動的，主要面向應用，儲存的一般都是即時性、細節性的資料，資料是可更新的。
- 分析型處理資料一般來說對查詢效能要求較高，資料是分析驅動的，主要面向決策分析，儲存的一般都是歷史、彙總性的資料，資料一般不會更新。
1.4.2.資料倉庫與ODS區別
1、ODS定義
ODS是這樣一種資料儲存系統，它將來自不同資料來源的資料（各種操作型資料庫、外部資料來源等）通過ETL過程匯聚整合成面向主題的、整合的、可更新的、當前或接近當前的、企業全域性一致的資料集合（主要是最新的或者最近的細節資料以及可能需要的彙總資料），用於滿足企業準實時的OLAP操作和企業全域性的OLTP操作，併為資料倉庫提供整合後的資料，將資料倉庫系統中的ETL過程下沉到ODS中完成以減輕資料倉庫的壓力。
2、ODS特點
- 面向主題的---進入ODS的資料是來源於各個操作型資料庫以及其他外部資料來源，資料進入ODS前必須經過
ETL過程； - 整合的---ODS的資料來源於各個操作型資料庫，同時也會在資料清理加工後進行一定程度的綜合；
- 可更新的---可以聯機修改。這一點區別於資料倉庫；
- 當前或接近當前的---“當前”是指資料在存取時刻是最新的，“接近當前”是指存取的資料是最近一段時間得到的。
3、ODS與DW的區別
①存放的資料內容不同：ODS中主要存放當前或接近當前的資料、細節資料，可以進行聯機更新。DW中主要存放細節資料和歷史資料，以及各種程度的綜合資料，不能進行聯機更新。ODS中也可以存放綜合資料，但只在需要的時候生成。
②資料規模不同：由於存放的資料內容不同，因此DW的資料規模遠遠超過ODS。
③技術支援不同：ODS需要支援面向記錄的聯機更新，並隨時保證其資料與資料來源中的資料一致。DW則需要支援ETL技術和資料快速存取技術等。
④面向的需求不同：ODS主要面向兩個需求：一是用於滿足企業進行全域性應用的需要，即企業級的OLTP和即時的OLAP；二是向資料倉庫提供一致的資料環境用於資料抽取。DW主要用於高層戰略決策，供挖掘分析使用。
⑤使用者不同：ODS主要使用者是企業中層管理人員，他們使用ODS進行企業日常管理和控制。DW主要使用者是企業高層和資料分析人員。
4、ODS在資料倉庫建設中的作用
大型資料倉庫的建設中一般採用三層體系結構，如下圖：
ODS和DW面向不同的使用者，為不同的需求產生，因此都有不可替代的作用，兩者相互結合、相互補充。ODS在三層體系結構中扮演著承上啟下的作用：
- 一方面ODS在原來獨立的各個DB的基礎上建立了一個一致的、企業全域性的、面向主題的資料環境，使原有的DB系統得到改造。
- 另一方面ODS使DW卸去了資料整合、結構轉換等一系列負擔，對DW的資料追加通過ODS完成，大大簡化的DW的資料傳輸介面和DW管理資料的複雜度
- ODS系統的建設，彌補了DB~DW兩層體系結構的不足，但是ODS並不是必需的，當企業並不需要操作型整合資訊時，基於DB~DW兩層體系結構是較優的，如果需要，那麼DB~ODS~DW三層體系結構則是較優的。
1.4.3.資料倉庫與資料集市
1、資料集市定義
資料集市是一組特定的、針對某個主題域、某個部門或者某些特殊使用者而進行分類的資料集合，也可以說是小型的資料倉庫。
2、資料倉庫與資料集市的區別
資料倉庫是企業級的，能為整個企業各個部門的執行提供決策支援手段；而資料集市則是一種微型的資料倉庫,它通常有更少的資料,更少的主題區域,以及更少的歷史資料,因此是部門級的，一般只能為某個區域性範圍內的管理人員服務，因此也稱之為部門級資料倉庫。
2.資料倉庫架構
2.1.資料設計方法
資料倉庫建立之前，就必須考慮其實現方法，通常有自頂向下、自底向上和兩者結合進行的這樣三種實現方案。
2.1.1.自頂向下實現
自頂向下的實現需要在專案開始時完成更多計劃和設計工作，這就需要涉及參與資料倉庫實現的每個工作組、部門或業務線中的人員。要使用的資料來源、安全性、資料結構、資料質量、資料標準和整個資料模型的有關決策一般需要在真正的實現開始之前就完成。
2.1.2.自底向上實現
自底向上的實現包含資料倉庫的規劃和設計，無需等待安置好更大業務範圍的資料倉庫設計。這並不意味著不會開發更大業務範圍的資料倉庫設計；隨著初始資料倉庫實現的擴充套件，將逐漸增加對它的構建。現在，該方法得到了比自頂向下方法更廣泛的接受，因為資料倉庫的直接結果可以實現，並可以用作擴充套件更大業務範圍實現的證明。
2.1.3.兩者結合的折中實現
每種實現方法都有利弊。在許多情況下，最好的方法可能是某兩種的組合。該方法的關鍵之一就是確定業務範圍的架構需要用於支援整合的計劃和設計的程度，因為資料倉庫是用自底向上的方法進行構建。在使用自底向上或階段性資料倉庫專案模型來構建業務範圍架構中的一系列資料集市時，您可以一個接一個地整合不同業務主題領域中的資料集市，從而形成設計良好的業務資料倉庫。這樣的方法可以極好地適用於業務。在這種方法中，可以把資料集市理解為整個資料倉庫系統的邏輯子集，換句話說資料倉庫就是一致化了的資料集市的集合。
2.2.資料倉庫架構爭論
關於Inmon 和 Kimball的大辯論：Ralph Kimball 和 Bill Inmon 一直是商業智慧領域中的革新者，開發並測試了新的技術和體系結構。在BI/DW領域中，圍繞“哪一種資料倉庫架構（Data Warehouse Architecture）最佳？”的爭論一直沒有休止，這個問題同時也是企業在建立DW時需要決策的關鍵問題：Bill Inmon的集線器架構/企業資訊工廠架構（Hub and Spoke / CIF – Corporate Information Factory）與 Ralph Kimball的資料集市/資料倉庫匯流排架構（Data Mart Bus Architecture/Data Warehouse Bus Architecture）則是DW架構的爭論焦點。
- Bill Inmon 將資料倉庫定義為“一個面向主題的、整合的、非易變的、隨時間變化的用於支援管理的決策過程的資料集合”；他通過“面向主題”表示應該圍繞主題來組織資料倉庫中的資料，例如客戶、銷售、產品等等。每個主題區域僅僅包含該主題相關的資訊。資料倉庫應該一次增加一個主題，並且當需要容易地訪問多個主題時，應該建立以資料倉庫為來源的資料集市。換言之，某個特定資料集市中的所有資料都應該來自於面向主題的資料儲存。 Inmon 的方法包含了更多上述工作而減少了對於資訊的初始訪問。但他認為這個集中式的體系結構持續下去將提供更強的一致性和靈活性，並且從長遠來看將真正節省資源和工作。下圖是他的設計方法圖解：
- Ralph Kimball 說“資料倉庫僅僅是構成它的資料集市的聯合”，他認為“可以通過一系列維數相同的資料集市遞增地構建資料倉庫”。每個資料集市將聯合多個數據源來滿足特定的業務需求。通過使用“一致的”維，能夠共同看到不同資料集市中的資訊。Kimball 的資料倉庫結構也就是著名的資料倉庫匯流排(BUS)。設計方法如下圖：
2.3.資料倉庫架構選型
資料倉庫架構的選取，與其所處的企業環境和業務的發展有著密切的關係：Inmon提倡的資料倉庫建設方法，需要資料倉庫建設人員自頂向下進行建設，資料倉庫開發人員需要在資料倉庫建設之前對企業各業務線進行深入的調研，有著非常全面的瞭解，然後根據企業各業務特點進行主題域劃分。這種建設方式建設週期比較長，規劃設計比較複雜，但是一旦建成，這個集中式的體系結構將提供更強的一致性和靈活性，並且從長遠來看將真正節省資源和工作；Kimball提倡的資料倉庫僅僅是構成它的資料集市的聯合，各部門或業務可以根據自身的發展，建設符合自身主題的資料集市，並持續豐富完善這些資料集市。在應對企業級資料需求時，將這些資料集市的維度資訊進行統一整理規範，然後通過一致的維度資訊，將這些資料集市連線起來，使資料集市形成一個覆蓋企業所有部門或業務的資料倉庫，對外提供服務。
根據企業發展階段和業務發展的速度建議：傳統的、業務成熟的企業可以考慮採用Inmon方法建設資料倉庫；業務複雜而且差異較大、發展速度又非常快的企業可以考慮Kimball方法建設資料倉庫。
2.4.美團資料倉庫建設變遷
美團在初期資料倉庫建設的過程中基本採用了Inmon提倡的資料倉庫建設方法，採用了DataSource-->ODS→EDW→DM的結構。即由ODS層完成各部門資料來源的整合，在ODS的基礎上建設了覆蓋公司所有業務的包含眾多主題的統一的資料倉庫，然後由這個統一的資料倉庫作為唯一的資料來源，為各部門的資料集市提供資料支援。如下圖：
採用上面方案的建設背景是，當時美團大多數業務都是通過團購開展的，形式上比較單一，規劃建設上比較容易，而且資料組也非常希望建設一個標準的資料倉庫。但是公司各部門發展速度非常快，業務變化非常大。Inmon模式下EDW規劃複雜、建設週期長，不能非常快速的響應各部門的需求，所以該方案逐步不能適應公司的發展。從而採用了Kimball的變種模式，結構如下：
從圖上可以看出，與原有的架構最大的區別是：各部門資料集市的資料來源並不是唯一的從資料倉庫獲取，而是從各部門資料來源所整合到的ODS層獲取。但是有各部門資料集市也會涉及到跨部門的資料統計，所以這種公司級的資料應用還是從資料倉庫中獲取。也就是各部門資料集市來支援各部門業務需求；企業級資料需求，從各部門資料集市或ODS層抽取公共模型進行建設（例如：公司級訂單、使用者等），並且在這裡將各部門集市所依賴的公共維度進行統一，來支援公司級或跨部門的業務需求。
3.資料倉庫建設中的資料建模
資料模型是指實體、屬性、實體之間的關係對業務概念和邏輯規則進行統一的定義，命名和編碼，主要描述企業的資訊需求和業務規則，是業務人員和開發人員溝通的語言，是資料倉庫設計工作的第一步。
首先我們需要解決三個問題：①什麼是資料模型；②為什麼需要資料模型；③如果建立資料模型；
3.1.什麼是資料模型
資料模型是抽象描述現實世界的一種工具和方法，是通過抽象的實體及實體之間聯絡的形式，來表示現實世界中事務的相互關係的一種對映。在這裡資料模型表現的抽象的實體和實體之間的關係，通過對實體和實體之間關係的定義和描述，來表達實際的業務中具體的業務關係。
資料倉庫模型是資料模型中針對特定的資料倉庫應用系統的一種特定的資料模型，一般的來說，我們資料倉庫模型分為以下幾個層次：業務模型、領域模型（主題域模型）、邏輯模型、物理模型。因此整個資料倉庫建模過程中，一般需要經歷四個過程：
- 業務建模：主要解決業務層面的分解和程式化；
- 領域（主題域）建模：主要是針對業務模型進行抽象處理，生成領域（主題域）概念模型；
- 邏輯建模：主要是將領域模型的概念實體以實體之間的關係進行資料庫層次的邏輯化；
- 物理建模：主要解決邏輯模型的物理化以及效能等一些具體的技術問題。
因此在整個資料倉庫的模型的設計和架構中，即涉及到業務知識，也涉及到具體的技術，我們既需要了解豐富的行業經驗，同時也需要一定的資訊科技來幫助我們實現我們的資料模型，最重要的是，我們還需要一個非常適用的方法論，來指導我們自己針對我們的業務進行抽象、處理、生成各個階段的模型。
3.2.為什麼需要資料模型
在資料倉庫的建設中，我們一再強調需要資料模型，那麼資料模型究竟為什麼這麼重要呢？首先我們需要了解整個資料倉庫的建設的發展史。資料倉庫的發展大致經歷了這樣的三個過程：
- 簡單的報表階段：這個階段，系統的主要目標是解決一些日常的工作中業務人員需要的報表，以及生成一些簡單的能夠幫助領導進行決策所需要的彙總資料。這個階段的大部分表現形式為資料庫和前段報表工具。
- 資料集市階段：這個階段主要是根據某個業務部門的需要，進行一定的資料的採集，整理，按照業務人員的需求，進行多維報表的展現，能夠提供對特定業務指導的資料，並且能夠提供特定的領導決策資料。
- 資料倉庫階段：這個階段主要是按照一定的資料模型，對整個企業的資料進行採集整理，並且能夠按照各個業務部門的需要，提供跨部門的，完全一致的業務報表資料，能夠通過資料倉庫生成對業務具有指導性的資料，同時為領導決策提供全面的資料支援。
通過對資料倉庫建設的發展階段，我們能夠看出，資料倉庫的建設和資料集市的建設的重要區別就在於資料模型的支援。因此，資料模型的建設，對於我們資料倉庫的建設，有著決定性的意義。 一般來說，資料模型的建設主要能夠幫助我們解決以下的一些問題：
- 進行全面的業務梳理，改進業務流程。在業務模型建設的階段，能夠幫助我們的企業或者管理機構對本單位的業務進行全面的梳理。通過業務模型的建設，我們應該能夠全面瞭解該單位的業務架構圖和整個業務的執行情況，能夠將業務按照特定的規律進行分門別類和程式化，同時，幫助我們進一步的改進業務的流程，提高業務效率，指導我們業務部門的生產。
- 建設全方位的資料視角，消滅資訊孤島和資料差異。通過資料倉庫的模型建設，能夠為企業提供一個整體的資料視角，不再是各個部門只是關注自己的資料，而且通過模型的建設，勾勒出部門之間的聯絡，幫助消滅各部門之間的資訊孤島的問題，更為重要的時，通過資料模型的建設，能夠保證這個企業的資料一致性，各個部門之間資料的差異將會得到有效解決。
- 解決業務的變動和資料倉庫的靈活性。通過資料模型的建設，能夠很好的分離出底層技術的實現和上層業務的展現。當上層業務發生變化時，通過資料模型，底層的技術實現可以非常輕鬆的完成業務的變動，從而達到整個資料倉庫的靈活性。
- 幫助資料倉庫系統本身的建設。通過資料倉庫的模型建設，開發人員和業務人員能偶很容易的達成系統建設範圍的界定，以及長期目標的規劃，從而能夠使整個專案組明確當前的任務，加快這個系統建設的速度。
3.3.如何建立資料模型
下面是資料倉庫模型階段劃分：
從上圖可以看出，資料倉庫的資料建模大致分為四個階段：
3.3.1.業務建模
從定義上來說，業務模型是最高層次的資料模型，主要完成：
- 劃分整個單位的業務，一般按照業務部分的劃分，進行各個部分之間業務工作的界定，理清各業務部門之間的關係；
- 深入瞭解各個業務部門的具體業務流程並將其程式化；
- 提出修改和改進業務部門工作流程的方法並程式化；
- 資料建模的範圍界定，這個資料倉庫專案的目標和階段劃分。
3.3.2.領域概念（主題域）建模
主題域模型資料倉庫的主要主題和重要業務之間的關係。一般來說，在進行資料倉庫系統設計和開發之前，設計開發人員和業務人員通過前期的業務建模，已經對主題域的劃分達成共識，因為主題域模型反映的是核心的業務問題。主題域模型設計步驟如下：
- 在業務建模的基礎上提取重要的業務資料主題，包括對業務資料主題的詳細解釋；
- 在業務資料主題的基礎上進行資料主題域的劃分，包括對資料主題域的詳細解釋；
- 劃分主題域概念模型：根據資料主題域的劃分，細化內部的組織結構和業務關係。
主題域建模的流程大致可以劃分成如下幾個部分：在前一個階段業務建模的過程中，已經對業務系統進行資料的梳理。根據各業務的特點列出資料主題詳細的清單，並對每個資料主題都作出詳細的解釋，然後經過歸納、分類，整理成各個資料主題域，列出每個資料主題域包含哪些部分，並對每個資料主題域作出詳細解釋，最後劃分成主題域概念模型。
3.3.3.邏輯建模
從定義上講，邏輯模型是以概念模型為基礎，對概念模型的進一步細化、分解。邏輯模型通過實體和實體之間的關係描述業務的需求和系統實現的技術領域，是業務需求人員和技術人員溝通的橋樑和平臺。 邏輯模型的設計是資料倉庫實施中最重要的一步，因為他直接反應了業務部門的實際需求和業務規則，同時對物理模型的設計和實現具有指導作用。他的特點就是通過實體和實體之間的關係勾勒出整個企業的資料藍圖和規則。 概念模型的主題域一般是從企業現有的資訊系統和行業自身業務活動彙總的來的業務模型主題域。而邏輯模型除了在概念模型的基礎上豐富和細化主題域，並且確定每個主題域包含哪些主題外，還需要：
- 分析需求，列出需求分析的主題，需求目標、維度指標、維度層次、分析的指標、分析的方法、資料的來源、關注的物件等。
- 選擇使用者感興趣的資料，通過業務需求將需要分析的指標分離抽取出來，轉化成邏輯模型需要的實體。
- 在實體中需要增加時間戳屬性，因為實體中需要儲存哥哥階段的歷史資料。通常情況下，如果實體為同一編碼，則不需要增加時間戳屬性。
- 需要考慮粒度層次的劃分。資料倉庫的粒度層次劃分直接影響了資料倉庫模型的設計，通常細粒度的資料模型直接從企業模型選取實體作為邏輯模型的實體，而粗粒度的資料模型需要經過彙總計算得到相應的實體。粒度決定了企業資料倉庫的實現方式、效能、靈活性和資料倉庫的資料量。
- 在粒度層次劃分的基礎上，還需要進行關係模式的定義，形成各個實體、實體屬性、實體之間的關係等內容。同時在邏輯模型框架的基礎上對實體的中英文名稱、屬性、屬性的值域進行明確、完善和細化，真實反映業務邏輯關係和業務規則。
3.3.4.物理建模
在邏輯模型的基礎上，為應用生產環境選取一個合適的物理結構的過程，包括合適的儲存結構和儲存方法，稱作物理模型的設計過程。邏輯模型轉變為物理模型包括以下幾個步驟：
- 實體名（Entity）變為表名（table）
- 屬性名（attribute）轉換為列明（column），確定列的屬性（Property）
- 物理模型必須對列的屬性進行明確的定義，包括：列名、資料型別
- 物理模型確定後，還可以進一步確定資料存放位置和儲存空間的分配。
3.4.資料倉庫建模方法
3.4.1.實體建模法
實體建模並不是資料倉庫建模中常見的一個方法，它來源於哲學的一個流派。從哲學的意義上說，客觀世界應該是可以細分的，客觀世界應該可以分成由一個個實體，以及實體與實體之間的關係組成。那麼在資料倉庫的建模過程中完全可以引入這個抽象的方法，將整個業務也可以劃分成一個個的實體，而每個實體之間的關係，以及針對這些關係的說明就是我們資料建模需要做的工作。
雖然實體建模看起來好像有些抽象，其實理解起來很容易。即我們可以將任何一個業務劃分成3個部分，實體，事件和說明。
上圖表述的是一個抽象的含義，如果描述一個簡單的事實：“小明開車去學校上學”。以這個業務事實為例，我們可以把“小明”，“學校”看成是一個實體，“上學”描述成一個業務過程，在這裡可以抽象為一個具體“事件”，而“開車去”怎可以看成事件“上學”的一個說明。
從上面列舉的例子可以瞭解，我們使用的抽象歸納方法其實很簡單，任何業務可以看成3個部分：
- 實體：指領域建模中特定的概念主題，指發生業務關係的物件；
- 事件：指概念主體之間完成一次業務流程的過程，指特定的業務過程；
- 說明：主要是針對實體和事件的特殊說明。
由於實體建模法，能夠很輕鬆的實現業務建模的劃分。因此，在業務建模階段和領域建模階段，實體建模方法有著廣泛的應用。一般在沒有現成的行業建模的情況下，可以採用實體建模的方法，和客戶一起清理整個業務的模型，進行領域概念的劃分，抽象出具體的業務概念，結合客戶的使用特點，完全可以創建出一個符合自己需要的資料倉庫模型來。
但是，實體建模也有著自己先天的缺陷，由於實體說明法只是一種抽象客觀事件的方法，因此，註定了該建模方法只能侷限在業務建模和領域概念建模階段。因此，到了邏輯建模階段和物理建模階段，則是正規化建模和維度建模發揮長處的階段。
3.4.2.正規化建模法
正規化建模法其實是我們在構建資料模型常用的一個方法，該方法的主要由inmon所提倡，主要解決關係型資料庫中資料儲存，利用的一種技術層面上的方法。目前，在關係型資料庫中的建模方法，大部分採用的是三正規化建模法。
正規化是資料庫邏輯模型設計的基本理論，一個關係模型可以從第一正規化到第三正規化進行無損分解，這個過程也可以稱為規範化。在資料倉庫的模型設計中目前一般採用第三正規化，他有著嚴格的數學定義。從其表達的含義來看，一個符合第三正規化的關係必須具有以下三個條件：
- 每個屬性值唯一，不具有多義性；
- 每個非主屬性必須完全依賴於整個主鍵，而非主鍵的一部分；
- 每個非主屬性不能依賴於其他關係中的屬性，因為這樣的話，這種屬性應該歸到其他關係中去。
根據Inmon的觀點，資料倉庫模型的建設方法和業務系統的企業資料模型類似。在業務系統中，企業資料模型決定了資料的來源，而企業資料模型也分為兩個層次，即主題域模型和邏輯模型。同樣，主題域模型可以看成業務模型的概念模型，而邏輯模型則是域模型在關係型資料庫上的例項化。
從業務資料模型轉向資料倉庫模型時，同樣也需要有資料倉庫的域模型，即概念模型，同時也存在域模型的邏輯模型。這裡，業務模型中的資料模型和資料倉庫的模型稍稍有一些不同，主要區別在於：
- 資料倉庫的域模型應該包含企業資料模型的域模型之間的關係，以及各個域模型定義。資料倉庫的域模型的概念應該比業務系統的主題域模型規範更加廣。
- 在資料倉庫的邏輯模型需要從業務系統的資料模型中的邏輯模型中抽象實體，實體的屬性，實體的子類，以及實體的關係等。
正規化建模法的最大優點就是從關係型資料庫的角度出發，結合了業務系統的資料模型，能夠比較方便的實現資料倉庫的建模。但其缺點也很明顯，由於建模方法限定在關係型資料庫之上，在某些時候反而限制了整個資料倉庫模型的靈活性，效能等，特別是考慮資料倉庫的底層資料向資料集市的資料進行彙總時，需要進行一定的變通才能滿足響應的需求。
3.4.3.維度建模法
維度建模是kimball最先提出的。其最簡單的描述就是：按照事實表，維表來構建資料倉庫、資料集市。這種方法最被人廣泛知曉的名字就是星型建模。
上圖就是這個架構中最典型的星型架構。星型模式之所以被廣泛使用，在於針對各個維做了大量的預處理，如按照維進行預先的統計、分類、排序等。通過這些預處理，能夠極大的提升資料倉庫的處理能力。特別是針對3NF的建模方法，星型模式在效能上佔據明顯的優勢。
同時，維度建模法的另外一個優勢是：維度建模非常直觀，僅僅圍繞著業務模型，可以直觀的反應出業務問題。不需要經過特別的抽象處理，即可以完成維度建模。這一點也是維度建模的優勢。
但是維度建模的缺點也非常明顯，由於在構建星星模型之前需要進行大量的資料預處理，因此會導致大量的資料處理工作。而且，當業務發生變化，需要重新進行維度的定義時，往往需要重新進行維度資料的預處理。而在這些預處理的過程中，往往會導致大量的資料冗餘。
另外一個維度建模的缺點是：如果只是單純的維度建模，不能保證資料來源的一致性和準確性，而且在資料倉庫的底層，不是特別適用於維度建模的方法。
4.維度建模
4.1.維度建模技術
維度建模是DW/BI系統的核心，他是ETL系統的目標、資料庫的結構、支援使用者查詢和製作報表的模型。建模要實現3個主要設計目標，分別是：能儘可能簡潔的向用戶展示需要的資訊；能儘快返回查詢結果給使用者；能提供相關資訊，以便精確的跟蹤潛在的業務過程。
維度建模能使任何事情儘可能簡單，但絕不是簡化。在資料倉庫和商業智慧中，維度模型是給使用者顯示資訊的首選結構，其比典型的原系統規範化模型更便於使用者理解。維度建模中表更少，資訊分組為對使用者有意義的、一致的業務類別。這些類別稱為維度，有助於使用者瀏覽模型，因為可以忽略與特定分析無關的全部類別。但是儘可能簡潔並不意味著模型一定簡單。模型必須反映業務，而業務通常都比較複雜，如果簡化的過多，一般來說只表示了聚合資料，模型就會丟失對理解業務非常重要的資訊。無論如何進行資料建模，資料內容在的複雜性都使大多數人最終願意通過結構化報表和分析應用程式來訪問DW和BI系統。
維度建模能提供更好的查詢效能，因為在建立維度時採用了反規範化的方法，通過預先連線各種層次結構和查詢表，優化程式考慮的連線路徑較少，建立的中間臨時表更少。
為了精確跟蹤潛在的業務過程，需要採用各種設計模式，以創建出精確捕獲和跟蹤業務模型。維度模型由一個或者多箇中心事實表和與其相關的維度構成。事實表位於中心，而維度環繞在其周圍，類似於星型結構，因此又把維度模型成為星型模型。
4.1.1.事實表
事實表是維度模型的基本表，存放有大量的業務效能度量值。應力圖將從一個業務處理過程得到的度量值資料存放在單個數據中心。由於度量值資料壓倒性的成為任何資料中心的最大部分，因此應該避免在企業範圍內的不同地方儲存其拷貝。用術語“事實”代表一個業務度量值。例如：商品銷售記錄每個商店每種產品的銷售數量和銷售額。在各維度值（日期、產品和商店）的交叉點就可以得到一個度量值。維度值的列表給出了一個事實表的粒度定義，並確定出度量值的取值範圍是什麼。
事實表的設計中要解決幾個重要問題：
- 粒度（記錄事實的細節級）：事實表中包含資訊的詳細程度稱為粒度。強烈建議以原始來源中可能的最小細節級別構建事實表--通常稱為原子級別。原子事實表提供了完整的靈活性，資料可以累積到現在或將來任何維度需要的任何聚合級別。每個事實表必須只有一種粒度。例如，如果在同一事實表中包含每月預測項和單獨的銷售訂單項，就很容易引起混淆併產生危險。
- 相加性：事實的可加性是至關重要的，因為資料倉庫應用幾乎從不僅僅只檢索事實表的單行資料。相反，往往一次性帶回數百、數千乃至數百萬行的事實，並且處理這麼多行的最有用的事就是將它們加起來。但是有些事實是半加性質的，而另外一些是不可加性質的。半加性事實僅僅沿某些維度相加，而非加性事實根本就不能相加。對於非加性事實，如果希望對其進行總結就不得不使用計數或平均數，或者降為一次一行的打印出全部事實行。對這長達數十億行的事實表來說，將是一個遲緩而乏味的工作。
- 文字度量值：度量事實在理論上可以是文字形式的，文字度量可以是某種事物的描述。但是設計者應該儘量將文字度量轉換成維度，原因在於維度能夠與其他文字維度屬性更有效關聯起來，並且消耗少的多的空間。不能將冗餘的文字資訊存放在事實表內。除非文字對於事實表的每行來說都是唯一的，負責他應該歸屬到維度表中。真正的文字事實在資料倉庫中很少出現，因為文字事實具有像自由文字內容那樣不可預見性，這幾乎是不可能進行分析的。
- 鍵選擇：多維資料建模中的鍵選擇是一個難題。它包含效能和易於管理之間的權衡（trade-off）。鍵選擇主要適用於維度。您為維度所選擇的鍵必須是事實的外來鍵。維度鍵有兩種選擇：您可以分配一個任意鍵，或者使用作業系統中的識別符號。任意鍵通常只是一個序列號，當需要一個新鍵時，就分配下一個可用的號碼。【為了使用作業系統中的識別符號惟一地表示維度，您有時需要使用一個複合鍵。複合鍵就是由多個列組成的鍵。任意鍵是一列，通常比操作派生的鍵要小。因此，任意鍵通常可以更快地執行連線。】【鍵選擇中的最後一個因素就是它對事實表的影響。在建立事實時，必須將每個維度的鍵分配給它。如果維度將帶有時間戳的操作派生的鍵用於歷史資料，那麼在建立事實時，就沒有附加工作。連線將自動發生。對於任意鍵或任意歷史識別符號，在建立事實時，就必須將一個鍵分配給事實。】【分配鍵的方式有兩種。一種就是維護操作和資料倉庫的鍵的轉換表。另一種就是儲存操作鍵，並且在必要時，儲存時間戳作為維度上的屬性資料。】【那麼，選擇就在任意鍵的更好效能和操作鍵的更易維護之間進行。效能提高多少和維護增加多少的問題就必須在您自己的組織中進行評估了。】【無論做出什麼選擇，都必須在元資料中用文件記錄生成它們的過程。該資訊對於管理和維護資料倉庫的技術人員來說是必要的。如果您所使用的工具沒有隱藏連線處理，那麼使用者可能也需要理解這一點。】
- 一致性事實：如果某些度量出現在不同的事實表中，需要注意，如果需要比較或計算不同事實表中的事實，應保證針對事實的技術定義是相同的。如果不同的事實表定義是一致的，則這些一致性事實應該具有相同的命名，如果它們不相容，則應該有不同的命名用於告誡業務使用者。
事實表的分類：事務事實表、週期快照事實表、積累快照事實表。
- 事務事實表：一行對應空間或時間上某點的度量事件。原子事務粒度事實表是維度化及可表達的事實表，這類健壯的維度確保對事務資料的最大劃分片和分塊。事務事實表可以是稠密的，也可以是稀疏的，因為僅當存在度量時才會建立行。這些事實表總是包含一個與維度表關聯的外來鍵，也可能包含精確的時間戳和退化維度建。度量數字事實必須與事務粒度保持一致。
- 週期性快照事實表：事實表中的每行彙總了發生在某一標準週期，如某天、某月。粒度是週期性的，而不是個體的事務。週期快照事實表通常包含許多事實，因為任何與事實表粒度一致的度量事件都是被允許存在的。這些事實表其外來鍵的密度是均勻的，因為即使週期內沒有活動發生，也會在事實表中為每個事實插入包含0或空值的行。
- 積累快照事實表：事實表彙總了發生在過程開始和結束之間可預測步驟內的度量事件。管道或工作流過程具有定義的開始點，標準中間過程，定義的結束點，他們在此類事實表中都可以被建模。通常在事實表中針對過程中的關鍵步驟都包含日期外來鍵。積累快照事實表中的一行，對應某一具體的訂單，當訂單產生時會插入一行。當管道過程發生時，積累事實錶行被訪問並修改。這種對積累快照事實錶行的一致性修改在三種類型事實表中具有特性，除了日期外來鍵與每個關鍵過程步驟關聯外，積累快照事實表包含其他維度和可選退化維度的外來鍵。通常包含數字化的與粒度保持一致的，符合里程碑完成計數的滯後性度量。
4.1.2.維度表
維度表包含有業務的文字描述。在一個設計合理的維度模型中，維度表有許多列或者屬性，這些屬性給出對維度表的行所進行的描述。維度表傾向於將列數做的特別大，每個維度用單一的主關鍵字進行定義，主關鍵字是確保同與之相連的任何事實表之間存在應用完整性的基礎。
維度屬性是查詢約束條件、成組與報表標籤生成的基本來源。例如，一個使用者要按照“星期”和“商標”來檢視銷售額，那麼“星期”與“商標”就必須是可用的維度屬性。資料倉庫的能力直接與維度屬性的質量和深度成正比。在提供詳細的業務用語屬性方面所化的時間越多，資料倉庫就越好。在屬性列值的給定方面所花的時間越多，資料倉庫就越好。在保證屬性列值的質量方面所花的時間越多，資料倉庫就越好。
最好的屬性是文字的和離散的。屬性應該是真正的文字而不應是一些編碼簡寫符號。例如：對於產品來說，典型的屬性應該包括一個短描述、一個長描述、一個商標名、一個分類名、包裝型別、尺寸以及大量其他產品特徵等方面的內容。
維度表時常描述業務中的層次關係。例如：產品劃分為商標、然後是分類。產品維度的每行都存放有與產品有關的商標和分類。但是存放層次描述資訊顯得很冗餘， 不過也是基於容易使用和查詢效能方面的考慮才這樣做的。不要受僅僅儲存商標編碼併為其建立一個單獨的商標查詢表的固有想法所限制，這種形式可以稱為雪花。維度表一般是很不規範的，通常也非常小。既然維度表一般都很小，通過規範化或者雪花來提高儲存效率的做法也起不了大作用，所以實際應用中，幾乎總是用維度表的空間來換取簡明性和可訪問性。
還需要了解：退化維度、多層次維度、非規範化扁平維度、雪花維度。OLAP對維度的劃分有：強制維度、普通維度、衍生維度、層次維度。
需要掌握：一致性維度整合、緩慢變化維處理、層次維度處理
4.1.3.事實與維度的融合
由數字型度量值組成的事實表連線到一組填滿描述屬性的維度表上。這個星型特徵結構通常被叫做星型連線方案。關於維度方案，應該注意第一件事就是其簡明性與對稱性。簡明性是指使用者可以很容易的理解和瀏覽資料；簡明性也提升了效能上的好處，倉庫在處理時首先對維度表進行過濾處理，然後用滿足使用者約束條件的維度表關鍵字的笛卡爾乘積一次性處理全部的事實表。
維度表模型能夠很自然的進行擴充套件以適應變化的需求。維度模型的可預訂框架能夠經受住無法預見的使用者行為變化所帶來的考驗。每個維度都是平等的，所有維度都是進入事實表的對等入口。每個邏輯模型不存在內建的關於某種期望的查詢形式方面的偏向，不存在這個月要問的業務問題相對於下個月來說具有優化方面的考慮。沒有誰希望，如果業務使用者採用新的方式進行業務分析，就要調整設計方案這樣的事情發生。維度模型的事實與維度表如下：
在設計過程中，最佳粒度或者原子資料具有最佳的維度。被聚合起來的原子資料是最有表現力的資料。原子資料應該成為每個事實表設計的基礎。從而經受住業務使用者無法預見的查詢所引起的特別攻擊。對於維度模型來說，完全可以向方案中加入新的維度，只要其值對於每個現有的事實行存在唯一性定義就行。同樣，可以向事實表加入新的不曾預料到的事實，只要其詳細程度與現有事實表處在一致的水平面上就可以了。可以用新的不曾預料到的屬性補充先前存在的維度表，也可以從某個前向時間點的角度在一個更低的粒度層面上對現存維度進行分解。在每種情況下，可以簡單的在表中加入新的資料行或者對現在表進行適當的修改。
認識事實與維度表之間互補性的另外一種方式是在所形成的報表中瞭解他們。如上圖，維度屬性提供了生成報表標籤的內容，而事實表則提供了報表的數字型取值。
最後就像已經強調的那樣，展示環節的資料應該是維度形式的。不過，維度模型與規範化模型之間存在著一種自然的關係。理解這種關係的關鍵在於認識到，單個規範化ER圖通常分解為多個維度方案。為機構建立的大型規範化模型可以將電話銷售、訂購單、裝貨發票、顧客付款、產品利潤等內容全部放在一個圖中。在某種程度上講，規範化ER圖對自身就是一種傷害，原因在於他將許多從來就不會出現在單個數據集中的多個業務處理放在了單張繪製圖中。可見，規範化模型看起來很複雜，是不足為奇的。
如果有一張已經存在的規範化ER圖，將它轉換為一組維度模型的第一步是，將ER圖分成一些分散的業務處理過程，然後分別單獨建模。第二步是選出ER圖中那些含有數字型與可加性非關鍵字事實的多對多關係，並將他們標記為事實表。最後一步是，將剩下的所有表複合成具有直接連線到事實表的單連關鍵字的平面表，這些表就成為維度表。
4.2.維度建模過程
維度建模具有一定順序，分別是：①業務處理②粒度③維度④事實。
4.2.1.選取業務處理
業務處理過程是機構中進行的一般都是有源系統提供支援的自然業務活動。聽取使用者的意見是選取業務處理過程的效率最高的方式。在選取業務階段，資料模型設計者需要有全域性和發展的視角，應該理解整體業務流程的基礎上，從全域性角度選取業務處理。
要記住的重要一點是，這裡談到的業務處理並不是指業務部門或者職能。通過將注意力集中放在業務處理過程方面，就能在機構範圍內更加經濟的提交一致的資料。如果建立的維度模型是同部門捆綁在一起的，就無法避免出現具有不同標記與術語的資料拷貝的可能性。多重資料流向單獨的維度模型，會使使用者在應付不一致性的問題方面顯得很脆弱。確保一致性的最佳辦法是對資料進行一次性的釋出。單一的釋出過程還能減少ETL的開發量，以及後續資料管理和磁碟儲存方面的負擔。
4.2.2.定義粒度
粒度定義意味著對各事實錶行，實際代表的內容給出明確的說明。粒度傳遞了同事實表度量值相聯絡的細節所達到的程度方面的資訊。他給出了後面這個問題的答案“如何描述事實表的單個行？”
粒度定義是不容輕視的至關重要的步驟。在定義粒度時應優先考慮為業務處理獲取最有原子性的資訊而開發維度模型。原子性資料是所收集的最詳細的資訊，這樣的資料不能再做更進一步的細分。通過在最低層面上裝配資料，大多原子粒度在具有多個前段的應用場合顯示出其價值所在。原子型資料是高度維結構化的。事實度量值越細微並具有原子性，就越能夠確切的知道更多的事情，所有那些確切知道的事情都轉換為維度。在這點上，原子型資料可以說是維度方法的一個極佳匹配。
原子型資料可為分析方面提供最大程度的靈活性，因為他可以接受任何可能形式的約束，並可以以任何可能的形式出現。維度模型細節性資料是穩如泰山的，並隨時準備接受業務使用者的特殊攻擊。
當然，可以總是給業務處理定義較高層面的粒度，這種粒度表示最具有原子性的資料的聚集。不過，只要選取較高層面的粒度，就意味著將自己限制到更少或者細節性可能更小的維度上了。具有較少粒度性的模型容易直接遭到深入到細節內容的不可預見的使用者請求的攻擊。聚集概要性資料作為調整的一種手段起著非常重要的作用，但他絕不能作為使用者存取最底層面細節內容的替代品。遺憾的是，有些權威人士在這方面一直含糊不清，他們宣稱維度模型只適合於總結性資料，並批判那些認為維度建模方法可以滿足預測業務需求的看法。這樣的誤解會隨著細節性的原子型資料在維度模型中的出現而慢慢的消失。
4.2.3.選定維度
維度所引出的問題是：“業務人員將如何描述從業務處理過程得到的資料？”。應該用一組在每個度量上下文中取單一值而代表了所有可能情況的豐富描述，將事實表裝扮起來。如果對粒度方面的內容很清楚，那麼維度的確定一般是非常容易的。通過維度的選定，可以列出那些使每個維度表豐滿起來的離散的文字屬性。常見的例子包括：日期、產品、客戶、賬戶和機構等。
4.2.4.確定事實
他是設計過程的第四步也是最後一步，在於仔細確定那些事實要在事實表中出現。事實的確定可以通過回答“要對什麼內容進行評測”這個問題來進行。業務使用者在這些業務處理效能度量值的分析方面有濃厚的興趣。設計中所有供選取的資訊必須滿足在第2步中定義的粒度要求。明顯屬於不同粒度的事實必須放在單獨的事實表中。通常可以從以下三個角度來建立事實表：
- 針對某個特定的行為動作，建立一個以行為活動最小單元為粒度的事實表。最小活動單元的定義，依賴於分析業務需求。比如使用者的一次網頁點選行為、一次網站登入行為，一次電話通話記錄。這種事實表，主要用於從多個維度統計，行為的發生情況，主要用於業務分佈情況，績效考核比較等方面的資料分析。
- 針對某個實體物件在當前時間上的狀況。我們通過對這個實體物件在不同階段儲存他的快照，比如使用者的餘額、使用者擁有的產品數等。通過這種可以統計實體在不同生命週期中的關鍵數量指標。
- 針對業務活動中的重要分析和跟蹤物件，統計在整個企業不同業務活動中的發生情況。比如會員，可以執行或參與多個特定的行為活動。這種事實表是以上兩種事實表的一個總計和歸納。它主要用於針對我們業務中的活動物件進行跟蹤和考察。