The Principle of Interchangeability implies that (a) users should be able to operate on views as if they were base relvars and (b) the DBMS should be able to map those user operations into suitable operations on the base relvars in terms of which the views are ultimately defined. I say “ultimately defined” here because if views really do behave just like base relvars, then one thing we can do is define further views on top of them, as in this SQL example:

     CREATE VIEW LS_STATUS
       AS ( SELECT SNO , STATUS
            FROM   LS ) ;

In this section, I limit my attention to the mapping of read-only or “retrieval” operations, for simplicity (I remind you that the operations of the relational algebra are indeed all read-only). In fact, the process of mapping a read-only operation on a view to operations on the underlying relvars is in principle quite straightforward. For example, suppose we issue this SQL query on the London suppliers view LS (I deliberately show all name qualifications explicitly):

     SELECT LS.SNO
     FROM   LS
     WHERE  LS.STATUS > 10

First, then, the DBMS replaces the reference to the view in the FROM clause by the expression that defines that view, yielding:

     SELECT LS.SNO
     FROM ( SELECT S.*
            FROM   S
            WHERE  S.CITY = 'London' ) AS LS
     WHERE  LS.STATUS > 10

This expression can now be directly evaluated. However—and for performance reasons perhaps more significantly—it can first be simplified to:

     SELECT S.SNO
     FROM   S
     WHERE  S.CITY = 'London'
     AND    S.STATUS > 10

In all likelihood, this latter expression is the one that will actually be evaluated.

Now, it’s important to understand that the reason the foregoing procedure works is precisely because of the relational closure property. Closure implies among other things that wherever we’re allowed to use the name of a variable to denote the value of the variable in question—for example, in a query—we can always replace that name by a more general expression (just so long as that expression denotes a value of the appropriate type, of course). In the FROM clause, for example, we can have an SQL table name; thus we can also have a more general SQL table expression, and that’s why we’re allowed to substitute the expression that defines the view LS for the name LS in the example.

For obvious reasons, the foregoing procedure for implementing read-only operations on views is known as the substitution procedure. Incidentally, it’s worth noting that the procedure didn’t always work in early versions of SQL—to be specific, in versions prior to 1992—and the reason was that those early versions didn’t fully support the closure property. As a result, certain apparently innocuous queries against certain apparently innocuous tables (actually views) failed, and failed, moreover, in ways that were hard to explain. Here’s a simple example. First the view definition:

     CREATE VIEW V
       AS ( SELECT CITY , SUM ( STATUS ) AS SST
            FROM   S
            GROUP  BY CITY ) ;

Now a query:

     SELECT CITY
     FROM   V
     WHERE  SST > 25

This query failed in the SQL standard, prior to 1992, because simple substitution yielded something like the following syntactically invalid expression:

     SELECT CITY
     FROM   S
     WHERE  SUM ( STATUS ) > 25     /* warning: invalid !!! */
     GROUP  BY CITY

(This expression is invalid because SQL doesn’t allow “set function” invocations like SUM(STATUS) to be used in the WHERE clause in this manner.)

Now, the standard has been fixed in this regard, as you probably know;^[127] however, it doesn’t follow that the products have!—and indeed, the last time I looked, there was at least one major product that hadn’t. Indeed, precisely because of problems like the foregoing among others, the product in question actually implements certain view retrievals by materialization instead of substitution; that is, it actually evaluates the view defining expression, builds a table to hold the result of that evaluation, and then executes the requested retrieval against that materialized table. And while such an implementation might be argued to conform to the letter of the relational model, as it were, I don’t think it can be said to conform to the spirit. (It probably won’t perform very well, either.)