The ERW Graphical Notation

The diagrams created by ERtool use graphical hints to suggest cardinality constraints, subtyping and identification functions. The conventions used are, unfortunately, mostly idiosyncratic. After a careful examination of the existing notations, major theoretical or practical flaws where discovered. In some cases, the notation would have worked just for binary relationship types. In other cases, it was utterly counterintuitive.

Thus, ERtool uses its own notation, which is directly derived from Chen's, but also borrows from the standard mathematical notation, Object Role Modelling, and a bit of fantasy.

Entity Types

Entity types are represented by boxes containing the type label. No attributes are shown, as they are hyperlinked, and can thus be easily accessed. The border of abstract types is dashed.

Figure 2. An entity type.

Figure 3. An abstract entity type.

Subtyping is represented by a dashed arrow from an entity type to its direct supertype(s).

Figure 4. An entity type with a subtype.

Weak entities are marked by a double frame, as in standard entity-relationship diagram practise. Identification functions are simply represented by a bold arrow from the weak entity type to the owner (the name is not relevant, as there can be at most one such function between two entity types)

Figure 5. An weak entity type and its owner, linked by an identification function.

Relationship Types

Relationship types are represented by diamonds containing the type label (again, no attributes are shown). Relationship types that are to be instantiated to multirelations are shown with a thicker border (as multirelations are somehow fatter than relations).

The representation of the remaining cardinality constraints is very simple: a cardinality constraint of the form (1:x) adds a black dot at the end of the corresponding leg. Thus, when you see a black dot you should read "mandatory" (as in Object Role Modelling). A cardinality constraint of the form (x:1), instead, generates an arrow tip near the diamond. This corresponds to the mathematical fact (explained in detail in the Section called Cardinality Constraints in the Chapter called Overall System Design) that such a constraints makes a leg into a partial function from the entity set to the relationship set. Moreover, it shows immediately and intuitively that there is just one way to go from the entity set to the relationship set (and thus to the other component type sets, as legs are functions).

Figure 6. (0:N)/(0:N)

Figure 7. (1:N)/(0:N)

Figure 8. (0:N)/(1:N)

Figure 9. (1:N)/(1:N)

Figure 10. (0:M)/(0:M)

Figure 11. (1:M)/(0:M)

Figure 12. (0:M)/(1:M)

Figure 13. (1:M)/(1:M)

Figure 14. (0:1)/(0:N)

Figure 15. (1:1)/(0:N)

Figure 16. (0:1)/(1:N)

Figure 17. (1:1)/(1:N)

Figure 18. (0:N)/(0:1)

Figure 19. (1:N)/(0:1)

Figure 20. (0:N)/(1:1)

Figure 21. (1:N)/(1:1)

Figure 22. (0:1)/(0:1)

Figure 23. (1:1)/(0:1)

Figure 24. (0:1)/(1:1)

Figure 25. (1:1)/(1:1)