ER Diagrams

[Carol Farlow Lerche <cafl msbit com>]

I have been following the discussions re ER diagrams with interest, as
the use of dia for database schema design is my reason for subscribing
to this list.  I apologize for the long post, but I think at least
some of the previous posts have been a bit strong.  Executive summary
of this post: it would be useful if dia/tedia2sql supported the
variants of ER notation known as crow's foot and IDEF1X as well as UML
notation, because conceptual data models in these notations have been
found by some to be easier to convey to the business stakeholders than
ones using UML class notation.

The ER diagrams supported by dia are, as has been stated, the original
Chen notation.  This notation is still used in academia but is not
used in real projects, as far as I know.  There are two notation
variants that are used in "real life": crow's foot and IDEF1X.  Tools
like "ER Studio" support both.  The difference is really in the
connectors used to join entities and represent optionality and
cardinality. The following url is a reference that shows the crow's
foot notation:

http://www.utexas.edu/its/windows/database/datamodeling/dm/erintro.html

IDEF1X is a FIPS standard (Integration Definition for Information
Modeling (IDEF1X). FIPS PUB 184. National Institute of Standards and
Technology (NIST): 1993.)  Online, have a look at this url:

http://www.idef.com/idef1x.html

I would not say that UML has eliminated the use of ER diagrams, as was
stated in a prior post, although there is certainly a faction that
holds that UML diagramming is the only thing worth using.  UML is
recognized even by its proponents as being more complex and harder to
use for communication to the non-technical members of a project.  This
is a religious war.  I would prefer to say that both are useful,
instead of instigating a battle of words.  You can translate ER
diagrams directly into UML diagrams, and there are some things that
can't be represented in an ER diagram that are representable in UML.
ER diagrams can be used for conceptual, logical, and physical
modelling.  I use them for all three, but the commercial
tools don't do a good job of transitioning from conceptual to logical
to physical.

I think the best discussion of the food fight between data modelling
and object modelling is by Alexander Cockburn, in my opinion one of
the best writers on the so-called "agile methodologies" and (I believe) the
originator of the use case as a requirements gathering tool.  At this
url
(http://alistair.cockburn.us/crystal/articles/oltoon/openlettertooonewcomers.html)

he answers this question: "Would the model produced by a data modeler
look the same or different as the structural part of an object model -
would the model produced by a process modeler look the same or
different as the behavioral part of an object model?"

"Those who model the information in the system produce the conceptual
data model. My experience is that the models they produce are very
similar to the models produced by experienced OO modelers. These
people typically work a lot closer to the business people than do the
logical data modelers, which perhaps explains the difference in their
results.

"Also, there seems to be a body of knowledge, lore, training, or
examples that let these people come to their results faster than OO
people do. I have time and time again seen OO people go through three
or four design iterations, ending up with the same model that the
(conceptual) data modelers produced on the first round. So I have a
lot of respect for the data modeling community. In fact, when I get
stuck in the object design, I sometimes run and snatch a copy of what
the data modelers produced, to look at where we are likely to end up."

Thanks for your patience in reading this.

Carol Lerche