Page 124 - Accounting Information Systems

CHAPT E R 2 Introduction to Transaction Processing 95

large files are involved. Using direct access files eliminates the need to sort transactions into a predeter-
mined sequence.
The second change is the elimination of automatic file backup in this system. Direct access update
does not produce a new physical master as a by-product of the process. Instead, changes to field values
are made to the original physical file. Providing file backup requires separate procedures.

DIRECT ACCESS FILE UPDATE AND BACKUP PROCEDURES
Each record in a direct access file is assigned a unique disk location or address that is determined by its
key value. Because only a single valid location exists for each record, updating the record must occur in
place of a destructive update approach similar to that for database tables. See Figure 2-29 and the associ-
ated discussion in the chapter for details.
Direct access file backup issues are also similar to modern database systems. Because the destruc-
tive update approach leaves no backup copy of the original master file, only the current value is available
to the user. If the current master becomes damaged or corrupted in some way, no backup version exists
from which to reconstruct the file. To preserve adequate accounting records, special backup procedures
need to be implemented like those illustrated in Figure 2-30.

General Logic for File Update

SEQUENTIAL FILE UPDATE
The logic of a sequential file update procedure is based on the following assumptions and conditions:
1. The transaction (T) file contains fewer records than the master (M) file. An organization may
have thousands of customers listed in its customer (AR) file, but only a small percentage of
these customers actually purchased goods during the period represented by the current batch of
transactions.
2. More than one transaction record may correspond to a given master file record. For example, a
department store sells its RCA 27-inch TV to several customers during a 1-day special offer. All of
these transactions are separate records in the batch and must be processed against the same inventory
master file record.
3. Both transaction file and master file must be in the same sequential order. For purposes of illustra-
tion, we will assume this to be ascending order.
4. The master file is presumed to be correct. Therefore, any sequencing irregularities are presumed to
be errors in the transaction file and will cause the update process to terminate abnormally.
With these assumptions in mind, let’s walk through the update logic presented in Figure 2-47. This
logic is divided into three sections: start-up, update loop, and end procedures.

Start-Up
The process begins by reading the first transaction (T) and the first master (M) record from their respective
files in the computer’s memory. The T and M records in memory are designated as the current records.

Update Loop
The first step in the update loop is to compare the key fields of both records. One of three possible condi-
tions will exist: T ¼ M, T > M, or T < M.

T ¼ M. When the key of T is equal to that of M, the transaction record matches the master record. Hav-
ing found the correct master, the program updates the master from the transaction. The update program
then reads another T record and compares the keys. If they are equal, the master is updated again. This
continues until the key values change; recall that under Assumption 2, there may be many Ts for any M
record.