oracle视图原理以及dml操作视图限制

1 视图的概念

oracle视图实际上就是封装sql语句，对外提供一个别名，使用者不需要关心复杂的sql，视图执行之后会将执行的结果当做一个表来使用，相当于一个虚拟的表，如果想在视图上进行DML的操作，在创建时候有两个选项

（1）选择项WITH CHECK OPTION表示对视图进行UPDATE INSERT DELETE操作时，要保证操作的数据满足视图定义的谓词条件，也就是视图子查询中的WHERE子句的条件

（2）选项WITH READ ONLY 只读视图，不允许通过本视图更新本表

视图创建语句： Create [or  Replace] VIEW VIEW_NAME AS 子查询【WITH CHECK OPTION】【WITH READ ONLY】
视图的删除：DROP  VIEW  VIEW_NAME

2.视图的存储
与表不同，视图不会要求分配存储空间，视图中也不会包含实际的数据。视图只是定义了一个查询，视图中的数据是从基表中获取，这些数据在视图被引用时动态的生成。由于视图基于数据库中的其他对象，因此一个视图只需要占用数据字典中保存其定义的空间，而无需额外的存储空间。

3.视图的作用
用户可以通过视图以不同形式来显示基表中的数据，视图的强大之处在于它能够根据不同用户的需要来对基表中的数据进行整理。也就是说根据不同的需求创建不同的视图，
通过视图可以设定允许用户访问的列和数据行，从而为表提供了额外的安全控制隐藏数据复杂性 视图中可以使用连接(join)，用多个表中相关的列构成一个新的数据集。此视图就对用户隐藏了数据来源于多个表的事实。

4.视图的工作机制
视图的定义就是其使用的查询语句，Oracle将这个定义以文本形式存储在数据字典中。当用户在 SQL 语句中引用了视图时，Oracle 将进行以下工作： 将引用了视图的语句与视图的定义语句整合为一个语句 在共享SQL 区解析整合后的语句 执行此语句 当现有的共享SQL 区中没有与整合后的语句一致时，Oracle 才会为此语句创建新的共享SQL 区。因此，引用了视图的SQL 语句也能够利用已有的共享 SQL 区以达到节约内存和提高性能的目的。

5.视图的依赖性
 
由于视图的定义是一个引用了其他对象（表，视图）的查询，因此视图依赖于其所引用的对象。Oracle 会自动地处理视图的依赖性。例如，当用户移除了一个视图的基表后再重建此表，Oracle 将检查新的基表是否符合视图的定义并判断视图的有效性。

对视图进行dml操作注意事项：

假设现在人事管理系统中有三个表，一个是员工基本信息表，包含员工编号(非空)、员工姓名(非空)、身份证号码等字段;第二个表是企业部门职位表包含职位编号(非空)、职位名称(非空)、职位描述等字段;第三个是员工与部门职位对应表，包含员工编号(非空)、职位编号(非空)、描述等字段。


现在数据库管理员做了一张视图，查询员工编号、员工姓名、部门信息。此时，这张连接视图可以用DML语句来进行更新呢?这就要看其是否满足一定的条件。


条件一：在连接视图中不能有Order by排序语句。


若用户想要在上面这张视图中，更改员工所属的部门，则首先要考虑，在生成视图的查询语句中，是否使用了Order by排序语句。若有这个排序语句的话，则在视图上进行DML操作，是不会成功的。


这主要是因为采用了Order by排序语句后，记录的物理存储顺序发生了改变。此时，若在视图上进行了数据更新，则其对应的基础表找不到具体更改的物理位置。所以，会以失败告终。


所以，用户若想在上面这个视图界面对员工所属的部门进行更改的话，则一定不能够在SQL语句中加入Order by等排序语句。类似的，也不能够在SQL语句中含有Group by、connetc by等语句。若有这些语句的话，则数据库都不允许对数据进行数据更新操作。


条件二：基础表中所有的NOT NULL列都必须在这个视图中。


若想在视图上进行数据更新操作的话，则必须要求对应基础表中的所有不允许空的字段都在当前的视图中。其实这很好理解，若每个字段不允许为空，则又不在当前的视图中，则新增加记录的时候，这个字段就没有被赋值，故在保存时就会被基础表所拒绝。


在上面这个例子中，数据库管理员若建立的视图没有包含所有的非空字段。如企业部门职位表总的职位编号就没有在这个视图中。所以，数据库不会接纳这张视图上的更新。若用户确实需要在这张视图上更新数据，则就要考虑把所有的非空字段显示在这张视图上。

另外，需要注意的是，无论是更新还是删除语句，若基础表中的某个非空列不在这个视图中，都无法进行更改。也许有人会问，如果用户不是增加记录，而只是更新数据。那难道也要求在视图中包含所有的非空字段呢?答案是肯定的。因为数据库系统在提交更新事务之前就会对这个条件进行判断。


条件三：需要更新的列不是虚拟列。


在视图中，可能有些列的结果是通过列表达式定义的，在基础表中并不存在。我们把这些列叫做虚拟列。如在上面的员工信息表中，并没有员工的出生年月信息。而在视图中，我们可以通过身份证号码来取得某个员工的出生日期。此时若想在视图中更改这个出生日期，则很明显是不行的。因为基础表中根本没有这个字段，那更改的结果就无法保存。


只要在视图中有虚拟列的存在，只要视图中任何一列是由列表达式定义的，那么对不起，整张视图都不能够进行更改。这个控制原理跟上面这个条件是类似的。


可见，在数据库设计的时候，就需要考虑是否需要在视图基础上对表的内容进行更改。若需要更改的话，则一定不能够在视图中采用虚拟列，而宁愿在表中多增加一些字段。或者在数据库视图中不采用虚拟列，而是在前台应用程序中采用虚拟列。


条件四：不能够具有分组函数。


如上面这张员工与职位的对应关系表中，用户不但想知道某个职位现有的员工有哪些;还希望知道，某个职位现在员工的具体人数。要实现这个需求的话，则数据库管理员就需要在视图中采用分组函数，来统计某个职位的具体人数。


但是，若视图中有这个函数的话，则也不能够对这张视图进行更新。这是Oracle数据库的强制规定。


其实，这也可以通过一些灵活的方式来避免。如在数据库视图中不需要采用分组函数。而是在前台的Select语句中，查用分组函数。因为前台要调用数据库中的数据，仍然需要查用Select语句去查询视图。所以，即使在原始的数据库视图中不对数据进行分组，则在前台应用程序中仍然可以帮助用户完成数据分组与统计的任务。此时，用户若在视图中更改数据的话，不仅可以更新数据库基础表中的内容;而且，还可以及时的反馈到前台的应用程序界面中。


分组函数会增加数据库查询的负担;同时，使得无法在视图上采取DML操作。故数据库管理人员需要跟前台应用程序开发人员进行协商，在前台实现对数据的分组统计，而不是在后台。


除了以上几个限制条件之外，若需要在视图上进行DML操作的话，则在建立视图的Select语句中，还不能够有集合运算符、子查询等等。以上这些是一些必须要满足的基本条件，缺一不可。否则的话，针对视图的DML操作，就会以失败告终。


但是，并不是说符合了上面这个几个条件后，视图就可以畅所无阻的进行数据更新了，其仍然必须符合一定的规则。这其中，最重要的就是键值保存表规则。


如果连接视图中的一个基础表的键在他的视图中仍然存在，并且在连接视图中仍然是主键，则这个基础表就为键值保存表。在连接视图上，对视图进行插入、删除、更新等操作时，一次只能够对视图中的一个键值保存表进行更新。