Introduction to Data Management

Managing Data on the Tandem Systems
2-6 15873 Tandem Computers Incorporated
Database Consistency
for Accurate Data
Relationships
When you design a database, you establish certain criteria for the relationship
between items in the database. One criterion for a banking application, for instance, is
that an account balance must always equal the credits minus the debits for that
account. When the database satisfies the criteria, it is said to be consistent.
For your applications to work correctly, they must be able to view input from the
database as consistent regardless of the changes continually occurring on the
database. These changes transform the database from one consistent state to another;
but, during the transformation itself, the database is generally inconsistent. For
example, the banking application noted earlier actually conducts two operations when
it balances an account: a debit operation and a credit operation. After debiting, the
database is not consistent until the second operation, crediting, is complete. Thus, at
the instant after the debit but before the credit, the application sees an inconsistent
database. When the credit operation is finished, however, the database again becomes
consistent; now, all applications viewing the database will see a true account balance.
In an active processing environment, with many transactions occurring
simultaneously, concern about database consistency naturally arises. Tandem ensures
this consistency with TMF. With this product, you can write your application
programs without worrying about any of the following potential problems:
Concurrency. When several transactions are applying changes to the database at
the same time, TMF allows you to code your transaction as if it were the only
activity in the system.
Failure. In all cases, either all changes imposed by a transaction occur, or none of
them occurs. TMF enforces this policy despite:
A single component failure that causes a transaction to abort
A user voluntarily aborting a transaction
Multiple component failures (resulting from an extended power failure, for
example)
In the case of an aborted transaction, TMF backs out the transaction by restoring
data items to the values they had before the transaction began. Thus, no change
begun by the transaction is reflected in the database. In the event of a total system
failure, TMF allows you to use an online dump tape or disk in conjunction with
audit trails to restore the database to a consistent state. No transactions already
completed before the abort or failure are lost—they all persist in the database.
Furthermore, you need not explicitly code primary and backup server processes
because TMF takes care of this for you automatically.