Entity-Relationship Models

If the requirements within a set involve a description of the structure and relationships among data within the system, it's often convenient to represent that information in an entity-relationship diagram (ERD). Figure 24-5 shows a typical ERD.

Figure 24-5. Example of an entity-relationship diagram

Note that the ERD provides a high-level "architectural" view of the data represented by customers, invoices, packing lists, and so on; it would be further augmented with appropriate details about the required information to describe a customer. The ERD does correctly focus on the external behaviors of the system and allows us to define such questions as "Can there be more than one billing address per invoice?" Answer: no.

Although an ERD is a capable modeling technique, it has the potential disadvantage of being difficult for a nontechnical reader to understand. As you can see in Figure 24-5, the lines connecting "Customer" to "Order" and "Order" to "Invoice" are annotated with circles and " crows -feet" indicators. The obvious question is: What does all of this mean? Attempting to answer such a question within this book would be a major digression which we will avoid, but avoiding the question in the review of a requirements set is likely to mean that some users simply won't understand what's going on. The alternatives are to send the appropriate users to a two-day training course in ERD notation, which they may or may not appreciate, or to use the notation as a "technical" form of documentation within the development group .