--- "Frederick D. S. Marshall" <[EMAIL PROTECTED]> wrote:
> Dear Matthew, > [...] > > All databases exist to record an abstract model of pieces of the > world. > Databases are usually structured as files (or tables or classes), > each > of which lists entities of a similar kind, such as patients, or > drugs, > or visits. Just as the file represents a category of entities, so > each > record (or entry or row or object or instance) in that file > represents a > specific entity, such as a specific patient, a specific drug, or a > specific visit. Databases, files, and records are not the real > things > they represent, only abstract representations of them. An entry in > the > patient file is not a real patient, but an abstraction of a patient, > a > metaphor for that patient. Very much as with poetry, the more > closely > that metaphor matches the important parts of the real thing it > represents, the more powerful the metaphor, the more meaningful, and > from the perspective of medical informatics, the more likely it is to > > assist in improving patient health. Whether you have the right > information and whether you have organized it into the right metaphor > is > largely dictated by how that information will be used--that tells you > > which operations can be inefficient and which need to be efficient, > which tells you how to balance the tradeoffs that are always > involved. > > A good database designer chooses apt metaphors that match well the > kinds > of information the clients need to record. The strategic part of > that > choice involves selecting the right database paradigm; the tactical > part > is using that paradigm effectively. WHICH data a file records is up > to > the file designer, but HOW that data is stored is up to the database > paradigm you choose (relational, hierarchical, network, polymorphic, > object-oriented, etc.). As with successful adaptation in nature, the > > secret to success lies not with rigid orthodoxy but with responsive > flexibility, varying your approach to let each problem dictate its > own > best solution. > 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. > [...] === Gregory Woodhouse <[EMAIL PROTECTED]> "Without the requirement of mathematical aesthetics a great many discoveries would not have been made." -- Albert Einstein ------------------------------------------------------- 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
