Re: Possible problems with Date & McGoveran View Updating

"Mikito Harakiri" <mikharakiri_at_ywho.com> wrote in message news:Uj47b.22$741.237_at_news.oracle.com...
>
> "Bob Badour" <bbadour_at_golden.net> wrote in message
> news:Ia07b.686$wf7.65737782_at_mantis.golden.net...
> > "Alfredo Novoa" <alfredo_at_ncs.es> wrote in message
> > news:e4330f45.0309080357.3a627b52_at_posting.google.com...
> > > Of course, but the DBMS does not have enough information in order to
> > > decide which is the true solution.
> >
> > If it inserts the tuple into only one relvar, it must decide which. If
it
> > inserts the tuple into both relvars, it eliminates an arbitrary decision
> > while preserving important mathematical properties.
>
> In language of view equations that translates into an equation
>
> Ax=b
>
> having more than one solution.

I am not certain what you mean. Are you saying that in the case of ignoring symmetry and arbitrarily deciding to insert to only one base relvar there is more than one solution? Or are you comparing the entire situation to an equation with multiple roots?

> > > Yes, it is. If a problem is undecidable it is better to say "the
> > > problem is undecidable" rather than inventing a possible false result
> > > without any warning.
> >
> > It is not undecidable. The only way it can create a false result without
> > warning is if the designer omitted an important integrity constraint. If
> the
> > designer completes his job, the problem goes away.
> >
> > See principle #4 at: http://www.dbdebunk.com/page/page/622150.htm
>
> There is a clear method of making equation solution unique: add more
> equations!

I assume you are agreeing with my suggestion to declare the constraints.

> > > It is even clearer with project views;
> > >
> > > var x real relvar { a Integer, b Integer} key { a, b };
> > > var vx virtual x { b };
> > >
> > > insert into vx relation { tuple { b 1 } };
> > >
> > > We can deduce infinite possible solutions. Which solution should we
> > > choose? All?
>
> Given
>
> table X (
> a integer,
> b integer
> )
>
> the view
>
> view A as
> select a from X
>
> is not updateable, since the equation
>
> Ax=y
>
> has nonunique solution no matter what value relation y has. If we throw in
> more equations, for example
>
> view A1 as
> select b from X
>
> then, the view that combines A and A1 together is updateable.
>
> Constraints are views that evaluate to constants, they could be added to
> disambiguate the original view the same way as the "normal" views.

Suppose we extend the syntax for view definition to allow systematic default values:

view A as
select a from X
default X set b = 0 on insert to A

> All these ideas are parallel to equations solving in algebra. Given 2
> variables x1 and x2, the equation
>
> x1 = y1
>
> doesn't have unique solution since x2 can be chosen arbitrarily. However,
if
> we add
>
> x2 = y2
>
> then our system of equation has unique solution (no matter what values
> variables y1 and y2 have). Alternatively, we can add a constraint
>
> x2 = 0
>
> which disambiguates our system of equations as well.

The constraint method basically restates POOD. Or alternatively, POOD states a good design has sufficient constraints declared to disambiguate the systems of equations.

The default value method constrains specific operations without constraining the base relvars. Received on Tue Sep 09 2003 - 01:13:00 CEST