数据库系统原理（四）——视图与索引
视图与索引
在某些情况下，让所有用户看到整个逻辑模型是不合适的
考虑一个职员需要知道教师的标识、姓名和所在系名，但是没有权限看到教师的工资值，此人应该看到的关系由如下SQL语句所描述：
select ID,name,dept_name
from instructor
视图就提供了这种机制：向用户隐藏特定的数据，和一些权限管理相关内容相结合可以进行安全方面的处理
SQL允许通过查询来定义“虚关系“，它在概念上包含查询的结果，但并不预先计算并存储。像这种所谓虚关系对用户可见的关系称为视图（对view的访问都要转换成对物理表的访问）
1. 视图定义
create 和之前的with as有什么区别？create view是logical 、virtual的，但with占空间
在instructor中对老师按照院系分类，然后将院系的名字和工资总和select出来，然后用来创建departments_total_salary视图，还可以在视图中对相关属性进行命名
2. 视图更新
插入的时候针对物理表进行插入，也就是values中应该包含实际上的instructor中的所有属性，但是上面那个并没有全部插入，所以没有写进的属性都被赋值成null
在实际构建这个视图的时候使用了两张table——instructor和department，那么对这样一张view进行一条信息的插入的话实际上是对两个table进行插入，同样也是没有value写出的地方用null代替。
但实际上会出现问题——插入的department的信息是已经有的了，重复；还有如果插入的department信息没有，但是Taylor并不是主键，而正常的主键的位置却是null，这样其实也不允许的。
因此定义一个视图之后是否是update是有条件的：
- 解释如上
- 表达式和聚集的话，没有办法把这个表达式或者聚集的关系反推，聚集之后插入的时候的值没有办法对应到具体关系的元组上去了
- 没有出现的属性必须插入空值，但是如果在这个table定义的时候设置成非空，在使用这个table的view进行插入的时候如果values列表里没有这个值，则会出错
- 和2类似
但是即使满足上述条件也会出现一些问题：
实际上在默认情况下是允许更新的但是用户没有办法看到插入的记录因为不满足构成视图的条件。如果在语句的末尾加入with check option则不允许加入。
SQL-99对于何时可以在视图上执行插入、更新和删除有更复杂的规则集，这里不予讨论。
3. 物化视图
视图实际上是不存在的，任何对视图的操作都会转换为对表的操作，这个时候可以创建物化视图，顾名思义，物化视图有自己对应的物理存储，不用去底层访问对应的table
维护的三种方式的解释：
一旦关系被更新就更新视图；在关系被更新的时候先不更新视图，而是等到视图被使用的时候才去更新视图；周期性定时更新视图（维护的工作量不大，但是数据可能是过时的，但是对于一些对时效性要求不高的应用可以使用这种方法。
【类似Cache处理的直写法和写回法】
4. 索引
索引在数据库中查询速度蛮快的，但是前提是在数据库的table中只有几千条或者几万条数据的时候，但是当表中的数据不断增加如果不创建索引而去直接查询的话，会发现等待的时候非常长
实际上是创建了一个数据结构，只把和查询有关的保存下来；
在数据库中用空间换取时间的一种机制