Re: Another view on analysis and ER

From: JOG <jog_at_cs.nott.ac.uk>
Date: Fri, 14 Dec 2007 04:11:50 -0800 (PST)
Message-ID: <063debb1-a596-4142-944a-dab1ba17f8d7_at_d21g2000prf.googlegroups.com>


On Dec 12, 7:32 pm, rp..._at_pcwin518.campus.tue.nl (rpost) wrote:
> JOG wrote:
>
> [...]
>
> >> >So why on earth would /anyone/ want to drop step 3? I'm at a loss as
> >> >to why certain cdt'ers (who are clearly intelligent people) seem to be
> >> >advocating this. An absolute loss I tell you.
>
> >> Being new here, I have no idea whom you're referring to.
> >> You'll never see *me* omit step 3, But I don't buy your "neutral".
>
> >As far as I understand OODBMS, they do drop that step 3, because they
> >directly translate a single conceptual model into an identical logical
> >one. In general, I think much of our conversation has probably crossed
> >in the mist anyhow Reinier. I'm thinking of it as a 'lack of beer'
> >issue, in that if we were discussing it at the pub, instead of on
> >usenet, there probably wouldn't be any confusion ;)
>
> Yes, I've seen that advertised as the whole point of having OODBMSes:
> the database would act as a more or less transparent object model
> "persister". (Just like XML databases, which persist XML documents.)
> This implies a pretty drastic change to the nature of the relationship
> between database and application, but I'm not convinced it's always bad
> to do things that way.

No, I would never say always a bad thing. However, for shared data specifically I would say alamost always.

>
> Moreover, an OODBMS doesn't force you to omit step 3.

This I am unclear of. Does an OODBMS not tie the logical encoding into one binding conceptual view?

>
> Finally, an OODBMS was never the reason for my defense of ER modelling
> in the first place. My reason is not wanting to skip steps 1 and 2!
>
> | 1) initial analysis of business processes and important concepts.
> | 2) Formulation of an initial conceptual model (that is necessarily
> | slanted to a certain viewpoint of the UoD).
> | 3) Translation into a nicely normalized logical model, that's query
> | neutral.
> | 4) On demand, extract data back out from the neutral logical model,
> | shaping it either the original conceptual view, or other conceptual
> | views as needs arise from new applications.
>
> If we take steps 1 and 2 seriously, we'd better have a decent formalism
> to denote and reason about their (intermediate and final) results, and
> ER modelling fits the bill rather well, which should be little surprise
> considering that everybody already uses it for that purpose.
>
> So I don't really see any disagreement between our positions.

Oh, I don't disagree that E/R can be useful if used wisely by someone knowledgeable of all the steps of the data modelling process they are undertaking (even though I have a strong preference for NIAM/ORM myself). It's just using an E/R or OO model at the logical layer that I would warn against. Regards, J.

>
> [...]
>
> >But welcome to cdt. It can get rawkus in here, [...]
>
> So I've noticed :) That's OK.
>
> --
> Reinier
Received on Fri Dec 14 2007 - 13:11:50 CET

Original text of this message