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

"Eric Kaun" <ekaun_at_yahoo.com> wrote in message news:BIl4c.57973$C45.24304_at_newssvr33.news.prodigy.com...
> "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.

It is important to note that stored procedures are applications. They are applications that run on the dbms, but the relational model says nothing about stored procedures per se.

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

E1, E2 and E3 in general have more meaning at the physical level than at the logical level, and his observations of what the industry is doing amount to what the industry is doing to overcome the failure of dbms vendors to provide adequate physical independence. Received on Fri Mar 12 2004 - 19:14:28 CET