Making Data Models Readable - High-Performance Web Databases: Design, Development, and Deployment - page 252

an occurrence of another? After that, it is important to ascertain whether
an occurrence can have more than one occurrence of the other entity.
Of lesser interest are the specific attributes of each entity.
The lowest priority, and indeed something that probably will only be dis-
cussed with the user in special cases, is whether or not the identity of
occurrences of an entity depends on occurrences of another entity. Where
this is so, it is usually obvious and not something that requires discussion.
Because of these priorities, graphically, the most dramatic symbols
should be the entities and relationships themselves, followed by those
used for the cardinality and optionality questions, with perhaps an
appended symbol for the unique identifier. In IDEF1X, unfortunately, the
most dramatic feature is the least important one — the notation for unique
identifier. This involves the relationship line, the shape of the entity box,
and the definition of attributes. Among other things, the use of solid and
dashed lines means that the unique identifier decision must be made first,
in order to draw the model at all.
This issue of convoluted lines also goes to the point of layering as well.
As shown in the example above, the use of many lines with elbows can
interfere with the viewer's ability to pick out the entities. By restricting
yourself to straight lines, even if it means stretching the entities, you focus
the viewer's attention on the entities first. In stretching entities, by the way,
you have the opportunity to make the most important entities larger, and
the lesser entities smaller, further contributing to effective layering.
POOR NAMING
The hardest thing for technicians to do is to name things. Many of us got
into computers, after all, because we didn't do all that well in English
classes. But names are important. An entity is a thing of significance to the
business, about which it wants to hold information. The name of that thing
must be meaningful. It cannot be an acronym, or an abbreviation, or a table
name. Unfortunately, too many analysts think they are providing table
names for a database management system (with their attendant limitations
on length), and the readability of the model suffers.
But one is looking for the names of things of significance to the business,
not tables. In Chen's drawing (Exhibit 2), the entity names PROJ and SUPP are
less than fully explanatory. Even worse, PART - PROJ - SUPP is not at all meaning-
ful. Better would be something like SUPPLY , which at least conveys the idea
that something is being supplied. Failure to name entities meaningfully
makes it virtually impossible to understand what a data model is about.
Relationship names are even harder. Some techniques, such as SSADM
and Yourdon's object-modeling technique, do not show relationship names