Revised with new information as of
November 1, 2012
The Basics of People Databases
This information is designed especially for small mission-based
organizations (nonprofits, non-governmental organizations or NGOs, civil
society organizations, public sector agencies, etc.) with very limited
staffing and funds.
The following terms are used repeatedly in this overview. However,
different database software probably use different terms.
an organized collection of data (.dbf)
a "window" to a database or databases (.apr)
- form or screen
a way of looking at information in a view
an organization of views for a database(s)
databases can be "joined" into one view file, so that information from
more than one database for one record can be viewed at one time
a view that shows data from multiple records on a single "page"
central entry into a database (usually a person); for instance, a record
is all of the information about ONE person: a name, address, phone
number, meeting attendance, publications ordered, committee membership,
etc. A record can also be about an individual project (date project
started, location of project, progress of project, etc.)
information categories for individual records
isolating and displaying a set of records based on data in one of more
reorganizing a set of records in the order you prescribe
a file that can only be read; in a read-only database, changes cannot be
made to the records, but view changes may be allowed
A flat database means all of the information about a record
is kept in a single database.
A flat database is very easy to manage, because it has all of
its information stored in one source. You can have relational data on a
flat database, meaning that some or all of the data from a flat database
can be used in a relational database. For instance, a relational database
may pull information from the flat database, combining it with data from
another database, so that you can see how many board members have email
addresses, or how many donors are also volunteers. A flat database should
allow you to create a variety of different ways to look at the data (input
screens, reports, mailing lists, etc.).
The limitation of a flat database is usually not in the number of
records you can put on (for instance, how many volunteers you can track),
but in how much information you can track per record. Limits of a flat
database are usually realized the more information you need to track about
each individual person (a record), rather than the number of people
(records) you need to track. As time passes, different people at one
organization need to track more and more information about each record, or
view it in very different ways. For instance, one staff member may want to
track meeting attendance and program involvement in detail, while another
may need detailed information about each record's donation history.
You can create a different flat database for each staff person's need,
but this will eventually make it very difficult to find out all
information about one person quickly; imagine having to look on one
database for board information, another for event attendance information,
another for publications they've received, another for their volunteer
involvement, and you get the idea.
There are two ways to avoid this project entirely: by requiring everyone
to input their information into one database, or, requiring everyone to
use the same software to create their databases, and then making these
databases relational, so that you can pull from multiple databases
to view information for a single record. With a relational database, users
do not see the separate databases that have been related together when
viewing a record's information; instead, users see different pieces of
information about a single record (person), without being able to see
which databases each piece of information is being pulled from. Only an
advanced user will be able to tell that, when she is looking at one
record, she is also looking at more than one database.
Upgrading from a flat database to a relational database allows for a
great deal of growth for information-tracking. A good relational database
allows for endless sorting and viewing options; virtually any combination
of information in any form can be generated from a good relational
When databases are relational or joined, adding a new record
to the main database will add the same record to ALL of the joined
databases. Or, changing the spelling of someone's name will change the
information to ALL of the joined databases.
To join a database, there must be a field that has something unique
about each and every record in a database. It's best to create a field
specifically for the joining process; this field should hold a unique
identification number. When a new record is added, it should automatically
assign a unique number in the MAIN database; this number is then copied
automatically to every other joined database. It's also a good idea to
create a function that makes the first name, last name and company
affiliation also copy to each database, and changed automatically and
simultaneously. If a record is deleted, it is also deleted from all other
Also have a look at the online support pages for whatever software you
are using. There may have their own tutorials about database basics as
When shopping for database software, make sure that it at least meets this
Before you invest in a software package:
- The person or people who will use it the most can feel ownership of
the software; it's easy to use and easy to learn.
- It can work on the computers and operating systems you already have
in-house (no need for upgrades).
- It can import and export data to and from the most-used software
packages for both IBM/Clones and Macintosh computers (FileMaker Pro, OpenOffice
Base (part of the entire free OpenOffice suite), NeoOffice
database (part of the entire free NeoOffice suite),
LibreOffice, Lotus Approach, various Microsoft products, etc.).
That means that it can export data as comma-delimited, tab-separated,
dbf, dif, sylk, csv or a spreadsheet. Why? The data in your database is
used by more than just your volunteer manager or your fundraising
manager -- it's going to be used by the bulk mail house, an outside
consultant, the marketing manager, maybe even traded with another
organization, and they all aren't going to have the same software as
- It comes with a tutorial of some kind
- It has lots of screen captures or sample database templates, so you
know exactly what it does or can look like
- It allows the user (preferably the person who will use the database
the most, not just your IT person) to change existing view screens, and
even create new ones (users should be able to change what information
they see on screens as appropriate).
- It allows the user (preferably the person who will use the database
the most, not just your IT person) to change, add or delete fields of
information. Your organization may have a particular information
interest in a particular group, and no specialized software can
anticipate every organization's every need.
- It can be networked (people can access the information from more than
one computer, either via a LAN or the Internet/the cloud).
- It allows the main user to set up security measures (read only access
for other users, for instance; see Customer
Database Principles for more information)
- Has relational capabilities, (e.g., adding a new record to the donor
database will add the same record to the ticket-selling database, and
- Users can generate personalized mailing labels, letters, name tags
and other customized reports.
- Users can set up automated functions on the database (sometimes known
as macros), such as automated numbering fields and automated calculation
Finally: no organization measures its success by the number of people who
are in its database(s). The value of a database also doesn't come from a
computer program. The value of a database comes from the quality of the
information that is tracked. The most important component in a good
database system is people who understand the importance of gathering quality
information and of thinking proactively, and who are dedicated to (and fully
supported and empowered in) keeping the information up-to-date.
Develop your systems of tracking "people" information based on how your
staff wants to use information about clients, volunteers, donors and
potential audiences. The first step in deciding WHAT information you need
to track is to find out what each staff member wants to be able to do with
the database. Fund-raising staff may want a list of volunteers each
quarter who have also made financial contributions; the executive director
may want to occasionally see what city and county officials have attended
your organization's events; the marketing staff may want to know to know
weekly who or what referred people who call your organization. If you
don't know what staff members need out of your information-tracking
Deciding what information needs to be tracked will help you decide what
fields to create to track information about people in your database(s).
These tip sheets may also help you:
- Customer Database Principles
- Customer Database Regular Maintenance
- Importing Information Into a Database
- Free Help With Databases & Software
- Keeping Volunteer Information
- Choosing Specialized Software
(label-making software, volunteer management software, project
management software, fund raising software, etc.)
- List and comparison of volunteer management
survey on volunteer management software
In March and April 2012, myself and Rob Jackson drafted and circulated a
survey regarding software used to manage volunteer information. The
purpose of the survey was to gather some basic data that might help
organizations that involve volunteers to make better-informed decisions
when choosing software, and to help software designers to understand the
needs of those organizations. We also wanted to get a sense of what
organizations were thinking about volunteer management software. The
results of the survey include an executive summary of our findings, as
well as the complete responses to questions and our analysis of such.
Rob and I did not have time to analyze all of the comments made in
answer to some questions; for all questions, we listed the comments
made, but we did not always offer any observations about such, or group
the responses into categories. We welcome the efforts of other
researchers to offer their own analysis of the data provided.
Also see TechSoup. The site
includes resources and advice regarding databases. TechSoup (formerly
CompuMentor) is a non-profit organization based in San Francisco,
Return to Index of Coyote Communications'
Technology Tip Sheets
Disclaimer: No guarantee of accuracy or suitability is made by the
poster/distributor. This material is provided as is, with no expressed
or implied warranty.
Permission is granted to copy, present and/or distribute a limited
amount of material from my web site without charge if the
information is kept intact and without alteration, and is credited to:
Otherwise, please contact
me for permission to reprint, present or distribute these
materials (for instance, in a class or book or online event for which
you intend to charge).
The art work and material on
this site was created and is copyrighted 1996-2014
by Jayne Cravens, all rights reserved
(unless noted otherwise, or the art comes from a link to another