Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Possible problems with Date & McGoveran View Updating

Re: Possible problems with Date & McGoveran View Updating

From: Mikito Harakiri <mikharakiri_at_ywho.com>
Date: Tue, 9 Sep 2003 10:46:40 -0700
Message-ID: <uuo7b.23$oA5.210@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?

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

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

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

> 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. Received on Tue Sep 09 2003 - 12:46:40 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US