Data, Processes, and Events: Keys to Comprehensive Analysis - High-Performance Web Databases: Design, Development, and Deployment - page 54

however, have two drawbacks. The first is that they depend on the skills of
the facilitator; skills that are difficult to develop. The second drawback is
that they are not highly structured and, moreover, cannot be readily repli-
cated. The next objective, therefore, is to provide a framework for a more
structured approach to requirements gathering, which can be repeated.
This framework specifies how to analyze the relationships between
entities and each stage in the ELH. The first step in this technique requires
that the major data entities be identified. Each pair of entities is analyzed
for the nine potential combinations of tight coupling to derive the first-cut
data relationships.
APPLYING THE APPROACH
The example used to illustrate this event-based approach is the order-entry
system modeled in Exhibit 5. The four major entities — CUSTOMER, ORDER,
LINE ITEM, and PRODUCT — have already been identified. Each pair of enti-
ties is examined for the nine combinations of tight coupling (see Exhibit 4).
The first entity pair is ORDER and LINE ITEM. One of the two is
selected to be the causal entity and the other to be the affected entity. At
this stage it does not matter which entity assumes which role because
this exercise is repeated for the same pair in the other direction. This
duality reflects the accepted concept that all data relationships are
bidirectional. It is important to note that, the ORDER entity represents
the header portion of an order and each occurrence of LINE ITEM reflects
each line of an order.
The analyst compares each pair of entities to all nine types of tight cou-
pling (see Exhibit 4) and examines each pair for relevance in the context of
causal and affected entities. For example, starting with the upper left box,
the analyst asks the client such a question as: Is there any case where the
creation of an order (the causal entity) causes the creation of a line item
(the affected entity)? The answer to this question is yes. When the system
creates an order, the order must have at least one line item. The analyst
checks the box to indicate the identification of an event.
These identified events are the building blocks of the requirements gath-
ering process. At first, it is not necessary to explore these events in detail.
The fact that these events require further exploration and decomposition
must be recorded.
Is there any case where the creation of an ORDER would cause the sys-
tem to update a LINE ITEM? Probably not, because at the time an ORDER is
created there would not have been an existing line item to which the order
relates. Is there any case where the creation of an ORDER is cause to delete
a LINE ITEM? Again, probably not.