Database System Concepts, Fourth Edition (PDF)

Edited by Foxit PDF Editor dddddd (c) by Foxit Software Company, 2004 Copyright For Evaluation Only. Edited by Foxit PDF Editor Copyright (c) by Foxit Software Company, 2004 For Evaluation Only. Computer Science Volume 1 Silberschatz−Korth−Sudarshan Database System Concepts, Fourth Edition Front Matter 1 Preface 1 1. Introduction 11 Text 11 I. Data Models 35 Introduction 35 2. Entity−Relationship Model 36 3. Relational Model 87 II. Relational Databases 140 Introduction 140 4. SQL 141 5. Other Relational Languages 194 6. Integrity and Security 229 7. Relational−Database Design 260 III. Object−Based Databases and XML 307 Introduction 307 8. Object−Oriented Databases 308 9. Object−Relational Databases 337 10. XML 363 IV. Data Storage and Querying 393 Introduction 393 11. Storage and File Structure 394 12. Indexing and Hashing 446 13. Query Processing 494 14. Query Optimization 529 V. Transaction Management 563 Introduction 563 15. Transactions 564 16. Concurrency Control 590 17. Recovery System 637 iii VI. Database System Architecture 679 Introduction 679 18. Database System Architecture 680 19. Distributed Databases 705 20. Parallel Databases 750 VII. Other Topics 773 Introduction 773 21. Application Development and Administration 774 22. Advanced Querying and Information Retrieval 810 23. Advanced Data Types and New Applications 856 24. Advanced Transaction Processing 884 iv Silberschatz−Korth−Sudarshan: Front Matter Preface © The McGraw−Hill 1 Database System Companies, 2001 Concepts, Fourth Edition Preface Database management has evolved from a specialized computer application to a central component of a modern computing environment, and, as a result, knowl- edge about database systems has become an essential part of an education in com- puter science. In this text, we present the fundamental concepts of database manage- ment. These concepts include aspects of database design, database languages, and database-system implementation. This text is intended for a ﬁrst course in databases at the junior or senior under- graduate, or ﬁrst-year graduate, level. In addition to basic material for a ﬁrst course, the text contains advanced material that can be used for course supplements, or as introductory material for an advanced course. We assume only a familiarity with basic data structures, computer organization, and a high-level programming language such as Java, C, or Pascal. We present con- cepts as intuitive descriptions, many of which are based on our running example of a bank enterprise. Important theoretical results are covered, but formal proofs are omitted. The bibliographical notes contain pointers to research papers in which re- sults were ﬁrst presented and proved, as well as references to material for further reading. In place of proofs, ﬁgures and examples are used to suggest why a result is true. The fundamental concepts and algorithms covered in the book are often based on those used in existing commercial or experimental database systems. Our aim is to present these concepts and algorithms in a general setting that is not tied to one particular database system. Details of particular commercial database systems are discussed in Part 8, “Case Studies.” In this fourth edition of Database System Concepts, we have retained the overall style of the ﬁrst three editions, while addressing the evolution of database management. Several new chapters have been added to cover new technologies. Every chapter has been edited, and most have been modiﬁed extensively. We shall describe the changes in detail shortly. xv 2 Silberschatz−Korth−Sudarshan: Front Matter Preface © The McGraw−Hill Database System Companies, 2001 Concepts, Fourth Edition xvi Preface Organization The text is organized in eight major parts, plus three appendices: Overview (Chapter 1). Chapter 1 provides a general overview of the nature and purpose of database systems. We explain how the concept of a database system has developed, what the common features of database systems are, what a database system does for the user, and how a database system inter- faces with operating systems. We also introduce an example database applica- tion: a banking enterprise consisting of multiple bank branches. This example is used as a running example throughout the book. This chapter is motiva- tional, historical, and explanatory in nature. Data models (Chapters 2 and 3). Chapter 2 presents the entity-relationship model. This model provides a high-level view of the issues in database design, and of the problems that we encounter in capturing the semantics of realistic applications within the constraints of a data model. Chapter 3 focuses on the relational data model, covering the relevant relational algebra and relational calculus. Relational databases (Chapters 4 through 7). Chapter 4 focuses on the most inﬂuential of the user-oriented relational languages: SQL. Chapter 5 covers two other relational languages, QBE and Datalog. These two chapters describe data manipulation: queries, updates, insertions, and deletions. Algorithms and design issues are deferred to later chapters. Thus, these chapters are suit- able for introductory courses or those individuals who want to learn the basics of database systems, without getting into the details of the internal algorithms and structure. Chapter 6 presents constraints from the standpoint of database integrity and security; Chapter 7 shows how constraints can be used in the design of a relational database. Referential integrity; mechanisms for integrity mainte- nance, such as triggers and assertions; and authorization mechanisms are pre- sented in Chapter 6. The theme of this chapter is the protection of the database from accidental and intentional damage. Chapter 7 introduces the theory of relational database design. The theory of functional dependencies and normalization is covered, with emphasis on the motivation and intuitive understanding of each normal form. The overall process of database design is also described in detail. Object-based databases and XML (Chapters 8 through 10). Chapter 8 covers object-oriented databases. It introduces the concepts of object-oriented pro- gramming, and shows how these concepts form the basis for a data model. No prior knowledge of object-oriented languages is assumed. Chapter 9 cov- ers object-relational databases, and shows how the SQL:1999 standard extends the relational data model to include object-oriented features, such as inheri- tance, complex types, and object identity. Silberschatz−Korth−Sudarshan: Front Matter Preface © The McGraw−Hill 3 Database System Companies, 2001 Concepts, Fourth Edition Preface xvii Chapter 10 covers the XML standard for data representation, which is see- ing increasing use in data communication and in the storage of complex data types. The chapter also describes query languages for XML. Data storage and querying (Chapters 11 through 14). Chapter 11 deals with disk, ﬁle, and ﬁle-system structure, and with the mapping of relational and object data to a ﬁle system. A variety of data-access techniques are presented in Chapter 12, including hashing, B+ -tree indices, and grid ﬁle indices. Chap- ters 13 and 14 address query-evaluation algorithms, and query optimization based on equivalence-preserving query transformations. These chapters provide an understanding of the internals of the storage and retrieval components of a database. Transaction management (Chapters 15 through 17). Chapter 15 focuses on the fundamentals of a transaction-processing system, including transaction atomicity, consistency, isolation, and durability, as well as the notion of serial- izability. Chapter 16 focuses on concurrency control and presents several techniques for ensuring serializability, including locking, timestamping, and optimistic (validation) techniques. The chapter also covers deadlock issues. Chapter 17 covers the primary techniques for ensuring correct transaction execution de- spite system crashes and disk failures. These techniques include logs, shadow pages, checkpoints, and database dumps. Database system architecture (Chapters 18 through 20). Chapter 18 covers computer-system architecture, and describes the inﬂuence of the underlying computer system on the database system. We discuss centralized systems, client – server systems, parallel and distributed architectures, and network types in this chapter. Chapter 19 covers distributed database systems, revis- iting the issues of database design, transaction management, and query eval- uation and optimization, in the context of distributed databases. The chap- ter also covers issues of system availability during failures and describes the LDAP directory system. Chapter 20, on parallel databases explores a variety of parallelization tech- niques, including I/O parallelism, interquery and intraquery parallelism, and interoperation and intraoperation parallelism. The chapter also describes parallel-system design. Other topics (Chapters 21 through 24). Chapter 21 covers database appli- cation development and administration. Topics include database interfaces, particularly Web interfaces, performance tuning, performance benchmarks, standardization, and database issues in e-commerce. Chapter 22 covers query- ing techniques, including decision support systems, and information retrieval. Topics covered in the area of decision support include online analytical pro- cessing (OLAP) techniques, SQL:1999 support for OLAP, data mining, and data warehousing. The chapter also describes information retrieval techniques for 4 Silberschatz−Korth−Sudarshan: Front Matter Preface © The McGraw−Hill Database System Companies, 2001 Concepts, Fourth Edition xviii Preface querying textual data, including hyperlink-based techniques used in Web search engines. Chapter 23 covers advanced data types and new applications, including temporal data, spatial and geographic data, multimedia data, and issues in the management of mobile and personal databases. Finally, Chapter 24 deals with advanced transaction processing. We discuss transaction-processing monitors, high-performance transaction systems, real-time transaction systems, and transactional workﬂows. Case studies (Chapters 25 through 27). In this part we present case studies of three leading commercial database systems, including Oracle, IBM DB2, and Microsoft SQL Server. These chapters outline unique features of each of these products, and describe their internal structure. They provide a wealth of in- teresting information about the respective products, and help you see how the various implementation techniques described in earlier parts are used in real systems. They also cover several interesting practical aspects in the design of real systems. Online appendices. Although most new database applications use either the relational model or the object-oriented model, the network and hierarchical data models are still in use. For the beneﬁt of readers who wish to learn about these data models, we provide appendices describing the network and hier- archical data models, in Appendices A and B respectively; the appendices are available only online (http://www.bell-labs.com/topic/books/db-book). Appendix C describes advanced relational database design, including the theory of multivalued dependencies, join dependencies, and the project-join and domain-key normal forms. This appendix is for the beneﬁt of individuals who wish to cover the theory of relational database design in more detail, and instructors who wish to do so in their courses. This appendix, too, is available only online, on the Web page of the book. The Fourth Edition The production of this fourth edition has been guided by the many comments and suggestions we received concerning the earlier editions, by our own observations while teaching at IIT Bombay, and by our analysis of the directions in which database technology is evolving. Our basic procedure was to rewrite the material in each chapter, bringing the older material up to date, adding discussions on recent developments in database technol- ogy, and improving descriptions of topics that students found difﬁcult to understand. Each chapter now has a list of review terms, which can help you review key topics covered in the chapter. We have also added a tools section at the end of most chap- ters, which provide information on software tools related to the topic of the chapter. We have also added new exercises, and updated references. We have added a new chapter covering XML, and three case study chapters cov- ering the leading commercial database systems, including Oracle, IBM DB2, and Mi- crosoft SQL Server. Silberschatz−Korth−Sudarshan: Front Matter Preface © The McGraw−Hill 5 Database System Companies, 2001 Concepts, Fourth Edition Preface xix We have organized the chapters into several parts, and reorganized the contents of several chapters. For the beneﬁt of those readers familiar with the third edition, we explain the main changes here: Entity-relationship model. We have improved our coverage of the entity- relationship (E-R) model. More examples have been added, and some changed, to give better intuition to the reader. A summary of alternative E-R notations has been added, along with a new section on UML. Relational databases. Our coverage of SQL in Chapter 4 now references the SQL:1999 standard, which was approved after publication of the third edition. SQL coverage has been signiﬁcantly expanded to include the with clause, ex- panded coverage of embedded SQL, and coverage of ODBC and JDBC whose usage has increased greatly in the past few years. Coverage of Quel has been dropped from Chapter 5, since it is no longer in wide use. Coverage of QBE has been revised to remove some ambiguities and to add coverage of the QBE version used in the Microsoft Access database. Chapter 6 now covers integrity constraints and security. Coverage of se- curity has been moved to Chapter 6 from its third-edition position of Chap- ter 19. Chapter 6 also covers triggers. Chapter 7 covers relational-database design and normal forms. Discussion of functional dependencies has been moved into Chapter 7 from its third-edition position of Chapter 6. Chapter 7 has been signiﬁcantly rewritten, providing several short-cut algorithms for dealing with functional dependencies and extended coverage of the overall database design process. Axioms for multivalued dependency inference, PJNF and DKNF, have been moved into an appendix. Object-based databases. Coverage of object orientation in Chapter 8 has been improved, and the discussion of ODMG updated. Object-relational coverage in Chapter 9 has been updated, and in particular the SQL:1999 standard replaces the extended SQL used in the third edition. XML. Chapter 10, covering XML, is a new chapter in the fourth edition. Storage, indexing, and query processing. Coverage of storage and ﬁle struc- tures, in Chapter 11, has been updated; this chapter was Chapter 10 in the third edition. Many characteristics of disk drives and other storage mecha- nisms have changed greatly in the past few years, and our coverage has been correspondingly updated. Coverage of RAID has been updated to reﬂect tech- nology trends. Coverage of data dictionaries (catalogs) has been extended. Chapter 12, on indexing, now includes coverage of bitmap indices; this chapter was Chapter 11 in the third edition. The B+ -tree insertion algorithm has been simpliﬁed, and pseudocode has been provided for search. Parti- tioned hashing has been dropped, since it is not in signiﬁcant use. Our treatment of query processing has been reorganized, with the earlier chapter (Chapter 12 in the third edition) split into two chapters, one on query processing (Chapter 13) and another on query optimization (Chapter 14). All details regarding cost estimation and query optimization have been moved 6 Silberschatz−Korth−Sudarshan: Front Matter Preface © The McGraw−Hill Database System Companies, 2001 Concepts, Fourth Edition xx Preface to Chapter 14, allowing Chapter 13 to concentrate on query processing algo- rithms. We have dropped several detailed (and tedious) formulae for calcu- lating the exact number of I/O operations for different operations. Chapter 14 now has pseudocode for optimization algorithms, and new sections on opti- mization of nested subqueries and on materialized views. Transaction processing. Chapter 15, which provides an introduction to trans- actions, has been updated; this chapter was numbered Chapter 13 in the third edition. Tests for view serializability have been dropped. Chapter 16, on concurrency control, includes a new section on implemen- tation of lock managers, and a section on weak levels of consistency, which was in Chapter 20 of the third edition. Concurrency control of index structures has been expanded, providing details of the crabbing protocol, which is a sim- pler alternative to the B-link protocol, and next-key locking to avoid the phan- tom problem. Chapter 17, on recovery, now includes coverage of the ARIES recovery algorithm. This chapter also covers remote backup systems for pro- viding high availability despite failures, an increasingly important feature in “24 × 7” applications. As in the third edition, instructors can choose between just introducing transaction-processing concepts (by covering only Chapter 15), or offering de- tailed coverage (based on Chapters 15 through 17). Database system architectures. Chapter 18, which provides an overview of database system architectures, has been updated to cover current technology; this was Chapter 16 in the third edition. The order of the parallel database chapter and the distributed database chapters has been ﬂipped. While the cov- erage of parallel database query processing techniques in Chapter 20 (which was Chapter 16 in the third edition) is mainly of interest to those who wish to learn about database internals, distributed databases, now covered in Chapter 19, is a topic that is more fundamental; it is one that anyone dealing with databases should be familiar with. Chapter 19 on distributed databases has been signiﬁcantly rewritten, to re- duce the emphasis on naming and transparency and to increase coverage of operation during failures, including concurrency control techniques to pro- vide high availability. Coverage of three-phase commit protocol has been ab- breviated, as has distributed detection of global deadlocks, since neither is used much in practice. Coverage of query processing issues in heterogeneous databases has been moved up from Chapter 20 of the third edition. There is a new section on directory systems, in particular LDAP, since these are quite widely used as a mechanism for making information available in a distributed setting. Other topics. Although we have modiﬁed and updated the entire text, we concentrated our presentation of material pertaining to ongoing database re- search and new database applications in four new chapters, from Chapter 21 to Chapter 24. Silberschatz−Korth−Sudarshan: Front Matter Preface © The McGraw−Hill 7 Database System Companies, 2001 Concepts, Fourth Edition Preface xxi Chapter 21 is new in the fourth edition and covers application develop- ment and administration. The description of how to build Web interfaces to databases, including servlets and other mechanisms for server-side scripting, is new. The section on performance tuning, which was earlier in Chapter 19, has new material on the famous 5-minute rule and the 1-minute rule, as well as some new examples. Coverage of materialized view selection is also new. Coverage of benchmarks and standards has been updated. There is a new sec- tion on e-commerce, focusing on database issues in e-commerce, and a new section on dealing with legacy systems. Chapter 22, which covers advanced querying and information retrieval, includes new material on OLAP, particulary on SQL:1999 extensions for data analysis. Coverage of data warehousing and data mining has also been ex- tended greatly. Coverage of information retrieval has been signiﬁcantly ex- tended, particulary in the area of Web searching. Earlier versions of this ma- terial were in Chapter 21 of the third edition. Chapter 23, which covers advanced data types and new applications, has material on temporal data, spatial data, multimedia data, and mobile data- bases. This material is an updated version of material that was in Chapter 21 of the third edition. Chapter 24, which covers advanced transaction process- ing, contains updated versions of sections on TP monitors, workﬂow systems, main-memory and real-time databases, long-duration transactions, and trans- action management in multidatabases, which appeared in Chapter 20 of the third edition. Case studies. The case studies covering Oracle, IBM DB2 and Microsoft SQL Server are new to the fourth edition. These chapters outline unique features of each of these products, and describe their internal structure. Instructor’s Note The book contains both basic and advanced material, which might not be covered in a single semester. We have marked several sections as advanced, using the symbol “∗∗”. These sections may be omitted if so desired, without a loss of continuity. It is possible to design courses by using various subsets of the chapters. We outline some of the possibilities here: Chapter 5 can be omitted if students will not be using QBE or Datalog as part of the course. If object orientation is to be covered in a separate advanced course, Chapters 8 and 9, and Section 11.9, can be omitted. Alternatively, they could constitute the foundation of an advanced course in object databases. Chapter 10 (XML) and Chapter 14 (query optimization) can be omitted from an introductory course. Both our coverage of transaction processing (Chapters 15 through 17) and our coverage of database-system architecture (Chapters 18 through 20) consist of 8 Silberschatz−Korth−Sudarshan: Front Matter Preface © The McGraw−Hill Database System Companies, 2001 Concepts, Fourth Edition xxii Preface an overview chapter (Chapters 15 and 18, respectively), followed by chap- ters with details. You might choose to use Chapters 15 and 18, while omitting Chapters 16, 17, 19, and 20, if you defer these latter chapters to an advanced course. Chapters 21 through 24 are suitable for an advanced course or for self-study by students, although Section 21.1 may be covered in a ﬁrst database course. Model course syllabi, based on the text, can be found on the Web home page of the book (see the following section). Web Page and Teaching Supplements A Web home page for the book is available at the URL: http://www.bell-labs.com/topic/books/db-book The Web page contains: Slides covering all the chapters of the book Answers to selected exercises The three appendices An up-to-date errata list Supplementary material contributed by users of the book A complete solution manual will be made available only to faculty. For more infor- mation about how to get a copy of the solution manual, please send electronic mail to [email protected]. In the United States, you may call 800-338-3987. The McGraw-Hill Web page for this book is http://www.mhhe.com/silberschatz Contacting Us and Other Users We provide a mailing list through which users of our book can communicate among themselves and with us. If you wish to be on the list, please send a message to [email protected], include your name, afﬁliation, title, and electronic mail address. We have endeavored to eliminate typos, bugs, and the like from the text. But, as in new releases of software, bugs probably remain; an up-to-date errata list is accessible from the book’s home page. We would appreciate it if you would notify us of any errors or omissions in the book that are not on the current list of errata. We would be glad to receive suggestions on improvements to the books. We also welcome any contributions to the book Web page that could be of use to other read- Silberschatz−Korth−Sudarshan: Front Matter Preface © The McGraw−Hill 9 Database System Companies, 2001 Concepts, Fourth Edition Preface xxiii ers, such as programming exercises, project suggestions, online labs and tutorials, and teaching tips. E-mail should be addressed to [email protected]. Any other cor- respondence should be sent to Avi Silberschatz, Bell Laboratories, Room 2T-310, 600 Mountain Avenue, Murray Hill, NJ 07974, USA. Acknowledgments This edition has beneﬁted from the many useful comments provided to us by the numerous students who have used the third edition. In addition, many people have written or spoken to us about the book, and have offered suggestions and comments. Although we cannot mention all these people here, we especially thank the following: Phil Bernhard, Florida Institute of Technology; Eitan M. Gurari, The Ohio State University; Irwin Levinstein, Old Dominion University; Ling Liu, Georgia In- stitute of Technology; Ami Motro, George Mason University; Bhagirath Nara- hari, Meral Ozsoyoglu, Case Western Reserve University; and Odinaldo Ro- driguez, King’s College London; who served as reviewers of the book and whose comments helped us greatly in formulating this fourth edition. Soumen Chakrabarti, Sharad Mehrotra, Krithi Ramamritham, Mike Reiter, Sunita Sarawagi, N. L. Sarda, and Dilys Thomas, for extensive and invaluable feedback on several chapters of the book. Phil Bohannon, for writing the ﬁrst draft of Chapter 10 describing XML. Hakan Jakobsson (Oracle), Sriram Padmanabhan (IBM), and César Galindo- Legaria, Goetz Graefe, José A. Blakeley, Kalen Delaney, Michael Rys, Michael Zwilling, Sameet Agarwal, Thomas Casey (all of Microsoft) for writing the appendices describing the Oracle, IBM DB2, and Microsoft SQL Server database systems. Yuri Breitbart, for help with the distributed database chapter; Mike Reiter, for help with the security sections; and Jim Melton, for clariﬁcations on SQL:1999. Marilyn Turnamian and Nandprasad Joshi, whose excellent secretarial assis- tance was essential for timely completion of this fourth edition. The publisher was Betsy Jones. The senior developmental editor was Kelley Butcher. The project manager was Jill Peter. The executive marketing manager was John Wannemacher. The cover illustrator was Paul Tumbaugh while the cover de- signer was JoAnne Schopler. The freelance copyeditor was George Watson. The free- lance proofreader was Marie Zartman. The supplement producer was Jodi Banowetz. The designer was Rick Noel. The freelance indexer was Tobiah Waldron. This edition is based on the three previous editions, so we thank once again the many people who helped us with the ﬁrst three editions, including R. B. Abhyankar, Don Batory, Haran Boral, Paul Bourgeois, Robert Brazile, Michael Carey, J. Edwards, Christos Faloutsos, Homma Farian, Alan Fekete, Shashi Gadia, Jim Gray, Le Gruen- 10 Silberschatz−Korth−Sudarshan: Front Matter Preface © The McGraw−Hill Database System Companies, 2001 Concepts, Fourth Edition xxiv Preface wald, Ron Hitchens, Yannis Ioannidis, Hyoung-Joo Kim, Won Kim, Henry Korth (fa- ther of Henry F.), Carol Kroll, Gary Lindstrom, Dave Maier, Keith Marzullo, Fletcher Mattox, Alberto Mendelzon, Hector Garcia-Molina, Ami Motro, Anil Nigam, Cyril Orji, Bruce Porter, Jim Peterson, K. V. Raghavan, Mark Roth, Marek Rusinkiewicz, S. Seshadri, Shashi Shekhar, Amit Sheth, Nandit Soparkar, Greg Speegle, and Mari- anne Winslett. Lyn Dupré copyedited the third edition and Sara Strandtman edited the text of the third edition. Greg Speegle, Dawn Bezviner, and K. V. Raghavan helped us to prepare the instructor’s manual for earlier editions. The new cover is an evo- lution of the covers of the ﬁrst three editions; Marilyn Turnamian created an early draft of the cover design for this edition. The idea of using ships as part of the cover concept was originally suggested to us by Bruce Stephan. Finally, Sudarshan would like to acknowledge his wife, Sita, for her love and sup- port, two-year old son Madhur for his love, and mother, Indira, for her support. Hank would like to acknowledge his wife, Joan, and his children, Abby and Joe, for their love and understanding. Avi would like to acknowledge his wife Haya, and his son, Aaron, for their patience and support during the revision of this book. A. S. H. F. K. S. S. Silberschatz−Korth−Sudarshan: 1. Introduction Text © The McGraw−Hill 11 Database System Companies, 2001 Concepts, Fourth Edition C H A P T E R 1 Introduction A database-management system (DBMS) is 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 relevant to an enterprise. The primary goal of a DBMS is to provide a way to store and retrieve database information that is both convenient and efﬁcient. Database systems are designed to manage large bodies of information. Manage- ment of data involves both deﬁning structures for storage of information and pro- viding mechanisms for the manipulation of information. In addition, the database system must ensure 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. Because information is so important in most organizations, computer scientists have developed a large body of concepts and techniques for managing data. These concepts and technique form the focus of this book. This chapter brieﬂy introduces the principles of database systems. 1.1 Database System Applications Databases are widely used. Here are some representative applications: Banking: For customer information, accounts, and loans, and banking transac- tions. Airlines: For reservations and schedule information. Airlines were among the ﬁrst to use databases in a geographically distributed manner — terminals sit- uated around the world accessed the central database system through phone lines and other data networks. Universities: For student information, course registrations, and grades. 1 12 Silberschatz−Korth−Sudarshan: 1. Introduction Text © The McGraw−Hill Database System Companies, 2001 Concepts, Fourth Edition 2 Chapter 1 Introduction Credit card transactions: For purchases on credit cards and generation of month- ly statements. Telecommunication: For keeping records of calls made, generating monthly bills, maintaining balances on prepaid calling cards, and storing information about the communication networks. Finance: For storing information about holdings, sales, and purchases of ﬁnan- cial instruments such as stocks and bonds. Sales: For customer, product, and purchase information. Manufacturing: For management of supply chain and for tracking production of items in factories, inventories of items in warehouses/stores, and orders for items. Human resources: For information about employees, salaries, payroll taxes and beneﬁts, and for generation of paychecks. As the list illustrates, databases form an essential part of almost all enterprises today. Over the course of the last four decades of the twentieth century, use of databases grew in all enterprises. In the early days, very few people interacted directly with database systems, although without realizing it they interacted with databases in- directly — through printed reports such as credit card statements, or through agents such as bank tellers and airline reservation agents. Then automated teller machines came along and let users interact directly with databases. Phone interfaces to com- puters (interactive voice response systems) also allowed users to deal directly with databases— a caller could dial a number, and press phone keys to enter information or to select alternative options, to ﬁnd ﬂight arrival/departure times, for example, or to register for courses in a university. The internet revolution of the late 1990s sharply increased direct user access to databases. Organizations converted many of their phone interfaces to databases into Web interfaces, and made a variety of services and information available online. For instance, when you access an online bookstore and browse a book or music collec- tion, you are accessing data stored in a database. When you enter an order online, your order is stored in a database. When you access a bank Web site and retrieve your bank balance and transaction information, the information is retrieved from the bank’s database system. When you access a Web site, information about you may be retrieved from a database, to select which advertisements should be shown to you. Furthermore, data about your Web accesses may be stored in a database. Thus, although user interfaces hide details of access to a database, and most people are not even aware they are dealing with a database, accessing databases forms an essential part of almost everyone’s life today. The importance of database systems can be judged in another way — today, data- base system vendors like Oracle are among the largest software companies in the world, and database systems form an important part of the product line of more diversiﬁed companies like Microsoft and IBM. Silberschatz−Korth−Sudarshan: 1. Introduction Text © The McGraw−Hill 13 Database System Companies, 2001 Concepts, Fourth Edition 1.2 Database Systems versus File Systems 3 1.2 Database Systems versus File Systems Consider part of a savings-bank enterprise that keeps information about all cus- tomers and savings accounts. One way to keep the information on a computer is to store it in operating system ﬁles. To allow users to manipulate the information, the system has a number of application programs that manipulate the ﬁles, including A program to debit or credit an account A program to add a new account A program to ﬁnd the balance of an account A program to generate monthly statements System programmers wrote these application programs to meet the needs of the bank. New application programs are added to the system as the need arises. For exam- ple, suppose that the savings bank decides to offer checking accounts. As a result, the bank creates new permanent ﬁles that contain information about all the checking accounts maintained in the bank, and it may have to write new application programs to deal with situations that do not arise in savings accounts, such as overdrafts. Thus, as time goes by, the system acquires more ﬁles and more application programs. This typical ﬁle-processing system is supported by a conventional operating sys- tem. The system stores permanent records in various ﬁles, and it needs different application programs to extract records from, and add records to, the appropriate ﬁles. Before database management systems (DBMSs) came along, organizations usu- ally stored information in such systems. Keeping organizational information in a ﬁle-processing system has a number of major disadvantages: Data redundancy and inconsistency. Since different programmers create the ﬁles and application programs over a long period, the various ﬁles are likely to have different formats and the programs may be written in several pro- gramming languages. Moreover, the same information may be duplicated in several places (ﬁles). For example, the address and telephone number of a par- ticular customer may appear in a ﬁle that consists of savings-account records and in a ﬁle that consists of checking-account records. This redundancy leads to higher storage and access cost. In addition, it may lead to data inconsis- tency; that is, the various copies of the same data may no longer agree. For example, a changed customer address may be reﬂected in savings-account records but not elsewhere in the system. Difﬁculty in accessing data. Suppose that one of the bank ofﬁcers needs to ﬁnd out the names of all customers who live within a particular postal-code area. The ofﬁcer asks the data-processing department to generate such a list. Because the designers of the original system did not anticipate this request, 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 ofﬁcer has 14 Silberschatz−Korth−Sudarshan: 1. Introduction Text © The McGraw−Hill Database System Companies, 2001 Concepts, Fourth Edition 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 ofﬁcer 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 ofﬁcer has the preceding two options, neither of which is satisfactory. The point here is that conventional ﬁle-processing environments do not al- low needed data to be retrieved in a convenient and efﬁcient manner. More responsive data-retrieval systems are required for general use. Data isolation. Because data are scattered in various ﬁles, and ﬁles may be in different formats, writing new application programs to retrieve the appropri- ate data is difﬁcult. 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 difﬁcult to change the programs to enforce them. The problem is compounded when constraints involve several data items from different ﬁles. 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 difﬁcult to ensure atomicity in a conventional ﬁle-processing system. Concurrent-access anomalies. For the sake of overall performance of the sys- 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 Silberschatz−Korth−Sudarshan: 1. Introduction Text © The McGraw−Hill 15 Database System Companies, 2001 Concepts, Fourth Edition 1.3 View of Data 5 last, the account may contain either $450 or $400, rather than the correct value of $350. To guard against this possibility, the system must maintain some form of supervision. But supervision is difﬁcult to provide because data may be accessed by many different application programs that have not been coordi- nated previously. 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 various bank employees. They do not need access to information about customer ac- counts. But, since application programs are added to the system in an ad hoc manner, enforcing such security constraints is difﬁcult. These difﬁculties, among others, prompted the development of database systems. In what follows, we shall see the concepts and algorithms that enable database sys- tems to solve the problems with ﬁle-processing systems. In most of this book, we use a bank enterprise as a running example of a typical data-processing application found in a corporation. 1.3 View of Data A database system is a collection of interrelated ﬁles and a set of programs that allow users to access and modify these ﬁles. 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.3.1 Data Abstraction For the system to be usable, it must retrieve data efﬁciently. The need for efﬁciency has led designers to use complex data structures to represent 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’ inter- actions with the system: Physical level. The lowest level of abstraction describes how the data are actu- ally stored. The physical level describes complex low-level data structures 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 logical level thus describes the entire database in terms of a small number of relatively simple structures. Although implementation of the simple struc- tures at the logical level may involve complex physical-level structures, the user of the logical level does not need to be aware of this complexity. Database administrators, who must decide what information to keep in the database, use the logical level of abstraction. 16 Silberschatz−Korth−Sudarshan: 1. Introduction Text © The McGraw−Hill Database System Companies, 2001 Concepts, Fourth Edition 6 Chapter 1 Introduction View level. The highest level of abstraction describes only part of the entire database. Even though the logical level uses simpler structures, complexity remains because of the variety of information stored in a large database. Many users of the database system do not need all this information; instead, they need to access only a part of the database. The view level of abstraction exists to simplify their interaction with the system. The system may provide many views for the same database. Figure 1.1 shows the relationship among the three levels of abstraction. 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-id : string; customer-name : string; customer-street : string; customer-city : string; end; This code deﬁnes a new record type called customer with four ﬁelds. Each ﬁeld has a name and a type associated with it. A banking enterprise may have several such record types, including account, with ﬁelds account-number and balance employee, with ﬁelds employee-name and salary At the physical level, a customer, account, or employee record can be described as a block of consecutive storage locations (for example, words or bytes). The language view level view 1 view 2 … view n logical level physical level Figure 1.1 The three levels of data abstraction. Silberschatz−Korth−Sudarshan: 1. Introduction Text © The McGraw−Hill 17 Database System Companies, 2001 Concepts, Fourth Edition 1.4 Data Models 7 compiler hides this level of detail from programmers. Similarly, the database system hides many of the lowest-level storage details from database programmers. Database administrators, on the other hand, may be aware of certain details of the physical organization of the data. At the logical level, each such record is described by a type deﬁnition, as in the previous code segment, and the interrelationship of these record types is deﬁned as well. 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 deﬁned, 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 certain 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 about salaries of employees. 1.3.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. The concept of database schemas and instances can be understood by analogy to a program written in a programming language. A database schema corresponds to the variable declarations (along with associated type deﬁnitions) in a program. Each variable has a particular value at a given instant. The values of the variables in a program at a point in time correspond to an instance of a database schema. Database systems have several schemas, partitioned according to the levels of ab- straction. The physical schema describes the database design at the physical level, while the logical schema describes the database design at the logical level. A database may also have several schemas at the view level, sometimes called subschemas, that describe different views of the database. Of these, the logical schema is by far the most important, in terms of its effect on application programs, since programmers construct applications by using the logical schema. The physical schema is hidden beneath the logical schema, and can usually be changed easily without affecting application programs. Application programs are said to exhibit physical data independence if they do not depend on the physical schema, and thus need not be rewritten if the physical schema changes. We study languages for describing schemas, after introducing the notion of data models in the next section. 1.4 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. To illustrate the concept of a data model, we outline two data models in this 18 Silberschatz−Korth−Sudarshan: 1. Introduction Text © The McGraw−Hill Database System Companies, 2001 Concepts, Fourth Edition 8 Chapter 1 Introduction section: the entity-relationship model and the relational model. Both provide a way to describe the design of a database at the logical level. 1.4.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 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 as entities. Entities are described in a database by a set of attributes. For example, the at- tributes account-number and balance may describe one particular account in a bank, and they form attributes of the account entity set. Similarly, attributes customer-name, customer-street address and customer-city may describe a customer entity. An extra attribute customer-id is used to uniquely identify customers (since it may be possible to have two customers with the same name, street address, and city). A unique customer identiﬁer must be assigned to each customer. In the United States, many enterprises use the social-security number of a person (a unique number the U.S. government assigns to every person in the United States) as a customer identiﬁer. A relationship is an association among several entities. For example, a depositor relationship associates a customer with each account that she has. The set of all enti- ties of the same type and the set of all relationships of the same type are termed an entity set and relationship set, respectively. The overall logical structure (schema) 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. As an illustration, consider part of a database banking system consisting of customers and of the accounts that these customers have. Figure 1.2 shows the cor- responding E-R diagram. The E-R diagram indicates that there are two entity sets, customer and account, with attributes as outlined earlier. The diagram also shows a relationship depositor between customer and account. In addition to entities and relationships, the E-R model represents certain con- straints to which the contents of a database must conform. One important constraint is mapping cardinalities, which express the number of entities to which another en- tity can be associated via a relationship set. For example, if each account must belong to only one customer, the E-R model can express that constraint. The entity-relationship model is widely used in database design, and Chapter 2 explores it in detail. Silberschatz−Korth−Sudarshan: 1. Introduction Text © The McGraw−Hill 19 Database System Companies, 2001 Concepts, Fourth Edition 1.4 Data Models 9 customer-name customer-street account-number balance customer-id customer-city customer depositor account Figure 1.2 A sample E-R diagram. 1.4.2 Relational Model The relational model uses a collection of tables to represent both data and the rela- tionships among those data. Each table has multiple columns, and each column has a unique name. Figure 1.3 presents a sample relational database comprising three ta- bles: One shows details of bank customers, the second shows accounts, and the third shows which accounts belong to which customers. The ﬁrst table, the customer table, shows, for example, that the customer identiﬁed by customer-id 192-83-7465 is named Johnson and lives at 12 Alma St. in Palo Alto. The second table, account, shows, for example, that account A-101 has a balance of $500, and A-201 has a balance of $900. The third table shows which accounts belong to which customers. For example, account number A-101 belongs to the customer whose customer-id is 192-83-7465, namely Johnson, and customers 192-83-7465 (Johnson) and 019-28-3746 (Smith) share account number A-201 (they may share a business venture). The relational model is an example of a record-based model. Record-based mod- els are so named because the database is structured in ﬁxed-format records of several types. Each table contains records of a particular type. Each record type deﬁnes a ﬁxed number of ﬁelds, or attributes. The columns of the table correspond to the at- tributes of the record type. It is not hard to see how tables may be stored in ﬁles. For instance, a special character (such as a comma) may be used to delimit the different attributes of a record, and another special character (such as a newline character) may be used to delimit records. The relational model hides such low-level implementation details from database developers and users. The relational data model is the most widely used data model, and a vast majority of current database systems are based on the relational model. Chapters 3 through 7 cover the relational model in detail. The relational model is at a lower level of abstraction than the E-R model. Database designs are often carried out in the E-R model, and then translated to the relational model; Chapter 2 describes the translation process. For example, it is easy to see that the tables customer and account correspond to the entity sets of the same name, while the table depositor corresponds to the relationship set depositor. We also note that it is possible to create schemas in the relational model that have problems such as unnecessarily duplicated information. For example, suppose we 20 Silberschatz−Korth−Sudarshan: 1. Introduction Text © The McGraw−Hill Database System Companies, 2001 Concepts, Fourth Edition 10 Chapter 1 Introduction customer-id customer-name customer-street customer-city 192-83-7465 Johnson 12 Alma St. Palo Alto 019-28-3746 Smith 4 North St. Rye 677-89-9011 Hayes 3 Main St. Harrison 182-73-6091 Turner 123 Putnam Ave. Stamford 321-12-3123 Jones 100 Main St. Harrison 336-66-9999 Lindsay 175 Park Ave. Pittsfield 019-28-3746 Smith 72 North St. Rye (a) The customer table account-number balance A-101 500 A-215 700 A-102 400 A-305 350 A-201 900 A-217 750 A-222 700 (b) The account table customer-id account-number 192-83-7465 A-101 192-83-7465 A-201 019-28-3746 A-215 677-89-9011 A-102 182-73-6091 A-305 321-12-3123 A-217 336-66-9999 A-222 019-28-3746 A-201 (c) The depositor table Figure 1.3 A sample relational database. store account-number as an attribute of the customer record. Then, to represent the fact that accounts A-101 and A-201 both belong to customer Johnson (with customer-id 192-83-7465), we would need to store two rows in the customer table. The values for customer-name, customer-street, and customer-city for Johnson would get unneces- sarily duplicated in the two rows. In Chapter 7, we shall study how to distinguish good schema designs from bad schema designs. 1.4.3 Other Data Models The object-oriented data model is another data model that has seen increasing atten- tion. The object-oriented model can be seen as extending the E-R model with notions Silberschatz−Korth−Sudarshan: 1. Introduction Text © The McGraw−Hill 21 Database System Companies, 2001 Concepts, Fourth Edition 1.5 Database Languages 11 of encapsulation, methods (functions), and object identity. Chapter 8 examines the object-oriented data model. The object-relational data model combines features of the object-oriented data model and relational data model. Chapter 9 examines it. Semistructured data models permit the speciﬁcation of data where individual data items of the same type may have different sets of attributes. This is in contrast with the data models mentioned earlier, where every data item of a particular type must have the same set of attributes. The extensible markup language (XML) is widely used to represent semistructured data. Chapter 10 covers it. Historically, two other data models, the network data model and the hierarchical data model, preceded the relational data model. These models were tied closely to the underlying implementation, and complicated the task of modeling data. As a result they are little used now, except in old database code that is still in service in some places. They are outlined in Appendices A and B, for interested readers. 1.5 Database Languages A database system provides a data deﬁnition language to specify the database sche- ma and a data manipulation language to express database queries and updates. In practice, the data deﬁnition and data manipulation languages are not two separate languages; instead they simply form parts of a single database language, such as the widely used SQL language. 1.5.1 Data-Deﬁnition Language We specify a database schema by a set of deﬁnitions expressed by a special language called a data-deﬁnition language (DDL). For instance, the following statement in the SQL language deﬁnes the account table: create table account (account-number char(10), balance integer) Execution of the above DDL statement creates the account table. In addition, it up- dates a special set of tables called the data dictionary or data directory. A data dictionary contains metadata — that is, data about data. The schema of a ta- ble is an example of metadata. A database system consults the data dictionary before reading or modifying actual data. We specify the storage structure and access methods used by the database system by a set of statements in a special type of DDL called a data storage and deﬁnition lan- guage. These statements deﬁne the implementation details of the database schemas, which are usually hidden from the users. The data values stored in the database must satisfy certain consistency constraints. For example, suppose the balance on an account should not fall below $100. The DDL provides facilities to specify such constraints. The database systems check these con- straints every time the database is updated. 22 Silberschatz−Korth−Sudarshan: 1. Introduction Text © The McGraw−Hill Database System Companies, 2001 Concepts, Fourth Edition 12 Chapter 1 Introduction 1.5.2 Data-Manipulation Language Data manipulation is The retrieval of information stored in the database The insertion of new information into the database The deletion of information from the database The modiﬁcation of information stored in the database 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. Declarative DMLs (also referred to as nonprocedural DMLs) require a user to specify what data are needed without specifying how to get those data. Declarative 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, the database system has to ﬁgure out an efﬁcient means of accessing data. The DML component of the SQL language is nonprocedural. 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 tech- nically incorrect, it is common practice to use the terms query language and data- manipulation language synonymously. This query in the SQL language ﬁnds the name of the customer whose customer-id is 192-83-7465: select customer.customer-name from customer where customer.customer-id = 192-83-7465 The query speciﬁes that those rows from the table customer where the customer-id is 192-83-7465 must be retrieved, and the customer-name attribute of these rows must be displayed. If the query were run on the table in Figure 1.3, the name Johnson would be displayed. Queries may involve information from more than one table. For instance, the fol- lowing query ﬁnds the balance of all accounts owned by the customer with customer- id 192-83-7465. select account.balance from depositor, account where depositor.customer-id = 192-83-7465 and depositor.account-number = account.account-number Silberschatz−Korth−Sudarshan: 1. Introduction Text © The McGraw−Hill 23 Database System Companies, 2001 Concepts, Fourth Edition 1.6 Database Users and Administrators 13 If the above query were run on the tables in Figure 1.3, the system would ﬁnd that the two accounts numbered A-101 and A-201 are owned by customer 192-83-7465 and would print out the balances of the two accounts, namely 500 and 900. There are a number of database query languages in use, either commercially or experimentally. We study the most widely used query language, SQL, in Chapter 4. We also study some other query languages in Chapter 5. The levels of abstraction that we discussed in Section 1.3 apply not only to deﬁning or structuring data, but also to manipulating data. At the physical level, we must deﬁne algorithms that allow efﬁcient access to data. At higher levels of abstraction, we emphasize ease of use. The goal is to allow humans to interact efﬁciently with the system. The query processor component of the database system (which we study in Chapters 13 and 14) translates DML queries into sequences of actions at the physical level of the database system. 1.5.3 Database Access from Application Programs Application programs are programs that are used to interact with the database. Ap- plication programs are usually written in a host language, such as Cobol, C, C++, or Java. Examples in a banking system are programs that generate payroll checks, debit accounts, credit accounts, or transfer funds between accounts. To access the database, DML statements need to be executed from the host lan- guage. There are two ways to do this: By providing an application program interface (set of procedures) that can be used to send DML and DDL statements to the database, and retrieve the results. The Open Database Connectivity (ODBC) standard deﬁned by Microsoft for use with the C language is a commonly used application program inter- face standard. The Java Database Connectivity (JDBC) standard provides cor- responding features to the Java language. By extending the host language syntax to embed DML calls within the host language program. Usually, a special character prefaces DML calls, and a pre- processor, called the DML precompiler, converts the DML statements to nor- mal procedure calls in the host language. 1.6 Database Users and Administrators A primary goal of a database system is to retrieve information from and store new information in the database. People who work with a database can be categorized as database users or database administrators. 1.6.1 Database Users and User Interfaces There are four different types of database-system users, differentiated by the way they expect to interact with the system. Different types of user interfaces have been designed for the different types of users. 24 Silberschatz−Korth−Sudarshan: 1. Introduction Text © The McGraw−Hill Database System Companies, 2001 Concepts, Fourth Edition 14 Chapter 1 Introduction Naive users are unsophisticated users who interact with the system by invok- ing one of the application programs that have been written previously. For example, a bank teller who needs to transfer $50 from account A to account B invokes a program called transfer. This program asks the teller for the amount of money to be transferred, the account from which the money is to be trans- ferred, and the account to which the money is to be transferred. As another example, consider a user who wishes to ﬁnd her account bal- ance over the World Wide Web. Such a user may access a form, where she enters her account number. An application program at the Web server then retrieves the account balance, using the given account number, and passes this information back to the user. The typical user interface for naive users is a forms interface, where the user can ﬁll in appropriate ﬁelds of the form. Naive users may also simply read reports generated from the database. Application programmers are computer professionals who write application programs. Application programmers can choose from many tools to develop user interfaces. Rapid application development (RAD) tools are tools that en- able an application programmer to construct forms and reports without writ- ing a program. There are also special types of programming languages that combine imperative control structures (for example, for loops, while loops and if-then-else statements) with statements of the data manipulation lan- guage. These languages, sometimes called fourth-generation languages, often include special features to facilitate the generation of forms and the display of data on the screen. Most major commercial database systems include a fourth- generation language. Sophisticated users interact with the system without writing programs. In- stead, they form their requests in a database query language. They submit each such query to a query processor, whose function is to break down DML statements into instructions that the storage manager understands. Analysts who submit queries to explore data in the database fall in this category. Online analytical processing (OLAP) tools simplify analysts’ tasks by let- ting them view summaries of data in different ways. For instance, an analyst can see total sales by region (for example, North, South, East, and West), or by product, or by a combination of region and product (that is, total sales of each product in each region). The tools also permit the analyst to select speciﬁc re- gions, look at data in more detail (for example, sales by city within a region) or look at the data in less detail (for example, aggregate products together by category). Another class of tools for analysts is data mining tools, which help them ﬁnd certain kinds of patterns in data. We study OLAP tools and data mining in Chapter 22. Specialized users are sophisticated users who write specialized database applications that do not ﬁt into the traditional dat

Database System Concepts, Fourth Edition (PDF)

Document Details

Tags

Related

Summary

Full Transcript

Upgrade to continue