Use a single, unambiguous name for each entity, describing the thing of significance it represents.
Use common English (or French, or German, or whatever) names.
If possible, use names familiar to your audience, but if the only available terms are ambiguous or do not have the same meaning to all concerned, create new terms as precisely as possible, and define them clearly.
Do not use abbreviations, acronyms, or table names. (No fin loc master, for example. Use financial location.)
Use the singular name of an occurrence of the thing. (No instructions. Use instruction. No product structure. Use product structure element.
Accompany each entity with a clear, concise definition in the dictionary. Use correct grammar and don’t use jargon, acronyms, or abbreviations. Don’t use the entity to define itself.
Share entities across applications wherever possible.
When an entity is identified, pursue its analysis until all possible relationships have been identified. If you know that you have not had time to analyze it completely, indicate that in the dictionary, and come back to it later.
A sub-type is a subset of the occurrences of an entity. An occurrence of an entity may appear in one and only one sub-type.
Use of the sub-type implies two things: first, the sub-type probably has attributes or relationships which distinguish it from other sub-types; second, the division of an entity into sub-types represents a fundamental and relatively stable organization of the data.
In general, do not use sub-types where examples would do. Do include examples as text on the drawing, where they clarify the meaning of the entity.
Relationships
Put one name at each end of each relationship.
Relationship names are prepositional phrases, not verbs. Don’t use "has", for example.
Each relationship name must fit into the following structure to produce simple, understandable English sentences:
Each <entity 1>
{must be|may be}
<relationship name>
{one and only one|one or more}
<entity 2>[s]
.
Do not use weak relationship names, such as "associated with", or "related to". The fact that we drew the relationship line already asserts that the entities are associated with or related to each other. Use something concrete enough that it could be wrong this allows your client to correct it.
If all else fails, you may use a gerund (as in "Each party may be owning one or more assets"), but it is weak, so avoid it if possible.
Standards for organizing the drawing
In general
Organize the drawing to be visually attractive.
Give equal weight to the left and right side of the diagram.
Leave white space judiciously.
Don't "scrunch" elements together unless absolutely necessary.
This allows about 10-15 entities on a page. This is the best size for a diagram to be readable. If you need more entities, you probably need two pages.
is also acceptable, and this will let you get up to thirty entities on the page, while allowing the text to be still readable. If you use "A1" or larger, the text will be very difficult to read if it is printed on 8 1/2" X 11" paper.
Break the overall model into topics, so that each diagram concerns only one or two subjects. Try to organize the drawings so that each represents a complete "logical horizon" (an entity with all the entities it requires). If the logical horizon is too deep to limit the drawing to 25 entities or so, split it into two diagrams, with enough entities overlapping to make it clear how they all are related.
Laying out the diagram in "portrait" format is better for publication, but laying it out in "landscape" form makes more efficient use of the screen. Whichever you choose, use it consistently for all diagrams.
Crow's feet
Orient the entities and relationships so that the "crows feet" have their toes pointing to the left or top of the diagram.
In general, this rule provides a "shape" to the model, so that it is not simply a random collection of boxes and lines.
It clusters tangible, reference entities in the lower right, while the less tangible transactions and intersect entities congregate in the upper left.
It allows someone who has not seen the diagram before to quickly identify which are defining entities, and which constitute the organization’s transactions.
Relative entity sizes
Vary the size of the entity boxes to make the diagram more interesting. In general, make each entity's size proportional to its importance.
As necessary, stretch entities to accommodate relationship problems (described below).
Legends
Have a consistent legend in the same place on every drawing, with a consistent format. Engineering convention calls for it to be in the lower right corner. One you may try is as follows:
The company name is in upper case; the other lines are in upper and lower case.
In Oracle's CASE*Designer, if you create a box that extends into the gray area on the lower right, the bottom and right borders won't print if you request to print just the "drawing area".
If additional annotation is required ("This is a model of the physical data base", for example), either add this as another line in the legend, or put it along the bottom of the drawing. It may be appropriate to put a box around that as well.
Detailed Drawing Standards
Entities
Usually center subtypes within super-types, at least horizontally. Leave a border around each subtype. There are legitimate exceptions to the centering rule. There are none to the rule about borders.
Center text horizontally within an entity. If the entity is squarish, center the text vertically, as well. If it is vertically elongated, put the text approximately one quarter of the way from the top. If it is horizontally elongated, you may either center the text vertically, or place it along the upper edge.
Relationships
A bend in a relationship becomes a symbol on the picture: To minimize clutter on the diagram, don't bend relationships, if possible.
Never bend it at a right angle.
If necessary, make it an oblique angle.
Make most relationships orthogonal (north/south, or east/west). An occasional diagonal is OK. Don't make it look like an afterthought.
Where possible, avoid crossing relationship lines, but this is not as important as not bending lines. Do not cross entities, ever.
Where possible, arrange relationship names to be read clockwise. That is, for vertical relationships, place them in the upper right and lower left. For horizontal ones, place them in the upper left and lower right. This rule may be waved if there is not room to follow it.
If possible, do not let relationship names cross super-type boundaries.
If a sub-type has a pig’s ear, allow enough room so that the relationship does not extend outside the super-type.
If there is room, place any pig’s ear on the lower right corner of the entity, with the "many" end on the right side of the entity.
Attributes
The CASE*Designer doesn't show attributes on the drawing. It is sometimes useful to add them as graphic text, however.
Don't add more than necessary to illustrate a point.
Don't crowd the entity text.
And if you don't have a CASE Tool . . . ?
Sometimes it is necessary to produce a data model when no CASE tools are available. (Remember, we are only talking to people who are so passionate about data models that they would do them by hand, if necessary.) Numerous graphic packages are available for PC's, but unfortunately, most vendors are so fixed on making it possible to draw space craft and cars in three dimensions, that they aren't very accommodating to the simpler, but highly disciplined requirements of the data modeler.
Your author's favorite package is McDraft, which is finally available for PC's, as well as the MacIntosh. MicroGrafix designer and Aldus [now *****] Freehand also work well. PC Draw, PowerPoint, and PageMaker may be used if nothing else is available, but each has severe limitations. (PowerPoint, for example has no dotted lines; you cannot export drawings from PageMaker, etc.)
[Since this article was written, Visio has enhanced its package to add "intelligence" to its symbols. It does not come with the symbols for Oracle notation, so these would have to be created. Your author has no direct experience with this tool.]
The good news about using a graphics package is that your models are much more attractive. The bad news is that you do have to do the work of keeping relationships connected without stretching the crow's feet. You also are not building an underlying dictionary.
Some of the above rules have variations, if you are doing this from scratch:
Use a consistent size for entity names and relationship names. In general, Arial (or helvetica) bold, in 12-14 points is suitable for entity names. Arial italic, in 10-12 points works well for relationship names. Use 10-12 point Times Roman for attributes.
Magnify the crow's feet on the screen enough to insure that you can see the lines meet cleanly at the center. If they aren't quite right, it doesn't necessarily show, but the drawing looks somehow less neat.
Hay's favorite relationship names:
Your author has frequently been asked for a list of typical relationship names. He is reluctant to do this, because the correct name for a relationship should come from the relationship, and not from some standard list. Still, it is true that a lot of relationship names come up frequently. Here then, is a modest list, with no guarantees that it will make relationship names leap from the page:
(definitions)
defined by/definer of
defined by/the definition of
in (or currently in)/location of (or site of)
in terms of/reference for
of/classification for
part of/composed of
responsible for (or currently responsible for)/responsibility of