Download the full version of the textbook now at textbookfull.

com

Database Design and Implementation 2nd

Edition --

https://textbookfull.com/product/database-design-
and-implementation-2nd-edition/

Explore and download more textbook at https://textbookfull.com

 Recommended digital products (PDF, EPUB, MOBI) that
you can download immediately if you are interested.

Database Systems: Design, Implementation, and Management

13th Edition Carlos Coronel

https://textbookfull.com/product/database-systems-design-
implementation-and-management-13th-edition-carlos-coronel/

textbookfull.com

Database Systems Design Implementation Management 12th

Edition Carlos Coronel

https://textbookfull.com/product/database-systems-design-
implementation-management-12th-edition-carlos-coronel/

textbookfull.com

Pro SQL Server Relational Database Design and

Implementation 5th Edition Louis Davidson

https://textbookfull.com/product/pro-sql-server-relational-database-
design-and-implementation-5th-edition-louis-davidson/

textbookfull.com

Commonwealth History in the Twenty-First Century Saul

Dubow

https://textbookfull.com/product/commonwealth-history-in-the-twenty-
first-century-saul-dubow/

textbookfull.com
Semi-Presidential Policy-Making in Europe: Executive
Coordination and Political Leadership Tapio Raunio

https://textbookfull.com/product/semi-presidential-policy-making-in-
europe-executive-coordination-and-political-leadership-tapio-raunio/

textbookfull.com

Topological Aspects of Condensed Matter Physics 1st

Edition Claudio Chamon

https://textbookfull.com/product/topological-aspects-of-condensed-
matter-physics-1st-edition-claudio-chamon/

textbookfull.com

German Political Thought and the Discourse of Platonism:

Finding the Way Out of the Cave Paul Bishop

https://textbookfull.com/product/german-political-thought-and-the-
discourse-of-platonism-finding-the-way-out-of-the-cave-paul-bishop/

textbookfull.com

The Rough Guide to Sweden 7th Edition Rough Guides

https://textbookfull.com/product/the-rough-guide-to-sweden-7th-
edition-rough-guides/

textbookfull.com

Where Is Area 51 Paula K. Manzanero

https://textbookfull.com/product/where-is-area-51-paula-k-manzanero/

textbookfull.com
Functional Analysis of the Human Genome First Edition
Cooper

https://textbookfull.com/product/functional-analysis-of-the-human-
genome-first-edition-cooper/

textbookfull.com
Data-Centric Systems and Applications

Edward Sciore

Database
Design and
Implementation
Second Edition
Data-Centric Systems and Applications

Series editors
Michael J. Carey
Stefano Ceri

Editorial Board Members

Anastasia Ailamaki
Shivnath Babu
Philip A. Bernstein
Johann-Christoph Freytag
Alon Halevy
Jiawei Han
Donald Kossmann
Gerhard Weikum
Kyu-Young Whang
Jeffrey Xu Yu
Edward Sciore
Boston College
Chestnut Hill, MA, USA

ISSN 2197-9723 ISSN 2197-974X (electronic)

Data-Centric Systems and Applications
ISBN 978-3-030-33835-0 ISBN 978-3-030-33836-7 (eBook)
https://doi.org/10.1007/978-3-030-33836-7

The first edition of this book was published by John Wiley & Sons, Inc.

© Springer Nature Switzerland AG 2020

This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the
material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation,
broadcasting, reproduction on microfilms or in any other physical way, and transmission or information
storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology
now known or hereafter developed.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication
does not imply, even in the absence of a specific statement, that such names are exempt from the relevant
protective laws and regulations and therefore free for general use.
The publisher, the authors, and the editors are safe to assume that the advice and information in this
book are believed to be true and accurate at the date of publication. Neither the publisher nor the authors or
the editors give a warranty, expressed or implied, with respect to the material contained herein or for any
errors or omissions that may have been made. The publisher remains neutral with regard to jurisdictional
claims in published maps and institutional affiliations.

This Springer imprint is published by the registered company Springer Nature Switzerland AG.
The registered company address is: Gewerbestrasse 11, 6330 Cham, Switzerland
Preface

A database system is a common, visible tool in the corporate world—employees

frequently interact directly with database systems to submit data or create reports.
Database systems are also common, but invisible, as components of software
systems. For example, consider an e-commerce website that uses a server-side
database to hold customer, product, and sales information. Or consider a GPS
navigation system that uses an embedded database to manage the road maps. In
both of these examples, the presence of the database system is hidden from the user;
the application code performs all of the database interaction.
From the point of view of a software developer, learning to use a database directly
is rather mundane, because modern database systems contain sophisticated front
ends that make the creation of queries and reports straightforward. On the other
hand, the possibility of incorporating database functionality into a software applica-
tion is exciting, because it opens up a wealth of new and unexplored opportunities.
But what does “incorporating database functionality” mean? A database system
provides many things, such as persistence, transactional support, and query
processing. Which of these features are needed, and how should they be integrated
into the software? Suppose, for example, that a programmer is asked to modify an
existing application, say to add the ability to save state, or to increase reliability, or to
improve the efficiency of file access. The programmer is faced with several archi-
tectural options. She could:
• Purchase a full-featured general-purpose database system and then modify the
application to connect to the database as a client
• Obtain a more specialized system that contains only the desired features and
whose code can be embedded directly into the application
• Write the necessary functionality herself
In order to make the proper choice, the programmer needs to understand what
each of these options entail. She needs to know not only what database systems do
but also how they do it and why.

v
vi Preface

This text examines database systems from the point of view of the software
developer. This perspective allows us to investigate why database systems are the
way they are. It is, of course, important to be able to write queries, but it is equally
important to know how they are processed. We don’t want to just use JDBC, we
want to know why the API contains the classes and methods that it does. We need a
sense of how hard is it to write a disk cache or logging facility. And what exactly is a
database driver, anyway?

Organization of the Text

The first two chapters provide a quick overview of database systems and their use.
Chapter 1 discusses the purpose and features of a database system and introduces
you to the Derby and SimpleDB systems. Chapter 2 explains how to write a database
application using Java. It presents the basics of JDBC, which is the fundamental API
for Java programs that interact with a database.
Chapters 3–11 examine the internals of a typical database engine. Each of its
chapters covers a different database component, starting with the lowest level of
abstraction (the disk and file manager) and ending with the highest (the JDBC client
interface). The chapter for each component explains the issues and considers possi-
ble design decisions. As a result, you can see exactly what services each component
provides and how it interacts with the other components in the system. By the end of
this part, you will have witnessed the gradual development of a simple but
completely functional system.
The remaining four chapters focus on efficient query processing. They examine
the sophisticated techniques and algorithms that can replace the simple design
choices described earlier. Topics include indexing, sorting, intelligent buffer
usage, and query optimization.

Text Prerequisites

This text is intended for upper-level undergraduate or beginning graduate courses in

computer science. It assumes that the reader is comfortable with basic Java pro-
gramming; for example, it uses the classes in java.util extensively, particularly
collections and maps. Advanced Java concepts (such as RMI and JDBC) are fully
explained in the text.
The material in this book is typically studied as a second course in database
systems. However, I have had success teaching it to students with no database
experience. To that end, this book assumes no prior database knowledge other
than a passing acquaintance with SQL. And students without such knowledge of
SQL will find it easy to pick up what they need.
Preface vii

The SimpleDB Software

In my experience, it is much easier for students to grasp conceptual ideas (such as

concurrency control, buffer management, and query optimization algorithms) than to
grasp how these ideas interact. Ideally, a student should write an entire database
system as part of his coursework, just as the student would write an entire compiler
in a compiler course. However, a database system is much more complex than a
compiler, so that approach is not practical. My solution was to write a simple but
fully functional database system, called SimpleDB. Students can apply their concep-
tual knowledge by examining SimpleDB code and modifying it.
SimpleDB “looks” like a commercial database system, both in its function and
structure. Functionally, it is a multiuser, transaction-oriented database server that
executes SQL statements and interacts with clients via JDBC. Structurally, it con-
tains the same basic components as a commercial system, with similar APIs. Each
component of SimpleDB has a corresponding chapter in the text, which discusses the
component’s code and the design decisions behind it.
SimpleDB is a useful educational tool because its code is small, easily readable,
and easily modifiable. It omits all unnecessary functionality, implements only a tiny
portion of SQL, and uses only the simplest (and often very impractical) algorithms.
There consequently are numerous opportunities for students to extend the system
with additional features and more efficient algorithms; many of these extensions
appear as end-of-chapter exercises.
SimpleDB can be downloaded from the http://cs.bc.edu/~sciore/simpledb.
Details on installing and using SimpleDB appear on that web page and in Chap. 1.
I welcome suggestions for improving the code, as well as reports of any bugs. You
can email me at [email protected].

End-of-Chapter Readings

This text is motivated by two questions: What functionality do database systems

provide? What algorithms and design decisions will best implement this function-
ality? Entire shelves can be filled with books that address different aspects of these
questions. Since there is no way that a single text could hope to be comprehensive, I
have chosen to present only those algorithms and techniques that most clearly
illustrate the issues involved. My overriding goal is to teach the principles behind
a technique, even if it means omitting (or reducing) discussion of the most commer-
cially viable version of it. Instead, the end of each chapter contains a “suggested
readings” section. Those sections discuss interesting ideas and research directions
that went unmentioned in the text and provide references to relevant web pages,
research articles, reference manuals, and books.
viii Preface

End-of-Chapter Exercises

The end of each chapter contains numerous exercises. Some exercises are of the
pencil-and-paper variety, designed to reinforce concepts taught in the chapter. Other
exercises suggest interesting modifications to SimpleDB, and many of them make
excellent programming projects. I have written solutions to most of the exercises. If
you are the instructor of a course using this textbook and would like a copy of the
solution manual, please email me at [email protected].
Contents

1 Database Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Why a Database System? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 The Derby Database System . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Database Engines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 The SimpleDB Database System . . . . . . . . . . . . . . . . . . . . . . 10
1.5 The SimpleDB Version of SQL . . . . . . . . . . . . . . . . . . . . . . . 11
1.6 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.7 Suggested Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.8 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2 JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1 Basic JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Advanced JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3 Computing in Java vs. SQL . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.4 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.5 Suggested Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.6 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3 Disk and File Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.1 Persistent Data Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.2 The Block-Level Interface to the Disk . . . . . . . . . . . . . . . . . . 60
3.3 The File-Level Interface to the Disk . . . . . . . . . . . . . . . . . . . . 61
3.4 The Database System and the OS . . . . . . . . . . . . . . . . . . . . . . 65
3.5 The SimpleDB File Manager . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.6 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.7 Suggested Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.8 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4 Memory Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.1 Two Principles of Database Memory Management . . . . . . . . . 79
4.2 Managing Log Information . . . . . . . . . . . . . . . . . . . . . . . . . . 81

ix
x Contents

4.3 The SimpleDB Log Manager . . . . . . . . . . . . . . . . . . . . . . . . . 83

4.4 Managing User Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.5 The SimpleDB Buffer Manager . . . . . . . . . . . . . . . . . . . . . . . 93
4.6 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.7 Suggested Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
4.8 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5 Transaction Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.1 Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.2 Using Transactions in SimpleDB . . . . . . . . . . . . . . . . . . . . . . 108
5.3 Recovery Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
5.4 Concurrency Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
5.5 Implementing SimpleDB Transactions . . . . . . . . . . . . . . . . . . 145
5.6 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
5.7 Suggested Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
5.8 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
6 Record Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
6.1 Designing a Record Manager . . . . . . . . . . . . . . . . . . . . . . . . . 159
6.2 Implementing a File of Records . . . . . . . . . . . . . . . . . . . . . . . 165
6.3 SimpleDB Record Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
6.4 SimpleDB Table Scans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
6.5 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
6.6 Suggested Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
6.7 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
7 Metadata Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
7.1 The Metadata Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
7.2 Table Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
7.3 View Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
7.4 Statistical Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
7.5 Index Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
7.6 Implementing the Metadata Manager . . . . . . . . . . . . . . . . . . . 205
7.7 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
7.8 Suggested Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
7.9 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
8 Query Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
8.1 Relational Algebra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
8.2 Scans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
8.3 Update Scans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
8.4 Implementing Scans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
8.5 Pipelined Query Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 226
8.6 Predicates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
8.7 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
8.8 Suggested Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
8.9 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Contents xi

9 Parsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
9.1 Syntax Versus Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
9.2 Lexical Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
9.3 The SimpleDB Lexical Analyzer . . . . . . . . . . . . . . . . . . . . . . 241
9.4 Grammars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
9.5 Recursive-Descent Parsers . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
9.6 Adding Actions to the Parser . . . . . . . . . . . . . . . . . . . . . . . . . 250
9.7 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
9.8 Suggested Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
9.9 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
10 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
10.1 Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
10.2 The Cost of Evaluating a Query Tree . . . . . . . . . . . . . . . . . . . 268
10.3 Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
10.4 Query Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
10.5 Update Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
10.6 The SimpleDB Planner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
10.7 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
10.8 Suggested Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
10.9 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
11 JDBC Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
11.1 The SimpleDB API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
11.2 Embedded JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
11.3 Remote Method Invocation . . . . . . . . . . . . . . . . . . . . . . . . . . 300
11.4 Implementing the Remote Interfaces . . . . . . . . . . . . . . . . . . . . 305
11.5 Implementing the JDBC Interfaces . . . . . . . . . . . . . . . . . . . . . 306
11.6 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
11.7 Suggested Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
11.8 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
12 Indexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
12.1 The Value of Indexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
12.2 SimpleDB Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
12.3 Static Hash Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
12.4 Extendable Hash Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
12.5 B-Tree Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
12.6 Index-Aware Operator Implementations . . . . . . . . . . . . . . . . . 345
12.7 Index Update Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
12.8 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
12.9 Suggested Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
12.10 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
13 Materialization and Sorting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
13.1 The Value of Materialization . . . . . . . . . . . . . . . . . . . . . . . . . 363
13.2 Temporary Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Visit https://textbookfull.com
now to explore a rich
collection of eBooks, textbook
and enjoy exciting offers!
xii Contents

13.3 Materialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364

13.4 Sorting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
13.5 Grouping and Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
13.6 Merge Joins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
13.7 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
13.8 Suggested Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
13.9 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
14 Effective Buffer Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
14.1 Buffer Usage in Query Plans . . . . . . . . . . . . . . . . . . . . . . . . . 397
14.2 Multibuffer Sorting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
14.3 Multibuffer Product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
14.4 Determining Buffer Allocation . . . . . . . . . . . . . . . . . . . . . . . . 402
14.5 Implementing Multibuffer Sorting . . . . . . . . . . . . . . . . . . . . . 403
14.6 Implementing Multibuffer Product . . . . . . . . . . . . . . . . . . . . . 404
14.7 Hash Joins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
14.8 Comparing the Join Algorithms . . . . . . . . . . . . . . . . . . . . . . . 412
14.9 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
14.10 Suggested Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
14.11 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
15 Query Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
15.1 Equivalent Query Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
15.2 The Need for Query Optimization . . . . . . . . . . . . . . . . . . . . . 426
15.3 The Structure of a Query Optimizer . . . . . . . . . . . . . . . . . . . . 430
15.4 Finding the Most Promising Query Tree . . . . . . . . . . . . . . . . . 430
15.5 Finding the Most Efficient Plan . . . . . . . . . . . . . . . . . . . . . . . 440
15.6 Combining the Two Stages of Optimization . . . . . . . . . . . . . . 441
15.7 Merging Query Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
15.8 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
15.9 Suggested Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
15.10 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
About the Author

Edward Sciore is a recently retired associate professor in the Computer Science

Department at Boston College. He is the author of numerous research articles about
database systems, which span both theory and practice. His favorite activity, how-
ever, is to teach database courses to captive students. These teaching experiences,
accumulated over a 35-year period, are what led to the writing of this text.

xiii
Chapter 1
Database Systems

Database systems play an important role in the computer industry. Some database
systems (such as Oracle) are enormously complex and typically run on large, high-
end machines. Others (such as SQLite) are small, streamlined, and intended for the
storage of application-specific data. Despite their wide range of uses, all database
systems have similar features. This chapter examines the issues that a database
system must address and the capabilities it is expected to have. It also introduces
the Derby and SimpleDB database systems, which will be discussed in this book.

1.1 Why a Database System?

A database is a collection of data stored on a computer. The data in a database is

typically organized into records, such as employee records, medical records, sales
records, etc. Figure 1.1 depicts a database that holds information about students in a
university and the courses they have taken. This database will be used as a running
example throughout the book. The database of Fig. 1.1 contains five types of
records:
• There is a STUDENT record for each student that has attended the university.
Each record contains the student’s ID number, name, graduation year, and ID of
the student’s major department.
• There is a DEPT record for each department in the university. Each record
contains the department’s ID number and name.
• There is a COURSE record for each course offered by the university. Each record
contains the course’s ID number, title, and the ID of the department that offers it.
• There is a SECTION record for each section of a course that has ever been given.
Each record contains the section’s ID number, the year the section was offered,
the ID of the course, and the professor teaching that section.

© Springer Nature Switzerland AG 2020 1

E. Sciore, Database Design and Implementation, Data-Centric Systems and
Applications, https://doi.org/10.1007/978-3-030-33836-7_1
2 1 Database Systems

STUDENT SId SName GradYear MajorId DEPT DId DName

1 joe 2021 10 10 compsci
2 amy 2020 20 20 math
3 max 2022 10 30 drama
4 sue 2022 20
COURSE CId Title DeptId
5 bob 2020 30
12 db systems 10
6 kim 2020 20
22 compilers 10
7 art 2021 30
32 calculus 20
8 pat 2019 20
42 algebra 20
9 lee 2021 10
52 acting 30
ENROLL EId StudentId SectionId Grade 62 elocution 30
14 1 13 A
SECTION SectId CourseId Prof YearOffered
24 1 43 C
13 12 turing 2018
34 2 43 B+ 23 12 turing 2016
44 4 33 B 33 32 newton 2017
54 4 53 A 43 32 einstein 2018
64 6 53 A 53 62 brando 2017

Fig. 1.1 Some records for a university database

• There is an ENROLL record for each course taken by a student. Each record
contains the enrollment ID number, the ID numbers of the student and the section
of the course taken, and the grade the student received for the course.
Figure 1.1 is just a conceptual picture of some records. It does not indicate
anything about how the records are stored or how they are accessed. There are
many available software products, called database systems, which provide an
extensive set of features for managing records.
What does it mean to “manage” records? What features must a database system
have, and which features are optional? The following five requirements seem
fundamental:
• Databases must be persistent. Otherwise, the records would disappear as soon as
the computer is turned off.
• Databases can be shared. Many databases, such as our university database, are
intended to be shared by multiple concurrent users.
• Databases must be kept accurate. If users cannot trust the contents of a database,
it becomes useless and worthless.
• Databases can be very large. The database of Fig. 1.1 contains only 29 records,
which is ridiculously small. It is not unusual for a database to contain millions
(or even billions) of records.
• Databases must be usable. If users are not able to easily get at the data they want,
their productivity will suffer, and they will clamor for a different product.
1.1 Why a Database System? 3

Fig. 1.2 Implementing the STUDENT records in a text file

The following subsections examine the implications of these requirements. Each

requirement forces the database system to contain increasingly more features,
resulting in more complexity than you might have expected.

1.1.1 Record Storage

A common way to make a database persistent is to store its records in files. The
simplest and most straightforward approach is for a database system to store records
in text files, one file per record type; each record could be a line of text, with its
values separated by tabs. Figure 1.2 depicts the beginning of the text file for the
STUDENT records.
This approach has the advantage that a user could examine and modify the files
with a text editor. Unfortunately, the approach is too inefficient to be useful, for two
reasons.
The first reason is that large text files take too long to update. Suppose, for
example, that someone deletes Joe’s record from the STUDENT file. The database
system would have no choice but to rewrite the file beginning at Amy’s record,
moving each succeeding record to the left. Although the time required to rewrite a
small file is negligible, rewriting a 1 gigabyte file could easily take several minutes,
which is unacceptably long. A database system needs to be much more clever about
how it stores records, so that updates to the file require only small, local rewrites.
The second reason is that large text files take too long to read. Consider searching
the STUDENT file for the students in the class of 2019. The only way is to scan the file
sequentially. Sequential scanning can be very inefficient. You probably know several
in-memory data structures, such as trees and hash tables, which enable fast searching.
A database system needs to use analogous data structures to implement its files. For
example, a database system might organize the records in a file using a structure that
facilitates one particular type of search (e.g., on student name, graduation year or
major), or it might create multiple auxiliary files, each facilitating a different type of
search. These auxiliary files are called indexes and are the subject of Chap. 12.

1.1.2 Multi-user Access

When many users share a database, there is a good chance that they will be accessing
some of its data files concurrently. Concurrency is a good thing, because each user
can be served quickly without having to wait for the other users to finish. But too
4 1 Database Systems

much concurrency is bad, because it can cause the database to become inaccurate.
For example, consider a travel-planning database. Suppose that two users try to
reserve a seat on a flight that has 40 seats remaining. If both users concurrently read
the same flight record, they both will see the 40 available seats. They both then
modify the record so that the flight now has 39 available seats. Oops. Two seats have
been reserved, but only one reservation has been recorded in the database.
A solution to this problem is to limit concurrency. The database system should
allow the first user to read the flight record and see the 40 available seats and then
block the second user until the first user finishes. When the second user resumes, it
will see 39 available seats and modify it to 38, as it should. In general, a database
system must be able to detect when a user is about to perform an action that conflicts
with an action of another user and then (and only then) block that user from
executing until the first user has finished.
Users also may need to undo database updates they have made. For example,
suppose that a user has searched the travel-planning database for a trip to Madrid and
found a date for which there is both an available flight and a hotel with a vacancy.
Now suppose that the user reserves the flight, but while the reservation process is
occurring, all of the hotels for that date fill up. In this case, the user may need to undo
the flight reservation and try for a different date.
An update that is undoable should not be visible to the other users of the database.
Otherwise, another user may see the update, think that the data is “real,” and make a
decision based on it. The database system must therefore provide users with the
ability to specify when their changes are permanent; the user is said to commit the
changes. Once a user commits, the changes become visible and cannot be undone.
Chapter 5 examines these issues.

1.1.3 Dealing with Catastrophe

Suppose that you are running a program that gives a pay raise to all professors, when
the database system unexpectedly crashes. After the system restarts, you realize that
some of the professors have a new salary, but others don’t. What should you do?
You can’t just rerun the program because that would give some professors a double
pay raise. Instead, you need the database system to recover gracefully from the crash,
undoing the updates of all programs that were running when the crash occurred. The
mechanism for doing so is interesting and nontrivial, and is examined in Chap. 5.

1.1.4 Memory Management

Databases need to be stored in persistent memory, such as disk drives or flash drives.
Flash drives are about 100 times faster than disk drives but are also significantly
more expensive. Typical access times are about 6 ms for disk and 60 μs for flash.
However, both of these times are orders of magnitude slower than main memory
1.1 Why a Database System? 5

(or RAM), which has access times of about 60 ns. That is, RAM is about 1000 times
faster than flash and 100,000 times faster than disk.
To see the effect of this performance difference and the consequent problems
faced by a database system, consider the following analogy. Suppose you crave a
chocolate chip cookie. There are three ways to get one: from your kitchen, at the
neighborhood grocery store, or via mail order. In this analogy, your kitchen corre-
sponds to RAM, the neighborhood store corresponds to a flash drive, and the mail
order company corresponds to a disk. Suppose that it takes 5 seconds to get the
cookie from your kitchen. Getting the cookie from the analogous store would require
5000 seconds, which is over an hour. This means going to the store, waiting in a very
long line, buying the cookie, and returning. And getting the cookie from the
analogous mail order company would require 500,000 seconds, which is over
5 days. That means ordering the cookie online and having it shipped using standard
delivery. From this point of view, flash and disk memory look terribly slow.
Wait! It gets worse. Database support for concurrency and reliability slows things
down even more. If someone else is using the data you want, then you may be forced
to wait until the data is released. In our analogy, this corresponds to arriving at the
grocery store and discovering that the cookies are sold out, forcing you to wait until
they are restocked.
In other words, a database system is faced with the following conundrum: It must
manage more data than main memory systems, using slower devices, with multiple
people fighting over access to the data, and make it completely recoverable, all the
while maintaining a reasonable response time.
A large part of the solution to this conundrum is to use caching. Whenever the
database system needs to process a record, it loads it into RAM and keeps it there for
as long as possible. Main memory will thus contain the portion of the database that is
currently in use. All reading and writing occur in RAM. This strategy has the
advantage that fast main memory is used instead of slow persistent memory but
has the disadvantage that the persistent version of the database can become out of
date. The database system needs to implement techniques for keeping the persistent
version of the database synchronized with the RAM version, even in the face of a
system crash (when the contents of RAM is destroyed). Chapter 4 considers various
caching strategies.

1.1.5 Usability

A database is not very useful if its users cannot easily extract the data they want. For
example, suppose that a user wants to know the names of all students who graduated
in 2019. In the absence of a database system, the user would be forced to write a
program to scan the student file. Figure 1.3 gives the Java code for such a program,
assuming that the file is stored as text. Note that most of the Java code deals with
decoding the file, reading each record and splitting it into an array of values to be
examined. The code to determine the desired student names (in bold) is hidden
within the uninteresting file-manipulation code.
6 1 Database Systems

public static List<String> getStudents2019() {

List<String> result = new ArrayList<>();
FileReader rdr = new FileReader("students.txt");
BufferedReader br = new BufferedReader(rdr);
String line = br.readLine();
while (line != null) {
String[] vals = line.split("\t");
String gradyear = vals[2];
if (gradyear.equals("2019"))
result.add(vals[1]);
line = br.readLine();
}
return result;
}

Fig. 1.3 Retrieving the name of students graduating in 2019

Consequently, most database systems support a query language, so that users can
easily specify their desired data. The standard query language for relational data-
bases is SQL. The code of Fig. 1.3 can be expressed by the single SQL statement:

select SName from STUDENT where GradYear = 2019

This SQL statement is much shorter and clearer than the Java program, primarily
because it specifies the values to be extracted from the file without having to specify
how to retrieve them.

1.2 The Derby Database System

Learning database concepts is much more effective if you can use a database system
to follow along interactively. Although there are a wide variety of available database
systems, I suggest that you use Derby database system because it is Java-based, free,
easy to install, and easy to use. The latest version of Derby can be downloaded from
the downloads tab at the URL db.apache.org/derby. The downloaded
distribution file unpacks to a folder containing several directories. For example,
the docs directory contains reference documentation, the demo directory contains a
sample database, and so on. The full system contains many more features than can be
covered here; the interested reader can peruse the various guides and manuals in the
docs directory.
Derby has many features that are not needed in this book. In fact, you only need to
add four files from Derby’s lib directory to your classpath: derby.jar,
derbynet.jar, derbyclient.jar, and derbytools.jar. There are
many ways to change your classpath, depending on your Java platform and operat-
ing system. I will explain how to do it using the Eclipse development platform. If
you are not familiar with Eclipse, you can download its code and documentation
1.2 The Derby Database System 7

from eclipse.org. If you use a different development platform, then you should
be able to adapt my Eclipse directions to fit your environment.
First, create an Eclipse project for Derby. Then configure its build path, as
follows. From the Properties window, select “Java Build Path.” Click on the
“Libraries” tab and then “Add External JARS,” and use the file chooser to select the
four jar files you need. That’s it.
The Derby distribution contains an application, called ij, which enables you to
create and access Derby databases. Because Derby is written completely in Java, ij
is actually the name of a Java class, located in the package org.apache.derby.
tools. You run ij by executing its class. To execute the class from Eclipse, go to
“Run Configurations” in the Run menu. Add a new configuration to your Derby
project; call it “Derby ij.” In the field for the configuration’s main class, enter “org.
apache.derby.tools.ij.” When you run the configuration, ij displays a console
window that asks for input.
Input to ij is a sequence of commands. A command is a string that ends with a
semicolon. Commands can be split over several lines of text; the ij client will not
execute a command until it encounters a line ending in a semicolon. Any SQL
statement is a legal command. In addition, ij supports commands to connect and
disconnect from a database and to exit the session.
The connect command specifies the database that ij should connect to, and
the disconnect command disconnects from it. A given session can connect and
disconnect multiple times. The exit command ends the session. Figure 1.4 shows
an example ij session. The session has two parts. In the first part, the user connects
to a new database, creates a table, inserts a record into that table, and disconnects. In
the second part, the user reconnects to that database, retrieves the inserted values,
and disconnects.
The argument to the connect command is called its connection string. The
connection string has three substrings, separated by colons. The first two substrings
are “jdbc” and “derby,” indicating that you want to connect to a Derby database
using the JDBC protocol. (JDBC is the topic of Chap. 2.) The third substring

ij> connect 'jdbc:derby:ijtest;create=true';

ij> create table T(A int, B varchar(9));
0 rows inserted/updated/deleted
ij> insert into T(A,B) values(3, 'record3');
1 row inserted/updated/deleted
ij> disconnect;
ij> connect 'jdbc:derby:ijtest';
ij> select * from T;
A |B
---------------------
3 |record3

1 row selected
ij> disconnect;
ij> exit;

Fig. 1.4 An example ij session

8 1 Database Systems

identifies the database. The string “ijtest” is the name of the database; its files will be
in a folder named “ijtest”, located in the directory from which the ij program was
launched. For example, if you ran the program from Eclipse, the database folder will
be in the project directory. The string “create ¼ true” tells Derby to create a new
database; if it is omitted (as in the second connection command), then Derby expects
to find an existing database.

1.3 Database Engines

A database application such as ij is comprised of two independent parts: the user

interface (or UI), and the code to access the database. This latter code is called the
database engine. Separating the UI from the database engine is good system design,
as it simplifies the development of the application. A well-known example of this
separation occurs in the Microsoft Access database system. It has a graphical UI that
allows a user to interact with the database by clicking the mouse and filling in values,
and an engine that handles the data storage. When the UI determines that it needs
information from the database, it constructs a request and sends it to the engine. The
engine then executes the request and sends values back to the UI.
This separation also adds flexibility to the system: an application designer can use
the same user interface with different database engines or build different user
interfaces for the same database engine. Microsoft Access provides an example of
each case. A form built using the Access UI can connect to the Access engine or any
other database engine. And the cells in an Excel spreadsheet can contain formulas
that query the Access engine.
A UI accesses a database by connecting to the desired engine and then calling
methods from the engine’s API. As an example, note that the Derby ij program is
really just a UI. Its connect command establishes a connection to the specified
database engine, and each SQL command sends the SQL statement to the engine,
retrieves the results, and displays them.
Database engines typically support multiple standard APIs. When a Java program
connects to an engine, the API of choice is called JDBC. Chapter 2 discusses JDBC
in detail and shows how to write an ij-like application using JDBC.
A connection from a UI to a database engine can be embedded or server-based. In
an embedded connection, the code for the database engine runs in the same process
as the code for the UI, which gives the UI exclusive access to the engine. An
application should use an embedded connection only when the database “belongs”
to that application and is stored on the same machine as the application. Other
applications need to use server-based connections.
In a server-based connection, the code for the database engine executes inside a
dedicated server program. This server program is always running, waiting for client
connections, and need not be on the same machine as its clients. After a client
establishes a connection with the server, the client sends JDBC requests to it and
receives responses.
Visit https://textbookfull.com
now to explore a rich
collection of eBooks, textbook
and enjoy exciting offers!
1.3 Database Engines 9

A server can be connected to multiple clients simultaneously. While the server is

processing one client’s request, other clients can be sending their own requests. The
server contains a scheduler, which queues up requests waiting for service and
determines when they get executed. Each client is unaware of the other clients and
(apart from delays due to scheduling) has the pleasant illusion that the server is
dealing with it exclusively.
The ij session of Fig. 1.4 used an embedded connection. It created the database
“ijtest” on the machine that was running the session, and no server was involved. To
execute an analogous server-based ij session, two things must change: the Derby
engine must run as a server, and the connect command must be modified so that it
identifies the server.
The code for the Derby server is in the Java class NetworkServerControl,
in the package org.apache.derby.drda. To run the server from Eclipse, go to
“Run Configurations” in the Run menu. Add a new configuration to your Derby
project and call it “Derby Server.” In the field for the main class, enter “org.apache.
derby.drda.NetworkServerControl.” In the Arguments tab, enter the program argu-
ment “start -h localhost.” Each time you run the configuration, a console window
should appear indicating that the Derby server is running.
What is the purpose of the program argument “start -h localhost”? The first word
is the command “start,” which tells the class to start the server. You can stop the
server by executing the same class with the argument “shutdown” (or you can simply
terminate the process from the console window). The string “-h localhost” tells the
server to only accept requests from clients on the same machine. If you replace
“localhost” by a domain name or IP address, then the server will only accept requests
from that machine. Using the IP address “0.0.0.0” tells the server to accept requests
from anywhere.1
A connection string for a server-based connection must specify the network or IP
address of the server machine. In particular, consider the following ij connect
commands:

ij> connect 'jdbc:derby:ijtest'

ij> connect 'jdbc:derby://localhost/ijtest'
ij> connect 'jdbc:derby://cs.bc.edu/ijtest'

The first command establishes an embedded connection to the “ijtest” database.

The second command establishes a server-based connection to “ijtest” using the
server running on the machine “localhost,” that is, on the local machine. The third
command establishes a server-based connection to “ijtest” using the server running
on the machine “cs.bc.edu.”
Note how the connect string completely encapsulates the decision to use an
embedded or server-side connection. For example, consider again Fig. 1.4. You
can modify the session to use server-side connections instead of embedded ones by

1
Of course, if you allow clients to connect from anywhere, then you expose the database to hackers
and other unscrupulous users. Typically, you would either place such a server inside of a firewall,
enable Derby’s authentication mechanism, or both.
10 1 Database Systems

simply changing the connect commands. The other commands in the session are
unaffected.

1.4 The SimpleDB Database System

Derby is a sophisticated, full-featured database system. This complexity, however,

means that its source code is not readily understandable or modifiable. I wrote the
SimpleDB database system to be the opposite of Derby—its code is small, easily
readable, and easily modifiable. It omits all unnecessary functionality, implements
only a tiny portion of SQL, and uses only the simplest (and often very impractical)
algorithms. Its purpose is to give you a clear look at each component of a database
engine and how these components interact.
The latest version of SimpleDB can be downloaded from its website at the URL
cs.bc.edu/~sciore/simpledb. The downloaded file unpacks to the folder
SimpleDB_3.x; this folder contains directories simpledb, simpleclient,
and derbyclient. The simpledb folder contains code for the database engine.
Unlike Derby, this code is not packed into a jar file; instead, every file is explicit
within the folder.
To install the SimpleDB engine, you must add the simpledb folder to your
classpath. To do so using Eclipse, first, create a new project; call it “SimpleDB
Engine.” Then from the operating system, copy the subfolder of your
SimpleDB_3.x folder named “simpledb” to the src folder of the project. Finally,
refresh the project from Eclipse, using the refresh command in the File menu.
The derbyclient folder contains example programs that call the Derby
engine. Use the operating system to copy the contents of this folder (not the folder
itself) to the src folder of your Derby project, and refresh it. These client programs
will be discussed in Chap. 2.
The simpleclient folder contains example programs that call the SimpleDB
engine. You should create a new project for them; call it “SimpleDB Clients.” To
ensure that the example programs can find the SimpleDB engine code, you should
add the SimpleDB Engine project to the build path of SimpleDB Clients.
Then use the operating system to copy the contents of simpleclient into the
src directory of SimpleDB Clients.
SimpleDB supports both embedded and server-based connections. One of the
programs in the simpleclient folder is SimpleIJ, which is a simplified
version of the Derby ij program. One difference from ij is that you can only
connect once, at the beginning of the session. When you execute the program, it asks
you for a connection string. The syntax of the connection string is similar to that in
ij. For example, consider the following SimpleDB connection strings:

jdbc:simpledb:testij
jdbc:simpledb://localhost
jdbc:simpledb://cs.bc.edu
1.5 The SimpleDB Version of SQL 11

The first connection string specifies an embedded connection to the “testij”

database. Like Derby, the database will be located in the directory of the executing
program, which is the SimpleDB Clients project. Unlike Derby, SimpleDB will
create the database if it does not exist, so there is no need for an explicit
“create ¼ true” flag.
The second and third connection strings specify a server-based connection to a
SimpleDB server running on the local machine or on cs.bc.edu. Unlike Derby,
the connection string does not specify a database. The reason is that the SimpleDB
engine can handle only one database at a time, which is specified when the server is
started.
SimpleIJ repeatedly prints a prompt asking you to enter a single line of text
containing an SQL statement. Unlike Derby, the line must contain the entire
statement, and no semicolon is needed at the end. The program then executes that
statement. If the statement is a query, then the output table is displayed. If the
statement is an update command, then the number of affected records is printed. If
the statement is ill-formed, then an error message will be printed. SimpleDB
understands a very limited subset of SQL, and SimpleIJ will throw an exception
if given an SQL statement that the engine does not understand. These limitations are
described in the next section.
The SimpleDB engine can be run as a server. The main class is StartServer in the
package simpledb.server. To run the server from Eclipse, go to “Run Configura-
tions” in the Run menu. Add a new configuration to your SimpleDB Engine
project called “SimpleDB Server.” In the field for the main class, enter “simpledb.
server.StartServer.” Use the Arguments tab to enter the name of the desired database.
For convenience, the server will use the database named “studentdb” if you omit the
argument. When you run the configuration, a console window should appear indi-
cating that the SimpleDB server is running.
The SimpleDB server accepts client connections from anywhere, corresponding
to Derby’s “-h 0.0.0.0” command-line option. The only way to shut down the server
is to kill its process from the console window.

1.5 The SimpleDB Version of SQL

Derby implements nearly all of standard SQL. SimpleDB, on the other hand,
implements only a tiny subset of standard SQL and imposes restrictions not present
in the SQL standard. This section briefly indicates these restrictions. Other chapters
of the book explain them in more detail, and many end-of-chapter exercises will ask
you to implement some of the omitted features.
A query in SimpleDB consists only of select-from-where clauses in which the
select clause contains a list of field names (without the AS keyword), and the
from clause contains a list of table names (without range variables).
The terms in the optional where clause can be connected only by the boolean
operator and. Terms can only compare constants and fieldnames for equality.
12 1 Database Systems

Unlike standard SQL, there are no other comparison operators, no other boolean
operators, no arithmetic operators or built-in functions, and no parentheses. Conse-
quently, nested queries, aggregation, and computed values are not supported.
Because there are no range variables and no renaming, all field names in a query
must be disjoint. And because there are no group by or order by clauses,
grouping and sorting are not supported. Other restrictions are:
• The “” abbreviation in the select clause is not supported.
• There are no null values.
• There are no explicit joins or outer joins in the from clause.
• The union keyword is not supported.
• An insert statement takes explicit values only. That is, an insertion cannot be
specified by a query.
• An update statement can have only one assignment in the set clause.

1.6 Chapter Summary

• A database is a collection of data stored on a computer. The data in a database is

typically organized into records. A database system is software that manages the
records in a database.
• A database system must be able to handle large shared databases, storing its data
on slow persistent memory. It must provide a high-level interface to its data and
ensure data accuracy in the face of conflicting user updates and system crashes.
Database systems meet these requirements by having the following features:
– The ability to store records in a file, using a format that can be accessed more
efficiently than the file system typically allows
– Complex algorithms for indexing data in files, to support fast access
– The ability to handle concurrent accesses from multiple users over a network,
blocking users when necessary
– Support for committing and rolling back changes
– The ability to cache database records in main memory and to manage the
synchronization between the persistent and main-memory versions of the
database, restoring the database to a reasonable state if the system crashes
– A language compiler/interpreter, for translating user queries on tables to
executable code on files
– Query optimization strategies, for transforming inefficient queries into more
efficient ones
• The database engine is the component of the database system that maintains the
data. A database application is responsible for user input and output; it calls the
database engine to obtain the data it needs.
• A connection to the database engine can be either embedded or server-based. A
program having an embedded connection has exclusive access to the database
1.8 Exercises 13

engine. A program having a server-based connection shares the engine with other
concurrent programs.
• Two Java-based database systems are Derby and SimpleDB. Derby implements
the full SQL standard, whereas SimpleDB implements only a limited subset of
SQL. SimpleDB is useful because its code is easy to understand. The rest of this
book starting in Chap. 3 will examine this code in detail.

1.7 Suggested Reading

Database systems have undergone dramatic changes over the years. A good account
of these changes can be found in Chap. 6 of National Research Council (1999) and in
Haigh (2006). The Wikipedia entry at en.wikipedia.org/wiki/Data
base_management_system#History is also interesting.
The client-server paradigm is useful in numerous areas of computing, not just
databases. A general overview of the field can be found in Orfali et al. (1999).
Documentation on the various features and configuration options of the Derby server
can be found at the URL db.apache.org/derby/manuals/index.html.
Haigh, T. (2006). “A veritable bucket of facts”. Origins of the data base management
system. ACM SIGMOD Record, 35(2), 33–49.
National Research Council Committee on Innovations in Computing and Commu-
nications. (1999). Funding a revolution. National Academy Press. Available from
www.nap.edu/read/6323/chapter/8#159
Orfali, R., Harkey, D., & Edwards, J. (1999). Client/server survival guide (3rd ed.).
Wiley.

1.8 Exercises

Conceptual Exercises
1.1. Suppose that an organization needs to manage a relatively small number of
shared records (say, 100 or so).
(a) Would it make sense to use a commercial database system to manage these
records?
(b) What features of a database system would not be required?
(c) Would it be reasonable to use a spreadsheet to store these records? What are
the potential problems?
1.2. Suppose you want to store a large amount of personal data in a database. What
features of a database system wouldn’t you need?
1.3. Consider some data that you typically manage without a database system (such
as a shopping list, address book, checking account info, etc.).
Random documents with unrelated
content Scribd suggests to you:
Or look at the painting of another vault on the opposite page. This is
more stiff than the former, because it was executed nearly a century
later; still, there is nothing to declare its Christian character until the
eye rests on the Good Shepherd, who appears below the principal
part of the decoration.

Painting on Vault of an Arcosolium in Cemetery of Prætextatus.

We are not saying that the artists who executed these paintings
had no Christian meaning in them; on the contrary, we believe that
they had, and that the paintings really suggested that meaning to
those who first saw them. For we know, on the authority of Tertullian,
that “the whole revolving order of the seasons” (which are
represented in the second painting) was considered by Christians to
be “a witness of the resurrection of the dead.” This, therefore, was
probably the reason why they were painted here; and no Christian
needs to be reminded that our Lord spoke of Himself under the
image of a vine, which sufficiently explains the first painting. Still the
fact remains that the representations themselves are such as might
have been used by Christian and by Pagan artists indifferently. If any
of our readers feel disappointed that the first essays of the Christian
painter should not have had a more distinctly Christian character,
they must remember that a new art cannot be created in a moment.
If the Christian religion in its infancy was to make use of art at all, it
had no choice but to appropriate to its own purposes the forms of
ancient art, so far as they were pure and innocent; by degrees it
would proceed to eliminate what was unmeaning, and substitute
something Christian.
Some writers have supposed that Christians used at first Pagan
subjects as well as Pagan forms of ornamentation; and they point to
the figure of Orpheus, which appears in three or four places of the
Catacombs, and to that of Psyche also, which may be seen about as
often. So insignificant a number of exceptions, however, would
scarcely suffice to establish the general proposition, even if they
were in themselves inexplicable. But, in truth, the figure of Orpheus
has no right to be considered an exception at all, for he was taken by
some of the early Fathers as a type of our Lord; and it was even
believed by some of them, that, like the sybil, he had prophesied
about Him. Clement of Alexandria calls our Lord the Divine
enchanter of souls, with evident reference to the tale of Orpheus;
and the same idea will have occurred to every classical scholar, as
often as he has heard those words of the Psalmist which speak of
the wicked as “refusing to hear the voice of the charmer, charm he
never so wisely.” When, then, we find Orpheus and his lyre, and the
beasts enchanted by his song, figured on the walls or roofs of the
Catacombs, we have a right to conclude that the artist intended a
Christian interpretation to be given to his work; and a similar
explanation may be given of any other subjects of heathen
mythology which have gained admittance there.
If we were asked to name the subject which seems to have been
used most frequently in the early decorations of the Catacombs, we
should give the palm to the Good Shepherd; nor is this preference to
be wondered at. Any one who has meditated upon the words in
which our Blessed Lord took this title to Himself, will easily
understand why the first Christians, living in the midst of heathen
persecutors, should have delighted to keep so touching an image
always before them. They scratched it, therefore, roughly on the
tombstone as they laid some dear one in the grave; they carved it on
their cups, especially on the sacred chalice; they engraved it on
signet rings and wore it on their fingers; they placed it in the centre of
the paintings with which they covered the ceiling of their
subterranean chapels, or they gave it the chief place immediately
over the altar. We meet with it everywhere, and everybody can
recognise it.
There are, however, one or two peculiarities in its mode of
treatment which require a word of explanation. The shepherd is
generally represented as a young man lightly clad, with his tunic girt
high about his loins, denoting thereby his unwearied activity; he is
surrounded by sheep, or he carries one on his shoulders, bearing it
home to the fold,—the most tender act of his office. And there is
nothing in this but what we might naturally have expected. But he is
also sometimes represented with a goat instead of a sheep upon his
shoulders; and, in later paintings, he has the pastoral reed or tuneful
pipe either hanging on the tree by his side or he is playing on it. Now
this last particular has no place in the gospel parable, and the former
seems directly opposed to it, since the goat is the accepted symbol
of the wicked, the sheep only of the good. Hence these points have
been taken up by some critics, either as tokens of thoughtless
carelessness on the part of the Christian artists, or as proofs that
their work, whether consciously or unconsciously, was merely copied
from some Pagan original. Neither of these remarks appears to be
just. The images of a shepherd in Pagan art, with scarcely a single
exception, are of a very different kind; and the particular details
objected to are not only capable of receiving a Christian
interpretation, they even express consoling Christian truths. St.
Gregory Nazianzen speaks of the anxious care of the shepherd as
he sits on the hillside, filling the air with the soft notes of his pipe,
calling together his scattered flock; and he observes that in like
manner the spiritual pastor, desirous to recall souls to God, should
follow the example of his Divine Master, and use his pipe more
frequently than his staff. Then, as to the substitution of the goat for
the sheep, it was probably intended as a distinct protest against the
un-Christian severity of those heretics, who in very early times
refused reconciliation to certain classes of penitent sinners.
Not many, however, of the most ancient Christian paintings are of
the same simple and obvious character as the Good Shepherd. The
leading feature which characterises most of them is this, that they
suggest religious ideas or doctrines under the guise of artistic
symbols or historic types. One doctrine specially prominent in them,
and most appropriately taught in cemeteries, is that of the
resurrection and the everlasting life of happiness which awaits the
souls of the just after death. It is in this sense that we must
understand not only the frequent repetitions of the stories of Jonas
and of Lazarus—the type and the example of a resurrection—but
also of Daniel in the lions’ den, and the three children in the fiery
furnace. These last, indeed, very probably had reference also to the
persecution which the Christians were then suffering, and were
intended to inspire courage and a confident expectation that God
would deliver them, even as He had delivered His chosen servants
of old; but, as they are spoken of in very ancient Christian
documents (e.g., in the hymns of St. Ephrem and in the Apostolic
Constitutions) as foreshadowing the future triumph of the body over
death, whence these too had been in a manner delivered, we prefer,
in obedience to these ancient guides, to assign this interpretation to
them; at any rate, it is certain that this interpretation cannot be
excluded. Figures also of the deceased, with arms outstretched in
prayer, sometimes accompanied by their names, or standing in the
midst of a garden, or, again, figures of birds pecking at fruits and
flowers, we understand as images of the soul still living after death,
received into the garden of Paradise, and fed by immortal fruits.
Sometimes there may be a difference of opinion perhaps as to the
correctness of this or that interpretation suggested for any particular
symbolical painting; but the soundness of the principle of
interpretation in itself cannot be called in question, nor will there
often be any serious difficulty in its application, among those who
study the subject with diligence and candour. The language, both of
Holy Scripture and of the earliest Fathers, abounds in symbols, and
it was only natural that the earliest specimens of Christian art should
exhibit the same characteristic. More was meant by them than that
which met at first the outward senses; without this clue to their
meaning, the paintings are scarcely intelligible,—with it, all is plain
and easy.

Tombstone from the very ancient Crypt of St. Lucina, now united with the
Catacomb of St. Callixtus.

Take, for example, the figure of an anchor, so repeatedly

represented on gravestones and other monuments of the
Catacombs; so rarely, if indeed ever, to be found on Pagan
monuments. What influenced the early Christians in the selection of
such a figure? what meaning did they attach to it? This enquiry
forces itself upon our minds, if we are intelligent students of Christian
archæology, anxious to understand what we see: and if we are also
prudent and on our guard against being led astray by mere fancy, we
shall conduct the enquiry by the same laws and principles as we
should apply to the interpretation of some perplexing riddle in
heathen art. We should first examine the literature of the age and
people to whom it was supposed to belong, and see if any light could
be thrown upon it from that source. In the present instance,
therefore, we turn to the sacred literature of the Christians, and we
find there a passage which speaks of the duty of “holding fast the
hope that is set before us, which hope we have as an anchor of the
soul, sure and firm.” We assume, then, provisionally, as a basis of
further enquiry, that an anchor may perhaps have been used as an
emblem of Christian hope. Continuing our search in the same sacred
books, we find that there was a special connection in the Christian
creed between hope and the condition of the dead. It is written that
Christians are not sorrowful about those who die, “as others who
have no hope.” The conclusion is obvious, that a reference to hope
is just one of those things which might not unreasonably be looked
for on a Christian’s grave-stone, since it was something on which
they prided themselves as a point of difference between themselves
and others. This greatly confirms our conjectural interpretation of the
symbol, and we proceed with some confidence to apply it to every
example of its use that we can meet with; for if it is the right key, it
cannot fail to unlock all the problems that will come before us. In
doing this, we are first struck by the fact that in several instances the
very names of the deceased persons on whose epitaphs the anchor
is engraved, themselves also meant the same thing. They were
called Spes, Elpis, Elpidius, Elpizusa; all names coming from the
Latin or Greek word for hope. Next, we observe that many of these
anchors are so fashioned as to contain a hidden yet unmistakable
representation of a cross; and, reflecting that the one only ground of
a Christian’s hope is the cross of Christ, we hail this also as lending
further support to our theory. Yet once more, we find many of the
epitaphs contain the same idea, expressed in distinct words written
in the ordinary alphabet and not in these hieroglyphics, so to call
them,—we find Spes in Deo, Spes in Deo Christo &c. Finally, we
often find the anchor united with one or more of several other
symbols, to which, by a similar but independent process, we can
assign a certain signification. We try, then, whether our rendering of
the anchor as equivalent to “hope” will make sense, as a schoolboy
would say who was trying to translate a piece of Greek or Latin into
English, in all these other places; and if it does, we are satisfied that
our interpretation can be no longer disputed. A false reading of a
single symbol might chance to fit one monument, or two, or three;
but to say that any false reading will fit hundreds of separate
monuments, fit all equally well, and succeed in extracting a
consistent meaning from each, is to assert what no sane man can
believe.
Those who know the way in which the interpretation of the
Egyptian hieroglyphics was first guessed at, and then triumphantly
established against all gainsayers, by a similar process of reasoning,
will not dispute the soundness of the argument by which the
meaning of the anchor has been arrived at. We cannot attempt to
vindicate our interpretation of all the other symbols used by Christian
artists with the same minuteness of detail, neither is it necessary. All
will accept the dove as a fitting symbol of the simplicity, the
gentleness, purity, and innocence of a Christian soul gone to its rest,
and a sheep as fitly representing a disciple of Christ.
Another emblem, the fish, requires more words of explanation,
because it is capable of receiving a double meaning. At first sight,
our thoughts at once recur to the words of our Blessed Lord to St.
Peter and his brother, “Follow me, and I will make you fishers of
men,” and no doubt this will sufficiently explain many old Christian
paintings or sculptures in which the fish appears. Taking this idea for
our guide, we can understand why a man angling and catching a fish
should find a place on the walls of a church, whether above ground
or below. Such a representation in these sacred places was inspired
by the same doctrinal teaching, and suggested the same ideas, as
were present to the old Christian preachers when they spoke of men
being caught by the bait of charity and the hook of preaching, and
being drawn out of the bitter waters of this world, not to have their life
taken from them, which is the fate that awaits the natural fish when it
is caught, but that they may be made partakers of a new and
heavenly life. This, however, will not enable us to decypher other
symbolical paintings into which the fish enters, and which are found
with equal frequency among the decorations of the Christian
cemeteries. It is necessary that we should learn another, and, as it
would seem, a still more common use of the fish. Just as the dove
might stand for the Holy Ghost, and also for a soul sanctified by the
Holy Ghost—just as the lamb or sheep might stand either for the
Lamb of God, or for those who are “the people of His pasture and
the sheep of His hand”—so the fish, too, was used not only to
represent a Christian, but also, still more frequently perhaps, Christ
Himself. To understand how this could be, we must study a little
Greek, which may be easily apprehended, however, even by those
who are not scholars, if they will fix their attention for a few moments
on the accompanying plan:—

Ι ΗϹΟΥϹ = Jesus
Χ ΡΙϹΤΟϹ = Christ
Θ ΕΟΥ = of God
Υ ΙΟϹ = Son
Ϲ ΩΤΗΡ = Saviour

The Greek for fish is here written perpendicularly, one letter above
another, ΙΧΘΥϹ; and it is seen that these five letters are the initial
letters of five words, which, together, contain a tolerably complete
account of what Christ is. He is Jesus Christ, Son of God,
Saviour. Thus, this one word, ιχθυς, or fish, read in this way, tells a
great deal about our Lord’s name and titles; it is almost a miniature
creed, or, as one of the Fathers expresses it, “it contains in one
name a whole multitude of holy names.” It would take us too long to
enquire into the origin of this device for expressing our Lord’s name
and titles in so compendious and secret a form. Clearly, whoever
may have invented it, it was very ingenious, and specially convenient
at those times and places where men dared not speak of Him freely
and openly. We cannot say when it began, but it was in universal use
throughout the Church during the first three hundred years of her life,
and then, when she was in the enjoyment of peace and liberty, it
gradually dropped, first out of sight in Christian monuments, and
then out of mind also in Christian literature. But, during the ages of
persecution, it had sunk deep into the habits of Christian thought and
language; it became, as it were, a part of the very Catechism,—
every baptized Christian seems to have been familiar with it, whether
he lived on the banks of the Tiber or of the Po, of the Loire, of the
Euphrates, or of the Nile. In all these parts of the world, writers in
books, poets in hymns, preachers in sermons, artists in painting, the
very masons themselves on gravestones, made use of it without a
word of explanation, in a way that would utterly mystify any modern
Christian community. Who would now dream of carving or painting a
fish upon a gravestone in a Christian churchyard? yet scores of
graves in the Catacombs were so marked, and some of them with
hardly a word or an emblem upon them besides. Or what meaning
could we attach to the picture of a dove or a lamb standing on a
fish’s back, if we did not understand that the fish represented Christ,
and the dove or the lamb a Christian, so that the whole symbol stood
for a Christian soul supported by Christ through the waves and
storms of life? Or again, only imagine a Christian in these days
having buried with him, or wearing round his neck during life, a little
figure of a fish cut in ivory, or crystal, or mother of pearl, or some still
more costly material? Yet a number of those who were buried in the
Catacombs did this; and some of these fish even bear an inscription,
calling upon the fish to be a Saviour!
It was necessary to give this explanation of certain symbols, and
to justify it by sufficient examples, before we proceed to study any of
the more complex paintings in the Catacombs. But now, with these
thoughts in our minds, let us enter the Cemetery of St. Callixtus, and
look on a figure represented two or three times on a wall of one of its
most ancient chambers: a fish swimming and carrying on its back a
basket of bread, and in the midst of the loaves of bread, a glass
vessel containing a red liquid. What is this but bread and wine, the
elements of the Sacrament of Love, and Jesus Christ Its reality? St.
Jerome, when speaking of a holy bishop of Toulouse who had sold
the gold and silver vessels of his church to relieve the poor, uses
these words, “What can be more rich than a man who carries the
body of Christ in a basket of wicker-work, and the blood of Christ in a
vessel of glass?” Here are undeniably the basket of wicker-work and
the vessel of glass; and who can doubt that we have the other also,
veiled under the figure of the fish?
 Consecration of the Holy Eucharist.

Let us go to another part of the same cemetery, and consider a

painting which with some variations is repeated in three or four
successive chambers, all opening out of one of the primitive
galleries. Bread and fish lie on a three-legged table, and several
baskets of bread are arranged along the floor in front of it, or a man
and woman stand by the side of the table. The woman has her arms
outstretched in the form of a cross, the ancient attitude of Christian
prayer; the man, too, is stretching forth his hands, but in another
way: he holds them forward, and especially his right hand, over the
bread and fish, in such a way as to press upon every Catholic
intelligence the idea that he is blessing or consecrating what is
before him. To modern eyes, indeed, his vestment does not look
worthy of one engaged in the highest act of Christian worship;
perhaps, at first sight, it almost strikes us as hardly decent.
Nevertheless, to the Christian archæologist, this very vestment is a
strong confirmation of the view we are taking of the real sense of the
painting. For it is the Greek pallium, or philosophers’ cloak; and we
know that at the time to which this painting belongs (the end of the
second or beginning of the third century) it was a common practice
to preach the Word of God in this particular costume. Tertullian, who
was living at the same time, wrote a treatise De Pallio, in which, in
his own peculiar style, he defended its use, and congratulated the
pallium on its promotion to be a Christian vestment. It was not until
fifty years later that St. Cyprian objected to it, both as not sufficiently
modest in itself and as vainglorious in its signification.
If there were any lingering uncertainty as to whether these figures
were really intended to have reference to the Holy Eucharist, or
whether our interpretation of them may not have been fanciful and
arbitrary, an examination of the other decorations of the same
chambers will suffice to remove it. For it will be seen that, whilst in
closest connection with them are other suitable emblems or figures
of the same Divine Sacrament, they are also uniformly preceded by
representations of the initiatory Sacrament of the Christian covenant,
without which no man can be admitted to partake of the Eucharist;
and they are followed by a figure of the Resurrection, which our Lord
Himself most emphatically connected with the eating of His flesh and
the drinking of His blood, saying, “He that eateth my flesh and
drinketh my blood, hath everlasting life, and I will raise him up at the
last day.” These three subjects, Baptism, the Holy Eucharist, and the
Resurrection occupy the three perfect sides of the chamber, the
fourth side being, of course, broken by the entrance; and, taken in
their right order, they faithfully depict the new life of a Christian; the
life of divine grace, first imparted by baptism, then fed by the Holy
Eucharist, and finally exchanged for an everlasting life of glory.

The Smitten Rock.

 Let us look at the figures of these subjects in detail, and see how
they are represented here. First, we have Moses striking the rock, a
scene which occurs over and over again in the Catacombs, and
which in these chambers commences the series of paintings we are
examining; it is to be seen on the left-hand wall as we enter. St. Paul
tells us that “the rock was Christ;” the water, then, which flowed from
it must be those streams of Divine grace whereby His disciples are
refreshed and sustained during their pilgrimage through the
wilderness of this world, and this grace is first given in the waters of
baptism. Next we have a man fishing, which has been already
explained; and (in one instance at least) this is followed by another
man performing the very act of baptism on a youth who stands
before him; the youth stands in the water, and the man is pouring
water over his head. Lastly, on the same wall, is the paralytic
carrying his bed on his shoulders—the same, doubtless, who was
miraculously cured at the pool of Bethsaida, which pool the fathers of
the Church uniformly interpret as typical of the healing waters of the
Christian sacrament.

The Sacrament of Baptism.

 Eucharistic Feast.

On the wall opposite the doorway, the central scene is a feast

wherein seven men are seated at a table, partaking of fish and
bread; and there is a history in the last chapter of St. John’s Gospel,
of which it may be taken as a literal representation. It was when our
Lord “showed Himself to His disciples at the Sea of Tiberias, and He
showed Himself, after this manner. There were together Simon Peter
and Thomas who is called Didymus, and Nathanael who was of
Cana of Galilee, and the sons of Zebedee, and two others of His
disciples”—seven in all. “And they went a-fishing, but caught nothing.
Jesus appeared to them on the shore.” Then there follows the
miraculous draught of fishes; and as soon as they came to land, they
saw “hot coals lying, and a fish laid thereon, and bread. Jesus saith
to them, Bring hither of the fishes which you have now caught. And
Jesus cometh and taketh bread and giveth them, and fish in like
manner.” Such is the letter of the gospel narrative; but this narrative
is in fact a mystical and prophetic representation of the Church
gathered together out of the waters of the world, and fed by the Holy
Eucharist. The hundred and fifty-three great fishes that were caught
represent the large numbers of the faithful that were drawn into the
Church by apostolic preaching; the fish laid on the hot coals is Jesus
Christ in His Passion, His Body “delivered for us” on Mount Calvary,
given to us also to be our food in the Blessed Sacrament whereby
“we show the death of the Lord until He come.” The faithful caught in
the net of the Church must be brought to that broiled fish (Piscis
assus, Christus passus, says St. Augustine), that crucified Lord, and
they must be incorporated with Him by partaking of the living Bread
which came down from Heaven.

Sacrifice of Isaac.

Resurrection of Lazarus.
 Such is the full meaning of the scene at the Sea of Tiberias, as
interpreted according to the unanimous consent of the Fathers; and
the adjuncts of this picture show that it was intended to be so
understood here also; for on one side is the figure of the
consecration already described; and on the other, the sacrifice of
Isaac by his father, which was surely a most lively type of the
sacrifice of Christ upon the altar; wherein blood is not really shed,
but the Lamb is only “as it were slain,” just as Isaac was not really
slain, but was received back from the dead, “for a parable.” Lastly, as
has been mentioned before, there follows on the third wall of the
same chamber the natural complement of the rest; the doctrine of
the Resurrection, as contained in the fact of the rising again of
Lazarus. Thus, this whole series of paintings, executed at the end of
the second century, or within the first twenty or thirty years of the
third, and repeated (as has been said) in several successive
chambers, was a continual homily, as it were, set before the eyes of
the faithful, in which they were reminded of the beginning, progress,
and consummation of their new and supernatural life.
We do not say that every modern Christian who looks at these
paintings will thus read their meaning at once; but we believe that all
ancient Christians did so, because it is clear from the writings of the
Apostles themselves and their successors, that nothing was more
familiar to the Christian mind of those days than the symbolical and
prophetical meaning of the facts both of the Old and of the New
Testaments. They believed the facts themselves to have taken place
just as they are recorded, but they believed also that they had a
mysterious signification, whereby the truths of the Christian faith
were insinuated or expressed, and that this was their highest and
truest meaning. “Perhaps there is no one recorded miracle of our
Lord,” says St. Gregory, “which is not therefore selected for
recording because it was the type of something to happen in the
Church;” and precisely the same was felt to be true also of the
histories of the patriarchal and Jewish dispensations. “All these
things had happened to them in figure, and they were written for our
correction, upon whom the ends of the world are come.”
 It may not be often possible to trace as clearly as we have just
done in a single instance, the logical order and dependence of the
several subjects that were selected for representation in each
chamber of the Catacombs; they may not always have been so
admirably arranged as to be in fact equivalent, as these were, to a
well-ordered dogmatic discourse. Nevertheless it is only when read
in this way, that the decoration of the Catacombs can be made
thoroughly intelligible; and it is certain that some such meaning must
have been intended from the first. The extremely limited number of
Biblical subjects selected for representation, while such an immense
variety is really contained in the Bible (and so many of those that are
neglected might have seemed equally suitable for the purpose), and
then again, the thoroughly unhistorical way in which these few
subjects are dealt with, shows clearly that the principle of selection
was theological rather than artistic. The artists were not left to
indulge their own unfettered fancy, but worked under ecclesiastical
supervision; and the Bible stories which they depicted were not
represented according to their historical verity, because they were
not intended to be a souvenir of past facts, but to symbolise and
suggest something beyond themselves. In order, therefore, to
understand them, it is necessary to bring them face to face with the
Christian doctrines which they foreshadow.
 Noe in the Ark.

Look, for example, at the numerous pictures of Noe in the ark

which appear in the Catacombs, all resembling one another, but
none resembling the reality. Instead of a vessel, three stories high,
containing eight human beings and specimens of every kind of
animal, we see only a narrow box, barely large enough to hold one
person, and that person sometimes a lady, whose name is also
inscribed upon it perhaps, being the same lady (as we learn from the
inscription) who lies buried in the adjacent tomb. If all ancient
Christian literature had perished, we should have been at a loss to
comprehend this enigma; but as soon as we know that the Fathers
of the Church speak of it as an acknowledged fact, which “nobody
doubts” (to use St. Augustine’s words), that the Church was typified
by the ark, a ray of light begins to dawn upon us; and when we call
to mind that St. Peter himself speaks of the waters of baptism as
saving men’s souls, “even as Noe and his family were saved by the
waters of the flood,” all is at once made clear. We see plainly that the
friends of the deceased have intended to signify that he had been
received into the ark of the Church and made a Christian by baptism.
And if they had added to the composition, as they often did, the
figure of a dove bringing an olive branch to the person standing in
the ark, this also enters into the same interpretation; it was
symbolical of that Divine peace which comes to the soul in this world
by faith, and which is a pledge of the peace given by everlasting
happiness in the next.

Scenes from the History of Jonas.

The frequent repetition of the story of Jonas in a Christian

cemetery needs no explanation, our Lord himself having put it
forward as a type of His own resurrection, and so a pledge of ours
also. The particular form, however, under which this story appears,
was not suggested, as Noe’s ark was, by the place which it held in
the cycle of Christian doctrine, but rather by a certain Pagan model
with which the Romans of that day were very familiar. The
mythological tale of Andromeda, and the sea-monster to which she
was exposed on the coast near Joppa (for so the story ran), was a
favourite subject for the decoration of the walls in Roman villas,
temples, and other public buildings. It may be seen in Pompeii, and,
much nearer to the Catacombs, in Rome itself—e.g., in the barracks
of one of the cohorts of the imperial police, discovered a few years
ago in Trastevere; and in both places the monster is the precise
counterpart of that which is always represented as swallowing or
casting up Jonas; a kind of dragon, with large head and ears, a long
slender neck, and a very tortuous body. Of course, in the infancy of
Christian art, it was convenient to have a model at hand to represent
an unknown monster, and, as we have said, we do not doubt that
this is the true history of its origin. Still this was not the only reason
which recommended the adoption of so grotesque a form; it offered
the further advantage of creating as strong a contrast as possible
between this “great fish,” which was a type of death, and the ordinary
fish, which, as we have seen, was the recognised symbol of the
Author of life.
Another incident in the life of Jonas, which was often painted in the
Catacombs, was his resting on the east side of the city of Nineve,
under the shade of a certain plant which God caused to grow up for
his protection, and which He again caused as suddenly to wither
away. In the days of St. Jerome and St. Augustine there was a
dispute between those learned doctors as to the precise nature of
this plant; and in the course of it St. Jerome appealed to these
paintings as bearing testimony in favour of his own rendering of the
Hebrew word. We need not enter into the merits of the dispute, but it
is important to note the fact of the appeal, as it peremptorily refutes
the ridiculous assertions of certain authors of the present day, who
would assign very recent dates to these and similar paintings in the
Catacombs. We know that St. Jerome was very fond, when a boy, of
visiting these places, and it is interesting to hear him appealing to the
paintings he had seen in them as to “ancient witnesses.” It would be
still more interesting, if we could say with certainty what were the
motives which led the ancient Christians to choose this subject for
such frequent contemplation; whether they read in it only a very
striking lesson as to the watchfulness of Divine Providence, or
whether it had a more subtle meaning, as a type of the mercy of God
which overshadows the souls of the faithful in the long sleep of death
which goes before the Sun of the Resurrection. But where no clue is
supplied by the writings of cotemporary, or nearly cotemporary
authors, we prefer to keep silence rather than to insist on any
doubtful interpretation. All that need be said is that such a painting
was certainly not out of place in a Christian Church or cemetery, any
more than the story of Adam and Eve, or any other Biblical narrative
which has reference to the doctrines or promises announced by
Christianity to the world.
We do not pretend to enumerate here all the subjects from the Old
and New Testaments that were painted in the Catacombs. We are
but naming those that were used most frequently, that seem most
interesting, or whose signification can be most precisely determined.
Those who have seen the Catacombs themselves will call to mind
others of which we have not spoken, but we think their meaning is
generally obvious so as to need no explanation. We will name one
class only of these paintings; those in which our Lord and His
Blessed Mother appear. Our readers will hardly expect to find
anything that pretends to be a portrait of either one or the other. We
have seen that the disposition in primitive Christian art was to
represent facts rather than persons, and the mystery which the facts
signified rather than the facts themselves. Christ, therefore, appears
most commonly in the typical character of the Good Shepherd, and
as such is represented in appropriate form and with suitable
accessories, or He sits in the midst of His Apostles, with a chest of
volumes at His feet, as the Great Teacher of the world. Once,
indeed, His head and bust form a medallion occupying the centre of
a roof in a chamber of the Cemetery of St. Domitilla, the same in
which appear Orpheus and his lyre. It is a work of the third century;
there is more evidence of an intention to give a definite individual
type of countenance, neither is the type altogether unlike that which
the practice of later ages has consecrated by traditional usage.
Nevertheless others of the fourth century are evidently not copies of
the same model, so that it is clear that in those early days there was
no uniform agreement upon the subject.