The tables would be (choose your own naming convention... you don't have to agree with mine): EXAM, QUESTION, ANSWER, and STUDENT, STUDENT_EXAM, QUESTION_ANSWER.

• EXAM would hold one row for each exam that was given.
• QUESTION would hold one row for each question on each exam; it would hold a foreign-key to EXAM
• ANSWER would hold a row for each multiple choice answer for the various questions; it would hold a foreign-key to QUESTION
• STUDENT would hold a row for each student
• STUDENT_EXAM would hold a row for each student, for each exam; it would hold a foreign-key to both STUDENT and to EXAM
• QUESTION_ANSWER would hold one row for each QUESTION on each STUDENT_EXAM; it would hold foreign-keys to STUDENT_EXAM, to ANSWER, and to QUESTION (the foreign-key to QUESTION might be somewhat redundant (since you could tell which QUESTION the ANSWER was for) but only if it were a multiple-choice question and the student did not leave the answer blank... and your data-model might not want to enforce that constraint)

Basically, EXAM, QUESTION and ANSWER represent the abstract exam... a template for each possible student exam. The real data of interest ends up residing in QUESTION_ANSWER... this is where you ultimately say that student "Fred", on exam 3, answered "c" to question 17.

Anyway, if that is a good start for you, then good luck... if it zoomed right over your head, then you need to read yourself up a little bit on relational databases. Then read this again.

Update:
jdtoronto's reply hadn't been posted yet, when I started writing my reply... which is somewhat redundant of his (sorry, JD... typing lag).

Anyway, just want to avoid confusion: the table-names he (or she?) uses do not mean the same things as mine do. Where he says EXAM, I say STUDENT_EXAM, and where he says ANSWER, I say QUESTION_ANSWER. Maybe I would have been more clear if I had said "POSSIBLE_ANSWER and ANSWER" as opposed to "ANSWER and QUESTION_ANSWER" (respectively)... oh, well.