Oraclei 实体化视图 执行概要 今天的数据库无论是数据仓库数据中心还是OLTP 系统都包含大量的信息等待人们去发现和理解然而如何以一种及时的方式查找和表示这些信息是一个重大的问题尤其是当需要搜索庞大数量信息的时候 实体化视图能够帮助解决这个问题因为它提供了一种快速访问和报告数据的方法 简介 实体化视图首先在Oraclei 中引入是称为概要管理的组件的一部分可能您的公司已经在使用实体化视图但只知道它的其他名字例如概要或聚合表在这里我们讨论如何创建和管理实体化视图还讨论查询重写功能如何透明地重写SQL 查询从而使用实体化视图来缩短查询响应时间这将使数据库用户完全无需知道存在哪些实体化视图 实体化视图应看作是一种特殊的视图它物理上存在于数据库内部可以包括联接和/或聚合它能够在执行之前预先计算开销大的联接和聚合操作因此它的存在缩短了查询执行时间 今天使用自身概要的公司花费了大量的时间用于手工创建概要识别将创建哪些概要对概要进行索引和更新以及建议用户使用哪些概要 现在DBA 将仅须在开始时创建实体化视图而无论数据源何时发生变化它都将被自动更新此外还有一个概要顾问组件它向DBA 推荐创建删除和保留哪些实体化视图 数据仓库或数据库用户将可以体会到使用实体化视图的最大好处之一DBA 无须再告诉他们存在哪些实体化视图他们可以对数据库中的表或视图编写自己的查询然后Oracle 服务器的查询重写机制将自动重写SQL 查询以使用实体化视图这样就大大缩短了查询响应时间终端用户无须了解概要 为何使用概要管理 当向数据仓库终端用户问起他们希望从中获得什么大部分人都会回答快速准确的信息但是这也给数据仓库设计者出了个大难题为了回答在y 地点我们卖出多少件x 产品同时希望避免读取表中的每一行必须建立一条到数据的快速路由 解决此问题最常见的办法之一就是创建概要表Oracle 将其称为实体化视图这一工作包括首先要理解典型负荷然后创建规模非常小的实体化视图实体化视图中可以包含所需信息的联接和/或聚合例如为了回答前面的问题实体化视图中每种产品对应于一行指明每个区域的销售量因此如果一家公司在 个地点销售 件产品则将要读取的最大行数始终为而无论已经售出多少商品 很明显实体化视图必须保证精确但该技术意味着终端用户现在需要读取的行数很少因此可以始终快速地接收结果数据库容量已经增长到兆兆字节因此使用这样的方法来缩短查询响应时间就显得越来越重要今天许多站点都创建了自己的概要表因此使用Oracle 概要管理所带来的额外好处是 Oracle 中的查询重写机制是透明的并采用实体化视图（即使它仅能部分满足查询的需要） 具有高级的查询重写可以使用实体化视图对不同聚合级别（例如按照星期月和年）进行报告 自动化机制刷新实体化视图单个请求刷新所有实体化视图 DBA 不再需要花时间查找应创建哪些实体化视图系统将基于过去对数据库或数据仓库的查询向DBA 提供有关需要哪些概要的信息 概要管理组件 组成概要管理的有五个组件 维度 实体化视图 刷新 查询重写 概要顾问 并不需要使用所有组件但所选用的组件越多获得的优势就越多现在我们将详细探讨这些组件 模式需求 用于实体化视图的模式类型或设计没有什么限制因此在数据仓库环境中模式可以是雪花式的设计但这并不是必须的 对于熟悉产品系统中数据库设计技术的设计者来说在一个数据仓库中必须使用不同的规则和技术例如产品数据库通常是规范化的因此在这种情况下时间维的表示方法最好是采用三个表日月年联接条件应该满足将每个日期行连接到一个（仅一个）月份行每个月份行连接到一个（仅一个）年份行数据仓库实现通常将导致一个完全非规范化的的时间维表其中日期月份年份栏都处于同一个表中不过无论设计使用的是规范化还是非规范化表都可以使用实体化视图 维度 在创建一个实体化视图之前第一步应该是回顾模式指明维度维度定义了列之间的层次化（父级/子级）关系所有的列无须来自同一个表我们强烈推荐定义数据的维度因为这将有助于查询重写和概要顾问做出更佳决策 数据库设计者所面临的另一个问题是频繁查询将不会直接涉及所有的维度列而仅参考与维度相关的那一列例如查询仅参考星期二而不是具体日期因此当定义了维度之后还必须描述维度列和表中其它列之间的关系 图 显示了包含两个层次的时间维从一个指定日期开始有一个层次告诉我们该日期涉及哪些财政周月或年而另一个层次定义了日月季度和年之间的关系 当定义了一个层次之后可以指定多个列来描述该层次例如如果City 在每个State 之内是唯一的但是在States 之间不唯一那么就需要指定一个地理层次其形式如（Country State
