Databases Reference
In-Depth Information
CONCLUDING REMARKS
This brings me to the end of the discussion of the motivating example. Now, that example is
extremely simple, and the conclusions I've drawn from it are perhaps all very obvious; but what
I'm suggesting is that thinking of views as base tables “living alongside” the tables in terms of
which they're defined is a fruitful way to think about the view updating problem in general—
indeed, not just a fruitful way, but a way I believe is
logically correct
.
8
The overall idea is thus
as follows:
1. The view defining expressions imply certain constraints. For example, the view defining
expression for view LS (“London suppliers”) implies a constraint to the effect that LS is
equal to that restriction of table S where the CITY value is London.
2. Such constraints in turn imply certain compensatory actions (i.e., actions that need to be
performed, over and above updates that are explicitly requested by the user, in order to
avoid some integrity violation that might otherwise occur). For example, the constraints on
tables S, LS, and NLS imply certain cascade deletes and cascade inserts, as we've seen.
By the way, I'd really like to stress this latter point—the point, that is, that it should be
possible for the compensatory actions that apply in a given situation to be determined by the
DBMS from the pertinent view defining expression. In other words, what I'm
not
suggesting is
that such actions need to be specified explicitly, thereby imposing yet another administrative
burden on the already overworked DBA.
9
But this issue, like many others I've touched on
briefly in this introductory chapter, will be explored in more detail in later parts of the topic.
In closing, let me suggest that if (like most people) you skipped the preface and started
straight in on this first chapter, now would be a good time to go back and read the preface, before
you move on to the next chapter. Among other things, the preface includes an outline of the
structure of the topic overall. It also spells out certain important technical assumptions that I'll
be relying on in the chapters to come, and hence that you need to be aware of.
8
Acknowledgments here to David McGoveran, who first got me thinking along these lines several years ago.
9
DBA = database administrator.
