Re: Date, the relational model and the application (software layer)
Date: Sat, 13 Mar 2004 12:13:50 +0100
Message-ID: <4052ed00$0$565$e4fe514c_at_news.xs4all.nl>
> "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...
>>>... 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.
>>>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.
Applied. Not adapted.
Analogy: Even advanced scientists very rarely need to adapt
mathematics to their specific environment. When they do their
adaptations become part of the knowledge we call mathematics,
and not just of their research field.
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).
>>>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.
>>>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?
Maybe not directly. I haven't read enough on this yet.
I do remember Chris Date requiring
computational completeness for a relational language.
>>...
>>>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).
4.1:
Could you elaborate on 'independent'?
4.2: Not necessarily - but that will come as no surprise after my earlier remarks.
4.3:
A := database.new;
(A statement in some imaginary language that did not abuse the single equals sign for assignment)
>>>...
>>>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? I've heard of a restaurant there, but I don't know which DBMS they use ;-) Received on Sat Mar 13 2004 - 12:13:50 CET