資料庫與資料倉庫

簡而言之，資料庫是面向事務的設計，資料倉庫是面向主題設計的。

　　資料庫一般存儲線上交易資料，資料倉庫存儲的一般是曆史資料。

　　資料庫設計是盡量避免備援，一般采用符合範式的規則來設計，資料倉庫在設計是有意引入備援，采用反範式的方式來設計。

　　資料庫是為捕獲資料而設計，資料倉庫是為分析資料而設計，它的兩個基本的元素是維表和事實表。維是看問題的角度，比如時間，部門，維表放的就是這些東西的定義，事實表裡放着要查詢的資料，同時有維的ID。

　　單從概念上講，有些晦澀。任何技術都是為應用服務的，結合應用可以很容易地了解。以銀行業務為例。資料庫是事務系統的資料平台，客戶在銀行做的每筆交易都會寫入資料庫，被記錄下來，這裡，可以簡單地了解為用資料庫記帳。資料倉庫是分析系統的資料平台，它從事務系統擷取資料，并做彙總、加工，為決策者提供決策的依據。比如，某銀行某分行一個月發生多少交易，該分行目前存款餘額是多少。如果存款又多，消費交易又多，那麼該地區就有必要設立ATM了。

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

　　資料倉庫，是在資料庫已經大量存在的情況下，為了進一步挖掘資料資源、為了決策需要而産生的，它決不是所謂的“大型資料庫”。那麼，資料倉庫與傳統資料庫比較，有哪些不同呢?讓我們先看看W.H.Inmon關于資料倉庫的定義:面向主題的、內建的、與時間相關且不可修改的資料集合。

　　“面向主題的”:傳統資料庫主要是為應用程式進行資料處理，未必按照同一主題存儲資料;資料倉庫側重于資料分析工作，是按照主題存儲的。這一點，類似于傳統農貿市場與超市的差別—市場裡面，白菜、蘿蔔、香菜會在一個攤位上，如果它們是一個小販賣的;而超市裡，白菜、蘿蔔、香菜則各自一塊。也就是說，市場裡的菜(資料)是按照小販(應用程式)歸堆(存儲)的，超市裡面則是按照菜的類型(同主題)歸堆的。

　　“與時間相關”:資料庫儲存資訊的時候，并不強調一定有時間資訊。資料倉庫則不同，出于決策的需要，資料倉庫中的資料都要标明時間屬性。決策中，時間屬性很重要。同樣都是累計購買過九車産品的顧客，一位是最近三個月購買九車，一位是最近一年從未買過，這對于決策者意義是不同的。

　　“不可修改”:資料倉庫中的資料并不是最新的，而是來源于其它資料源。資料倉庫反映的是曆史資訊，并不是很多資料庫處理的那種日常事務資料(有的資料庫例如電信計費資料庫甚至處理實時資訊)。是以，資料倉庫中的資料是極少或根本不修改的;當然，向資料倉庫添加資料是允許的。

　　資料倉庫的出現，并不是要取代資料庫。目前，大部分資料倉庫還是用關系資料庫管理系統來管理的。可以說，資料庫、資料倉庫相輔相成、各有千秋。

　　補充一下，資料倉庫的方案建設的目的，是為前端查詢和分析作為基礎，由于有較大的備援，是以需要的存儲也較大。為了更好地為前端應用服務，資料倉庫必須有如下幾點優點，否則是失敗的資料倉庫方案。

　　1.效率足夠高。客戶要求的分析資料一般分為日、周、月、季、年等，可以看出，日為周期的資料要求的效率最高，要求24小時甚至12小時内，客戶能看到昨天的資料分析。由于有的企業每日的資料量很大，設計不好的資料倉庫經常會出問題，延遲1-3日才能給出資料，顯然不行的。

　　2.資料品質。客戶要看各種資訊，肯定要準确的資料，但由于資料倉庫流程至少分為3步，2次ETL，複雜的架構會更多層次，那麼由于資料源有髒資料或者代碼不嚴謹，都可以導緻資料失真，客戶看到錯誤的資訊就可能導緻分析出錯誤的決策，造成損失，而不是效益。

　　3.擴充性。之是以有的大型資料倉庫系統架構設計複雜，是因為考慮到了未來3-5年的擴充性，這樣的話，客戶不用太快花錢去重建資料倉庫系統，就能很穩定運作。主要展現在資料模組化的合理性，資料倉庫方案中多出一些中間層，使海量資料流有足夠的緩沖，不至于資料量大很多，就運作不起來了。