数据库系统概念——视图

视图

1. 需求：为什么要有视图？

没有视图的弊：

我们在逻辑模型层的任何操作所导致的变化都会被映射到数据库底层，引起底层数据的变化。

有了视图的利：

1. 安全性：
让所有用户都看到整个逻辑模型（数据表）是不合适的。出于安全考虑，需要向用户隐藏特定的数据，比如：工资
2. 个性化：
用户希望能创建符合其要求的个性化的关系集合。
例如：教务处希望有一个“各个系每年的秋季学期所开设的课程列表”。这样的关系集合在逻辑模型层并不存在，需要用户创建。如果没有视图，意味着每次使用时，都要手动SQL查询，及其不方便。而有了视图，可以“一次定义，终身使用”。

2. 使用：视图定义与使用

视图定义

0. 概念
    虚关系：通过SQL查询定义，在概念上包含查询的结果
    视图：不是逻辑模型的一部分，但作为“虚关系”对用户可见的关系
1. 标准视图定义
create view v as <query expression>
其中：
    <query expression>:任何合法的查询表达式
     v：视图别名

2. 显式指定视图的属性名
create view dept_total_salary(dept_name, total_salary) as 
    select dept_name, sum(salary)
    from instrctor
    group by dept_name;

在SQL查询中使用视图

在SQL查询中，视图可以出现在关系名可以出现的任何地方。

3. 深入：视图的存储，更新与维护

视图存储

当我们定义一个视图时，数据库系统存储视图的定义本身，而不存储定义该视图的查询表达式的计算结果。一旦视图出现在查询中，它就会被已存储的查询表达式所替代。因此，无论我们何时执行这个查询，视图关系都被重新计算。

物化视图

0. 概念
某些数据库存储视图关系（即查询表达式的计算结果），但保证：一旦用于定义视图的实际关系改变，视图也随之改变
1. 必要手段：视图维护
保持物化视图一直在最新状态的过程。
不同的数据库有不同的视图维护策略
    1. 周期性视图维护（可能访问到旧数据）
    2. 视图被访问时，才执行视图维护
    3. 数据库管理员自控制
2. 应用场景
    1. 频繁使用视图的应用
    2. 需要快速响应 基于大关系上聚集计算的特定查询
3. 利弊
在某些情况下，聚集结果要比定义视图的大关系小得多，所以，利用物化视图来回答查询就快得多，它避免了读取大的底层关系。
当然，这种好处需要权衡存储代价和更新开销。

视图更新

1.  为什么一般不允许对视图关系进行修改？
    1.  不满足数据表的定义（主要是完整性约束）
    2.  “伪更新操作”
        视图：
            create view instructor_info as 
                select ID, name, building 
                from instructor, building
                where instructor.dept_name = building.dept_name;
        操作：
            insert into instructor_info
                values(‘69987’, 'White', 'Taylor');
        问题：
        这个更新并没有产生所需的结果。
        因为新插入的元祖并不满足视图关系的选择条件，故仍然不包含元祖
2.  什么情况下我们可以对视图关系进行修改？
可更新（updatable）的视图
    1.  from子句中只有一个数据库关系
    2.  select子句中只包含关系的属性名，不包含任何表达式，聚集或者distinct声明
    3.  任何没有出现在select子句中的属性可以取空值（即这些属性上没有not null约束，也不构成主码的一部分）
    4.  查询中不含有group by 或 having子句
3.  修改视图会带来哪些影响？
    即便是向可更新的视图进行插入操作，新插入的元祖可能仍不会被包含在视图中，因为其不满足视图关系的选择条件
    （在视图定义的末尾加上with check option子句加以解决）