Re: Possible problems with Date & McGoveran View Updating

"Alfredo Novoa" <alfredo_at_ncs.es> wrote in message news:e4330f45.0309080357.3a627b52_at_posting.google.com...
> "Bob Badour" <bbadour_at_golden.net> wrote in message
news:<YwM6b.656$iy5.61949065_at_mantis.golden.net>...
>
> > > You want to insert a relation in V = A union B and the relation value
> > > satisfies P(A) and P(B). D&McG rules say: yes the relation must be
> > > insterted in both relvars, but why in both?
> >
> > Symmetry.
>
> Symmetry is a principle of beauty, but not a principle of logic :-)

http://dictionary.reference.com/search?q=symmetry

symmetry

n 1: (mathematics) an attribute of a shape; exact correspondence of form on opposite sides of a dividing line or plane [syn: symmetricalness, correspondence, balance] [ant: asymmetry] 2: balance among the parts of something [syn: proportion] [ant: disproportion]

> > > No reasons are given. If
> > > you insert the relation in only in one relvar the view is updated
> > > correctly.
> >
> > And if you insert the tuple(s) in both relvars, the view is also updated
> > correctly.
>
> 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.

> > > It seems an arbitrary rule to me, and it causes strange
> > > behaviours that they tried to fix with the now dropped Principle of
> > > Orthogonal Design. In my opinion the correct result is: the update is
> > > invalid because there is not a unique solution, the insert proposition
> > > is ambiguous.
> >
> > And this is any less arbitrary?
>
> 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

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

Choose the default if any exists; if no default exists, the insert is an error.

> > > var Dead real relvar { Name Char } key { Name };
> > > var Missing SameTypeAs( Dead ) key { Name };
> > > var DeadOrMissing virtual Dead union Missing;
> > >
> > > insert DeadOrMissing relation { tuple { Name 'John Doe' } };
> > >
> > > The DBMS can not deduce if Doe is dead, missing or both, therefore the
> > > update must be rejected.
> > >
> > > Imagine we drop the POOD and we follow D&McG rules. The DBMS would
> > > deduce that Doe is dead and missing, what is clearly an absurd
> > > specially if Doe is found alive later :-)
> >
> > If you do not declare all of your constraints to the dbms, the dbms
cannot
> > enforce them.
>
> I declared all my constraints, but probably the example was not very
> good.

No, you did not declare all of your constraints. You did not declare the mutual exclusion between dead and missing, which you later assumed by noting an absurdity.

> Imagine another example:
>
> You have two relvars Fat and Tall, with this type: relation { Name
> Char }
>
> Relvar Fat holds the relation of people we know they are fat and
> relvar Tall holds the relation of people we know they are tall.
>
> You don't know if they are views or base relvars.
>
> We create a view:
>
> FatOrTall virtual Fat union Tall;
>
> Imagine that a guy called Quixote is thin and tall, and a guy called
> Sancho Panza is fat and short.
>
> We try to insert a relation:
>
> insert FatOrTall
> relation { tuple { Name 'Quixote' },
> tuple { Name 'Sancho Panza' } };
>
> This operation means: Quixote and Sancho Panza are fat or tall. This
> is a true proposition.
>
> If we use the D&McG approach we would deduce that Quixote and Sancho
> Panza are fat AND tall, what is a false proposition.

How is your example a straw man? Let me count the ways:

1. You start with an objectively and principly bad design by ignoring POOD.
2. You assume the user has knowledge the user intentionally ignores.

If the user knows Quixote is tall, why doesn't the user insert the tuple into Tall?
If the user knows Sancho Panza is fat, why doesn't the user insert the tuple into Fat?

> If you make this query:
>
> Fat where Name = 'Quixote';
>
> The DBMS will lie to you saying that Quixote is fat.
>
> Is this reasonible?

No, the example is not reasonable. It is a straw man, but it burns beautifully.

> The POOD was created in order to elude problems like this, but it is
> only a patch. If the POOD falls, the D&McG view updating approach
> falls with it.

Even without POOD, your example assumes the user ignores available knowledge.

> Although this is an easy to solve flaw.

I agree. I can think of several ways to solve the flaw without changing the view updating rules. The easiest way is to assume the user acts on his or her knowledge. Received on Mon Sep 08 2003 - 14:55:19 CEST