Re: more on delete from join

From: paul c <toledobythesea_at_oohay.ac>
Date: Sat, 29 Aug 2009 00:00:04 GMT
Message-ID: <8c_lm.43014$PH1.35301_at_edtnps82>


Kevin Kirkpatrick wrote:
...
> My point, phrased another way, is: given base relvars A, B, and C with
> identical headings, this does not make sense:
>
> (A UNION B) := (B UNION C)
>
> in the exact same way that this does not make sense:
>
> int x, y;
> x+y := 3;
> ...

Even though I like JOIN as an easier problem to see through, these are good examples because they cut away all the sql fluff. First, "does it make sense?" is a question people often ask without context. Let me give it a context: "does it make sense in a chosen logic?", which also means, I think equivalently, does it make the logic inconsistent or lead to contradictions?

I've heard lots of people say the rm is based on logic because logic is "good" which is also nebulous. We must ask what is the purpose of basing an implementation on a formal logic. I would say there are two reasons which are practical ones, not mystical ones: 1) so we can ask does a result make sense in the sense that it obeys or doesn't violate the logic (usually much easier than referencing code let alone the sql spec', and 2) so that we can use logical optimization techniques in the construction of an implementation.

I would ask anybody who thinks those assignments don't make sense to show an inconsistency or contradiction in assigning B UNION C to A and B UNION C to B or 3 to x and 0 to y. If these assignments were equations, the left-hand-side would equal the right-hand-side and in the relational algebra example, both sides would be interpreted as 'true'. In both cases, the result obeys the assignment but perhaps there are some unwritten constraints that make the results contrary to the system users' expectations. You could say that these results "don't make sense" because it is a system requirement that all recording forms, such as tables or integer variables must be able to record values for all possible truth combinations. One might say that neither a single relation nor the programming variables allow that, in which case one should admit the system requirement that all possible true values must be representable. Or you might say that it's because of a cultural attachment to certain programming styles. But if those are their reasons, people should say so, and not hint that the result doesn't make sense according to the logic. Whether I would want an arithmetic system to treat integers this way is one question but as for the relations, show me the logical inconsistency or contradiction, eg., if A AND B is true, so are A AND NOT B and NOT A AND B, what's the problem, really?

If one feels that these results are just somehow too distasteful, one could devise a language that stored all integers in infinite arrays or one could invent a version of the RM where results could be multiple relations, both of which have big practical problems and I don't see the practical need. I don't see any inconsistency in assigning non-loss projections of a relation to the operands of join or union because I don't see any violation of predicate logic by doing so. Maybe the result should be more accurately called relational logic. (Inserting to projection is a different problem because it involves predicates that aren't mutually implied.)

As far as updating in the RM is concerned, it is a matter of excising all unstated requirements and possibilities that the chosen algebra doesn't allow, aka mysticism. The essential fact here is that every relation logically implies the truth of its non-loss projections and their conjunction. This should be patent to anybody who's played with the algebra, so I think it is not mysticism. Doesn't matter whether it's base or view. I started this thread to examine not the possibility of updating but the implications of updating to both, should have known better than to expect no objections, but some of those are still useful to me for helping to clarify my thoughts.

It is remarkable that there are people who advocate nulls as a value sometimes and not a value other times, such as many sql implementers, at the same time as they suggest there is some logical problem with certain view updates. I believe even Codd fell into this trap. I reconcile this simply because it shows even the most learned people can't be right all the time. Received on Sat Aug 29 2009 - 02:00:04 CEST

Original text of this message