Re: Possible problems with Date & McGoveran View Updating

"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 :-)

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

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

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

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.

If you make this query:

Fat where Name = 'Quixote';

The DBMS will lie to you saying that Quixote is fat.

Is this reasonible?

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.

Although this is an easy to solve flaw.  

Regards
  Alfredo Received on Mon Sep 08 2003 - 13:57:23 CEST