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

From: Bob Badour <bbadour_at_golden.net>
Date: Fri, 12 Mar 2004 13:17:32 -0500
Message-ID: <gNednZya3ulnY8zdRVn-hQ_at_golden.net>


"Eric Kaun" <ekaun_at_yahoo.com> wrote in message news:KSl4c.57974$%Y4.56975_at_newssvr33.news.prodigy.com...
> "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...
> > > 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
> > >
> > >
> > > 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?
> >
> > No. I think E2 & E3 will be partitioned differently in the future, for
> > example, to have the constraint services available throughout an
> application
> > without launching any CRUD services.
> >
> > > 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.

>

> Here's what will happen: more and more functionality will migrate from the
> database to the applications. Then people will realize, as they did 30
years
> ago, that that's a very bad idea because it replicates business rules. Or
> they'll achieve proper use of a "middle tier" of "validation services",
and
> leave the data store to be little more than a file manager, at which point
> they'll realize how difficult it is to get different technologies to share
> it without (again) replicating logic all over the place. Or maybe some
> relational (logical) concepts will actually pervade programming languages.
>

> In any event, we (as an industry) are about to dive into the same nonsense
> the industry was in 30 years ago, and after much wailing and gnashing of
> teeth, relational or something like it will be invented anew.
>

> It's a shame that information systems has to be so fad-driven...
>

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

> I disagree. The RM would be a wonderful thing to have in any programming
> language, and I don't think Date suggests otherwise - The Third Manifesto
> has, I think, a bit to say on this. There are plenty of logic-based
> programming and specification languages (e.g. Prolog, Alloy, Z and its
> tools, etc.) that suggest the utility of logic in a purer form than
> languages today, which are operational/procedural (especially OO ones).
>

> > 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).
>
> Agreed. We've disagreed on the choice of model, but your conclusion is
sound
> whatever model is used.
>

> > > 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. If that model is only appropriate for one
> > aspect of an application, that would be relevant to its usefulness, for
> > example. An application developer chooses a data model that relates to
a
> UI
> > as well as one related to data storage.
>
> Imagine, for example, that your file system had a relational data store.
How
> simple it would be to find files, run reports, etc. without descending
> through every node in the "tree." The presence of hard and symbolic links,
> drive mappings and so on in many O/Ss shows the limited value of
hierarchy,
> even in what's normally viewed as a fairly pure one. So I'd suggest
> relations are useful on a very broad scale. And yes, I'm aware of the
> hammer/nail analogy, and am thinking practically.
>

> > > 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?
> >
> > I'd toss in a VM on top of the OS and then, yup, I agree.
> >
> > > Any references to Date's work on any of these questions would
> > > be appreciated.
> >
> > Nothing from Date on my shelf seems to head in such directions, but if
you
> > happen to have his latest (8th edition?) of An Introduction to Database
> > Systems ($95 new, so not on my shelf yet) I'm curious whether there
there
> is
> > more front-end-of-application-related database material in it.
>

> I wish Date would put out a cheaper version, maybe a condensed one - the
> first 6-7 chapters stand alone fairly well. $95 is a lot (I got mine as a
> Christmas gift, geek that I am). You'll find much interesting discussion
of
> database management, security, replication, transactions, etc. Still not
the
> front-end that you're seeking, but in my opinion a strong discussion of
why
> relations should be carried into the front-end, rather than less
> well-founded concepts from the front-end leaking into the data.

When did libraries stop lending books for free? Received on Fri Mar 12 2004 - 19:17:32 CET

Original text of this message