Re: more on delete from join

On Aug 26, 1:35 pm, Kevin Kirkpatrick <kvnkrkpt..._at_gmail.com> wrote:
> On Aug 26, 12:40 pm, paul c <toledobythe..._at_oohay.ac> wrote:
>
>
>
>
>
> > Kevin Kirkpatrick wrote:
>
> > ...
>
> > > By the narrowest interpretation of RT, shouldn't the whole "view
> > > update" problem just be tossed out once and for all?  Tuples in base
> > > relvars represent business meaningful propositions, and tuples in
> > > virtural relvars represent business meaningful conclusions drawn from
> > > base relvar propositions.    As such, view updates amount to letting
> > > end-users assert conclusions and having the DBMS make "educated
> > > guesses" at the appropriate modifications to business meaningful
> > > propositions such that those conclusions will be reached.  Seems
> > > inherently mystical to me.
> > > ...
>
> > Insert to a base relvar represents a conclusion: R =: R UNION A conludes
> > R AND A.
>
> Sorry, I can't make sense of what you've written here.  The statement
> "R =: R UNION A" is an assignment statement; hence it "assigns" - it
> does not "conclude".  From a end-user level, it asserts the truth
> value of the predicate represented by relvar R for all tuples in
> already in relvar R and all tuples in relation A.  Certainly, once
> this has been asserted, a query run against relation R should conclude
> that the predicate represented by R holds for all tuples that had been
> in R and all tuples that had been in A.
>
> I'm not sure how to make this more clear: A view is a named query, and
> a query is a set of conclusions drawn from the propositions stored in
> the database.  What does it mean to assign tuples to a view?  I mean,
> if a view is defined as
>
> HIGH_PAYED_EMPS := EMPS where SAL > 50000
>
> and John Doe makes $50001, can his boss reduce his salary by deleting
> him from HIGH_PAYED_EMPS?  Why not?  What principle would be violated
> if the DBMS received:
>
> DELETE FROM HIGH_PAYED_EMPS WHERE ENAME = 'JOHN DOE';
>
> and issued the following update:
>
> UPDATE EMPS SET SAL = 50000 WHERE ENAME = 'JOHN DOE';
>
> After all, the plain language meaning of "DELETE FROM HIGH_PAYED_EMPS
> WHERE ENAME = 'JOHN DOE'" is the simple assertion "John Doe is not a
> high paid employee."  Reading anything more into it is "educated
> guessing", and any actions taken on that basis is "mysticism".  That's
> what I mean when I say the whole notion of allowing database users to
> assert *conclusions* by updating named queries, rather than limiting
> them to asserting/denying propositions that conform to predicates of
> the underlying data model, should be disposed of.- Hide quoted text -
>
> - Show quoted text -

First, apologies for the PAID/PAYED mis-spelling. Incredible what slips past ones notice until after a message is published.

And a quick addendum: To draw contrast to my example, it's plausible that a universe of discourse might have no concern for the salary of most individuals, yet be concerned with a predicate "Employee <ENAME> is a high-paid employee with salary <SAL>". Such a predicate might map to a base relvar HIGH_PAID_EMPS {ENAME, SAL}, perhaps having a constraint SAL > 50000. In this context,

DELETE FROM HIGH_PAID_EMPS WHERE ENAME = 'JOHN DOE'; is a clearcut, unambiguous, and obviously acceptable negation of a set of *propositions* that conform to the data model, rather than a negation of some set of *conclusions*. Hopefully this further clarifies the categorical distinction I see between a table update and a view update. Received on Wed Aug 26 2009 - 21:02:31 CEST