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

"Bob Badour" <bbadour_at_golden.net> wrote in message news:JcqdnT4CAJHfY8zdRVn-tA_at_golden.net...
> "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...

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

...[trim]...

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

Of course, it would help things if in general there was adequate provision in *some* theoretical model to handle the logical concepts E1, E2 and E3 which are - in engineering terms - the basis of any modern (database served) computer system.

The history of the path of the modern dbms vendors is essentially in the beginning there was the E1 and the E3 only. Gradually there emerged out of the amorphous E3, software which was very specialised in handling the data. This software evolved to the modern dbms.

You are correct in pointing out it is an industry problem. Not so sure about the hand-waving at the dbms vendors.

Any implementation of E1/E2/E3 combination has its own problems due to the E3 and the organisation. The E1 and E2 are generally very robust and very stable, although possibly not mastered at every site.

The E3 (application) to be applied to the E2 (instance of the Relational Model) is as diverse as are organisational activities. Expertise is often scarce in the co-implentation of E2 and E3 particularly, due to specialisation of activities in the organisation.

Specialisation of roles - sometime dramatically demarked - can often correspond between the E2 (DBA) and the E3 (App.Dev) and this requires special attention, management, and especially detailed coordination, as you can apreciate, for a successful outcome with given resources.

If the RM is not yet fully implemented in some RDBMS, and is still awaiting creation (after 30 odd years) then it had better take note and regard the lessons learnt by RDBMS technology supporting all manner of application software.

If OTOH the RM is incarnate (partially, or evolving) in some or a number of current RDBMS software (E2), then I believe that the Relational Model - for industries sake - needs to become cognisant of the E3 environment - leastways discuss the interface to this. Additionally E3 management, and E3 change management.

However, the purists may would respond that the model is for the data alone. This does not sit well for industry imo.

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