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

I'd say separation of the above concerns is a good idea regardless of the evolution of the layers. Or, rather, that they evolved in that way with good reason.

Shouldn't E3 just read "application software"? The words "database" and "system" in there are confusing, unless you can clarify. In fact, the word "system" appears in all three - let's be concise.

> 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?

The RM is purely logical. There's no reason major portions of E3 can't use RM as well. And I suppose that you could even imagine an RDBMS on a chip, or relational services available to the O/S. It can be used anywhere.

> 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?

I don't think he's ignoring applications, though certainly his focus is on data management. Keep in mind that the relational model was invented FOR applications - to make life easy for them! Just because the application isn't mention specifically doesn't mean that the RM has no value for them - quite the contrary. Discussions of O/S can also ignore the application (temporarily), though O/Ss serve applications.

> 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.

I'm not sure that's a trend - in fact, the recent trend has been to move to a "shared services" layer (like a J2EE container).

> 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?

The model can serve many masters, since it's just a model. The interface is through query/command submission - an RDBMS is very much a service.

> 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.

I'm having a hard time grokking that last sentence - can you rephrase? I can guess, but would rather you just told us.

> This appears to be a database systems management
> issue (or aspect thereof) that is not in the realm of database theory.
> Is this correct?

Sure. There may be separate theories to address those things.

> 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?

It really depends on what you mean by "systems solution." If you mean that a given application relies on all of them, then yes. Beyond that, I'm not sure what you mean...

• Eric