0. What is a database?

Introduction

A database is an organized collection of data that makes it easy to store, manage, and retrieve information. The types of databases you will come across in fundraising are exposed through relational database management systems usually through some kind of customer relationship management (CRM) software or data warehouse.

Throughout this course, I will be using the word "database" in its broadest, most general sense. You can think of a database as the CRM/data warehouse you use to house your donor data, for example:

• Salesforce
• ROI CRM
• Raiser's Edge
• Blackbaud CRM
• EveryAction
• Hubspot
• Civis

Tables

A database is made up of one or more tables. Each table generally contains data about one specific type of object/concept. For example, a typical CRM will have tables for:

• Donors - listing their ID and their names
• Transactions - gifts given by donors
• Campaigns/Source Codes - information about which types of marketing are responsible for transactions
• Addresses - listing each donor's mailing address
• Phone Numbers - listing each donor's phone numbers
• Email Addresses - listing each donor's email addresses

Columns

Each table contains one or more columns, each identifying a specific piece of information. For example, a Donors table may contain individual columns for:

• Donor ID - the donor's unique ID number
• First Name - the donor's first name
• Last Name - the donor's last name

Each column in a database must have a type, specifying what sort of data is stored in it. Some example types include:

• varchar - short for "variable character", this type of field stores text like Hello world!
• int - short for "integer", this type stores whole numbers like 42, or 24601
• date - this type stores dates like 2025-06-01 (for June 1, 2025)

Databases are strongly typed, meaning that you cannot store data of mixed types in a single column. For example, if you try to store the number 42 in a date column, the database will return an error.

Rows

Each table will also have some number of rows, individual entries in the table. For example, our hypothetical Donors table described above may have a row like:

Primary and Foreign Keys

Finally, each table in a database generally has a primary key, a column that contains no blank values and uniquely identifies each row. In our hypothetical Donors table, "Donor ID" is our primary key. Each donor has one (so there are no blanks) and each donor is uniquely identified by their Donor ID (so there are no duplicates).

Primary keys and foreign keys are used to join two tables together. For example, a hypothetical Transactions table would contain a "Donor ID" column which we could use to link back to our Donors table and find all of Jean Valjean's transactions. In this scenario, the Donor ID column in the Transactions table is a foreign key, since it points to the primary key of another table. I'll have much more to say about the topic of joins and foreign keys later on in the course.

A Helpful Analogy

Data people don't like it when Microsoft Excel is referred to as a "database", because, well, it isn't. But when you're learning new concepts, it can help to map those concepts onto something you are familiar with. If we can indulge for a minute in thinking of Excel in database terms, it may be helpful to imagine that:

• An individual Excel workbook is a database
• Each tab/sheet in the workbook is a table
• Each column on each tab/sheet is a column in that table
• Each row on each tab/sheet is a row in that table
• Each cell is formatted a certain way, according to the type of data in it

And much like you may have formulas and cell references from one sheet to another, you will have primary key and foreign key references between tables in a database.