第8章 视图与索引

数据库原理复习专栏

• 视图分虚拟视图和物化视图，索引是一种物化视图。一般地，除非特别说明，否则当我们说“视图”时指的都是虚拟视图。

虚拟视图$\to View$

• 一般的表($table$)均存放于物理存储器中，它们是实际保存的数据，而视图(指虚拟视图，下同)则是由DBMS维护的“虚拟表”，在每次需要访问视图时都会相应地先重构整个表然后再提供访问，除了使之后的操作语句稍简洁外，没有提供任何效率的提升和优化，甚至可能比直接查询更慢一点点。
  
  • 稍后可以发现，甚至连创建视图时，除了前面多了create view <视图名> as，后面的语句和之前的select语句一毛一样。换句话说，视图就像一个指向某select语句的指针！
• 创建视图，使用语句CREATE VIEW <视图名> AS <视图定义>;，如：

create view employees_view as
    select emp_no as id, concat(first_name, ' ', last_name) as name
    from employees;

便定义了一个视图(相当于一张表)，提取了employees表中的３个字段，并且将emp_no重命名(别名, $alias$, $AS$)为id，将first_name和last_name通过系统字符串函数concat连接并命名为name，因此新的(虚拟)表employees_view包含两个字段id和name。通过show tables;可以看到employees_view和普通的表一样被列了出来，并且可以对它进行任何和普通表一样的操作(增删改查,但前３者仅对可更新视图有效)。

• 视图查询，如上所述，可以直接通过(虚拟)表employees_view查询其中的信息：select * from employees_view limit 10;、select * from employees_view where name = 'gongbaojin';、select id from employees_view where name = 'Kruskal David';等等。

• 属性重命名，上例通过在查询语句中使用as实现属性重命名(emp_no$\to$id)，另外可以通过

CREATE VIEW employees_view(id, name) AS
    SELECT emp_no, CONCAT(first_name, ' ', last_name)
    FROM employees;

即在视图名后带上新的属性名来达到同样的效果。

习题 8.1.1

• $a)$

create view RichExec as
    select name, address, cert, netWorth
    from MovieExec
    where netWorth > 1000000;

• $b)$

create view StudioPress as
    select name, address, cert
    from MovieExec
    where (name) in
        (select (presC\#) from Studio);

• $c)$

create view ExecutiveStar as
    select S.name as name, S.address as address, gender, birthdate, cert, netWorth
    from MovieStar S inner join MovieExec;

视图更新

• 视图删除：drop view <视图名>，就删掉了。根据前面的比喻，我们相当于删除了一个指针，或者说一个快捷方式，原本的数据表不受任何影响。

• 可更新视图，要求：视图是由从单个关系$R$(就是单个表，当然，可以是虚拟表$\to$视图)中选取的一些属性组成(简单$select$，注意如果是$select\ distinct$则不行，因为选取出数据后会去重，相当于破坏了最原始的取出的那份数据)。于是：

  • 创建该视图时，如果$select$过程中使用了$where$子句，不能使用$\,R\,$关系。
  • $from$语句只能包含$R$，不能再加上其他关系
  • $select$出的属性必须足够多，没有默认值的属性应该都被选出。

  满足上述条件便可以通过更新视图来同时达到更新关系$~R~$的效果。对满足上述条件的视图，也就可以愉快地更新了。

• 现在，可以说明为何需要$~instead\ of~$触发器了。假设关系$~Movies\left(title, year, studioName\right)$，另有视图：

create view fox as
select title, year
where studioName = 'Fox';

可以选出所有福克斯电影公司的电影及其年份。它满足上面的可更新视图的要求，我们自然知道，该视图中仅存放了福克斯公司出品的电影，但在插入时$studioName$却会被自动设置为$null$，于是可以使用一个$~instead\ of~$触发器来代替完成插入功能：

create trigger foxInsert
instead of insert on fox
referencing new row as newrow
for each row
    insert into Movies (title, year, studioName)
    values (newrow.title, newrow.year, 'Fox');

当然，话说回来，劳资费这劲儿干嘛呢！

索引$\to Index$

• 所谓索引，就是目录，把章节内容和“页码”这个东西对应起来，以此加快查找。$DBMS$一般使用$~B^-$树实现索引。
• 声明索引，使用语句CREATE INDEX <索引名> ON <关系名>(<欲用以建立索引的属性名>)，如create index keyindex on Movies(title, year);
• 删除索引，DROP INDEX <索引名>

• 索引的选择，最有用的索引是建立在主键上的索引，原因：

  • 使用频繁，比如在选择想要的某条记录时往往都把主键值等于某某某作为where语句来使用
  • 键值唯一，可以大大提高页面交换效率

  但是事实上，一般只要保证被索引的属性上存在相同属性值的元组比较少就可以起到比较好的效果。

• 调优：可以通过从$~log~$中读取各类查询的统计结果来评估优化索引设计。按下不讲...

习题 8.4.2

物化视图$\to materialized$

• 物化视图是经过“物化”的视图，会实际保存于物理存储器中。假设其省略了原关系(原表)中我们不关心的部分属性，那么查找数据和维护数据都会来得更简洁和方便，但是为了避免虚拟视图的低效率，物化视图不应该在原关系数据更新后随着立即更新，不然在原关系更新频繁时依然会发生恼人的效率问题，所以一般选择“每晚定时更新”这样的策略，尽管这样会使得视图中的数据有一些“不及时”，“延迟”，但在这样的延迟不重要时是可以考虑使用它的。比如为超市提供进货意见...
• 举个栗子：

CREATE MATERIALIZED VIEW MovieProd AS
    SELECT title, year, name
    FROM Movies, MovieExec
    WHERE producer = cert;

当然，$MySQL~$是不资瓷这个东西的。