Diagram Conventions   «Prev  Next»

Lesson 4Diagramming entities and attributes
ObjectiveIdentify conventions for diagramming entities and attributes.

Diagramming Entities and Attributes

The Crowsfoot model neatly packages entities with their attributes by placing them in boxes. There are no hard and fast rules about how these “entity packages” should look; the important thing is that the look be consistent across the diagram.
Below is an example of a common format for a Crowsfoot ER diagram, illustrating, in this case,
  1. a standard entity (STUDENT) and
  2. composite entity (STUDENT CLASS),
with all the key types identified. Take a look at it and then read on for an explanation of its various elements.

Assume that the foreign key in STUDENT table came from a RESIDENCE entity (not shown) and the foreign key IN CLASS came from an INSRUCTOR entity (not shown).


Entity names in the box are singular and often all capital letters are used. Within the box, a line separates the entity name from the list of attributes below it.
Note: Composite entities are identified by special markings in the corners of the box as show in the STUDENT CLASS above.


Attributes are listed in a single column beneath the entity name. The key attribute is listed first, and is often labeled PK to indicate it is the primary key (another case where, for the sake of convenience, entities and tables share terminology). When an entity receives a PK from an associated entity, that attribute is labeled FK to indicate that it is a foreign key (in other words, the primary key from an associated entity).
Composite entities have composite primary keys, labeled CPK/FK. In the graphic above, the two attributes labeled CPK/FK indicate the two primary keys the composite entity STUDENT CLASS received to form the links to STUDENT and to CLASS.
The next lesson illustrates the constructs used to diagram types of relationships with the Crowsfoot model.