Re: View Updates Problem Statement

"Bob Badour" <bbadour_at_golden.net> wrote in message news:jqn7b.779$z22.72420381_at_mantis.golden.net...
> "Mikito Harakiri" <mikharakiri_at_ywho.com> wrote in message
> news:BBa7b.29$741.241_at_news.oracle.com...
> > That entirely depends upon view update context. Suppose we have "data
> > integration" problem.
> >
> > Database A has relations RA1, RA2, RA3, ...
> > Database B has relations RB1, RB2, ...
> >
> > Views V1, V2, V3, ... establish the mapping between the 2 databases:
> >
> > V1*RA1 = RB1
> > V2*RA2 = RB2
> > ...
> >
> > Problem. Translate each update in database B into database A.
> >
> > We, therefore, have at least one view update problem with many views.
>
> Insofar as the user names multiple relvars while updating B, the update
> involves multiple views. If the user names only a single relvar in B, the
> update involves only a single view.

I'm not sure why "user" is an important concept in that context. Or I simply misunderstand who the user is.

> > Now let's change "relations in the database A" to "base relations", and
> > "relations in the database B" into "views" (in the same database). That
> > sounds like original view updates formulation.
> >
> > What is wrong with user knowing the effect of update on a set of views
V1,
> > V2, ... ?
>
> I never claimed there is anything wrong with a user having such knowledge;
> although, I find it unreasonable for a dbms to require more knowledge of a
> user than is necessary.

I think we understand each other. Summarizing my point: if a transformation defined by a single view is invertible, then no firther knowledge required for solving view update problem. If not, then perhaps refining transformation with constraint equations may help resolving ambuguties. Given that constraints are part of database spec, that step doesn't really require additional input from user. However, if the transformation is still not invertible, then additional views are absolutely necessary.

> > > > 3. Constraints are views that evaluate to constants. For example, if
> we
> > > > define
> > > >
> > > > view V3
> > > > select max(sal) from (
> > > > select sal from emp
> > > > union
> > > > select 1000 from DEE
> > > > )
> > > >
> > > > then constraint "each emp has salary no more than 1000" can
> > algebraically
> > > be
> > > > written as
> > > >
> > > > V3*x = 1000
> > > >
> > > > where "V3*x" means view V3 applied to a set of base relations x, and
> > > "1000"
> > > > means an output relation that has one tuple with a single value
1000.
> > >
> > > What set of relations are you talking about? V3 references emp and
DEE.
> Or
> > > are you talking about the possible values of emp and DEE?
> >
> > Date's DEE is a constant relation containing one tuple. I introduced it
in
> > order to transform inequality into equality. Emp is the only relation
> > variable that is used in the V3. But it can be many. We can assume that
a
> > view input is the set of all base relations, while view output doesn't
> > necessarily depend upon all of them.
>
> So, you were talking about a set of relvars. Is that a correct
> interpretation?

Yes, as long as view transformation maps a set of input relational variables to the set of output relational variables. For example

create view Phone as
select id, "VOICE" phonetype, number
from Voice

   union
select id, "FAX" phonetype, number
from Fax

maps {Voice, Fax} set of relvals into {Phone} set of relvals. Received on Tue Sep 09 2003 - 19:10:33 CEST