Re: Date is Incomplete - database application software and database theory

"John Jacob" <jingleheimerschmitt_at_hotmail.com> wrote in message news:72f08f6c.0405161232.dbb7d2f_at_posting.google.com...
> > Firstly, I think you should acknowledge the fact that any
> > model of reality/data is always necessarily incomplete. Or
> > do you subscribe to the philosophy that the RM is a holy
> > relic?
>
> This is precisely the point. Of course it is incomplete, it is an
> active body of research. What it is not is limited. If you claim it
> is limited you must show in what way it is limited. You must provide
> some example of data which cannot be modeled using relations. The
> point is that the relational model is not a model in the usual sense
> of the word. It is not a mock-up that necessarily lacks the detail of
> the actual subject being modeled. It is a theoretical abstraction for
> modeling *all* data.

OK. Well done. If other posters on this newsgroup admitted as much then we may get somewhere in discussion, but some, not all, hide behind ad hominem abuse and the kill-file mentality. This is half the problem.

> So I must ask again, what example can you provide which shows that the
> relational model is limited.

Please bear with me ...

Traditionally, the RM does not concern itself with (application) objects. Historically, as I have outlined eslewhere, this stems from the technological separateness of the database systems environment (E2) and the application system environment (E3) in the early days.

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 third the "intelligence" (ie: code) was in the client-side objects and another third in the server-side objects and the final third 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.

Everything is connected in the RDBMS, but the R-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.

I think this reflects a limitation in potential.

> At the very least, if you really want to find a 'theory of
> applications' you should read What Not How. It is a simple read, and
> describes in detail how the relational model can be applied to
> application development.

Production systems are what I am on about. Dont get me wrong about the actual mathematical philosophy of the RM. 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 RM needs to be extended/expanded 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 (and managed in a cohesive and unified manner).

Pete Brown
Falls Creek
Oz
www.mountainman.com.au/software/ Received on Mon May 17 2004 - 15:56:54 CEST