Understanding Entity Relationship Diagrams
Entity relationship diagrams, or ERDs as they are fondly known in the field, contain a wealth of information
on the architecture of a relational database. Unfortunately, those not actively working on database design
issues are likely to find them confusing, intimidating, and sometimes aggravating. In this brief tutorial I will
try to dispell some of this miasma. Like so many things, it turns out that understanding a few key concepts is
all that is required. This section is meant as a broad, rather high level introduction to the major concepts
surrounding relational databases. This is a very broad and rapidly growing field, so that it is only possible to
just barely scratch the surface. Fortunately there are now a great number of well written books on the subject.
An entity relationship diagram at best can only be considered a static picture of the "structure" of a database.
Nothing is revealed regarding the flow of data, or anything else that relates to how the data changes.
However, exploring an entity relationship diagram is often a first step in understanding a databases design.
Unfortunately, one gets the impression that at least in some cases the design process may have stopped with
the ERD, with many incongrous columns added "just in case". To some extent, reviewing an ERD is a bit
like an archeological expedition, knowning that a particular room in a ruin was used for religious ceremonies
without having any idea what rituals were performed or even who might have conducted them.
There are actually a variety of possiblities used in industry to generate entity relationship diagrams. The one
described here and used throughout this document is known as "Crow's Foot" notation. I believe the reason
for this should become obvious shortly. Of the three approaches considered here, all used different notations,
and none used "Crow's Foot". We use it here because it is the accepted
convention, it is supported by the
® drafting program, and it is ubiquitous in
articles and books describing
® applications. Also, once one convention is understood, it is not
difficult to read diagrams using the others. For purposes of the comparisons in this document, I found it
conventient to recast the three approaches into the same notational convention.
There are two basic components comprising an entity relationship diagram, entities and relationships. Entities
can be invisioned as tables with columns and rows somewhat like a spreadsheet. Each column has a name
and contains some certain type of information such as the latitude of a hypocenter, or the arrival time of some
seismic phase. The table itself also has a name by which it is referenced. Rows represent a particular instance
of what the table represents. For example, an origin table might contain one row for each location that has
been calculated. In the old days, columns were referred to as attributes, and rows were called tuples. It may