It is important to understand the different notations that are available in data modeling.  I am biased to Crow's Feet database modeling notation, Because it is easier to understand the images and visual clues than to read the words.  This style of notation is useful with high-level logical and enterprise data modeling designs.  I wanted to make sure that I use these symbols so that our users/clients understand how the pieces of the puzzle come together. 


To keep the information relevant to the users.  Let us use a school administration configuration to display the different elements associated with a Entity Relational Model (ERD) Diagram.

Entity - A person, place, event or thing about which we want to collect and store multiple instances of data.  It has a name, which is a noun, and the attributes describe the data we are interested in storing.  It also has to contain an identifier, which uniquely identifies one instance of an entity.


Relationship - Illustrates an association between two entities.  It also may have a description ( title ) attached to it which is a verb, which describes the relationship between the two entities.


Cardinality and Modality are the indicators of the business rules around a relationship.  Cardinality refers to the maximum number of times an instance in one entity can be associated with instances of another related entity.  Modality refers to the minimum number of times an instance in one entity can be associated with an instance in the related entity.

Cardinality can be 1 or many and the symbol is placed on the outside ends of the relationship line, closest to the entity.  Modality can be 1 or 0 and the symbol is placed on the inside, next to the cardinality symbol.  For a cardinality of 1 a straight line is drawn.  For cardinality of many a "foot" with three toes  is drawn. 




Modality of 1 a straight line is drawn, while for modality of 0 a circle is drawn




Cardinality and modality are indicated at both ends of the relationship line.  Once this has been done, the relationships are read as being 1 to 1 (1:1) , 1 to many (1:M), or many to many (M:M)

Bridging Entities

The "Many to Many" scenario is a special one.  This is when an instance of an entity can be related to multiple instances of another entity and vice versa. In the example below a student can be "enrolled in" more than one class and a class can be "offered to" more than one student.


While this model is valid, it is impossible to translate directly into a relational database design.  In a relational database, relationships need to be implemented by having a column of a table that points to a correct instance in a related table.  A many-to-many relationship does not allow this relationship expression, because each record in each table might have to point to multiple records in the other table.  In order to build a relational database that captures this relationship, it is necessary to build a bridge between the two entities that uniquely expresses each relationship instance.  This can be modeled in an ERD with a “bridge entity,” an entity box containing a diamond, which may replace the many-to-many relationship. (The diamond is used in other ER modeling systems to indicate relationships, or may be viewed as the joining—the bridge—of the many-to-many “crows-feet”).



This diagram expresses the same relationship as the diagram abo ve.  Each instance of the "Student" bridge entity indicates that a certain student is enrolled in a certain class. In addition to explicitly depicting a relational database structure that can capture a many-to-many type relationship, the bridge entity has an additional function in abstract entity-relationship modeling: A bridge entity may capture attributes that a specific to the relationship between instances of the bridged entities.  In the student and class example, a class does not have an inherent cost; it only has a cost in the relation to the supplies needed for that class.  Any attributes that are dependent on the relationship would be associated with the relationship's bridge entity.








I got the following image from Scott Ambler's web site.  Be sure to look at www.AgileData.org for some good information