Dear Greg,
You have put your finger on my point about MUMPS, the relational model,
the hierarchical model, and so on--they are just the raw materials.
They shape the way we solve the problems we face, but they do not
usually prevent us from solving problems. If I am an architectural
designer working with a client, the conversation is far more productive
if we focus on what the client wants in terms of functionality--a
hospital, a house, a bridge--rather than the client wasting their time
telling me they have heard that cement is superior to steel.
I completely agree that the table is no more the ultimate abstraction of
the relational model than the tree is of the hierarchical model. At a
panel session at the MTA annual meeting in the mid-nineties, during a
discussion of database paradigms, it first occurred to me as I was
talking that the relational and hierarchical models were mathematically
equivalent, and that an intelligent DBMS should be able to
mathematically morph the same data back and forth between the different
equivalent structures. This struck me because I was objecting to an
audience member who believed that the relational model had invented the
ideas of keys, indexes, relationships, and so on. I was trying to
explain that all of the major database paradigms share such common
concepts, that the differences lay elsewhere. I was just starting to
argue it was in the geometry each used to represent one-to-many and
many-to-many relationships when it struck me that the work of Greg Shorr
for IHS on QMan and of Tami Winn for VHA on the Meta-Data-Dictionary
demonstrated their mathematical equivalence.
The whole point of abstract data types is to get away from such
primitives as trees and tables to metaphors that better match the real
things we want to describe--patients, visits, nurses, etc. This is why
it is good that object orientation has come to dominate computer
science--it is the most ruthlessly committed to strong metaphors.
However, the idea of such higher-level abstract data types is in no way
specific to the relational model. Most of the interesting things you
can do with any database paradigm are common to them all. To answer a
question like how are the relational and hierarchical paradigms
different, we have to reduce them down to what makes them unique, to
caricature them. You are right, though, that it is crucial thereafter
to re-generalize, to explain that none of these paradigms are limited to
their primitive abstractions.
Yours truly,
Rick
Greg Woodhouse wrote:
I find it useful to think in terms of data types. I believe that what
you are saying here is that it is important to abstract away from the
primitives used to implement other types. Just as pointers are the
basic primitive used in a language like Pascal to implement abstract
data types, tuples and relations are the basic primitives used in the
relational world to model other structures. I believe it is
unnecessarily narrow (and in fact, a caricature of the relational
model) to think of the table as the basic *abstraction* of this model.
That would be like saying pointers and subfiles are the basic
abstractions with which one works in Fileman. That's just not true.
They are *primitives* used to model abstractions that can be quite
complex.
Think about this way: Bricks and mortar may be used to construct
buildings (well, maybe not out here in earthquaqke country), but when
an architect looks at a building, (s)he does not see (just) brick and
mortar. There is much more that can be said about buildings than simply
that they are built out of certain fundamental components.
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
