Only if you care about things like correctness. Most people don't; most people only care about performance. If you get the right answer most of the time, they're happy.
The general thinking seems to be that coming up with the wrong answer really quickly is much better than coming up with the right answer a bit more slowly.
Most data models today are built on "The C Programming Language" by Kernigan and Ritchie.
"Ian" <kellizer(nospam)@hotmail.com> wrote in message <news:SWXpa.670$xI5.520@newsfep3-gui.server.ntli.net>... > What about the Object Model - It wasn't built on a mathmatically proof , as > with the relational model, not agree?
There is not a Data Model called "The Object Model".
"Ian" <kellizer(nospam)@hotmail.com> wrote in message <news:SWXpa.670$xI5.520@newsfep3-gui.server.ntli.net>... > What about the Object Model - It wasn't built on a mathmatically proof , as > with the relational model, not agree?
Perfectly correct. What was it built on? And also what is it? If you know where there is a reasonably widely agreed definition of the Object Model, please point me to it.
(I assume that we are talking about an Object Data Model, not, for instance, an Object Programming Model.)
I think that's a widely inaccurate notion, that if data models don't follow a mathematical concept, they are not "correct". Data model follow rules, If the model conforms to the rules, it is correct. You talk about the implementation of data models as a deciding factor is the design?
"Marshall Spight" <mspi...@dnai.com> wrote in message
> > Do Data Models Need to built on a Mathematical Concept?
> > Example, The relational model has set theory.
> Only if you care about things like correctness. Most people > don't; most people only care about performance. If you get > the right answer most of the time, they're happy.
> The general thinking seems to be that coming up with the > wrong answer really quickly is much better than coming up > with the right answer a bit more slowly.
> Most data models today are built on "The C Programming > Language" by Kernigan and Ritchie.
"...And, I contend that lack of useful theorems about a typical C++ program is what makes it so difficult to make claims about it: its intent, whether a particular change will have a disastrous effect on its execution and whether it can be integrated with other programs. In other words, we typically build mathematical systems whose properties we cannot discern."
Se here you have it: Computer Systems, Software Systems, Informations Systems -- whatever you want to call them are in essence *mathematical objects*, whether you like them or not to be that's what they are.
So even if you think you build your object model, custom C hacks, device driver -- whatever, without using or better said without thinking about Mathematics, in the end you'll end up with a *mathematical object* that's the essence of it. So here you have it: all data models, even the bad XML data model, or the equally bad ODMG object data model are *mathematical*, from this perspective your question has no sense.
And now, once we put this confusion behind we can see that there are two categories or two extremitities on a quality scale, there are mathematical objects :
- WHO'S PROPERTIES WE *CAN* DISCERN or - WHO'S PROPERTIES WE *CANNOT* DISCERN
If you buid your mathematics starting from a sound theory, using careful design and forethought about your objectives (what in the end you want to accomplish), and *mathematical rigor*, you end up with a mathematical system who is sound, who's properties you can discern, and who is very *adequate* to tackle the problem you want it to tackle (otherwise you can try to apply differential equations to solving integer optimization problem years in a row you'll bang your head against the all).
Or you can say you don't need to have to do anything with mathematics and you'll end uo in ignorance, and with mathematical objects who's properties you cannot discern. In case of object models, it's even worse than that: practitioners don't even have a *ing clue what properties they should look for.
For example in relational model you can establish useful properties about the database schema: whether it's normalized or not, while using today SQL implementation you can reasonably establish how long a operation will take, you will establish the ACID properties as part fo the deal with the DBMS vendor, again reasonably well ( cause I don;t know of any DBMS vendor who aquitted itself of the Proof Obligation Dijkstra talked about), and also you know, and you know _why those properties are important for your system_.
Now compare that to your typical OO mathematical objects:
- You largely have no clue what properties they have - People don't know what properties are really important about their mathematical objects
For typical examples: - most Java programmers know how to use threads and they programmed at list one multithreaded program. But they have no clue if it's safe, if their program will not deadlock, lead to starvation, etc - even Sun's engineers have no clues, because key APIs exhibit critical bugs like deadlock, infinite loops, OutOfMemory errors, JVM crashes etc. - C++ programmers: anyone has seen one that can prove that his non-trivial programs doesn't have memory leaks or memory access violation ? - Object Management Group. They did the stupid UML specification that all OO "architect" (by the way, I am one of those) and their grandmas use to monkey around with the upper management for the "illusion of control". Anybody knows about any property you should look for in a UML diagram ? No, and frankly you can't really look for any property, because UML is not a mathematical system *well defined*.
In the end, if you looked for a debate there's no room for debate in here, it is your choice.
Either you build software systems who's important properties you can discern, or you can build software systems about which all you can say is: it si likely to work, or 3 months of extensive QA shows that the defect rate is acceptable and let's ship the hell out of it ot the customer.
"Ian" <kellizer(nospam)@hotmail.com> wrote in message news:av8qa.611$oA1.85469@newsfep2-gui.server.ntli.net... > I think that's a widely inaccurate notion, that if data models don't follow > a mathematical concept, they are not "correct". Data model follow rules, If > the model conforms to the rules, it is correct.
Well, what I'd call a data model is a set of rules. It sounds like perhaps you're calling the implementation of the rules in code the "data model."
It seems to me that if the data model, the rules, or whatever, are built on sound mathematical foundations, you've got something sound. If it was just thrown together in order to be easy to implement, (the usual case) then what you've got is anyone's guess.
> You talk about the > implementation of data models as a deciding factor is the design?
I didn't quite understand this sentence, but I'll note that I'm just talking about model, not implementation; they are separate.
See also Costin's post, which says a lot of interesting and important things really well. (That is, better than I could have.)
> "...And, I contend that lack of useful theorems about a typical C++ > program is what makes it so difficult to make claims about it: its > intent, whether a particular change will have a disastrous effect on its > execution and whether it can be integrated with other programs. In other > words, we typically build mathematical systems whose properties we > cannot discern."
[snip]
Top post Costin, top post.
That lecture is very interesting indeed. Here we have Jayadev Misra, the inheretor of one of Dijkstra's chairs saying: "... let me suggest a problem worthy of your attention. The fundamental structuring principle for systems is hierarchical organization. It permeates the world around us; social and political systems are hierarchical. We have found from experience that tree-structured file systems, hierarchical organization of large domains such as the internet, and system designs in which each component itself is regarded as a system, is convenient. Even within object-oriented programming, the notions of components and encapsulation impose hierarchical structures."
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.
"I am driven to these considerations by the need to view a system from different angles. I can look at this building floor by floor, or by its electrical, plumbing and computational infrastructures, or by the people who work here by their professions. I would like to slice the same system in a variety of ways depending on which aspect of it I want to study. I would like to see my file system not only as being hierarchical but also providing groupings according to other criteria: all files that constitute the chapters of a book ought to be arranged in a sequence so that I can read from Chapter 3 to 7, say. I would like to see the list of all printers in the campus, even when the campus network is organized by departments. How do we support multiple views of a system while retaining the advantages of hierarchical structuring? How do we exploit multiple views during program design and evolution?"
This was one of the fundamental incites of the relational model. It was highlighted when Codd created formal network and hierarchal data models with the purpose of comparing them to the relational model and in the process showing the superiority of the relational model. That superiority being exactly as characterised by Jayadev; the RM is democratic - all data is treated equally - and therein lies it's advantage.
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.
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? Maybe the fact he said 'relational databases' and not in 'the relational data model' is also telling.
His question "How do we exploit multiple views during program design and evolution?" is one that us relational people have always been able to answer (at least since views have been considered updatable).
His other question "How do we support multiple views of a system while retaining the advantages of hierarchical structuring?", is, if you will allow, being partially answer by the more sensible efforts to integrate XML with SQL databases. Specifically I'm thinking of XQuery and XTables, that look much more respectable than you might think would come out of such an effort. (See
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 Chirs Date.
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.
Reflecting Jayadev's closing remarks, we need the relational model and relational programming to become part of the mainstream of computer science. I don't believe we are there yet.
Thanks. Online & off-line discussions encouraged.
Paul Vernon Business Intelligence, IBM Global Services
> His other question "How do we support multiple views of a system while > retaining the advantages of hierarchical structuring?", is, if you will allow, > being partially answer by the more sensible efforts to integrate XML with SQL > databases. Specifically I'm thinking of XQuery and XTables, that look much > more respectable than you might think would come out of such an effort. (See
> "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.
> 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.
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.
> 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.
> 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 Chirs 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.)
>>His other question "How do we support multiple views of a system while >>retaining the advantages of hierarchical structuring?", is, if you will
> allow,
>>being partially answer by the more sensible efforts to integrate XML with
> SQL
>>databases. Specifically I'm thinking of XQuery and XTables, that look much >>more respectable than you might think would come out of such an effort. (See
> Regards > Paul Vernon > Business Intelligence, IBM Global Services
You'll excuse me if what I read in the article triggered my recollection of this formidable saying of Dijkstra:
"In the software business there are many enterprises for which it is not clear that science can help them; that science should try is not clear either."
XML is doomed to be such an enterprise.
I find many of the (unspecified) premises of the article rather not happening in practice, if I'm ever going to see them I'll probably consider them bad engineering, and of course those premises do raise a hell of a lot of problems, that the proposed approach might or might not address.
The quality of ad-hoc solutions to ad-hockery kind of problems is certainly not going to be great, and frankly speaking reading the article and seeing some of the unnecessary complexities in their code samples, one has to wonder how have we got here ? Where do we depart them and what is such a serious problem that requires such a complex of a solution for moving a bunch of bytes around the computer ?
Well, the point that the authors departed from is that you have to have XML in the database, or to "integrate" XML whatever that means. Yes, of course, then you have problems, lots of them.
Well, those are not the problems of my users. The problems of my users are orthogonal to whether I store native XML in relational databases (which is something that I refrain from qualifying for the sake of civility). So the article has 0 value for me, and I consider that IBM will likely spend a hell of a lot more money for no benefit of their users. Reminds me of the sheer engineering effort of Oracle to put first objects in the database as a PL/SQL extension, and then make room for them in tables, of course I would regard any usage of those features a serious engineering mistake.
Of course, I can imagine a reply, but you have to deal with XML because it is industry standard, and other systems will want XML and so on so forth, and even if XML is technically less than desirable, the sheer force of the whole industry being behind it makes it a better engineering solution to virtually all its competitors, byt the amount of tools put at your disposal, your needs fo integration, etc, etc, etc
Yes. I will admit XML is a neccessary evil for the time being, but I won't make a deal with the devil for the sake of it :) And the forces of industry might be great, but they are petty nothing compared to the daunting force of Mathematics.
That's what made COBOL obsolete, C++ obsolete, and will make Java , UML, C# and XML onsolete soon. That's what makes Lisp still alive with a design dating back to 1958, that's what makes Dijkstra's Discipline Of Programming be still a book in print. You can have all your industry behind you, that's easy part, the hard part in our business is to deal with Mathematics.
> "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?
[snip]
Thanks Paul, for summarising the issue so nicely. I am, though a bit sceptical on the XML-stuff...
> 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. This is what I understand is proposed in TTM (www.thethirdmanifesto.com) and implemented in Dataphor by Alphora.
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.
> Reflecting Jayadev's closing remarks, we need the relational model and > relational programming to become part of the mainstream of computer science. I > don't believe we are there yet.
I think it requires that computer scientists realise that what's good for mathematics (i.e. relations) is good for computer science also and that in the end of the day we have to base everything on mathematics anyway.
> > "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
> > "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
Re-reading my words, I said "much more respectable [ideas may come out of this effort] than you might think". Following Fabian Pascal, you would think no useful ideas could ever arrive, indeed after the experience of the OO extensions to SQL (DB2 in my case), no useful ideas at all showed up (which annoyed me, I thought I might get half-way useable User Defined Types at the very least). This time I am just a little more hopeful, that is all. Maybe it will be 'higher-order' languages (like SchemaSQL). That is certainly one thing that the FP guys have (or are on the way to getting with 'meta-programming' research) and it's one of the things that I want in my relational languages.
BTW I do believe that the _underlying_ goal is laudable. Namely non-relational, non-scalar access to relational data. (albeit on relational terms). Indeed the manifesto suggests ARRAY types that can be associated with relation types. It's just a shame that the promoters of this XML + SQL stuff don't see things in such terms...
Regards Paul Vernon Business Intelligence, IBM Global Services
> 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..!!!!)
Ha ha! At my university, I had the opportunity to take database classes from Michael Stonebreaker, but I figured it would be about the same thing as taking accounting.
> > 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.
("defiantly" of "definitely?" Not that I am opposed to doing things defiantly.)
Could you expand on that? It seems to me that the core of what I get out of TTM as far as UDTs goes is the clear definition of values and variables. I don't see anything particularly wrong with having variables. It seems to me the problems come when you allow variables to contain other variables. (That is, objects, pointers, etc.) As long as all a variable can do is hold a value, and variables can't be aliased, you are side-effect free. And THAT I think is the real issue: ridding ourselves of side effects, and not functional vs. imperative. (The functional guys just come out looking better today because they've managed to free themselves from side effects. But I'd say they did it the hard way.)
> 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?
Well, we certainly *can't* get away with one. There are application languages and there are systems languages. Take Java and C++ today, for example. Sure, they're deeply flawed, but they both have some cool things in them, and they're the two most popular languages today. One is an application language; the other is a systems language. I'd certainly hate to use either for the other's purpose, although it can be done.
This language I'm semi-seriously designing, is an imperative relational language. It's great for writing applications. It'd suck to write a device driver in, in a manner similar to how much it would suck to write a device driver in Java.
And besides that, why not allow one language to be embedded in another? I'd claim that's what regular expressions are: a special purpose sublanguage.
> 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"
I always figured they meant the same thing. FOLDOC calls them synonyms:
"Paul Vernon" <paul.ver...@ukk.ibmm.comm> wrote in message news:b8hirr$3kgo$1@gazette.almaden.ibm.com... > "Marshall Spight" <mspi...@dnai.com> wrote in message > news:WcBqa.632745$L1.180197@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 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.
Paul Vernon wrote: >>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"
OK, I am a bit out of my depth here, I have to admit. I don't know the difference between imperative and procedural - I thought they were the same thing. I would be grateful for any clarification on this...
>>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?
Well, any algorithm can be performed by a Turing machine, and I faintly remember seeing (and learning) a proof that says that anything that can be expressed with a Turing machine can be expressed with relations - however, there where some slight performance problems ;-). Does anybody remember such a proof? It must have been from the early 70's.
> > "Marshall Spight" <mspi...@dnai.com> wrote in message > > news:WcBqa.632745$L1.180197@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
I noted that one
> 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.)
Frankly I've always thought that normalisation is overblown. Redundancy is a semantic matter. The database only know the semantics if you declare them to it with integrity constraints. If you then want to keep more redundancies by not normalising your database, then so be it. The DBMS won't allow you to break the constraints so there is no problem. All you will find is that fewer single relvar updates will work, and you will need to use multiple relvar updates instead. Big deal.
> persistence
Hardly specifc to DBMSes. I think punch-cards got there first
> transactions
Dead wrong. Transactions are bad, real bad. In short they are not compatible with the 'arrow of time'. They let you freeze time and that is not a good model of reality. Start a new thread if you want to discuss the details, I've a draft paper on the subject and a could do with some intelligent challenges to sharpen up my argument.
> declarative integrity constraints
Yep, that is a big one, but again for me it is subsumed by application independence. To use the terminology, unless all your business rules are declared and enforced by the database, then each application will have to reimplement your rules and be vetted before being given database access. The goal of *strong application independence* is to allow any 'application' whatsoever to access and update your database, and still gureantee maintian a correct and working system even in a 'hostile' environment like the net.
> 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.
Its a term I use and possibly hasn't been defined. It's the independence of a database from the applications that use it - the ability of a database to stand alone and be valid even if it's only 'application' is the relational language used dynamically directly by users.
> > 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.
Thank you. Of course it's not just our (by which I mean the 'database community') failure. Some would even say it is the failure of society as a whole, I would certainly not go that far, but it is certainly also a failure of the 'programming community'. E.g. I saw this today on comp.lang.functional:
} Lately, I've spent some time working with Joe Armstrong's UBF } (http://www.sics.se/~joe/ubf/site/home.html). In Joe's own words: } } "UBF is a language for transporting and describing complex } data structures across a network. It has three components: } } * UBF(A) is a data transport format, roughly equivalent } to well-formed XML. } * UBF(B) is a programming langauge for describing types } in UBF(A) and protocols between clients and servers. } UBF(B) is roughly equivalent to to Verified XML, } XML-schemas, SOAP and WDSL. } * UBF(C) is a meta-level protocol between used between } UBF servers."
[and Joe responded..]
} Actually this was the reason I designed UBF - it all goes back } to a discussion that was floating around about 15 years ago - } "wouldn't it be nice is Lisp could talk to Prolog and smalltalk etc...." [snip] } ..it appears to be at least as expressive as XML + WSDL but } at a fraction of the complexity - UBF was *designed* to be easy } to implement > > 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.
I agree with you below, but man, without TimBL there would be no WWW. Even I find it difficult to see how the relational model could have done a better job at spreading the networked world than HTML and web browsers.
> 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.
The 'semantic web' is obviously something that should be relational, and indeed it is a shame that few seem to realise it.
[snip]
Regards Paul Vernon Business Intelligence, IBM Global Services
> > 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..!!!!)
> Ha ha! At my university, I had the opportunity to take database classes > from Michael Stonebreaker, but I figured it would be about the same > thing as taking accounting.
You were probably right. Taken by Michael Stonebreaker, I guess it would be all implementation details and little theory? The class I missed is taken by Hugh Darwen would you believe.
> > > 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.
> ("defiantly" of "definitely?" Not that I am opposed to doing things
defiantly.)
Ha. I guess I meant the latter, but either are OK ;-)
> Could you expand on that? It seems to me that the core of what I get out > of TTM as far as UDTs goes is the clear definition of values and variables. > I don't see anything particularly wrong with having variables. It seems to > me the problems come when you allow variables to contain other variables. > (That is, objects, pointers, etc.) As long as all a variable can do is hold > a value, and variables can't be aliased, you are side-effect free. And > THAT I think is the real issue: ridding ourselves of side effects, and not > functional vs. imperative. (The functional guys just come out looking > better today because they've managed to free themselves from side effects. > But I'd say they did it the hard way.)
I'm no expert on FP, but I agree that side-effects are the real issue. (In relational also. Why do folks not see referential actions (and view updates!) for what they are - side effect changes to the database value)
Functional programs are at a higher level of abstraction. To quote http://www.haskell.org/aboutHaskell.html "The focus is on what is to be computed, not how it should be computed"
What, not How. Now where have I heard that before...
> > 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?
> Well, we certainly *can't* get away with one. There are application languages > and there are systems languages. Take Java and C++ today, for example. Sure, > they're deeply flawed, but they both have some cool things in them, and they're > the two most popular languages today. One is an application language; the > other is a systems language. I'd certainly hate to use either for the other's purpose, > although it can be done.
Systems languages? That's almost like including 'hardware logic' in our definition of what is needed to build applications. Systems/internals is 'under the covers', use what language you like, it's outside of my world view.
> This language I'm semi-seriously designing, is an imperative relational language. > It's great for writing applications. It'd suck to write a device driver in, in a manner > similar to how much it would suck to write a device driver in Java.
> And besides that, why not allow one language to be embedded in another? > I'd claim that's what regular expressions are: a special purpose
sublanguage.
Maybe we need a 'hierarchy' of languages, each one made more powerful that the previous by the addition of extra 'features'. The simpler ones are limited, but can be proved to terminate and are easy to optimise, the higher ones are more powerful but harder to reason about. The trick of coding then becomes to use the simplest language sensible for the problem at hand.
> > 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"
> I always figured they meant the same thing. FOLDOC calls them synonyms:
