Re: Why bother with Logical data model?

"David Portas" <REMOVE_BEFORE_REPLYING_dportas_at_acm.org> wrote in message news:1155203013.461762.241750_at_i42g2000cwa.googlegroups.com...
> Brian Selzer wrote:
>>
>> I don't agree with your characterization of confusion, nor your
>> definition
>> of the physical model.
>
>
> It is not my definition. It is the one defined by Codd, by industry
> standards (ISO 2382 and also the ISO SQL standards) and all good
> textbooks that I know. Representation of data in an RDBMS as relations
> or in a SQL DBMS as tables is a LOGICAL representation, by definition.
> A standard SQL CREATE TABLE statement defines the Logical Model not the
> physical one. The Physical Model is always implementation defined and
> typically consists of files, devices, volumes and other structures
> (perhaps data pages but not usually "tables") that map the logical
> level onto storage.
>
> So your statements about the logical model being absent and the
> physical model being denormalized don't make any sense. How can you
> use a database without tables? How can a file or device be
> denormalized?
>
>> On the other hand, the decision to use a partitioned view to improve
>> performance does affect the physical model because additional database
>> objects are needed (tables and views)--not because the underlying tables
>> and
>> indexes will reside on different storage media.
>
> No. The decision to create additional tables and views affects the
> *logical* model because by definition those are objects in the
> database's logical model. Your stated intention is to change the
> physical model as well, however there is no need to assume that this
> *must* happen or that such a logical change will *always* affect the
> physical model. For example, multiple tables could easily have exactly
> the same physical representation as a single table.
>
> As Kenneth mentioned, your remarks and the OP's question do make some
> sense if you read "logical model" as "conceptual model" or "business
> model". This is a fairly common attitude but it is technically a big
> mistake.
>

Thanks for the naming correction. I've often been guilty of using the wrong term for things database. I remember the first time Joe Celko raked me over the coals because I used the term, "field" instead of "column." On the other hand, I think it's important to separate what is the minimum information required to meet business needs from how implementational issues can affect that database schema, and to model them separately, regardless of what such models are called. I think I'm choking on the term model. The locations on the physical media upon which the information is recorded and whether or not those locations are organized into files is in my mind more an implementation than a model. But as I've been told many times, I'm often wrong.

> --
> David Portas
>
Received on Thu Aug 10 2006 - 16:25:18 CEST