本节书摘来自异步社区出版社《视图更新与关系数据库理论》一书中的第1章，第1.1节，作者：【美】C.J. Date（达特），更多章节内容可以访问云栖社区“异步社区”公众号查看。
1.1 可交换性原则
到目前为止，表S是基表，LS和NLS是视图。现在仔细观察，你会发现其实我们还可以用另一种方式来看它们，那就是把LS和NLS作为基表，而S作为视图，具体如下所示。
CREATE TABLE LS
( SNO VARCHAR(5) NOT NULL ,
SNAME VARCHAR(25) NOT NULL ,
STATUS INTEGER NOT NULL ,
CITY VARCHAR(20) NOT NULL ,
UNIQUE ( SNO ) ) ;
CREATE TABLE NLS
( SNO VARCHAR(5) NOT NULL ,
SNAME VARCHAR(25) NOT NULL ,
STATUS INTEGER NOT NULL ,
CITY VARCHAR(20) NOT NULL ,
UNIQUE ( SNO ) ) ;
CREATE VIEW S AS
( SELECT SNO , SNAME , STATUS , CITY
FROM LS
UNION
SELECT SNO , SNAME , STATUS , CITY
FROM NLS ) ;
为了保证现在这个设计与原先的设计完全等价，我应该声明并且让数据库满足特定的完整性约束，当然其中应该包括针对CITY值的一致性约束，以保证LS中每一个CITY值都是London，NLS中CITY值都不是London。但是现在我们暂时不考虑这些细节，稍后我会对这些问题做更详细的解释。
那么现在，做出上面这个变化所要表明的内容可以概括为：对基表和视图的设定是没有限制的，是可以互换的（至少从正式的角度来看是这样）。换句话说，对于这个例子，我们至少可以用两种方式设计数据库，这两种方式逻辑上不同，但包含的信息是等价的。（这里的等价信息，是指两个设计代表了相同的信息，也就是说对于在一种设计执行的查询，一定有在逻辑上和它等价的查询可以在另一种设计上执行。第3章将详细阐述这个概念。）而“可交换性原则”就是对上面内容的总结。
定义：可交换性原则说明在基表和视图之间一定不能存在不确定的和不必要的区别。换句话说，在用户看来，视图与基表应该看起来感觉是很像的。
关于这个原则，下面几点值得注意。
正如我所阐述的，视图与基表一样，受完整性约束的限制（我们通常认为完整性约束是专门应用于基表的，但是可交换性原则证明这种想法有失偏颇）。
特别要说的是，视图是有键的（我确实应该在视图的定义中包括键的声明。但可惜的是，SQL并不允许这样声明）[2]。同时，视图也可能有外键，而外键也可能引用自视图。
很多SQL产品和SQL标准，提供了某种叫作row ID的特性（在标准中，此特性被称为REF类型和引用值）。如果这个特性只对基表有效，而对视图无效（实际上，这种情况非常有可能发生），那就明显违反了可交换性原则。
最后，也许最重要的是，我们必须能够更新视图，因为如果不能实现更新，那就等于“可交换性原则”内部自相矛盾了。
