My favorite modelling tool, the age-old ER, Entity-Relationship model, focuses strongly on the information structures, rather than the workflow. It is essentially a semi-formal drawing technique - and of course there are a number of "dialects". Some computer based tools are available, often forcing you to use a specific dialect. The one I have used most recently is called yEd[^] - it is not specifically for ER, but supports it well. An ER model is a graph with "entities" (data objects) forming the nodes, drawn as rectangular boxes. Actually, the entity is like a class definition; a "customer" entity is any customer object. Relationships to other entiries are edges, drawn as arrows. Arrowheads, both ends, indicate how many objects are involved in a relation: A "bill" object and a "customer" object has an n:1 relationship, indicated by different heads. Notation exists for "0 or more", "exactly 1", "1 or more" (more specific cases, like 1 to 3, is indicated textually by the arrowhead). For straightforward relationships, a textual label on the edge is sufficient it is always double, indicating each entity's view of the relationship, such as a customer "bought" what the bill specifies; this "was bought by" a customer. If you need to handle data about the relationship itself, which are not properties of the entities (such as the date when the relationship was established), or a three way relationship (such as who endorsed it), you can draw it as a diamond with arrows to two or more entities, and attributes associated with the relationship. Two entities may have several distinct relationhips. Often, splitting up a diffusely specified relationships into distinct one can be enlightening, e.g. "business connection" going to "Buys products from", "Provides programming services to" and "Owns shares in" - different procedures will need to relate to the relationship in different ways. Entitiy attributes are either, in simple models, drawn as ovals attached to the entity, or, in larger models, listed inside the entity rectangle - this illustrates one dialect variation! Another variation (more in modelling style than language) is how much you break down complex data into distinct entities: Is a "car" one single entity, or should you split off an "engine" entity with an "is powered by / powers" relationship? If otherwise identical cars differ only in engine selection, and/or each e
