Re: a union is always a join!
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
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
> 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.
> ...
...
>
> 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