Re: a union is always a join!
Date: Mon, 16 Mar 2009 16:14:24 GMT
Message-ID: <AVuvl.18343$PH1.16792_at_edtnps82>
Walter Mitty wrote:
> "Brian Selzer" <brian_at_selzer-software.com> wrote in message
> news:pi_rl.24249$ZP4.5099_at_nlpi067.nbdc.sbc.com...
>
>> My point has little if anything at all to do with transactions and >> concurrency control. Those belong to implementations. My point is that >> relational calculus, or any equivalent mechanism such as relational >> algebra, while necessary for describing database updates, is not >> sufficient for that purpose because it can only apply to a single >> database, not two successive databases. The mechanism of updating the >> database cannot be reduced to mere algebraic expressions, but instead to >> asserting, in the context of what has been the case, just what in the >> world is different and exactly how. Let me explain.
>
> I finally figured out that this is where the discussion branched off into
> what some of us consider mysticism.
>
> I disagree with the last sentence. In particular, the phrase "just what in
> the world is different" implies, if I read it correctly, that a database
> update has to be mapped into a "real world update". However, this mapping
> is not presupposed by either the relational calculus or the relational
> algebra. A database update is simply the difference between the ex ante
> state of the database and the ex post state of the database. It is not an
> assertion about what in the world is different, except in the eye of the
> beholder.
>
> The mathematics of relational calculus and relational algebra are fully
> capable, AFAIK, of describing the difference between two states of a
> database.
>
If the algebra isn't capable of that, the RM is in trouble! (Heh, I could predict in advance one mystic response, ie., there could be many possible such 'differences', but as I might've hinted, I don't think the mystics are really talking about the RM, though at least the late lamented Dawn had the grace to state her PICK bias up-front.)
Regarding transactions and concurrency control 'belonging' to implementations, it is more that most people are blinded by past practice, failing to see that Codd's 'keys' might offer a theoretical way to describe those aspects. Maybe if those same people asked what are the requirements for transactions and concurrency from an application viewpoint, they would see their way to a more logical, verifiable basis for implementations. Eg., what is the difference between an application data model in a single-user system versus in a multi-user system? I guess that most people think none but my attitude is that this is myopic, which rhymes with mystic. Can't count how many requirements meetings I went to where nobody wanted to talk about concurrency models, usually they just tossed around various porridge phrases like isolation levels and picked the first one that sounded presentable to the ignorami. Received on Mon Mar 16 2009 - 17:14:24 CET