怎么理解物化视图呢，先随意拿一个建物化视图的例子看一下。
create materialized view EBS_ACCOUNTS_HIERARCHY_MV
refresh complete on demand
as
select v.flex_value,
v.description,
case
when (sysdate between nvl(v.start_date_active, sysdate) and
nvl(v.end_date_active, sysdate)) and (v.enabled_flag = 'Y') then
'Y'
else
'N'
end enabled_flag,
cv.parent_flex_value， v.created_by,
v.creation_date,
v.last_update_date,
v.last_updated_by,
nvl(v.start_date_active, sysdate) start_date_active,
nvl(v.end_date_active, sysdate) end_date_active,
v.summary_flag
from fnd_flex_values_vl v,
fnd_flex_value_sets s,
fnd_flex_value_children_v cv
where s.flex_value_set_id = v.flex_value_set_id
and s.flex_value_set_name = ' xxx_COA_xx'
and cv.flex_value_set_id = s.flex_value_set_id
and cv.flex_value = v.flex_value;
若忽略掉materialized以及 refresh complete on demand是不是可以理解为创建视图（视图仅是举例，因为物化视图可以查询表，视图和其它的物化视图），那么这两个起什么作用呢，可以把它们试做在视图上加的trigger，当满足trigger的条件生效后，视图里的数据会变化。可以想成，数据属于一层，而物化视图在它的上一层，当满足一定条件时，select视图中的数据才会随着下层数据的变化而变化，这也说明了两点：
1. 可以用于预先计算并保存表连接或聚集等耗时较多的操作的结果，这样，在执行查询时，就可以避免进行这些耗时的操作，而从快速的得到结果。
2. 当未满足条件时，基表的数据改变，但物化视图的数据没有改变，查询获取时有可能获取不到最新的数据。
也有另外一种理解方式，物化视图有很多方面和索引很相似：使用物化视图的目的是为了提高查询性能；物化视图对应用透明，增加和删除物化视图不会影响应用程序中SQL语句的正确性和有效性；物化视图需要占用存储空间；当基表发生变化时，物化视图也应当刷新。
语法
物化视图语法：
create materialized view materialized_view_name
build [immediate|deferred]--1.创建方式
refresh [complete|fast|force|never]--2.物化视图刷新方式
on [commit|demand]--3.刷新触发方式
start with (start_date)--4.开始时间
next (interval_date)--5.间隔时间
with [primary key|rowid]--默认 primary key
ENABLE QUERY REWRITE--7.是否启用查询重写
as--8.关键字
select statement;--9.基表选取数据的select语句
1.创建方式默认是immediate，立即；deferred，延迟，至第一次refresh时，才生效。
2.物化视图刷新方式默认为force，意思是：如果可以快速刷新，就执行快速刷新；否则，执行完全刷新。 complete，完全刷新，即，刷新时更新全部数据，包括视图中已经生成的原有数据。 fast，快速刷新，只刷新增量部分。前提是，需要在基表上创建物化视图日志（见示例）。该日志记录基表数据变化情况，所以才能实现增量刷新。 never，从不刷新。
3.on commit，基表有commit动作时，刷新视图，不能跨库执行(因为不知道别的库的提交动作)；on demand，在需要时刷新，即，根据后面设定的起始时间和时间间隔进行刷新，或者，手动调用dbms_mview包中的过程刷新时再执行刷新。
4和5.即开始刷新时间和下次刷新的时间间隔。如：start with sysdate next sysdate+1/1440表示马上开始，刷新间隔为1分钟。（与 on commit选项冲突）
6.基于基表的主键或者rowid创建。如果是基于rowid，不能对基表执行分组函数、多表连结等需要把多个rowid合成一行的操作（理由很简单：到底以哪个rowid为准呢？）。
7.如果设置了初始化参数query_rewrite_enabled=true则默认就会启用查询重写。但是，数据库默认该参数为false。并且，不是什么时候都应该启用查询重写。所以，该参数应该设置为false，而在创建特定物化视图时，根据需要开启该功能。另外，如果选择使用了上面第4‘5选项，则不支持查询重写功能（原因很简单，所谓重写，就是将对基表的查询定位到了物化视图上，而4、5选项会造成物化视图上部分数据延迟，所以，不能重写）。
创建物化试图主要选项说明
创建物化视图时可以指定多种选项，下面对几种主要的选项进行简单说明：
|
名称 |
Build Clause |
创建方式 |
|
描述 |
包括BUILD IMMEDIATE和BUILD DEFERRED两种 |
|
|
取值 |
BUILD IMMEDIATE |
在创建物化视图的时候就生成数据 |
|
|
BUILD DEFERRED |
在创建时不生成数据，以后根据需要在生成数据 |
|
默认 |
BUILD IMMEDIATE |
|
|
名称 |
Refresh |
刷新子句 |
|
描述 |
当基表发生了DML操作后，物化视图何时采用哪种方式和基表进行同步 |
|
|
语法 |
[refresh [fast | complete | force] [on demand | commit] [start with date] [next date] [with {primary key | rowid}] ] |
|
|
简介 |
FAST |
采用增量刷新，只刷新自上次刷新以后进行的修改；对于增量刷新选项，如果在子查询中存在分析函数，则物化视图不起作用。 |
|
|
COMPLETE |
对整个物化视图进行完全的刷新即完全刷新重新生成整个视图 |
|
|
FORCE(默认) |
Oracle在刷新时会去判断是否可以进行快速刷新，如果可以则采用Fast方式，否则采用Complete的方式，Force选项是默认选项 |
|
|
ON DEMAND(默认)
|
物化视图在用户需要的时候进行刷新，可以手工通过DBMS_MVIEW.REFRESH等方法来进行刷新，也可以通过JOB定时进行刷新 |
|
|
ON COMMIT
|
物化视图在对基表的DML操作提交的同时进行刷新 |
|
|
START WITH |
通知数据库完成从主表到本地表第一次复制的时间,应该及时估计下一次运行的时间点，因此它是和next成组出现 |
|
|
NEXT |
刷新时间间隔 |
|
|
WITH PRIMARY KEY(默认)
|
生成主键物化视图,也就是说物化视图是基于表的主键，而不是ROWID(对应于ROWID子句)。为了生成PRIMARY KEY子句，应该在表上定义主键，否则应该用基于ROWID的物化视图。主键物化视图允许识别物化视图表而不影响物化视图增量刷新的可用性 |
|
|
WITH ROWID
|
只有一个单一的主表，不能包括下面任何一项: ●Distinct ●聚合函数 ●Group by ●子查询 ●连接 ●SET操作 |
|
名称 |
Query Rewrite |
查询重写 |
|
描述
|
包括ENABLE QUERY REWRITE和DISABLE QUERY REWRITE两种。分别指出创建的物化视图是否支持查询重写。查询重写是指当对物化视图的基表进行查询时，Oracle会自动判断能否通过查询物化视图来得到结果，如果可以，则避免了聚集或连接操作，而直接从已经计算好的物化视图中读取数据 |
|
|
简介 |
ENABLE QUERY REWRITE |
支持查询重写 |
|
|
DISABLE QUERY REWRITE |
不支持查询重写 |
|
默认 |
DISABLE QUERY REWRITE |
|
创建实体化视图日志主要选项说明 ：
如果需要进行快速(FAST)刷新，则需要建立物化视图日志。物化视图日志根据不同物化视图的快速刷新的需要，可以建立为ROWID或PRIMARY KEY类型的。还可以选择是否包括SEQUENCE、INCLUDING NEW VALUES以及指定列的列表。
|
名称 |
WITH Clause |
|
|
描述 |
|
|
|
取值 |
OBJECT ID |
如果是对象物化视图(object materialized view)，则只能采用该方式 |
|
|
PRIMARY KEY |
|
|
|
ROWID |
|
|
|
SEQUENCE |
|
|
默认 |
|
|