• go to Ole-Johan Dahl 's profile page
  • go to Kristen Nygaard 's profile page
  • go to William Kahan's profile page
  • go to Donald E. Knuth's profile page
  • go to Edsger W. Dijkstra's profile page
  • go to Richard Karp's profile page
  • go to Kenneth Lane Thompson's profile page
  • go to Yoshua Bengio's profile page
  • go to E. Allen Emerson's profile page
  • go to Dennis M. Ritchie 's profile page
  • go to Leslie Lamport's profile page
  • go to Robert W. Floyd's profile page
  • go to Geoffrey E Hinton's profile page
  • go to Silvio Micali's profile page
  • go to Edwin Catmull's profile page
  • go to Pat Hanrahan's profile page
  • go to Shafi Goldwasser 's profile page
  • go to Kenneth E. Iverson 's profile page
  • go to Raj Reddy's profile page
  • go to Peter Naur's profile page
  • go to Richard W. Hamming's profile page
  • go to Joseph Sifakis's profile page
  • go to Dana S Scott's profile page
  • go to Manuel Blum's profile page

Edgar F. ("Ted") Codd DL Author Profile link

United States – 1981
Additional Materials

The Relational Model of Data

The relational model of data is, in essence, a formal and rigorous definition of what the data in a database should look like to the user; i.e., it is a (somewhat abstract) specification of the user interface to a database system. In other words, a database system is relational if and only if the user interface it supports is a faithful implementation of the relational model—meaning that, as far as the user of such a system is concerned, (a) the data looks relational, and (b) relational operators such as join are available for operating on data in that relational form.

Data Looks Relational

Relations can be depicted on paper as simple tables of rows and columns. Loosely, therefore, we can say the user sees the data in the form of such tables.

Relational Operators Are Available

Relational operators are operators that derive further relations from given relations. Since relations can be thought of (loosely) as tables, therefore, we can think of those operators as “cut and paste” operators for tables. For example, given a table of employee information, the restrict operator will let us “cut out” just the rows for employees with a certain salary. And if we are also given a table of department information, the join operator will then let us “paste on” to those employee rows department information for the employees in question.


Since the user interface in a relational system is so radically different from (and of course so much simpler than) the way data is physically stored and manipulated inside the system, there are some significant implementation challenges to be faced. Researchers began to investigate this problem early in the 1970s, soon after the publication of Codd’s original papers, and numerous prototypes were built throughout the 1970s. The first commercial products began to appear toward the end of that decade. And while it is unfortunately still true, even today, that none of those products is entirely faithful to Codd’s original vision, they quickly came to dominate the marketplace. The relational model—thanks to its solid foundation in set theory and formal logic—is here to stay. It will stand the test of time.