數據倉庫究竟是什么？它和事務交易處理系統（OLTP）又有什么區別？初次接觸它的朋友往往覺得它很神 秘、很復雜，其實不然。今天就和大家來認識一下數據倉庫的本質，以及在實施商務智能過程中它的一些設計技巧。
Ralph Kimball，數據倉庫（Data Warehouse，DW）領域最權威的專家之一，曾下過這樣的結論：BI系統=數據倉庫。或許這種說法有一定的片面性，經不起咬文嚼字的推敲，但從中我 們卻不難看出數據倉庫在BI系統中舉足輕重的地位。
仔細想想，的確如此。幾乎所有的BI項目，都是在數據倉庫這個“大舞臺”之上“演出”的，它就像是BI 系統的心臟，源源不斷地為前端提供新鮮的血液——最新的業務數據，有了這些數據，我們才會看到前端詳盡的報表、直觀的分析和神奇的預測。
數據倉庫究竟是什么呢？它和事務交易處理系統（OLTP）又有什么區別？初次接觸它的朋友往往覺得它很 神秘、很復雜，其實不然。今天就和大家來認識一下數據倉庫的本質，以及在實施商務智能過程中它的一些設計技巧。
概念解析
目前，關于數據倉庫的定義有很多種，都是從不同的角度和層面概括的。著名數據倉庫專家 W.H.Inmon在其著作《Building the Data Warehouse》一書中有過如下描述：數據倉庫是一個面向主題的（Subject Oriented）、集成的（Integrate）、穩定的（Non-Volatile）、隨時間不斷變化（Time Variant）的數據庫系統，主要用于企業的決策支持。對于上述概念，結合與OLTP系統的比較，我們可以從以下幾個方面來理解數據倉庫：
“遺傳”性 從 “數據庫”到“數據倉庫”，雖然多了一個“倉”字，但卻沒有改變它數據庫的“本性”。從物理上來講，它依然是一個關系型的數據庫，表、字段、主鍵、索引、 鍵約束等概念，在數據倉庫中依然存在，無論數據的組織方式還是在表中二維的存放，數據的存儲規則也基本遵循關系型數據庫的各種范式。從這個層面來看，數據 倉庫與普通的數據庫系統并無本質區別。
主題性 OLTP系統是被設計用來處理和存儲事務交易數據 的，通常一個企業內存在多個OLTP系統，各自之間相互獨立。而數據倉庫是被設計用來進行決策支持，主要是進行數據分析，因此它的數據組織方式是按主題劃 分的。主題是一個抽象的概念，是指用戶使用數據倉庫進行分析時所關注的具體的業務領域。如一個企業的數據倉庫中可能包含了財務系統、銷售系統、庫存系統、 人力資源系統等方面的數據，它們都被劃分為一個主題（通常對應著一個數據集市）。
集成性 所謂“ 集成”，也是與OLTP系統相比較而言。OLTP系統通常是與某些特定的應用相關的，數據庫之間相互獨立，結構不一。而數據倉庫中的數據是對原有獨立的、 分散的、異構的各種OLTP系統（包括文本文件、半結構化文件）中的數據進行了大匯總，并對這些數據進行了清洗和轉換，消除了其中的不一致性，統一規范了 數據格式，保證了這些數據是關于整個企業的全局性數據。
穩定性 OLTP系統由于面向事務操作，經常會有增、刪、改等操作，所以其中的數據會經常更新。而數據倉庫的數據主要供企業決策分析使用，所涉及的數據操作主要是 數據查詢。數據一旦進入數據倉庫，將會被長期保存，一般不會進行修改和刪除操作，通常只需要定期進行加載和刷新。
時變性 既 “穩定”又“時變”，聽起來有些矛盾，這更為數據倉庫增添了幾分神秘色彩。這里說的時變，指的是其中的數據不是一成不變的，而是按一定的時間間隔進行更新 的。隨著OLTP系統數據的積累，新的數據按時經過轉換加工后被源源不斷地抽取到數據倉庫中。只有數據不斷更新，新數據不斷的注入，我們基于數據倉庫進行 的前端分析展現的結果才會更符合企業當前的實際狀況，來有效地輔助企業決策。
“外觀”解析
前面提到，數據倉庫在物理上仍然是一個關系型的數據庫系統，那從外觀上來看，數據倉庫有什么特點呢？如 圖1所示，是一個比較典型的數據倉庫（準確地說是一 個數據集市），大家可以看到，與普通的數據庫不同，其中的表都以“Dim”或“Fact”開始，這是因為數據倉庫中的數據不外乎維度數據和事實數據（元數 據除外），為了我們直觀上容易判斷和以后多維建模過程中便于識別，我們通常在維度表的表名前加“Dim”，在事實表的表名前加“Fact”，當然，這只是 一種良好的命名習慣，并不是必須這樣來命名。
地位解析
數據倉庫在整個BI的流程中的地位可以概括為“承前啟后”。所謂“承前”，正如前面所提到的，它匯總了 來自異構數據源的、經過清洗整合后的數據， 使數據與業務系統脫離，保障了業務系統的安全和效率；所謂啟后，是因為它為以后建設多維數據庫做好了準備，是建立多維數據庫的基礎和平臺。
相關技巧
1、架構模式的選擇
數據倉庫的架構主要有星型和雪花型兩種方式，下 面從多個角度來比較一下這兩種模式的利弊。
從查詢性能角度來看，在OLTP-DW環節，由于雪花型要做多個表聯接，性能會低于星型架構；但從 DW-OLAP環節，由于雪花型架構更有利于度量值的聚合，因此性能要高于星型架構。
從模型復雜度來看，星型架構更簡單。
從層次概念來看，雪花型架構更加貼近OLTP系統的結構，比較符合業務邏輯，層次比較清晰。
從存儲空間角度來看，雪花型架構具有關系數據模型的所有優點，不會產生冗余數據，而相比之下星型架構會 產生數據冗余。
根據我們的項目經驗，一般建議使用星型架構。因為我們在實際項目中，往往最關注的是查詢性能問題，至于 磁盤空間一般都不是問題。 當然，在維度表數據量極大，需要節省存儲空間的情況下，或者是業務邏輯比較復雜、必須要體現清晰的層次概念情況下，可以使用雪花型維度。
2、“鍵”與“約束”的取舍
主外鍵的選擇是數據倉庫建設過程中一個很重要的方面。事實表中由于引用了多個維度表的主鍵，這些主鍵結 合起來已經具有唯一性，可以確定唯一的事實記錄，所以通常情況下，我們不會再為其設立代理鍵作為主鍵，而是為其建立復合主鍵。
相比之下，維度表中的情況稍微復雜。維度表中的主鍵通常有兩種選擇：自然鍵（Natural Key），它是業務系統中已經存在的，通常是具有一定業務含義的一個字符型的標志符，可以唯一地標志維度表中的每一條記錄。比如機構的代碼、縮寫、時間標 簽等。另一種是代理鍵（Surrogate Key），通常是數據庫系統賦予的一個數值，是自增型的，按順序分配，沒有內置含義但也可以唯一地標識一條維度信息。
根據筆者的項目經驗，推薦采用第二種，即代理鍵。原因如下：
首先，自然鍵雖然在邏輯上可以唯一地標識出一條維度信息，但它通常是字符型的，且一般比較長，若用它作 為維度表中的主鍵，那就意味著在事實表中也要加入同 樣的外鍵信息，而事實表記錄行數往往是巨大的，在多個維度表上重復這樣的做法會使事實表由于列寬過于膨脹而導致性能的急劇下降。
其次，代理鍵可以作為數據倉庫與源系統之間的“緩沖”。自然鍵通常具有一定的業務含義，但日久天長，這 些信息是有可能發生變化的，比如身份證號碼，由最初 的15位變成了現在的18位。如果這種主鍵一旦發生了變化，由于它同時作為事實表中的外鍵，必然會對事實表產生影響，因為已有的事實記錄已經找不到與之匹 配的維度記錄，這就帶來了很大的麻煩。但若采用代理鍵作為維度表中的主鍵，就完全可以把這些變化屏蔽在維度表內，不會對事實表產生任何影響（當然這個還要 結合緩慢變化維度的處理）。
最后，從關聯效率考慮，數值型的關聯要比字符型的關聯快很多。
鍵約束的取舍也是數據倉庫設計過程中一個很值得注意的問題。在OLTP系統環境中，數據的完整性通?？?兩種方式來保證，一是應用程序的邏輯保證，另一個是 數據庫結構自身的約束機制。這兩種方式相互補充，而數據倉庫環境中的情況則完全不同，數據倉庫中數據的完整性更依賴于應用程序，也就是ETL系統的保證。
首先，ETL系統運行時間雖然很長，但其結構是簡單的，重復地抓取、清洗、轉換、加載動作。與其相 比，OLTP系統可能同時在一張表上執行大量并行業務操作。
其次，事實表的唯一入口是維度表，按照維度建模的思路實現ETL程序，只會產生不準確的維度信息，不可 能在事實表中產生重復記錄。第三，與OLTP系統相比，數據倉庫系統沒有交互式人機錄入界面，不存在“人為”錯誤。
因此，在我們比較關注數據加載時間的情況下，最好從數據倉庫中刪除一些不必要的約束，其中包括主鍵約 束、外鍵約束及唯一索引約束，這些約束規則可以在外部得以實施。
3、ODS的運用
ODS（Operational Data Storage，操作型數據存儲區）是數據倉庫體系結構中的一個可選部分，它具備數據倉庫的部分特征和OLTP系統的部分特征。它是“面向主題的、集成 的、當前或接近當前的、隨時間不斷變化的”數據庫系統。在什么情況下才需要用到ODS這個環節呢？或者說，ODS起到了什么作用？
ODS在業務系統和數據倉庫之間形成一個隔離層。一般的數據倉庫應用系統都具有非常復雜的數據來源，這 些數據存放在不同的地理位置、不同的數 據庫、不同的應用之中。從這些業務系統對數據進行抽取并不是一件容易的事，此時就需要用到ODS。它在業務系統和數據倉庫之間形成一個隔離層，用來存放從 業務系統直接抽取出來的數據，這些數據從數據結構、數據之間的邏輯關系上都與業務系統基本保持一致，因此在抽取過程中極大降低了數據轉化的復雜性，而主要 關注數據抽取的接口、數據量大小、抽取方式等方面的問題。
ODS還可用來轉移一部分業務系統細節查詢的功能。在數據倉庫建立之前，大量的報表、分析是由業務系統 直接支持的，在一些比較復雜的報表生成過程中，對業 務系統的運行產生很大的壓力。而ODS中的數據從粒度、組織方式等各個方面都保持了與業務系統相一致，那么原來由業務系統產生的報表、細節數據的查詢自然 能夠從ODS中進行，從而降低了業務系統的查詢壓力。
ODS還可以完成數據倉庫中不能完成的一些功能。一般來說，帶有ODS的數據倉庫體系結構中，DW層所 存儲的數據都是進行匯總過的數據，并不存儲每筆交易 產生的細節數據，但是在某些特殊的應用中，可能需要對交易細節數據進行查詢，這時就需要把細節數據查詢的功能轉移到ODS來完成，而且ODS的數據模型按 照面向主題的方式進行存儲，可以方便地支持多維分析等查詢功能。在一個沒有ODS層的數據倉庫應用系統體系結構中，數據倉庫中存儲的數據粒度是根據需要而 確定的，但一般來說，最為細節的業務數據也是需要保留的，實際上也就相當于ODS，但與ODS所不同的是，這時的細節數據不是“當前、不斷變化的”數據， 而是“歷史的，不再變化的”數據。
總結：
通覽本文，大家應該認識到，數據倉庫并不神秘，在物理上它與OLTP并無本質區別。與OLTP不同的 是，不是用來做交易處理，而是用于決策支持。也正因為 此，它具有主題性、集成性、穩定性和時變性等特點。為提高數據倉庫的性能和效率，在設計數據倉庫時，也有技巧可循。
