因爲是轉載，首先將原文的鏈接粘出來：http://www.cnblogs.com/xugang2008/archive/2009/07/09/1519777.html
本文小白我只是看過，感覺對於和我一樣搞不清數據倉庫的人來說，還是能從一個比較淺顯的角度去解釋的。但我尚未對數據倉庫有過較細緻的研究，等進一步研究之後，再自己寫一篇博文，解釋數據倉庫。
下面是原文：
目前，數據倉庫一詞尚沒有一個統一的定義，著名的數據倉庫專家W.H.Inmon在其著作《Building the Data Warehouse》一書中給予如下描述：數據倉庫（Data Warehouse）是一個面向主題的（Subject Oriented）、集成的（Integrate）、相對穩定的（Non-Volatile）、反映歷史變化（Time Variant）的數據集合，用於支持管理決策。對於數據倉庫的概念我們可以從兩個層次予以理解，首先，數據倉庫用於支持決策，面向分析型數據處理，它不同於企業現有的操作型數據庫；其次，數據倉庫是對多個異構的數據源有效集成，集成後按照主題進行了重組，幷包含歷史數據，而且存放在數據倉庫中的數據一般不再修改。
數據庫是一個裝數據（信息的原材料）的地方。數據倉庫是一種系統，這種系統也是用數據庫裝東西。
數據倉庫系統（用數據庫裝東西）與其他基礎業務系統（例如財務系統、銷售系統、人力資源系統等，也是用數據庫裝東西）的區別是：
基礎業務系統的特點是各管各的，例如財務系統生產了白菜，那麼用一個數據庫來裝，人力資源系統生產了豬肉，再用一個數據庫來裝。我要做一道菜，需要分別到各個數據庫去取，比較麻煩（現實的情況是大部分時候讓種菜的農民伯伯送過來，但送過來的東西不一定是我想要的，而且不同的時候我想要不同的東西，經常會被農民伯伯罵，弄得雙方都不開心）。另外一方面，各個數據庫中放的是一些比較原始的東西，我要拿過來做菜，還需要經過很麻煩的清洗過程，一不小心裏面可能就藏着一條大青蟲。
那麼，數據倉庫系統就是建立一個大的超市，將各地農民伯伯出產的東西收集過來，清洗乾淨，分門別類地放好。這樣，你要哪種菜的時候，直接從超市裏面拿就可以了。
早期一直不理解數據倉庫是什麼困惑得很。
宏觀一點講，數據倉庫就是堆放公司所有數據的地方，之所以把數據都堆在一起，是爲了從中間找到有價值的東西。
數據倉庫更多的是一個概念，不要把數據倉庫想成那些號稱是數據倉庫的軟件產品們。
數據倉庫的物理上就是數據庫。相對業務系統數據庫叫OLTP數據庫（用於業務處理），這種數據庫叫OLAP數據庫（用於業務分析）。
數據倉庫的概念是針對以下基本需求產生的：
公司的業務系統很多，業務系統的歷史數據不方便查詢。不同的業務系統往往管理部門不同，地域不同。能不能將所有這些數據集中起來，再淘淘有沒有有意義的業務規律。
數據倉庫數據庫往往很大，因爲公司所有的數據集中得越多，越能淘到有價值的發現。例如隨便就100G以上。
數據倉庫的組成十分繁雜，既有業務系統的歷史數據，又有人事、財務數據，還要自己建一些基礎性的數據，例如，公共假期數據、地理信息、國家信息等等。
數據倉庫概念包含從業務生產系統採集數據的程序，這個程序還不能影響業務系統的運行。（屬於所謂“ETL”過程）
數據倉庫包括業務系統長期的歷史數據，例如5年，用來分析。（所謂“ODS”數據）
數據倉庫包括針對某相業務值（例如銷售量）重新打上標籤的業務流水數據。（所謂“事實表”、“維度表”）。
數據倉庫概念興許還包含報表生成工具（所謂“BI”工具）。這些工具能夠達到幾年前所謂DSS（決策分析）的效果。
數據倉庫的客戶歷史資量的分析，也許又與CRM系統粘點邊。
總之，一點，一個公司想針對已有的歷史業務數據，充分的利用它們，那麼就上數據倉庫項目。至於哪些嚇唬人的大寫字母的組合，只是達到這個目標的科學技術罷了。
牢記住數據倉庫的基本需求，不要被供應商嚇着。
數據倉庫可以說是決策支持系統，能幫助老闆瞭解企業的整體全貌，看到數據倉庫提供的經過整理統計歸納的數據後老闆憑自己的管理經驗可以發現企業的問題或困難或成功因素在哪一方面，然後可以不斷的追溯數據，直到確定到最具體的細節上，這樣能夠不斷提升老闆或管理層的管理水平，不斷改善企業的管理。我們知道的最好的一個例子就是美國某大型超市啤酒和尿布的故事。
沃爾瑪公司在美國的一位店面經理曾發現，每週，啤酒和尿布的銷量都會有一次同比攀升，一時卻搞不清是什麼原因。後來，沃爾瑪運用商業智能（Business
Intelligence，簡稱ＢＩ）技術發現，購買這兩種產品的顧客幾乎都是25歲到35歲、家中有嬰兒的男性，每次購買的時間均在週末。沃爾瑪在對相關數據分析後得知，這些人習慣晚上邊看球賽、邊喝啤酒，邊照顧孩子，爲了圖省事而使用一次性的尿布。得到這個結果後，沃爾瑪決定把這兩種商品擺放在一起，結果，這兩種商品的銷量都有了顯著增加。
數據庫是數據倉庫的基礎。數據倉庫實際上也是由數據庫的很多表組成的。需要把存放大量操作性業務數據的數據庫經過篩選、抽取、歸納、統計、轉換到一個新的數據庫中。然後再進行數據展現。老闆關注的是數據展現的結果。
數據倉庫(DATA WAREHOUSE/DATA MART)的另一重要概念是數據從不同的數據庫(DATABASES) 裏調出經過ETL工具(如POWERCENTRE，DECISIONSTREAM, SQL SERVER 2000 DTS, SQL SERVER 2005 SSIS)過程進行清理，確證，整合並設計成多維(dimensional framework)。以保證數據的正確、準確、完整, 這是非常重要的一點。
我們現在的項目穩定運行了6年多，一直自己開發，最近慢慢開始使用datastage。很多大型項目之所以用工具，是因爲工具的本身的特點是開發快，效率相對還可以，讓你更好地有精力用在業務、數據庫的優化以及數據測試上，和數據質量本身並沒有關係。
而數據質量關係最密切的還是從設計（架構、模型等）、業務關係的理解、項目管理（含和客戶的交流，以及遵從開發流程和測試流程）等一系列項目工程的過程。這也是爲什麼很多項目使用了ETL工具，但是數據質量還是提高不大的主要原因。
數據倉庫的作用重在數據的集中管理。集中管理的最終目的是爲了分析，預測。
所謂的ETL。不過是數據倉庫的構建的一個必須過程。數據的抽取轉換與裝載，都是爲了集中管理所做的基礎工作，這些數據與動作的描述，都會有有響應的元數據進行描述。
在數據倉庫建模的過程，我們一般都是採用多維模型，如星形，雪花型等等，這樣做最大的特點就是效率高，數據的冗餘度低。所以，把OLAP與數據倉庫混爲一談我認爲是片面的解釋。
我們也可以選擇業務邏輯模型建立數據倉庫，這是很早以前的做法了，特點就是效率不高，數據的冗餘度高，但他能實現非常難以表達的業務邏輯設計。
基於數據倉庫最重要的是分析與預測，我認爲，歷史現在將來是數據倉庫的精華。。
基於數據倉庫的DM，OLAP都是爲了分析與預測。爲了讓使用企業單位更好的把握現在，預測將來，因此他最實效的說法我認爲是給決策者與管理者進行決策管理提供分析與預測的依據。
另外，數據倉庫還會起到歷史數據分類歸檔的目的（就像圖書館一樣），屆時可以通過檢索條件方便的查詢歷史信息；而同類信息在OLTP中早已被更新了。
至於它的分析功能，就象氣象考古研究工作，在不同深度的冰川中保存着當時的氣象信息，否則拿什麼預測氣候變化趨勢呢！
不過，要有相當的管理及技術儲備以及管理層的強力支持纔可以。先有需求，並具備了必要條件纔可上馬，否則您的數據倉庫將不是超市而是個垃圾堆，“garbage
in，then garbage out”！
所以，我認爲是企業信息化建設及科學管理水平的提高催生了數據倉庫的必然產生，不要趕時髦，炒概念，關鍵還是冷靜分析自己企業的現實狀況是否到了必須部署數據倉庫的階段了！
至於如何說服管理者，則需要您的努力了，不要站在您技術人員的立場闡述問題，CEO對技術問題不感興趣，站在他們的角度考慮問題，回答諸如“我們投入如此大的資金、人力，同時面對升級系統的巨大風險，目的何在？”記住，CEO和CFO（甚至包括CIO）是更希望用數字說話的，您分析一下公司的管理決策流程，就可以向他們提出很有價值的決策支持報表，而部門經理（或類似人員）每季度也不必頭大的製作相關分析報表了，節省的精力可以做更多有價值的事情，這就是企業人力資源利用率的巨大提升，可以節省多少銀子，恐怕CEO不會用你提示了吧！
談談一年來關於數據倉庫好處的困惑、探索和感悟
quote:
最初由 maltig 發佈
早期一直不理解數據倉庫是什麼困惑得很。
宏觀一點講，數據倉庫就是堆放公司所有數據的地方，之所以把數據都堆在一起，是爲了從中間找到有價值的東西。
數據倉庫更多的是一個概念，不要把數據倉庫想成那些號稱是數據倉庫的軟件產品們。
數據倉庫的物理上就是數據庫。相對業務系統數據庫叫OLTP數據庫（用於業務處理），這種數據庫叫OLAP數據庫（用於業務分析）。
數據倉庫的概念是針對以下基本需求產生的：
公司的業務系統很多，業務系統的歷史數據不方便查詢。不同的業務系統往往管理部門不同，地域不同。能不能將所有這些數據集中起來，再淘淘有沒有有意義的業務規律。
數據倉庫數據庫往往很大，因爲公司所有的數據集中得越多，越能淘到有價值的發現。例如隨便就100G以上。
數據倉庫的組成十分繁雜，既有業務系統的歷史數據，又有人事、財務數據，還要自己建一些基礎性的數據，例如，公共假期數據、地理信息、國家信息等等。
數據倉庫概念包含從業務生產系統採集數據的程序，這個程序還不能影響業務系統的運行。（屬於所謂“ETL”過程）
數據倉庫包括業務系統長期的歷史數據，例如5年，用來分析。（所謂“ODS”數據）
數據倉庫包括針對某相業務值（例如銷售量）重新打上標籤的業務流水數據。（所謂“事實表”、“維度表”）。
數據倉庫概念興許還包含報表生成工具（所謂“BI”工具）。這些工具能夠達到幾年前所謂DSS（決策分析）的效果。
數據倉庫的客戶歷史資量的分析，也許又與CRM系統粘點邊。
總之，一點，一個公司想針對已有的歷史業務數據，充分的利用它們，那麼就上數據倉庫項目。至於哪些嚇唬人的大寫字母的組合，只是達到這個目標的科學技術罷了。
牢記住數據倉庫的基本需求，不要被供應商嚇着。
數據倉庫是幹什麼的，到現在，我終於看到了成果。
一年半以前，我來到現在這家公司(一家證券公司)。跟所有2004年的證券公司一樣，“生”與“死”是當時考慮的唯一問題。爲獲得證監會的“創新業務資格”(獲得這個牌照就如同獲得了免死金牌，不但能夠生存而且能獲得資助從而做大做強)，公司急需上馬一套集中監控系統，我就是爲了這個項目被招募到公司。
背景：
在證券行業中，所有公司的業務系統（所謂證券交易系統）有一個基本特徵：每一個分支機構（所謂營業部）的交易系統都是獨立的（地理上、管理上），這樣總部沒辦法在技術上對數十套這樣的系統的業務數據進行及時的分析與覈對。（當然這兩年幾乎所有公司都實現了交易系統的集中。）於是，幾乎所有的證券公司都上馬了一套集中監控系統，它通過廣域網，把公司下屬的這幾十家營業部的數據實時或當天晚上採集到總部的數據庫中，白天實時的對資金存取、證券買賣等業務行爲進行監控，晚上再運算一些覈對功能，看資金和證券是否帳實相符，再通過WEB界面將結果展示給公司審計部門。我們公司在05年上半年上了這個系統。
由於手頭上的這個系統整合了公司所有的業務系統的數據(30多套分佈在全國各地的交易系統、30多套財務系統、集中清算系統、登記公司數據、等等)，所以象每個技術型IT員工一樣，我有一個自然而然的想法：能不能搞清楚公司所有業務信息的邏輯關係，自己建一個數據庫，搞一個數字虛擬證券公司，在我的這個數據庫中包含公司每一個業務細節的信息，業務部門不管要什麼，我都能很快提供出來（而不是依賴供應商）。
OK。在我這個最樸素的想法的支配下，我開始學習數據庫（搞了若干年IT基礎設施的我，居然在2004年底又開始學習數據庫！可見中國的IT崗位有多麼不清晰。），向供應商請教底層數據結構，向他們請教業務邏輯關係。3個月後，我居然已經能夠對供應商提供的“監控功能”提供完全的功能驗證，指出了無數的功能BUG，同時也具備了證券交易、結算業務邏輯的完全的知識。於是想着手搞一套表名字段名命名規則、再搞一套表對應關係（到後來才知道這叫建立“數據模型”），把證券公司的業務描述得清清楚楚，但到底怎麼搞，朦朦濃濃的，不知如何下手。
另外，我這個人最講究前因後果，所以十分想對證券業務信息中的因果關係搞清楚講明白。例如：統計出來的股票交易量的前提條件有很多：不同營業部、不同的委託方式、不同的交易所、不同的幣種、不同的證券類別、不同的客戶規模、不同的客戶年齡段、不同的月份日期，等等，出來的交易量結果都不一樣。可以用一個表來描述，前邊都是因素字段，最後一個是一數值型的交易量字段。濛濛濃濃知道這裏邊有邏輯關係，但總說不清道不明。
一般而言，越是本能的困惑，往往越是一門大學問。我們在現實工作中遇到的很多問題，美國人早就遇到了，並形成了文字、理論（還起了一堆足以讓我們愣住的大寫字母組成的名次。）我們缺乏的是對我們自己本質需求的理解，和與外國已有經驗（經驗經過歸納後就叫理論），的連接。
考慮到項目招標時，供應商如何描述“數據倉庫”“元數據”等等，搞不清的概念，於是想搞清楚到底什麼是“數據倉庫”。於是去圖書城，專門到數據倉庫、OLAP、多維建模書籍區域去，挨個拿過來翻。注意：如果你沒有這方面的困惑和經驗，很難對這些書產生共鳴（或者理解），特別是翻譯這些專業書籍的人往往本身對這些東西不懂，所以又誤導了一批讀者。所以，十幾本書裏，我只對2本里的一些描述產生強烈的共鳴。
1、《維度建模完全指南》（該書的作者自稱是“數據倉庫”的鼻祖）開篇對“數據倉庫項目經理”的本質做了描述：一個數據的收集者，一個數據的整理者，一個統計分析數據的發佈者。OK。完全與我的濛濛濃濃的對自己在公司裏的定位完全一致！作者認爲，數據倉庫的本質就是收集儘可能多的信息，用作公司的決策支持（中國人總認爲做決策的人一定是領導，所以把“決策支持”等同於“領導查詢”，其實在美國，“決策”（decision）是分散到普通員工的（通常是普通的業務人員），而且任何一項普通的業務決定也叫“決策”，並不是“戰略決策”才叫決策。所以“決策支持”絕對不是什麼高深的東西）。經過清理的數據往往以一種特定的格式（所謂星型結構）存放在數據庫中，整本書就是與讀者探討（注意是“探討”，而不是“傳授”，所有美國的這類權威書籍裏都極力強調不要按書裏的方法去實踐，這就是美國鼓勵自主創新和中國服從權威的不同文化的典型體現）這方面的經驗。
2《建立多維信息系統》，以一步步深入的方式，解釋了維度的概念。所謂“維度”，就是前邊我理解的“因素字段”，影響誰呢？表結構中最後的那個數值型的字段。例如證券交易量字段。交易量字段就是一個“事實”、fact。營業部、委託方式、交易所、幣種、證券類別、客戶規模、客戶年齡段、交易日期，都是因素字段，就是維度！數數有多少？8個，就是8維。當然可以更多。這就是多維的概念。在我們本能的對日常事務的分析中，就蘊含了“多維”的概念，只是我們沒把這種意識寫下來，出書，辦研討會等等。美國人做事就是較真，我們的朦朦濃濃的東西，到人家那裏就是幾萬人研究幾十年！
因爲證券公司就靠着客戶做證券交易收取手續費，所以業務部門對交易量的統計報表需求很強烈。2年前，由每個營業部發Email報報表，專門一個人彙總。現在有了集中的業務數據，業務部門就開始使用供應商提供的業務統計報表。太多了，例如：以營業部爲行，證券類別爲列出一張報表；以月份爲單位出，以周爲單位出；算公司交易量對證券交易所交易量的比例。等等。算了一下，不下30多張。還經常要變動。一覺得數據不正常，就找我，讓我找找原因。於是，我就到數據庫裏去，這個字段加上那個字段再按某個字段某段時間來彙總，哦，怎麼算出來跟供應商提供的報表的數值不對呢？於是打電話給供應商，讓他們找問題。第二天給我一個升級補丁。好，報表好了。反反覆覆，搞死了。
總書j不是號召自主創新嗎？乾脆我自己搞一套。於是找出影響交易量的10個因素，建了一張表，前10個字段是（營業部、委託方式、交易所、幣種、證券類別、客戶規模、客戶年齡段、交易性質、交易月份、交易周），最後一個是交易量。寫了個SQL過程，每天生成這張表（後來才知道，這張表就叫CUBE。術語害死人吶。），再在EXECL裏寫了一些VBA（簡直把美國人10個崗位分工乾的活全包了），可以把這個表下載到EXCEL中。再用EXCEL的“數據旋轉表”（正式中文譯名爲“數據透視表”，但我覺得一定要用上“旋轉”這兩個點睛的字）的功能，就可以靈活的配置與這10個因素字段相關的所有報表。（我們公司根本沒人用過“數據旋轉表”這個功能，甚至連“自動篩選”的功能都沒用過。）自己挺得意的。但跟後面用MicroStrategy做出來的報表比起來就差得太遠了！
日本母公司有一套MicroStratey，對中國區總裁說如何如何好，於是2005年初買了一套，做管理財務數據分析。由另一個同事負責。（當時我很奇怪，這種商業智能、BI、決策支持、數據倉庫、OLAP、多維的工具應該由我來管理纔對。）一直擱置在那裏，直到05年底。業務部門提出對營業部每月新增底有效客戶進行分析，纔想起讓我用MicroStrategy作爲平臺。正中下懷。於是，構建一個完全獨立於供應商數據結構體系的數據倉庫（這裏指狹義的數據倉庫，或者叫數據倉庫展示區）成了一項現實的工作。
開始着手設計表結構。（設計一套完整的證券公司業務數據倉庫可不是一件好玩的事情。）完全是瀑布方法進行設計，不斷的嘗試，修改，從頭再來。幾個月前曾沿用供應商的字段命名規則，維度表不使用代理鍵，試着做了套數據倉庫模型，用MicroStrategy做做報表，還可以。到了春節，下決心完全重新設計這個數據倉庫。這下可好，好多個晚上睡不好，腦子裏完全是這個表應該是什麼字段，時間維度如何劃分層次，如何來劃分事實，搞幾個大的事實範疇，粒度到什麼級別，那些事實是一個粒度，這些事實需要不同的事實表描述嗎，維度表直接的關係，怎樣設計維度最能保證將來的擴充性，如何避免雪花型。不斷的返工。整個模型，越來越清晰。最終，自己覺得滿意了，既能滿足最基本的需求，也能保證將來對這個模型的擴充。又開始寫SQL存儲過程，驗證數據轉換的準確性，不斷的修改，不斷的擴充。不斷的告誡自己，不要過於最求完美，告誡自己適度的缺陷是項目前進的保證。總之，有了一套完全自主知識產權的東西，並且自認爲還是比較完備、復扎和嚴謹的，沒有足夠的思索是難以獲得這個東西的。
開始設置MicroStrategy，從沒系統的用過，什麼都是摸石頭過河。但在使用這個OLAP工具的時候，完全體會到它的好處。因爲，我爲業務部門做過太多的SQL統計，多到我自己都想要搞一套SELECT語句的自動生成工具。結果發現，MICROSTRATEGY完全就是我想要的東西！設置好什麼實體、事實、度量、層系、上下級關係之類的東西，然後不斷的試這做一些報表，找到自動生成的SELECT語句跟之前設置的那些東西到底是什麼關係。沒多久就摸熟了。（因爲關於如何使用SELECT語句生成各種報表，我有太多的經驗和苦悶。）
出來的效果出奇的好，靈活的實體配置，行列擡頭的隨意旋轉，各種方向的鑽取，彙總表的自動選取。從沒覺得OLAP工具這麼好用。有了它，我甚至再也不用去寫SELECt語句，不用在不同的表直接Join來join去。3分鐘就能做一張所謂的報表。
到現在，可以說，我已經完全領悟到數據倉庫的好處。雖然這些好處只是冰山一角。
但是話說回來，如果甲方沒有我這個“人”，沒有對數據倉庫的理解人，沒有願意對數據分析的人，公司沒有精細化管理的意識，沒有較真的社會風氣，“數據倉庫”這個概念還不是廢物一堆，或者是外國供應商騙錢的口實？
一般人只看到數據倉庫好處的表皮，其實還有一個重要作用是，數據倉庫通過分析數據（包括報表、OLAP、挖掘），能把分析出來的東西找出來，就可以對症下藥，採取措施。比如某品牌產品，在某代理商代理的銷售中，在某地區某季度業績很差，於是在下鑽分析，分析出銷售中第幾步出了問題，分析出問題是質量不好，服務不好，還是其他原因。分析好了後，在即席查詢中將所有條件列出，查詢出具體的情況，公司相關部門負責人去處理，解決好具體環節。
這纔是數據倉庫解決實際具體情況的深入應用，不僅僅是給老總決策參考，而是給老總及部門負責人具體的，詳細的信息，指導如何去處理。
這樣講不知道你是不是好理解一點：
數據倉庫的概念是美國傳進來的。講講在美國，數據倉庫這個概念是怎麼興起的。
30年前，所有的美國的任何行業都轟轟烈烈的進行着信息化的活動。各種業務活動都由電腦處理，叫做“業務系統”。
必然的，所有業務系統裏都有查詢統計功能。
20年前，隨着電腦化的業務系統裏存儲的歷史數據逐漸增加，他們發現查詢歷史數據或者做業務統計的速度越來越慢。對業務數據統計分析的需求也越來越複雜。業務系統已經不堪重負。
於是很多公司就把，業務系統裏的歷史數據拿出來，放在另一個地方，專門負責對歷史數據的查詢統計分析。這個工作顯得越來越重要，也越來越有企業肯花錢來做，也越來越有人認真的研究怎麼把查詢統計分析的工作做好。
10多年前，開始美國人開始有人起名字，就叫“數據倉庫”。
這就是“數據倉庫”這個名詞的由來。當然，在這個領域術語極不規範，說白了就是專門用來查詢分析統計業務數據的數據庫。