视图的引入
1，视图是一种虚拟的表，是从数据库中一个或者多个表中导出来的表。

2，数据库中只存放了视图的定义，而并没有存放视图中的数据，这些数据存放在原来的表中。

3，使用视图查询数据时，数据库系统会从原来的表中取出对应的数据。   

视图的作用
1，使操作简便化；

2，增加数据的安全性；

3，提高表的逻辑独立性；

视图的概念：

视图是一张虚拟的表，是从数据库中一个或多个表中导出来的表；视图是不存在物理数据的；使用视图查询时，数据来源于数据库原表中的数据。具有普通表的结构，但是不实现数据存储。



视图的作用:

1.操作简便化：我们可以建立一些简单的视图，所见即所得。视图不仅可以简化用户对数据的理解，也可以简化他们的操作。那些被经常使用的查询可以被定义为视图，从而使得用户不必为以后的操作每次指定全部的条件。

2.增加数据的安全性：比如写代码时使用视图，不直接操作数据库表。可能原数据库表中的某些字段有很重要的信息，我们不对外公开，使用视图可以屏蔽掉不使用，只能操作可见到的数据，这样数据更加安全。

3.提高表的逻辑独立性：视图可以使应用程序和数据库表在一定程度上独立。如果没有视图，应用一定是建立在表上的。有了视图之后，程序可以建立在视图之上，从而程序与数据库表被视图分割开来。



视图的缺点：

1.性能开销大：

数据库必须把视图查询转化成对基本表的查询，如果这个视图是由一个复杂的多表查询所定义，那么，即使是视图的一个简单查询，数据库也要把它变成一个复杂的结合体，需要花费一定的时间。

2.修改限制：

当用户试图修改视图的某些信息时，数据库必须把它转化为对基本表的某些信息的修改，对于简单的视图来说，这是很方便的，但是，对于比较复杂的试图，可能是不可修改的。



参考表数据：





视图的创建：



这样，我们就创建好了一个视图：

下面我们来使用一下这个视图：



--从视图中检索数据，执行：

SELECT * FROM v1;


-- 定义一个只有书名和价格字段的视图：

create view v2 as select bookName,price from t_book;

--从v2视图中检索数据：

select * from v2;



这样只能检索到相关的列 保证了数据的安全性和独立性



你认为这样很安全吗？字段名还是被开发人员给看到了 我们可以给视图中的列单独取名字：

--创建单表视图（自定义列名）：

create view v3(自定义的名字,p) as select bookName,price from t_book;

-- 执行：

select * from v3;

--结果：





--多表上创建视图：

create view v4 as select t1.bookName,t2.bookTypeName from t_book t1,t_booktype t2 WHERE t1.bookTypeId=t2.id; 

--检索数据：

SELECT * FROM v4;

--结果：





查看视图：

1. DESCRIBE 语句查看视图基本信息

执行语句： DESCRIBE v4;

或者省略写法: DESC v4;

2.SHOW TABLE STATUS 语句查看视图基本信息:

执行语句：SHOW TABLE STATUS LIKE 'v4' 可以看到最后comment是View

可以对比执行：SHOW TABLE STATUS LIKE '表名' 看看 有什么不同





 3.SHOW CREATE VIEW 语句查看视图详细信息

执行语句：SHOW CREATE VIEW v4



4.在 views 表中查看视图详细信息：

系统库中有一张VIEW表：





 修改视图：是指修改数据库中，存在的视图的定义 

                   比如，当基本表中的某些字段发生变化时，可以通过修改使徒的方式，来保持视图与基本表的一致性 

1.用  CREATE  OR  REPLACE   VIEW  语句修改视图

我们把之前建立的V1 视图 改为只有bookName和price 两个字段：

执行语句：CREATE OR REPLACE VIEW v1(bookName,price) AS SELECT bookName,price FROM t_book

用这个命令时视图存在就修改，不存在就创建；

 

2. 用  ALTER  语句修改视图

ALTER VIEW v1 AS SELECT * FROM t_book



更新视图：更新视图是指通过视图来插入（INSERT）、更新（UPDATE）和删除（DELETE）表中的数据。因为视图是一个虚拟的表，其中没有数据。通过视图更新时，都是转换基本表来更新。更新视图时，只能更新权限范围内的数据。

超出了范围，就不能更新。

 

 插入(INSERT)：

INSERT INTO v1 VALUES(NULL,'java good','120','fang',1);

 

 更新(UPDATE)

UPDATE v1 SET bookName='java very good',price=200 WHERE id=5;

 

删除(DELETE)

DELETE FROM v1 WHERE id=5；



删除视图：删除视图是指删除数据库中已存在的视图。删除视图时，只能删除视图的定义，不会删除数据；

删除V4视图：

DROP VIEW IF EXISTS v4;


 

 

 

 

  物化视图是一种特殊的物理表，“物化”(Materialized)视图是相对普通视图而言的。普通视图是虚拟表，应用的局限性大，任何对视图的查询，oracle都实际上转换为视图SQL语句的查询。这样对整体查询性能的提高，并没有实质上的好处。
　　oracle最早在OLAP系统中 引入了物化视图的概念。但后来很多大型OLTP系统中，发现类似统计的查询是无可避免，而这些查询操作如果很频繁，对整体数据库性能是很致命的。于是 Oracle开始不断的改进物化视图，使得其也开始合适OLTP系统。从Oracle 8i到现在，功能已经相对比较完备了。
　　本文是Oracle物化视图系列文章的第一篇，有两个主要目的，来体验一下创建ON DEMAND和ON COMMIT物化视图的方法。ON DEMAND和ON COMMIT物化视图的区别在于其刷新方法的不同，ON DEMAND顾名思义，仅在该物化视图“需要”被刷新了，才进行刷新(REFRESH)，即更新物化视图，以保证和基表数据的一致性;而ON COMMIT是说，一旦基表有了COMMIT，即事务提交，则立刻刷新，立刻更新物化视图，使得数据和基表一致。
　　1、第一个ON DEMAND物化视图
　　1.1、创建ON DEMAND物化视图
　　下面创建一个最简单的物化视图，这个物化视图的定义很类似于普通视图的创建语句，只是多了一个materialized，但就是这个单词，造成了物化视图和普通视图(虚拟表)的天壤之别，也引申出后面很多的事情，呵呵。
　　本例中需要特别注意的是，Oracle给物化视图的重要定义参数的默认值处理，在下面的例子中会有特别说明。因为物化视图的创建本身是很复杂和 需要优化参数设置的，特别是针对大型生产数据库系统而言。但Oracle允许以这种最简单的，类似于普通视图的办法来做，所以不可避免的会涉及到默认值问 题。
　　像我们这样，创建物化视图时未作指定，则Oracle按ON DEMAND模式来创建。
　　从下例中可以看出：
　　1) 物化视图在某种意义上说就是一个物理表(而且不仅仅是一个物理表)，这通过其可以被user_tables查询出来，而得到佐证;
　　2) 物化视图也是一种段(segment)，所以其有自己的物理存储属性;
　　3) 物化视图会占用数据库磁盘空间，这点从user_segment的查询结果，可以得到佐证。
　　●  创建物化视图
　　--获取数据库rdbms版本信息　　
      SQL> select * from v$version; 
　　BANNER 
　　-------------------------------------------------------------------------------- 
　　oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production 
　　PL/SQL Release 11.1.0.6.0 - Production 
　　CORE 11.1.0.6.0 Production 
　　TNS for 32-bit windows: Version 11.1.0.6.0 - Production 
　　NLSRTL Version 11.1.0.6.0 – Production
　--创建物化视图　　
      sql> create materialized view mv_testcf 
　　2 as 
　　3 select * from xiaotg.testcf; 
　　Materialized view created
　　--分析物化视图，以获得统计信息　
      sql> analyze table xiaotg.mv_testcf compute statistics; 
　　table analyzed
　　--查看物化视图的行数，发现和master表(TESTCF)一样　　
      sql> select tl.table_name, tl.num_rows from user_tables tl where tl.table_name in ( 'TESTCF', 'MV_TESTCF' ); 
　　TABLE_NAME NUM_ROWS 
　　------------------------------ ---------- 
　　MV_TESTCF 80000 
　　TESTCF 80000
　　--查看物化视图的存储参数　　
      sql> col segment_name for a24 
　　sql> select sg.segment_name, sg.bytes, sg.blocks from user_segments sg where sg.segment_name = 'MV_TESTCF'; 
　　SEGMENT_NAME BYTES BLOCKS 
　　------------------------ ---------- ---------- 
　　MV_TESTCF 9437184 1152
　　●  查看物化视图关键定义
　　--查看物化视图的定义设置，请关注蓝色字体部分。
　　--这表明，默认情况下，如果没指定刷新方法和刷新模式，则Oracle默认为FORCE和DEMAND。
　　--其他的集中刷新方法和刷新模式以后将分别予以介绍。
　　sql> select mv.* from user_mviews mv where mv.MVIEW_NAME = 'MV_TESTCF';
(为增加查询结果的可读性，下面进行了行列的互转)
      OWNERXIAOTG 
　　MVIEW_NAMEMV_TESTCF 
　　CONTAINER_NAMEMV_TESTCF 
　　QUERY 
　　QUERY_LEN80 
　　UPDATABLEN 
　　UPDATE_LOG 
　　MASTER_ROLLBACK_SEG 
　　MASTER_LINK 
　　REWRITE_ENABLEDN                                          
　　REWRITE_CAPABILITYGENERAL 
　　REFRESH_MODEDEMAND 
　　REFRESH_METHODFORCE 
　　BUILD_MODEIMMEDIATE 
　　FAST_REFRESHABLEDML 
　　LAST_REFRESH_TYPECOMPLETE 
　　LAST_REFRESH_DATE2008-9-9 15:02 
　　STALENESSFRESH 
　　AFTER_FAST_REFRESHFRESH 
　　UNKNOWN_PREBUILTN 
　　UNKNOWN_PLSQL_FUNCN 
　　UNKNOWN_EXTERNAL_TABLEN 
　　UNKNOWN_CONSIDER_FRESHN 
　　UNKNOWN_IMPORTN 
　　UNKNOWN_TRUSTED_FDN 
　　COMPILE_STATEVALID 
　　USE_NO_INDEXN 
　　STALE_SINCE 
　　NUM_PCT_TABLES0 
　　NUM_FRESH_PCT_REGIONS 
　　NUM_STALE_PCT_REGIONS
　　1.2、测试ON DEMAND物化视图的更新特性
　　物化视图最重要的功能和特性之一，就是其数据会随着基表(或称主表，master表，本例中为TESTCF)的变化而变，基表数据增了，物化视图数据会变多;基表数据删了，物化视图数据也会变少。
　　但怎么更新?或者说物化视图的数据怎么随着基表而更新?Oracle提供了两种方式，手工刷新和自动刷新，像我们这种，在物化视图定义时，未作 任何指定，那当然是默认的手工刷新了。也就是说，通过我们手工的执行某个Oracle提供的系统级存储过程或包，来保证物化视图与基表数据一致性。
　　这是最基本的刷新办法了。但所谓的自动刷新，其实也就是Oracle会建立一个job，通过这个job来调用相同的存储过程或包，加以实现，这在本系列文章的第2篇会将以详细阐述。
　　下面将测试INSERT，UPDATE和DELETE的测试方法类似，大家有兴趣的话，可以自己试一试。
　　需要注意的是，下面暂不讨论如何刷新ON DEMAND物化视图，这是下一篇文章的内容。下面仅仅关注ON DEMAND物化视图的特性及其和ON COMMIT物化视图的区别，即前者不刷新(手工或自动)就不更新物化视图，而后者不刷新也会更新物化视图，——只要基表发生了COMMIT。
　　●  在基表插入测试数据
　　基表数据插入后，会发现，物化视图并不会随之更新。
　　--检查基表和物化视图是否有80001这一行记录。
      sql> col id for a10; 
　　sql> col name for a30; 
　　sql> select * from xiaotg.testcf t where t.id = 80001 ; 
　　ID NAME 
　　---------- ------------------------------ 
　　sql> select * from xiaotg.mv_testcf t where t.id = 80001 ; 
　　ID NAME 
　　---------- ------------------------------
　　--插入测试数据80001 
　　--这时发现，基表有数据，但物化视图并没有　
      sql> insert into xiaotg.testcf 
　　2 values ( 80001, 'xiaotg he he'); 
　　1 row inserted 
　　sql> commit; 
　　Commit complete
　　1.2.2 测试物化视图数据是否更新
　　从下面的实验可以看出，物化视图数据不会更新，即使等上1分钟、1小时、或者1天。
　　关于如何使得ON DEMAND物化视图数据被更新，参加本系列的第二篇文章哈：)　　
      sql> select * from xiaotg.testcf t where t.id = 80001 ; 
　　ID NAME 
　　---------- ------------------------------ 
　　80001 xiaotg he he 
　　sql> select * from xiaotg.mv_testcf t where t.id = 80001 ; 
　　ID NAME 
　　---------- ------------------------------ 
　　sql>
　　2、第一个ON COMMIT物化视图
　　最简单的ON COMMIT物化视图的创建，和上面创建ON DEMAND的物化视图区别不大。因为ON DEMAND是默认的，所以ON COMMIT物化视图，需要再增加个参数即可。
　　2.1 创建ON COMMIT物化视图
　　●  创建物化视图
　　需要注意的是，无法在定义时仅指定ON COMMIT，还得附带个参数才行，本例中附带refresh force，关于这个参数的意思，以后将加以阐述。
　　--创建ON COMMIT物化视图
      sql> create materialized view mv_testcf2 
　　2 refresh force on commit 
　　3 as 
　　4 select * from xiaotg.testcf; 
　　Materialized view created 
　　sql>
　　--分析物化视图和基表　　
      sql> analyze table xiaotg.mv_testcf2 compute statistics; 
　　table analyzed 
　　sql> analyze table xiaotg.testcf compute statistics; 
　　table analyzed
　　--查看当前基表和物化视图的行数 　
      SQL> select tl.table_name, tl.num_rows from user_tables tl where tl.table_name in ( 'TESTCF', 'MV_TESTCF2' ); 
　　TABLE_NAME NUM_ROWS 
　　------------------------------ ---------- 
　　MV_TESTCF2 80000 
　　TESTCF 80000
　　●  查看物化视图关键定义
　　可以从DBA_MVIEWS中看出，刷新模式为COMMIT，这也是它和上面ON DEMAND物化视图的唯一区别。 
   　sql> select mv.* from user_mviews mv where mv.MVIEW_NAME = 'MV_TESTCF';
　　(为增加查询结果的可读性，下面进行了行列的互转，且只显示前三个关键列的)　　
      REFRESH_MODECOMMIT 
　　REFRESH_METHODFORCE 
　　BUILD_MODEIMMEDIATE
　　2.2 测试ON COMMIT物化视图的更新特性
　　ON COMMIT物化视图会在基表一旦提交时，就会立刻更新物化视图本身，而且一般仅在物化视图数据也被更新后，基表数据才会事实的提交。
　　这意味着，这种模式可能会导致延迟基表数据的提交。。这点在下面的实验中体现得很清楚。
　　实验中，对基表TESTCF，平常的COMMIT在0.01秒内可以完成，但在有了ON COMMIT视图MV_TESTCF2后，居然要6秒。速度减低了很多倍。ON COMMIT视图对基表的影响可见一斑。
　　●  在基表中插入数据　　

sql> set timing on; 
　　sql> insert into xiaotg.testcf ( id, name ) values ( 80002, ' xiaotg again he he '); 
　　1 row inserted 
　　Executed in 0.015 seconds 
　　sql> commit; 
　　Commit complete 
　　Executed in 6.985 seconds 
　　sql> select * from xiaotg.testcf where id = 80002; 
　　ID NAME 
　　--------------------------------- -------------------------------------------------------------------------------- 
　　80002 xiaotg again he he 
　　Executed in 0 seconds 
　　sql> col id for a10; 
　　sql> col name for a40; 
　　sql> select * from xiaotg.testcf where id = 80002; 
　　ID NAME 
　　---------- ---------------------------------------- 
　　80002 xiaotg again he he 
　　Executed in 0.016 seconds 
　　sql> select * from xiaotg.mv_testcf2 where id = 80002; 
　　ID NAME 
　　---------- ---------------------------------------- 
　　80002 xiaotg again he he 
　　Executed in 0.031 seconds
　　●  测试基表正常情况下的COMMIT速度　　
      sql> drop materialized view mv_testcf2; 
　　Materialized view dropped 
　　Executed in 1.984 seconds 
　　sql> 
　　sql> 
　　sql> insert into xiaotg.testcf ( id, name ) values ( 80003, ' xiaotg again he he 3 '); 
　　1 row inserted 
　　Executed in 0 seconds 
　　sql> commit; 
　　Commit complete 
　　Executed in 0 seconds

物化视图是一种特殊的物理表，“物化”(Materialized)视图是相对普通视图而言的。普通视图是虚拟表，应用的局限性大，任何对视图的查询，Oracle都实际上转换为视图SQL语句的查询。这样对整体查询性能的提高，并没有实质上的好处。
　　Oracle最早在OLAP系统中引入了物化视图的概念。但后来很多大型OLTP系统中，发现类似统计的查询是无可避免，而这些查询操作如果很频繁，对整体数据库性能是很致命的。于是Oracle开始不断的改进物化视图，使得其也开始合适OLTP系统。从Oracle 8i到现在，功能已经相对比较完备了。
　　本文是Oracle物化视图系列文章的第一篇，有两个主要目的，来体验一下创建ON DEMAND和ON COMMIT物化视图的方法。ON DEMAND和ON COMMIT物化视图的区别在于其刷新方法的不同，ON DEMAND顾名思义，仅在该物化视图“需要”被刷新了，才进行刷新(REFRESH)，即更新物化视图，以保证和基表数据的一致性;而ON COMMIT是说，一旦基表有了COMMIT，即事务提交，则立刻刷新，立刻更新物化视图，使得数据和基表一致。
 
http://database.ctocio.com.cn/tips/234/8303734.shtml