Create Views
 
 
在S表中创建以学号、姓名、系为列的新视图（V_A）
 
 – 利用上面建立的视图，把本人的系别信息改为“管理系”
 
 – 利用上面建立的视图，删除你本人的记录
 
      
 
 
 
 
在SC上定义视图V_B，当用UPDATE修改数据时，必须满足视图中SCORE>60的条件，否则不能被更改，并验证
 
 
 
更改成绩时不会有行受到影响
 

 
 
 
创建新视图V_C，按照学号分组显示学生的最高分、最低分和平均成绩
 

 
 
 
创建一个视图V_D，显示‘数据库’考试不及格的学生信息
 

 
 
 
Query by Using Views
 
利用上面建立的各个视图（V_A – V_D）
 
查询学生的学号、姓名、所在系、课程号、课程名、课程学分
 
 
 
查询学生的学号、姓名、选修课程名和考试成绩
 

 
 
 
统计每个学生的选课门数的视图，要求列出学生学号和选课门数
 

 
 
 
统计每个学生的修课总学分的视图，要求列出学生学号和总学分（考试成绩大于等于60才可获得此门课程的学分）
 

 
 
 
Create Views
 
V1：查询学生的学号、姓名、所在系、课程号、课程名、课程学分
 

 
 
 
V2：查询学生的学号、姓名、选修课程名和考试成绩
 

 
 
 
V3：统计每个学生的选课门数的视图，要求列出学生学号和选课门数
 

 
 
 
V4：统计每个学生的修课总学分的视图，要求列出学生学号和总学分（说明：考试成绩大于等于60才可获得此门课程的学分）
 

 
 
 
Query by Using Views
 
利用上面建立的各个视图（V_1 – V_4）
 
查询考试成绩大于等于90分的学生的姓名、课程名和成绩
 

 
 
 
查询选课门数超过3门的学生的学号和选课门数
 

 
 
 
查询计算机系选课门数超过3门的学生的姓名和选课门数
 

 
 
 
查询修课总学分超过80分的学生的学号、姓名、所在系和
 

 
 
查询年龄大于等于20岁的学生中，修课总学分超过10分的学生的姓名、年龄、所在系和修课总学分
 

 
 
 
Create Database – DingBao
 
创建表结构时要求满足：
 
1） 报纸编码表（PAPER）以报纸编号（pno）为主键；
 

 
 
 
2） 顾客编码表（CUSTOMER）以顾客编号（cno）为主键；
 

 
 
 
3）报纸订阅表（CP）以报纸编号（pno）与顾客编号
 
（cno）为主键，订阅份数（num）的默认值为1；
 
 

 
 
3） 添加你自己的信息
 

 
 
      
 
Query by Using Views
 
创建含有顾客编号、顾客名称、报纸编号、报纸名称和订阅份数等信息的视图，视图名C_P_N
 

 
 
 
修改已经创建的视图C_P_N，使其含有报纸单价信息
 

 
 
 
通过视图C_P_N查询“人民日报”被订阅的情况，并实验能否通过视图C_P_N实现对数据的更新操作
 

 
 
 
通过视图更改
 

 
 
 
尝试更新操作
 
 – 修改本人的订阅某报的份数、修改某报纸的名称等
 

 
 
 
删除视图C_P_N
 

 
 
 

 
文章目录
 
物化视图
物化视图与普通视图的区别
创建一个存放person的表
创建一个存放person的address的表
初始化数据
创建物化视图的语句
1.build [immediate|deferred]
2.refresh [fast|complete|force] 视图刷新的方式:
3.MV数据刷新的时间：
4.查询重写（QueryRewrite)
演示 refresh complete on demand
演示 build deferred
演示 refresh complete on commit
演示on commit情况下的物化视图更新出错
   
简单总结什么情况下不适合使用物化视图
如何查看物化视图
如何使用job去刷新物化视图
删除schedule job
演示如何创建一个schedule job来刷新物化视图
   
如何删除物化视图
  
物化视图日志
物化视图的Fast刷新
[67000][439] ORA-00439: feature not enabled: Advanced replication
创建物化视图日志
演示创建物化视图with primary key
including new values
    
演示创建物化视图with rowid
   
实现物化视图的增量刷新
使用物化视图增量刷新的优缺点
oracle通过v$sql视图查询sql的平均执行时间
 

 
以下都是最近我通过网上学习和实践简单总结的一些学习成果，还有很多还是不了解。
 
物化视图
 
物化视图与普通视图的区别
 
物化视图是一种特殊的物理表，“物化”(Materialized)视图是相对普通视图而言的。普通视图是虚拟表，应用的局限性大，任何对视图的查询， Oracle 都实际上转换为视图SQL语句的查询。这样对整体查询性能的提高，并没有实质上的好处。
 
而物化视图是一张实际存在的表，是占有数据库磁盘空间的。
 物化视图并不像普通视图那样，只有在使用的时候才去读取数据，而是预先计算并保存表连接或者聚集等比较耗时操作的结果，这样大大提高了读取的速度，特别适合抽取大数据量表的某些信息。
 
创建一个存放person的表
 
create table test_person(pid int,name varchar2(20));
alter table test_person add constraint  pk_pid primary key(pid);
--删除表
drop table test_person;
 
创建一个存放person的address的表
 
create table test_address(aid int,address varchar2(20),pid int);
alter table test_address add constraint pk_aid primary key(aid);
--删除表
drop table test_address;
 
初始化数据
 
insert into test_person values(1,'kevin');
insert into test_address values(1,'SHA',1);
insert into test_person values(2,'vincent');
insert into test_address values(2,'HKG',2);
COMMIT;
 
创建物化视图的语句
 
create materialized view [view_name] 
build [immediate|deferred]
refresh [fast|complete|force] 
[ 
on [commit|demand] | 
start with (start_time) next (next_time) 
] 
 [enable | disable] query rewrite
as 
{创建物化视图用的查询语句} 
 
1.build [immediate|deferred]
 
创建方式（BuildMethods）：包括BUILD IMMEDIATE和BUILD DEFERRED两种。
 
 
BUILD IMMEDIATE是在创建物化视图的时候就生成数据。
 
 
BUILD DEFERRED则在创建时不生成数据，以后根据需要在生成数据。默认为BUILD IMMEDIATE
 
 
2.refresh [fast|complete|force] 视图刷新的方式:
 
 
fast: 增量刷新.假设前一次刷新的时间为t1,那么使用fast模式刷新物化视图时,只向视图中添加t1到当前时间段内,主表变化过的数据.为了记录这种变化，建立增量刷新物化视图还需要一个物化视图日志表。create materialized view log on （主表名）。
 
 
complete:全部刷新。相当于重新执行一次创建视图的查询语句。
 
 
force: 这是默认的数据刷新方式。当可以使用fast模式时，数据刷新将采用fast方式；否则使用complete方式。
 
 
3.MV数据刷新的时间：
 
 
on demand:在用户需要刷新的时候刷新，这里就要求用户自己动手去刷新数据了（也可以使用job定时刷新）
 
 
on commit:当主表中有数据提交的时候，立即刷新MV中的数据；
 
 
start ……：从指定的时间开始，每隔一段时间（由next指定）就刷新一次；
 
 
4.查询重写（QueryRewrite)
 
包括ENABLE QUERY REWRITE和DISABLE QUERY REWRITE两种。
 
分别指出创建的物化视图是否支持查询重写。查询重写是指当对物化视图的基表进行查询时，Oracle会自动判断能否通过查询物化视图来得到结果，如果可以，则避免了聚集或连接操作，而直接从已经计算好的物化视图中读取数据。默认为DISABLEQUERY REWRITE。
 
感觉很少用，有兴趣的可以研究下：
 https://mp.weixin.qq.com/s/5Lg8cSEb3R5WkQwVF9xfPQ
 
演示 refresh complete on demand
 
create materialized view my_mv_cd
build immediate refresh complete on demand
as
select p.pid as id, p.name, a.address from test_person p,test_address a
where p.pid = a.aid;
 
这里的build immediate表示创建物化视图的同时立即导入数据。
 BUILD DEFERRED则在创建时不生成数据，以后根据需要在生成数据。默认为BUILD IMMEDIATE。
 
 
在demand模式下，修改基表，物化视图是不会跟着改变的，只能手动DBMS_MVIEW.REFRESH等方法来进行刷新，也可以通过JOB定时进行刷新
 
演示 build deferred
 
create materialized view my_mv_cd2
build deferred refresh complete on demand
as
select p.pid as id, p.name, a.address from test_person p,test_address a
where p.pid = a.aid;
 
 
如何手动刷新？
 
BEGIN
DBMS_MVIEW.REFRESH (
list => 'my_mv_cd2',
Method =>'C',
refresh_after_errors => True);
END;
 
 
演示 refresh complete on commit
 
create materialized view my_mv_cc
build immediate refresh complete on commit
as
select p.pid as id, p.name, a.address from test_person p,test_address a
where p.pid = a.aid;
 
insert into test_person values(3,'thomas');
insert into test_address values(3,'ZHA',3);
COMMIT;
 
 
一旦基表有了COMMIT，即事务提交，则立刻刷新，立刻更新物化视图，使得数据和基表一致。缺点就是对基表的DML操作影响很大。
 
演示on commit情况下的物化视图更新出错
 
而且对基表的DML跟对物化视图的刷新应该是在同一个事务下的。所以如果物化视图更新出错，主表也无法提交事务。
 
我们可以做如下的一个实验。。
 
创建两个表，不设置主键。
 
create table test_person2(pid int,name varchar2(20));
create table test_address2(aid int,address varchar2(20),pid int);
 
创建物化视图，刷新时间模式设置为on commit
 
create materialized view my_mv_test
refresh complete on commit
as
select p.pid as id, p.name, a.address from test_person2 p,test_address2 a
where p.pid = a.aid;
 
然后我们给id加一个唯一索引。
 
create unique index u_test_index on my_mv_test(id);
 
现在开始插入数据。。我们插入相同id的数据
 
insert into test_person2 values(1,'kevin');
insert into test_address2 values(1,'SHA',1);
insert into test_person2 values(1,'vincent');
insert into test_address2 values(1,'HKG',1);
COMMIT;
 
 
然后我们可以发现两个基表也没有数据提交，说明是在同一个事务下进行了rollback。
 
所以使用commit需要注意的地方：
 
主表提交时基表也提交，系统开销增大。在繁忙的OLTP系统中会影响一部分性能。如果物化视图更新出错，主表也无法提交事务。
主表和物化视图必须在同一个数据库中
无法在基表上执行分布式事务
不支持含有对象类型或Oracle补充支持类型的物化视图
 
更多的参考：
 http://blog.itpub.net/29047826/viewspace-1575568/
 
简单总结什么情况下不适合使用物化视图
 
1.不适合建立物化视图的情况： 基表有频繁的DML操作 / （on commit刷新时很费时，大大增加DML操作的时间）
 
2.多表连接的物化视图仅适合 refresh complete 定时刷新，且刷新时间不能小于30min，否则弊大于利（complete是删除原有数据重新连接多表数据）
 
如何查看物化视图
 
SELECT * FROM user_mviews;
SELECT * FROM all_mviews;
 
如何使用job去刷新物化视图
 
begin
dbms_scheduler.create_job(
  job_name => 'sam_job', --job名
  job_type => 'STORED_PROCEDURE', --job类型
  job_action => 'pc_sam', --存储过程名
  start_date => sysdate, --开始执行时间
  repeat_interval => 'FREQ=MINUTELY;INTERVAL=5', --下次执行时间，每5分钟执行存储过程pc_sam
  comments => '测试存储过程', --注释
  auto_drop => false, --job禁用后是否自动删除
  enabled => true);
end;
/
 
1、job_name： 任务名称
 
2、job_type：有三种类型，PL/SQL Block、Stored procedure、Executable
 
3、job_action：根据job_type的不同，有不同的含义
 
如果job_type指定的是存储过程，就需要指定存储过程的名字;
如果job_type指定的是PL/SQL块，就需要输入完整的PL/SQL代码;
如果job_type指定的外部程序，就需要输入script的名称或者操作系统的指令名
 
4、start_date：开始时间
 
5、repeat_interval：运行的时间间隔，上面例子是每天23点运行一次
 
6、end_date：到期时间
 
7、enabled：创建后自动激活
 
8、auto_drop：默认true,即当job执行完毕都到期是否直接删除job
 
9、comments：备注
 
关于schedule时间设置可以查看官网:https://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_sched.htm#ARPLS72235
 
关于可以repeat_interval设置可以参考：https://blog.csdn.net/zq9017197/article/details/6985109
 
删除schedule job
 
BEGIN
  DBMS_SCHEDULER.DROP_JOB(
     job_name => 'my_mv_cd_job'
  );
END;
/
 
演示如何创建一个schedule job来刷新物化视图
 
首先我们创建一个存储过程，用来刷新我们的物化视图
 
create or replace procedure my_mv_cd_procedure_job is
begin
 dbms_mview.refresh('my_mv_cd');
end my_mv_cd_procedure_job;
/
 
然后我们可以通过如下的sql来查询我们的存储过程。。
 
SELECT * FROM all_source where type = 'PROCEDURE';

SELECT * FROM user_source where type = 'PROCEDURE';
 
然后我们创建一个schedule job来trigger我们的刚刚定义的存储过程。。
 
BEGIN
DBMS_SCHEDULER.CREATE_JOB (
   job_name           =>  'my_mv_cd_job',
   job_type           =>  'STORED_PROCEDURE', --指定执行的是存储过程
   job_action         =>  'my_mv_cd_procedure_job', --对应的存储过程名称
   repeat_interval    =>  'FREQ=MINUTELY; INTERVAL=1', --1分钟trigger一次
   enabled            =>  true
   );
END;
/
 
然后我们可以通过如下sql查询我们创建的schedule job
 
--查询
select * from ALL_SCHEDULER_JOBS;
select * from USER_SCHEDULER_JOBS;
 
 
我们可以看到执行时间是相隔了1分钟
 
我们可以试着插入数据
 
insert into test_person values(4,'justin');
insert into test_address values(4,'HKG',4);
commit;
 
1分钟之后就会发现物化视图trigger刷新了。
 
 
如何删除物化视图
 
drop materialized view {物化视图名称};
 
物化视图日志
 
物化视图的Fast刷新
 
前面说到物化视图是可以进行Fast刷新，也就是增量刷新，当每次刷新的时候不必对整个物化视图进行刷新，只需要对有改动的record进行刷新。
 那db是如何知道有哪些record有change呢？
 通过对基表建立物化视图日志，就可以监测到基表的变动，每当基表有变动的时候就会往对应的物化视图日志中写入数据。当进行Fast刷新的时候，db就会把物化视图日志中的改动写入到物化视图中，这样就实现了增量的刷新。
 
[67000][439] ORA-00439: feature not enabled: Advanced replication
 
create materialized view log on test_kevin with primary key including new values;
 
当我在本地尝试创建物化视图日志的时候发生了如下错误：
 
[67000][439] ORA-00439: feature not enabled: Advanced replication
 
我们可以通过如下sql查看我们db开启的功能：
 
select * from v$option where parameter = 'Advanced replication';
 
通过查看我们可以知道我们的高级复制功能是没有被开启的。不知道是当时安装有问题还是可能这是一个加钱才会有的功能吧。
 
创建物化视图日志
 
如果我们想要创建fast模式刷新的物化视图就一定要对关联的基表都需要创建物化视图日志。
 
Oracle 的物化视图的快速刷新要求必须建立物化视图日志，通过物化视图日志可以实现增量刷新功能。
 
物化视图日志在建立时有多种选项：可以指定为ROWID、PRIMARY KEY和OBJECTID几种类型，同时还可以指定SEQUENCE或明确指定列名。不过上面这些情况产生的物化视图日志的结构都不相同。
当发生DML 操作时，内部的触发器会把变化记录到物化视图日志里，也就是说物化视图不支持DDL的同步，所以在物化视图的编写过程中不可使用select * from 的形式，因为这样当基表发生变化时，物化视图就会失效。
 
 
 
物化视图日志的名称为MLOG$_后面跟基表的名称，如果表名的长度超过20位，则只取前20位，当截短后出现名称重复时，Oracle会自动在物化视图日志名称后面加上数字作为序号。
 
 
任何物化视图都会包括的4列：
 
SNAPTIME$$：用于表示刷新时间。
DMLTYPE$$：用于表示DML操作类型，I表示INSERT，D表示DELETE，U表示UPDATE。
OLD_NEW$$：用于表示这个值是新值还是旧值。N（EW）表示新值，O（LD）表示旧值，U表示UPDATE操作。
CHANGE_VECTOR$$：表示修改矢量，用来表示被修改的是哪个或哪几个字段。Oracle就是通过CHANGE_VECTOR$$列来记录每条记录发生变化的字段包括哪些。
如果WITH后面跟了ROWID，则物化视图日志中会包含：M_ROW$$：用来存储发生变化的记录的ROWID。
如果WITH后面跟了PRIMARY KEY，则物化视图日志中会包含主键列。
如果WITH后面跟了OBJECT ID，则物化视图日志中会包含：SYS_NC_OID$：用来记录每个变化对象的对象ID。
如果WITH后面跟了SEQUENCE，则物化视图日子中会包含：SEQUENCE$$：给每个操作一个SEQUENCE号，从而保证刷新时按照顺序进行刷新。
如果WITH后面跟了一个或多个COLUMN名称，则物化视图日志中会包含这些列。
 
演示创建物化视图with primary key
 
我们首先创建一张表
 
create table test_person(pid int,name varchar2(20));
alter table test_person add constraint test_pk_pid primary key(pid);
 
然后我们创建物化视图日志，指定primary key
 
create materialized view log on test_person with primary key;
 
然后我们可以向基表test_person加入一条数据。
 
insert into test_person values(1,'kevin');
 
然后在update一条数据
 
update test_person set name='kevin cai' where pid = 1;
 
然后我们通过如下sql可以查看物化视图日志的内容。
 
select * from mlog$_test_person;
 
 
including new values
 
我们创建物化视图日志的时候还可以带上including new values
 
create materialized view log on test_person with primary key including new values;
 
同样我们也是先insert一条数据然后在update同一条数据，然后我们从mlog$_test_person中的内容就可以看得区别。
 
 
NEW VALUES子句允许Oracle数据库将新旧值都保存在物化视图日志中，以便更新DML操作。
 
更多参考：
 
http://www.itpub.net/forum.php?mod=viewthread&tid=2052180&highlight=
 
https://docs.oracle.com/cd/E11882_01/server.112/e41084/statements_6003.htm#i2119924
 
演示创建物化视图with rowid
 
CREATE MATERIALIZED VIEW LOG on test_person with rowid INCLUDING NEW VALUES;
 
 
使用场景，具体不是很了解，可以参考：https://blog.csdn.net/demonson/article/details/81450938
 
实现物化视图的增量刷新
 
我们先创建两张表
 
create table test_person(pid int,name varchar2(20));
alter table test_person add constraint test_pk_pid primary key(pid);
create table test_address(aid int,address varchar2(20),pid int);
alter table test_address add constraint test_pk_aid primary key(aid);
 
然后我们对基表创建物化视图日志
 我们这里使用的是with rowid来创建物化视图日志
 
CREATE MATERIALIZED VIEW LOG on test_person with rowid INCLUDING NEW VALUES;
CREATE MATERIALIZED VIEW LOG on test_address with rowid INCLUDING NEW VALUES;
 
然后我们就可以创建fast刷新模式的物化视图。。
 
create materialized view my_test_mv refresh fast WITH ROWID as
  select p.pid as p_id, p.name, a.address, p.ROWID as p_ROWID,a.ROWID as a_ROWID
      from test_person p, test_address a where p.pid = a.pid;
 
注意：
 with rowid的时候记得创建物化视图的时候需要带上select条件ROWID，不然会宝如下错误：
 ORA-12052: cannot fast refresh materialized view
 
而且建MV时一定要加上with rowid，因为没有聚合函数的MV默认是with primary key
 
更多参考：https://blog.csdn.net/minwang593/article/details/19205553
 
这时候我们可以尝试往基表插入数据
 
insert into test_person values(1,'kevin');
insert into test_address values(1,'SHA',1);
insert into test_person values(2,'vincent');
insert into test_address values(2,'HKG',2);
 
我们可以看到物化视图日志中都有数据
 
select * from mlog$_test_person;
select * from mlog$_test_address;
 
 
但是物化视图中还没有数据。我们可以通过手动方式刷新物化视图中的数据
 
BEGIN
DBMS_MVIEW.REFRESH (
list => 'my_test_mv',
Method =>'C',
refresh_after_errors => True);
END;
 
之后就可以发现物化视图中有数据了。
 
 
而且一旦物化视图刷新，关联基表的物化视图日志也会被清空。。
 
我们可以通过如下sql删除物化视图和物化视图日志：
 
--删除物化视图
drop materialized view my_test_mv;
--删除物化视图日志
drop materialized view log on test_person;
drop materialized view log on test_address;
 
然后我们可以试试以外连接的语法来创建物化视图
 
create materialized view my_test_mv refresh fast WITH ROWID as
  select p.pid as p_id, p.name, a.address, p.ROWID as p_ROWID,a.ROWID as a_ROWID
      from test_person p left join test_address a on p.pid = a.pid;
 
然后我们发现我们创建物化视图的时候报错如下：
 
[72000][12015] ORA-12015: cannot create a fast refresh materialized view from a complex query
 
这是因为物化视图快速刷新不支持标准外联接写法，必须要改写sql
 
select * from a,b where a.id(+)=b.id;--b为主表,a为补充
select * from a,b where a.id=b.id(+);--a为主表,b为补充
 
所以我们将我们的sql改写为
 
create materialized view my_test_mv refresh fast WITH ROWID as
  select p.pid as p_id, p.name, a.address, p.ROWID as p_ROWID,a.ROWID as a_ROWID
      from test_person p, test_address a where p.pid = a.pid(+);
 
更多参考：https://www.cnblogs.com/tracy/archive/2011/09/01/2162080.html
 
总结一下创建fast模式物化视图条件：
 
多表连接的物化视图想要使用fast刷新时,
 
首先,select 语句中包含到的每一个表都需要创建视图日志;
 
其次,视图日志中需要指定在select语句和where条件中用到的该表的字段;
 
第三,在select中必须包含所涉及到的所有表的rowid,
 
第四,外连接不能使用标志sql语法,应使用(+)这种oracle固有语法.
 
当然还有很多其他的限制条件，可以参考：https://blog.csdn.net/aiyocxuan/article/details/78732567
 
使用物化视图增量刷新的优缺点
 
我个人觉得使用增量模式刷新物化视图的优点就是不需要对整个物化视图进行刷新，当物化视图的数据特别大的时候可以减少刷新的时间，其他的优点没有暂时还没感受到。
 
缺点：
 
1.使用增量模式进行刷新需要对所有关联的基表都建立物化视图日志，首先在数据库中就要占据一部分的空间，其次对基表创建物化视图日志对基表的DML还是有影响的，可以参考下面:
 Oracle 物化视图快速刷新对性能的影响
 http://blog.itpub.net/28539951/viewspace-2127870/
 
2.然后对基表的DML和对物化视图日志的更新应该是在同一个事务里的，因为rollback的时候是会一起rollback的，所以如果物化视图日志一旦失败可能导致基表的DML操作失败，对业务上可能会影响。
 
3.物化视图日志的维护成本比较高
 物化视图日志经常会由于物化视图长时间没有刷新，或者基表的一次批量数据更改而变得很大，这会影响物化视图的刷新性能，因此对于这种情况需要对物化视图日志进行处理，降低物化视图日志表的高水位线。
 
Oracle的物化视图的快速刷新功能，主要是靠物化视图日志来实现的。
 物化视图日志会记录下基表所有的增、删、改操作，而物化视图执行完快速刷新操作后，会从物化视图日志中将本物化视图刷新过且其他物化视图所不需要刷新的记录删除掉。如果其中一个物化视图一直不刷新，那么物化视图日志就会变得越来越大。
 还有一种情况，比如表中插入了大量的数据，或者删除了大量的数据，或者将表中的某一列统一更新为一个值，这种操作都会在物化视图日志中产生大量的记录。
 而物化视图日志的增大必然影响物化视图的刷新速度。一方面，物化视图在刷新的时候要扫描物化视图日志，另一方面，物化视图在刷新结束后，也要清除物化视图日志中的记录，仍然要扫描物化视图日志，因此物化视图日志的大小直接会影响物化视图快速刷新的速度。更重要的是，物化视图日志的高水位一旦增长到一个很高的位置，即使以后物化视图日志中记录很少，甚至没有记录存在，物化视图在刷新的时候仍然需要较长的时间。
 
oracle通过v$sql视图查询sql的平均执行时间
 
SELECT SQL_TEXT,EXECUTIONS "总执行次数",ELAPSED_TIME/1000 "总耗时(秒)", ELAPSED_TIME/nvl(EXECUTIONS,1)/1000 "平均耗时（秒）",
       PARSE_CALLS "硬解析次数",DISK_READS "物理读次数",BUFFER_GETS "读缓存区次数"
FROM v$SQL WHERE SQL_TEXT LIKE '%select * from t1%';
 
更多参考：https://blog.csdn.net/yh_zeng2/article/details/78946807

1、视图概述
 
视图是由数据库中的一个表或多个表导出的虚拟表，是一种虚拟存在的表，方便用户对数据的操作。
 
1.1 视图的概念
 
视图是一个虚拟表，是从数据库中一个或多个表中导出来的表，其内容由查询定义。同真实表一样，视图包含一系列带有名称的列和行数据。但是，数据库中只存放了视图的定义，而并没有存放视图中的数据。这些数据存放在原来的表中。使用视图查询数据时，数据库系统会从原来的表中取出对应的数据。因此，视图中的数据是依赖于原来的表中的数据的。一旦表中的数据发生改变，显示在视图中的数据也会发生改变。
 
视图是存储在数据库中的查询的SQL语句，它主要出于两种原因：安全原因，视图可以隐藏一些数据，例如，员工信息表，可以用视图只显示姓名、工龄、地址，而不显示社会保险号和工资数等；另一个原因是可使复杂的查询易于理解和使用。
 
1.2 视图的作用
 
对其中所引用的基础表来说，视图的作用类似于筛选。定义视图的筛选可以来自当前或其他数据库的一个或多个表，或者其他视图。通过视图进行查询没有任何限制，通过它们进行数据修改时的限制也很少。视图的作用归纳为如下几点。
 
1、简单性
 
看到的就是需要的。视图不仅可以简化用户对数据的理解，也可以简化他们的操作。那些被经常使用的查询可以被定义为视图，从而使得用户不必为以后的操作每次指定全部的条件。
 
2、安全性
 
视图的安全性可以防止未授权用户查看特定的行或列，使有权限用户只能看到表中特定行的方法，如下：
 
（1）在表中增加一个标志用户名的列。
 
（2）建立视图，使用户只能看到标有自己用户名的行。
 
（3）把视图授权给其他用户。
 
3、逻辑数据独立性
 
视图可以使应用程序和数据库表在一定程度上独立。如果没有视图，程序一定是建立在表上的。有了视图之后，程序可以建立在视图之上，从而程序与数据库表被视图分割开来。视图可以在以下几个方面使程序与数据独立。
 
（1）如果应用建立在数据库表上，当数据库表发生变化时，可以在表上建立视图，通过视图屏蔽表的变化，从而使应用程序可以不动。
 
（2）如果应用建立在数据库表上，当应用发生变化时，可以在表上建立视图，通过视图屏蔽应用的变化，从而使数据库表不动。
 
（3）如果应用建立在视图上，当数据库表发生变化时，可以在表上修改视图，通过视图屏蔽表的变化，从而使应用程序可以不动。
 
（4）如果应用建立在视图上，当应用发生变化时，可以在表上修改视图，通过视图屏蔽应用的变化，从而使数据库可以不动。
 
 
 
2、创建视图
 
创建视图是指在已经存在的数据库表上建立视图。视图可以建立在一张表中，也可以建立在多张表中。
 
2.1 查看创建视图的权限
 
创建视图需要具有CREATE VIEW的权限。同时应该具有查询涉及的列的SELECT权限。可以使用SELECT语句来查询这些权限信息。查询语法如下：
 
SELECT Select_priv,Create_view_priv FROM mysql.user WHERE user='用户名';
 
参数说明：
 
（1）Select_priv：属性表示用户是否具有SELECT权限，Y表示拥有SELECT权限，N表示没有。
 
（2）Create_view_priv：属性表示用户是否具有CREATE VIEW权限；
 
（3）mysql.user：表示MySQL数据库下面的user表。
 
（4）用户名：参数表示要查询是否拥有权限的用户，该参数需要用单引号引起来。
 
示例：查询MySQL中root用户是否具有创建视图的权限。
 
SELECT * FROM mysql.user WHERE user='root';
 
2.2 创建视图
 
MySQL中，创建视图是通过CREATE VIEW语句实现的。其语法如下：
 
CREATE [OR REPLACE] [ALGORITHM={UNDEFINED|MERGE|TEMPTABLE}]
VIEW 视图名[(属性清单)]
AS SELECT语句
[WITH [CASCADED|LOCAL] CHECK OPTION];
 
参数说明：
 
（1）ALGORITHM：可选项，表示视图选择的算法。
 
（2）视图名：表示要创建的视图名称。
 
（3）属性清单：可选项，指定视图中各个属性的名词，默认情况下与SELECT语句中的查询的属性相同。
 
（4）SELECT语句：表示一个完整的查询语句，将查询记录导入视图中。
 
（5）WITH CHECK OPTION：可选项，表示更新视图时要保证在该视图的权限范围之内。
 
示例：创建视图。
 
CREATE OR REPLACE VIEW view_user
AS
	SELECT id,name FROM tb_user;
 
示例：创建视图同时，指定属性清单。
 
CREATE OR REPLACE VIEW view_user (a_id,a_name)
AS
	SELECT id,name FROM tb_user;
 
创建视图时需要注意以下几点：
 
（1）运行创建视图的语句需要用户具有创建视图（create view）的权限，若加了[or replace]时，还需要用户具有删除视图（drop view）的权限；
 
（2）select语句不能包含from子句中的子查询；
 
（3）select语句不能引用系统或用户变量；
 
（4）select语句不能引用预处理语句参数；
 
（5）在存储子程序内，定义不能引用子程序参数或局部变量；
 
（6）在定义中引用的表或视图必须存在。但是，创建了视图后，能够舍弃定义引用的表或视图。要想检查视图定义是否存在这类问题，可使用check table语句；
 
（7）在定义中不能引用temporary表，不能创建temporary视图；
 
（8）在视图定义中命名的表必须已存在；
 
（9）不能将触发程序与视图关联在一起；
 
（10）在视图定义中允许使用order by，但是，如果从特定视图进行了选择，而该视图使用了具有自己order by的语句，它将被忽略。
 
 
 
3、修改视图
 
修改视图是指修改数据库中已存在的表的定义。当基本表的某些字段发生改变时，可以通过修改视图来保持视图和基本表之间一致。MySQL中通过CREATE OR REPLACE VIEW语句和ALTER VIEW语句来修改视图。
 
示例：修改视图
 
ALTER VIEW view_user
AS
	SELECT id,name FROM tb_user where id  in (select id from tb_user);
 
说明：ALTER VIEW语句改变了视图的定义，该语句与CREATE OR REPLACE VIEW语句有着同样的限制，如果删除并重新创建一个视图，就必须重新为它分配权限。
 
 
 
4、删除视图
 
删除视图是指删除数据库中已存在的视图。删除视图时，只能删除视图的定义，不会删除数据。MySQL中，使用DROP VIEW语句来删除视图。但是，用户必须拥有DROP权限。
 
示例：删除视图。
 
DROP VIEW IF EXISTS view_user;
 
 
 
5、MySQL视图中使用IF和CASE语句
 
在创建视图时，经常需要使用到MySQL的流程控制语句，如：IF语句和CASE语句。
 
示例：创建MySQL视图中使用IF和CASE语句。
 
（1）创建员工信息表。
 
-- 判断数据表是否存在，存在则删除
DROP TABLE IF EXISTS tb_staff;
 
-- 创建数据表
CREATE TABLE IF NOT EXISTS tb_staff
( 
	id INT AUTO_INCREMENT PRIMARY KEY COMMENT '编号',
	NAME VARCHAR(50) NOT NULL COMMENT '姓名',
	sex INT COMMENT '性别（1：男；2：女；）',
	dept_code VARCHAR(10) COMMENT '部门编号',
	is_post BIT COMMENT '是否在职（0：否；1：是）'
) COMMENT = '员工信息表';
 
（2）新增员工数据。
 
-- 新增数据
INSERT INTO tb_staff(NAME,sex,dept_code,is_post) VALUES('pan_junbiao的博客_01',1,'1001',1);
INSERT INTO tb_staff(NAME,sex,dept_code,is_post) VALUES('pan_junbiao的博客_02',2,'1002',1);
INSERT INTO tb_staff(NAME,sex,dept_code,is_post) VALUES('pan_junbiao的博客_03',1,'1003',0);
INSERT INTO tb_staff(NAME,sex,dept_code,is_post) VALUES('pan_junbiao的博客_04',1,'1001',1);
INSERT INTO tb_staff(NAME,sex,dept_code,is_post) VALUES('pan_junbiao的博客_05',2,'1008',1);
INSERT INTO tb_staff(NAME,sex,dept_code,is_post) VALUES('pan_junbiao的博客_06',1,'1001',0);
INSERT INTO tb_staff(NAME,sex,dept_code,is_post) VALUES('pan_junbiao的博客_07',2,'1002',1);
INSERT INTO tb_staff(NAME,sex,dept_code,is_post) VALUES('pan_junbiao的博客_08',1,'1003',0);
INSERT INTO tb_staff(NAME,sex,dept_code,is_post) VALUES('pan_junbiao的博客_09',1,'1001',1);
INSERT INTO tb_staff(NAME,sex,dept_code,is_post) VALUES('pan_junbiao的博客_10',2,'1008',0);
 
查询员工信息表结果：
 
 
（3）创建员工视图，在视图中使用IF和CASE语句。
 
-- 创建视图
CREATE OR REPLACE VIEW view_staff
AS
	SELECT id 
	,NAME
	,IF(sex=1,'男','女') AS sex_name
	,CASE dept_code
		WHEN '1001' THEN '研发部'
		WHEN '1002' THEN '人事部'
		WHEN '1003' THEN '财务部'
		ELSE '其他'
	END AS dept_name
	,IF(is_post,'在职','离职') AS is_post_name
	FROM tb_staff
;
 
查询员工视图结果：
 
 
 

RUP概述
 

 RUP（Rational Unified Process），统一软件开发过程，统一软件过程是一个面向对象且基于网络的程序开发方法论。
 
在RUP中采用“4+1”视图模型来描述软件系统的体系结构。“4+1”视图包括逻辑视图、实现视图、进程视图、部署视图和用例视图。
 
最终用户关心的是系统的功能，因此会侧重于逻辑视图；
 
程序员关心的是系统的配置、装配等问题，因此会侧重于实现(开发)视图；
 
系统集成人员关心的是系统的性能、可伸缩性、吞吐率等问题，因此会侧重于进程(处理)视图；
 
系统工程师关心的是系统的发布、安装、拓扑结构等问题，因此会侧重于部署(物理)视图。
 
分析人员和测试人员关心的是系统的行为，因此会侧重于用例(场景)视图；

 原文链接：https://blog.csdn.net/turbock/article/details/102930810
 
 
 
（2）4+1视图介绍：
 
 
（3）UML 4+1视图：
 
 
（https://blog.csdn.net/tgbyn/article/details/53573584?ops_request_misc={%22request_id%22:%22158314833519725222420112%22,%22scm%22:%2220140713.130056874..%22}）
 
 
 
运用RUP 4+1视图方法进行软件架构设计
 
 
 
下文摘自：http://www.uml.org.cn/zjjs/201412262.asp
 
 
比如设计一座跨江大桥：
 
我们会考虑"连接南北的公路交通"这个"功能需求"，从而初步设计出理想化的桥墩支撑的公路桥方案；
 
然后还要考虑造桥要面临的"约束条件"，这个约束条件可能是"不能影响万吨轮从桥下通过"，于是细化设计方案，规定桥墩的高度和桥墩之间的间距；
 
另外还要顾及"大桥的使用期质量属性"，比如为了"能在湍急的江流中保持稳固"，可以把大桥桥墩深深地建在岩石层之上，和大地浑然一体；其实，"建造期间的质量属性"也很值得考虑，比如在大桥的设计过程中考虑"施工方便性"的一些措施。
 
和工程领域的功能需求、约束条件、使用期质量属性、建造期间的质量属性等类似，软件系统的需求种类也相当复杂，具体分类如图1所示。
 
 
图1 软件需求分类的复杂性
 
超市系统案例：理解需求种类的复杂性
 
例子是最好的老师。为了更好地理解软件需求种类的复杂性，我们来分析一个实际的例子。在表1中，我们列举了一个典型的超市系统的需求子集，从这个例子中可以清晰地看到需求可以分为两大类：功能需求和非功能需求。
 
 
表1 超市系统案例：理解需求种类的复杂性
 
 
 
简单而言，功能需求就是"软件有什么用，软件需要做什么"。同时，注意把握功能需求的层次性是软件需求的最佳实践。以该超市系统为例：
 超市老板希望通过软件来"提高收银效率"。
 
那么，你可能需要为收银员提供一系列功能来促成这个目的，比如供收银员使用的"任意商品项可单独取消"功能有利于提供收银效率（笔者曾在超市有过被迫整单取消然后一车商品重新扫描收费的痛苦经历）。
 
而具体到这个超市系统，系统分析员可能会决定要提供的具体功能为：通过收银终端的按键组合，可以使收银过程从"逐项录入状态"进入"选择取消状态"，从而取消某项商品。
 
从上面的例子中我们还惊讶地发现，非功能需求--人们最经常忽视的一大类需求--包括的内容非常宽、并且极其重要。非功能需求又可以分为如下三类：
 
约束。要开发出用户满意的软件并不是件容易的事，而全面理解要设计的软件系统所面临的约束可以使你向成功迈进一步。约束性需求既包括企业级的商业考虑（例如"项目预算有限"），也包括最终用户级的实际情况（例如"用户的平均电脑操作水平偏低"）；既可能包括具体技术的明确要求（例如"要求能在Linux上运行"），又可能需要考虑开发团队的真实状况（例如"开发人员分散在不同地点"）。这些约束性需求当然对架构设计影响很大，比如受到"项目预算有限"的限制，架构师就不应选择昂贵的技术或中间件等，而考虑到开发人员分散在不同地点"，就更应注重软件模块职责划分的合理性、松耦合性等等。
 
运行期质量属性。这类需求主要指软件系统在运行期间表现出的质量水平。运行期质量属性非常关键，因为它们直接影响着客户对软件系统的满意度，大多数客户也不会接受运行期质量属性拙劣的软件系统。常见的运行期质量属性包括软件系统的易用性、性能、可伸缩性、持续可用性、鲁棒性、安全性等。在我们的超市系统的案例中，用户对高性能提出了具体要求（真正的性能需求应该量化，我们的表1没体现），他们不能容忍金额合计超过2秒的延时。
 
开发期质量属性。这类非功能需求中的某些项人们倒是念念不忘，可惜很多人并没有意识到"开发期质量属性"和"运行期质量属性"对架构设计的影响到底有何不同。开发期质量属性是开发人员最为关心的，要达到怎样的目标应根据项目的具体情况而定，而过度设计（overengineering）会花费额外的代价。
 
什么是软件架构视图
 
那么，什么是软件架构视图呢？Philippe Kruchten在其著作《Rational统一过程引论》中写道：
 
一个架构视图是对于从某一视角或某一点上看到的系统所做的简化描述，描述中涵盖了系统的某一特定方面，而省略了于此方面无关的实体。
 也就是说，架构要涵盖的内容和决策太多了，超过了人脑"一蹴而就"的能力范围，因此采用"分而治之"的办法从不同视角分别设计；同时，也为软件架构的理解、交流和归档提供了方便。
 
值得特别说明的，大多数书籍中都强调多视图方法是软件架构归档的方法，其实不然。多视图方法不仅仅是架构归档技术，更是指导我们进行架构设计的思维方法。
 
Philippe Kruchten提出的4+1视图方法
 
1995年，Philippe Kruchten在《IEEE Software》上发表了题为《The 4+1 View Model of Architecture》的论文，引起了业界的极大关注，并最终被RUP采纳。如图2所示。
 
 
图2 Philippe Kruchten提出的4+1视图方法
 
该方法的不同架构视图承载不同的架构设计决策，支持不同的目标和用途：
 
逻辑视图：当采用面向对象的设计方法时，逻辑视图即对象模型。
 
开发视图：描述软件在开发环境下的静态组织。
 
处理视图：描述系统的并发和同步方面的设计。
 
物理视图：描述软件如何映射到硬件，反映系统在分布方面的设计。
 
 
 
运用4+1视图方法：针对不同需求进行架构设计
 
如前文所述，要开发出用户满意的软件并不是件容易的事，软件架构师必须全面把握各种各样的需求、权衡需求之间有可能的矛盾之处，分门别类地将不同需求一一满足。
 
 
 
Philippe Kruchten提出的4+1视图方法为软件架构师"一一征服需求"提供了良好基础，如图3所示。
 
 
图3 运用4+1视图方法针对不同需求进行架构设计
 
 
 
逻辑视图。逻辑视图关注功能，不仅包括用户可见的功能，还包括为实现用户功能而必须提供的"辅助功能模块"；它们可能是逻辑层、功能模块等。
 
开发视图。开发视图关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件。开发视图和逻辑视图之间可能存在一定的映射关系：比如逻辑层一般会映射到多个程序包等。
 
处理视图。处理视图关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。处理视图和开发视图的关系：开发视图一般偏重程序包在编译时期的静态依赖关系，而这些程序运行起来之后会表现为对象、线程、进程，处理视图比较关注的正是这些运行时单元的交互问题。
物理视图。物理视图关注"目标程序及其依赖的运行库和系统软件"最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。物理视图和处理视图的关系：处理视图特别关注目标程序的动态执行情况，而物理视图重视目标程序的静态位置问题；物理视图是综合考虑软件系统和整个IT系统相互影响的架构视图。
 
 
 
设备调试系统案例概述
 
本文的以下部分，将研究一个案例：某型号设备调试系统。
 
设备调试员通过使用该系统，可以察看设备状态（设备的状态信息由专用的数据采集器实时采集）、发送调试命令。该系统的用例图如图4所示。
 
 
图4 设备调试系统的用例图
 
经过研制方和委托方的紧密配合，最终确定的需求可以总括地用表2来表示。
 
 
表2 设备调试系统的需求
 
下面运用RUP推荐的4+1视图方法，从不同视图进行架构设计，来分门别类地将不同需求一一满足。
 
 
 
逻辑视图：设计满足功能需求的架构
 
 
 
首先根据功能需求进行初步设计，进行大粒度的职责划分。如图5所示。
 
应用层负责设备状态的显示，并提供模拟控制台供用户发送调试命令。
 
应用层使用通讯层和嵌入层进行交互，但应用层不知道通讯的细节。
 
通讯层负责在RS232协议之上实现一套专用的"应用协议"。
 
当应用层发送来包含调试指令的协议包，由通讯层负责按RS232协议将之传递给嵌入层。
 
当嵌入层发送来原始数据，由通讯层将之解释成应用协议包发送给应用层。
 
嵌入层负责对调试设备的具体控制，以及高频度地从数据采集器读取设备状态数据。
 
设备控制指令的物理规格被封装在嵌入层内部，读取数采器的具体细节也被封装在嵌入层内部。
 
 
 
 
图5 设备调试系统架构的逻辑视图
 
 
 
开发视图：设计满足开发期质量属性的架构
 
 
 
软件架构的开发视图应当为开发人员提供切实的指导。任何影响全局的设计决策都应由架构设计来完成，这些决策如果"漏"到了后边，最终到了大规模并行开发阶段才发现，可能造成"程序员碰头儿临时决定"的情况大量出现，软件质量必然将下降甚至导致项目失败。
 
其中，采用哪些现成框架、哪些第三方SDK、乃至哪些中间件平台，都应该考虑是否由软件架构的开发视图确定下来。图6展示了设备调试系统的（一部分）软件架构开发视图：应用层将基于MFC设计实现，而通讯层采用了某串口通讯的第三方SDK。
 
 
图6 设备调试系统架构的开发视图
 
在说说约束性需求。约束应该是每个架构视图都应该关注和遵守的一些设计限制。例如，考虑到"一部分开发人员没有嵌入式开发经验"这条约束情况，架构师有必要明确说明系统的目标程序是如何编译而来的：图7展示了整个系统的桌面部分的目标程序pc-moduel.exe、以及嵌入式模块rom-module.hex是如何编译而来的。这个全局性的描述无疑对没有经验的开发人员提供了实感，利于更全面地理解系统的软件架构。
 
 
图7 设备调试系统架构的开发视图
 
 
 
处理视图：设计满足运行期质量属性的架构
 
 
 
性能是软件系统运行期间所表现出的一种质量水平，一般用系统响应时间和系统吞吐量来衡量。为了达到高性能的要求，软件架构师应当针对软件的运行时情况进行分析与设计，这就是我们所谓的软件架构的处理视图的目标。处理视图关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。图8展示了设备调试系统架构的处理视图。
 
可以看出，架构师为了满足高性能需求，采用了多线程的设计：
 
应用层中的线程代表主程序的运行，它直接利用了MFC的主窗口线程。无论是用户交互，还是串口的数据到达，均采取异步事件的方式处理，杜绝了任何"忙等待"无谓的耗时，也缩短了系统响应时间。
 
通讯层有独立的线程控制着"上上下下"的数据，并设置了数据缓冲区，使数据的接收和数据的处理相对独立，从而数据接收不会因暂时的处理忙碌而停滞，增加了系统吞吐量。
 
嵌入层的设计中，分别通过时钟中断和RS232口中断来激发相应的处理逻辑，达到轮询和收发数据的目的。
 
 
图8 设备调试系统架构的处理视图
 
 
 
物理视图：和部署相关的架构决策
 
 
 
软件最终要驻留、安装或部署到硬件才能运行，而软件架构的物理视图关注"目标程序及其依赖的运行库和系统软件"最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。图9所示的物理架构视图表达了设备调试系统软件和硬件的映射关系。可以看出，嵌入部分驻留在调试机中（调试机是专用单板机），而PC机上是常见的桌面可执行程序的形式。
 
 
图9 设备调试系统架构的物理视图
 
我们还可能根据具体情况的需要，通过物理架构视图更明确地表达具体目标模块及其通讯结构，如图10所示。
 
 
图10 设备调试系统架构的物理视图
 
小结与说明
 
所谓本立道生。深入理解软件需求分类的复杂性，明确区分功能需求、约束、运行期质量属性、开发期质量属性等不同种类的需求就是"本"，因为各类需求对架构设计的影响截然不同。本文通过具体案例的分析，展示了如何通过RUP的4+1视图方法，针对不同需求进行架构设计，从而确保重要的需求一一被满足。
 
本文重点在于方法的解说，因此省略了对架构设计中不少具体问题的说明，同时本文提供的说明架构设计方案的模型也经过了简化。请读者注意。