Re: Conceptual, Logical, and Physical views of data

David Cressey wrote:

> My introduction to databases, back in the 1980s, was, in part, by way of
> Martin. I got this description of multiple views of data: the
> conceptual, logical, and physical views.
>
> The conceptual view of data: the data as seen by the subject matter
> expert. The meaning of each of the values, in context, is part of the
> subject matter
> expert's domain. Database structure is not the domain of the SME, in that
> role.
>
> The logical view of data: the data as seen by the programmers. The
> people who store and retrieve data from a database (or who write software
> that does the same thing) view the data in terms of its appearance at the
> interface.
> Structural aspects of the data that are visible at the programming
> interface are part of the logical view. Structural aspects that are
> transparent at the interface are not part of the logical view. Structural
> alterations at the logical level may require program maintenance, but
> structural changes at the physical level will not.
>

Methinks there is a lot of mischief here that comes from taking something and dressing it up much fancier than it really is or deserves to be.

First some imagery. The SME, the end-user (typist), and developer are all in orbit about the database. It is forgivable if the SME and typist look in the sky and think the Sun (database) goes around the Earth (insert false god here), but it is up to the developer to point out that all goes around the Sun.

Now in simpler terms what I mean is that the database should be thought of as what it is, a record-keeping system. The laws of normalization give us ways to organize our records, and the reporting tools allow us to present it as is useful in any particular situation.

Taking this to its complete extreme, there are no different "models", there is only the data, which is organized to be comprehensible or not. If the record-keeping system is organized in a way that makes sense, then the SME will recognize it, with various amounts of salesmanship. If the SME never recognizes it, you have a dead-end client if you are into quality and a gold mine if you believe "there's one born every minute".

The implications of this for the typist tend to be rather obvious. If the records (read: tables) are organized well, then the UI will fit to the tables like dipped latex. There is no separate model for the typist because they are following the tables.

Finally there is the programmer. This word is actually problematic, do we mean the database designer or the coder? Well both should be doing the same thing, which is to implement the table design. Again, there is no special model for them, there is only the implementation of the record-keeping system. The more "abstraction" there is between the programmer and the tables, the more likely they are doing it wrong. The tools they use should bring them up close to the tables, allowing them to easily implement the table specs, rather than abstracting the tables out to the distance.

My two cents.

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth_at_(Sec)ure(Dat)a(.com)