1. 數據倉庫的關鍵特征
數據倉庫是一個面向主題的、集成的、隨時間而變化的、不容易丟失的數據集合，支持管理部門的決策過程。
面向主題：
面向主題，是數據倉庫顯著區別於關系數據庫系統的一個特征
圍繞一些主題，如顧客、供應商、產品等
關注決策者的數據建模與分析，而不是集中於組織機構的日常操作和事務處理。
排除對於決策無用的數據，提供特定主題的簡明視圖。
數據集成：
一個數據倉庫是通過集成多個異種數據源來構造的。
關系數據庫，一般文件，聯機事務處理記錄
使用數據清理和數據集成技術。
確保命名約定、編碼結構、屬性度量等的一致性。
當數據被移到數據倉庫時，它們要經過轉化。
隨時間而變化：
數據倉庫是從歷史的角度提供信息
數據倉庫的時間范圍比操作數據庫系統要長的多。
操作數據庫系統: 主要保存當前數據。
數據倉庫:從歷史的角度提供信息（比如過去 5-10 年）
數據倉庫中的每一個關鍵結構都隱式或顯式地包含時間元素，而操作數據庫中的關鍵結構可能就不包括時間元素。
不容易丟失：
盡管數據倉庫中的數據來自於操作數據庫，但他們卻是在物理上分離保存的。
操作數據庫的更新操作不會出現在數據倉庫環境下。
不需要事務處理，恢復，和並發控制等機制
只需要兩種數據訪問:
數據的初始轉載和數據訪問（讀操作）
2. OLTP和OLAP的區別：
OLTP與OLAP的介紹
-
OLTP：系統強調數據庫內存效率，強調內存各種指標的命令率，強調綁定變量，強調並發操作；
-
OLAP：系統則強調數據分析，強調SQL執行市場，強調磁盤I/O，強調分區等。
-
決策支持系統（DDS，Decision support system)，典型的操作是全表掃描，長查詢，長事務，但是一般事務的個數很少，往往是一個事務獨占系統。
OLTP與OLAP的區別：
OLTP的瓶頸與優化技術：
OLTP系統最容易出現瓶頸的地方就是CPU與磁盤子系統。
1）CPU出現瓶頸常表現在邏輯讀總量與計算性函數或者是過程上，邏輯讀總量等於單個語句的邏輯讀乘以執行次數，如果單個語句執行速度雖然很快，但是執行次數非常多，那么，也可能會導致很大的邏輯讀總量。設計的方法與優化的方法就是減少單個語句的邏輯讀，或者是減少它們的執行次數。另外，一些計算型的函數，如自定義函數、decode等的頻繁使用，也會消耗大量的CPU時間，造成系統的負載升高，正確的設計方法或者是優化方法，需要盡量避免計算過程，如保存計算結果到統計表就是一個好的方法。
2）磁盤子系統在OLTP環境中，它的承載能力一般取決於它的IOPS處理能力. 因為在OLTP環境中，磁盤物理讀一般都是db file sequential read，也就是單塊讀，但是這個讀的次數非常頻繁。如果頻繁到磁盤子系統都不能承載其IOPS的時候，就會出現大的性能問題。
OLTP比較常用的設計與優化方式為Cache技術與B-tree索引技術：
Cache決定了很多語句不需要從磁盤子系統獲得數據，所以，Web cache與Oracle data buffer對OLTP系統是很重要的。另外，在索引使用方面，語句越簡單越好，這樣執行計划也穩定，而且一定要使用綁定變量，減少語句解析，盡量減少表關聯，盡量減少分布式事務，基本不使用分區技術、MV技術、並行技術及位圖索引。因為並發量很高，批量更新時要分批快速提交，以避免阻塞的發生。
OLTP 系統是一個數據塊變化非常頻繁，SQL 語句提交非常頻繁的系統。 對於數據塊來說，應盡可能讓數據塊保存在內存當中，對於SQL來說，盡可能使用變量綁定技術來達到SQL重用，減少物理I/O 和重復的SQL 解析，從而極大的改善數據庫的性能。
這里影響性能除了綁定變量，還有可能是熱快（hot block）。 當一個塊被多個用戶同時讀取時，Oracle 為了維護數據的一致性，需要使用Latch來串行化用戶的操作。當一個用戶獲得了latch后，其他用戶就只能等待，獲取這個數據塊的用戶越多，等待就越明顯。 這就是熱快的問題。 這種熱快可能是數據塊，也可能是回滾端塊。 對於數據塊來講，通常是數據庫的數據分布不均勻導致，如果是索引的數據塊，可以考慮創建反向索引來達到重新分布數據的目的，對於回滾段數據塊，可以適當多增加幾個回滾段來避免這種爭用。
OLAP的缺點與優化：
在這樣的系統中，語句的執行量不是考核標准，因為一條語句的執行時間可能會非常長，讀取的數據也非常多。所以，在這樣的系統中，考核的標准往往是磁盤子系統的吞吐量（帶寬），如能達到多少MB/s的流量。
磁盤子系統的吞吐量則往往取決於磁盤的個數，這個時候，Cache基本是沒有效果的，數據庫的讀寫類型基本上是db file scattered read與direct path read/write。應盡量采用個數比較多的磁盤以及比較大的帶寬，如4Gb的光纖接口。
在OLAP系統中，常使用分區技術、並行技術。
分區技術在OLAP系統中的重要性主要體現在數據庫管理上，比如數據庫加載，可以通過分區交換的方式實現，備份可以通過備份分區表空間實現，刪除數據可以通過分區進行刪除，至於分區在性能上的影響，它可以使得一些大表的掃描變得很快（只掃描單個分區）。另外，如果分區結合並行的話，也可以使得整個表的掃描會變得很快。總之，分區主要的功能是管理上的方便性，它並不能絕對保證查詢性能的提高，有時候分區會帶來性能上的提高，有時候會降低。
並行技術除了與分區技術結合外，在Oracle 10g中，與RAC結合實現多節點的同時掃描，效果也非常不錯，可把一個任務，如select的全表掃描，平均地分派到多個RAC的節點上去。
在OLAP系統中，不需要使用綁定（BIND）變量，因為整個系統的執行量很小，分析時間對於執行時間來說，可以忽略，而且可避免出現錯誤的執行計划。但是OLAP中可以大量使用位圖索引，物化視圖，對於大的事務，盡量尋求速度上的優化，沒有必要像OLTP要求快速提交，甚至要刻意減慢執行的速度。
綁定變量真正的用途是在OLTP系統中，這個系統通常有這樣的特點，用戶並發數很大，用戶的請求十分密集，並且這些請求的SQL 大多數是可以重復使用的。
分開設計與優化
在設計上要特別注意，如在高可用的OLTP環境中，不要盲目地把OLAP的技術拿過來用。
如分區技術，假設不是大范圍地使用分區關鍵字，而采用其它的字段作為where條件，那么，如果是本地索引，將不得不掃描多個索引，而性能變得更為低下。如果是全局索引，又失去分區的意義。
並行技術也是如此，一般在完成大型任務時才使用，如在實際生活中，翻譯一本書，可以先安排多個人，每個人翻譯不同的章節，這樣可以提高翻譯速度。如果只是翻譯一頁書，也去分配不同的人翻譯不同的行，再組合起來，就沒必要了，因為在分配工作的時間里，一個人或許早就翻譯完了。
位圖索引也是一樣，如果用在OLTP環境中，很容易造成阻塞與死鎖。但是，在OLAP環境中，可能會因為其特有的特性，提高OLAP的查詢速度。MV也是基本一樣，包括觸發器等，在DML頻繁的OLTP系統上，很容易成為瓶頸，甚至是Library Cache等待，而在OLAP環境上，則可能會因為使用恰當而提高查詢速度。
對於OLAP系統，在內存上可優化的余地很小，增加CPU 處理速度和磁盤I/O 速度是最直接的提高數據庫性能的方法，當然這也意味着系統成本的增加。
比如我們要對幾億條或者幾十億條數據進行聚合處理，這種海量的數據，全部放在內存中操作是很難的，同時也沒有必要，因為這些數據快很少重用，緩存起來也沒有實際意義，而且還會造成物理I/O相當大。 所以這種系統的瓶頸往往是磁盤I/O上面的。
對於OLAP系統，SQL 的優化非常重要，因為它的數據量很大，做全表掃描和索引對性能上來說差異是非常大的。
對於OLAP系統來說，絕大多數時候數據庫上運行着的是報表作業，執行基本上是聚合類的SQL 操作，比如group by，這時候，把優化器模式設置為all_rows是恰當的。 而對於一些分頁操作比較多的網站類數據庫，設置為first_rows會更好一些。 但有時候對於OLAP 系統，我們又有分頁的情況下，我們可以考慮在每條SQL 中用hint。 如：Select a.* from table a;
3. 多維數據模型
數據倉庫和OLAP工具基於多維數據模型
在多維數據模型中，數據以數據立方體(data cube)的形式存在。數據立方體允許以多維數據建模和觀察。它由維和事實定義。維是關於一個組織想要記錄的視角或觀點。每個維都有一個表與之相關聯，稱為維表。
多維數據模型圍繞中心主題組織，該主題用事實表表示。事實表包括事實的名稱或度量以及每個相關維表的關鍵字。事實指的是一些數字度量。
概念模型：
星型模式、雪花模式、或事實星座模式的形式存在。
星型模式（Star schema）: 事實表在中心，周圍圍繞地連接着維表（每維一個），事實表含有大量數據，沒有冗余。
雪花模式（Snowflake schema）: 是星型模式的變種，其中某些維表是規范化的，因而把數據進一步分解到附加表中。結果，模式圖形成類似於雪花的形狀。
事實星座（Fact constellations）: 多個事實表共享維表, 這種模式可以看作星型模式集，因此稱為星系模式（galaxy schema），或者事實星座（fact constellation）
4. 數據倉庫的架構
底層：數據倉庫的數據庫服務器
關注的問題：如何從這一層提取數據來構建數據倉庫（通過Gateway（ODBC,JDBC,OLE/DB等）來提取）
中間層：OLAP服務器
關注的問題：OLAP服務器如何實施（關系型OLAP，多維OLAP等）
前端客戶工具層
關注的問題：查詢工具、報表工具、分析工具、挖掘工具等
5. 聯機分析挖掘OLAM的體系結構
