Re: Conceptual, Logical, and Physical views of data

"dawn" <dawnwolthuis_at_gmail.com> wrote
> David Cressey wrote:
> > "dawn" <dawnwolthuis_at_gmail.com> wrote

> > 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.

And this can be called "thinking inside of the box". "The box" is not a feature of the problem itself,
but of our early attempts to frame the problem in terms of a solution.

> 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.
>

The skill is to recognize elements of design in your analysis, and back them out. They don't need to be necessarily discarded. They just need to be identified as elements of design, and, as such, subject to review. Elements of analysis can be reviewed, but the review process is different.

> > 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.

I disagree completely. In my experience, it's just the opposite. Tables and indexes port very readily from one SQL DBMS to another. I've never attempted a port from say IMS to VAX DBMS or vice versa, but those who have report to me that's it's very difficult to sort out what features of the design are product specific from what features are generic.

> 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!

All programmers feel this way about databases. Your problem isn't that you don't like relational databases, or the relational data model. Your problem is that you don't like databases, period.

I still think that it's easier to understand 500 tables than 100,000 lines of code! (thanks, Paul C.) Received on Wed Sep 07 2005 - 08:59:54 CEST