Data Flow Diagrams show one thing... the flow of data. It has nothing to do with the equipment, pricing or anything specific to the implementation of systems. It is to show how data moves around the system. Where it might rest (in a database) or how it sends that data to another process (a priest accessing that record in the database) etc.
So think generally and the best way to approach it is to think of some input and how it is passed around the church and how that data might leave. Data can not simply "disappear" from the system nor can it sudden "appear" from within the system. These are known as blackholes and miracles respectively.
Lets run through a small example. The Jones family comes to church on Sunday and talks to the pastor. They tell him they wish to sign up for the church's softball game in March. The pastor then presents a form which the Jones fill out with their name, the fee, the positions they want to play etc. This is information coming into the system from outside the church (just like keyboard entry comes into the computer system). The pastor then takes that form and types it into an application on his computer where it then goes into a database. In the diagram you show data coming into the system and going to a database where it may rest for awhile.
March rolls around and the pastor is building the team. He reads the database and pulls the Jone's record out of the database and sends it to a process where he acts on that data to select who will get what positions on the team. He builds a team roster and then stores that information into a file which he stores on his computer. Later he accesses that file and prints it and posts it out on the church's community board. The community board might be another place it will rest for awhile. There the Jones and other families read it and can take the information with them for the game.
Here we have input, storing it into a database, pulled out and run through tasks to create a roster, then stored again in a file, accessed later and sent to the community board where from there it leaves the system in the way of refined information (an official team roster).
This is a very very basic look at a DFD scenario. Perhaps while in the database it is accessed by multiple other church officials and used to create a mailing list or attendance records etc. Data can flow in many different directions. But keep in mind that a process should always have the same number of inputs as outputs. You can't collect a person's name and then suddenly pull out their social security number to use in filing taxes. That would be a miracle instance for example.