Re: Do Data Models Need to built on a Mathematical Concept?
Date: Fri, 25 Apr 2003 08:29:59 -0700
Message-ID: <b8bk2f$8cccm$1_at_ID-152540.news.dfncis.de>
Ian wrote:
> Do Data Models Need to built on a Mathematical Concept?
>
> Example, The relational model has set theory.
Jayadev Misra once said: (
http://www.cs.utexas.edu/users/misra/Speeches.dir/Schlumberger.Jan02.pdf
) :
"...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
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. Received on Fri Apr 25 2003 - 17:29:59 CEST