今天的数据库，无论是数据仓库、数据中心还是OLTP 系统，都包含大量的信息等待人们去发现和理解。然而，如何以一种及时的方式查找和表示这些信息是一个重大的问题，尤其是当需要搜索庞大数量信息的时候。
实体化视图能够帮助解决这个问题，因为它提供了一种快速访问和报告数据的方法。
简介
实体化视图首先在Oracle8i 中引入，是称为“概要治理”的组件的一部分。可能您的公司已经在使用实体化视图，但只知道它的其他名字，例如概要或聚合表。在这里我们讨论如何创建和治理实体化视图，还讨论查询重写功能如何透明地重写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、概要顾问。
并不需要使用所有组件，但所选用的组件越多，获得的优势就越多。现在我们将具体探讨这些组件。
模式需求
用于实体化视图的模式类型或设计没有什么限制。因此在数据仓库环境中，模式可以是雪花式的设计，但这并不是必须的。
对于熟悉产品系统中数据库设计技术的设计者来说，在一个数据仓库中必须使用不同的规则和技术。例如，产品数据库通常是规范化的，因此在这种情况下，时间维的表示方法最好是采用三个表：日、月、年。联接条件应该满足：将每个日期行连接到一个（仅一个）月份行，每个月份行连接到一个（仅一个）年份行。数据仓库实现通常将导致一个完全非规范化的的时间维表，其中日期、月份、年份栏都处于同一个表中。不过，无论设计使用的是规范化还是非规范化表，都可以使用实体化视图。
