![](https://csdnimg.cn/release/download_crawler_static/2590831/bg12.jpg)
Silberschatz−Korth−Sudarshan:
Database System
Concepts, Fourth Edition
1. Introduction Text
14
© The McGraw−Hill
Companies, 2001
4 Chapter 1 Introduction
now two choices: either obtain the list of all customers and extract the needed
information manually or ask a system programmer to write the necessary
application program. Both alternatives are obviously unsatisfactory. Suppose
that such a program is written, and that, several days later, the same officer
needs to trim that list to include only those customers who have an account
balance of $10,000 or more. As expected, a program to generate such a list does
not exist. Again, the officer has the preceding two options, neither of which is
satisfactory.
The point here is that conventional file-processing environments do not al-
low needed data to be retrieved in a convenient and efficient manner. More
responsive data-retrieval systems are required for general use.
• Data isolation. Because data are scattered in various files, and files may be in
different formats, writing new application programs to retrieve the appropri-
ate data is difficult.
• Integrity problems. The data values stored in the database must satisfy cer-
tain types of consistency constraints. For example, the balance of a bank ac-
count may never fall below a prescribed amount (say, $25). Developers enforce
these constraints in the system by adding appropriate code in the various ap-
plication programs. However, when new constraints are added, it is difficult
to change the programs to enforce them. The problem is compounded when
constraints involve several data items from different files.
• Atomicity problems. A computer system, like any other mechanical or elec-
trical device, is subject to failure. In many applications, it is crucial that, if a
failure occurs, the data be restored to the consistent state that existed prior to
the failure. Consider a program to transfer $50 from account A to account B.
If a system failure occurs during the execution of the program, it is possible
that the $50 was removed from account A but was not credited to account B,
resulting in an inconsistent database state. Clearly, it is essential to database
consistency that either both the credit and debit occur, or that neither occur.
That is, the funds transfer must be atomic—it must happen in its entirety or
not at all. It is difficult to ensure atomicity in a conventional file-processing
system.
• Concurrent-access anomalies.Forthesakeofoverallperformanceofthesys-
tem and faster response, many systems allow multiple users to update the
data simultaneously. In such an environment, interaction of concurrent up-
dates may result in inconsistent data. Consider bank account A, containing
$500. If two customers withdraw funds (say $50 and $100 respectively) from
account A at about the same time, the result of the concurrent executions may
leave the account in an incorrect (or inconsistent) state. Suppose that the pro-
grams executing on behalf of each withdrawal read the old balance, reduce
that value by the amount being withdrawn, and write the result back. If the
two programs run concurrently, they may both read the value $500, and write
back $450 and $400, respectively. Depending on which one writes the value