Re: Conceptual, Logical, and Physical views of data

From: dawn <dawnwolthuis_at_gmail.com>
Date: 6 Sep 2005 16:46:24 -0700
Message-ID: <1126050384.429291.177460_at_g49g2000cwa.googlegroups.com>


David Cressey wrote:
> "dawn" <dawnwolthuis_at_gmail.com> wrote in message
> news:1125611358.454623.172590_at_g47g2000cwa.googlegroups.com...
> >
> > mAsterdam wrote:
> > > David Cressey wrote:
> > > > mAsterdam wrote:
> > > [snip agreement]
> > > >>Does it matter if the technical
> > > >>architecture is given or not (say: we will use DBMS xyz)?
> > > >
> > > > Here's the way it works in practice for me:
> > > >
> > > > The conceptual model is implementation independent.
> > >
> > > Agreed.
> >
> > I would agree that is the idea, but it seems rare that it works out
> > this way.
>
> Not so rare in my experience.

Good deal.

> The difficulty is distinguishing a feature of
> the problem itself from a feature of some imaginary soultion to the problem.
> In other words, the difference between analysis and design.

And in theory there is a clear line between the question of "what is the system we planning to build?" and "how are we planning to build it?". However, I would suggest, as others have, that how we describe what we are building, or what problems we are solving, is necessarily influenced by how we think we will be designing a system. In some sense, analysis turns out to be an early stage in design, although I do teach them as separate. If you try to write a requirements document without any assumptions about the target system, it will be unnecessarily obscure.

> If you can keep
> analysis and design separate, you can create a conceptual model that is
> implementation independent.

That's a big "if" in my opinion.

>

> > > 2. How do we make the conceptual model explicit?
> >
> > This is probably a naive response, but where I used to choose an early
> > prototyping tool, possibly paper & pencil, even in the analysis phase
> > of a project, I now use web pages. I can mock these up even in place
> > of showing any end-user an erd (or uml class diagram) with any level of
> > detail in it. If you model the conceptual data with web pages with
> > foreign keys turned into links and sample data values, you can get a
> > lot of bang for the buck.
> >
> Interesting. I would imagine that a collection of interlinked web pages
> could model
> anything that can be modeled as a web of interlinked nodes.

Yes -- in fact a di-graph is a good modeling approach for just about ... nevermind ;-)

>

> > That seems close to what happens, although plenty of people seem to
> > think that the logical model is db independent. --dawn
>

> I'm one of them. The logical model should be DBMS independent... but not
> DBMS class independent.

If a logical data model is prepared after a choice of dbms "class", then this would work, in theory. Such selections might be better completed after a logical system design, however. I'm OK with your statement, recognizing there's a bit of grey area.

> The best success, in practice, came when two of us had finished the logical
> modeling for a DEC Rdb/VMS implementation, and it was decided to implement
> in Oracle instead. (That was about the time that Oracle bought the Rdb
> division from DEC).
> We had zero changes to make to our logical model.

excellent!

> If we had decided to implement in a non relational DBMS, or even a non SQL
> DBMS, we might have had to undo and the redo some design decisions.

>

> And, of course, all of our physical design decisions were worthless. We
> just tossed them, and started over.

An aside -- it seems to be less expensive to migrate from one non-SQL dbms to another than from one SQL-dbms to another. If your application logic is in your code instead of your dbms, then you can point your code at something else, while if you have application logic (e.g. constraints) in your dbms and you switch, you need to recode that application logic in your new proprietary language that might be something like the previous one, but often not close enough. cheers! --dawn Received on Wed Sep 07 2005 - 01:46:24 CEST

Original text of this message