Re: algebra equations for Reference and FD constraints

From: paul c <>
Date: Sun, 28 Dec 2008 04:58:48 -0800
Message-ID: <1JK5l.12656$701.981_at_newsfe12.iad>

Brian Selzer wrote:

> "paul c" <> wrote in message 
> news:lts4l.4362$hr3.935_at_newsfe01.iad...

>> Brian Selzer wrote:
>> ...
>>> Second, this does not dispel the claim that there are some 'model'
>>> concepts that can't be expressed with the algebra or calculus. In
>>> particular, database updates cannot be expressed. To be sure, a value
>>> that is to be assigned can, but the update itself--the actual
>>> assignment--cannot. Nor should it.
>> "update" is not a relational model concept nor is "assignment". They are
>> both programming language concepts and are not necessarily present
>> depending on the language, eg., some languages don't need assignment. Same
>> goes for variables, aka pointers. Imputing any of these concepts to the
>> relational model is making the same illogical mistake as criticizing the
>> RM because of flaws in the SQL language. The mistake originates with the
>> false assumption that a dbms implementation that may have been partly
>> inspired by Codd's original model can somehow introduce or retro-fit
>> concepts to that model, that he never ascribed to it. The mistake is
>> mysticism at its finest. Whereas I would say that if one can't express a
>> concept with either an algebra or calculus, then the concept is not a
>> 'model' concept in the first place.
> The Relational Model as Codd defined it involves what he called 
> 'time-varying relations.'  These are not the static relations that are the 
> result of algebraic expressions--though their values at any particular point 
> in time are.  Your statement that neither 'update' nor 'assignment' are 
> relational model concepts is patently absurd, for how can a relation vary 
> with time unless there is some form of update or assignment involved.
> <snipped irrelevant references to SQL>

I think this was one of the rare times when Codd was being sloppy. Taking the phrase at face value can only logically mean that time values are involved in such a relation (some people use the term but that's when they are talking about temporal db's). Assuming such a thing is possible without time attributes is a symptom of one or more of: 1) playing with words, 2) being willfully shallow, 3) being afflicted with dyslexia.

Here is what Date had to say about the phrase some years ago:


Codd then goes on to define a "data bank" (which we would now more usually call a database, of course) to be "a collection of time-varying relations ... of assorted degrees," and states that "each [such] relation may be subject to insertion of additional n-tuples, deletion of existing ones, and alteration of components of any of its existing n-tuples." Here, unfortunately, we run smack into the historical confusion between relation values and relation variables. In mathematics (and indeed in Codd's own definition), a relation is simply a value, and there's just no way it can vary over time; there's no such thing as a "time-varying relation." But we can certainly have variables -- relation variables, that is -- whose values are relations (different values at different times), and that's really what Codd's "time-varying relations" are.

A failure to distinguish adequately between these two distinct concepts has been another rich source of subsequent confusion. For this reason, I would have preferred to couch the discussions in the remainder of this series of columns in terms of relation values and variables explicitly, rather than in terms of just relations -- time-varying or otherwise. Unfortunately, however, this type of approach turned out to involve too much rewriting and (worse) restructuring of the material I needed to quote and examine from Codd's own papers, so I reluctantly decided to drop the idea. I seriously hope no further confusions arise from that decision!

(end quote)

I suspect SQL is quite relevant because a shallow reading of Codd is certainly a plausible cause of some of its errors. Received on Sun Dec 28 2008 - 13:58:48 CET

Original text of this message