Fase de realización

Database relvars shall be eitherrealorvirtual. Avirtual relvarVshall be a database relvar whose value at any given time is the result of evaluating a certain relational expression at that time; the relational expression in question shall be specified whenVis defined and shall mention at least one database relvar. Areal relvarshall be a database relvar that is not virtual. Defining a real relvar

Vshall have the effect of initializingVto some value—either a value specified explicitly as part of the operation that definesV,or an empty relation if no such explicit value is specified.

Application relvars shall be eitherpublicorprivate. Apublic relvarshall be an application relvar that constitutes the perception of the application in question of some portion of some database. Aprivate relvarshall be an application relvar that is completely private to the

application in question and is not part of any database. Defining a private relvarVshall have the effect of initializingVto some value—either a value specified explicitly as part of the operation that definesV,oran empty relation if no such explicit value is specified.

——————

Virtual Relvars

Database relvars are either real or virtual (“base tables or views”). Real relvars were discussed under RM Prescription 13. Here by contrast are a couple of examples of virtual relvars:

VAR PART_CITIES VIRTUAL

( P { P#, CITY } ) /* projection of parts on P# and CITY */ KEY { P# } ;

VAR COLOCATED VIRTUAL

( S JOIN P ) /* join of suppliers and parts on CITY */ KEY { S#, P# } ;

Relvars PART_CITIES and COLOCATED are now part of the database, in the sense that— like the relvars S and P in terms of which they are defined1—they are now described by entries in the database catalog. The value of each of these virtual relvars at timetis the value at timetof the

1_{We do not preclude the possibility of defining views of application relvars as well as database ones. For simplicity,}

relational expression in terms of which it is defined. Note: If the KEY specifications were omitted, the relvars would be considered to have whatever candidate keys could be inferred by the system for their defining expressions (see RM Very Strong Suggestion 3 in Chapter 10).

Now, it is well known (but still worth mentioning explicitly) that virtual relvars serve two rather different purposes:

1. A user who actuallydefinesa virtual relvarVis, obviously, aware of the expressionXin terms of whichVis defined. Such a user can use the nameVwherever the expressionXis intended, but such uses are basically just shorthand.

2. By contrast, a user who is merely informed that relvarVexists and is available for use is typicallynotaware of the defining expressionX. To such a user, in fact, relvarVshould ideally look and behave just like a real relvar. Of course, it is also well known that there are difficulties over updating virtual relvars; thus, it is unclear at the time of writing to what extent this objective can be achieved. We observe, however, that if any relvar turns out to be intrinsically nonupdatable, then we would not be justified in calling it a relvar—i.e., a

variable—in the first place. See Appendix E for further discussion.

We distinguish between these two cases when necessary by referring to them explicitly as Case 1 and Case 2, respectively. Note in particular, however, that we do not make any distinctions in this regard regarding updatability in particular—we intend Case 1 and Case 2 virtual relvars to be exactly as updatable as each other.

We observe further that, at least for Case 2, the decision as to which relvars should be considered real and which virtual is to some degree arbitrary (we say “to some degree” because database design theory sometimes has something to say on such matters). For example, let the values of relvarsA, B,andCat timetbea, b,andc,respectively. If it is true for all such timest

thataandbare projections ofcandcis the join ofaandb,then either (a)AandBcould be real and

Cvirtual, or (b)Ccould be real andAandBvirtual. It follows that there should be no arbitrary and unnecessary distinctions between real and virtual relvars. We refer to this fact—or perhaps

objectivewould be a better word, given the uncertainties over updatability already mentioned—as

The Principle of Interchangeability(of real and virtual relvars). Private Relvars

A private relvar is simply a local variable that happens to be a relvar; it is not part of the database and has no entry in the catalog. For example:

VAR PQ PRIVATE RELATION { P# P#, QTY QTY } KEY { P# } ;

Relvar PQ is initialized to the following empty relation:

Public Relvars

Suppose applicationAaccesses database relvarVdirectly by name (note that we do not prohibit such a possibility, though we would not object if the implementation did so). Clearly, then, applicationAis vulnerable to changes in the definition ofV. In the interests of logical data

independence, therefore [86], we prescribe support forpublic relvars. A public relvar represents the application’s perception of some portion of the database. For example:

VAR ZS PUBLIC RELATION { S# S#, SNAME NAME, CITY CHAR } KEY { S# } ;

This definition effectively asserts that “the application believes” there is a relvar in the database called ZS, with attributes and key as specified. Such is not the case, of course—but there is a database relvar called S (with attributes and key as specified for ZS but with one additional attribute), and we can clearly define a mapping between them, thus:

ZS ≡ S { S#, SNAME, CITY }

The right side of this mapping denotes the projection of S on S#, SNAME, and CITY. The mapping is performed outside the application.1 Now if it ever becomes necessary to change the definition of relvar S in any way, logical data independence can be preserved by changing the mapping and not the application.

The concept of public relvars allows us to draw a sharp distinction between the database as it is known (a) to the system and (b) to the application. In other words, we maintain two sets of definitions, one in the application and one in the catalog; the former represent the application’s perception of the database and the latter represent the database “as it really is,” and maintaining the mapping between the two is what enables us to achieve logical data independence.

We close this subsection by pointing out that (as you might have realized already) public relvars amount to little more than a slight variation on Case 2 virtual relvars. That is, a public relvar can be thought of as a Case 2 virtual relvar,Rsay, except that:

a. The mapping ofRto the relvar(s) in terms of whichRis defined is specified not as part of the definition ofRitself but, rather, somewhere external to that definition.

b. The structure ofRis explicitly specified as part of the definition ofRitself, instead of being inferred from that mapping.

In fact, Case 2 virtual relvars were always intended, like public relvars, to serve as a mechanism for achieving logical data independence; unfortunately, however, the manner of their commercial realization undermined that objective, at least in SQL. The problem with SQL views in this regard is that an SQL view definition explicitly reveals the mapping information and so makes it difficult to hide that information from the user—despite the fact that hiding that information is exactly what needs to be done. (Indeed, the structural information, which the user does need to know about, is not defined explicitly but is inferred from the mapping.) Thus, it would be possible to dispense with

1_{We leave details of the mapping process to implementers, though we observe that the languageDmight be used for}

the public relvar concept if the Case 2 virtual relvar concept were revised appropriately. We do not propose any such revision here, however, for fear of introducing confusion—and so the criticisms just articulated apply to our virtual relvars almost but not quite as much as they do to SQL views. (We say “not quite” because we do at least allow integrity constraints to refer to virtual relvars.) Relation Constants

LetVbe a virtual relvar, and letXbe the defining expression forV. As noted in Chapter 5,Xmust not mention any variables other than database relvars (but it must mention at least one of those, for otherwise it would have a constant value andVwould not be a variable at all). As also noted in Chapter 5, however, the ability to define relation constants orrelconsmight well be useful in practice. For example (to invent some syntax on the fly):

CONST PQ6 RELATION { TUPLE { P# P#('P1'), QTY QTY( 600) } , TUPLE { P# P#('P2'), QTY QTY(1000) } , TUPLE { P# P#('P3'), QTY QTY( 400) } , TUPLE { P# P#('P4'), QTY QTY( 500) } , TUPLE { P# P#('P5'), QTY QTY( 500) } , TUPLE { P# P#('P6'), QTY QTY( 100) } } ;

Now, it might be objected that a virtual relvarVcan have a constant value even if its defining expression does mention at least one database relvar and no other variables. For example:

VAR NO_SUPPLIERS VIRTUAL ( S WHERE FALSE ) ;

This relvar is always empty (INSERTs will always fail unless the set of tuples to be inserted is empty), and thus it certainly has a constant value. But this state of affairs is not really different in kind from one in which the relvar is real but subject to a certain constraint:

VAR R REAL ... ;

CONSTRAINT R_IS_EMPTY ( IS_EMPTY ( R ) ) ;

Like R in this example, NO_SUPPLIERS is notintrinsicallynonupdatable—in both cases, it is just that the existence of a certain constraint implies that certain updates (not all) will fail.1 To be more specific, both relvars are subject to the constraint “for all tuples in the relvar, FALSE,” which evaluates to TRUE if and only if the relvar is empty. See Appendix E for further explanation.

It might also be objected that a virtual relvarVcan have different values at different times even if its defining expression fails to mention any database relvars at all. For example:

VAR TODAY VIRTUAL ( RELATION { TUPLE { D CURRENT_DATE ( ) } } ) ;

We are assuming here that CURRENT_DATE is a niladic built-in operator that returns “the date today”; in effect, it is a kind of system variable (and the defining expression for TODAY thus does mention a variable, albeit not a database relvar). While it might be useful to support some

1_{In fact, the virtual relvar NO_SUPPLIERS seems to be logically indistinguishable from arealrelvar defined to be}

such functionality, we feel that such considerations are secondary to our main purpose. We also feel that to use the terminology of virtual relvars in connection with such functionality is to muddy an otherwise clear picture (virtual relvars were always intended to provide views of the database specifically). Note in particular that it makes little sense to attempt to apply explicit updates to a “relvar” like TODAY.