Most church staff and volunteers use their church management software every day without thinking about the technology under the hood. But a little knowledge can go a long way in making these tools easier to use and adapt. Understanding the fundamentals of relational databases—the way data is structured in these systems—can empower church workers to better navigate their software and even customize it to fit their ministry’s needs.
In the conversation below, Rob Davidson of Concordia Technology Solutions sits down with Rev. Bill Johnson, Chief Information Officer at Concordia Theological Seminary, Fort Wayne. Rev. Johnson discusses relational databases and how concepts like one-to-many relationships and data tables for things such as households, members, donations, and attendance are at the heart of church management software (like Church360° Members). Together, they explore why these technical ideas matter for everyday ministry work and how they can help church staff use their software more effectively.
DAVIDSON: Rev. Johnson, most church staff might not spend much time thinking about the database behind their church management software. Why does it matter how information is structured? Could you give us an example of how relational databases handle something basic, like household and member information, and why it’s set up that way?
JOHNSON: Great question. Most church management software really boils down to tracking a number of different objects—households, people, donations, events, even things like trees or church library books, if you wanted. Computers use databases to store information about these different objects in tables. So, as an example, we might have a table of households that looks something like this:
| Id | HouseholdName | Number of People | <bunch of other fields/columns> |
| 1 | Martin and Katie Luther Household | 2 | <Address, etc.> |
The fields in this table all relate to the Household—like its address and how many people are in it—but this alone doesn’t tell us much about Martin or Katie themselves. Because a Person is a different kind of object than a Household, we create a separate table for people:
| Id | HouseholdId | FirstName | LastName | <bunch of other fields/columns> |
| 1 | 1 | Martin | Luther | <Phone, email, etc.> |
| 2 | 1 | Katie | Luther | <Her phone, email, etc.> |
Here we keep all the information that relates to a specific person—names, phone, email, Baptism date, and so on—in one spot. But notice, if we wanted to send Katie a letter, there’s no address listed in the Person table. That address is stored with the Household, so we need to connect the two. That’s where the HouseholdId field comes in. By storing the household’s ID on each person who belongs to that household, we create a relationship in our database between these two objects. Every person can be linked to a household, and every household can have many people. In technical terms, this is a one-to-many relationship (one household, many people). The important part is seeing how the back end of the system connects these two objects together.
Now, you might ask: why not just store all this information in one big table? We could add an address column to the Person table and have everything in one place, right? Absolutely—but consider what happens when a family moves to a new address. If the address is listed on each individual person in the household, you would have to update every single person’s record with the new address. That’s a lot of extra work (and an easy way for data to become inconsistent if you miss someone). By keeping address data on the household record and using the relationships to link people to households, you only have to edit the single household entry. The change automatically applies to everyone in that household. In short, the relational design saves time and keeps your data cleaner whenever something like an address needs updating.
DAVIDSON: Churches also track offerings and donations in their management software. How are donations stored in the database, and why aren’t they just fields on a person’s profile? What’s the benefit of having a separate Donations table when tracking contributions over time?
JOHNSON: When it comes to donations, church software will store each gift as its own record in a Donations table (separate from the People records). For example, a Donations table might look like this:
| Id | DonorId | Amount | <bunch of other fields/columns> |
| 1 | 1 | 100.00 | <Payment method, date, etc.> |
Here, we’re once again using the relational aspect of the database to tie this donation to a particular donor (DonorId 1, which might correspond to Martin Luther in the People table). Keeping donation data in a separate table from the Person table makes a lot of sense. Remember, Martin can—and hopefully will—make more than one donation in his life. We need a way to record multiple donation entries that all still point back to Martin (and through Martin, connect to the Luther Household). By using a one-donor-to-many-donations structure, the database can store exactly what we need: any given person can have multiple donations associated with them over time.
If we tried to put donations as fields on Martin’s person record (for example, having fields like “Donation1,” “Donation2,” etc.), we’d quickly run out of room or end up with a very messy design, especially for generous members who give often. Instead, the separate Donations table allows the church to keep an ongoing list of contributions, each linked to the donor. This makes it easy to generate giving statements, track total contributions, and see giving history for each member without cluttering the core member profile with countless donation fields.
DAVIDSON: Let’s talk about attendance tracking. Say we want to record who attends each worship service. If one service has 200 people in attendance, how does the database manage that without duplicating the service entry 200 times? How does a relational model record which people showed up at which worship service?
JOHNSON: Excellent example. Consider a Worship Services table in your church management system. Each worship service (each instance of a Sunday or special service) would be one record in this table. It might look like this:
| Id | Date | Time | <bunch of other fields/columns> |
| 1 | 2/23/25 | 10:30 AM | <Other data as appropriate> |
Notice that in the Worship Services table, we don’t have a list of people attending or a direct link to a Person record. We wouldn’t want to enter the same service into the database 200 times just to connect 200 attendees to it—that would be a ton of duplicate data for no good reason. Instead, we define the relationships between tables. In this case, each person can attend many services, and each service has many people attending. That’s what we call a many-to-many relationship. Managing a many-to-many relationship requires a third table (often called a Join table) to connect the two sides. Let’s call it ServiceAttendance:
| Service Id | Person Id |
| 1 | 1 |
| 1 | 2 |
There’s not much to this table because its whole job is simply to sit at the intersection of the other two tables (People and Worship Services) and record the relationship. In our example above, we can clearly see that Service Id 1 (the 2/23/25 10:30 a.m. service) is linked to Person Id 1 (Martin) and Person Id 2 (Katie). This tells us that Martin and Katie were both in worship on that date. We did all of that without needing 200 separate rows for the service or having a gigantic list of attendee names stuck onto the service record.
In some cases, a join table like ServiceAttendance might include additional details—say, a checkbox for whether each person received Communion at that service or other attendance notes. But usually, it’s kept simple: just two columns (or a few) to connect the records. The benefit is huge: by structuring attendance as its own link table, the software can efficiently answer questions like “Who attended the 10:30 a.m. service on 2/23/25?” or “How many services has Martin attended this year?” without any duplication of the service or person data. It’s all about linking existing records together.
DAVIDSON: This is really insightful on a technical level. So what’s the takeaway for a church staff member? Why should pastors, administrators, or volunteers care about these behind-the-scenes relationships? How does knowing about tables and relationships actually help people use their church management software day to day?
JOHNSON: The big payoff in understanding the data structure is that it can make the software less confusing and more useful for you. In most software, especially church management systems, the user interface is designed after the data structure is figured out. In other words, the way the screens and menus are organized usually reflects how the data is organized under the hood. Knowing a little about those relationships can give you clues about where to find things and why the system works the way it does.
For example, if the software developers (programmers) built addresses into a separate table linked to households (a common design, especially if people might have seasonal addresses or multiple addresses), then chances are the user interface will have a distinct section or screen for managing addresses for a household. If you’re aware of that design, it makes sense why you might have to go to a specific Address area to update a family’s contact info, instead of just editing a person’s profile. Another example: if your system allows you to manage groups or ministries (like a youth group or an LWML circle), and you can add members to those groups, behind the scenes there’s probably a many-to-many relationship at work. The interface might have a multi-select dropdown or a checklist where you connect people to a group. Understanding that there’s a separate linking mechanism for groups and people helps you anticipate that you might need to go to a special Groups screen to manage membership, rather than expecting a simple checkbox on a person’s profile. In short, the interface is often built around these underlying tables and relationships.
By understanding the underlying data structure, the entire system becomes more transparent and easier to use. You won’t be as perplexed when the software makes you enter something a certain way, because you’ll recognize the database relationship guiding that process. Additionally, if your system allows for any customization—say you can add custom fields or even custom types of records—having a grasp of good database structure can help you configure those in a smart way. A well-planned database structure can be the difference between a system that works exactly how your church needs and a system that can’t quite capture the information you want. In ministry, we often say tools should serve the mission; understanding how your data is structured ensures the software is serving your church effectively, not causing frustration.
DAVIDSON: Thank you, Rev. Johnson. This has been a fascinating look under the hood of church management software. Your insights really help demystify those technical concepts and show why they matter for ministry. I’m sure church leaders and staff will find it much easier to work with their software knowing what’s going on behind the scenes.
Work with your membership database with ease with Church360° Members, our people-focused church management software.