Re: Possible problems with Date & McGoveran View Updating

From: Bob Badour <bbadour_at_golden.net>
Date: Tue, 9 Sep 2003 11:09:06 -0400
Message-ID: <qen7b.776$v02.72328255_at_mantis.golden.net>


"Mikito Harakiri" <mikharakiri_at_ywho.com> wrote in message news:OTa7b.30$741.269_at_news.oracle.com...
> "Bob Badour" <bbadour_at_golden.net> wrote in message
> news:N3b7b.732$%Q.69880903_at_mantis.golden.net...
> > > Not general enough.
> >
> > Not general enough for what?
>
> Clarified in different thread.

I suggest that your clarification was too cryptic. I don't recall seeing how systematic defaults are not general enough to resolve ambiguities.

> > > Constraints are one possibility. Extending views (aka adding more
> > equations)
> > > like in the "union" example above is more general approach.
> >
> > The view is what it is. Extending the view would alter the logical view
of
> > some user or application.
>
> No, I'm not suggesting to arbitrarily extend the view.
>
> The system must just reject any attempt updating ambiguous system of
views.

Default values can resolve ambiguieties.

> The user can correct the error by supplying view update effect on
additional
> views (which is analogous to adding more equations).

Okay, I see what you are saying: The user requests an update such that it preserves some invariant also supplied by the user.

This violates many principles of effective data management. It forces the cognitive burden onto unsophisticated end-users.

> If you agree that
> constraint is a view that evaluates to a constant, then you can easily
adopt
> the idea that there are multiple views involved, not just one.

A constraint is an invariant, and a view is an unstored derived relvar. One can express an invariant by asserting a view evaluates to a constant, but the view is different from the assertion. I can see how the dbms can rewrite the expression for a named constraint to a named view, but regardless the constraint is simply part of the derivation of the view to update.

> At least, one
> view with input and output relation variables
>
> V*x=y
>
> and many constraints like this
>
> VC*x=DUM
>
> Next, I can hope handling equations involving views with a uniform method,
> while Date et.al. needs to a special rules involving constraints.

I am not sure what "special rules" you refer to. Do you refer to the inverse relational operations? Received on Tue Sep 09 2003 - 17:09:06 CEST

Original text of this message