Re: algebra equations for Reference and FD constraints


"paul c" <toledobythesea@xxxxxxxx> wrote in message
news:1JK5l.12656$701.981@xxxxxxxxxxxxxxx
Brian Selzer wrote:
"paul c" <toledobythesea@xxxxxxxx> wrote in message
news:lts4l.4362$hr3.935@xxxxxxxxxxxxxxx
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.


Codd wasn't being sloppy. It does not logically mean that time values are
involved: it means that the instantaneous state of the data bank at one
arbitrary point in time can be a different collection of relations than that
for the instantaneous state of the data bank at another arbitrary point in
time. There is no need to record the time value because it is irrelevant
and in some cases impossible to replicate: what is the case now is likely
not what was the case yesterday and is probably not what will be the case
tomorrow. If the database is supposed to reflect what is the case, then the
collection of relations that represents what is the case must be different
from the collection of relations that represented what was the case
yesterday and also from the collection of relations that will be the case
tomorrow. In order to house a representation of what is actually the case,
there must be a means for asserting which possible value for the database is
now the actual value--that is, which collection of relations represents what
is the case. That is the essence of database updates, which are definitely
outside the scope of the algebra and the calculus.

Suppose you have a database that is supposed to record the moves in a game
of chess. There are 20 possible initial moves for each player, and the set
of all possible subsequent moves depends upon the moves that have already
been played. For example, an initial e4 permits moves not only from the
pawns and knights, but also from the king's bishop and the queen. If black
responded to e4 with e5, then the move e4-e5 is no longer a possibility.
Now, at the start of the game, no moves have been played, so the relation
for recording moves starts out empty. Once a move is played, how can the
database reflect that fact unless there is some means to assert that fact?
Database updates are indeed a relational model concept even though neither
the algebra nor the calculus are sufficient to express them..

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

(quote)

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.

I don't agree with Date's characterization, nor with his conception that a
database is a collection of relvars. There are several reasons, not the
least of which is that its intended interpretation relies upon the false
assumption that key values rigidly designate individuals in the universe of
discourse, but most importantly it is that Date asserts that relational
assignment is a primitve operation when it is clear that information is lost
when UPDATE is translated into assignment. Using the primitives insert,
update and delete, it is possible to describe completely--down to the
attribute value--what is different between successive databases. Relational
assignment relies upon the false assumption that a key value in one database
can be used to identify an individual represented by the same key value in
another database. The assumption is false, and it is relevant to this
discussion because each possible database corresponds to a proposition but
only one of those propositions is supposed to be true at any instant. When
a different possible database is asserted to be the actual database--that
is, when the database is updated, the proposition that corresponds to the
database that has been the actual database is supposed to be false while the
proposition that corresponds to the database that is becoming the actual
database is supposed to be true. So if a proposition is supposed to be
false, then how can it be relied upon. It is therefore not logical to
assume that a tuple with a particular set of attribute values that appears
in both a possible database and the actual database maps to the same
individuals in the universe of discourse.



.

Relevant Pages

  • Re: A different definition of MINUS, Part 3
    ... can actually be the value of the database at any set point in time. ... updates, on the other hand, assert which possible value for the ... neither the algebra nor the calculus are sufficient when it comes to ... To extend the analogy to view updates, we also have an input delta ...
    (comp.databases.theory)
  • Re: too much OOP ?
    ... backing up 4GL is relational algebra. ... "relational people" did it in a 3GL with an elaborated types system then it ... Also don't forget that there is no market of languages. ... Or should they use some other kind of database? ...
    (comp.object)
  • Re: a union is always a join!
    ... algebra, while necessary for describing database updates, is not ... database, not two successive databases. ... is not presupposed by either the relational calculus or the relational ... 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. ...
    (comp.databases.theory)
  • Re: A different definition of MINUS, Part 3
    ... can actually be the value of the database at any set point in time. ... Algebraic expressions derive information from the actual value of the ... neither the algebra nor the calculus are sufficient when it comes to ... database updates. ...
    (comp.databases.theory)
  • Re: A different definition of MINUS, Part 3
    ... Y', we would have a serious contradiction in the algebra, so R' IS ... Regardless of how many possible values there can be for a database, ... calculus are therefore limited in their utility to answering queries from ... recalculated once the assignment has been made. ...
    (comp.databases.theory)