Re: Possible problems with Date & McGoveran View Updating

"Alfredo Novoa" <alfredo_at_ncs.es> wrote in message news:e4330f45.0309091340.49a978d3_at_posting.google.com...
> "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.

I don't necessarily agree with you. I see it as an issue that relates to the properties of operators like distributivity, commutativity, associativity etc.

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

This boils down to the closed world assumption, which is widely accepted in database management.

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

Yes, the dbms can know. If they can not be true, the dba can declare a constraint that resolves the issue one way or the other. If the dbms applies the closed world assumption to constraints, it must insert the tuple into both base relvars unless it has a constraint that tells it otherwise.

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

They are not identical. The treatment of predicates differs.

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

They always apply when it applies. It does not apply to union.

> It is sufficient for any kind
> of view update.

And any view update may affect multiple base relvars.

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

This partially addresses one of the two ways your argument is a straw man. Applying POOD would still resolve the issue without ambiguity, and you continue to assume the user inserts to DeadOrMissing knowing which it really is.

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

In this case, it clearly does.

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

Yes. However, he does not assume a design that evaluates the union of SALARY_UNK and UNSALARIED nor does he assume a user who inserts to this union instead of the more specific relvar. Even if such a union view existed and even if the user inserted to the union view, his distributed key would guarantee the error you desire.

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

I agree that POOD does not suffice to prevent the issue -- at least, as far as I understand POOD. POOD applies to all relvars; however, each of the four relvars has a unique predicate. I think you are persuading me to your point of view, but I wonder whether some other design principle might resolve the issue.

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

I would suggest in this case that it was unwise of the dba to grant update rights to this relvar given the problem you identify.

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

I wonder whether this is something a dba can resolve under the covers by specifying whether to insert to both or to reject the update as ambiguous. Received on Wed Sep 10 2003 - 05:01:21 CEST