Dr Codd
Dr Codd
Dr. E(dger). F. "Ted" Codd is one of the great names in computing. Recipient of 1981 TuringAward. He is often called the Father of RelationalDatabases.
http://www.wikipedia.org/wiki/Edgar_F._Codd
His classic paper describing the relational model is here: http://www.acm.org/classics/nov95/
Dr. Codd died April 18th, 2003 http://www.bayarea.com/mld/mercurynews/news/5676110.htm
Dr. Codd was a researcher at InternationalBusinessMachines for many years. In 1969 he circulated an internal paper within IBM on an idea for improving databases by combining set theory, the concept of "tables" (called "relations" in some circles), and related mathematics. The idea was further developed and published in 1970 to become one of the greatest research papers in computer history. Colleagues at IBM and CalBerkeley experimented with his ideas and found that they simplified queries that were complex or too tied to the internal structures in other database paradigms. Contrary to popular belief, he did not "invent" the StructuredQueryLanguage, at least not in a syntactical sense. (Some consider SQL an imperfect relational language anyhow - SqlFlaws.)
Before relational, the predominant databases were NavigationalDatabases.
See "The Great Debate was a debate between proponents of the relational and network approaches. It was held at the ACM SIGMOD Workshop on Data Description, Access, and Control in 1974; the principal speakers were Edgar F. Codd for the relational approach (surprise!) and Charles W. Bachman for the network, or CODASYL, approach. In preparing for the debate, Codd wrote a paper entitled "Interactive Support for Nonprogrammers: The Relational and Network Approaches"1, and it's that paper that I want to discuss here." ChrisDate, http://www.intelligententerprise.com/db_area/archives/1999/991105/online2.jhtml
It is possible he is under-represented on the WikiWikiWeb because no one can figure out how to make a WikiName for him.
Some possibilities:
"DrCodd" seems to combine the respect he deserves with a easily remembered WikiName.
This was written on Sunday, May 4, 2003, two weeks after the passing on April 18, 2003 of Dr. E. F. Codd ("Ted" Codd), the "Father of the Relational Model" for very large data bases. I would like to dedicate this entry to Dr. Codd and his lovely wife, Sharon.
[This entry also appears at the ArtificialLife entry.]
It was about 1995 and I was on the phone with Dr. Codd, he in Florida at his home, and me in Mission Viejo, CA. I was telling him that Chris Langton would like to meet him. Chris had told me not long before then that Chris, in his research that led to "Artificial Life," had thoroughly digested Ted's doctoral thesis "CellularAutomata" and leveraged Dr. Codd's 8-state self-reproducing cellular automata ("machine" or "pattern") in creating Chris's own "machine." By the way, you can read some of this history in Mitch Waldrop's book "Complexity - The Emerging Science at the Edge of Order and Chaos" on pages 216-222. I related this story of Chris' to Dr. Codd and Ted asked me if I would like to hear the story of how he devised his eight-state cellular automata. I was all ears. So, Ted (if you're listening) and Sharon, here is that true story, as related to me over the phone by Ted.
Dr. Codd related that he and a fellow doctoral student were in a "pub" and the "lad was speaking rather reverently of JohnVonNeumann's 29-state machine." Ted, not one to let something like this slide by (Sharon, you know this wonderful trait so well), insisted he could beat that! Ted boldly said he could drastically reduce the number of required states and still produce the same results. His buddy replied in the negative. With the quick retort, "Yes, I can, I'll bet you I can!" the challenge demanded some sort of "formality." Dr. Codd said to me, "We were poor graduate students, what did we have of value to bet?" "How about a beer?" Ted chuckled over the phone. And, sure enough, shortly thereafter they returned to the "pub" and Ted presented his eight-state machine (8-state cellular automata).
Ted and I laughed over the fact that a "branch of science," artificial life, was borne from a bet over a beer.
I hope you have enjoyed this true story.
I had the honor of spending time with Dr. Codd and his wife Sharon at the 25th anniversary of the Relational Model in Boston, MA in 1994, where he graciously signed my copy (#242) of his book (edited by Sharon) specially published for that event. Thank you, Dr. Codd, for a life of giving that has made such a difference for just about every human on earth.
Gavin Gray (ggray2@earthlink.net), now in San Diego, CA. May 4, 2003.
No disrespect to the late great DrCodd, but the popular mythos that Langton invented the field of ArtificialLife is a great exaggeration, at best. He most certainly innovated in that field, and widely popularized it, and possibly coined the name, but didn't invent the field.
I happened to be reading the classic paper cited above and noticed the following challenge [edited for readability] in section 1.2.3 ...
Since, in general, it is not practical to develop application programs which test for all tree structuring permitted by the system, these programs fail when a change in structure becomes necessary. Systems which provide users with a network model of the data run into similar difficulties. The reader who is not convinced should develop sample programs for this simple problem. -- Codd
http://www.acm.org/classics/nov95/struct.html -- Codd's sample structures
No need to wonder, please take the ManyToManyChallenge, so far nobody has solved it. If you want to argue that modern oo practice and the LawOfDemeter (or any other design pattern) make Codd's intuition obsolete, well, it ain't that easy. Until last year, GemStone, the peak of OO DBMS didn't have APIs good enough to solve that minimal challenge out of the box, while the worst SQL DBMS does. Actually if OO folks would get passed the NotInventedhere? syndrome, we'd all benefit from application of DrCodd's ideas in OO frameworks (they are sorely missing), and even better, in OO languages.
OO people are very prowd of their collection libraries (like the SmallTalk one) and of their splitting of the hair into "one to many", many to many, "one to one", "associations", "association classes". etc, etc. However all these are just toys and are not even as powerful as to handle the simple ManyToManyChallenge out of the box (not to mention the more serious challenges). However, let us give them a pass, and let' suppose that they came up with an OO framework that would be able to handle, among other things the simple ManyToManyChallenge and even more. How would the API for this framework would look like ? Well, it would look exactly like DrCodd's RelationalAlgebra. And there it is, RelationalAlgebra ( and the counterpart RelationalCalculus) is under their nose for more than three decades now, and they still can't figure out that it is 'the most elegant design for handling relations. "Modern OO practice", as Ward puts it, still has to play catch up with the genius and inspiration of DrCodd. -- CostinCozianu
Hey, I didn't say I didn't like the paper. But in section 1.2.3 he was talking about the unmanagiblity of conditional logic in the presence of change, a real problem, to which oo is also a solution. -- Ward
And that's exactly what I was trying to argue: that OO is not an adequate solution :) OO is a solution to many other problems, but not to this one. Please note, that the section is entitled access path dependence, and this is still a problem that many "out in the wild" ObjectModels suffer from, meaning the way they encoded X to X associations as collection of pointers attached to one class or the other. These collections will later have to be "navigated" through APIs, thus the application becomes "navigation path dependent". I'm ready to bet you that when we'll see an adequate OO solution to this problem, it will be a faithful OO API or language level encoding of DrCodd's ideas. -- Costin
Here's some quotes suggesting that Dr. Codd's ideas gained traction because they simplified queries, not (merely) because they had some kind of magic mathematical purity or foundation:
http://www.mcjones.org/System_R/SQL_Reunion_95/sqlr95-Prehisto.html
Irv Traiger: A couple of us from the Systems Department had tried to read [Codd's paper] - couldn't make heads nor tails out of it. [laughter] At least back then, it seemed like a very badly written paper: some industrial motivation, and then right into the math. [laughter] ...
Don Chamberlin: [CODASYL DBTG] had all sorts of real complicated pointers and set-oriented selection rules and you could just study it all day. It was a real puzzle. I was kind of a programmer type; I really grooved on that and gave a lot of talks on it and things like that. I was the CODASYL expert in our group...
We knew sort of peripherally that there was some work going on in the provinces, in San Jose. There was this guy Ted Codd who had some kind of strange mathematical notation, but nobody took it very seriously. Ray Boyce was hired at about this time, and we kind of got into this game called the Query Game where we were thinking of ways to express complicated queries. But actually before the Query Game started, I had a conversion experience, and I still remember this. Ted Codd came to visit Yorktown, I think it might have been at this symposium that Irv alluded to. He gave a seminar and a lot of us went to listen to him. This was as I say a revelation for me because Codd had a bunch of queries that were fairly complicated queries and since I'd been studying CODASYL, I could imagine how those queries would have been represented in CODASYL by programs that were five pages long that would navigate through this labyrinth of pointers and stuff. Codd would sort of write them down as one-liners. These would be queries like, "Find the employees who earn more than their managers." [laughter] He just whacked them out and you could sort of read them, and they weren't complicated at all, and I said, "Wow." This was kind of a conversion experience for me, that I understood what the relational thing was about after that. {emphasis added}
See also DrCodd capsule bios at http://www.oracle.com/technology/oramag/oracle/03-jul/o43edit.html and http://en.wikipedia.org/wiki/Edgar_F._Codd
EditText of this page
(last edited April 20, 2009)
or FindPage with title or text search