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

"Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message news:b8hirr$3kgo$1_at_gazette.almaden.ibm.com...
> "Marshall Spight" <mspight_at_dnai.com> wrote in message
> news:WcBqa.632745$L1.180197_at_sccrnsc02...
> > > 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.

Let's see:

relational calculus
content-addressable data
a *formal* way to prove that your data is free of redundancies, and

    therefor immune to update, insert, and delete anomalies. And if it isn't,     a set of algorithms to transform it so that it is. (the Normal Forms.) persistence
transactions
declarative integrity constraints
the ability to alter the performance characterstics of data access

    at *runtime* by, say, adding an index.

I suppose a number of those are RDBMS features, and not features of the relational model per se. But still. (I really ought to write that list down; it comes out different every time I try to reproduce it.)

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

Hmm. It appears I have a very different definition of application independence than you do. Maybe I'm too narrow about it. Come to think of it, I don't think I've ever seen the term defined. I've always just thought of it as the fact that your data is independent of your applications. That is, it survives them and isn't directly tied to them, but rather accessed through some API. I definitely agree, though, that the Information Principle is key.

> In a way, XML is our failiure, or at least it stems from the failure to bridge
> your two continents.

Wow. "XML is our failure" is a very powerful way of saying it.

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

I am very fond of saying, to whoever will listen, that Tim Berners-Lee set computing back by decades. His sucess in pushing hierarchical XML for data transfer takes data management back to the 1960s, and what's less of a regression but perhaps a worse sin, he's taken user interfaces back to about 1985. Having written both GUI client apps and web apps, it is appalling to me how primitive the UI the web provides is. Where's the tree control? Where are the menus? How about a sortable table? It just sucks. And don't even talk to me about Javascript as being some kind of cure. :-) And now the insult of the frickin' "semantic web." Argh, I hate that guy.

Of course, I don't get much traction with that argument, especially at work. My company lives and dies by the web.

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

Well, I don't see why a sequence of expressions, including the use of local variables, is any more of a mathematical function than in a single complex expression that eschews variables.

It seems to me that the reason why ML, say, is so awesome, is not because it's functional, but because it has such an excellent type system. I can't think of a single imperative language that has an excellent type system, but I don't see anything that would make it impossible.

> and in the introduction, they argue againt the concept of 'embedded query
> languages' due to their "impedance mismatch" and ...

That whole impedance mismatch issue is, again, "merely" an issue with the type system. Note that databases *must* use a value-based type system, and functional languages *must* use a value-based type system. Imperative language tend to use unnecessarily complex, close-to-the-metal, variables-can-contain-other-variables type systems, but there's nothing that *requires* them to do so. You could have an imperative language with a type system as good as ML's, but including variables. (Local variables, at least.)

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

Hmm. Have to think about that.

> Regards
> Paul Vernon
> Business Intelligence, IBM Global Services

Say, you wouldn't happen to be aware of the existence of an ODBC driver in IBM's Single Sign On product line, would you? I wrote that.

Marshall Received on Mon Apr 28 2003 - 08:31:53 CEST