5 Replies Latest reply on May 12, 2011 2:56 PM by philmodjunk

    setting up a database to analyze survey results

    KristineGentry

      Title

      setting up a database to analyze survey results

      Post

      I am trying to set up a database to analyze the results of a survey that includes both open and closed ended questions.  I know I need a table for the survey questions, respondents, and answers.  I will also be reviewing the answers to the open ended questions and coding them.  Should the coded responses be on a separate table?

      Also, the only data I have on the respondents is there userID number.  I do not have any data before conducting the survey about the respondents that will be useful for the survey.  Is there anything else I need in the respondent table other than the userID number?  And if there is no other data in that table, do I really need a separate table for respondents?

      Thanks!

      Kristine

        • 1. Re: setting up a database to analyze survey results
          philmodjunk

          I think some of those questions can't really be answered by us as we don't fully know what you want to do with your survery results.

          A table for respondants, even if the only field is a UserID may still be useful to you. It could make it easier to review all the results for a given individual, it could help you tell if the survey from that individual is complete. Is it necessary? Probably not but only you know what specific kinds of analysis need to be performed on your results.

          What "coded responses" are these? Do you mean that you have a list of codes and a response description for each and you need to review the open ended responses and use this table to select a code for each such response? That sounds like you'll need a table for the coded response list.

           

          • 2. Re: setting up a database to analyze survey results
            KristineGentry

            The database will be used to import survey responses (not for actually taking the survey).  Then we will read and code the open-ended responses.  On the open-ended questions, we will actually need to have the option of selecting multiple codes per response.  Some of the codes will be pregenerated, but we will also need to edit as we read through the responses.

            For instance, we ask respondents to describe X.  Then we need a field where we choose a category from a drop down list for that description.  We will also have several other fields where we can select characteristics used to describe X (and add to the drop down list when necessary).  So, a description could have one field coded if it's a very short description, or it can have 9 fields coded if it is a long description with a lot of characteristics.  The goal is to be able to run some analysis on the number of times certain descriptions show up across any of the 9 fields.

            So I'm wondering if the coded responses should go in a separate table?  I would like to also track who is creating the codes automatically.  I'm thinking the answer is yes, but wanted to double check.

            Thanks for the answer on respondents. That makes sense and could be helpful.

            Kristine

            • 3. Re: setting up a database to analyze survey results
              philmodjunk

              If you have more than one response code to assign to a single response, then a related table will allow you to count the responses and this will be difficult to do if you do not.

              • 4. Re: setting up a database to analyze survey results
                KristineGentry

                I have 4 questions whose responses will be set up this way.  Should I do a separate table for the coding of each question? Or can I have one table that has all the codes in it?

                • 5. Re: setting up a database to analyze survey results
                  philmodjunk

                  I would think you can use a single table. You can use a portal to log the multiple codes from a layout based on the response records. Since the relationship will auto-enter the ResponseID, you'll be able to tell which Code record goes with which response so that you can break things down by response or lump them all together simply by how you do finds and sorts on this unified table.