SQL and Views
They’re concerned by adverse publicity and that I have to move more into public eye.Problem is to define first the exact view we want to project.
—H. R. Haldeman: The Haldeman Diaries: Inside the Nixon White House (1994)
Intuitively, there are several different ways of looking at what a view is, all of which are valid and all of which can be helpful in the right circumstances:
A view is a virtual relvar; in other words, it’s a relvar that “looks and feels” just like a base relvar but (unlike a base relvar) doesn’t exist independently of other relvars—rather, it’s defined in terms of such other relvars.
A view is a derived relvar; in other words, it’s a relvar that’s explicitly derived (and known to be derived, at least by some people) from certain other relvars. Note: If you’re wondering what the difference is between a derived relvar and a virtual one (see the previous bullet item), I should explain that all virtual relvars are derived but some derived ones aren’t virtual. See the section “Views and Snapshots,” later in this chapter.
A view is a “window into” the relvars from which it’s derived; thus, operations on the view are to be understood as “really” being operations on those underlying relvars.
A view is what some writers call a “canned query” (more precisely, it’s a named relational expression).
As usual, in what follows I’ll discuss these ideas in both relational and SQL terms. But talking of SQL, let me remind you of something I said in