Incompleteness
of the
Relational
Model

Traditionally, the Relational Model is a model of the data and
does not concern itself with (application) objects. Historically, 
this stems from the technological separateness of the database 
systems environment and the application systems environment in 
the early days of computing.

However there is an increasing use of stored procedures as application 
objects within modern use of RDBMS technology. The syntactical 
contruction, etc of these is covered (by wrote & example very well) in 
Date et al, but only one or two diagrams, and a brief mention is made 
of "the application layer".

If you are able to abstract the essence of this modern change I believe
you can determine that what is happening is that there is now a potential
to store lines of application code, instead of in the client code, in the
SQL code within the proprietory RDBMS environments.

There is great advantage to be had from this, in performance and admin
costs, etc, etc, but the problem of course is that, baring encryption 
of the source code of the stored procedures, their authors had no control
(apart from standard security issues) over who viewed this code, or
indeed relicated it.  This is a separate issue, which is resolvable.

For arguments sake, let's say that you were able to sit down and
examine the entire suite of any given application, all its modules,
in totality.  When you added all the lines of code up you found
that a third the "intelligence" (ie: code) was in the client-side 
objects and another third in the server-side objects and the final third 
you determined to be in the stored procedure objects (within the RDBMS 
environment).

We are thus presented with a situation wherein one third of all
the (organisational) intelligence encoded in the application is
resident in the same physical file as the data and its relations,
constraints, etc.

When examined, each of these stored procedures are seen to
have exact formal and sytactical reference to very specific and
exact data structures, constraints, relations, etc.  They are all
expressed in the "relational language" of the RDBMS vendor.
They are explicitly intelligent in what they do.

Yet the current Relational Model must remain mute in regard
to this intellgence, which in this example, being a third of all
code used by an organisation, might be substantial. I consider
this to be a limiting.  Specifically, it is limiting in the 
potential to address object data within its own domain.

Everything is connected in the RDBMS, but the current Relational
Model cannot make that extra step and incorporate dynamic
and generic program objects.  Modern database management
practices mandate that one must turn elsewhere from the
relational model, because it is only modelling data.

More than data now exists in the database systems.

To take the example to its ultimate conclusion I present an
engineering solution whereby 100% of an application can
be composed of standard stored procedures:
www.mountainman.com.au/software/southwind

In this example we have no application code external to
the RDBMS, and the entire applications environment is
represented in SQL code in the database system itself.

The management of this database system and 100% of
its application environment is complete in the database
management system itself!  But the relational model
of the data is still mute on this complete set of objects.

This reflects a limitation in potential of current theory
(ie: the Relational Model) to appropriately and satisfactorily
describe this fundamental state of affairs with respect to
database systems and their management.

The actual mathematical philosophy of the Relational Model is
fine, and patently useful. In what it does, it does very very 
well, if thought and sufficient analytical homework is done by 
implementors and developers.

It is an eminently pragmatic tool, but nevertheless limited
in applicability to what is happening in database systems
today.  The model is many decades old, and there exists
divergence between the models axiomatic foundations and
the modern state of technology.

The Relational Model needs to be extended so that it has the
extra capability (even if it is rudimentary at first) to make
reference to RDBMS stored procedure object data, on the
grounds that this object data is an integral and highly related
part of the database system being studied, managed, and change-
managed in a cohesive and unified manner.

Addressing this issue is complicated by the extraordinary claim
by many academic database system theorists, that the true Relational
Model has not yet been implemented in the modern series of RDBMS
(ie: the vendore products: SQL Server from Microsoft, Oracle from
Oracle Corporation, DB2 from IBM, etc).

This has been the case since 1979 when Relational Systems Inc,
first released the Oracle product.  Since that time, technology
has diverged from the academic definition of the Relational
Model, and since that time things have become exceedingly 
more complicated.

So we have the situation today where the database systems
theory is the same theory that was promulgated in the 1970's.

It is believed that this is acceptible because the Relational
Theory of the data was believed to be integrally complete.
However, this is not the case, as I have outlined.

Relational Theory has a Godel-like incompleteness 
that may be simply specified:

The Relational Model of the data is incomplete 
because it cannot adequately address 
RDBMS stored procedure object data.