So far in this chapter, I’ve been tacitly assuming you already know what views are for—but now I’d like to say something about that topic nonetheless. In fact, views serve two rather different purposes:
The user who actually defines view V is, obviously, aware of the corresponding defining expression exp. Thus, that user can use the name V wherever the expression exp is intended; however, such uses are basically just shorthand, and are explicitly understood to be just shorthand by the user in question. (What’s more, the user in question is unlikely to request any updates on V—though if such updates are requested, they must perform as expected, of course.)
By contrast, a user who’s merely informed that V exists and is available for use is supposed (at least ideally) not to be aware of the expression exp; to that user, in fact, V is supposed to look and feel just like a base relvar, as I’ve already explained at length. And it’s this second use of views that’s the really important one, and the one I’ve been concentrating on, tacitly, throughout this chapter prior to this point.
The second of the foregoing purposes is intimately related to the question of logical data independence. Recall from Chapter 1 that physical data independence means we can change the way the data is physically stored and accessed without having to make corresponding changes in the way the data is perceived by the user. Reasonably enough, then, logical data independence means we can change the way the data is logically stored and accessed without having to make corresponding changes in the way the data is perceived by the user. And it’s views that are supposed to provide that logical data independence.
By way of example, suppose that for some reason (the precise reason isn’t important for present purposes) we wish to replace base relvar S by base relvars LS and NLS, as follows:
VAR LS BASE RELATION/* London suppliers */{ SNO CHAR , SNAME CHAR , STATUS INTEGER , CITY CHAR } KEY { SNO } ; VAR NLS BASE RELATION/* non London suppliers */{ SNO CHAR , SNAME CHAR , STATUS INTEGER , CITY CHAR } KEY { SNO } ;
As we saw earlier, the old relvar S is the disjoint union of the two new relvars LS and NLS (and LS and NLS are both restrictions of that old relvar S). So we can define a view that’s exactly that union, and name it S:
VAR S VIRTUAL ( LS D_UNION NLS ) KEY { SNO } ;(Note that now I’ve specified D_UNION instead of UNION, for explicitness.) Any expression that previously referred to base relvar S will now refer to view S instead. Assuming the system supports operations on views correctly—unfortunately a rather large assumption, given the state of today’s products—users will be immune to this particular change in the logical structure of the database.
I note in passing that replacing the original suppliers relvar S by its two restrictions LS and NLS isn’t a totally trivial matter. In particular, something might have to be done about the shipments relvar SP, since that relvar has a foreign key that references the original suppliers relvar S. See Exercise 9.8 at the end of the chapter.