數據庫的數據倉庫設計體系是什么

這篇文章主要介紹“數據庫的數據倉庫設計體系是什么”，在日常操作中，相信很多人在數據庫的數據倉庫設計體系是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”數據庫的數據倉庫設計體系是什么”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

深入剖析數據倉庫

數據倉庫概念:

英文名稱為Data Warehouse，可簡寫為DW或DWH。數據倉庫的目的是構建面向分析的集成化數據環境，為企業提供決策支持（Decision Support）。它出于分析性報告和決策支持目的而創建。

數據倉庫本身并不“生產”任何數據，同時自身也不需要“消費”任何的數據，數據來源于外部，并且開放給外部應用，這也是為什么叫“倉庫”，而不叫“工廠”的原因。

基本特征:

數據倉庫是面向主題的、集成的、非易失的和時變的數據集合，用以支持管理決策。

注：文章首發于公眾號：五分鐘學大數據

1. 面向主題:

傳統數據庫中，最大的特點是面向應用進行數據的組織，各個業務系統可能是相互分離的。而數據倉庫則是面向主題的。主題是一個抽象的概念，是較高層次上企業信息系統中的數據綜合、歸類并進行分析利用的抽象。在邏輯意義上，它是對應企業中某一宏觀分析領域所涉及的分析對象。

1. 集成性:

通過對分散、獨立、異構的數據庫數據進行抽取、清理、轉換和匯總便得到了數據倉庫的數據，這樣保證了數據倉庫內的數據關于整個企業的一致性。

數據倉庫中的綜合數據不能從原有的數據庫系統直接得到。因此在數據進入數據倉庫之前，必然要經過統一與綜合，這一步是數據倉庫建設中最關鍵、最復雜的一步，所要完成的工作有：

• 要統一源數據中所有矛盾之處，如字段的同名異義、異名同義、單位不統一、字長不一致，等等。

• 進行數據綜合和計算。數據倉庫中的數據綜合工作可以在從原有數據庫抽取數據時生成，但許多是在數據倉庫內部生成的，即進入數據倉庫以后進行綜合生成的。

下圖說明一個保險公司綜合數據的簡單處理過程，其中數據倉庫中與“保險” 主題有關的數據來自于多個不同的操作型系統。這些系統內部數據的命名可能不同，數據格式也可能不同。把不同來源的數據存儲到數據倉庫之前，需要去除這些不一致。

數倉主題

1. 非易失性（不可更新性）

數據倉庫的數據反映的是一段相當長的時間內歷史數據的內容，是不同時點的數據庫快照的集合，以及基于這些快照進行統計、綜合和重組的導出數據。

數據非易失性主要是針對應用而言。數據倉庫的用戶對數據的操作大多是數據查詢或比較復雜的挖掘，一旦數據進入數據倉庫以后，一般情況下被較長時間保留。數據倉庫中一般有大量的查詢操作，但修改和刪除操作很少。因此，數據經加工和集成進入數據倉庫后是極少更新的，通常只需要定期的加載和更新。

1. 時變性

數據倉庫包含各種粒度的歷史數據。數據倉庫中的數據可能與某個特定日期、星期、月份、季度或者年份有關。數據倉庫的目的是通過分析企業過去一段時間業務的經營狀況，挖掘其中隱藏的模式。雖然數據倉庫的用戶不能修改數據，但并不是說數據倉庫的數據是永遠不變的。分析的結果只能反映過去的情況，當業務變化后，挖掘出的模式會失去時效性。因此數據倉庫的數據需要更新，以適應決策的需要。從這個角度講，數據倉庫建設是一個項目，更是一個過程。數據倉庫的數據隨時間的變化表現在以下幾個方面：

（1） 數據倉庫的數據時限一般要遠遠長于操作型數據的數據時限。
（2） 操作型系統存儲的是當前數據，而數據倉庫中的數據是歷史數據。
（3） 數據倉庫中的數據是按照時間順序追加的，它們都帶有時間屬性。

1. 數據倉庫與數據庫的區別

數據庫與數據倉庫的區別實際講的是 OLTP 與 OLAP 的區別。

操作型處理，叫聯機事務處理 OLTP（On-Line Transaction Processing，），也可以稱面向交易的處理系統，它是針對具體業務在數據庫聯機的日常操作，通常對少數記錄進行查詢、修改。用戶較為關心操作的響應時間、數據的安全性、完整性和并發支持的用戶數等問題。傳統的數據庫系統作為數據管理的主要手段，主要用于操作型處理，像Mysql，Oracle等關系型數據庫一般屬于OLTP。

分析型處理，叫聯機分析處理 OLAP（On-Line Analytical Processing）一般針對某些主題的歷史數據進行分析，支持管理決策。

首先要明白，數據倉庫的出現，并不是要取代數據庫。數據庫是面向事務的設計，數據倉庫是面向主題設計的。數據庫一般存儲業務數據，數據倉庫存儲的一般是歷史數據。

數據庫設計是盡量避免冗余，一般針對某一業務應用進行設計，比如一張簡單的User表，記錄用戶名、密碼等簡單數據即可，符合業務應用，但是不符合分析。數據倉庫在設計是有意引入冗余，依照分析需求，分析維度、分析指標進行設計。

數據庫是為捕獲數據而設計，數據倉庫是為分析數據而設計。

以銀行業務為例。數據庫是事務系統的數據平臺，客戶在銀行做的每筆交易都會寫入數據庫，被記錄下來，這里，可以簡單地理解為用數據庫記賬。數據倉庫是分析系統的數據平臺，它從事務系統獲取數據，并做匯總、加工，為決策者提供決策的依據。比如，某銀行某分行一個月發生多少交易，該分行當前存款余額是多少。如果存款又多，消費交易又多，那么該地區就有必要設立ATM了。

顯然，銀行的交易量是巨大的，通常以百萬甚至千萬次來計算。事務系統是實時的，這就要求時效性，客戶存一筆錢需要幾十秒是無法忍受的，這就要求數據庫只能存儲很短一段時間的數據。而分析系統是事后的，它要提供關注時間段內所有的有效數據。這些數據是海量的，匯總計算起來也要慢一些，但是，只要能夠提供有效的分析數據就達到目的了。

數據倉庫，是在數據庫已經大量存在的情況下，為了進一步挖掘數據資源、為了決策需要而產生的，它決不是所謂的“大型數據庫”。

2. 數據倉庫分層架構

按照數據流入流出的過程，數據倉庫架構可分為：源數據、數據倉庫、數據應用

范式建模

根據 Inmon 的觀點，數據倉庫模型的建設方法和業務系統的企業數據模型類似。在業務系統中，企業數據模型決定了數據的來源，而企業數據模型也分為兩個層次，即主題域模型和邏輯模型。同樣，主題域模型可以看成是業務模型的概念模型，而邏輯模型則是域模型在關系型數據庫上的實例化。

2. 維度建模法（Dimensional Modeling）

維度模型是數據倉庫領域另一位大師Ralph Kimall所倡導，他的《數據倉庫工具箱》是數據倉庫工程領域最流行的數倉建模經典。維度建模以分析決策的需求出發構建模型，構建的數據模型為分析需求服務，因此它重點解決用戶如何更快速完成分析需求，同時還有較好的大規模復雜查詢的響應性能。

實體建模

上圖表述的是一個抽象的含義，如果我們描述一個簡單的事實：“小明開車去學校上學”。以這個業務事實為例，我們可以把“小明”，“學校”看成是一個實體，“上學”描述的是一個業務過程，我們在這里可以抽象為一個具體“事件”，而“開車去”則可以看成是事件“上學”的一個說明。

維度建模

維度建模是專門應用于分析型數據庫、數據倉庫、數據集市建模的方法。數據集市可以理解為是一種"小型數據倉庫"。

1. 維度建模中表的類型

1. 事實表

發生在現實世界中的操作型事件，其所產生的可度量數值，存儲在事實表中。從最低的粒度級別來看，事實表行對應一個度量事件，反之亦然。

事實表表示對分析主題的度量。比如一次購買行為我們就可以理解為是一個事實。

2. 雪花模式

雪花模式(Snowflake Schema)是對星形模式的擴展。雪花模式的維度表可以擁有其他維度表的，雖然這種模型相比星型更規范一些，但是由于這種模型不太容易理解，維護成本比較高，而且性能方面需要關聯多層維表，性能也比星型模型要低。所以一般不是很常用

星座模型

3. 維度建模過程

我們知道維度建模的表類型有事實表，維度表；模式有星形模型，雪花模型，星座模型這些概念了，但是實際業務中，給了我們一堆數據，我們怎么拿這些數據進行數倉建設呢，數倉工具箱作者根據自身60多年的實際業務經驗，給我們總結了如下四步，請務必記住！

數倉工具箱中的維度建模四步走：

數據分層架構

數據層具體實現

使用四張圖說明每層的具體實現

• 數據源層ODS

數據明細層

事實表中的每行對應一個度量，每行中的數據是一個特定級別的細節數據，稱為粒度。維度建模的核心原則之一是同一事實表中的所有度量必須具有相同的粒度。這樣能確保不會出現重復計算度量的問題。

維度表一般都是單一主鍵，少數是聯合主鍵，注意維度表不要出現重復數據，否則和事實表關聯會出現數據發散問題。

有時候往往不能確定該列數據是事實屬性還是維度屬性。記住最實用的事實就是數值類型和可加類事實。所以可以通過分析該列是否是一種包含多個值并作為計算的參與者的度量，這種情況下該列往往是事實；如果該列是對具體值的描述，是一個文本或常量，某一約束和行標識的參與者，此時該屬性往往是維度屬性。但是還是要結合業務進行最終判斷是維度還是事實。

• 數據輕度匯總層DM

數據應用層

數據應用層的表就是提供給用戶使用的，數倉建設到此就接近尾聲了，接下來就根據不同的需求進行不同的取數，如直接進行報表展示，或提供給數據分析的同事所需的數據，或其他的業務支撐。

到此，關于“數據庫的數據倉庫設計體系是什么”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！