Logical Data Structures 

Introduction 

The creation of the Logical Data Structure (LDS) is the second of seven steps in program design.

Step Two: Create a Warnier/Orr diagram depicting the structure of the minimum necessary logical input. This Logical Data Structure can be built from information gathered on the Output Definition Form: the Input (or Change) Frequencies listed become the hierarchy shown on the LDS; the Data Elements marked as "*" (required) become the data features shown on the LDS.

Example Whereas the Logical Output Structure shows the data which is logically output, the Logical Data Structure shows the minimum data which must be logically input. The LDS is quite often a subset of the LOS: on many outputs the LDS can be created from the LOS by simply removing the Labels and Computed data elements. When this is true for an output, the output is said to be "well-behaved."

Occasionally, the LDS can have features which are not present on the LOS. These "hidden" features will be discussed shortly. LDS's containing hidden features are said to be "ill-behaved."

Consider the output prototype examined earlier...

The Logical Data Structure for this output is as follows...

The LDS says that in order to be able to produce the output, the input must be available by Client within Attorney for the Firm; further that Client Number, Name, and Amount Billed must be available for each Client; Attorney Number and Name must be available at the beginning of each Attorney; and Month End Date must be available at the beginning of the Firm.

Again, notice that the Logical Data Structure DOES NOT reflect the actual input data which is available to the program. It is created independently of knowledge of the real input data in order to preserve information hiding aspects mentioned earlier. If the real input is not the same as the logical input, it will be the job of the Physical Input Mapping section of the program to make the conversion.

The Logical Data Structure always reflects "perfect" data: just the data needed for the output in just the sequence needed, with no extra data and no bad data.

Hidden Data Elements 
Hidden data elements are those which are needed for calculation, but which do not appear explicitly on the output. As an example, consider the following output prototype...

It it obvious from inspection of this output that the running Balance is a computed data element: the Check Amounts are being subtracted from the Balance and the Deposit Amounts are being added to the Balance. However, there is clearly a Beginning Balance Amount necessary for the calculation of the first Balance; this is an example of a "hidden" data element. The element "Beginning Balance Amount" DOES NOT appear on the Logical Output Structure (LOS), since that element is not explicitly on the output. It DOES appear on the Logical Data Structure (LDS) since it is required as input.

Again, notice that the data actually available as input IS NOT a consideration when deciding what to show on the LDS; the data present on the LDS is the minimum data required to produce the output.

Hidden Hierarchies 
Hidden Hierarchies are those levels of data visible in the Input (or Change) Frequencies of the data but not visible in the Output Frequencies. They are always related to the sorting sequence: the Logical Data Structure (LDS) will reflect all levels of sorting even if those levels are not reflected on the Logical Output Structure. Consider the following file fragment...

Although it is output on each Transaction record, Customer Number is the same for a whole group of Transactions (assuming the output is in Customer Number sequence). Thus, the Logical Output Structure looks something like...

while the Logical Data Structure looks like...

Whenever sorting data appears on an output more often than its contents change, the Logical Data Structure for that output will have "hidden" levels which are not present on the Logical Output Structure.

Note that if you are developing an output for a client, it is generally not a good idea to include "hidden" features. An output is almost always easier to understand and use if it is a "well-behaved" output.

Tips and Hints 
When developing Logical Data Structures, there are several things to keep in mind...

• The LDS represents a "logical" view of the minimum necessary data. Like the LOS, it will never include data that is specific to a particular kind of input device or output device.
• The LDS should include all data which must be input to support production of the output. It may have additional data elements and/or additional hierarchies not present on the LOS.
• The highest level of the LDS is named for the organization represented by the data on the output. By definition its "number of times" designation is "1." It is the only set present on the LDS which is allowed to have such a designation.
• Every set except for the highest level must either repeat (appear with a frequency of "0,n" or "1,n") or alternate (appear with a frequency of "0,1").
• Each Data Element appearing on the LDS has a default "number of times" of "1," although that designation is never shown explicitly on the diagram. No element is allowed to repeat or alternate. (Remember that each element must have a defined input frequency of once per some logical set).
• There will be one bracket (set) on the LDS for each different input frequency defined on the Output Definition Form. Each such set should represent some "logical" group; set names which are specific to a particular device are not permitted. Thus, groups like "report," "record," "file," and "page" are not allowed.
• The LDS IS NOT meant to show the actual input to the program. Remember that the purpose of the Physical Input Mapping (the part of the program that turns the actual data into the logical input) will translate the actual input data into the "perfect" input.