Re: IDJIT! Your Data Model Can't Posssibly Work!

From: Jay Dee <ais01479_at_aeneas.net>
Date: Wed, 19 Apr 2006 21:31:01 GMT
Message-ID: <p_x1g.3867$YI5.2244_at_tornado.ohiordc.rr.com>


Neo wrote:

>>Bob: ORM is not a data model. Jay Dee observed that you were attacking a straw man by addressing entities and attributes instead of addressing sound conceptual modelling.

>
>
> :) Actually, Jay Dee made no such observation and I was attacking no
> such straw man. Go back and review the posts in the original thread
> titled "Multiplicity, Change and MV". I summarize below:
>
> In the original thread, OP's asked - how to avoid the headaches caused
> by changes to db schema, data, queries, code and GUI as a result of
> changes in application requirements after specifications were given,
> schema designed, code written, GUI developed and data entered. It
> wasn't a matter of improperly designing the schema initially. New
> speficiations now require a relation's attribute to have multiple
> values instead of just one.
>
> I responded to the OP that to handle the unexpected in RM (without
> incurring NULLs), he needed to use some level of generic modelling (ie
> T_Thing, T_Attrib, T_Value, etc) but this quickly becomes impractical.
> I also asserted that his situation wouldn't result in any schema
> changes in the experimental db as none is ever required (yet the data
> is fully "normalized" and queryable).
>
> Jay Dee responded to OP (not me), that the situation was the
> consequence of the approach to database design. And Jay Dee stated that
> the most resilient designs are those which accurately represent data,
> not relationships and he found Halpern's ORM approach to be helpful.
>
> Upon reading Jay Dee's response, I knew ORM wasn't applicable to OP's
> situation because:
> 1) OP's situation was not caused by poor database design, but by
> changes in project requirements after implementation.
> 2) I vaguely knew that ORM was some sort of modelling tool involving
> diagrams.
>
[snip]

[First of all: my apologies for the extremely sloppy post that appeared in this thread. Different news server, different client. I will try to avoid such nonsense in future.]

I again find myself amazed at how difficult it can be to make a simple point. Actually, Bob's synopsis of my post is accurate. Yes, I did say that the Halpin's (I mistakenly referred to him as "Halpern.") ORM* could be helpful - but only to the extent that it sets a different framework within which to analyze the real world than the Entity-Attribute-Relationship approach does.

I also misunderstand what OP meant when he said that an attribute could suddenly have more than one value. Looking over more of the posts in this group, it seems that I failed to recognize some of the "code words" used by the multi-value attribute gang. Bad on me.

I think that the "OP's originally situation" was caused by poor design. That better designs are able to meet changing requirements. That careful attention to entities results in better designs. That "relationships" and "roles" are unreal and efforts made searching for them result in distractions. That studying the events that transform entities is more useful. That it will soon be obvious that too much time has been wasted on this topic.


  • Object-Role Modeling. That OverRelational Manifesto was tough to take. The laudable effort U-Gene made to present his ideas in English kept me turning the pages thinking, "Maybe he's using the wrong words" and "Maybe he's not using the words I expect." When I arrived at the end, though, I found myself asking, "WTF was *that* all about?"
Received on Wed Apr 19 2006 - 23:31:01 CEST

Original text of this message