gos, maybe it would be useful to take a step backwards and revisit your structure. Some issues that I see are that a responder can only respond to one survey (perhaps that's what you want), and that a person can have multiple responses to the same question, which seems a bit counterintuitive.
If you want to revisit your structure, the first step is to identify your "kernel entities". "Kernel entity" means basically "stuff you're going to keep track of". To, it looks like you have four kernel entities:
1. Surveys
2. Responders
3. Questions
4. Answers
The next step is to determine the relationships between these entities, and whether they are one to many or many to many. What kind of answers you have in your survey has some bearing on this. Is this a multiple choice or a written in answer type survey? If the former, you can have multiple answers for each question: a combination of correct and incorrect ones. If the latter, there will be only one answer per question and you can merge questions and answers into one entity.
For the purpose of this discussion, let's assume that you have at least some multiple choice answers in your survey. Let's also assume that a person can take more than one survey. These given, you actually have a direct relationship between responders and questions, and not responders and surveys. (If a "responder takes a survey", you have to look up the questions that are in that survey and present them to the user. You may keep a record of what surveys a user took, but that's outside of the scope of the mechanics of presenting the user with the survey questions. From a data storage standpoint, what survey a responder is taking is a separate issue from what questions he's answering.) Now the point about this is that each responder answers many questions, and each question is answered by many responders (we're assuming that the same responder can't take the same survey twice, by the way). So you need an associtive entitiy to resolve the many to many relationship between answers (note NOT questions) and responders. Let's call it Responses, since that's what they are. You will also need an associative entity for the
That given, we will implement our design with five tables:
1. Surveys
2. Responders
3. Questions
4. Answers
5. Responses
These tables will relate as follows:
1. Surveys 1 Questions *
2. Questions 1 Answers *
3. Answers 1 Responses *
4. Responders 1 Responses *
Ok, that's a first pass. If you like, see if you can find any requirements that this structure doesn't meet, and see if you can poke holes in my logic. (I always assume that there are plenty in the first pass!) Also, I'll let you work out what attributes go with each entity (i. e. what fields go in each table).
HTH
Bob