《經典原版書庫：數據庫系統概念（英文精編版·第6版）》內容由淺入深，既包含數據庫系統基本概念，又反映數據庫技術新進展。它被國際上許多著名大學所采用，包括斯坦福大學、耶魯大學、得克薩斯大學、康奈爾大學、伊利諾伊大學等。我國也有多所大學采用《經典原版書庫：數據庫系統概念（英文精編版·第6版）》作為本科生和研究生數據庫課程的教材和主要教學參考書，收到了良好的效果。《經典原版書庫：數據庫系統概念（英文精編版·第6版）》基于該書第6版進行改編，保留其中的基本內容，壓縮或刪除了一些高級內容，更加適合作為國內高校計算機及相關專業本科生數據庫課程教材。
數據庫系統是對數據進行存儲、管理、處理和維護的軟件系統，是現代計算環境中的一個核心成分。隨著計算機硬件、軟件技術的飛速發展和計算機系統在各行各業的廣泛應用，數據庫技術的發展尤其迅速，引人注目。有關數據庫系統的理論和技術是計算機科學技術教育中必不可少的部分。《數據庫系統概念》是一本經典的、備受贊揚的數據庫系統教科書，其內容由淺入深，既包含數據庫系統的基本概念，又反映數據庫技術新進展。本書被國際上許多著名大學采用，并多次再版。
我們先后將本書的第3版、第4版、第5版和第6版譯成中文，由機械工業出版社分別于2000年、2003年、2006年和2012年出版發行。國內許多大學采用《數據庫系統概念》作為本科生和研究生數據庫課程的教材或主要教學參考書，收到了良好的效果。
我們基于《數據庫系統概念》第5版進行了改編，保留其中的基本內容，壓縮或刪除了一些高級內容，形成了該書的本科教學版，其目的是使它更適合本科生的數據庫課程使用。該本科教學版由機械工業出版社于2008年出版發行，被國內許多高校采用作為本科生數據庫課程的教材或主要教學參考書。
現在我們又基于《數據庫系統概念》第6版進行了改編工作，希望它能夠成為一本效果更好、更實用的本科生數據庫課程的教材。
……
Abraham Silberchatz，于紐約州立大學石溪分校獲得博士學位，現為耶魯大學計算機科學SidneyJWeinberg教授，計算機科學系主任，曾任貝爾實驗室信息科學研究中心副主任。
HenryF．Korth，于普林斯頓大學獲得博士學位，現為利哈伊大學計算機科學與工程系Weiseman教授，曾任貝爾實驗室數據庫原理研究中心主任。他是ACM Fellow和IEEE Fellow，是VLDB10年貢獻獎的獲得者。
S．Sudarshan，于威斯康星大學麥迪遜分校獲得博士學位，現為印度理工學院計算機科學與工程系教授，曾為貝爾實驗室數據庫研究組技術人員。
Chapter 1 Introduction
1.1 Database-System Applications
1.2 Purpose of Data base Systems
1.3 View of Data
1.4 Database Languages
1.5 Relational Databases
1.6 Database Design
1.7 Data Storage and Querying
1.8 Transaction Management
1.9 Database Architecture
1.10 Data Mining and Information Retrieval
1.11 Specialty Databases
1.12 Database Users and Administrators
1.13 History of Database Systems
1.14 Summary
Review Terms
Practice Exercises
Exercises
Tools
Bibliographical Notes
PART ONE RELATIONAL DATABASES
Chapter 2 Introduction to the Relational Model
2.1 Structure of Relational Databases
2.2 Database Schema
2.3 Keys
2.4 Schema Diagrams
2.5 Relational Query Languages
2.6 Relational Operations
2.7 Summary
Review Terms
Practice Exercises
Exercises
Bibliographical Notes
Chapter3 Introduction to SQL
3.1 Overview of the SQL Query Language
3.2 SQL Data Definition 3.3 Basic Structure of SQL Queries
3.4 Additional Basic Operations
3.5 Set Operations
3.6 Null Values
3.7 Aggregate Functions
3.8 Nested Subqueries
3.9 Modification of the Database
3.10 Summary
Review Terms
Practice Exercises
Exercises
Tools
Bibliographical Notes
Chapter 4 Intermediate SQL
4.1 Join Expressions
4.2 Views
4.3 Transactions
4.4 Integrity Constraints
4.5 SQL Data Types and Schemas
4.6 Authorization
4.7 Summary
Review Terms
Practice Exercises
Exercises
Bibliographical Notes
Chapter 5 Advanced SQL
5.1 Accessing SQL From a Programming Language
5.2 Functions and Procedures
5.3 Triggers
5.4 Recursive Queries
5.5 Advanced Aggregation Features
5.6 OLAP
5.7 Summary
Review Terms
Practice Exercises
Exercises
Tools
Bibliographical Notes
Chapter 6 Formal Relational Query Languages
6.1 The Relational Algebra
6.2 The Tuple Relational Calculus
6.3 The Domain Relational Calculus
6.4 Summary
Review Terms
Practice Exercises
Exercises
Bibliographical Notes
PART TWO DATABASE DESIGN
Chapter 7 Database Design and the E-R Model
7.1 Overview of the Design Process
7.2 The Entity-Relationship Model
7.3 Constraints 269
7.4 Removing Redundant Attributes in Entity Sets
7.5 Entity-Relationship Diagrams
7.6 Reduction to Relational Schemas
7.7 Entity-Relationship Design Issues
7.8 Extended E-R Features
7.9 Alternative Notations for Modeling Data
7.10 0ther Aspects of Database Design
7.11 Summary
Review Terms
Practice Exercises
Exercises
Tools
Bibliographical Notes
Chapter 8 Relational Database Design
8.1 Features of Good Relational Designs
8.2 Atomic Domains and First Normal Form
8.3 Decomposition Using Functional Dependencies
8.4 Functional-Dependency Theory
8.5 Algorithms for Decomposition
8.6 Decomposition Using Multivalued Dependencies
8.7 More Normal Forms
8.8 Database-Design Process
8.9 Modeling Temporal Data
8.10 Summary
Review Terms
Practice Exercises
Exercises
Bibliographical Notes
PART THREE DATA STORAGE , QUERYING, AND TRANSACTION MANAGEMENT
PART FOUR ADVANCED TOPICS
Bibliography
Atomicity： Suppose that， just before the execution of transaction Ti， the values of accounts A and B are $1000 and $2000， respectively. Now suppose that， during the execution of transaction Ti， a failure occurs that prevents Ti from completing its execution successfully. Further， suppose that the failure happened after the write（A） operation but before the write（B） operation. In this case， the values of accounts A and B reflected in the database are $950 and $2000. The system destroyed $50 as a result of this failure. In particular， we note that the sum A + B is no longer preserved.
Thus， because of the failure， the state of the system no longer reflects a real state of the world that the database is supposed to capture. We term such a state an inconsistent state. We must ensure that such inconsistencies are not visible in a database system. Note， however， that the system must at some point be in an inconsistent state. Even if transaction Ti is executed to completion， there exists a point at which the value of account A is $950 and the value of account B is $2000， which is clearly an inconsistent state. This state， however， is eventually replaced by the consistent state where the value of account A is $950， and the value of account B is $2050.Thus， if the transaction never started or was guaranteed to complete， such an inconsistent state would not be visible except during the execution of the transaction. That is the reason for the atomicity requirement： If the atomicity property is present， all actions of the transaction are reflected in the database， or none are.
The basic idea behind ensuring atomicity is this： The database system keeps track （on disk） of the old values of any data on which a transaction performs a write. This information is written to a file called the log. If the transaction does not complete its execution， the database system restores the old values from the log to make it appear as though the transaction never executed. Ensuring atomicity is the responsibility of the database system; specifically， it is handled by a component of the database called the recovery system， which we describe in detail in Section 12.7.
Durability： Once the execution of the transaction completes successfully， and the user who initiated the transaction has been notified that the transfer of funds has taken place， it must be the case that no system failure can result in a loss of data corresponding to this transfer of funds. The durability property guarantees that， once a transaction completes successfully， all the updates that it carried out on the database persist， even if there is a system failure
after the transaction completes execution.
We assume for now that a failure of the computer system may result in loss of data in main memory， but data written to disk are never lost. We can guarantee durability by ensuring that either：
1. The updates carried out by the transaction have been written to disk before the transaction completes.
2. Information about the updates carried out by the transaction is written to disk， and such information is sufficient to enable the database to reconstruct the updates when the database system is restarted after the failure.
……
新書資訊