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

Thanks for the response.
Notes below ...

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

Well I was trying to be specific about the type of application software here, and all I am interested in are applications that are related to databases.

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

ok.

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

Good points.

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

Yes, I am aware of this.

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

Agreed. But quite often, for specific applications the OS needs to be somewhat tuned so as to optimise things. In an analogous manner I would expect that the relational model might be adapted in specific application environments in different ways. This appears not to be so.

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

When I wrote "recent" I should have been more specific and said, say, the last 10 years. In this time, there has been an increasing use of stored procedures by applications.

Code previously held in VB/C/etc is now in the (R)DBMS.

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

You appear to concede (unlike others here) that the Relational Model lives and breathes (in some stage of evolution) as one of the proprietory RDBMS software packages available today. Is this correct?

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

Given the first sentence, the second can be itemised ...

1. the R-Model is theory about data (alone and independent of apps).
2. the R-Model is embodied to some degree within RDBMS software.
3. there is always "in production" an interface between RDBMS and the application. [you are absolutely correct that it is a service level interface]
4. there appears "in DB theory" to be little if any interface between the R-Model and the "models apps" (notwithstanding the 1st sentence in the above).

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

Where are they? ;-)

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

I mean that in production everything is reliant upon everything.

E1 = The organisation needs an OS for the machines and network layers.
E2 = The organisation needs a (R)DBMS due to their historical precedence.
E3 = The organisation  also needs a specific (series) of application level

The number of permutations between E1 and E2 in todays world is small. The problems are therefore usually relatively small in this area.

OTOH the number of permutations between the types of E2 and E3 are huge, because the number of applications in the world is huge. It is usual that the
organisation has its problems in the proper management and coordination of the E2 and E3 environments specific for them.

The "systems solution" above refers to the concurrent management of all the above E1, E2 and E3 for, and at, the organisation site.

Thanks for the response,

-- 
Pete Brown
Winluck P/L
IT Managers & Engineers
Falls Creek
Australia
www.mountainman.com.au/software