Re: a union is always a join!

From: paul c <toledobythesea_at_oohay.ac>
Date: Mon, 09 Mar 2009 00:17:11 GMT
Message-ID: <beZsl.15959$Db2.2243_at_edtnps83>


Walter Mitty wrote:

> ... I'm also going to suggest that what
> Brain S. calls "oversimplification" is almost exactly what others call
> "abstraction". I'm also going to suggest that without abstraction you don't
> get any independence, and without independence, you don't get much of any
> bang for the buck. That may be of zero theoretical importance, but it's of
> interest to me.
> ...

Walter, I'm with the many people who think phyaical and logical independence are of high importance, both theoretically and practically. But I'd say many of the nuances and implications of those haven't been explored much in print. Brain S as you call him regularly enters the realm of mysticism. I point this out not to correct him, but to warn newcomers here that he is not exactly swimming in the main stream of relational theory (to be fair, not many are, because the theory is often confused with past practice). I have a number of mystic acquaintances and I like them all, partly because they don't involve themselves in db theory and there is much in life for which mysticism offers the only comfortable clues.

But here we must remember one of Codd's first precepts - all meaning in an rdb is expressed through the values of attributes of relations.   With care in their expression, some constraints can stand in effect (eg. intensions) for such relations, but many programmers who come to this field are incapable of removing their past experience from the topic, which is one of the reasons we see the word 'interpretation' mentioned so often here (basically what Edward de Bono called a porridge word). It seems that Brian S doesn't want to use attributes to express time values or state successions. I doubt if Codd would have gone along with that (but being smarter than I he wouldn't have bothered arguing about it either).

...
>
> I'm afraid this is over my head. I appreciate the fact that you don't talk
> down to me, and I'm not asking you to change that. But I need some
> intermediate steps in the above chain of reasoning, simply due to my own
> ignorance. I got the part about non closure under division. I didn't get
> the connection between updating views and closure under union.
> ...

If I can understand it, it can't be very deep. There used to be many posters here who could think better than I but most of them seem to have gone away. If we can't insert to all possible unions, then sooner or later some expression will be interrupted by an exception. Big names like Darwen and Date don't need to worry about this much because of their choice of implementation language style. But imagine a language that implicitly asserts what we think of as persistent updates in the course of making queries. Such a language would be impossible because nested expressions could fail at any time depending on data. So I say a more universal definition of an rdb needs to avoid the possibility of some (single) relations being thought of as conjuntions of disjunctions. Much better to think of them as conjunctions of simple propositions. But I warn you - this is coming from somebody who doesn't even think persistence is necessary to have a relational engine!

(Brian S's association P V ^P with deletion is a bizarre example of mixing up programming operators with db values and with formal language definitions/operators.)

When it comes to assuming logical independence when inserting to union, I think it's enough to imagine relations A, B and C, where C is a union of A and B. Then allow any of the three to be base (aka 'real') and any of the three to be a view (aka 'virtual'), then ask whether there is only one way to update one of the three so that no matter what, a user ignorant of the 'independent' qualities of tables will see the same result.

> Closure under negation is problematic. For finite data sets, we can define
> closure in a finite way. But our definition loses clarity when we try to
> extrapolate from finite sets to infinite sets. Now most of us, when we
> think about the data in a database, are content to think of this data as
> being "a finite subset of an infinite reality". We usually call this subset
> the "universe of discourse". There may be logical contradictions here, but I
> don't detect them at my low level of thinking. But when you do negation,
> the question of whether the universe of discourse is finite or infinite
> becomes consequential.
>

Infinity is not a problem because when we implement on a digital machine, all stored values are finite. It's true that materializing some negations is intractable. This is where an algebraic foundation rather than a programming or mystical foundation for definitions comes to our aid. But people who talk of infinity here might as well talk about the effect of gravitons on dbs, for all it matters. Received on Mon Mar 09 2009 - 01:17:11 CET

Original text of this message