《视图更新与关系数据库理论》——1.4 视图:约束和补偿性操作-阿里云开发者社区

开发者社区> 数据库> 正文

《视图更新与关系数据库理论》——1.4 视图:约束和补偿性操作

简介:

本节书摘来自异步社区出版社《视图更新与关系数据库理论》一书中的第1章,第1.4节,作者:【美】C.J. Date(达特),更多章节内容可以访问云栖社区“异步社区”公众号查看。

1.4 视图:约束和补偿性操作

现在我要开始讨论本章的核心概念。如果前面两段中所涉及的表中有一部分或者全部都是视图的话,那么我们讨论的所有结论依旧成立,没有改变。例如,像之前一样,假设S是表,LS和NLS是视图。

CREATE TABLE S        ( .............. , UNIQUE ( SNO ) ) ;
CREATE VIEW   LS   AS ( SELECT ... WHERE CITY = ‘London’ ) ;
CREATE VIEW   NLS AS ( SELECT ... WHERE CITY <> ‘London’ ) ;

现在假设用户只能看到视图LS和NLS,但是希望像基表一样操作它们。在这个用户看来,这些表的语义如下。

LS:供应商SNO是已经签约的,名称为SNAME,有状态值STATUS,位于城市CITY中(London)。

NLS:供应商SNO是已经签约的,名称为SNAME,有状态值STATUS,位于城市CITY中(非London)。

此用户将会了解有下面的约束存在(注意这些约束没有提到表S,因为用户并不知道表S的存在)。

{SNO}是LS和NLS的键。
LS中的每一行CITY值均为London,NLS没有这样的行。
供应商编号不会同时出现在LS和NLS中。
但是,该用户并不会意识到有补偿性操作的存在,因为他并不知道LS和NLS实际上是表S的视图。如前所述,该用户甚至根本不知道表S的存在,因此他也并不知道实现这些操作的约束到底是什么,以及视图LS和NLS合起来就等于表S这个事实。该用户执行的针对视图LS和NLS的更新也都会生效,在他看来就像LS和NLS都是基表一样。同样,这个用户在视图LS和NLS执行的更新在S中也会产生对应的关联效果,只是他看不到而已。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

其他文章