今天的數據庫，無論是數據倉庫、數據中心還是OLTP 系統，都包含大量的信息等待人們去發現和理解。然而，如何以一種及時的方式查找和表示這些信息是一個重大的問題，尤其是當需要搜索龐大數量信息的時候。 實體化視圖能夠幫助解決這個問題，因為它提供了一種快速訪問和報告數據的方法。 簡介 實體化視圖首先在Oracle8i 中引入，是稱為“概要治理”的組件的一部分?？赡苣墓疽呀浽谑褂脤嶓w化視圖，但只知道它的其他名字，例如概要或聚合表。在這里我們討論如何創建和治理實體化視圖，還討論查詢重寫功能如何透明地重寫SQL 查詢，從而使用實體化視圖來縮短查詢響應時間。這將使數據庫用戶完全無需知道存在哪些實體化視圖。 實體化視圖應看作是一種非凡的視圖，它物理上存在于數據庫內部，可以包括聯接和/或聚合。它能夠在執行之前預先計算開銷大的聯接和聚合操作，因此它的存在縮短了查詢執行時間。 今天，使用自身概要的公司花費了大量的時間用于手工創建概要、識別將創建哪些概要、對概要進行索引和更新，以及建議用戶使用哪些概要。 現在DBA 將僅須在開始時創建實體化視圖，而無論數據源何時發生變化，它都將被自動更新。此外還有一個概要顧問組件，它向DBA 推薦創建、刪除和保留哪些實體化視圖。 數據倉庫或數據庫用戶將可以體會到使用實體化視圖的最大好處之一，DBA 無須再告訴他們存在哪些實體化視圖。他們可以對數據庫中的表或視圖編寫自己的查詢。然后Oracle 服務器的查詢重寫機制將自動重寫SQL 查詢以使用實體化視圖。這樣就大大縮短了查詢響應時間，終端用戶無須“了解概要”。 為何使用概要治理 當向數據倉庫終端用戶問起他們希望從中獲得什么，大部分人都會回答：快速準確的信息。但是這也給數據倉庫設計者出了個大難題：為了回答“在y 地點我們賣出多少件x 產品”，同時希望避免讀取表中的每一行，必須建立一條到數據的快速路由。 解決此問題最常見的辦法之一就是創建概要表，Oracle 將其稱為實體化視圖。這一工作包括首先要理解典型負荷，然后創建規模非常小的實體化視圖，實體化視圖中可以包含所需信息的聯接和/或聚合。例如，為了回答前面的問題，實體化視圖中每種產品對應于一行，指明每個區域的銷售量。因此假如一家公司在5 個地點銷售2000 件產品，則將要讀取的最大行數始終為10000，而無論已經售出多少商品。 很明顯，實體化視圖必須保證精確，但該技術意味著終端用戶現在需要讀取的行數很少，因此可以始終快速地接收結果。數據庫容量已經增長到兆兆字節，因此使用這樣的方法來縮短查詢響應時間就顯得越來越重要。今天許多站點都創建了自己的概要表，因此使用Oracle8 概要治理所帶來的額外好處是： 1、Oracle 中的查詢重寫機制是透明的并采用實體化視圖（即使它僅能部分滿足查詢的需要）。 2、具有高級的查詢重寫，可以使用實體化視圖對不同聚合級別（例如按照星期、月和年）進行報告。 3、自動化機制刷新實體化視圖，單個請求刷新所有實體化視圖。 4、DBA 不再需要花時間查找應創建哪些實體化視圖。系統將基于過去對數據庫或數據倉庫的查詢，向DBA 提供有關需要哪些概要的信息。 概要治理組件 組成概要治理的有五個組件： 1、維度。 2、實體化視圖。 3、刷新。 4、查詢重寫。 5、概要顧問。 并不需要使用所有組件，但所選用的組件越多，獲得的優勢就越多。現在我們將具體探討這些組件。 模式需求 用于實體化視圖的模式類型或設計沒有什么限制。因此在數據倉庫環境中，模式可以是雪花式的設計，但這并不是必須的。 對于熟悉產品系統中數據庫設計技術的設計者來說，在一個數據倉庫中必須使用不同的規則和技術。例如，產品數據庫通常是規范化的，因此在這種情況下，時間維的表示方法最好是采用三個表：日、月、年。聯接條件應該滿足：將每個日期行連接到一個（僅一個）月份行，每個月份行連接到一個（僅一個）年份行。數據倉庫實現通常將導致一個完全非規范化的的時間維表，其中日期、月份、年份欄都處于同一個表中。不過，無論設計使用的是規范化還是非規范化表，都可以使用實體化視圖。