Re: View updating in practice?

"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? 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

1. 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).

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? Received on Wed Nov 13 2002 - 03:24:20 CET