Re: View updating in practice?

From: Jens Lechtenbörger <>
Date: 13 Nov 2002 10:22:30 +0100
Message-ID: <> (Mikito Harakiri) writes:

> "Jens Lechtenbörger <> wrote in message
> news:<>...
> > Just to clarify the connection between view inverses and
> > constant complement translators, here is a rough outline of my
> > approach: Any set V of views over some data sources D usually
> > preserves some but not all of the information contained in D.
> > Now, a set C of views over D is a complement of V if it is
> > possible to compute D from V and C, i.e., if there is way to
> > compute any source state from the state of V and C, or, in other
> > words, if V and C are equivalent to D (equivalent with respect
> > to information content), or, again in other words, if there is a
> > view inverse for V and C. Note that in general, complements are
> > not unique (as you might expect from algebraic complements). In
> > particular, views that describe a copy of D are a complement for
> > any set of views.
> >
> > Now, a view update on view V can be translated under constant
> > complement if there is a complement C of V such that the
> > contents of C do not change when the view update is executed on
> > the database. The intuition why such view updates are desirable
> > is the following: Assume that there is a view update that cannot
> > be translated under constant complement. Then such a view
> > update must have effects that are not visible in V. Without any
> > precautions, those effects will be visible in external schemata
> > of different users. Please think about it.
> >
> > What I have shown is the following: Users might be able to undo
> > their view updates using further view updates if and only if
> > their view updates can be translated under constant complement.
> > (The "might" indicates that users are able to undo their view
> > updates at least in theory; in practice, the update language
> > might not be expressive enough, though.)
> >
> > Informally, translation under constant complement implies that
> > all effects of view updates are visible in the views. Hence,
> > users are in full control of their actions. Stated differently,
> > users can undo their view updates if and only if they know what
> > they are doing.
> >
> > Concerning the relationship to an approach based on view
> > inverses: If the view itself is equivalent to some base
> > relation(s) then there is no need for a complement. Hence, even
> > the empty set of views is a complement. Clearly, the empty
> > complement remains constant under any update. Consequently,
> > such an approach is a very special and restricted case of the
> > constant complement approach.
> I don't follow (even after struggling with Bancilhon&Spuratos
> paper:-(
> Consider a view
> F: select x+y as u, 2*x+3*y as w from A
> It is equivalent (in the B&S sense) to the base relation
> A(x,y). It is just a special case when constant complement is 0,
> therefore. Is the task of translating
> insert into F (u,v) values(5,10);
> into the base relation A trivial?

No. Please note that the Bancilhon&Spuratos paper contains existence proofs, no constructions.

> Do we have to find a closed form
> expression for the inverse view, or could we somehow avoid it and
> get away with just computing the complement?
> OK, in linear algebra domain, as in my example, I can just ask
> Maple:
> > F:=Matrix([[1,1],[2,3]]); F^(-1);
> so that the answer for the inverse view is
> A: select 3*u-w as x, -2*u+1 as y from F
> If inverse view is known, then translating view update is trivial,
> but I don't see how one can compute inverse view without solving
> systems of equations. (Besides, there are obvious limits to
> equation solving).

I don't see that either.

> Ariphmetic domain operators in my previous example could raise
> relational eyebrows, but here is an example without them:
> Relation A:
> -- ----------- --------------
> 1 4150000000 4081111111
> 2 80012345672 6501234567
> select id, 'VOICE' phonetype, voice number
> from A
> union
> select id, 'FAX' phonetype, fax number from A
> What is the method to invert it?

It should be a join of (a) the projection of the view on id and voice_number and (b) the projection of the view on id and fax_number, i.e., something like this:

select, v1.voice_number, v2.fax_number from
 (select id, voice_number from view) as v1,  (select id, fax_number from view) as v2 where

Jens Received on Wed Nov 13 2002 - 10:22:30 CET

Original text of this message