In the late 1920s and early 1930s, William Dyer, Frank Pabodie, and Valentina Roerich led expeditions to the Pole of Inaccessibility in the South Pacific, and then onward to Antarctica. Two years ago, their expeditions were found in a storage locker at Miskatonic University. We have scanned and OCR'd the data they contain, and we now want to store that information in a way that will make search and analysis easy.
We basically have three options: text files, a spreadsheet, or a database. Text files are easiest to create, and work well with version control, but then we would then have to build search and analysis tools ourselves. Spreadsheets are good for doing simple analysis, they don't handle large or complex data sets very well. We would therefore like to put this data in a database, and these lessons will show how to do that.
A relational database is a way to store and manipulate information that is arranged as tables. Each table has columns (also known as fields) which describe the data, and rows (also known as records) which contain the data.
When we are using a spreadsheet, we put formulas into cells to calculate new values based on old ones. When we are using a database, we send commands (usually called queries) to a database manager: a program that manipulates the database for us. The database manager does whatever lookups and calculations the query specifies, returning the results in a tabular form that we can then use as a starting point for further queries.
Every database manager—Oracle, IBM DB2, PostgreSQL, MySQL, Microsoft Access, and SQLite—stores data in a different way, so a database created with one cannot be used directly by another. However, every database manager can import and export data in a variety of formats, so it is possible to move information from one to another.
Queries are written in a language called SQL, which stands for "Structured Query Language". SQL provides hundreds of different ways to analyze and recombine data; we will only look at a handful, but that handful accounts for most of what scientists do.
The tables below show the database we will use in our examples:
**Person**: people who took readings.
Site: locations where readings were taken.
Visited: when readings were taken at specific sites.
|
**Survey**: the actual readings.
|
Notice that three entries—one in the Visited table,
and two in the Survey table—are shown in red
because they don't contain any actual data:
we'll return to these missing values later.
For now,
let's write an SQL query that displays scientists' names.
We do this using the SQL command select,
giving it the names of the columns we want and the table we want them from.
Our query and its output look like this:
In [1]:
%load_ext sqlitemagic
In [2]:
%%sqlite survey.db
select family, personal from Person;
The semi-colon at the end of the query tells the database manager that the query is complete and ready to run. We have written our commands and column names in lower case, and the table name in Title Case, but we don't have to: as the example below shows, SQL is case insensitive.
In [3]:
%%sqlite survey.db
SeLeCt FaMiLy, PeRsOnAl FrOm PeRsOn;
Whatever casing convention you choose, please be consistent: complex queries are hard enough to read without the extra cognitive load of random capitalization.
Going back to our query, it's important to understand that the rows and columns in a database table aren't actually stored in any particular order. They will always be displayed in some order, but we can control that in various ways. For example, we could swap the columns in the output by writing our query as:
In [4]:
%%sqlite survey.db
select personal, family from Person;
or even repeat columns:
In [5]:
%%sqlite survey.db
select ident, ident, ident from Person;
As a shortcut,
we can select all of the columns in a table using *:
In [6]:
%%sqlite survey.db
select * from Person;