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

Thanks for the response.
Some notes below ....

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c2r525$qkj$1_at_news.netins.net...
> "mountain man" <hobbit_at_southern_seaweed.com.op> wrote in message
> news:a264c.98739$Wa.65668_at_news-server.bigpond.net.au...

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

Essentially I am trying to use the E1-E2-E3 as a simplified protocol stack within a computer network. When dealing with large scale change management you need to carefully delineate these respective domains.

What is an E1.5?

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

Consistency is paramount, and the basis of all integrity.

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

In some database application software this may certainly be the case. However, I'd be inclined to suggest that since the emergence of database management system software it has been seen to be far more efficient to store all of the data (or as much as possible) in the database.

The data lives in the (R)DBMS and the application deals with this rather than the data itself (ie: data encoded in the application layer). However, many legacy systems dating back to the eighties still work the data in the code.

Thanks again.

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