Page 100 - Accounting Information Systems

CHAPT E R 2 Introduction to Transaction Processing 71

Database Backup Procedures
Each record in a database file is assigned a unique disk location or address (see Section A of the chapter
Appendix) that is determined by its primary key value. Because only a single valid location exists for
each record, updating the record must occur in place. Figure 2-29 shows this technique.
In this example, an AR record with a $100 current balance is being updated by a $50 sale transaction.
The master file record is permanently stored at a disk address designated Location A. The update program
reads both the transaction record and the master file record into memory. The receivable is updated to
reflect the new current balance of $150 and then returned to Location A. The original current balance,
value of $100, is destroyed when replaced by the new value of $150. This technique is called destructive
update.
The destructive update approach leaves no backup copy of the original master file. Only the current
value is available to the user. To preserve adequate accounting records in case the current master becomes
damaged or corrupted, separate backup procedures, such as those shown in Figure 2-30, must be imple-
mented.
Prior to each batch update or periodically (for example, every 15 minutes), the master file being
updated is copied to create a backup version of the original file. Should the current master be
destroyed after the update process, reconstruction is possible in two stages. First, a special recovery
program uses the backup file to create a pre-update version of the master file. Second, the file
update process is repeated using the previous batch of transactions to restore the master to its current
condition. Because of the potential risk to accounting records, accountants are naturally concerned
about the adequacy of all backup procedures. In Chapter 15 we examine many issues related to
file backup.

BATCH PROCESSING USING REAL-TIME DATA COLLECTION
A popular data processing approach, particularly for large operations, is to electronically capture
transaction data at the source as they occur. By distributing data input capability to users, certain
transaction errors can be prevented or detected and corrected at their source. The result is a transac-
tion file that is free from most of the errors that plague older legacy systems. The transaction file
is later processed in batch mode to achieve operational efficiency. Figure 2-31 illustrates this

FI G U R E
2-29 DESTRUCTIVE UPDATE APPROACH

Transaction File
Sale = $50

AR
Master File
Read $50
Read $100
Update Program
$100 + $50 = $150 Current Bal = $100
Write $150

Record Location A