Re: Possible problems with Date & McGoveran View Updating

"Mikito Harakiri" <mikharakiri_at_ywho.com> wrote in message news:uuo7b.23$oA5.210_at_news.oracle.com...
> "Bob Badour" <bbadour_at_golden.net> wrote in message
> news:qen7b.776$v02.72328255_at_mantis.golden.net...
> > I suggest that your clarification was too cryptic. I don't recall seeing
> how
> > systematic defaults are not general enough to resolve ambiguities.
>
> View transformation can't be inverted because some information is missing.
A
> user can supply that missing info multiple ways. For example, he might
know
> the view update effect on some other view (which can even be an existing
> view on the system). Why insist on defaults if a user can find alternative
> ways more convenient?

I question the assumption of convenience. In the case of an insert to a project view, how would one resolve the ambiguiety without default values? Can one express the equivalent as a constraint where a constraint is a transformation that equates to a constant?

> > > The system must just reject any attempt updating ambiguous system of
> > views.
> >
> > Default values can resolve ambiguieties.
>
> You can do only that much with defaults! We are speaking equations, and
> defaults might find an easy way to make user system of equations
> inconsistent.

True. In some cases, one might desire inconsistency. Thus an insert to one project view might populate an attribute with one value while an insert to another project view might populate the same attribute with a different value.

> > > 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.
>
> You jumped to the conclusion too quickly.
>
> More important at this time is that I don't have a method of view
> transformation inversion.

Yes, that would present a problem.

> > > 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.
>
> It's all boils down to equations anyway. Equations can be freely
manipulated
> and rewritten according to algebraic laws.

Absolutely.

> > I am not sure what "special rules" you refer to. Do you refer to the
> inverse
> > relational operations?
>
> I'm taking my statement back.
>
> In math they spent much more time researching what the conditions for
> equation roots existence & uniqueness are, as opposed to developing
methods
> for solving them. Date's view update theory doesn't bother with analysis,
> and jumps to the methods right away. That is a little bit suspicious.

Fair enough. Received on Wed Sep 10 2003 - 14:06:38 CEST