設計數據倉庫

數據倉庫是數據的倉庫，數據是從操做型數據庫系統中獲取，通過集成處理、按照合適的粒度進行聚合而成的數據的集合。 構建數據倉庫，要從數據模型、數據集成、粒度設計和分區設計這四個方面着手，迭代式開發。

一，數據模型

在設計數據倉庫以前，首先要了解操做型數據庫的數據模型，數據模型分爲三個層次：

• ERD（實體關係圖）是最頂層的概念模型，是實體關係的高度抽象，主要用於肯定各個實體（或主題）及其之間的關係；
• 中間層是數據集成（DIS），用於對主要數據分組，設置數據的連接，肯定主鍵、屬性和關係；
• 底層是物理模型，用於設計SQL Server的關係表，在這一層上，肯定數據的粒度、對數據進行分區、定義引用、建立索引等

 1，實體關係圖（ERD）

實體關係圖是數據之間關係的高度抽象，直接定義了數據模型中的實體（主題）和實體之間的關係，用於理解數據模型中涵蓋的主題

2，數據集成（DIS）

 對實體-關係模型中標識出的每個主題或實體，都要創建一個DIS模型，

數據集成模型基本上由三部分構成：

• 主要數據分組：每一個主題或實體有且只有一個主要數據分組，例如，客戶是一個主要數據分組，有客戶ID這個惟一標識。
• 二級數據分組：實體的額外屬性，例如，客戶的居住地址
• 鏈接器：數據之間的關係，用於把一個數據分組和其餘數據分組聯繫起來

 

 當在ERD層標識一個實體-關係以後，在DIS層就用鏈接器和數據分組來表現：

數據分組包含關鍵字和其餘屬性，用於對數據分組進行詳細的描述。 

3，物理模型（關係表）

物理模型是從DIS模型建立而來的， 通常來講，數據集成模型中定義的數據分組，都對應一個關係表，數據分組中的關鍵字和屬性，用於定義關係表的主鍵和屬性列。可是，這些表不能直接用於設計數據庫中的關係表，可是，物理模型是設計關係的依據，還要考慮對關係表進行性能優化。

二，數據倉庫的性能優化設計

設計關係表的關鍵是集成數據，設計數據的粒度和分區，另外，爲了優化性能，還須要設計緩存，設計冗餘字段，去外鍵，增長層次結構。

1，數據集成

把原始數據集成到數據倉庫中，爲了性能優化，一般會對數據列作以下處理：

• 增長代理主鍵：保留業務主鍵，可是，增長自增的正整數列（代理主鍵）做爲關係表的主鍵，用於惟一標識實體。
• 增長時間列：記錄數據插入的時間（Inserted Time）和數據最新更新的時間（Last Updated Time），便於對數據作增量更新。
• 數據集成時，還須要對數據進行一致性處理，好比，對屬性列統一命名，統一編碼，統一度量單位等

另外，通常數據倉庫中，不會保留長文本數據，若是必須保留長文本數據，建議把該文本列分離出去。對於無效的數據，須要清理出去；對於空值得數據，須要設置默認值等。

2，粒度

在數據倉庫中，數據存在着不一樣的細節級：原始數據（最細節的數據）、當前細節數據、輕度聚合數據和高度聚合數據，數據的粒度升級，是在數據由操做層傳輸到導出層進行的，一旦數據過時，就由原始數據導出當前細節數據，進而導出聚合數據。咱們把聚合以後的數據稱做緩存數據，這是爲了定向提升某個主題或分析的查詢性能。

不一樣的細節級，實際是由數據粒度的不一樣致使的，而粒度的升級一般是由時間、類別等屬性聚合以後獲得的。粒度會深入地影響存儲到數據倉庫中的數據量的大小和數據倉庫支持的查詢類型。數據倉庫中數據量的大小和粒度成反比，粒度越低，支持的查詢範圍越普遍，數據量越大。換句話說，低粒度能夠回答任何問題，而高粒度會限制數據所能回答的問題。

因爲高粒度會下降數據量，使得查詢速度更快；而低粒度可以回答更多的問題，所以，在數據倉庫中，通常根據數據被查詢的頻次，設計多重粒度，這樣啊，既能使用高粒度快速響應高頻問題，也能使用低粒度回答低頻的問題。

3，分區

數據分區是把數據分散到可獨立進行IO處理的分離的硬盤中，從根本上來講，分區的好處有兩點：

• 利用分區，能夠把IO分散到不一樣的物理硬盤上去，以併發方式訪問數據，提升數據查詢和更新的速度；
• 利用分區，能夠把不經常使用的數據切換到廉價的大容量硬盤上去，而把經常使用的數據切換到性能優越的硬盤上去；

對數據分區，須要依據特定的數據列，一般以時間列做爲分區列，把不一樣的時間區間的數據存放到不一樣的分區中去。

注意：把分區分佈於不一樣的物理硬盤，才能充分利用硬件的IO能力，一般狀況下，一塊物理硬盤會劃分爲多個邏輯硬盤，若是把不一樣的分區放到不一樣的邏輯硬盤上，而這些邏輯硬盤屬於同一個物理硬盤，那麼IO實際上不會併發執行。

4，反向規範化

數據模型的輸出是一系列的關係表，每一個表都包含關鍵字和屬性，典型的OLTP數據庫設計的規範是避免冗餘，全部的屬性都必須依賴於主鍵，不容許傳遞依賴（即不容許間接依賴主鍵），這樣設計的結果使更新操做的cost最小化，可是，對於一個查詢請求，可能會join多張表，而SQL Server對於多表的Join操做的性能優化能力有限，這會致使查詢性能急劇下降。

因爲數據倉庫不多對數據進行更新，一般是保存歷史數據不變；在設計數據倉庫時，能夠違反第三範式（不容許間接依賴主鍵），把實體的相關字段合併到一個表中，使相關的數據在物理上是順序存儲的。這樣的表結構設計，既能減小了查詢語句中使用Join的次數，充分利用SQL Server引擎的優化能力，也能利用物理硬盤的IO特性（順序讀取一塊數據），提升數據查詢的性能。

另一個提升查詢性能的表設計是根據訪問頻率來分裂表，當一個列是長文本字段，且訪問頻次至關低時，能夠把該列分離出去，存放到另外一個附表中，這樣設計表的結果是高頻訪問的列和窄列放到主表中，低頻的長文本列放到副表中，主表和附表經過代理主鍵關聯在一塊兒。

5，緩存設計

因爲數據倉庫中的數據更新的次數少，對於經常使用的數據聚合，能夠預先把數據計算好，存儲到緩存表，也就是說，在數據倉庫中，建立不一樣粒度的關係表。而緩存表中的數據，能夠把計算的時間安排在夜晚等非工做時間段，這樣，用戶在工做時不須要重複計算，只須要查詢就能夠快速得到結果，提升了工做效率。

6，外鍵關係

對於參照完整性，在數據倉庫中，通常不會建立外鍵關係，參照完整性是經過「人工」識別的。這樣，即便刪除了參考表中的數據，也不會影響引用表，只不過join不出結果而已。

把外鍵關係轉換爲數據冗餘，這也就是數據的反規範化設計，這樣作會增大數據倉庫使用的存儲容量，下降數據更新的性能，可是會加快數據查詢的速度，當數據是穩定的，補償更新時，採用數據冗餘是性能優化的設計方案。

7，增長層次結構

層次結構是聚合數據的角度，例如，數據是以天爲單位，那麼能夠設計時間維度，該維度表的層次結構分別是天、周、月、季和年，分析人員能夠按照周、月、季和年來聚合數據，以不一樣的視角來分析數據。經常使用的層次結構是日期、行政區劃，類別等。數據倉庫中，確定是存儲在時間維度的，也一定存在日期維度。

8，數據壓縮

對於數據倉庫而言，IO資源比CPU資源更加稀缺，咱們可使用計算資源換IO資源。雖然壓縮和解壓縮會浪費CPU資源，可是數據壓縮使得數據能夠存儲到較小的硬盤空間中，也就是說，一樣的硬盤空間存儲更多的數據，這使得一次IO可以讀取更多的數據。

9，索引設計

儘可能使用窄列建立索引時，索引不是越多越好，但也不能一個索引都不建立。

對於只插入數據，而極少查詢的數據表，能夠建立一個自增列做爲主鍵，並建立彙集索引從物理上順序存儲數據；

對於複合主鍵的狀況下，能夠建立非彙集索引，而使用自增列做爲主鍵，並建立彙集索引從物理上順序存儲數據；

對於變長數據類型，若是數據常常更新或改變，可能會帶來很是嚴重的性能問題，在建立索引時，儘可能不要把變化頻繁的變長列做爲索引列，考慮做爲包含列來處理。

三，多維結構

數據倉庫中常常提到的設計方法是多維結構，基於星型鏈接、事實表和維度表來設計關係表架構，多維方法只適用於數據集市，而不適合數據倉庫。數據集市中的表結構是根據部門的特殊需求而創建的，其結構通常是星型鏈接，包含事實表和維度表，一般由OLAP技術支持。

一般來講，多維結構的特徵是：

• 星型鏈接是指維度表中數據容許冗餘，
• 維度表主要存儲類別屬性和層次結構，
• 事實表存儲實體數據，實體的屬性經過外鍵和維度表關聯。

使用多維結構的結果是：事實表中基本不存儲文本數據，維度表中記錄的是實體的類別，時間等屬性，大多數是文本數據和層次結構數據。多維結構靈活性不足，通用性不足。

四，設計模型

數據倉庫的數據庫設計有兩種基本模型：關係模型和多維模型，關係模型更加靈活，因此更適合數據倉庫的設計，而多維模型更適合數據集市。

1，關係模型

關係模型是OLTP數據庫系統的設計模型，表設計符合數據庫設計的第一範式、第二範式和第三範式，關係模型提升了數據更新的性能，而犧牲了數據查詢的性能。因爲OLTP是高更新的數據庫系統，所以，關係模型很是適合操做型數據庫系統。然而，數據倉庫中存儲的數據不常更新，更多的是對數據的查詢。

關係模型的最大優勢是靈活，支持適度變化的需求，適合數據倉庫的設計。

2，多維模型

一般認爲，多維模型是創建數據倉庫的設計方法，多維模型犧牲數據更新的性能，以提升數據查詢的性能。多維模型的兩種結構是星形鏈接和雪花形鏈接，雪花形鏈接是星形鏈接的擴展。多維模型存在數據冗餘，這會使得，經過一次訪問就能夠獲得一個實體的全部數據，Join操做較少，數據查詢較快，能夠直接用於OLAP技術。缺點是不夠靈活，一旦設計完成，要想改動就很難了。

（1）星形鏈接

從設計模型上來看，星形鏈接是以一顆事實表爲中心，周圍圍繞着維度表。

星形鏈接的中心是一個事實表，事實表是包含大量數據值的一個表；事實表的周圍是維度表，用於描述事實表的類別，時間等屬性。事實表和維度表經過公共屬性（外鍵）相關聯。

（2）雪花形鏈接

一般，星形鏈接只包含一張事實表，當須要多張事實表相結合時，這就是雪花形結構：

在雪花形結構中，不一樣的事實表經過共享一個或多個公共維度錶鏈接起來。

 

 

參考文檔：