Re: Possible problems with Date & McGoveran View Updating

"Bob Badour" <bbadour_at_golden.net> wrote in message news:<Ia07b.686$wf7.65737782_at_mantis.golden.net>...

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

This is not a principle of logic.

The common sense principle of prudence (don't make assumptions without enough information), has more priority than the principles of beauty :-)

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

I agree with Mikito here. Any decision is an arbitrary assumption. You are stating as true, things you can't know if they are really true.

To deduce (A and B) from (A or B) is not good logic.

(Don't you consider suspicious that the rules for unions and intersections are identical?)

> > var x real relvar { a Integer, b Integer} key { a, b };
> > var vx virtual x { b };
 

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

Correct. The insert in an error because we don't have information enough in order to deduce an unique solution.

Why don't apply this principle always?. It is sufficient for any kind of view update.

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

Mutual exclusion simply doesn't exist. I wached on today's news the funeral for a mising fireman, and funerals are for dead people. But I don't want to waste time discussing if you can be dead and missing, that's why I made a clearer example where mutual exclusion evidently doesn't exist.  

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

Ignoring POOD does not mean bad design. Darwen is ignoring the POOD too:

http://www.hughdarwen.freeola.com/TheThirdManifesto.web/Missing-info-without-nulls.pdf

He explicitly prefers a design which violates the POOD.

However, you don't know if I am violating the POOD because I said you don't know if the Tall and Fat relvars are base or virtual relvars. They migth be virtual relvars derived from one base relvar which respects the POOD.

var People real relation { Name Char, Feature Char } key { Name, Feature };
var Tall virtual (People where Feature = 'Tall') { Name }; var Fat virtual (People where Feature = 'Fat') { Name }; var FatOrTall virtual Fat union Tall;

grant select, insert, update, delete on FatOrTall to 'Alfredo';

insert FatOrTall relation { tuple { Name 'John' } };

The POOD is not sufficient in order to avoid the strange behaviors detected by D&McG, because it only applies to base relvars.

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

I never said he knows that, and the Fat and Tall relvars may be hidden to the user by the security mechanism.

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

Here is some water :-)

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

And if we find a better way changing the rules, why don't use it?

Regards
  Alfredo Received on Tue Sep 09 2003 - 23:40:30 CEST