Re: Date, the relational model and the application (software layer)

"mountain man" <hobbit_at_southern_seaweed.com.op> wrote in message news:a264c.98739$Wa.65668_at_news-server.bigpond.net.au...
> My reading of Date's work in regard to his reference to the application
> software layer is that is is located external to the (R)DBMS as seems
> indicated by a number of diagrams in the introductory chapters.
>
> Initially this would seem understandable, from the historical perspective
> because of the evolution of the architecture of software layers over and
> above the hardware layer (E0):
>
> Software environment E1: machine and network operating system software
> Software environment E2: (R)DBM system software
> Software environment E3: database application system software
>
>
> Question 1:
> Discussion of the relational model (RM) seems to suggest to me that Date
> (and
> others) envisage that the RM is to be implemented in environment E2 (ie:
as
> some advanced form of RDBMS software). Do you consider this to be
> a correct statement, and if not, why?

No. I think E2 & E3 will be partitioned differently in the future, for example, to have the constraint services available throughout an application without launching any CRUD services.

> Question 2:
> I cannot conceive of a production realtime database system without the
> sybiosis of each of these above 3 system software layers (E1, E2, E3),
> yet the database theory promulgated by Date appears to ignore any
> reference to the application. Do you consider this to be
> a correct statement, and if not, why?

Yes. I can see an effort to remove the E1 discussions if we inject an E1.5 of a virtual machine running on top of the OS/hardware layers. But I cannot see hard lines between DBMS and application being seen as the best strategy in our profession a decade from now.

> Question 3:
> In recent years there has been an increasing tendency to migrate "code"
> from the application software environment E3 to the RDBMS software
> environment E2. Examples of this evolving tendency include the use of
> database constraints, triggers, but are dramatically highlighted by the
> utility of RDBMS stored procedures. (eg: this code may have been
> previously physically held external to the DBMS on the client app E3).
>
> Date does not seem to address this (evolving) issue ... How does the
> relational model interface the application software environment?

S/W application professionals seem to be migrating the code into the database or database features into the code -- so the lines are definitely blurring. I don't think there is anything in the relational model that would promote the latter, but the former is promoted by the fact that data is relevant to the application throughout, so if the relational model is employed in one area, it makes sense to employ it elsewhere. (And if a not-strictly-relational model is followed in one part of the app, it also makes sense to carry that throughout).

> Question 4:
> It is quite understandable that the RM be considered to be entirely
> independent of the application to which the model is to be applied,
> for this is its strength. However, OTOH, according to my position
> developed above, whenever the RM will be implemented in some
> form of RDBMS it will be implemented with a very real application
> software layer which will be physically interfaced from the RDBMS
> software layer. This appears to be a database systems management
> issue (or aspect thereof) that is not in the realm of database theory.
> Is this correct?

I disagree. If you use a def of a database as a set of facts (not my favorite, but it suits others on the list), then you can see that there are sets of fact all throughout a software application, requiring a data model throughout the application. If that model is only appropriate for one aspect of an application, that would be relevant to its usefulness, for example. An application developer chooses a data model that relates to a UI as well as one related to data storage.

> Question 5:
> The above 3 software layers might be physically and logically separate
> however they must be managed at an implementation concurrently.
> The end database systems solution thus appears as an evolving
> symbiosis of these 3 different software environments. Is this a
> reasonable statement?

I'd toss in a VM on top of the OS and then, yup, I agree.

> Any references to Date's work on any of these questions would
> be appreciated.

Nothing from Date on my shelf seems to head in such directions, but if you happen to have his latest (8th edition?) of An Introduction to Database Systems ($95 new, so not on my shelf yet) I'm curious whether there there is more front-end-of-application-related database material in it.

Cheers! --dawn Received on Fri Mar 12 2004 - 02:50:52 CET