An Article on contemporary
Why is the Relational Model Incomplete?
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.PRF Brown