# Re: View updating in practice?

Date: 13 Nov 2002 10:22:30 +0100

Message-ID: <m28yzxhlih.fsf_at_pcwi1068.uni-muenster.de>

mikharakiri_at_yahoo.com (Mikito Harakiri) writes:

> "Jens Lechtenbörger <lechtej_at_uni-muenster.de> wrote in message

*> news:<m265v6nz31.fsf_at_pcwi1068.uni-muenster.de>...
**> > 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:
**>
**> ID VOICE FAX
**> -- ----------- --------------
**> 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.id, v1.voice_number, v2.fax_number
from

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

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