在開始噴這個主題之前，讓我們先看看數據倉庫的官方定義：
數據倉庫(Data Warehouse)是1個面向主題的(Subject Oriented)、集成的(Integrate)、相對穩定的(Non-Volatile)、反應歷史變化(Time-Variant)的數據集合，用于支持管理決策。
以上是數據倉庫的官方定義。

“操作型數據庫”如銀行里記賬系統數據庫，每次業務操作（比如你存了5元錢），都會立刻記錄到這個數據庫中，久而久之，滿肚子積累的都是零碎的數據，這類干臟活累活還不得閑的數據庫就叫“操作型數據庫”，面向的是業務操作。

“數據倉庫”用于決策支持，面向分析型數據處理，不同于操作型數據庫；另外，數據倉庫是對多個異構的數據源有效集成，集成后依照主題進行了重組，并包括歷史數據，而且寄存在數據倉庫中的數據1般不再修改。

操作型數據庫、數據倉庫與數據庫之間的關系，就像 C:、D: 與硬盤之間的關系1樣，數據庫是硬盤，操作型數據庫是 C:，數據倉庫是 D:，操作型數據庫與數據倉庫都存儲在數據庫里，只不過表結構的設計模式和用處不同。

那末為何要在操作型數據庫和 BI 之間加這么1層“數據倉庫”呢？ 1是由于操作型數據庫晝夜奔忙，以快速響應業務為主要目標，根本沒精力服侍 BI 這邊的數據需求，而且 BI 這邊的數據需求通常是匯總型的，1個 select sum(xx) group by xx 就可以讓操作型數據庫耗費大量資源，業務處理跟不上趟，麻煩就大了，比如你存了 5000 元錢，發現10分鐘后錢還沒到賬，作何感想？1定是該銀行的領導在看餅圖？

2是由于企業中1般存在有多個利用，對應著多個操作型數據庫，比如人力資源庫、財務庫、銷售單據庫、庫存貨品庫等等，BI 為了提供全景的數據視圖，就必須將這些分散的數據綜合起來，例如為了實現1個融會銷售和庫存信息的 OLAP 分析，BI 工具必須能夠高效的獲得兩個數據庫中的數據，這時候最高效的方法就是將數據先整合到數據倉庫中，而 BI 利用統1從數據倉庫里取數。

將分散的操作型數據庫中的數據整合到數據倉庫中是1門大學問，催生了數據整合軟件的市場。這類整合其實不是簡單的將表疊加在1起，而是必須提取出每一個操作型數據庫的維度，將共同的維度設定為共用維度，然后將包括具體度量值的數據庫表依照主題統1成若干張大表（術語“事實表”，Fact Tables），依照維度-度量模型建立數據倉庫表結構，然落后行數據抽取轉換。后續的抽取1般是在操作性數據庫負載比較小的時候（如清晨），對新數據進行增量抽取，這樣數據倉庫中的數據就會構成積累。

大多數 BI 利用其實不要求獲得實時的數據，比如決策者，只需要在每周1看到上周的周報就能夠了，95% 的 BI 利用都不要 求實時性，允許數據有 1 小時至 1 個月不等的滯后，這是決策支持系統的利用特點，這個滯后區間就是數據抽取工具工作的時間。固然，BI 利用中通常還將包括極少的對實時數據的要求，這時候僅需針對這些特殊需求，將 BI Querying 軟件直接連接在業務數據庫上就能夠了，但是必須限制負載，制止做復雜查詢。

目前的數據庫產品都對數據倉庫提供有專門優化，例如在安裝 MySQL 的高版本時，安裝成序會詢問你是想讓數據庫實例作為 Transaction-Oriented ，還是 Decision Support ，前者就是操作型數據庫，后者就是數據倉庫（決策支持么，再振臂高呼1遍），針對這兩種情勢，數據庫將提供針對性的優化。

源自：http://www.powerbibbs.com/thread⑴31⑴⑴.html