Re: foundations of relational theory?

From: Anthony W. Youngman <thewolery_at_nospam.demon.co.uk>
Date: Wed, 5 Nov 2003 22:54:01 +0000
Message-ID: <eE90Y3DJ+Xq$Ewmv_at_thewolery.demon.co.uk>


In article <3FA90A65.7050908_at_quest.with.a.w.net>, cmurthi <xyzcmurthi_at_qu est.with.a.w.net> writes
>byrmol wrote:
>>
>> 1) MV/PICK is not a data model by any accepted definition.
>Granted; but that's mostly because there has been no study of. It is
>more of a data handling mechanism than a data model.
>>
>>
>> 2) The logical/physical distinction in MV/PICK is unidentifiable.
>Not entirely, but much more than in a model that starts from a
>mathematical theory.

Actually, I think it's pretty clear. MV does not *enforce* a data model, but any programmer with any sense maps the physical object to the database "row" (in MV terms a RECORD).

That RECORD is equivalent to a relational VIEW of a single physical entity.
>>
>> 3) Every time anyone says the word theory, the MV/PICK people say
>> practise, which tends to justify statement 1 & 2.
>Ok.

Except it WORKS !!!
>>
>>[snip]
>>
>> But I am huge advocate of the relational theory of data for 2 valid
>> reasons and 1 selfish reason..
>>
>>
>>
>> 1) It has a general theory that has gone unchallenged for hundreds of
>> years. (Set theory - Georg Cantor 1874, Predicate Logic from
>> Aristotle 322BC to Frege, Peno, Godel and Turing & Church (1936) who
>> prove that it is not "decidable").
>
>I assume (and I can stand corrected) that this is set theory, and while
>relational theory springs from it, it's a stretch to imply that
>relational db theory was somehow even postulated in 1874 or before. But
>as I say, the theory may be provenaced there.

And set/relational theory decomposes data into its fundamental particles - like Physics decomposes matter into quarks and leptons. But there is also the "theory of emergent complexity", which says that you just CANNOT explain things like atoms, chemistry, and biology (heck, even classical physics!) in terms of fundamental particles.

By decomposing information down to its fundamental particles, relational actually makes life HARDER, because, according to Einstein's version of Occam's razor, it makes things TOO simple :-)
>
>> 2) All computer software has bugs. Lots of them! When I start a
>> project that will have some kind of DBMS, IMO the only choice is to
>> start from "perfection" (no bugs). As far as I am aware, the
>> relational model has no bugs and thus serves as the foundation for a
>> "perfect" logical/business model. To start from anything else is to
>> increase the number of bugs. Of course the actual implementation of
>> the model may not be possible with current products and can/will
>> cause bugs, but they should be fairly easy to spot.
>
>Ah, this is where we can diasagree. I think the fundamental assumption
>here has a profound misunderstanding of how application software is
>developed (now maybe you can take issue with the 'how'...but that's
>another story.) Application software is a *lot simpler* than you think.
>Business rules have little to do with set theory and, in fact, a
>database. So when you say you 'start from "perfection"', to me that's
>so vague it's a moot point. I might start from perfection with the most
>perfect paints and brushes when I paint my living room, but if I'm a
>poor painter (practitioner) it wouldn't matter at all. On the other
>hand, a master craftsman can work with his 10year old battered brush and
>leftover paint and do better.
>
>The point is, the number of bugs *may* be decreased by the purity of the
>underlying structure (of course, if you're saying that the alternative
>to the perfect db is one that actually *introduces* bugs, you do have a
>point, albeit a trivial (mathematically speaking) one,) but if, for
>instance, you use mv/pick you will not automatically be increasing your
>chances of bugginess. Integrity constraints, (etc. etc. ad naseum) can
>be enforced in both just as well or just as badly. There is no data
>structure that cannot be handled as well by pick or relational. There
>are significant pluses on either side and perhaps, significant minuses.
>
>It's a matter of style-if you are more mathematically trained,
>relational will naturally appeal to you. Most of us in the mv/pick
>world, who are from various disciplines, mv/pick is more appealing
>because it is simpler, has a much lower learning curve and is more
>flexible. We do *not* think in terms of what the db 'models', it just is
>a data-handling mechanism that fits well with our abilities (and,
>perhaps, prejudices.)

And those who are mathematically trained have a habit of thinking that the real world is determined by mathematics, rather than thinking that the real world is described by mathematics. Dare I suggest that mathematicians have a habit of putting the cart before the horse?
>
>To the user the choice...

If only it were that simple ...
>
>Chandru Murthi
>

Cheers,
Wol

-- 
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
Witches are curious by definition and inquisitive by nature. She moved in. "Let 
me through. I'm a nosey person.", she said, employing both elbows.
Maskerade : (c) 1995 Terry Pratchett
Received on Wed Nov 05 2003 - 23:54:01 CET

Original text of this message