Re: many to many relationship

Enrollment is not hidden in an ERD (which is a conceptual model) - it shows as a diamond with M:N cardinality. Can't draw it here, but in text:

|STUDENT|----- n: <enrolled> m: -----|CLASS|

If the above represents the entire model, then mapping rules happen to break this up into three relations (tables).

STUDENT{student_id PK, etc...}
ENROLLED_IN{student_id PK, class_id PK}
CLASS{class_id PK, etc...}

Regarding ERD vs. ORM, UML, etc., Use the right tool for the job at hand. Or, better yet, just enhance the ERD with your own notation. Then sell it to a software company and make a profit!

"Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message news:b4adf6$emg$1_at_sp15at20.hursley.ibm.com...
> "Alan" <alan_at_erols.com> wrote in message
> news:b4a9p3$1tdad9$1_at_ID-114862.news.dfncis.de...
> > Don't confuse the conceptual model with the physical model
>
> As if I would
>
> > An ERD models the business.
>
> My point is that classic Entity Relationship Diagrams are *not* a great
way to
> model a business if they encourage you to hide entities such as 'enrolment
> from your conceptual model.
>
> In fact as many common constraints (aka business rules) are not
representable
> graphically in Entity Relationship Diagrams, I don't find they make good
> conceptual models at all. ORM is generally much better.
>
> Regards
> Paul Vernon
> Business Intelligence, IBM Global Services
>
>
Received on Fri Mar 07 2003 - 22:30:40 CET