From: PC

To: Editor

 

Saw your latest and once again I think you have hit one of the many protruding nails on the head.  Understanding one's data is so central and so crucial and yet so often ignored.

 

All this talk (not from you, I note) of silver bullets. Nothing new and I wonder if the paying customers and the big-ticket so-called technology strategy companies will ever wise up. Edward de Bono wrote of 'porridge words' that distract thought from the matter at hand. When used sparingly, they can facilitate new lines of thought but when, as they are in this field, they are used so casually and often they blur the real issues. All this technicalese of XML etcetera has this effect on me.

 

During one of the few times an employer allowed me to help people with logical design, I was having difficulty because the customer's IT staff knew very little English and had perhaps even less database background. I hit on the idea of explaining tables as relations and relations as sentences - sentences that must have the same 'size and shape'. Their faces seemed to light up and when they agreed that they had overloaded some of their tables, I was very pleased with myself.  I felt vindicated a few weeks later when I read an article about predicates and propositions, which put these thoughts much more precisely than I could, that Hugh Darwen had written in the now defunct DBPD magazine. Of course, the changes created new problems because the database product, like so many others, gave precious few ways to map the logical design to the physical one. But I regarded these as preferable problems since the staff was much more interested in the more concrete physical optimization techniques.

 

Without any disrespect to Dr. Codd (who I once met but was too awe-struck to ask any questions of), I have often thought that the language used by everybody in the field, with words such as "tables", nearly always brings connotations of physical arrangements to the mind of anybody who has done traditional programming. This seems unfortunate to me. Especially after I read Mr. McGoveran's proposals for results that might embody more than one table. (I wonder if these might not be part of the key for much better physical integration of databases with their visualization for users, not to mention smarter engines.)

 

I came across a site the other day, http://www.mcjones.org, where a bunch of the System R people reminisced about its development on the occasion of, I think, the 25th anniversary of one of Codd's early papers. Presumably Mr. Date was absent from this gathering so that he could write his own most interesting history, which I remember reading five or six years ago. Anyway, I was struck again by how often their design decisions were either determined or distorted by physical considerations. And now, when many of the obstacles have been overcome courtesy of Moore's and other laws, some of those clever people seem regretful.

 

Also, please let me submit an historical, non-technical 'nit' to Mr. Date - I remember him writing that Codd did not coin the database term 'normalization of relations' as a result of R.M. Nixon's foreign policy excursion with China. But I also remember reading what I recall was an original interview with Dr. Codd in the DBMS magazine where he stated that this was the case. It's not really important, perhaps I'm just sensitive to it because I live in a country that established relations with modern China a year earlier!

 

 

Fabian Pascal Responds: Using complicated or pompous language in the absence of substance is an old trick to impress the uninformed. The blame for lack of fundamental knowledge and the “server bullet" approach is on the culture of this society. It is anti-intellectual and counts on lack of adequate education to push all sorts of silver bullets.

 

Explaining the relational model is not Codd's forte, but his contribution is major enough that he should be forgiven for that (although it would have helped the model had he been better at it). To his credit, however, he introduced the term relation and tuple precisely in order to distinguish them from the physical file and record concepts used in the industry. I am not sure that he used the term table, but I believe that the simplicity of and universal familiarity with tables is too useful to give up, so I am prefixing the term with an R, or use relational tables, to express that they are a special kind of tables, and purely logical in character [Ed. Note: Date and Darwen introduced the more precise term relvar (relation variable) in recognition of the fact that relations change over time and, therefore, are variables. In this context, R-tables would be snapshots of relvars at given points in time.)

 

 

Posted: 09/13/02

 

 

 

[ABOUT] [QUOTES] [LINKS]