Re: Mixing OO and DB

David Cressey wrote:

> "Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message
> news:47d53e64$0$4037$9a566e8b_at_news.aliant.net...
>

>>David Cressey wrote:
>>
>>>"Marshall" <marshall.spight_at_gmail.com> wrote in message

>>>>On Mar 9, 6:08 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:
>>>>
>>>>>I don't agree with this.  You're equating the database schema with the
>>>>>database implementation.  The schema specifies what information is to be and
>>>>>can be recorded.  As such the schema is an integral part of the application
>>>>>specification, and it cannot be decoupled, but that doesn't mean that the
>>>>>database implementation cannot.  The schema does not specify how information
>>>>>is physically  recorded, nor does it specify the process by which the
>>>>>recording takes place.  That belongs to the implementation, and that can
>>>>>certainly be decoupled and probably should be.
>>>>
>>>>Just so.
>>>>
>>>>This is a difficult distinction for a lot of people to make, however.
>>>>Vanishing few software tools even attempt to make any distinction
>>>>between the logical and physical, so few people have an opportunity
>>>>to see the distinction in action.
>>>
>>>In addition, the logical/physical distinction has not been defined
>>>consistently among all the people teaching other people about databases.

>>>I learned relational DB practice back in the mid 1980s, and learned SQL a
>>>couple of years later.  The logical/physical distinction was decribed for me
>>>by my mentors in ways that are subtly different from the way the same
>>>distinction is discussed in c.d.t.
>>>
>>>Actually, when I first learned this stuff,  the distinction made was
>>>conceptual/logical/physical.
>>>
>>>As far as modeling tools go,  the tool we used in the mid 1980s was pencil
>>>and paper or whiteboard and marker.  As far as real software tools go, the
>>>only one I used much was "Data Architect"  about 2000.  Data Architect, at
>>>that time,  managed two kinds of data models:  conceptual and physical.
>>>
>>>The physical model contained schema objects and database objects.  The
>>>database objects,  things like Oracle tablespaces, were completly invisible
>>>to the application programmer.   The schema objects,  things like tables and
>>>procedures were generally visible to the application programmer across the
>>>interface.
>>>
>>>While this does NOT address the point you make above thoroughly,  it's a far
>>>cry from not even attempting to make any distinction.  I don't know what's
>>>become of DA in recent years.
>>>
>>>I can add more detail about the conceptual/logical/physical distinction as I
>>>learned it.  However,  every time I post such material in c.d.t. It gets
>>>dismissed as simply "wrong",  and I get told to read enough D&D to become
>>>orthodox.  I don't need to repeat this exercise.
>>>
>>>Marshall, if you are truly interested,  perhaps we can exchange e-mails. I
>>>don't intend to convert you to the way of thinking that I learned back in
>>>the 1980s.  But I think there's enough ore mixed in with the slag there so
>>>that you should extract the ore and integrate it into your emerging world
>>>view.
>>
>>I don't recall what you were taught about conceptual/logical/physical,
>>and I am not sure exactly what D&D's position is. However, the standard
>>vocabularies make the distinctions clear:
>>
>>Conceptual is the domain of all information of interest to humans.
>>Logical is the domain of data, that subset of information suitably
>>represented for machine processing without reference to any specific device.
>>Physical is the domain of actual devices.

In a way, are you not saying the conceptual model is limited to the information humans actually care about?

> In your writings, you tend to relegate the conceptual model to an English
> language description of the requirments. I don't. Unlike you, I value
> graphics. "Pretty pictures" are a valuable tool in abstracting out
> irrelevant detail when discussing requirments, and possible solutions, IMO.

I disagree with your characterization of my writings.

Conceptual analysis is about capturing and communicating what's inside people's heads. I am quite happy to use any number of artifacts and any number of media for such communication.

In essense, conceptual analysis is an exercise in applied psychology. It's at this level of discourse where one would record and communicate usability results from paper prototypes, card sorting etc. as well as domain expert interviews, governing legislation etc.

I would even agree that effective graphics can be very useful to illustrate points. What I find less useful is graphical analysis. The graphical analysis methodologies use graphics far too often and for the wrong purposes. Graphics used for reasoning can introduce pitfalls, special cases and illusions that are easily avoided when reasoning by other more formal methods.

Domain experts, in particular, are more likely to agree that any pretty picture is correct than admit they might not understand the picture. Presenting the exact same information in formalized english will elicit the disagreements that eventually reveal the truth. The most important ones are the "Yes, usually, but not always" responses.

> The logical model captures those features of the design that pertain to the
> CLASS of database being built, but not to the specific DBMS. Thus, an
> implementation that's being ported from Oracle to SQL Server should survive
> the port with the logical model almost intact. But a port from Oracle to
> some kind of OODBMS would NOT carry the logical model with it.

Are you not saying that different formalisms require different representations and that the logical model captures the data represented suitably for the formalism in question?

> The physical model captures features of the implementation. Some of the
> physical design features should conform to the logical model. For example,
> the table design should conform to the logical design's description of the
> data. However, in addition to the logical model, the physical model is
> also affected by: the choice of a particular DBMS; the volume; the load;
> the computing resources; the response time requirements; etc.

Are these not the characteristics of the physical devices and structures used?

>>Something that might be logical from one perspective might be physical
>>from another.

It's also an opportunity for people to talk past one another.

>>The standard vocabularies also make clear the distinction between
>>internal and external.

>>Most discussions on c.d.t would take a perspective similar to the DBA's.

I mean someone who manipulates the physical structures and devices as well as the logical constructs of the database as the requirements change. ie. Someone who administers one or more databases and associated systems--not someone who merely swaps backup tapes. Received on Mon Mar 10 2008 - 21:46:38 CET