Re: Relation or attribute and why

David Cressey wrote:
> "Gene Wirchenko" <genew_at_ucantrade.com.NOTHERE> wrote in message
> news:m419725upa1r1cbsjngurlc7sr7i12b47p_at_4ax.com...
>

>>On Wed, 24 May 2006 12:33:43 GMT, "David Cressey"
>><dcressey_at_verizon.net> wrote:
>>
>>[snip]
>>
>>
>>>I disagree.
>>>
>>>Conceptual Data Model has enough detail to describe the problem domain

>>>a data centric point of view.
>>>The napkin model doesn't.  The difference between the napkin model and

>>>CDM is analysis.
>>
>>     Of course.  A conceptual model (and note that I do not put the
>>word "data" in there) is that undetailed.  That is what the analysis
>>is for, and the result is a logical model.
>>
>>     What do you disagree with?

"Me too!" Although I must admit, when describing systems at the conceptual level, we're seldom talking about data. One glaring counterexample is the Snodgrass and Jensen (I think, or was it Christiansen? ) description of the "Bitemporal Conceptual Data Model." It just goes to show...

> A conceptual model and a conceptual data model
> may or may not be the same thing.

...that, "It all depends." And I have the uneasy feeling that somewhere along the line, we should shake off this cloak of relativism and settle upon language that gets us somewhere. Far too much time is spent explaining, "What I meant was..."

> As far as level of detail goes, a model that fits on a napkin is good for a
> casual conversation in a bar or restaurant. That could be the beginning of
> a formal project, but it's hardly the end of conceptual modeling. The thing
> that attracted me to OOA by Coad and Yourden is that they don't split the
> conceptual model into a data model and a process model.

Translating a concept into a design into an implementation has been a particularly sticky problem. "Data flows" are useful in some contexts but "control flows" seem more useful in others. The difference seems to be that imperative code, while obviously "process" in the first instance, is more easily treated like "data" in the second.

I was particularly impressed with a technique used by an aircraft manufacturer in which the two were pulled together. They had a set of boxes and blobs and lines and connectors and arrows, etc., that captured it all. Loaded with jargon, of course -- but it worked. Received on Fri May 26 2006 - 12:06:43 CEST