July 31, 2011

The Ted Codd guarantee

I write a lot about whether or not to use relational DBMS. For example:

Before going further in that vein, I’d like to do a quick review of what E. F. “Ted” Codd was getting at with the relational model in the first place. 

The first sentence of Codd’s famous 1970 paper introducing the relational database concept reads:

Future users of large data banks must be protected from having to know how the data is organized in the machine (the internal representation).

In modern terms, that means “all you have to know to use the database is its logical schema; you don’t need to know anything about its physical representation.”

Over the next 15 years, Codd’s thinking — and his employer IBM’s technology — evolved to the point that Codd proposed 12 rules for a relational DBMS, the three most fundamental of which are:

Foundation Rule
A relational database management system must manage its stored data using only its relational capabilities.

Information Rule
All information in the database should be represented in one and only one way — as values in a table.

Guaranteed Access Rule
Each and every datum (atomic value) is guaranteed to be logically accessible by resorting to a combination of table name, primary key value and column name.

I.e., Codd was positively asserting that a database should have a fixed logical schema, in a tabular form. The clear implication was that programmers could or should be able to write anything they wanted to against that schema, without database performance being unduly compromised.

Of course, things never quite worked out that way. For most of the history of tabular DBMS, the best-performing short-request and analytic DBMS have been designed quite differently from each other.* Non-relational systems — from IBM’s own IMS to various object-oriented DBMS — outperformed relational DBMS on particular applications. Designers of high-performance applications were sensitive to the database’s physical design, sometimes even going to the extreme of non-transparent sharding. But on the whole, it was generally agreed that programming against a fixed logical schema is a good thing.

*Codd acknowledged this himself by promoting multidimensional OLAP over traditional RDBMS. (I regard the multidimensional/relational divide to be a distinction without significant difference; it’s all just fixed-logical-schema tabular processing with different data manipulation languages.)

In my next post, I’ll return to the subject of why fixed schemas might not always be such a good idea after all.


3 Responses to “The Ted Codd guarantee”

  1. Terminology: Dynamic- vs. fixed-schema databases | DBMS 2 : DataBase Management System Services on July 31st, 2011 6:02 pm

    […] F. “Ted” Codd taught the computing world that databases should have fixed logical schemas (which protect the user from having to know about physical database organization).  But he may not […]

  2. The refactoring of everything | DBMS 2 : DataBase Management System Services on July 20th, 2013 12:13 pm

    […] main point of relational DBMS is the Ted Codd guarantee, which says that applications and database designs can be loosely coupled. The price is that […]

  3. Brittleness, Murphy’s Law, and single-impetus failures | Smart Solution 4.0 on June 20th, 2018 6:53 am

    […] bigots who view the Ted Codd guarantee as an absolute requirement for data […]

Leave a Reply

Feed: DBMS (database management system), DW (data warehousing), BI (business intelligence), and analytics technology Subscribe to the Monash Research feed via RSS or email:


Search our blogs and white papers

Monash Research blogs

User consulting

Building a short list? Refining your strategic plan? We can help.

Vendor advisory

We tell vendors what's happening -- and, more important, what they should do about it.

Monash Research highlights

Learn about white papers, webcasts, and blog highlights, by RSS or email.