Re: Conceptual, Logical, and Physical views of data

David Cressey wrote:
> "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".

Or simply shorthand, recognizing that the cost of doing analysis while making no assumptions is likely not worth the benefit. It is a risk and if the risk is high enough, then it needs to be mitigated. Additionally, when reviewing the analysis, the readers/designers should make an effort not to be trapped by solutions present in the analysis.

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

Yes, but they don't need to be backed out in the writing, recognizing the risk.

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

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

Constraints? Derived data (e.g. stored procedures)? SQL code (and ODBC)?
> 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.

Sounds likely. My experience has been that it was more difficult to map between modeling approaches when one side (source or target) is a SQL-DBMS. Other models map more handily to each other. Perhaps this is because you don't have to split out all of the weak entities for most non-SQL-DBMS products, or maybe because more of the constraints are in the code rather than converting them between app code and dbms code. I don't have enough experience in this regard to generalize, however (no OO-DBMS experience, for example).

>
> > 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'm almost willing to say "Good catch, David". I might lean that way. However, I do want support for transactions, backup & recovery, logging, security, derived data, query languages, indexes, caching, logical schema, ... . I suspect SQL is more of an issue for me than the relational model now that the relational model seems to have evolved to include what was once non-1NF (NF2). I do want navigational operators, however and that seems to go against relational theory. I want to "click on" a foreign key value and navigate to the referenced entity.

> I still think that it's easier to understand 500 tables than 100,000 lines
> of code! (thanks, Paul C.)

Why have either of those options? I'd go for a reasonable number of tables, close to the number of strong entities, combined with a reasonable number of services/interfaces.

--dawn Received on Wed Sep 07 2005 - 22:48:31 CEST