Oracle Training Oracle Support Development Oracle Apps

 E-mail Us
 Oracle Articles
New Oracle Articles

 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog

 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Oracle Support

 SQL Tuning

 Oracle UNIX
 Oracle Linux
 Remote s
 Remote plans
 Application Server

 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S


 Consulting Staff
 Consulting Prices
 Help Wanted!


 Oracle Posters
 Oracle Books

 Oracle Scripts

Don Burleson Blog 








Chris Date defends "shortcomings" of his relational model

Chris Date, co-creator of the relational database model (with Ted Codd), speaks-out in an O'Reilly interview:

Interview with Chris Date

In this insightful interview, Date addresses some alleged "complaints" about alleged shortcomings of the relational database model.

  1. With regard to data modeling, you can't define attributes which are of complex types (arrays, records, tables). Each relation has to be in first normal form. Or in other words: A "simple" natural structure must be divided into many flat structures (= tables/relations). The result is a complex structure of relations.
  2. Result of a query is a flat table. Any complex structure, which has been input of the query has got lost.
  3. No way to define recursive program structure (using SQL).
  4. The type system of SQL doesn't match with the type system of the embedding language ("type mismatch").
  5. Controlling integrity constraints costs a lot of time (need to control the usage of primary/foreign keys).
  6. Lack of mechanisms to control the physical level of the database (only simple clustering).
  7. Definition of operations detached from data definition.

Date has some interesting comments on these alleged shortcomings.

The changing definition of first normal form

I used to speak at the Database World conference with Chris, and this reminds me of Date's legendary debates with Dr. Won Kim, founder of the UniSQL "object relational" database.

Every year at Database World, Kim chastised the relational model for not supporting non-first-normal relationships, citing Date's 1970 definition of 1NF as containing "atomic" values.  The confusion about relational theory not meshing with non-first-normal-form databases eventually caused Date to clarify his definition of first normal form (in his third manifesto) to allow a column to be a "set", which can include an atomic values of any complexity (thereby including repeating groups and pointers to arrays).

"I reject the idea of "atomic values," at least in the sense that there might be such a thing as absolute atomicity. In The Third Manifesto,3 we let domains contain values of arbitrary complexity. (They can even be relations.)"

Oracle departs from the relational model?

It's also interesting that Oracle has deliberately departed from purely logical relational model, introducing their object-relational model in Oracle8.  The question is whether Oracle's object-relational implementation violates the spirit of relational theory.  There seems to be a widespread debate about the Codd and Dates willful omission of physical storage in their relational model.

Oracle officially changed their data definition language (DDL) in the 1990's to allow the Oracle DBA to physically sequence table rows (to improve runtime SQL performance) by allowing "create table as select" syntax to include the "order by" clause.   

Since then, Oracle has incorporated many physical storage features into their object-relational model, introducing cluster tables, the index-organized table (IOT), and the Oracle 10g sorted hash cluster table structure.

Date notes the deliberate omission of the physical storage layer in the relational model:

"The fact that the relational model says nothing about physical storage is deliberate, of course.

The idea was to give implementers the freedom to implement the model in whatever way they chose—in particular, in whatever way seemed likely to yield good performance—without compromising on data independence.

The sad fact is, however, that SQL vendors seem mostly not to have understood this point; instead, they map base tables fairly directly to physical storage,* and (as noted in the previous section) their products therefore provide far less data independence than relational systems are theoretically capable of."


Oracle Training at Sea
oracle dba poster

Follow us on Twitter 
Oracle performance tuning software 
Oracle Linux poster


Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


Copyright © 1996 -  2017

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.

Remote Emergency Support provided by Conversational