數據倉庫模型
出自 MBA智库百科(https://wiki.mbalib.com/)
目錄 |
數據倉庫模型的概述[1]
數據倉庫是一種近年來出現的、發展迅速的技術，它將企業內各種跨平臺的數據經過集成，為企業決策者進行市場分析並做出決策提供了有效的途徑。數據倉庫的開發是由數據模型驅動的，數據倉庫的創建過程中數據建模是最關鍵的技術環節，它直接決定數據倉庫的成敗。因此，要成功地創建一個數據倉庫，必須有一個合理的數據模型。
數據模型是對現實事物的反映和抽象，它可以幫助我們更加清晰地瞭解客觀世界。數據倉庫建模在業務需求分析之後開始，是數據倉庫構造的正式開始。在創建數據倉庫的數據模型時應考慮：
（1）滿足不同層次不同用戶的信息需求。
（2）兼顧查詢效率與數據粒度的需求。數據粒度與查詢效率往往是相互矛盾的，細小的粒度保證了信息查詢的靈活性，但降低了查詢的效率。因此，建模要提供足夠的數據粒度，並保證查詢的效率。
（3）適應需求的變化。用戶的信息需求隨著市場的變化，建模要考慮支持需求的變化。
（4）避免業務運營系統的性能影響。由於數據倉庫系統中數據增長迅速，運行占用大量資源，建模要考慮儘量減少業務運營系統的性能的影響。
（5）提供可擴展性。數據模型的可擴展性決定了數據倉庫對新的需求的適應能力，建模既要考慮眼前的信息需求，也要考慮未來的需求。
合理而完備的數據模型是用戶業務需求的體現，是數據倉庫成敗的技術因素。因此，數據模型的創建能直接反映出業務需求，對系統的物理實施起著指導性的作用，是數據倉庫的核心問題。
數據倉庫模型的主要內容[2]
數據倉庫的實現策略有多種, 面向主題的自頂而下的設計方法, 其實面向主題就是面向對象。數據倉庫包含的對象可以是:客戶、產品、策略等多維概念。終端用戶通過各種維度來獲取商業數據, 其中時間是最基本、最關鍵的維度。數據倉庫的數據建模分為3個層次: 高層建模、中間層建模、底層建模, 其設計方法同傳統的資料庫設計一樣經歷了概念模型設計、邏輯模型設計和物理模型設計3 個階段, 對於面向主題的數據倉庫, 數據建模的具體方法有多種, 這裡介紹的是信息包圖設計、星型圖模型設計和物理數據模型設計：
; 1.高層建模方法——信息包圖
高層建模(ERD,實體關係層),其特點是實體和關係,屬概念模型設計階段,也就是通常所說的需求分析,在與用戶交流的過程中,確定數據倉庫所需要訪問的信息,這些信息包括當前、將來以及與歷史相關的數據。在需求分析階段確定操作數據、數據源以及一些附加數據,設計容易理解的數據模型,有效地完成查詢和數據之間的映射。
由於數據倉庫的多維性,利用傳統的數據流程圖進行需求分析己不能滿足需要。超立方體(hypercube)用超出三維的表示來描述一個對象,顯然具備多維特性,完全可以滿足數據倉庫的多維特性。利用自上而下方法設計一個超立方體的步驟為:(1)確定模型中需要抓住的商業過程,例如銷售活動或銷售過程;(2)確定需要捕獲的值,例如銷售數量或成本,這些信息通常是一些數值;(3)確定數據的粒度,亦即需要捕獲的最低一級的詳細信息。
由於超立方體在表現上缺乏直觀性,尤其當維度超出三維後,數據的採集和表示都比較困難,因此我們可以採用一種稱為信息包圖的方法在平面上展開超立方體,即用二維表格反映多維特征。
信息包圖提供了一個多維空間建立用戶信息模型的方法,它提供了超立方體的可視化表示。
信息包圖集中在用戶對信息包的需要,它定義主題內容和主要性能測試指標之間的關係,其目標就是滿足用戶需要。信息包圖擁有3個重要對象:指標、維度和類別,而類別是在一個維度內為了提供詳細分類而定義的,利用信息包圖設計概念模型需要確定如下這3大內容:確定指標。指標表明在維度空間上衡量商務信息的一種方法,是訪問數據倉庫的關鍵所在,是用戶最關心的信息。成功的信息包可以保證用戶從信息包中獲取需要的各個性能指標參數。
確定維度。維度提供了用戶訪問數據倉庫信息的途徑,對應超立方體的每一面,位於信息包圖的第一行的每一個欄目中。
確定類別。類別表示一個維度包含的詳細信息,其中的成員是為了辨別和區分特定數據而設,一個維度內最底層的可用的分類又稱為詳細類別。
對於複雜的商業要求進行需求分析時,有時一張信息包圖不能反映所有情況,可能需要設計不同的信息包圖來滿足全部需求,此時應該保證多個信息包圖中出現的維度信息和類別信息完全一致。
- 2.中間層建模方法——星形圖設計
高層數據模型建好後,下一步就是中間層建模(DIS,數據項集),對高層模型中標識的每個實體都要建一個中間層模型。數據倉庫主要提供的是查詢操作,而最便於執行查詢操作的邏輯模型設計工具是星形圖,因此可以利用星形圖來設計數據倉庫的邏輯模型。
星形圖因其外觀似五角星而得名,它支持以商務決策者的觀點定義數據實體,滿足面向主題數據倉庫設計的需要,而信息包圖又為星形圖的設計提供了完備的概念基礎。同信息包圖中的3個對象對應,星形圖擁有以下3個邏輯實體的定義。
定義指標實體。位於星形圖中心的實體是指標實體,是用戶最關心的基本實體和查詢活動的中心,為用戶的商務活動提供定量數據。使用每一個指標,同時確定是否存儲經過計算的指標。
定義維度實體。位於星形圖星角上的實體是維度實體,其作用是限制用戶的查詢結果,將數據過濾使得從指標實體查詢返回較少的行,從而縮小訪問範圍。一個維度實體對應指標實體中多個指標。一個維度實體對應信息包圖中的一個列。
定義詳細類別實體。詳細類別實體,對應現實世界的某一實體。一個維度內的每個單元就是一個類別,代表該維度內的一個單獨層次,要求更加詳細的信息才能滿足用戶的需要,與對應的事務資料庫結構產生映射。
在星形圖中,用戶通過維度實體獲得指標實體數據,其中指標實體與維度實體間的聯繫通過每個維度中的最低一層的詳細類別實體連接。
當多個信息包圖轉換成星形圖時,可能出現維度實體的交叉重疊,為了保證實體的一致性需要進行統一處理,確定它們是同一實體在不同層次上的數據反映,還是兩個不同的實體。當多個維度實體相關並且存在共性時,可能需要將其合併為一個指標實體。
- 3.底層建模方法——星形圖轉換為物理數據模型
底層建模(物理層),從邏輯模型轉向物理模型設計,完全遵循傳統的資料庫設計方法。一般來說,星形圖中的指標實體和詳細類別實體通常轉變為一個具體的物理資料庫表,而維度實體則作為查詢參考、過濾和聚合數據使用,因此通常並不直接轉變為物理資料庫表。在物理模型設計階段,需要確定以下內容:定義數據標準。規範化數據倉庫中的各種數據。
定義實體和實體特征。完整定義實體所具有的一切屬性,決定數據的粒度與分割,當然要加入與每個數據單元相關的時間元。
定義規模。確定數據容量和更新頻率。
對於傳統的OLTP系統,我們總是按照應用來建立它的模型,換言之,OLTP系統是面嚮應用的。而數據倉庫則一般按照主題 (Subject)來建模,它是面向主題的。何謂應用?何謂主題?讓我們來看一個簡單的例子。在銀行中,一般都有對私 (個人儲蓄)、對公 (企業儲蓄)、信用卡等多種業務系統,它們都是面嚮應用的,所支持的交易類型簡單而且固定。由於實施的先後等原因,這些系統可能運行在不同的平臺上,相互之間沒有什麼關係,各系統之間的數據存在冗餘。比如每個系統中都會有客戶的數據,當針對銀行建立其數據倉庫應用時,要把上述生產系統中的數據轉換到數據倉庫中來。從整個銀行的角度來看,其數據模型不再面向個別應用,而是面向整個銀行的主題,比如客戶、產品、渠道等。因此,各個生產系統中與客戶、產品、渠道等相關的信息將分別轉換到數據倉庫中相應的主題中,從而在整個銀行的業務界面上提供一個一致的信息視圖。
模型是對現實事物的反映和抽象，它可以幫助我們更加清晰的瞭解客觀世界。數據倉庫建模在業務需求分析之後開始，是數據倉庫構造工作正式開始的第一步，正確而完備的數據模型是用戶業務需求的體現，是數據倉庫項目成功與否最重要的技術因素。
金融企業的信息系統具有業務複雜、機構複雜、系統龐大的特點，因此金融行業數據倉庫建模必須註意以下幾個方面，
——滿足不同用戶的需求
金融行業的業務流程十分複雜，數據倉庫系統涉及的業務用戶眾多，在進行數據模型設計的時候必須兼顧不同業務產品、不同業務部門、不同層次、不同級別用戶的信息需求。
數據倉庫應該支持企業的各種業務，比如對財產保險行業應該考慮財產險、貨物運輸險、工程險、責任險等不同業務的特點；不同的業務部門對信息的需求各有不同，應考慮業務、市場、財務、管理等各個部門的需要；不同層次的組織所關心的信息不同，數據模型應支持地市公司、省公司和總公司的信息需求；金融企業是知識密集型的企業，知識密集型企業的顯著特征是智能員工(Knowledge Worker)占企業員工的大多數，數據倉庫必須支持所有相關智能型員工的信息需求，包括高層領導、基層領導和普通員工。
——兼顧效率與數據粒度的需要
數據粒度和查詢效率從來都是矛盾的，細小的數據粒度可以保證信息訪問的靈活性，但同時卻降低了查詢的效率並占用大量的存儲空間，數據模型的設計必須在這矛盾的兩者中取得平衡，優秀的數據模型設計既可以提供足夠詳細的數據支持又能夠保證查詢的效率。
——支持需求的變化
用戶的信息需求隨著市場的變化而變化，所以需求的變化只有在市場競爭停頓的時候才會停止，而且隨著競爭的激化，需求變化會越來越頻繁。數據模型的設計必須考慮如何適應和滿足需求的變化。
——避免對業務運營系統造成影響
金融企業的數據倉庫系統是一個每天都在長大的龐然大物，它的運行很容易占用很多的資源，比如網路資源、系統資源，在進行數據模型設計的時候也需要考慮如何減少對業務系統性能的影響。
——考慮未來的可擴展性
數據倉庫系統是一個與企業同步發展的有機體，數據模型作為數據倉庫的靈魂必須提供可擴展的能力，在進行數據模型設計時必須考慮未來的發展，更多的非核心業務數據如人事數據、市場數據、競爭對手數據等必須可以方便的加入到數據倉庫，而不需要對數據倉庫中原有的系統進行大規模的修改。
大規模的數據倉庫系統特別是金融行業數據倉庫的數據結構從技術角度劃分應當包含三個部分，如下圖所示，
- 1.分段存儲區（Staging Area）
由於數據倉庫中的數據結構和組織方式具有很大差異、所有原始業務系統的數據必須經過嚴格的抽取、映射和轉換，數據的整合過程十分複雜，通常會耗費比較長的處理時間。如果從業務系統直接抽取數據到數據倉庫，必定會占用許多業務系統的資源和時間，為了避免影響業務系統的運行，我們在數據模型的設計中引入分段存儲區的概念。
分段存儲區（Staging Area）是為了保證數據移動的順利進行而開設的階段性數據存儲空間，它是業務系統原始數據進入數據倉庫前的緩存區。需要進入數據倉庫的各個業務系統的數據首先直接快速傳輸到分段存儲區，再從分段存儲區經過清洗、轉換、映射等複雜的數據移動處理轉移到目標數據倉庫中。從業務系統到分段存儲區的數據傳輸，應儘量避免進行複雜的數據處理，以保證數據的快速導入而儘量減小對業務系統造成的壓力。分段存儲區的數據有關係資料庫和文件兩種不同存儲方式，分別對應於不同運營系統的數據源。數據成功導入數據倉庫之後，應清空分段存儲區中的數據。
在數據倉庫系統的運行和使用過程中，分段存儲區的作用主要體現在以下幾個方面，
- 可以減少對業務系統資源的占用，避免複雜數據轉換對業務系統的影響
- 分段存儲區作為數據緩存區，可以在一定程度上屏蔽業務系統變化對數據移動整合系統的影響
- 如果在數據處理過程中發生系統故障，作為數據倉庫系統的備份數據，可以直接從分段存儲區進行數據倉庫數據恢復，而不必要再從業務系統原始數據開始。
- 2.基礎數據倉庫（BaseLine）
基礎數據倉庫存儲所有最詳細的業務數據。該層數據直接來源於對分段存儲區數據的清洗和加工，屬於未經彙總的數據，但數據的組織方式可能已經完全不同於原始的業務系統。根據業務需求的不同，基礎數據倉庫的組織形式以三範式模型為主，在有的系統中也可能採用星型或雪花模型。
通常在金融企業的數據倉庫系統中，基礎數據倉庫數據包括未經彙總的客戶交易數據，用戶資料數據、客戶服務數據等，此外一些相關數據如網路利用，競爭對手，成本投資數據也包括在內。由於基礎數據倉庫數據是對原始業務數據的原形再現，所以數據量會非常龐大，根據不同業務的需要數據保留的時間在6個月到兩年不等。
根據業務需求將數據倉庫數據分類成幾個不同的數據集市，每個數據集市完成不同的分析和查詢需求，數據集市中的數據通常由基礎數據倉庫的詳細數據聚合而來，根據數據聚合程度的不同包含輕度聚合、中度聚合和高度聚合三種不同的層次。彙總的方式將依據數據量的大小和使用頻度綜合考慮。
