Ask an Analyst | What Database Should I Buy?

      Do you work in fundraising? Have you ever wondered about what all those people in development/advancement services are doing at your organization? Have you ever sat in a meeting with your data people and thought; what on earth are they talking about? If so, this mini-series is for you! I’ll be answering questions frequently asked by non-technical fundraising professionals. If you have a question that you would like answered, feel free to leave it in the comments section below.  

Spring in Texas is gorgeous. When we first moved to Austin we had been told about the bluebells and other wild flowers that appear in March and April, but nothing had prepared me for their actual splendor. Driving down the highway is a potlatch of color as splashes of blue, yellow, and pink fly by, set against a canvas of vernal greens. Given the Spring weather, when I dressed my six year-old for school this morning I put him in a pair of shorts in anticipation of the seventy-degree forecast set for this afternoon. However, when we stepped outside to catch the bus the sun had yet to fully rise and we were greeted by a misty morning with temperatures in the low-fifties. My six year-old – being particularly sensitive to temperature as perhaps most six year-olds are – chided me for putting him in shorts instead of pants. This led to the predictable back and forth which ended with him waiting for the bus from just inside the front door to keep warm.

Have you ever over-dressed or under-dressed for the weather? I definitely have (a particularly chilly Klondike winter camp from adolescence comes to mind). You are probably asking yourself; what does any of this have to do with choosing a database? Hopefully, my none-too-subtle analogy is transparent, databases have much in common with clothing. Clothing is generally designed to serve a particular function in a particular setting; be it enhancing our stature in a formal setting or providing fuzzy warmth in our private moments of unwinding, clothing is meant to be both functional and situational. The same can be said of databases.

What is a database?

Simply put a database is a structured set of data and can be as simple as a shopping list on the back of a receipt. However, we’re not here to talk about shopping lists, but rather digital database systems that we employ to store and extract facts about our business. People often confuse applications with databases. There is a difference between what we would term an application and a database that is important to understand. An application is what is often referred to as the ‘front-end’ of the database. It is the sleek, shiny, graphical user interface (GUI, pronounced 'gooey') that most people use to interact with the actual database. Instead of requiring advanced knowledge of a programming or querying language, GUI’s enable users to input and extract facts about their business using text fields, check boxes, radio buttons, and drop-down menus. A good GUI is meant to be intuitive, simple, and should provide the user access to any piece of information within three clicks of the mouse. (Though the three-click rule is widely debated and there probably isn’t much difference between three, four, and five clicks - you get the idea.)

The actual database itself is generally entirely separate from the application and can actually exist on its own without a GUI. In fact, if you know a query language like SQL (Structured Query Language), it is often much faster and easier to interact with the database without a GUI. SQL allows programmers to ask complex questions of databases in variable and dynamic ways (I've used SQL to fulfill simple requests such as pulling mailing lists for all alumni within a 50 mile radius of Dallas, to complex queries fitting regression lines to donors' giving histories to better understand their giving velocity, patterns, and life cycles). The most widely adopted type of database is the relational database. If you were to picture a relational database, imagine data stored in tables (much like Excel worksheets) with columns and rows. Groups of tables are linked together and are used to represent different domains (parts of your business). If I had a customer database for example, I would have a series of tables that stored their names, shipping addresses, phone numbers, email addresses, birth dates, etc. that would be linked together with a unique identifier like a social security number (which is actually pretty rare, most databases use a randomly generated unique identifier instead of an SSN or any other sensitive data point). These different data points are queried and then displayed from their various tables to fields in the GUI that appear anytime I open the application.

When companies come and demo their databases, they generally limit their presentation to the GUI. This is understandable as most users will only interact with the database through this application. However, it is important to at least have a cursory understanding of the actual database design itself. Allow me to explain with another clothing analogy.

Finding the Right Fit

Consider the all-important latex surgical glove. This article of clothing is, though fully functional and not particularly stylish, a necessary item in surgical theaters around the world. Suppose as a surgeon you were given a box of mismatched latex gloves to choose from before proceeding into the operating theater. A glove with four fingers obviously wouldn’t fit, causing you to have to smash a finger in with another if you were to put the glove on, while a glove with six fingers would be clumsy and would inevitably impede your hand’s ability to perform its surgical tasks. Suppose you were provided with one of those Dickensian half-fingered gloves? You’d only have half the coverage you needed leaving the other half of your fingers exposed. Or, what if you were given a mitten? Your range of motion would be hindered by a one-size-fits-all solution.

Imagine for a moment that your business is a surgeon’s hand and that your database is a surgical glove. Each of the five fingers represents a portion of your business operations. In order for your business to operate efficiently it requires a glove with five fingers to provide maximum coverage without restricting dexterity. Let’s unpack this analogy by looking at the different types of glove we have to choose from:

The Four-Fingered Glove

I’ve worked in companies that have a four fingered solution for a five finger problem. One critical component of their business is not supported by their database or CRM leaving them to have to invent stop-gap solutions that are less than robust. Perhaps as your business has grown over time you have taken on new endeavors that your old system just wasn’t designed to track. In order to accommodate the information surrounding these endeavors, you have found yourself repurposing a part of the database with your own special coding or rules to distinguish the new information type from what was originally intended. (Something along the line of all transactions after January 1st, 2010 with a transaction type of X, with the understanding that if the transaction value is Y then that means one thing, whereas if the value is Z, that means another, etc.)

The Six-Fingered Glove

Much like the four fingered database, the six fingered database is generally a result of change over time, where once you were tracking a certain type of information, you are no longer. These are often referred to as legacy databases and are the stuff of legend among database developers (not to mention they generally run on dated technology using often outdated programming languages and restrictive data structures). You can also buy your way into a brand-new six fingered database. Suppose you work in a particular industry and you’ve brought in all of the different vendors that have made a name for themselves designing databases for your particular niche. They show you all of their slick GUI’s and all of the amazing out of the box functionality of their systems. If you’re not careful, it’s really easy to buy too much database. Much of the time these vendors start by building a database solution for one institution and then re-purposing that solution and selling it to others. Not every institution does business the same way, even within the same industry. What was right for one institution may not be right for yours. Most vendors will customize their product for your particular needs, but at a price. Some customization is almost always necessary and is fairly standard practice. It is good though to have a firm understanding of how much customization will be required in one solution over another.

The Half-Fingered Glove

Sometimes, your database is just missing functionality outright. There are parts of your business that are not supported by your system that you find yourself tracking by other means. These are the Excel spreadsheets that we keep on the side, outside of our database, to track the information that our current database doesn’t have room for. I’ve seen this range from HR data to marketing and communications lists, to critical transaction lists.

Tailoring Your Database

Hopefully you get the idea by now – the optimal database solution is that which is tailored to your own areas of business, processes, and business rules. When you find yourself in need of a new database, before even reaching out to vendors, take the time to do a little requirement gathering. Think of this as the measurements a tailor would take when sizing you for a new suit. One of the best techniques for this is called conceptual modeling. There are several conceptual modeling methodologies out there, the simplest and best known is called Chen notation. (Vertableo gives a good introduction to diagramming with this notation.) I showed an example of this in a previous article. The idea is to identify all of the entities (proper nouns, i.e. people, places, things, and concepts) in your business and the relationships that exist between them. Below is a simple example of this followed by a more complex one I did for the University of Illinois for an advancement specific talent management database. (The Illinois example doesn't use conventional ovals for attributes, rather I've listed them on the side of each entity to save space.) Performing this exercise early before even contacting a vendor will give you a good idea of the critical components of your business, how they interact with each other, and the functionality you will need to require of any new system.

The good news is that database systems and applications are becoming more powerful, flexible, and integrated. With the advent of CRM (customer relationship management) vendors are thinking holistically about the complete life-cycle of the different types of relationships that you maintain with your customers and are designing for them. In fact, I see a not-too-distant future in which the technology will become available to where the non-expert will be able to quickly build, design, and deploy their own database applications much in the same way one might use WIX or WordPress to build a website today. This is all, of course, very exciting for analysts. The more we organize and maintain quality data about our business processes and relationships, the better able we are to understand, evaluate, and improve them.

So if you're in the market for a new database I hope this has been of some assistance. To help get you started I've compiled a list of questions that you might find useful to ask of any new vendor as you consider purchasing their database system. You don't need to be an expert to ask them, but your sales representative should be expert enough to give you simple and convincing answers to each of these; or at least enough information to where you can answer them for yourself. Happy hunting, and as I say to my students every semester; 'Keep calm, and SQL on!'

Questions You Should Ask Before Buying a New Database System

• What parts of my business are covered by the database? Which are not?
• Does the database support our current processes and workflows?
• Which of our processes will have to change if I purchase this database system without modifying it?
• What definitions, assumptions, and business rules will change if I purchase this database?
• How easily can the new system be modified to accommodate current and future changes to the way we conduct business?
• Is it easy to get data in? Is it easy to get data out?
• Does the database provide storage for all of the data we will need to support an analytics program and inform our decision making? (This question is relevant to both the database and your current data generating activities. If you discover you are missing data, you will need to find a way to generate it before you can store it.)
• Does the database store data in a way that is well structured and meaningful?
• Does the database accurately represent the relationships between entities that exist in the real world?