Chris Date defends "shortcomings" of his relational
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
- 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.
- Result of a query is a flat table. Any complex
structure, which has been input of the query has got
- No way to define recursive program structure
- The type system of SQL doesn't match with the
type system of the embedding language ("type
- Controlling integrity constraints costs a lot of
time (need to control the usage of primary/foreign
- Lack of mechanisms to control the physical level
of the database (only simple clustering).
- Definition of operations detached from data
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
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
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