Page 254 -

chaPter 8 • analyzing systems Using Data Dictionaries 221

COnSUlting OppORtUnity 8.1

Want to Make It Big in the Theatre?
Improve Your Diction(ary)!

As you enter the door of Merman’s, Annie Oaklea greets you Clinging to Annie’s initial praise, you are undaunted by
warmly, saying, “I’m delighted with the work you have done on her exit line. You determine that a data dictionary based on
the data flow diagrams. I would like you to keep playing the role the rental and return data flow diagrams would make a big hit.
of systems analyst for Merman’s and see if you can eventually Begin by writing entries manually in as much detail as
get a new information system for our costume inventory sewn up. possible. Prepare two data flow entries, two data store entries,
Unfortunately, some of the terms you’re using don’t come off very one data structure entry, and four data element entries using the
well in the language of Shakespeare. Bit of a translation problem, formats in this chapter. Portraying interrelated data items with
I suspect.” preciseness will result in rave reviews. (Refer to Consulting
Opportunity 7.1.)

It is important that the data flow names on the child data flow diagram be contained as ele-
ments or structural records in the data flow on the parent process. Returning to the example,
WAGE INFORMATION (input into process 5.3, COMPUTE CURRENT PAY AMOUNTS)
is a structural record contained in the EMPLOYEE RECORD (input to process 5). Similarly,
GROSS PAY (output from process 5.3.4, a lower-level process not shown in the figure) is con-
tained in the structural record CURRENT PAY AMOUNTS (output from the parent process 5.3,
COMPUTE CURRENT PAY AMOUNTS).

Analyzing Input and Output
An important step in creating a data dictionary is to identify and categorize system input and out-
put data flow. Input and output analysis forms contain the following commonly included fields:
1. A descriptive name for the input or output. If the data flow is on a logical diagram, the
name should identify what the data are (for example, CUSTOMER INFORMATION). If
the analyst is working on the physical design or if the user has explicitly stated the nature
of the input or output, however, the name should include that information regarding the
format. Examples are CUSTOMER BILLING STATEMENT and CUSTOMER DETAILS
INQUIRY.
2. The user contact responsible for further details clarification, design feedback, and final
approval.
3. Whether the data is input or output.
4. The format of the data flow. In the logical design stage, the format may be undetermined.
5. Elements indicating the sequence of the data on a report or screen (perhaps in columns).
6. A list of elements, including their names, lengths, and whether they are base or derived,
and their editing criteria.
Once the form has been completed, each element should be analyzed to determine whether the
element repeats, whether it is optional, or whether it is mutually exclusive of another element.
Elements that fall into a group or that regularly combine with several other elements in many
structures should be placed together in a structural record.
These considerations can be seen in the completed Input and Output Analysis Form for
World’s Trend Catalog Division (see Figure 8.12). In this example of a CUSTOMER BILLING
STATEMENT, the CUSTOMER FIRST NAME, CUSTOMER LAST NAME, and CUSTOMER
MIDDLE INITIAL should be grouped together in a structural record.

Developing Data Stores
Another activity in creating a data dictionary is developing data stores. Up to now, we have deter-
mined what data need to flow from one process to another. This information is described in data