Experience Seamless Full Ebook Downloads for Every Genre at textbookfull.

com

Database Design and Implementation 2nd Edition --

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

OR CLICK BUTTON

DOWNLOAD NOW

Explore and download more ebook 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/

textboxfull.com

Database Systems Design Implementation Management 12th

Edition Carlos Coronel

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

textboxfull.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/

textboxfull.com

Database Principles: Fundamentals of Design,

Implementation, and Management 3rd Edition Carlos Coronel

https://textbookfull.com/product/database-principles-fundamentals-of-
design-implementation-and-management-3rd-edition-carlos-coronel/

textboxfull.com
Pro SQL Server Relational Database Design and
Implementation Sixth Edition Louis Davidson

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

textboxfull.com

Pro SQL Server Relational Database Design and

Implementation: Best Practices for Scalability and
Performance Louis Davidson
https://textbookfull.com/product/pro-sql-server-relational-database-
design-and-implementation-best-practices-for-scalability-and-
performance-louis-davidson/
textboxfull.com

A Practical Guide to Database Design 2nd Edition Rex Hogan

https://textbookfull.com/product/a-practical-guide-to-database-
design-2nd-edition-rex-hogan/

textboxfull.com

A Practical Guide to Database Design 2nd Edition Rex Hogan

https://textbookfull.com/product/a-practical-guide-to-database-
design-2nd-edition-rex-hogan-2/

textboxfull.com

Electronic Design Automation for IC Implementation Circuit

Design and Process Technology 2nd Edition Luciano Lavagno

https://textbookfull.com/product/electronic-design-automation-for-ic-
implementation-circuit-design-and-process-technology-2nd-edition-
luciano-lavagno/
textboxfull.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 sciore@bc.edu.

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 sciore@bc.edu.
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
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.
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.).
14 1 Database Systems

(a) How large would the data have to get before you would break down and
store it in a database system?
(b) What changes to how you use the data would make it worthwhile to use a
database system?
1.4. If you know how to use a version control system (such as Git or Subversion),
compare its features to those of a database system.
(a) Does a version control system have a concept of a record?
(b) How does check-in/checkout correspond to database concurrency control?
(c) How does a user perform a commit? How does a user undo uncommitted
changes?
(d) Many version control systems save updates in difference files, which are
small files that describe how to transform the previous version of the file
into the new one. If a user needs to see the current version of the file, the
system starts with the original file and applies all of the difference files to
it. How well does this implementation strategy satisfy the needs of a
database system?
Project-Based Exercises
1.5. Investigate whether your school administration or company uses a database
system. If so:
(a) What employees explicitly use the database system in their job?
(As opposed to those employees who run “canned” programs that use the
database without their knowledge.) What do they use it for?
(b) When a user needs to do something new with the data, does the user write
his own query, or does someone else do it?
1.6. Install and run the Derby and SimpleDB servers.
(a) Run the ij and SimpleIJ programs from the server machine.
(b) If you have access to a second machine, modify the demo clients and run
them remotely from that machine as well.
Chapter 2
JDBC

A database application interacts with a database engine by calling the methods of its
API. The API used by Java applications is called JDBC (for Java DataBase Con-
nectivity). The JDBC library consists of five Java packages, most of which implement
advanced features useful only in large commercial applications. This chapter is
interested in the core JDBC functionality found in the package java.sql. This
core functionality can be divided into two parts: basic JDBC, which contains the
classes and methods required for rudimentary usage, and advanced JDBC, which
contains optional features that provide added convenience and flexibility.

2.1 Basic JDBC

The basic functionality of JDBC is embodied in five interfaces: Driver, Con-

nection, Statement, ResultSet, and ResultSetMetadata. Moreover,
only a very few methods of these interfaces are essential. Figure 2.1 lists these
methods.
The example programs of this section illustrate the use of these methods. The first
example program is CreateTestDB, which illustrates how a program connects to
and disconnects from a Derby engine. Its code appears in Fig. 2.2, with the JDBC-
related code highlighted in bold. The following subsections examine this code in
detail.

2.1.1 Connecting to a Database Engine

Each database engine will have its own (and possibly proprietary) mechanism for
making connections with clients. Clients, on the other hand, want to be as server
independent as possible. That is, a client doesn’t want to know the nitty-gritty details

© Springer Nature Switzerland AG 2020 15

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

Driver
public Connection connect(String url, Properties prop)
throws SQLException;
Connection
public Statement createStatement() throws SQLException;
public void close() throws SQLException;

Statement
public ResultSet executeQuery(String qry) throws SQLException;
public int executeUpdate(String cmd) throws SQLException;
public void close() throws SQLException;

ResultSet
public boolean next() throws SQLException;
public int getInt() throws SQLException;
public String getString() throws SQLException;
public void close() throws SQLException;
public ResultSetMetaData getMetaData() throws SQLException;

ResultSetMetaData
public int getColumnCount() throws SQLException;
public String getColumnName(int column) throws SQLException;
public int getColumnType(int column) throws SQLException;
public int getColumnDisplaySize(int column) throws SQLException;

Fig. 2.1 The APIs for basic JDBC

import java.sql.Driver;
import java.sql.Connection;
import org.apache.derby.jdbc.ClientDriver;

public class CreateTestDB {

public static void main(String[] args) {
String url = "jdbc:derby://localhost/testdb;create=true";
Driver d = new ClientDriver();
try {
Connection conn = d.connect(url, null);
System.out.println("Database Created");
conn.close();
}
catch(SQLException e) {
e.printStackTrace();
}
}
}

Fig. 2.2 The JDBC code for the CreateTestDB client

2.1 Basic JDBC 17

of how to connect to an engine; it simply wants the engine to provide a class for the
client to call. Such a class is called a driver.
JDBC driver classes implement the interface Driver. Derby and SimpleDB
each have two driver classes: one for server-based connections and one for embed-
ded connections. A server-based connection to the Derby engine uses the class
ClientDriver, whereas an embedded connection uses EmbeddedDriver;
both classes are in package org.apache.derby.jdbc. A server-based connec-
tion to the SimpleDB engine uses the class NetworkDriver (in package
simpledb.jdbc.network), whereas an embedded connection uses
EmbeddedDriver (in package simpledb.jdbc.embedded).
A client connects to a database engine by calling a Driver object’s connect
method. For example, the following three lines of Fig. 2.2 make a server-based
connection to a Derby database:

String url = "jdbc:derby://localhost/testdb;create=true";

Driver d = new ClientDriver();
Connection conn = d.connect(url, null);

The connect method takes two arguments. The first argument to the method is
a URL that identifies the driver, the server (for server-based connections), and the
database. This URL is called the connection string and has the same syntax as the ij
(or SimpleIJ) server-based connection strings of Chap. 1. The connection string
in Fig. 2.2 consists of four parts:
• The substring “jdbc:derby:” describes the protocol used by the client. Here, the
protocol says that this client is a Derby client that speaks JDBC.
• The substring “//localhost” describes the machine where the server is located.
Instead of localhost, you could substitute any domain name or IP address.
• The substring “/testdb” describes the path to the database on the server. For a
Derby server, the path begins at the current directory of the user that started the
server. The end of the path (here, “testdb”) is the directory where all data files for
this database will be stored.
• The remainder of the connection string consists of property values to be sent to
the engine. Here, the substring is “;create ¼ true”, which tells the engine to create
a new database. In general, several property values can be sent to a Derby engine.
For example, if the engine requires user authentication, then values for the
properties username and password would also be specified. The connection
string for the user “einstein” might look like this:
"jdbc:derby://localhost/testdb;create=true;user=einstein;
password=emc2"

The second argument to connect is an object of type Properties. This

object provides another way to pass property values to the engine. In Fig. 2.2, the
value of this argument is null because all properties are specified in the connection
string. Alternatively, you could have put the property specification into the second
argument, as follows:
Other documents randomly have
different content
 CHAP. VI.
PROVINCE OF PARANNA.

Boundaries—Climate—Productions—Matte the most lucrative—First

Discoverers—Proceedings of the Spanish Jesuits—Guarani
Indians formed into Reduçoes, or Villages—Nature of those
Missions—Expulsion of the Jesuits—Delivery of the Missions to
other Ecclesiastics—their Decay—Mountains—Mineralogy—
Rivers and Lakes—Phytology—Zoology—Towns, Parishes, &c.—
Remaining Establishments of the Jesuitical Missions.
This province is bounded on the north by Matto Grosso, on the
west and south by the Paraguay, and on the east by the Uruguay
and the Paranna, which latter affords it the name, and divides it into
two unequal parts, northern and southern. It is altogether situated in
the temperate zone, between 24° and 33° 30′ south latitude, being
six hundred and fifty miles long from north to south, and more than
two hundred and fifty at its greatest width from east to west. The
winter, which commences in May and lasts till October, is cold. The
prevailing wind in this province is from the south-west. The climate is
temperate and wholesome, with the exception of those marshy
situations, and others which occasionally overflow, where the fever
reigns periodically in certain months. This is a country almost
universally low, with few mountains and hills, and these of
inconsiderable elevation. The land is generally excellent, and
adapted to almost all the productions of the torrid zone, as well as
those of the temperate. Wheat and Indian corn are abundant, as are
the plantations of cane, cotton, and mandioca. The most lucrative,
however, are those of the matte. These productions do not prosper
generally in all the districts; wheat rarely grows but in the southern
parts, and matte in the northern. The peach tree is so prodigiously
abundant in the southern islands of the Paraguay and the adjacent
country, that they are frequently cut down in order to heat the oven
with their branches. They are not met with to the north of St. Fé.
Sebastian Caboto and Diogo Garcia were the discoverers of this
country, on advancing up the Paraguay in 1526.
 The colony of Assumption was the first establishment in the
province after the fort of St. Anna, and suffered much from the
various neighbouring nations of barbarous Indians, principally the
Guaycurus and Payagoas, who were as numerous as they were
ferocious and brave. It was, however, rendered defensible by the
augmentation of its settlers. Defective in gold and silver mines, which
attracted so many people to Peru and Mexico, this fine country, so
advantageously situated, remained for many years after its discovery
almost unnoticed.
The middle and eastern parts were the conquests of the Jesuits,
by the introduction of Christianity amongst their possessors, the
Guaranis. These priests, knowing, from experience, the relaxation of
European morals, and how much it prevailed amongst the American
colonists, determined to catechize only those Indians who were at a
distance from the Europeans, in order that the proselytes should not
know practices contrary to the precepts to be taught. The perfection
with which they soon spoke the Guaranitic idiom, and the docility of
this tribe of Indians, concurred equally to carry into effect this
wished-for object.
In a few years the Jesuits reduced the various hordes of this
nation to a settled life, in large aldeias, or villages, denominated
reduçōes, the number of which, in the year 1630, had arrived at
twenty, with seventy thousand inhabitants. Those who had advanced
to the Upper Paranna, with the intention of extending the spiritual
conquest, were obliged, by eight thousand Paulistas, to fall back, in
1631, to the south of the Maracajú Serra. The Jesuit, Montoya,
relates, that he and his colleagues retired from above to below the
seven falls of the Paranna, with two thousand Indians, when the
Paulistas invaded the Upper Paranna, and that the latter continued
hostilely to visit the reduçōes of the Lower Paranna; and that, in
1637, one hundred and forty Paulistas, with one thousand five
hundred Indians, attacked the reduçōes of Jesu Maria, St.
Christovam, and St. Anna, and retired with seven thousand
prisoners.
The Jesuits next reduced the Tappes to the eastward, and
continued to civilize those two nations, by teaching them all the
useful arts, thus forming the celebrated Guaranitic empire, which
moderate calculators never raised to more than two hundred
thousand inhabitants; and it is said they were able to carry into the
field an army of forty thousand men. One authority states that
between the rivers Uruguay and Paraguay was established a
powerful republic, comprising thirty-one large villages, inhabited by
one hundred thousand souls; but Guthrie raises the population of
these missions to three hundred and forty thousand families, making
a surprising and incredible population of thirteen hundred thousand
inhabitants.
It is said the word Guarrannis means Guerreiros, (warriors,) and
that this people, in former times, wandered about, carrying
destruction to every part within their reach, and obtaining many
prisoners, thus acquiring greater numbers and power. Their
language and name became common to divers tribes, whom these
religious teachers introduced into their associations, from different
parts, by which they greatly augmented the population of this
republic. The exchequer of the catholic crown furnished annually
forty to fifty thousand ducats to the missionaries employed in this
conquest, inasmuch as the Indians did not render their agriculture
and industry adequate to the expenditure and support of the country,
the public receipts of which the Jesuits were the receivers and
appropriators. When the villages and temples were completed, each
man, from eighteen to fifty years, paid annually a capitation of two
gold pieces. The captains (caciques) were exempted from this tribute
as well as their first born, (primogenitas,) and twelve men more in
each mission destined to the service of the church. In 1634, when
there was already thirty reduçōes with one hundred and twenty-five
thousand Christian Indians, the number that paid tribute only
amounted to nineteen thousand one hundred and sixteen. In 1649,
with a view of gaining more subjects, and to avoid any desertion to
the territory of the crown of Portugal, where there was no capitation,
the Indians were alleviated from one-half of this tribute. Four years
previously was conceded to them the power of exporting the matte,
upon certain conditions, in order that they might become less
chargeable to the capitation. The concession of this liberty was a
means of feeding the cupidity of the Jesuits, by the intervention of
the curates of the reduçōes serving them as a cloak through the
Indians, to carry on a great trade in this commodity, to the prejudice
of the merchants at Assumption, whose complaints produced two
decrees; the one apprizing the chief priest of Paraguay of the
exorbitant quantity of matte which its padres had traded in; the other
prohibiting the Indians from carrying more than twelve thousand
arrobas annually to that city.
Each of the reduçōes, otherwise called missions, was a
considerable town, laid out with straight streets. The houses,
generally of earth, were whitened, covered with tiles, and had
verandas on each side, in order to preserve them from the sun and
rain. On seeing one, a correct idea might be formed of the whole.
Each mission had only a mother church, generally of stone,
magnificent and richly ornamented, some being entirely gilded. A
vicar and a curate, both Jesuits, were the only ecclesiastics
exercising the parochial functions, being, at the same time,
inspectors of all civil economy; under whose direction there were
magistrates, (corregedores,) elected annually; a cacique, or chief,
elected for life; and other officers, each with his jurisdiction. With the
exception of these, every individual of both sexes wore a shirt
reaching to the ancles, usually of white cotton. They cultivated matte,
the cotton tree, and such provisions as prospered best in the
country. The whole was deposited in warehouses, from whence it
was distributed daily to the people. Each family received an ounce of
matte, four pounds of meat, and a certain measure of Indian corn,
and more if it was judged necessary. All passed under the review of
the magistrates or of other subordinate persons. The curates lived
commodiously, near to their churches, and contiguous to their
dwellings were two spacious houses; one destined for schools of
reading, painting, architecture, music, and having shops for different
manual occupations; the other was a recolhimento, or receptacle for
a great number of young girls, who were engaged in different works,
under the inspection of matronly women, already instructed. The
women received on Monday a certain portion of cotton, which they
were to return in the spun state on Saturday. The curate,
accompanied by certain officers and masters, went daily at eight
o’clock to visit the schools and shops. The signal of the last Avi
Marias was also that of the rosario, or counting of beads, at which all
assisted.
All superfluities were exported, with a large quantity of tallow,
hides, and matte, and with the proceeds they paid the capitations,
and obtained in return requisite European articles.
It is calculated that the Indians possessed near two million head
of cattle.
Such was the condition of the reduçōes, or missions, which
constituted the pretended Guaranitic state, in 1768, when the Jesuits
were expelled and their people delivered over to the direction of the
Dominicans, Franciscans, and Mercenarians. The last is an order of
friars instituted in Arragon by King James for the redemption of
captives.
The Marquis of Bucarelli, governor of Buenos Ayres, wishing to
go personally, accompanied by the best troops of Europe which he
could collect in that capital, to execute the orders of his sovereign
relative to the missions, which were repugnant to the feelings of the
Indians, wrote, before he commenced his march, to all the vicars to
send to him the chief (cacique) and head magistrate of each mission,
in order that he might communicate to them advices from his
Majesty. On their arrival at Buenos Ayres he unjustly retained them
as hostages, with a view of obviating any difficulty that might arise. In
Yapegú, which is the first mission, was presented to him the
celebrated chief, Nicolau, who in Europe passed for the sovereign of
the Guaranitic republic, and who was not able to proceed in the train
of the others, in consequence of the infirmities of old age, being then
seventy. The Europeans and their descendants began to frequent
the missions, and the Indians to have mutual relations with them,
and to learn from them many of the most familiar words, also some
relaxation from the more correct morals and manners of the Jesuits.
The population, in consequence, soon began to diminish, as well as
the neatness and cleanliness of their houses and temples.
Mountains.—In the northern part there is the serra of Maracaju,
which is of trifling altitude; and the Lambara, in the vicinity of the
capital, also not of remarkable elevation, although it exceeds in
height all those that encompass it.
The mineralogy consists of gesso, or plaster, limestone, granite,
and marble.
Rivers and Lakes.—Besides the three great rivers that limit this
province, there are many others which water the interior, and some
of them navigable for a considerable distance.
The Gualeguay, which has a course of more than one hundred
and forty miles, empties itself into the Uruguay, a few leagues above
the Negro, after having watered a level country, rich in cattle, corn,
and fruit trees.
The Mirinay, which also runs into the Uruguay, fifty miles below
the Ibicui, is considerable, and runs through an extensive country,
stocked with large cattle.
The Taquary, seventy miles long, empties itself also into the
Uruguay, ninety miles below the preceding.
The Jaguare, rising in the Serra Maracaju, runs into the Paranna,
twelve leagues below the Setequedas (Seven Falls).
According to a map of the country, which does not appear a bad
one, the Acarahy is the first considerable river which enters the
Paranna by the right bank, seventy miles below the Setequedas.
The Tibiquary, which is considerable, disembogues into the
Paraguay ninety miles above the confluence of the Paranna. The
Cannabé, after a course of one hundred miles, enters the Paraguay
fifty miles north of the Tibiquary.
The lake Ibera, otherwise Caracares, is pretty considerable, and
approximates the left margin of the Paranna; it has some islands,
and its neighbouring lands are marshy. Charts do not accord as to its
size: some give it one hundred and fifty miles in length, and little less
in width; others, ninety in length, and twenty in width; they agree that
it communicates with the Uruguay by the Mirinay, and with the
Paraguay by the Correntes, which empties itself near thirty-five miles
below St. Luzia. It is also said to communicate in two parts with the
Paranna. The lake Jagapé, which is large, and surrounded with
woods, is near the northern bank of the Paranna, about sixty miles
above the town of Itaty.
Phytology.—The cedar, which is of various sorts, the páu
d’arco, (bow wood,) sassafras, with many other trees of fine timber
for building; the pine tree, and those which afford a resin
denominated the blood of the dragon, and the oil of cupahiba; the
ipecacuanha, jalap, rhubarb, and other medicinal plants; the
opuncia, pine-apple, orange, banana, and mamoe, of which last tree
there are male and female; the male bears no fruit but only flowers,
the female bears fruit and no flowers.
The vegetable matte is a large shrub or bush, with leaves similar
to an orange tree, and tastes of mallows; it is said the serra
Maracaju produces the best. It is usual not to wait for the leaves
falling, but they are plucked, and then dried by some of the most
approved methods, generally upon hides between two fires. This
plant is taken almost like tea, and the use of this beverage has
prevailed from time immemorial amongst the Indians of the northern
part of this province. It was they who introduced it amongst the first
inhabitants of Assumption.
Zoology.—This province is prodigiously abundant in cattle,
horses, and mules; sheep are numerous, but goats few. There is a
sufficiency of hogs for the consumption of the inhabitants. Amongst
the wild quadrupeds are remarked the ounce, the deer, the monkey,
the fox, the rabbit, the cat, the tamandua, quaty, zorrilha, or squash,
the tatous, or armadillo, paca, cotia, and the boar. Of birds, the emu
ostrich, the seriema, jaburu, cegonha, garca, mutun, jacu, colhereira,
urubu, tucano, rola, troquaze pigeons, the parrot, codornize, or quail,
beija-flor, or humming-bird, the guiraponga, and the partridge. There
are also a diversity of wild ducks and geese.
The principal povoações are, Assumpçao, or Assumption,
Correntes, Coruguaty, and Villa Rica.
Assumpçao, an episcopal city, is in a state of mediocrity,
possessing some commerce. It is the capital and the residence of
the governor, and is situated upon the margin of the Paraguay, which
daily washes away a part of the ground upon which it is built. It is
ornamented with a hospital, with convents of the Dominicans,
Franciscans, Mercenarians, Recoletos, (rigid friars,) and a seminary
which was a Jesuitical college. This city has no regularity nor fine
edifices; the greater part of the houses are built of earth, and many
of the inhabitants of its three parishes are descended from the
Portuguese. From hence is exported tobacco, imbe, timber, and a
prodigious quantity of matte to Buenos Ayres, where it is afterwards
packed in hides, and distributed over various Spanish districts, being
a beverage universally used amongst them, as well as by the
Portuguese in the southern parts of Brazil. In its environs are bred
numerous herds of large cattle. There are plantations of cotton and
the cane. Honey and wax are abundant. They cultivate also, as in
other parts, aipim, or pompim, as it is called here, which root, after
being scraped, chopped, and dried in the oven, is cooked with meat,
serving for bread. The maize, or Indian corn, after it is boiled, and
beat in a pestle, is passed through a sifter, kneaded with milk, and
baked, when it receives the name of chippa.
The bishop is a suffragan of La Plata, otherwise chuquissaca.
The chapter of the church, as in all other ultramarine cathedrals of
the Spanish states, is composed of twelve canons, including the
moderator of the Inquisition, five dignitaries, the dean, archdeacon,
chanter, treasurer-mór, and master of the college; also six petty
canons to sing the Evangelists, and as many more half petty canons
for the Epistles, whose vestments differ little from the others. The
canons of theology, doctorial, magisterial, and penitentiary, only give
graduates, and that by competition. The revenue of the suppressed
canonship is destined for the expenses of the tribunal of the holy
office.
There are two tribunals, one called the Junta Decimal, for the
public disposal of the decimos, and consisting of two canons, a royal
fiscal, a minister clothed with a toga, or gown, an accountant, and an
escrivao, or scrivener. The other denominated Meza Capitular, for
the collection and distribution of the proceeds of the decimos, is
formed of a provisor, or vicar-general, a canon, acting at times as a
fiscal, the contador-mor, or chief accountant of the treasury, and
another accountant to make the distribution or rates.
All the produce of the decimos is appropriated to the church. In
calculating this, the chief accountant of the treasury divides it into
nine equal parts; one and a half, under the name of noveno e medio,
belongs to the crown, and is destined for the repairs and other
necessities of the church; and which the sovereign, as patron, gives
by way of succour. Of the other seven and a half parts, one-half is for
the bishop, whose duty is to relieve the necessities of the diocesans,
especially the poor ones, collected in the house erected for their
habitation, because none of them are permitted to solicit alms pelas
portas, at the doors.
The residue is divided into three equal fifths, one for the dean,
the remainder subdivided anew into three, two are distributed
amongst the other dignitaries and the canons, with arithmetical
proportion. The part remaining is portioned equally amongst the
petty canons, and the half petty canons, or chaplains. The priests of
the cities are denominated reytors, or rectors, and those of the
towns, vigarios, or vicars. The padres only of the Indians have
revenues, (congrua,) drawn from the coffers where the produce of
the Indian lands that are sold, and the rents of the emprazadas,
(persons paying an annual fine for lands bought,) are deposited.
They receive nothing from the parishioners, except for the
solemnization of burials.
The priests of the churches of the whites (brancos) alone have
the altarage, (or free offerings of the people made at the altar,) and
the productions of the patrimonies with which they were founded.
The churches are given after a competition of talent exhibited
before the bishop. The competitors are convoked by him and the
vice-patron, who is the governor, and without whose consent nothing
can be decided in these cases. In order to fill up a vacancy, the
bishop proposes three, the choice from which belongs to the vice-
patron, if he does not reject the whole, and demand a proposal of
others for his choice.
 Correntes is a small city, advantageously situate in the southern
angle of the confluence of the river Paranna, ornamented with a
convent of Dominicans, one of Franciscans, and a third of
Mercenarians, having straight streets, and many houses with one
story. The Jesuitical house is in ruins. Amongst its inhabitants, there
are some Portuguese, many Indians, and a few negroes. In its
vicinity there is much marshy land, and very extensive woods. Cattle
and horses are the wealth of the country. Mandubins, Indian corn,
vegetables, water-melons, and cotton, are the objects of culture. The
land is neither adapted for wheat nor matte. The ants and locusts,
which are extremely numerous, destroy the mandioca, and prevent
its cultivation. The pitangueira, or pitangua tree, is very abundant;
peaches are not met with. The imbagay is a fruit similar to the
mango, but something smaller, and found from hence northward.
Hides and timber are the principal articles of exportation. Mosquitoes
are extremely troublesome here.
Justice is daily administered by two alcaldes, or magistrates,
assisted by two assessores, or lawyers. The four are elected
annually by a judicial cabildo, composed of twenty-four governors for
perpetuity, except in the event of delinquency; four of whom are
principals, namely the royal ensign, the deacon, an officer called the
aguazil maior, and the provincial alcalde. The others are ordinaries,
each with his inspection, presided by an assessor-general, called
tenente assessor, (lieutenant assessor.) There is an advocate
named by the audiencia, or audience-court of the province, for the
purpose of defending gratis the causes of the poor, or those who do
not possess a patrimony of a certain value, and also of prisoners,
although they may be rich.
Ten leagues to the north of Correntes is the parish of
Nehembuçu, on the margin of the Paraguay, where they build boats
and different sorts of vessels. Thirty leagues to the south of
Correntes is situated the village and parish of St. Luzia, also upon
the margin of the Paraguay; in its district there is gesso, a species of
plaster, which forms a branch of exportation. In this interval are the
parishes of Algarrobas, Esquina, and Goya, abounding sufficiently in
meat and fish.
 Bagada de St. Fé, and commonly called Paranna, is a small
village situated upon the Paraguay, in front of St. Fé, in view of an
island of considerable extent. From hence is exported a good deal of
limestone.
Coruguaty is a middling town, and celebrated for the large
quantity of matte collected in its district, of which it is the deposit. It is
situated about thirty leagues to the north-east of Assumption, and
three miles distant from the left margin of the river from which it
borrows the name.
Five leagues to the north of it is the prezidio or garrison of St.
Miguel, established in order to obstruct the invasions of the
Guaycuru Indians.
Villa Rica, where also is accumulated large quantities of matte,
lying twenty leagues to the south-east of Assumption, is yet small.
There is another place of the same name on the borders of the
Paraguay, to the north of the capital.
Arroio da China is a middling town, situated on the banks of the
Uruguay, more than thirty leagues above its embouchure. Its
inhabitants, mainly white people, breed cattle and cultivate corn and
fruit.
Itaty is a small town, but regular, and well situated upon the
southern bank of the Paranna, about thirty leagues above Correntes.
Its inhabitants consist of Indians and some white people; a portion
occupy themselves in potteries, and others in forming plantations of
the cotton tree. The soil and climate are adapted for oranges and
water-melons, which prosper abundantly.
In the country of the missions is to be remarked the following
places.
Candellaria, which took the name from its magnificent church, as
did almost all the reduçōes of the pretended Guaranitic kingdom, or
the missions of the Paranna, of which it was always considered the
capital, in consequence of its superior size and population. It is
situate upon the left bank of the river Paranna, where it inclines to
the west, near the mouth of a small river.
 Corpus, also on the left margin of the same river, is fifteen
leagues to the north of Candellaria, and is the most northern of the
missions, situated upon the Paranna, and one of the handsomest in
the province.
Between the two preceding are situated those of St. Gosme, St.
Anna, St. Gosme Velho, Nosso Senhora do Loreto, and St. Ignaçio
Menor, (the smaller.) This last is three leagues above the preceding
one, and four below Corpus.
The Padre Xarque, says the reduções of Nosso Senhora do
Loreto and St. Ignaçio Menor, were founded for the establishments
of the twelve thousand Indians, which the Jesuits conducted from the
Upper Paranna, when the Paulistas invaded the country.
Itu, upon the same margin of the Paranna, is fifteen leagues to
the west of Candellaria.
Assumpçao is fifteen leagues, with little variation, to the south-
west of Corpus, near the mouth of a small river that loses itself in the
Uruguay.
Conceiçao is situated sixteen leagues to the south of the
preceding one, and little more than three leagues distant from the
river Uruguay.
St. Thomas is fifteen leagues distant, in a southern direction,
from Conceiçao.
St. Maria Maior is a few leagues to the north of Conceiçao, also
upon the margin of the Uruguay.
Apostolos is little more than six leagues to the west of Conceiçao,
upon the road which leads towards Itu; and twenty miles further in
the same direction upon this road St. Carlos is situated.
St. Francisco Xavier is a few leagues to the north of St. Maria,
and to the east of Candellaria. In this interval Martyres is situated.
Itapuan is on the right bank of the Paranna, to the north of
Candellaria. Trinidade is eight leagues to the north of Itapuan. St.
Ignaçio Guassu (the larger) is near the head of a branch of the river
Tibiquary. It is the most ancient of the whole.
 St. Fé is five leagues to the north-east of St. Ignaçio Guassu. The
mission of Jesus is four leagues to the north-north-west of Trinidad.
St. Roza is six leagues to the east of St. Ignaçio Guassu; St.
Gosme four leagues to the south-east of St. Roza.
St. Tiago is eight leagues to the north of Itu; and Yapegu, which is
the most southern, and amongst the largest of the missions, is
situated near the Uruguay, a little below the confluence of the Ibicui,
and half a league to the north of the river Guavirida. The Jesuits had
a college here richly ornamented.
 CHAP. VII.
PROVINCE OF URUGUAY.

Foundation of Aldeias, called Missions, by the Spanish Jesuits for the

Tappe Indians—Flourish till the Expulsion of that Sect—
Subsequent Decay—War between the Spaniards and Portuguese
—Conquest of the Seven Missions by the latter Power in 1801—
Governor sent—Boundaries—Mountains—Rivers—Phytology—
Zoology—Names and Population of the Seven Missions at their
Conquest.
In the beginning of the seventeenth century, the Spanish Jesuits
entered the territory to the east of the river Uruguay, and there
founded seven large villages, called reduçōes, for the habitation of
various hordes of Tappes, the possessors of the country, in order the
better to civilize and bring them to Christianity, by the same means
as were practised with those of the Paranna. It has been already
stated, that, in the treaty of limits of 1750, the exchange of these
missions for Colonia do Sacramento was agreed upon by their
Faithful and Catholic Majesties; and also, that the Jesuits frustrated
its execution in the first instance, and that, on the sudden return to
Rio de Janeiro, of Gomes Freyre d’Andrade, in 1756, things soon
reverted to their anterior state.
These reduçōes, which made a part of the spiritual Jesuitical
kingdom, flourished to the period of the expulsion of their founders,
when they began to decay, and thirty-four years of deterioration, by
imperceptible degrees, could not have transformed the whole more
effectually; in which state they were, in effect, at the beginning of the
present century, when the declaration of war between the two
crowns in Europe, caused the arming of the inhabitants of the
capitania of Rio Grande de St. Pedro, who, since the peace of 1777,
had lived in tranquillity.
Almost at the same time that the Portuguese troops of the town
of St. Pedro passed the river of St. Gonçalo, in 1801, against the
Spanish posts, in the vicinity of the western margin of the lake of
Patos, a corps of Portuguese militia and deserters, attracted by the
amnesty, were put in motion upon the frontiers of the river Pardo;
amongst the latter of which appeared Joze Borges do Canto, a
native of the country, and who had deserted from a regiment of
dragoons. He immediately offered to go and commence hostilities in
the Spanish territories, on being granted some comrades and the
necessary arms. Ammunition only was conceded to him, with the
liberty of assembling such people together as would join his
standard. Having formed a battalion of forty men, armed at their own
expense, he marched direct to the missions of Uruguay, and,
encountering on the road a known Indian, who was retiring
discontented from the Spaniards, he received from him the certain
intelligence that the Indians, on hearing of the war, would not
hesitate to subject themselves to the crown of Portugal, as almost all
the Indian population lived unhappily under their present
government. Canto persuaded the Indian to return, and announce to
his compatriots the opportunity which was now presented of freeing
themselves from the Spanish yoke, and of passing under the
protection of the Faithful Crown, and to inform them, that he would
afford all necessary assistance. The Indian, convinced of this,
accompanied them to within sight of St. Miguel, where there was a
lieutenant-colonel, commanding a trench which he had formed in
apprehension of an attack from the Portuguese.
Having arrived thus far at day-break, Canto sent the Indian
forward by a bye-way, with orders to bring him what information he
could, to a certain situation, whither he should continue to march. As
the place was very near to the trench, Canto and his party were
discovered by the sentinel, who called out to arms. Under these
circumstances, Canto saw himself obliged to advance without order
against the entrenched, who were in greater disorder; and after
discharging a few shots they abandoned the fortification, retiring to
the town, where the commandant was, and leaving this intrepid
squadron masters of the trench, with ten pieces of artillery.
The commandant supposing himself to be attacked by a great
number of another class of combatants, offered a capitulation to the
chief of the conquerors, who willingly conceded almost all that was
asked, in order that the Spaniards might leave the country before a
reinforcement arrived, or before they knew that it was only forty
adventurers, without any corps of reserve, from whom they had fled.
The commandant was a good deal perplexed, at the execution of the
articles of capitulation, when Canto, being asked for his degree of
rank, replied that he was the lowest soldier in the Portuguese army.
At this time the Indians of the place had already united with the
Portuguese, and the adjustment of the treaty was indispensable.
The Spaniards on retiring experienced the misfortune of falling
into the hands of a similar party, who took them prisoners, and all
that was conceded to them, against which the commandant
protested, and demanded the fulfilment of the capitulation. The
Spanish officer called upon Canto for an adjustment, who replied,
that he could not interfere, inasmuch as the party were not
subordinate to him, but that he would report the affair to the governor
of Rio Grande, and all that he ordered should be executed; the party
in the mean time remaining prisoners.
The governor, on receiving the account, ordered Canto to fulfil
the capitulation, excepting the article that gave up the artillery; which,
he said, ought to belong to his Royal Highness, and to whom he had
given a detail of Canto’s valorous deeds, in order that he might be
rewarded. In the mean time he made him captain of a new company
of militia; and the person who brought the standard a lieutenant,
giving him too the liberty of naming for ensign one of his brave
companions.
As soon as the people of the other missions had witnessed the
comportment of Canto towards the first that had submitted to him,
almost all hastened to acknowledge the Faithful Crown. The happy
conqueror released them from some public contributions, which were
the most heavy upon them, and, freely giving up to them the fruits of
their labour, received the name of Liberator.
Shortly after the governor sent Major Joaquim Felis to govern the
conquest, with orders to confer with Canto, upon the state of affairs.
Having delivered the new province to the commandant, and received
a good reinforcement of regular troops, with some militia and
volunteers from the serra above, he obtained permission of the
governor to pass to the other side of the Uruguay; for which purpose
some barks of skins were made according to the fashion of the
country.
In the night of the 1st of November, eighty men, chosen from the
army, passed the river, amongst whom figured some grenadiers of
the regiment of Estremoz; and whose chief was a brave ensign, well
known by his surname of Padilha. Part of them took up a position in
a wood; others proceeded a little way up the river, keeping near its
banks, in order to give more prompt succour to the first on the signal
of attack, which began in the morning, against those who first
entered the plain. The assailants, together with thirty Spaniards, who
came to their succour, were put to flight, but immediately returned in
larger numbers, with three field pieces, with which they laboured to
open out both their wings. However, the Portuguese did not give
them time for a second discharge, but falling intrepidly upon them,
they put them to the rout, taking their cannon, nine prisoners, and
leaving fifteen dead upon the field.
On the 23d of the same month, almost at midnight, a cannon was
discharged in the Passo dos Barros, which is about three leagues
below St. Borja, where it was heard; and from whence afterwards
arrived an Indian, living in that neighbourhood, with information to
the Portuguese, that the Spaniards were stationed in the woods,
near the same pass. They remained the rest of the night under arms.
The following morning Captain Joze Borges do Canto put himself in
march for this point, with his company and some others, amounting
to one hundred and ten men; and finding the Spaniards entrenched
in the woods on the banks of the river, and not discovering any
advantageous mode of attacking them, sent his lieutenant with thirty
men dressed in white according to the Indian fashion, which
marching at a great distance from the Spaniards, and having gained
their rear, began firing upon them. The first discharges were the
signal for the captain to invest the fortification, which was abandoned
without any resistance, the Spaniards leaving seventy-four prisoners.
Such was the success of the campaign, on the part of the
Portuguese, in this district, and the mode by which the Portuguese
crown possessed itself of the province of the Seven Missions, which
made a part of that of Rio Grande de St. Pedro, until a governor was
named to it. It is confined on the north by that of St. Paulo; on the
west by that of Paranna; and on the south and east by the province
of Rio Grande de St. Pedro.
Mountains.—St. Martinho, the most elevated portion of the
serra, which serves for its eastern limits, and the mountain of St.
Luiz, in the vicinity of the town of its name, are the most remarkable
mountains.
Rivers.—Besides the Uruguay and Ibicui, already mentioned, is
to be remarked the Hyjuhy, which originates at the base of the
mountain of St. Martinho, traverses the province from east to west,
empties itself into the Uruguay in front of Assumption, and a few
leagues to the north of St. Nicolau, having passed near St. Angelo, a
little below which the Hyjuhy-mirim enters it on the left side.
The Toropy rises in the same cordillera and falls into the Ibicui.
The Jaquari waters a considerable portion of this province, and falls
into the Ibicui four or five leagues below the Forquilha. The Hibipita
enters the Ibicui also twenty leagues below the preceding.
The Piratini forms itself in the vicinity of the said serra, passes a
short distance from St. Miguel, and runs into the Uruguay a little
below St. Nicolau.
Phytology.—The Brazilian pine and the cedar are not
numerous. The cotton tree, the matte, and mandioca, also Indian
corn, wheat, potatoes, with other edible roots, are cultivated;
likewise, gourds, water-melons, pine-apples, and divers hortulans;
and, among fruit trees, the orange, pitangua, and peach.
Zoology.—The animals, both domestic and wild, are the same
as those of the adjoining provinces.
The Tappes are a horde of Guaranis, which separated from the
latter in former times, and lived for a long period upon the banks of
the higher Paranna, where they were at times invaded by the others.
It is, however, certain that they occupied the southern part of this
province when the Jesuits began to have a knowledge of them. They
were esteemed a people, not only less vicious than all other tribes in
Welcome to our website – the ideal destination for book lovers and
knowledge seekers. With a mission to inspire endlessly, we offer a
vast collection of books, ranging from classic literary works to
specialized publications, self-development books, and children's
literature. Each book is a new journey of discovery, expanding
knowledge and enriching the soul of the reade

Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.

Let us accompany you on the journey of exploring knowledge and

personal growth!

textbookfull.com