數據庫壹般存儲在線交易數據，而數據倉庫壹般存儲歷史數據。
數據庫設計是盡可能避免冗余，壹般采用符合範式的規則，而數據倉庫設計是故意引入冗余，采用反範式。
數據庫是用來捕獲數據的，數據倉庫是用來分析數據的。它的兩個基本元素是維度表和事實表。維度是看問題的視角，比如時間、部門、維度表，裏面包含了這些東西的定義，事實表包含了要查詢的數據和維度的ID。
從概念上來說，有點晦澀。任何技術都是為應用服務的，結合應用就很容易理解。以銀行業為例。數據庫是交易系統的數據平臺。客戶在銀行的每壹筆交易都會被寫入數據庫並記錄在案。這裏可以簡單理解為用數據庫記賬。數據倉庫是分析系統的數據平臺，它從交易系統中獲取數據，對數據進行匯總和處理，為決策者提供決策的依據。比如某銀行某支行壹個月發生了多少筆交易，該支行的活期存款余額是多少。如果存款多，消費交易多，就要在這個區域設置自動取款機。
顯然，銀行的交易量是巨大的，通常以百萬甚至百萬倍計算。交易系統是實時的，要求時效性。客戶把壹筆錢存入幾十秒鐘，要求數據庫只能存儲很短壹段時間的數據，這是難以承受的。分析系統是事後的，它應該提供相關時間段內的所有有效數據。這些數據是海量的，匯總計算比較慢，但只要能提供有效的分析數據，就達到目的了。
數據倉庫的產生是為了在已經存在大量數據庫的情況下，進壹步挖掘數據資源，滿足決策的需要。絕不是所謂的“大型數據庫”。那麽，數據倉庫和傳統數據庫有什麽區別呢？我們來看看W.H.Inmon對數據倉庫的定義:面向主題的、集成的、與時間相關的、不可改變的數據集。
“面向主題”:傳統數據庫主要是為應用處理數據，可能不會按照同壹個主題存儲數據；數據倉庫側重於數據分析，按照主題存儲。這類似於傳統農貿市場和超市的區別——在市場裏，大白菜、蘿蔔、香菜會在壹個攤位，如果是小商販的話；超市裏白菜蘿蔔香菜各壹個。也就是說，市場裏的菜(數據)是按照攤販(應用)來堆放(存儲)的，而超市裏的菜是按照菜的種類來堆放的(同壹主題)。
“時間相關”:數據庫保存信息時，並不強調壹定要有時間信息。而數據倉庫則不同，由於決策的需要，數據倉庫中的數據要標註時間屬性。時間屬性在決策中非常重要。同樣的客戶，壹共買了九輛車，壹個最近三個月買了九輛車，壹個最近壹年沒買過車，對決策者的意義是不壹樣的。
“不可修改”:數據倉庫中的數據不是最新的，而是來自其他數據源。數據倉庫反映的是歷史信息，而不是很多數據庫處理的日常交易數據(有些數據庫，比如電信計費數據庫，甚至處理實時信息)。因此，數據倉庫中的數據很少或從不修改；當然，向數據倉庫添加數據是允許的。
數據倉庫的出現並不是要取代數據庫。目前，大多數數據倉庫都是由關系數據庫管理系統管理的。可以說數據庫和數據倉庫是相輔相成，各有優勢的。
順便說壹下，數據倉庫方案構建的目的是作為前端查詢和分析的基礎。由於其更大的冗余，它需要更多的存儲。為了更好地服務於前端應用，數據倉庫必須具備以下優勢，否則就是壹個失敗的數據倉庫方案。
1.足夠高效。客戶要求的分析數據壹般分為日、周、月、季、年等。可以看出，以日為周期的數據要求效率最高，要求客戶在24小時內甚至12小時內看到昨天的數據分析。由於壹些企業的日常數據量很大，設計很差的數據倉庫往往會出現問題，延遲1-3天給出數據顯然不可行。
2.數據質量。客戶想要看到各種信息，必須要有準確的數據。但是，因為數據倉庫過程至少分為三個步驟和兩個ETL，所以復雜的架構會有更多的層次。然後因為數據源有臟數據或者代碼不嚴謹，會導致數據失真。當客戶看到錯誤的信息，可能會導致錯誤的分析決策，造成損失，而不是收益。
3.擴展性。壹些大型數據倉庫系統的架構設計之所以復雜，是考慮到未來3-5年的可擴展性，讓客戶不用花太多的錢去重建數據倉庫系統就能穩定運行。主要體現在數據建模的合理性上，數據倉庫方案中有更多的中間層，讓海量的數據流有足夠的緩沖，這樣數據量不會大很多，也不會運行。