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

"Marshall Spight" <mspight_at_dnai.com> wrote in message news:WcBqa.632745$L1.180197_at_sccrnsc02...
> "Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message
news:b8eg1v$1pbo$1_at_gazette.almaden.ibm.com...
> >
> > "Is it time to consider a more democratic structuring principle,
similar
> > to what they have in relational databases?"
>
> Absolutely.
>
>
> > Unbeliveable! Why have computer scientists taken 30 years to to consider
this?
> > Where have they been? His next words just confim this.
>
> The model I have for the relationship that the relational world has with
> the rest of the programming world is that of the Indian subcontinent's
> drift into Asia: inexorable but very slow, and causing chaos on
> a Himmalayan scale.

LOL
> > To me, this lecture shows that the wider academic community never really
*got*
> > the Relational Model. They got the relational algebra/calculus (albeit
mostly
> > restricting themselves to binary relations), they could see the benefit of
> > data independence, but they missed the equally important *application
> > independence* that relationally defined data can provide.
>
> While I agree, I think there's still more. For example, the fact that
relational
> data is content-addressable is huge. Lots of other things, too.

I'd be interested in your list.
Although I think I would consider content addressed data as but an aspect of the Information Principle which for me, is itself just a weak version of application independence.
All data is equal - all is relations. If data was index addressed, or positionally addressed or whatever, then there is information embedded in the addressing scheme that is not relations, not equal. Anything but content addressing is going to be specific to some set of applications.

> By the way, I thought the file system example [not quoted] was interesting.
> Date's fond of saying that many things that are modeled as hierarchies
> aren't really hierarchies, and the example I always use is the filesystem.
> It seems to me that filesystem design reflects the thinking of the standard
> modern programmer. The basic meme is that there are only two data
structures:
> list and tree. If you can't make a list work, use a tree. So we model the
filesystem
> as a tree. But then, hey, you have to have *hard links* don't you? And you
> also need soft links, right? So you end up with a graph, but everyone
insists
> on pretending that it's a tree. (There's gotta be a line about "can't see
the
> forest" in here somewhere.) Modern application programmers use a tree
> structure for almost everything more complex than a list, whether it's
> appropriate or not. Witness the ascendance of XML.

Spot on.
In a way, XML is our failiure, or at least it stems from the failure to bridge your two continents. I'ld be very interested to know what Tim-Berners Lee knows of the relational model. (ho-ho maybe this is it http://www.w3.org/2002/Talks/1107-marconi-tbl/slide13-2.html (found using his marvellous WWW I must add) )

> > Note how Jayadev said "...similar to what *they* have in relational
> > databases". Why did he not say "what *we* have"? Why does he not consder
> > relational databases as part of his heratige?
>
> Well, because it's not. The database world has been off in a corner all this
> time. Database programming is a definite ghetto.

So it seems. I would like to understand why it is so, although I think the answers are probably many and there are more pressing matters.

> > To conclude, I think there is still a big gap in understanding between the
> > 'programming community' - the academic side typified by Jayadev - and the
> > 'database community' - the academic side being represented in it's seeming
> > absence in the universities by outsiders such as Chris Date.
>
> Totally agree.
>
>
> > To bridge this gap, I am thinking that there needs to be bridging of
> > functional programming with relational programming.
>
> Why functional programming? Why not imperative programming as
> well? It seems to me that an imperative programming language with
> first-class relational support, and a type system a la ML would be
> Most Excellent. (I've been kicking this idea around for about
> a year now. I have some primitive notes, and of course I've read
> TTM a few times. Still wrestling with my OOP heritage, though.)

Why functional programming? For all the reasons that the folks on comp.lang.functional would give for the superiority of FP over conventional ones. Because functions _are_ relations. Because they don't have variables, and we have one great big one to let them use for all their interactions with the outside world and so maybe solve their I/O and GUI difficulties. In short because FPs and relational programming are already very similar (as far as I can tell - I've written but one non-trivial functional program in my life; in Miranda on my not so recent CS degree), and I would believe that a merge, or at least a bridging of the chasm might not be that difficult.

Not being an acadmenc nor in research, I would not know how much work towards such a merging might have already been done. A quick look around brought up the following for one:

"Structural Recursion as a Query Language" with the quote

    "We ... put forward a programming paradigm that tries to get close to both the semantic simplicity of relational algebra and the expressive power of unrestricted programming languages. Its main computational engine is structural recursion on sets"

and in the introduction, they argue againt the concept of 'embedded query languages' due to their "impedance mismatch" and (in my words) the proving/understanding and optimisation difficulties when half an algorithm is in relational algebra and the rest in some more powerful (read: potentially non-terminating) external language.

Dijkstra's shortest path algorithm in SQL anyone?

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Sun Apr 27 2003 - 23:40:20 CEST