Many people enter survey data (or data from chart reviews) directly into Excel or SPSS, or worse: directly into an Access table instead of an Access form. This is spreadsheet doom! Entering data directly into a spreadsheet is fraught with problems: it yields higher rates of data entry errors and data anomalies, many of which you won’t uncover until you start to analyze the data and find yourself wondering why Larry Smith’s survey was entered twice; why some zip codes have 3 digits and some have letters; and why the female gender has been entered four different ways: “Female”, “F”, “girl”, and “Beyonce.” It’s also very confusing to have to figure out how someone who answered, “No, I didn’t attend the orientation” was somehow able to answer in great detail a follow-up question about what they liked most about the orientation – the orientation that they supposedly didn’t attend.

These errors will add to your project hours of tedious data cleaning and investigating. If you’re doing both the data entry and data analysis, you have only yourself to blame. But if someone else is doing the analysis, don’t be surprised if they stop responding to your emails when you ask for their help on another project. Save yourself the headaches by making a great Access database from the start.

I’ve split this tutorial into two parts:

• Part I (which you’re reading now) introduces you to the sample survey project, the Access environment, and shows you how to set up your tables in Access. (6 videos)
• Part II shows you how to build the data entry form, which is based on the tables you built earlier. (10 videos)

Video 1: A Quick Look at the Database you’ll Build

Click here to view the embedded video.

Video 2: A Quick Look at the Sample Survey

Click here to view the embedded video.

Video 3: Turn Your Survey into a Codebook (the Blueprint for your Database)

Click here to view the embedded video.

Video 4: Opening Access and Getting Started

Click here to view the embedded video.

Video 5: Create a “Lookup Table” to Store the Answer Choices

The method I teach here for setting up your tables differs from the method most database experts would recommend. My approach is very simplified, and requires you to build only two tables: one table to store all of the answer options to your multiple choice questions (e.g., “Yes,” “No,” “Strongly Disagree,” “Disagree,” etc.) and one table to store the actual responses you collect from people who filled out your surveys. (An even more simplified version would involve only one table that holds everything.)

There are pros and cons to this simplified approach:

CONS

It will be difficult to use Access’s built-in query and report features to calculate and show summary statistics of your data (e.g., frequencies and percentages to show how everyone answered each question.) This is because your data – when structured in the way I teach in this tutorial – will not be fully “normalized.” Creating a non-normal structure means that you’re cramming into one or two tables many different categories of data: data about your survey questions (their wording, their numbering, etc.); data about answer choices on your survey (Yes/No, Strongly Disagree … Strongly Agree, etc.); data about your respondents (name, sex, race, etc.); and data on the actual responses people gave to each question (e.g., how many people answer “Yes” to question 7, etc.). A fully normalized survey database would put each of these categories of data into its own table, like so:

• tblQuestions: stores information about the survey questions (with fields like QuestionID, QuestionNumber, QuestionText, etc.)
• tblAnswerChoices: stores information about the response options for each multiple choice question (with fields like QuestionID, Choice [e.g., "Yes," "No," "Strongly Agree," "Agree," etc..)
• tblRespondents: stores information on the respondents (with fields like RespondentID, LastName, Sex, Race, etc.)
• tblResponses: stores the actual responses you collect (with fields like ResponseID, QuestionID, ResponseID, Response, etc.)

These four tables would then be connected to each other, like so:

Each of these tables is called - in database speak - a "relation," which is why Access is a type of "relational database" management system. In a normalized database, each table contains only data on a single topic (one table for data about survey questions; one table for data about respondents, etc.). The tables are then linked to each other on a common field or "key" to form relationships. Take a look at tblQuestions and tblResponses. See the line connecting them? Notice it has a "1" next to tblQuestions and an infinity sign next to tblResponses. This tells us that there is a "one-to-many relationship" between these two tables, such that "one" question can have "many" responses.

When each category of data is stored in its own table, it's much easier to create Access queries to calculate statistics about each category of data. Or you can combine queries to get statistics about multiple categories of data, like a report that shows how males vs. females (data from tblRespondents) answered (data from tblResponses) each question (data from tblResponses). Normalization is a big concept and entire books are dedicated to it. For a quick but excellent overview of normalization and relational database concepts, check out Databases: Normalizing Access Data and Databases: Access Terminology and Relational Database Concepts.

Another downside to this simplified approach is that you can't reuse your survey database to manage other (different) surveys you might collect data on in the future. In a normalized survey database, the characteristics of the survey are not hard coded into the table or forms.

It's the difference between this non-normal structure ...

... and this normalized one:

When we view the normalized table in Datasheet view, we see this is where the characteristics of the survey have been specified. That's right! The features of the survey are entered in rows, as real, dynamic data:

When you're done with the survey project, you can easily delete the data and keep the table structures (and probably the forms) intact for use with another survey. (Or, add a 5th table to the relationships picture earlier - a table called tblSurveys (with fields like SurveyID, SurveyName, SurveyAuthor) - and link it (one-to-many) to tblQuestions (add a new field in tblQuestions called SurveyID). Vaoila! You have a single Access database you can use to manage all of your survey projects.

So with all the advantages you get from a normalized structure, why would I recommend a non-normal, simplified approach?

PROS

Statistical programs (like SPSS, SAS, etc.) hate normalized data. If you plan to export your data to a statistical program for analysis, you'll have to spend a lot of time converting your normalized data (which, for one, is spread across four tables) into a non-normal structure, like a single flat file. Look at the picture above (the one in Datasheet view). If you export that to SPSS, it will give you a dataset with variables called QuestionID, QuestionNumber, etc., and cases containing data about the survey questions. Um ... that's not what you want. Instead you need a dataset with variables (i.e., columns) like q1, q2, q3, and so on, with cases that represent each respondent's answers to the survey. In a normalized Access database, your variables are stored as live data, in rows; in SPSS, your variables are hard coded, one per column, and their properties are stored in the Variable view window. With a normalized structure, not only will you need to merge the four different tables into one, but you will also need to somehow transpose the columns and rows so that you end up with something SPSS can make sense of. Ugh.

Another advantage of my simplified approach is that it gives you great flexibility when creating the data entry form(s), also called the graphical user interface (or GUI, pronounced "gooey"). The closer the GUI looks like the original survey, the faster (and more error-free) the data entry will go. In the GUI of a normalized survey database, you most likely have to present the survey questions as one long, single column, continuous list. Have fun with all that vertical scrolling. You won't have much flexibility with making an eye-pleasing, multi-column, multi-tab, bells-and-whistles GUI like the one you'll learn in Part II of this tutorial.

Again, it's the difference between a GUI based on a non-normalized table structure:

... and a GUI based on a normalized one (this one is from a different project):

Both GUIs "work," but with the first one I was able to take more liberties with the design and implement better validation rules.

A final advantage of the simplified approach is that it's easier to add to your form custom validation rules, automatic skip pattern logic, and so on. Creating conditional codes on a normalized GUI form like above is tricky. (e.g., 'If user selects "Other" for Question1, enable Question1_specify; otherwise, disable Question1_specify and jump to Question 2.). On either type of form, you have to write code to add such rules, but it's much easier to do this in a GUI based on a non-normalized structure.

So the choice of whether to normalize or not is up to you. As you can see, it depends on your needs, the project, and, most importantly, whether you plan to analyze you data in Access or a statistical program. I've built lots of survey databases and have always found the non-normalized approach much better suited to my needs. Of course, this doesn't stop the Access purists from shaking their fists at me.

Now back to the videos!

Video 5: Create a "Lookup Table" to Store the Answer Choices

Click here to view the embedded video.

Video 6: Create a Table to Store the Survey Questions and the Data you Collect

Click here to view the embedded video.

Once the tables are done, you’re ready to build your form. So when you’re ready, check out Create a Survey Database in Access: Part II.

Video 1: Starting a new form; Design View; dragging and dropping fields onto your form; “labels” vs “controls”; moving controls and labels; deleting, editing, and adding labels; the “Toolbox”

Click here to view the embedded video.

Video 2: Form View; hiding the default record selector, dividing line, and scroll bars; saving and naming form

Click here to view the embedded video.

Video 3: Adding more fields to the form; copying and pasting labels; using form grid to maintain a consistent layout

Click here to view the embedded video.

Video 4: Changing font; resizing controls & labels; grouping and deselecting controls; moving a group of controls closer to their labels by lengthening and resizing

Click here to view the embedded video.

Video 5: Updating your form and field list after making changes (e.g., properties, new fields, etc.) to the underlying table

Click here to view the embedded video.

Video 6: Adding some more labels; adding a hard return (CTRL+ENTER) inside a label so it goes on two lines; shrink excess form space

Click here to view the embedded video.

Video 7: Changing text alignment; changing width of drop down list; ensuring your data entry boxes are mapped to the correct field

Click here to view the embedded video.

Video 8: Add a soft gray line; changing the tab order

Click here to view the embedded video.

Video 9: Add a “Delete Record” button; brief view of Visual Basic, Access’ programming language

Click here to view the embedded video.

Video 10: Create rectangles, background colors, and section headings; Access’ weird ampersand (&) issue; changing the order of items in a drop down (i.e., combo) box; show more than 8 items in a drop down list

Click here to view the embedded video.