Re: Do Data Models Need to built on a Mathematical Concept?

"Lauri Pietarinen" <lauri.pietarinen_at_atbusiness.com> wrote in message news:e9d83568.0304271138.63409dde_at_posting.google.com...
> "Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message
news:<b8eg1v$1pbo$1_at_gazette.almaden.ibm.com>...
> >
> > but wait, he then says next
> >
> > "Is it time to consider a more democratic structuring principle,
similar
> > to what they have in relational databases?"
> >
> > Unbeliveable! Why have computer scientists taken 30 years to to consider
this?
> > Where have they been? His next words just confim this.
>
> YES! This is the very question I have been trying to find an answer
> to for the last years! Any suggestions?

Beats me. I didn't even have a relational databases course on my CS degree. OK, so it was cancelled that year, but it no-one seemed particularly put out about it and I knew no better at the time (I think I had the impression that they were old hat, industry things only, and this newfangled OO thing would replace them..!!!!)

> [snip]
>
> Thanks Paul, for summarising the issue so nicely.

No worries. It felt good to get that post out

> I am, though a bit sceptical on the XML-stuff...

So am I , so am I....

> > To bridge this gap, I am thinking that there needs to be bridging of
> > functional programming with relational programming. Such a bridging is not
> > just a matter of a relational interface to FPs that allows persistent data
> > storage, no, it is the full integration of the two worlds.The Relational
model
> > needs improving with the type theory and program/theory proving of FPs and
FPs
> > need to have relations and the relational algebra as first class
primitives,
> > and they need to accept the principle that all permantly stored, generally
> > accessible data needs to be represented as relations.
>
> I tend to agree with Marshall here that there is still room for
> an imperative component, both inside the implementations of the
> datatypes and their operators and outside and around the relations.

From what I understand of type theory, you would defiantly want to go the functional route for user defined type implementations.

> This is what I understand is proposed in TTM (www.thethirdmanifesto.com)
> and implemented in Dataphor by Alphora.

Date & Darwen in The Third Manifesto (TTM) wrote:

    "do not infer from our assumptions of an imperative style that we discount the possibility of (e.g.) a "functional programming style" D at the time of writing, however, we have not investigated such a possibility in any depth"

Did someone else on the group say that if Date knew functional programming, he would much prefer it?
Maybe John Backus (circa '78) could convince you

    "Can Programming Be Liberated from the von Neumann Style"     www.stanford.edu/class/cs242/readings/backus.pdf

> Of course the more we can keep in the relational realm the better,
> but I believe there will always be parts of the application that
> will have to be tackled imperatively.

Show me a (useful) algorithm that cannot be performed in a relational algebra (hypothetically extended with 'features' from the FP world). Why have two languages if we can get away with one?

BTW does anyone have a good defn of 'imperative'. In the footnotes of the TTM, Date (and it would be him) says:

    "we have recently observed a distressing tendency to confuse procedural with imperative ... In particular, D - or its relational portion, at any rate - is imperative but not procedural"

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Mon Apr 28 2003 - 00:34:13 CEST