Q & A
How do you build a good database?
Involve important stakeholders in the design and development of the database.
As a team, clarify your purpose and needs for using the database. List all the important data you want to keep tract of and all the important things you want to be able to accomplish using the database. Study what other faculty development units have already done.
Choose the right software. I highly recommend FileMaker Pro.
Hire a good database developer (or get the right training for someone on your staff). Make sure you find someone that will listen well and will help you accomplish your purposes.
Design the system completely on paper before beginning database development. This includes all the main tables, fields, and relationships. Sketch layouts of every screen on paper and make sure they work for everyone.
Use sound database principles as you develop the system.
As you work with the database developer, continually test the design to make sure it is going to satisfy your most important needs and allow flexibility for growth.
How can you find data for the database?
Import from the university database. The best way to collect extensive data about faculty is to pull the data from the university's central database systems. If the university can export the data to a file [e.g. a tab-separated format], you can import it into your database. You may need to make a case to the university for why this data is important to the work of the Center and assure them that the data will be kept secure confidential It took us a year to get this data.
Use data you have already collected. Format the data you have into an Excel spreadsheet and then import into your database. With FileMaker Pro you can import multiple Excel spreadsheets into the same database file.
Hire a student to input data. Get data from the phone directory, the Internet or any on-line or off-line source available at your university.
Input data as it is needed. This is the build-as-you-go strategy– simply input data into the database as it is needed. Don't worry about creating a comprehensive list, you'll always have the data you need at the time you need it.
Keep data up-to-date. Be sure to input all new faculty every year. When you get mail or email that is returned because the address is bad, get the right data and input it. Take the responsibility to enter correct data and update it when new data comes out.
What database software should you use?
Reasons to use FileMaker Pro (be sure to get the latest version)
- It is a powerful database software program.
- It can do anything needed by a faculty development center.
- It is built with both novices and advanced users in mind, so it is much easier to learn and to use than any comparable system, yet it will not unduly limit the advanced user.
- It is worth the price.
- It is cross-platform (both your Macintosh and PC users will love it)
Reasons to use Microsoft Access
- You already own the program and can't afford to buy FileMaker Pro (Access comes free with MS Office).
- No one in your unit will ever use the Macintosh to access the database (There is no Macintosh version of Access—though Mac users could use it if you develop it to be used over the Internet).
- You have (or can easily employ someone who has) expertise in using Access (it may be more difficult to find someone with FileMaker expertise on your campus).
Reasons to use Excel or a flat-file database system
- Your clientele is fewer than 100 people or your needs are very simple.
- You have very limited time and money to put into database development.
(Note: Excel is a spreadsheet program, not a database program, though it is often used as a database.)
Reasons to use a more sophisticated database or programming language to create a database from scratch
- You have oodles of time and money.
- Your expectations for what your system will be able to do are fairly modest.
(In short, this is probably not a good direction to go.)
What other tips and suggestions are useful?
Thoroughly design the structure of the database on paper before you begin database development. This was stated earlier, but this is probably the most important tip. Designing a database can be a complicated task, and you might be tempted to rush it. Don't. The time spent doing this is critical. Be sure to investigate what other faculty development units have done (e.g. Brigham Young University, The Ohio State University Faculty and TA Development, New Mexico State University Teaching Academy).
Concretely think through the "end products and processes" you want your database to do. Make sure your database design will be able to accomplish what you need.
Store data in the smallest useful unit possible. Don't store complete names into one field, divide them up into First Name and Last Name.
Do not use any meaningful data for your database "ID" or "key" fields. It is tempting to do, but never a good idea; always use random, unique, assigned numbers for the "ID" or "key" fields.
Create only one "participant" or "client" table. Don't create a totally new table for each type of activity you do; create one table, participant or client, and add as many fields to it as are needed to contain as many different types of data as you want. This way, it is easy to collect stats across programs and see everything any one participant has done. It also greatly simplifies the design and development of the database and provides better flexibility for a growing center.