【正文】 ckly.2. Query processing: how queries expressed in a very highlevel language such as SQL can be executed efficiently.3. Transaction management: how to support transactions with the ACID properties discussed in Section .Each of these topics is covered by several chapters of the book.StorageManagement OverviewChapter 11 introduces the memory hierarchy. However, since secondary storage, especially disk, is so central to the way a DBMS manages data, we examine in the greatest detail the way data is stored and accessed on disk. The “block model” for diskbased data is introduced。 it influences the way almost everything is done in a database system.Chapter 12 relates the storage of data elementsrelations, tuples, attributevalues, and their equivalents in other data modelsto the requirements of the block model of data. Then we look at the important data structures that are used for the construction of indexes. Recall that an index is a data structure that supports efficient access to data.Chapter 13 covers the important onedimensional index structuresindexedsequential files, Btrees, and hash tables. These indexes are monly used in a DBMS to support queries in which a value for an attribute is given and the tuples with that value are desired. Btrees also are used for access to a relation sorted by a given attribute.Chapter 14 discusses multidimensional indexes, which are data structures for specialized applications such as geographic databases, where queries typically ask for the contents of some region. These index structures can also support plex SQL queries that limit the values of two or more attributes, and some of these structures are beginning to appear in mercial DBMS39。s.QueryProcessing OverviewChapter 15 covers the basics of query execution. We learn a number of algorithms for efficient implementation of the operations of relational algebra. These algorithms are designed to be efficient when data is stored on disk and are in some cases rather different from analogous mainmemory algorithms.In Chapter 16 we consider the architecture of the query piler and optimizer. We begin with the parsing of queries and their semantic checking. Next, we consider the conversion of queries from SQL to relational algebra and the selection of a logical query plan, that is, an algebraic expression that represents the particular operations to be performed on data and the necessary constraints regarding order of operations. Finally, we explore the selection of a physical query plan, in which the particular order of operations and the algorithm used to implement each operation have been specified.TransactionProcessing OverviewIn Chapter 17 we see how a DBMS supports durability of transactions. The central idea is that a log of all changes to the database is made. Anything that is in mainmemory but not on disk can be lost in a crash (say, if the power supply is interrupted). Therefore we have to be careful to move from buffer to disk, in the proper order, both the database changes themselves and the log of what changes were made. There are several log strategies available, but each limits our freedom of action in some ways.Then, we take up the matter of concurrency controlassuring atomicity and isolationin Chapter 18. We view transactions as sequences of operations that read or write database elements. The major topic of the chapter is how to manage locks on database elements: the different types of locks that may be used, and the ways that transactions may be allowed to acquire locks and release their locks on elements. Also studied are a number of ways to assure atomicity and isolation without using locks.Chapter 19 concludes our study of transaction processing. We consider the interaction between the requirements of logging, as discussed in Chapter 17, and the requirements of concurrency that were discussed in Chapter 18. Handling of deadlocks, another important function of the transaction manager is covered here as well. The extension of concurrency control to a distributed environment is also considered in Chapter 19. Finally, we introduce the possibility that transactions are “l(fā)ong”, taking hours or days rather than milliseconds. A long transaction cannot lock data without causing chaos among other potential users of that data, which forces us to rethink concurrency control for applications that involve long transactions. Information Integration OverviewMuch of the recent evolution of database systems has been toward capabilities that allow different data sources, which may be databases and/or information resources that are not managed by a DBMS, to work together in a larger whole. We introduced you to these issues briefly, in Section . Thus, in the final Chapter 20, we study important aspects of information integration. We discuss the principal modes of integration, including translated and integrated copies of sources called a “data warehouse”, and virtual “views” of a collection of sources, through what is called a “mediator”.From:Hector GarciaMolina, Jeff Ullman, Jennifer Worlds of Database Systems.