Entity Relationship Diagrams (ERD)
Crow's Feet
The "Crow's Feet" notation is named for the symbol used to denote the many sides of a relationship, which resembles the forward digits of a bird's claw.
A's relationship to B in the diagram above shown is that of a one to one relationship between the two tables. Specifically this means that for every row in table A there is one and only one corresponding row in table B. This requires that the number of rows in A must be the same as the number of rows in B. Such relationships represent a kind of a choice, in that it would be possible to merge two tables related in this manner into a single table sharing all of the columns of both. Alternatively, and particularly for seismic applications, it might be better to keep two tables distinct, with B containing information of a specialized and possibly site specific nature, while A might contain information of a much more.
C's relationship to D shown above is much more common, and will help to understand the bidirectional nature of this notation. Simply put, the symbol is to be interpreted that every row of D is uniquely related to specific row of C, while every row of C is related to at most one row of D. As a pneumonic, I sometimes think of the symbol near the D entity as reading "0 or 1", since that is what it looks like. One thing that is difficult to keep sorted out, speaking for myself, is the directionality of the relationship. One can think of the terminal symbol as an arrow head, defining how one entity, C in the example, is related to another, D. Apparently some of the rows in C do not relate to any rows in D, and the corresponding "foreign key" is said to be null. On the other hand, every row of D is related to exactly one row of C. One can see, that table C must contain at least as many rows as table D, and possibly considerably more.
E's relationship to F shown in diagam, things get quite a bit more interesting. This notation reads that a given row of E is related to one or more rows in F. To accomplish this, particular values of some foreign key in F, which is also the primary key of E, might be duplicated one or more times. For example, a column in a table holding information on the arrival times of particular seismic phases might have a column (foreign key) containing an ID, which is the primary key of a table of hypocenters. In this example, the phase table is F, and the hypocenter list is E. In this way multiple phase arrivals can be "assocated" with a given hypocenter. The simple example below, however, shows that the situation is generally a bit more tricky than this for real applications. Note that every row of E must be associated with at least one row of F.
G:H shows the situation where a row of G corresponds to no row in H. This reads that rows of G are associated with zero or more rows of H. For the phase arrival example, this would mean that there could be a location for which no phase data was available. The location, perhaps, was simply typed in without supporting data.
