Re: algebra equations for Reference and FD constraints

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.

I believe the SQL standard does not mention the word 'relation', only tables. Correct me I'm wrong but I think it talks of 'updating tables'.   Whenever people talk of a model that 'updates tables', they might be talking about some 'SQL model' but they are not talking about any 'relational model' that I've ever heard of.

I suspect Codd used the word 'update' only to give his ideas some familiar link to the sloppy terminology that was in wide play more than thirty years ago and seems to persist, eg., 'file updating'. The verb 'replace' seems closer to the actual effect of such languages, but even that word is imperfect unless a dbms language formally specifies its algebraic equivalent. 'Substitute' might be a word that is closer to the phenomenon of algebraic symbol manipulation.

Vadim recently quoted some Oracle documentation or other:

    *The DML statement must affect only one table underlying the join.      *For an INSERT statement, the view must not be created WITH CHECK OPTION, and all columns into which values are inserted must come from a key-preserved table. A key-preserved table is one for which every primary key or unique key value in the base table is also unique in the join view.

     *For an UPDATE statement, all columns updated must be extracted from a key-preserved table. If the view was created WITH CHECK OPTION, then join columns and columns taken from tables that are referenced more than once in the view must be shielded from UPDATE.

Good god, try to count all the concepts those few lines introduce, updating columns (presumably updating a column is not the same as updating a table), key preservation (presumably keys can come and go), column extraction (presumably columns could be inserted too), underlying tables (presumably underlying and base are two different concepts), "only one table", "referenced more than once", blah, blah. It looks very much like a specification that was written AFTER the implementation was written! Received on Wed Dec 24 2008 - 16:24:04 CET