In my analysis and design classes I try to impress upon my students the importance of the arrangement of their diagrams. Aesthetics matters! The layout of a diagram conveys important information about the basic structure of the domain — application, database, process, or whatever — that is being diagrammed.
Here are some examples that illustrate that point. All of these diagrams are structurally identical. They all contain the same number of nodes, connected in the same way. But they are arranged differently, and the different arrangements tell very different stories about the basic structure of the domain being modeled.
If your diagram looks like this, you need to untangle it. Make it tell a clear story about the basic structure of the domain.
Try to avoid having connector lines crossing other connector lines.
Your diagram should have a clear flow or direction:
Diagrams that represent processes (e.g. process flow diagrams) have an inherent flow or sequence based on the process being represented. The flow of the diagram should reflect the inherent flow of the process.
When diagramming static domains that don't have an inherent flow (e.g. class diagrams, entity-relationship diagrams, database diagrams), the diagram's direction of flow should be from the most important nodes (entities/classes/tables/modules) of the application toward the less important nodes.
TIP: Put the most important nodes at the beginning of the flow — at the left, top, or center of the diagram. Their position on the diagram helps to draw the viewer's attention to them, and indicates that they are the important nodes in the domain.
If rule 1 (no crossing connector lines) conflicts with rule 2 or 3, rules 2 and 3 take precedence.
In developing a database design diagram, you might be tempted to put database lookup tables (reference tables, mapping tables, translation tables) at the center of the diagram. After all (you think), the database design contains many foreign keys that reference the lookup tables, so putting the lookup tables at the center of the diagram will avoid a lot of crossed lines.
True... but still not a good idea! The lookup tables are simply a part of the mechanics of database design. They are not of core importance for the business application for which the database is being designed. They belong at the edges, or the bottom, of the diagram.
If necessary, to avoid a lot of connector lines crossing all over the diagram to get to one lookup table, draw duplicate nodes representing the same lookup table on your diagram. Position them so that you can minimize crossed lines and so that they are in keeping with the direction/flow of the diagram.
Some diagrams are naturally tall and narrow (like example 1) while others are naturally short and wide (like example 3). Switching your diagram from portrait mode to landscape mode (or vice versa) may make it easier to create a diagram with a natural shape.
The most common mistake I see is to try to arrange a diagram so it fits on a single sheet of paper, rather than arranging it to show its natural structure. The result often looks like example 4.
Do not do this!
The most important rule of all (because it is so often violated) is: Once you have a nice clean diagram that tells a clear story about the domain, do not rearrange it so that it will fit on one page.
Don't try to eliminate empty space. You want empty space in your diagram. Empty space gives you room in which to arrange your nodes in a way that tells a clear story.
Keep the size of your nodes fairly small. This will increase the amount of empty space on your diagram.