easy
`iFH
`
`| DATABASE
`aN
`
`aeel\
`
`Patent OwnerFinjan,Inc. - Ex. 2015, p. 1
`
`ABRAHAM SILBERSCHATZ~—=HENRY F. KORTH
`S. SUDARSHAN
`
`Patent Owner Finjan, Inc. - Ex. 2015, p. 1
`
`

`

`McGraw-Hill
`A Division of The McGraw Hill Companies
`
`DATABASE SYSTEM CONCEPTS
`
`Copyright ©1997 by The McGraw-Hill Companies, Inc. All rights reserved. Printed in the
`United States of America. Except as permitted under the United States Copyright Act of
`1976, no part of this publication may be reproduced or distributed in any form or by any
`means, or stored in a data base or retrieval system, without the prior written permission
`of the publisher.
`
`This book is printed on acid-free paper.
`
`1 2 3 4 5 6 7 8 9 0 D O C D O C 9 0 9 8 7 6
`
`I S B N D - 0 7 - 0 4 4 7 5 f c i - X
`
`This book was set in Times Roman by ETP Harrison.
`The editor was Eric M. Munson;
`the production supervisor was Leroy A. Young.
`The cover was designed by Christopher Brady.
`Project supervision was done by ETP Harrison (Portland, Oregon).
`R. R. Donnelley & Sons Company was printer and binder.
`
`Library of Congress Cataloging-in-Publication Data
`
`Silberschatz, Abraham.
`Database system concepts / Abraham Silberschatz, Henry F. Korth,
`S. Sudarshan. — 3rd ed.
`p.
`cm. — (McGraw-Hill series in computer science)
`Korth's name appears first on earlier editions.
`Includes bibliographical references and index.
`ISBN 0-07-044756-X
`II. Sudarshan, S.
`I. Korth, Henry F.
`1. Database management.
`III. Title. IV. Series: McGraw-Hill computer science series.
`QA76.9.D3S5737
`1996
`005.74—dc21
`
`96-44015
`
`http://www.mhcoIIege.com
`
`Patent Owner Finjan, Inc. - Ex. 2015, p. 2
`
`

`

`CHAPTER
`
`1
`
`INTRODUCTION
`
`A database-management system (DBMS) consists of a collection of interrelated
`data and a set of programs to access those data. The collection of data, usually
`referred to as the database, contains information about one particular enterprise.
`The primary goal of a DBMS is to provide an environment that is both convenient
`and efficient to use in retrieving and storing database information.
`Database systems are designed to manage large bodies of information. The
`management of data involves both the definition of structures for the storage of
`information and the provision of mechanisms for the manipulation of information.
`In addition, the database system must provide for the safety of the information
`stored, despite system crashes or attempts at unauthorized access. If data are to be
`shared among several users, the system must avoid possible anomalous results.
`The importance of information in most organizations—which determines the
`value of the database—has led to the development of a large body of concepts
`and techniques for the efficient management of data. In this chapter, we present
`a brief introduction to the principles of database systems.
`
`1.1 Purpose of Database Systems
`
`Consider part of a savings-bank enterprise that keeps information about all cus­
`tomers and savings accounts. One way to keep the information 011 a computer is
`to store it in permanent system files. To allow users to manipulate the informa­
`tion, the system has a number of application programs that manipulate the files,
`including
`
`• A program to debit or credit an account
`
`• A program to add a new account
`
`1
`
`Patent Owner Finjan, Inc. - Ex. 2015, p. 3
`
`

`

`2 Introduction
`
`Chapter 1
`
`• A program to find the balance of an account
`
`• A program to generate monthly statements
`
`These application programs have been written by system programmers in response
`to the needs of the bank organization.
`New application programs are added to the system as the need arises. For
`example, suppose that new government regulations allow the savings bank to
`offer checking accounts. As a result, new permanent files are created that contain
`information about all the checking accounts maintained in the bank, and new
`application programs may need to be written to deal with situations that do not
`arise in savings accounts, such as handling overdrafts. Thus, as time goes by,
`more files and more application programs are added to the system.
`The typical file-processing system just described is supported by a conven­
`tional operating system. Permanent records are stored in various files, and different
`application programs are written to extract records from, and to add records to,
`the appropriate files. Before the advent of DBMSs, organizations typically stored
`information using such systems.
`Keeping organizational information in a file-processing system has a number
`of major disadvantages
`
`• Data redundancy and inconsistency. Since the files and application pro­
`grams are created by different programmers over a long period, the various
`files are likely to have different formats and the programs may be written
`in several programming languages. Moreover, the same information may be
`duplicated in several places (files). For example, the address and telephone
`number of a particular customer may appear in a file that consists of savings-
`account records and in a file that consists of checking-account records. This ^
`redundancy leads to higher storage and access cost. In addition, it may lead
`to data inconsistency, that is, the various copies of the same data may no
`longer agree. For example, a changed customer address may be reflected in
`savings-account records but not elsewhere in the system.
`
`• Difficulty in accessing data. Suppose that one of the bank officers needs to
`find out the names of all customers who live within the city's 78733 zip code.
`The officer asks the data-processing department to generate such a list. Be­
`cause this request was not anticipated when the original system was designed,
`there is no application program on hand to meet it. There is, however, an ap­
`plication program to generate the list of all customers. The bank officer has
`now two choices: Either obtain the list of all customers and have the needed
`information extracted manually, or ask the data-processing department to have
`a system programmer write the necessary application program. Both alterna­
`tives 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.
`
`Patent Owner Finjan, Inc. - Ex. 2015, p. 4
`
`

`

`Section 1.1
`
`Purpose of Database Systems 3
`
`The point here is that conventional file-processing environments do not
`allow needed data to be retrieved in a convenient and efficient manner. More
`responsive data-retrieval systems must be developed for general use.
`
`• Data isolation. Because data are scattered in various files, and files may be in
`different formats, it is difficult to write new application programs to retrieve
`the appropriate data.
`
`• Integrity problems. The data values stored in the database must satisfy certain
`types of consistency constraints. For example, the balance of a bank account
`may never fall below a prescribed amount (say, $25). Developers enforce these
`constraints in the system by adding appropriate code in the various application
`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 to ensure
`that, once a failure has occurred and has been detected, the data are restored
`to the consistent state that existed prior to the failure. Consider a program to
`transfer $50 from account A to B. If a system failure occurs during the execu­
`tion 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 this property
`in a conventional file-processing
`system.
`
`• Concurrent-access anomalies. So that the overall performance of the sys­
`tem is improved and a faster response time is possible, many systems allow
`multiple users to update the data simultaneously. In such an environment,
`interaction of concurrent updates 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 in­
`consistent) state. Suppose that the programs 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, respec­
`tively. Depending on which one writes the value last, the account may con­
`tain either $450 or $400, rather than the correct value of $350. To guard
`against this possibility, the system must maintain some form of supervision.
`Because data may be accessed by many different application programs that
`have not been coordinated previously, however, supervision is difficult to
`Provide.
`
`• Security problems. Not every user of the database system should be able
`to access all the data. For example, in a banking system, payroll personnel
`need to see only that part of the database that has information about the vari­
`ous bank employees. They do not need access to information about customer
`
`Patent Owner Finjan, Inc. - Ex. 2015, p. 5
`
`

`

`4
`
`Introduction
`
`Chapter 1
`
`accounts. Since application programs are added to the system in an ad hoc
`manner, it is difficult to enforce such security constraints.
`
`These difficulties, among others, have prompted the development of DBMSs.
`In what follows, we shall see the concepts and algorithms that have been developed
`for database systems to solve the problems mentioned. In most of this book, we
`use a bank enterprise as a running example of a typical data-processing application
`found in a corporation. A typical data-processing application stores a large number
`of records, each of which is fairly simple and small.
`In Chapters 8 and 9, we consider different classes of database applications,
`such as interactive design applications. Applications in these categories typically
`deal with more complex and larger records, such as a complete building design, but
`there are fewer records. There is a substantial amount of research and development
`work underway to provide database systems that are both sufficiently powerful
`and sufficiently flexible to manage these applications.
`
`1.2 View of Data
`
`A DBMS is a collection of interrelated files and a set of programs that allow users
`to access and modify these files. A major purpose of a database system is to
`provide users with an abstract view of the data. That is, the system hides certain
`details of how the data are stored and maintained.
`
`1.2.1 Data Abstraction
`
`For the system to be usable, it must retrieve data efficiently. This concern has
`led to the design of complex data structures for the representation of data in the
`database. Since many database-systems users are not computer trained, developers
`hide the complexity from users through several levels of abstraction, to simplify
`users' interactions with the system:
`
`• Physical level. The lowest level of abstraction describes how the data are
`actually stored. At the physical level, complex low-level data structures are
`described in detail.
`
`• Logical level. The next-higher level of abstraction describes what data are
`stored in the database, and what relationships exist among those data. The
`entire database is thus described in terms of a small number of relatively
`simple structures. Although implementation of the simple structures at the
`logical level may involve complex physicalrlevel structures, the user of the
`logical level does not need to be aware of this complexity. The logical level
`of abstraction is used by database administrators, who must decide what in­
`formation is to be kept in the database.
`
`• View level. The highest level of abstraction describes only part of the entire
`database. Despite the use of simpler structures at the logical level, some
`complexity remains, because of the large size of the database. Many users of
`the database system will not be concerned with all this information. Instead,
`
`Patent Owner Finjan, Inc. - Ex. 2015, p. 6
`
`

`

`Section 1.2
`
`View of Data 5
`
`view level
`
`view 1
`
`view 2
`
`...
`
`view n
`
`logical
`level
`
`physical
`level
`
`Figure 1.1 The three levels of data abstraction.
`
`such users need to access only a part of the database. So that their interaction
`with the system is simplified, the view level of abstraction is defined. The
`system may provide many views for the same database.
`
`The interrelationship among these three levels of abstraction is illustrated in Fig­
`ure 1.1.
`An analogy to the concept of data types in programming languages may
`clarify the distinction among levels of abstraction. Most high-level programming
`languages support the notion of a record type. For example, in a Pascal-like
`language, we may declare a record as follows:
`
`type customer - record
`customer-name : string;
`social-security : string;
`customer-street : string;
`customer-city : string;
`end;
`
`This code defines a new record called customer with three fields. Each field has a
`name and a type associated with it. A banking enterprise may have several such
`record types, including
`
`• account, with fields account-number and balance
`
`• employee, with fields employee-name and salary
`
`At the physical level, a customer, account, or employee record can be de­
`scribed as a block of consecutive storage locations (for example, words or bytes).
`The language compiler hides this level of detail from programmers. Similarly, the
`database system hides many of the lowest-level storage details from database pro-
`gtammers. Database administrators may be aware of certain details of the physical
`°rganization of the data.
`
`Patent Owner Finjan, Inc. - Ex. 2015, p. 7
`
`

`

`6
`
`Introduction
`
`Chapter 1
`
`At the logical level, each such record is described by a type definition, as
`illustrated in the previous code segment, and the interrelationship among these
`record types is defined. Programmers using a programming language work at this
`level of abstraction. Similarly, database administrators usually work at this level
`of abstraction.
`Finally, at the view level, computer users see a set of application programs
`that hide details of the data types. Similarly, at the view level, several views of
`the database are defined, and database users see these views. In addition to hiding
`details of the logical level of the database, the views also provide a security
`mechanism to prevent users from accessing parts of the database. For example,
`tellers in a bank see only that part of the database that has information on customer
`accounts; they cannot access information concerning salaries of employees.
`
`1.2.2 Instances and Schemas
`
`Databases change over time as information is inserted and deleted. The collection
`of information stored in the database at a particular moment is called an instance
`of the database. The overall design of the database is called the database schema.
`Schemas are changed infrequently, if at all.
`Analogies to the concepts of data types, variables, and values in program­
`ming languages is useful here. Returning to the customer-record type definition,
`note that, in declaring the type customer, we have not declared any variables. To
`declare such variables in a Pascal-like language, we write
`
`var customer I
`
`: customer,
`
`Variable customer 1 now corresponds to an area of storage containing a customer
`type record.
`A database schema corresponds to the programming-language type defini­
`tion. A variable of a given type has a particular value at a given instant. Thus,
`the value of a variable in programming languages corresponds to an instance of
`a database schema.
`Database systems have several schemas, partitioned according to the levels
`of abstraction that we discussed. At the lowest level is the physical schema, at the
`intermediate level is the logical schema-, and at the highest level is a subschema.
`In general, database systems support one physical schema, one logical schema,
`and several subschemas.
`
`1.2.3 Data Independence
`
`The ability to modify a schema definition in one level without affecting a schema .
`definition in the next higher level is called data independence. There are two
`levels of data independence:
`
`1. Physical data independence is the ability to modify the physical schema
`without causing application programs to be rewritten. Modifications at the
`physical level are occasionally necessary to improve performance.
`
`Patent Owner Finjan, Inc. - Ex. 2015, p. 8
`
`

`

`Section 1.3
`
`Data Models 7
`
`2. Logical data independence is the ability to modify the logical schema
`without causing application programs to be rewritten. Modifications at the
`logical level are necessary whenever the logical structure of the database is
`altered (for example, when money-market accounts are added to a banking
`system).
`
`Logical data independence is more difficult to achieve than is physical data
`independence, since application programs are heavily dependent on the logical
`structure of the data that they access.
`The concept of data independence is similar in many respects to the concept
`of abstract data types in modern programming languages. Both hide implementa­
`tion details from the users, to allow users to concentrate on the general structure,
`rather than on low-level implementation details.
`
`1.3 Data Models
`
`Underlying the structure of a database is the data model: a collection of conceptual
`tools for describing data, data relationships, data semantics, and consistency con­
`straints. The various data models that have been proposed fall into three different
`groups: object-based logical models, record-based logical models, and physical
`models.
`
`1.3.1 Object-Based Logical Models
`
`Object-based logical models are used in describing data at the logical and view
`levels. They are characterized by the fact that they provide fairly flexible struc­
`turing capabilities and allow data constraints to be specified explicitly. There are
`many different models, and more are likely to come. Several of the more widely
`known ones are
`
`• The entity-relationship model
`
`• The object-oriented model
`
`• The semantic data model
`
`• The functional data model
`
`In this book, we examine the entity-relationship model and the object-
`oriented model as representatives of the class of the object-based logical models.
`The entity-relationship model, explored in Chapter 2, has gained acceptance in
`database design and is widely used in practice. The object-oriented model, exam­
`ined in Chapter 8, includes many of the concepts of the entity-relationship model,
`but represents executable code as well as data. It is rapidly gaining acceptance in
`practice. We shall give brief descriptions of both models next.
`
`1.3.1.1 The Entity-Relationship Model
`
`The entity-relationship (E-R) data model is based on a perception of a real world
`that consists of a collection of basic objects, called entities, and of relationships
`
`Patent Owner Finjan, Inc. - Ex. 2015, p. 9
`
`

`

`8
`
`Introduction
`
`Chapter 1
`
`Figure 1.2 A sample E-R diagram.
`
`among these objects. An entity is a "thing" or "object" in the real world that is
`distinguishable from other objects. For example, each person is an entity, and bank
`accounts can be considered to be entities. Entities are described in a database by a
`set of attributes. For example, the attributes account-number and balance describe
`one particular account in a bank. A relationship is an association among several
`entities. For example, a Depositor relationship associates a customer with each ac­
`count that she has. The set of all entities of the same type, and the set of all relation­
`ships of the same type, are termed an entity set and relationship set, respectively.
`In addition to entities and relationships, the E-R model represents certain
`constraints to which the contents of a database must conform. One important
`constraint is mapping cardinalities, which express the number of entities to which
`another entity can be associated via a relationship set.
`The overall logical structure of a database can be expressed graphically by
`an E-R diagram, which is built up from the following components:
`
`• Rectangles, which represent entity sets
`
`• Ellipses, which represent attributes
`
`• Diamonds, which represent relationships among entity sets
`
`• Lines, which link attributes to entity sets and entity sets to relationships
`
`Each component is labeled with the entity or relationship that it represents.
`An an illustration, consider part of a database banking system consisting of
`customers and of the accounts that these customers have. The corresponding E-R
`diagram is shown in Figure 1.2. This example is extended in Chapter 2.
`
`1.3.1.2 The Object-Oriented Model
`
`Like the E-R model, the object-oriented model is based on a collection of objects.
`An object contains values stored in instance variables within the object. An object
`also contains bodies of code that operate on the object. These bodies of code are
`called methods.
`Objects that contain the same types of values and the same methods are
`grouped together into classes. A class may be viewed as a type definition for
`objects. This combination of data and methods comprising a type definition is
`similar to a programming-language abstract data type.
`
`Patent Owner Finjan, Inc. - Ex. 2015, p. 10
`
`

`

`Section 1.3
`
`Data Models 9
`
`The only way in which one object can access the data of another object
`is by invoking a method of that other object. This action is called sending a
`message to the object. Thus, the call interface of the methods of an object defines
`that object's externally visible part. The internal part of the object—the instance
`variables and method code—are not visible externally. The result is two levels of
`data abstraction.
`To illustrate the concept, let us consider an object representing a bank ac­
`count. Such an object contains instance variables account-number and balance. It
`contains a method pay-interest, which adds interest to the balance. Assume that
`the bank had been paying 6-percent interest on all accounts, but now is changing
`its policy to pay 5 percent if the balance is less than $1000 or 6 percent if the
`balance is $1000 or greater. Under most data models, making this adjustment
`would involve changing code in one or more application programs. Under the
`object-oriented model, the only change is made within the pay-interest method.
`The external interface to the objects remains unchanged.
`Unlike entities in the E-R model, each object has its own unique identity,
`independent of the values that it contains. Thus, two objects containing the same
`values are nevertheless distinct. The distinction among individual objects is main­
`tained in the physical level through the assignment of distinct object identifiers.
`
`1.3.2 Record-Based Logical Models
`
`Record-based logical models are used in describing data at the logical and view
`levels. In contrast to object-based data models, they are used both to specify the
`overall logical structure of the database and to provide a higher-level description
`of the implementation.
`Record-based models are so named because the database is structured in
`fixed-format records of several types. Each record type defines a fixed number
`of fields, or attributes, and each field is usually of a fixed length. As we shall
`see in Chapter 10, the use of fixed-length
`records simplifies the physical-level
`implementation of the database. This simplicity is in contrast to many of the
`object-based models, whose richer structure often leads to variable-length records
`at the physical level.
`The three most widely accepted record-based data models are the relational,
`network, and hierarchical models. The relational model, which has gained favor
`over the other two in recent years, is examined in detail in Chapters 3 through
`7. The network and hierarchical models, still used in a large number of older
`databases, are described in the appendices. Here, we present a brief overview of
`each model.
`
`1-3.2.1 Relational Model
`
`The relational model uses a collection of tables to represent both data and the re­
`lationships among those data. Each table has multiple columns, and each column
`has a unique name. Figure 1.3 presents a sample relational database comprising
`of two tables: one shows bank customers, and the other shows the accounts that
`belong to those customers. It shows, for example, that customer Johnson, with
`
`Patent Owner Finjan, Inc. - Ex. 2015, p. 11
`
`

`

`10
`
`Introduction
`
`Chapter 1
`
`customer-name
`
`social-security
`
`customer-street
`
`customer-city account-number
`
`Johnson
`Smith
`Hayes
`Turner
`Johnson
`Jones
`Lindsay
`Smith
`
`192-83-7465
`019-28-3746
`677-89-9011
`182-73-6091
`192-83-7465
`321-12-3123
`336-66-9999
`019-28-3746
`
`Alma
`North
`Main
`Putnam
`Alma
`Main
`Park
`North
`
`Palo Alto
`Rye
`Harrison
`Stamford
`Palo Alto
`Harrison
`Pittsfield
`Rye
`
`A-101
`A-215
`A-102
`A-305
`A-201
`A-217
`A-222
`A-201
`
`account-number
`
`balance
`
`A-101
`A-215
`A-102
`A-305
`A-201
`A-217
`A-222
`
`500
`700
`400
`350
`900
`750
`700
`
`Figure 1.3 A sample relational database.
`
`social-security number 321-12-3123, lives on Main in Harrison, and has two ac­
`counts: A-101, with a balance of $500, and A-201, with a balance of $900. Note
`that customers Johnson and Smith share account number A-201 (they may share
`a business venture).
`
`1.3.2.2 Network Model
`
`Data in the network model are represented by collections of records (in the Pascal
`sense), and relationships among data are represented by links, which can be viewed
`as pointers. The records in the database are organized as collections of arbitrary
`graphs. Figure 1.4 presents a sample network database using the same information
`as in Figure 1.3.
`
`1.3.2.3 Hierarchical Model
`
`The hierarchical model is similar to the network model in the sense that data
`and relationships among data are represented by records and links, respectively.
`It differs from the network model in that the records are organized as collections-
`of trees rather than arbitrary graphs. Figure 1.5 presents a sample hierarchical
`database with the same information as in Figure 1.4.
`
`1.3.2.4 Differences Among the Models
`
`The relational model differs from the network and hierarchical models in that it
`does not use pointers or links. Instead, the relational model relates records by the
`
`Patent Owner Finjan, Inc. - Ex. 2015, p. 12
`
`

`

`Section 1.3
`
`Data Models 11
`
`Figure 1.4 A sample network database.
`
`values that they contain. This freedom from the use of pointers allows a formal
`mathematical foundation to be defined.
`
`1.3.3 Physical Data Models
`
`Physical data models are used to describe data at the lowest level. In contrast to
`logical data models, there are few physical data models in use. Two of the widely
`known ones are the unifying model and the frame-memory model.
`Physical data models capture aspects of database-system implementation that
`are not covered in this book.
`
`Figure 1.5 A sample hierarchical database.
`
`Patent Owner Finjan, Inc. - Ex. 2015, p. 13
`
`

`

`12 Introduction
`
`Chapter 1
`
`1.4 Database Languages
`
`A database system provides two different types of languages: one to specify the
`database schema, and the other to express database queries and updates.
`
`1.4.1 Data-Definition Language
`
`A database schema is specified by a set of definitions expressed by a special lan­
`guage called a data-definition language (DDL). The result of compilation of DDL
`statements is a set of tables that is stored in a special file called data dictionary,
`or data directory.
`A data dictionary is a file that contains metadata—that is, data about data.
`This file
`is consulted before actual data are read or modified in the database
`system.
`The storage structure and access methods used by the database system are
`specified by a set of definitions in a special type of DDL called a data storage
`and definition language. The result of compilation of these definitions is a set of
`instructions to specify the implementation details of the database schemas—details
`are usually hidden from the users.
`
`1.4.2 Data-Manipulation Language
`
`The levels of abstraction that we discussed in Section 1.2 apply not only to the
`definition or structuring of data, but also to the manipulation of data. By data
`manipulation, we mean
`
`• The retrieval of information stored in the database
`
`• The insertion of new information into the database
`
`• The deletion of information from the database
`
`• The modification of information stored in the database
`
`At the physical level, we must define algorithms that allow efficient access to
`data. At higher levels of abstraction, we emphasize ease of use. The goal is to
`provide efficient human interaction with the system.
`A data-manipulation language (DML) is a language that enables users to
`access or manipulate data as organized by the appropriate data model. There are
`basically two types:
`
`• Procedural DMLs require a user to specify what data are needed and how to
`get those data.
`
`• Nonprocedural DMLs require a user to specify what data are needed without
`specifying how to get those data.
`
`Nonprocedural DMLs are usually easier to learn and use than are procedural
`DMLs. However, since a user does not have to specify how to get the data, these
`
`Patent Owner Finjan, Inc. - Ex. 2015, p. 14
`
`

`

`Section 1.5
`
`Transaction Management 13
`
`languages may generate code that is not as efficient as that produced by procedural
`languages. We can remedy this difficulty through various optimization techniques,
`several of which we discuss in Chapter 12.
`A query is a statement requesting the retrieval of information. The portion
`of a DML that involves information retrieval is called a query language. Although
`technically incorrect, it is common practice to use the terms query language and
`data-manipulation language synonymously.
`
`1.5 Transaction Management
`
`Often, several operations on the database form a single logical unit of work. An
`example that we saw earlier is a funds transfer, in which one account (say A)
`is debited and another account (say B) is credited. Clearly, it is essential that
`either both the credit and debit occur, or that neither occur. That is, the funds
`transfer must happen in its entirety or not at all. This all-or-none requirement is
`called atomicity. In addition, it is essential that the execution of the fund transfer
`preserve the consistency of the database. That is, the value of the sum A -f B must
`be preserved. This correctness requirement is called consistency. Finally, after the
`successful execution of a funds transfer, the new values of accounts A and B must
`persist, despite the possibility of system failure. This persistency requirement is
`called durability.
`A transaction is a collection of operations that performs a single logical
`function in a database application. Each transaction is a unit of both atomicity
`and consistency. Thus, we require that transactions do not violate any database-
`consistency constraints. That is, if the database was consistent when a transaction
`started, the database must be consistent when the transaction successfully ter­
`minates. However, during the execution of a transaction, it may be necessary
`temporarily to allow inconsistency. This temporary inconsistency, although nec­
`essary, may lead to difficulty if a failure occurs.
`It is the responsibility of the programmer to define properly the various
`transactions, such that each preserves the consistency of the database. For example,
`the transaction to transfer funds from account A to account B could be defined to
`be composed of two separate programs: one that debits account A, and another that
`credits account B. The execution of these two programs one after the other will
`indeed