Re: Entity Relationship Diagrams
Date: Wed, 11 Apr 2007 13:06:30 GMT
Message-ID: <q35Th.23264$PV3.230752_at_ursa-nb00s0.nbnet.nb.ca>
David Cressey wrote:
> "Gregc." <gregchilton_at_bigpond.com> wrote in message
> news:1176284039.467335.142540_at_b75g2000hsg.googlegroups.com...
>
>>Hi >> >>I am currently drawing and ER diagram and am not sure about how to >>draw the diagram for the following: A bike must have at least 2 wheels >>but it may have more. The way that I would draw it is thus: >> >> BIKE-------< WHEELS (ie crows feet with no line) >> >>Would anyone have a suggestion on this. >> >>Greg
>
> As Roy said, there are lots of different notations. Here's my suggestion:
>
> Don't attempt to use the crows' feet to express anything more than "one" or
> "more than one" at either end.
> I don't even use the little bars to express "mandatory" or "optional" , but
> you may differ.
>
> If you want to express cardinality of relationships a little more precisely,
> I suggest the min:max notation, right next to the end of the relationship
> line. In the case of a bicycle which must have at least two wheels, but
> might have more, this would be "2:N".
>
> As far as whether or not ER diagrams are a "good thing" that issue has
> surfaced repeatedly in this newsgroup. Here's my opinion:
>
> First, let's separate out attitudes about the ER model, and attitudes about
> diagrams.
>
> I like the ER model for expressing data requirements on a database. It's
> useful for communicating with stakeholders (uncluding users) about that
> subject. It is NOT useful for conveying database design, and I claim
> intentionally so. Many of the regulars in this newsgroup prefer modeling
> data requirements directly in the relational model. I don't.
I don't know where you are getting that last idea. I suggest english sentences suit requirements gathering, recording and communication. In general, plenty of concepts exist at the conceptual level that never make it into the logical design. See "external predicate".
> Second, what about diagrams? I like diagrams. I used them, back when I
> was doing this stuff, as a backdrop for meetings, conversations, and
> presentations about the subject. However, good diagrams are simple
> diagrams. A diagram is useful as much for what it leaves out as for what is
> puts in. The problem with many diagrams is that they try to be as
> comprehensive as a spec would be. I claim that's a mistaken use of
> diagrams, and defeats the whole purpose of conveying "the big picture".
>
> So.... I would say that there are features in an ER model that should be
> left out of the matching ER diagram. Minimum cardinalities beyond one is
> one of them, in my book. But suit yourself.
In computing science, as in most of mathematics, graphical methods are pitfalls for the unwary. I have thought about this very issue for the past few days.
In the physical sciences and when engineering physical artifacts, some graphical methods have great utility. Physical artifacts obey constraints of the physical world, and this obedience makes those graphical methods work.
In mathematics, no such constraints exist. As a result, graphical methods often lead to incorrect conclusions or at best a lot of special cases to analyse.
IMO, people get drawn to graphical methods in the mistaken belief that what works for engineering buildings and vehicles will work for engineering software. Received on Wed Apr 11 2007 - 15:06:30 CEST