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

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

• erk