Re: delete from join

From: paul c <toledobythesea_at_oohay.ac>
Date: Mon, 07 Sep 2009 17:33:33 GMT
Message-ID: <Ntbpm.44109$PH1.8619_at_edtnps82>


Walter Mitty wrote:
...
>
> Insert to projection is indeed underconstrained, provided the projection is
> non trivial.
>
> When you insert into a projection, this means adding tuples to the relvar on
> which the projection is based. If there are attributes in the base relvar
> that are not present in the projection, then those attributes remain
> unspecified by the insert into the projection. They become "missing data"
> in the resulting tuples. That's underconstrained.

This is just re-phrasing Scott's logical argument.

More accurate to say it's undefined (in the typical dbms). Undefined because the resulting header of an assignment of a projection is typically not specified unless a relvar with the projected heading is recorded (Vadim also said this). Whereas insert to projection and delete from join are defined, just not treated as possible by most dbms' because the result form excludes all possible true combinations.

We really need to ask what is the purpose of the logical foundation. I say it is to i) unambigously predict resulting extension values without reading code and 2) use logical theorems to optimize the physical implementation. To accomplish this, all that's required is to use different language definitions, eg., don't use C' = C MINUS D to define delete nor D' = C UNION I to define insert, Different definitions for delete and insert don't deny logical axioms at all and those axioms can still be used for both of the above purposes. If one likes, one could call those new definitions constrained.

In other words, logic is applied to the definitions of a language's verbs by a dbms to obtain recordable extensions. This is quite different from a dbms that duplicates logical statements. I'd say it is the essential difference between the typical commercial dbms and the logic-based AI systems. Application and duplication are two different purposes. A language designer needs to choose which purpose. It seems most sql designers ignore the question and pretend to do both

Whereas inserting to projection isn't amenable to constraining the definition of the assignment, rather that would need expanding the result in a form that allows an expanded interpretation without requiring the explicit specification of allowable headers. I think some people call such a form a 'multi-relation', which is neither a table nor a relvar as we know them, but I'm not sure if they all have the same form in mind,

(They aren't alone. I think the almost pathological introduction of insert to union or insert to projection here when the topic is delete is symptomatic of a general inability to separate questions and focus on a dbms' purpose. Once a dbms designer chooses a suitable delete from join definition, the next thing he needs to check is what that means to his delete operator in general.) Received on Mon Sep 07 2009 - 19:33:33 CEST

Original text of this message