How Relational Is My DBMS?

The term relational is used (and abused) by many DBMS vendors these days. If you want to
determine whether these vendors speak the truth, you are faced with the problem that relational
is a theoretical concept. There is no simple litmus test to check whether or not a DBMS
is relational. Actually, to be honest, there are no pure relational DBMS implementations.
That’s why it is better to investigate the relational degree of a certain DBMS implementation.
This problem was identified by Ted Codd, too; that’s why he published 12 rules (actually,
there are 13 rules, if you count rule zero, too) for relational DBMS systems in 1986. Since then,
these rules have been an important yardstick for RDBMS vendors. Without going into too
much detail, Codd’s rules are listed here, with brief explanations:


0. Rule Zero: For any DBMS that claims to be relational, that system must be able to
manage databases entirely through its relational capabilities.
1. The Information Rule: All information in a relational database is represented explicitly
at the logical level and in exactly one way: by values in tables.
2. Guaranteed Access Rule: All data stored in a relational database is guaranteed to be
logically accessible by resorting to a combination of a table name, primary key value,
and column name.
3. Systematic Treatment of Missing Information: Null values (distinct from the empty
string, blanks, and zero) are supported for representing missing information and
inapplicable information in a systematic way, independent of the datatype.
4. Dynamic Online Catalog: The database description is represented at the logical level
in the same way as ordinary data, so that authorized users can apply the same relational
language to its interrogation as they apply to the regular data.
5. Comprehensive Data Sublanguage: There must be at least support for one language
whose statements are expressible by some well-defined syntax and comprehensive in
supporting all of the following: data definition, view definition, data manipulation,
integrity constraints, authorization, and transaction boundaries handling.
6. Updatable Views: All views that are theoretically updatable are also updatable by the
system.
7. High-Level Insert,Update, and Delete: The capability of handling a table or a view as
a single operand applies not only to the retrieval of data, but also to the insertion,
updating, and deletion of data.
8. Physical Data Independence: Application programs remain logically unimpaired
whenever any changes are made in either storage representations or access methods.

9. Logical Data Independence: Application programs remain logically unimpaired when
information-preserving changes that theoretically permit unimpairment are made to
the base tables.
10. Integrity Independence: Integrity constraints must be definable in the relational data
sublanguage and storable in the catalog, not in the application programs.
11. Distribution Independence: Application programs remain logically unimpaired when
data distribution is first introduced or when data is redistributed.
12. The Nonsubversion Rule: If a relational system also supports a low-level language,
that low-level language cannot be used to subvert or bypass the integrity rules and
constraints expressed in the higher-level language.