Databases Reference
In-Depth Information
For every query Q1 on db1, there must exist a query Q2 on db2 that yields the same result
(and vice versa, obviously). Note: It follows from this observation that IS_EMPTY ( Q1 )
and IS_EMPTY ( Q2 ) are either both true or both false, and hence that, as claimed
previously, for every constraint C1 on DB1 there must exist a corresponding constraint C2
on DB2 and vice versa.
Let U1 be an update on DB1 that yields a “new” value db1′ of DB1 ; then there must exist
an update U2 on DB2 that yields a “new” value db2′ of DB2 , such that db1′ and db2′ are
information equivalent in turn (and vice versa once again). Fig. 3.1 illustrates this point.
db1
db2
U1
U2
db1′
db2′
Fig. 3.1: Information equivalence and updating
In contrast to the foregoing, suppose DB1 and DB2 aren't information equivalent. Then
there'll be operations—queries and updates—on DB1 that have no counterpart on DB2 or vice
versa. (Note, incidentally, that if DB1 and DB2 are indeed not information equivalent, then their
current values db1 and db2 might or might not themselves be information equivalent in turn; in
general, however, they won't be.)
Observe now that all of the above applies in the particular case in which DB2 consists
exclusively of views of the relvars in DB1 . In other words, if DB2 is “views only” and that set of
views is information equivalent to DB1 , then every update on DB2 has a counterpart update on
DB1 and vice versa. In the chapters to come, I'll consider this situation in detail; that is, I'll
show in detail how updates on the views in DB2 can be implemented in terms of updates on the
relvars in DB1 .
 
Search WWH ::




Custom Search