Database Reference
In-Depth Information
The above features define the minimum requirements of a relational system. Other
desirable features of a database system discussed in chapters 1 and 2 are still important.
As it has turned out, meeting those standards was (and is) not easy. For years, they have
eluded, and continue elude software engineering firms aspiring to construct and market
DBMS suites. As you will soon see, the standards bar has been raised even higher for
contemporary products.
9.2 Ramifications of the Relational Model
The relational model has very far-reaching implications, and makes very stringent
demands on the software engineering industry, to deliver DBMS products that meet a
minimum set of standards. Let us briefly look at some of these ramifications.
9.2.1 Codd's Early Benchmark
In 1982, Edgar F. Codd (referred to by many as the father of database systems), in a paper
entitled “Relational Database: A Practical Foundation for Productivity” (see [Codd, 1982]),
proposed that a system could be regarded as relational if it supported at least, the
following:
•
Relational databases
•
The operations RESTRICT, PROJECT and (natural) JOIN, without
requiring any prior definition of access paths to support these
operations
Codd further asserted the following:
•
The operations may be supported explicitly or implicitly.
•
The system must internally optimize user requests for desirable
performance.
Based on those minimum requirements, DBMS suites were classified in one of four
categories: tabular, minimally relational, relationally complete, and fully relational. These
classifications are clarified in Figure
9-2
.
Figure 9-2.
Categorization of DBMS Suites
Not many products were able to survive the rigors of that benchmark. Interestingly,
three of the products that survived the test are still doing well in the industry today; they
are Oracle, DB2 and INGRES.
