1.什么是视图
视图是基于一个表或多个表或视图的逻辑表，本身不包含数据，通过它可以对表里面的数据进行查询和修改。视图基于的表称为基表。视图是存储在数据字典里的一条select语句。 通过创建视图可以提取数据的逻辑上的集合或组合，不会存储数据。
      视图包含简单视图和复杂视图，两者区别如下： 
1.简单视图只从单表里获取数据，复杂视图从多表获取数据； 
2.简单视图不包含函数和数据组，复杂视图包含； 
3.简单视图可以实现DML操作，复杂视图不可以
 
2.视图的优点
1）对数据库的访问，因为视图可以有选择性的选取数据库里的一部分。 
2）用户通过简单的查询可以从复杂查询中得到结果。 
3）维护数据的独立性，试图可从多个表检索数据。 
4）对于相同的数据可产生不同的视图
3.创建视图
CREATE [ORREPLACE] [FORCE|NOFORCE] VIEW view_name  
 
[(列名1,列名2…)]  
 
AS 
视图查询语句  
 
[WITHCHECK OPTION [CONSTRAINT constraint]]  
[WITH READONLY] 
 
FORCE  ：不管基表是否存在ORACLE都会自动创建该视图；
NOFORCE   ：只有基表都存在ORACLE才会创建该视图：
列名1,列名2 ：视图产生的列名； 
WITHCHECK  OPTION ：插入或修改的数据行必须满足视图定义的约束，指定对视图执行的dml操作必须满足“视图子查询”的条件，即可对通过视图进行的增删改操作进行"检查",要求增删改操作的数据, 必须是select查询所能查询到的数据,否则不允许操作并返回错误提示. 默认情况下, 在增删改之前"并不会检查"这些行是否能被select查询检索到；
WITH READONLY ：创建的视图只能用于查询数据, 而不能用于更改数据。
 
视图的定义原则： 
1.视图的查询可以使用复杂的SELECT语法，包括连接/分组查询和子查询； 
2.在没有WITH CHECK OPTION和 READ ONLY 的情况下，查询中不能使用 ORDER BY 子句； 
3.如果没有为CHECK OPTION约束命名，系统会自动为之命名，形式为SYS_Cn;
 
4.视图操作
查看视图数据：select * from view_name
删除视图：drop view view_name 
查询视图：SELECT view_name,text from user_views;
 
5.物化视图
物化视图，存储实际数据， 因此会占用一定的数据库空间，物化视图中 的数据是可以重用的， 因此经常应用与 读取频繁的场合。比如统计一个拥有 百万级记录的数据表的 和  以及 均值 题， 将耗费大量的数据库资源和时间 ，可以通过物化视图对表进行一次统计， 并将统计结果存储在物化视图中，以后的每次查询直接查询该视图即可。
6.创建物化视图
CREATE MATERIALIZED VIEW VIEW_NAME   
BUILD [IMMEDIATE| DEFERRED]  
REFRESH [FAST| COMPLETE |FORCE| NEVER]   
ON [COMMIT |DEMAND]  
[start with sysdate next sysdate+1;]
[for update]
AS 
查询语句 ; 
BUILD IMMEDIATE：用于立即加载 化视图的数据
BUILD DEFERRED：表示延迟载入数据
REFRESH FAST:增量刷新，只刷新自上次刷新以后进行的修改。采用这种方式刷新时，需要创建物化视图日志，增量刷新有一些约束条件，需要满足；
REFRESH COMPLETE：全量刷新
REFRESH FORCE：选择FORCE方式，则Oracle在刷新时会去判断是否可以进行快速刷新，如果可以则采用FAST方式，否则采用COMPLETE的方式
REFRESH NEVER：指物化视图不进行任何刷新
ON COMMIT：要求 Oracle实现自动更新功能， 即基础表的数据更新被提交后， 应该自动更新物化视图的数据；
ON DEMAND仅在该物化视图“需要”被刷新了，才进行刷新(REFRESH)，即更新物化视图
start with…指定视图刷新时间,配置该参数后，会自动创建job
for update:设置该选项，物化视图可以进行增删操作；
7.物化视图操作
1）物化视图刷新：
手工刷新：DBMS_MVIEW.REFRESH(视图名称,'f');
自动刷新：物化视图可以采用job进行定时刷新
2）删除物化视图：
DROP MATERIALIZED VIEW
3）创建物化视图日志：
create materialized view log on test1 [withprimary key|with rowid]
4)删除物化视图日志
drop materialized view log on test1
5）物化视图可以创建索引；
6）查看物化视图日志select * from MLOG$_ test1

  
视图是指计算机数据库中的视图，是一个虚拟表，其内容由查询定义。同真实的表一样，视图包含一系列带有名称的列和行数据。但是，视图并不在数据库中以存储的数据值集形式存在。行和列数据来自由定义视图的查询所引用的表，并且在引用视图时动态生成。——百度百科


关系型数据库中的数据是由一张一张的二维关系表所组成，简单的单表查询只需要遍历一个表，而复杂的多表查询需要将多个表连接起来进行查询任务。对于复杂的查询事件，每次查询都需要编写MySQL代码效率低下。为了解决这个问题，数据库提供了视图（view）功能。



0 视图相关的MySQL指令

操作指令
  
代码
创建视图
  
CREATE VIEW 视图名(列1，列2...) AS SELECT (列1，列2...) FROM ...;
使用视图
  
当成表使用就好
修改视图
  
CREATE OR REPLACE VIEW 视图名 AS SELECT [...] FROM [...];
查看数据库已有视图
  
>SHOW TABLES [like...];（可以使用模糊查找）
查看视图详情
  
DESC 视图名或者SHOW FIELDS FROM 视图名
视图条件限制
  
[WITH CHECK OPTION]
1 视图

百度百科定义了什么是视图，但是对缺乏相关知识的人可能还是难以理解或者只有一个比较抽象的概念，笔者举个例子来解释下什么是视图。

朕想要了解皇宫的国库的相关情况，想知道酒窖有什么酒，剩多少，窖藏多少年，于是派最信任的高公公去清点，高公公去国库清点后报给了朕；朕又想知道藏书情况，于是又派高公公去清点并回来报告给朕，又想知道金银珠宝如何，又派高公公清点。。。过一段时间又想知道藏书情况，高公公还得重新再去清点，皇上问一次，高公公就得跑一次路。

后来皇上觉得高公公不容易，就成立了国库管理部门，小邓子负责酒窖，小卓子负责藏书，而小六子负责金库的清点。。。后来皇上每次想了解国库就直接问话负责人，负责人就按照职责要求进行汇报。 


安排专人管理后，每次皇上想要了解国库情况，就不必让高公公每次都跑一趟，而是指定的人员按照指定的任务完成指定的汇报工作就可以了。

和数据库相对应，每次进行查询工作，都需要编写查询代码进行查询；而视图的作用就是不必每次都重新编写查询的SQL代码，而是通过视图直接查询即可。因此：


  
视图是虚拟表，本身不存储数据，而是按照指定的方式进行查询。


比如，我们希望从前文提到的四张表，order_baisc,order_details，user和product中查找所有记录，需要写入代码指令： 


想再次查询这几个表中uid为u0001的用户的记录，有需要键入一次操作指令： 


也就是说，每次查询都得重新键入查询指令SQL代码，这种费时费力的体力活，对于时间就是生命的你我来说，是不划算的。所以借助视图，来执行相同或相似的查询。



2 创建视图

2.1 创建视图create view 

创建视图的代码为：



>CREATE VIEW 视图名(列1，列2...)
 AS SELECT (列1，列2...)
 FROM ...;

可以看到，创建视图和查询相比，增加了前面的CREATE VIEW  视图名 AS

2.2 视图运用


  
使用视图和使用表完全一样，只需要把视图当成一张表就OK了。视图是一张虚拟表。


eg：创建order_baisc,order_details，user和product的查询视图，并通过视图查找uid为u0001的记录： 


2.3 修改视图CREATE OR REPLACE VIEW

修改和创建视图可以使用代码：



CREATE OR REPLACE VIEW 视图名 AS SELECT [...] FROM [...];

eg: 


2.4 查看视图 
(1)查看数据库中有哪些视图 show tables 

前面提到，视图就是虚拟的表，因此，查看视图的方法和查看表的方法是一样的：



>SHOW TABLES;



通过show tables;反馈得到所有的表和视图。同样的，我们可以通过模糊检索的方式专门查看视图，这个时候，视图的命令统一采用v_视图名v_视图名的优势就体现出来了。 
（2）查看视图详情 

查看视图详情的方法有两种，一种是和查看表详情一样使用desc 视图名，另外一种方法是show fields from 视图名：



>DESC 视图名;
或者
>SHOW FIELDS FROM 视图名;



两种方法得到的详情都是一毛一样的。



3 视图与数据变更

3.1 表格数据变更 

将表product中的数据进行更新，在通过视图检索：



可以看到表格数据变化后，在通过视图检索，得到的结果也同步发生了变化，因此，在此证明了：


  
视图不是表，不保存数据，知识一张虚拟表；


3.2  通过视图变更数据

（1）插入数据
>INSERT INTO v_order(pid,pname,price) VALUES('p010','柴油','34');

在此查询视图，发现插入了数据。



（2）跨表插入数据 

通过上图，我们可以看到，跨表插入数据系统反馈报错，提示不能修改超过一个表的数据。

  
因此，可以通过视图插入数据，但是只能基于一个基础表进行插入，不能跨表更新数据。


（3）WITH CHECK OPTION 

如果在创建视图的时候制定了“WITH CHECK OPTION”，那么更新数据时不能插入或更新不符合视图限制条件的记录。

eg:对表product创建一个单价超过3000的视图，并加上“WITH CHECK OPTION”，之后插入一个价格为42的记录：



可以看到系统提示错误CHECK OPTION FAILED。因为视图限制了价格要高于3000. 

后面再次尝试了不加“WITH CHECK OPTION”的视图，后者可以成功插入。

同样的，在不加“WITH CHECK OPTION”的情况下，通过视图修改记录，也可以成功执行： 

通过视图修改，可能导致数据无故消失，因此：


  
没有特殊的理由，建议加上“WITH CHECK OPTION”命令。





  
注意点： 

  1. 视图不是表，不直接存储数据，是一张虚拟的表； 

  2. 一般情况下，在创建有条件限制的视图时，加上“WITH CHECK OPTION”命令。

mysql手册04_视图

视图是一种虚拟的表，封装了一条select查询语句。
视图的优势：


简化复杂的查询，封装了复杂的查询语句，方便多次调用。
隐藏表结构，提升了数据库安全性，可以使低权限的开发者只能看到数据表的部分字段，隐藏了机密字段


创建视图：
create view view_city_country 
as 
select c.*,t.country_name from city c, country t where c.country_id = t.country_id;

查看表和视图：
show tables;

查看表和视图内容：
select * from view_city_country

通过更新视图修改表数据：
update view_city_country set city_name = '西安市' where city_id = '1';

注：虽然可以通过更新视图来修改表数据，但是视图是为了方便数据查询的，不推荐通过视图修改表数据。

查看视图封装的select语句：
show create view view_city_country\G;

删除视图：
drop view if exists view_city_country;

补充：视图中可以嵌套使用视图

目录

一、RUP概述

二、“4+1”视图模型

一、RUP概述

RUP（Rational Unified Process），统一软件开发过程，统一软件过程是一个面向对象且基于网络的程序开发方法论。

在RUP中采用“4+1”视图模型来描述软件系统的体系结构。“4+1”视图包括逻辑视图、实现视图、进程视图、部署视图和用例视图。


	
最终用户关心的是系统的功能，因此会侧重于逻辑视图；
	
	

	
程序员关心的是系统的配置、装配等问题，因此会侧重于实现(开发)视图；
	
	

	
系统集成人员关心的是系统的性能、可伸缩性、吞吐率等问题，因此会侧重于进程(处理)视图；
	
	

	
系统工程师关心的是系统的发布、安装、拓扑结构等问题，因此会侧重于部署(物理)视图。
	
	

	
分析人员和测试人员关心的是系统的行为，因此会侧重于用例(场景)视图；
	
二、“4+1”视图模型

“4+1”视图模型从五个不同的视角来描述软件架构，每个视图只关心系统的一个侧面，五个视图结合在一起才能反映软件架构的全部内容。

（1）逻辑视图。

逻辑视图主要支持系统的功能需求，即系统提供给最终用户的服务。在逻辑视图中，系统分解成一系列的功能抽象，这些抽象主要来自问题领域。这种分解不但可以用来进行功能分析，而且可用作标识在整个系统的各个不同部分的通用机制和设计元素。在OO技术中，通过抽象、封装和继承，可以用对象模型来代表逻辑视图，用类图来描述逻辑视图。逻辑视图中使用的风格为面向对象的风格，在设计中要注意保持一个单一的、内聚的对象模型贯穿整个系统。

（2）开发视图。

开发视图也称为模块视图，在UML中被称为实现视图，它主要侧重于软件模块的组织和管理。开发视图要考虑软件内部的需求，例如，软件开发的容易性、软件复用和软件的通用性，要充分考虑由于具体开发工具的不同而带来的局限性。开发视图通过系统I/O关系的模型图和子系统图来描述。

（3）进程视图。

进程视图侧重于系统的运行特性，主要关注一些非功能性需求，例如，系统的性能和可用性等。进程视图强调并发性、分布性、系统集成性和容错能力，以及逻辑视图中的功能抽象如何适合进程结构等，它也定义了逻辑视图中的各个类的操作具体是在哪一个线程中被执行的。进程视图可以描述成多层抽象，每个级别分别关注不同的方面。

（4）物理视图。

物理视图在UML中被称为部署视图，它主要考虑如何把软件映射到硬件上，它通常要考虑到解决系统拓扑结构、系统安装和通信等问题。当软件运行于不同的物理节点上时，各视图中的构件都直接或间接地对应于系统的不同节点上。因此，从软件到节点的映射要有较高的灵活性，当环境改变时，对系统其他视图的影响最小化。

（5）用例视图。

用例可以看作是那些重要系统活动的抽象，它使四个视图有机联系起来，从某种意义上说场景是最重要的需求抽象。场景视图对应UML中的用例视图。在开发软件架构时，它可以帮助架构设计师找到构件及其相互关系。同时，架构设计师也可以用场景来分析一个特定的视图，或描述不同视图的构件之间是如何相互作用的。场景可以用文本表示，也可以用图形表示。下面是题目选项中几种UML图的解释，从中可以了解题目所描述的，是哪一种UML图。

对象图（object diagram）。对象图描述一组对象及它们之间的关系。对象图描述了在类图中所建立的事物实例的静态快照。和类图一样，这些图给出系统的静态设计视图或静态进程视图，但它们是从真实案例或原型案例的角度建立的。
	
活动图（activity diagram）。活动图将进程或其他计算结构展示为计算内部一步步的控制流和数据流。活动图专注于系统的动态视图。它对系统的功能建模和业务流程建模特别重要，并强调对象间的控制流程。 
	
状态图（state diagram）。状态图描述一个状态机，它由状态、转移、事件和活动组成。状态图给出了对象的动态视图。它对于接口、类或协作的行为建模尤为重要，而且它强调事件导致的对象行为，这非常有助于对反应式系统建模。 
	
类图（class diagram）。类图描述一组类、接口、协作和它们之间的关系。在OO系统的建模中，最常见的图就是类图。类图给出了系统的静态设计视图，活动类的类图给出了系统的静态进程视图。