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

Thanks again...

"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message news:4052ed00$0$565$e4fe514c_at_news.xs4all.nl...
> mountain man wrote:

...[trim]...

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

>

Essentially this is one of the key issues to be explored.

From an IT engineering aspect, the RM is harnessed and part of (to some nominal degree that is non-zero and not yet 100%) within let us say the major RDBMS vendors at this point in history.

There are hundred of thousands (therefore) of implementation instances of the (evolving) Relational Model. Now, lets first concede that it is quite possible, and in many cases quite common, for the implementation of real-live organisational daily bread and butter database applications, the implementation could be done better. Let's leave this issue aside, and assume the best impl.

Thus, in real terms we have this RDBMS at the very heart of the organisational activity. Obviously, in a fully blow E-office, the hardware and network geography, topology, user-base (h/w) ditribution would be within tables in the RDBMS, and also presumeably a financial asset register, tracking this aspect of the hardware.

OTOH the E1 software can be managed in tables, as can the E3 (application level) software. In fact, with large suites of E3, one cannot do without databases (eg: problem resolution, change management issues, Help Desk, etc). to assist in the admin of change.

It is the E3 side that is to me important, because it is obviously the wild-seeded environment amidst the (E0,E1,E2,E3) melting pot which has to be appropriately managed at every one of the RDBMS sites on the planet.

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

>

Not necessarily, although it would be interesting to know the statistical distribution of the above, to the following:

History would have it that mathematicians are free to dream up anything they like so long as it exhibits some form of defined consistency. Pure mathematics breeds theories like rabbits, (which compete for survival) and they are freely available to future generations of scientists to *apply*.

When a scientist seeks some mathematical treatment not yet available to contemporary analysis, he or she may certainly try and create something from scratch. But imo when they start to get serious they will search the related literature for an existent rigorous treatment of the terrain they aspire to study.

> Most of the time even these geniuses just apply this knowledge
> to their realm. Now the RM doesn't have the maturity of mathematics,
> of course, but it is conquering a similar place as say
> group-theory (a math field).

I think that in fact there is a fair degree of maturity inherent in the maturity of the mathematics available to the RM, because it in fact does represent so many centuries of development to be able to arrive at the contemporary understanding of group theory (to use your example).

The RDBMS is more than the vessel for the data model, due to its physical and genuinely central role it plays in today's production sites.

It is also conquering things from the implementations of the existent RDBMS solutions as discussed above, world wide.

If the model is indeed inculcated in the modern RDBMS software then the model needs not to remain mute on the interfaces between the RDBMS software layer (E2) and the others.

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

>

>

The whole reason for the existence of the middle tier is the misunderstanding that is capable of happening between the E2 and the E3. The middle tier is often necessary to rescue applications that are not capable of being changed to work correctly from the ground up.

Their purpose is to correctly interface an existent E3 package to an existent E2 package, when noone wants to do the task from the ground up, or it is too hard, or too expensive, or there are insufficient resources available to the organisation for example.

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

>

This is a first step, no problems. The native relational languages available to the modern RDBMS (E2) software are good enough to be able to achieve any task that is capable of being visualised.

However I still maintain that the Relation Model itself, being mute on the subject of the application layer, is not assisting clarity.

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

>

>

My take on the Relation Model as covered by Date is that the data model (in theory) should be entirely generic between all applications. IE: The model is a theory, and can be applied to all and any implementation instance. At implementation, the same data model (techniques and consistencies) are adapted to the business activity environment of the organisation.

IE: The model (theory) is independent of its applications.

It may have certainly started out that way, however we have come a long way since Codd Rules etc, especially with the RDBMS implementations of the current day.

> 4.2: Not necessarily - but that will come as no surprise
> after my earlier remarks.

Look it is capable of being put on a chip, or withinan app and both of these have obviously already been done. My point simply is that statistically, if one needs to point at the best available currently production instances of the RM then one needs to regard to current RDBMS user base.

> 4.3:
> A := database.new;

A bridge in construction requires non-use for a period.

> (A statement in some imaginary language that did
> not abuse the single equals sign for assignment)

Not sure what this is.

> 4.4:
> I may not have understood the Q. As far as I did:
> What would you/we need in that area beyond a language?

Simplification of the terms in the environment.

> >>>...
> >>>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?
>
> Are you talking about the database at the end of the universe?

Jokes aside, I am talking about managing the theory of it all once the theory has made an instance of itself at some implementation or another.

> I've heard of a restaurant there, but I don't know which DBMS they use ;-)

It's a SQL Server RDBMS.
Bill has table 42. ;-)

And there are indeed turtles
all the way down!

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