Re: Mixing OO and DB

"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
> >
news:ce09666e-ca81-4da4-95e2-11c358049614_at_h11g2000prf.googlegroups.com...
> >
> >>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.

That's not the way I learned it.

The way I learned it, the conceptual data model captures only those features of the data that pertain to the requirements. In the case of a database, the conceptual data model need change ONLY when the requirements change. The conceptual model is an analysis model, not a design model. It also is a data model that need not be a database model.

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.

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.

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.

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

Strongly agreed. And it's this failure to recognize the multiple layers of the logical/physical distinction that leads sloppy thinkers to throw out the entire concept, or to relegate the concept to the level of a general hand-wavy concept, and lose its clarity and usefulness.

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

A very useful distinction.

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

It depends on what you mean by a DBA. There are DBA's in the field who have no authority over, and no responsibility for, the data as it pertains to the application(s) that manipulate it. While I tend to think of such people as glorified database baby-sitters, this division of jobs makes a lot of sense to a lot of people other than myself. Received on Mon Mar 10 2008 - 15:18:15 CET