Re: View Updates Problem Statement

"Mikito Harakiri" <mikharakiri_at_ywho.com> wrote in message news:DYn7b.21$oA5.198_at_news.oracle.com...
>
> "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.

It is important who or what specifies the invariants. If a dba can specify the invariants for a view, then I would argue the invariants are simply part of the view itself. If the user must specify the invariants an update preserves, then the user must know the addressed relvar is a view and must know the effect on other views. Given that the user might be an application in the field that addressed base relvars when written, requiring the application change to specify the invariants is exactly the thing we want to avoid.

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

Can one express defaults as constraint tranformations? I agree that the dbms cannot resolve the update if ambiguous, and I suggest the dbms simply return an error to the user rather than have the user specify additional constraints.

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

Okay. I agree that one can express most and perhaps all constraints as transformations that evaluate to constants. Received on Wed Sep 10 2003 - 13:59:23 CEST