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 - 16:31:01 CDT
