The dreaded question about questionnaire database

[foxtrot123]

Well, this question gets at the issue a little differently.

The normalizated structure for a typical questionnaire database has (at a minimum) these three tables:

tblQuestions
tblResponseOptions
tblActualResponses

Why is this structure not typically recommended for other types of databases that collect a lot of data related to an individual or entity (which is, well, pretty much every database out there). An example would be a contact database that collects each person's name, age, race, gender, family history, favorite pets, etc. You rarely see someone advise against creating a table like:

tblContacts
-----------
ContactID
FirstName
LastName
Gender
Race
etc.

Is the recommended questionnaire structure usually limited to questionnaire databases because of the usual need to calculate summary statistics, or to easily reuse the database structure for other surveys?

 

[John Big Booty]

You would seem to be trying to comparing Apples and Oranges here.

The nature of the data being capture in the two DB's is quite different. A questionnaire DB is capturing a large set of responses to a limited number of questions most of which have a set of predefined responses.

Whilst a contact DB is collecting a set of data for which only a small number of the questions (fields) can have predefined responses (Gender, title/salutation, city, postcode and state) the balance of the data in a contact DB can not so easily be predefined.

Therefore the two DB's will have different structures due to the nature of the data they are designed to capture.

 

[dportas]

Why is this structure not typically recommended for other types of databases that collect a lot of data related to an individual or entity (which is, well, pretty much every database out there). An example would be a contact database that collects each person's name, age, race, gender, family history, favorite pets, etc.

You are asking an excellent question. I challenge people with the same question whenever I see tables or columns with names like "Question" and "Response", which always makes me think something is "wrong".

A data model is a model for representing facts in a system. A questionnaire on the other hand is just one method of gathering such facts. To be most useful, the data model generally ought to represent the facts themselves, independently of the method used to gather the information.

So to take your contact database example, if the contact database was populated based on a questionnaire it would not really make much sense to have an Answer attribute which contained all the values for name, age, gender, etc. Such a design would obviously obscure the true model of the contact information and make it hard or impossible to use the correct data types and constraints for the data.

The "questionnaire data model" is really a type of EAV model. It is a compromise of convenience for the database designer because it reduces the effort required to design and maintain data models that accurately represent the information being captured. Ease of summary reporting is not generally a reason for it because the EAV representation frequently makes reporting much harder than in a more conventional model.

 

[gemma-the-husky]

what table layout do people normally end up with in a questionairre database?

short and flat (a spreadsheet)
ie Participant Q1 answer Q2 Answer Q3 answer etc

or long and thin
ie
Participant QuestionNumber Answer


I suspect not many people end up with the latter style, which is why it becomes a problem.

 

[foxtrot123]

what table layout do people normally end up with in a questionairre database?

short and flat (a spreadsheet)
ie Participant Q1 answer Q2 Answer Q3 answer etc

or long and thin
ie
Participant QuestionNumber Answer

I suspect not many people end up with the latter style, which is why it becomes a problem.

Despite my appreciation for normalization, the typical 3-table structure has generally failed me when building questionnaire databases. It has failed for two reasons.

First, the high degree of normalization severely limits the designer's ability to create a graphical user interface (GUI) that mirrors the layout of the original questionnaire. Studies in data entry and quality control all conclude that the data entry interface should look as close to the data collection tool as possible; it speeds manual data entry while reducing entry error. But this is almost impossible to do with questionnaires that contain multiple question types (e.g., integer, yes/no, multiple choice, memo, check all that apply), skip patterns, and other conditional logic. Almost all surveys in the research world have these features. I'm yet to see a normalized Access database that can effectively handle multiple question types in a streamlined GUI. (I've seen plenty of data models for complicated surveys, including some on this forum, but never an effective implementation.)

Second, I work in a research environment, and the analysis of questionnaire data is always done in a statistical program, like SPSS or SAS. In these programs, it is much easier to analyze the data when it is denormalized (i.e., converted to a flat file). For example, a question with a "check all that apply" option needs to have a separate field for each option, with a value of no/yes (or 0/1) each each. This structure, of course, is frowned upon in the database world, but it's exactly what statistical programs require.

So I'm undecided about the usefulness of the traditional data model for questionnaires. Until someone can master the GUI challenges (I've tried and failed!), I will probably continue to use the flat file approach when building questionnaire databases.

 

[Galaxiom]

First, the high degree of normalization severely limits the designer's ability to create a graphical user interface (GUI) that mirrors the layout of the original questionnaire.

But this is almost impossible to do with questionnaires that contain multiple question types (e.g., integer, yes/no, multiple choice, memo, check all that apply), skip patterns, and other conditional logic.

I'm yet to see a normalized Access database that can effectively handle multiple question types in a streamlined GUI.

Aything can be done in VBA, clever data modelling and cascading combos or list boxes. There are some good tricks too with hidden textboxes.

... statistical program, like SPSS or SAS. In these programs, it is much easier to analyze the data when it is denormalized (i.e., converted to a flat file).

Normalized data can be easily converted to any structure using a query and exported.

For example, a question with a "check all that apply" option needs to have a separate field for each option, with a value of no/yes (or 0/1) each each. This structure, of course, is frowned upon in the database world, but it's exactly what statistical programs require.

There is nothing wrong with this structure. Each answer is allocated a subquestion field value to separate the responses. The multiple answers in the table of answers would have a subquestion field too.

It is also possible to translate data structures in the form design.

For example a form might have a set of unbound checkboxes but could store the result in a single integer field similar to the technique used in in decimal colour encoding.

This is done by allocation a progression of values to the outcomes such that summing them gives a integer that represents a unique combination. The raw data is remarkably easy to read and manipulate across a population of records without regenerating the original checkboxes.

So I'm undecided about the usefulness of the traditional data model for questionnaires. Until someone can master the GUI challenges (I've tried and failed!), I will probably continue to use the flat file approach when building questionnaire databases.

Denormalized data is much harder to process. It can easily lead to errors.

I have no doubt that *any* paper interface can be reproduced. Even a single form could be morphed to change from page to page representing the paper form, turning on the controls applicable to the current page.

 

[gemma-the-husky]

It is important to not confuse data analysis with data presentation/representation.

I am convinced that the key to this (the key to any database project, to be honest) is getting properly normalised data tables

I really don't think a questionaire is a special case that needs this paradigm to be broken.


Once the data is mnormalised, data can be extracted simply and flexibly.


Although it may be that some forms and reports are slightly more awkward to develop, I am sure they CAN still be developed with any look and feel required, irrespective of the underlying data structure.

Although having said that, for interactive data entry purposes, it is not necessarily the best soulution to try to reproduce on a screen, exactly the same presentation that you would use on a printed form.

(eg, I have just designed a quotation system - which enables up to 50 items to be included on a quote - The quote is printed with two columns of 25 items - but for ENTRY purposes it is not feasible to present it to the user for ENTRY in this way - because there just isnt enough screen space - so the DATA ENTRY is achieved by a single column of 50 items, which also includes some additional internal fields which dont get printed)


The benefit of using a normalised structure is that you then have a generic questionairre database, that can be re-used without needing any modification.

 

[dportas]

A design with a key plus one column per attribute (one column per "answer") is already in 5NF if it doesn't contain any non-key dependencies or nulls. It doesn't need any modification to be normalized.

Putting all values in a single answer column has the obvious disadvantages I already mentioned: you can't use different data types (single type for Date of Birth and Gender for example) and it may be hard or impossible to add certain constraints that apply to the data (check that Date of Birth is a valid date for example).

 

[foxtrot123]

So to take your contact database example, if the contact database was populated based on a questionnaire it would not really make much sense to have an Answer attribute which contained all the values for name, age, gender, etc. Such a design would obviously obscure the true model of the contact information and make it hard or impossible to use the correct data types and constraints for the data.

I fully agree. Which is why I was surprised to see that Duane Hookom, in his popular At Your Survey database, used one Answer attribute: a text field called "Rspns" in tblResponses to store all types of answers (numeric, text, date, logical, etc.) He stores the data types and constraints for the answers in tblQuestions, using fields like "RspnsType", "RspnsLength," "LmtLst", and "RspnsValid," (for validation functions), and "QstnMask" (to store an input mask). He uses VBA in the data entry form to dynamically assign these constraints to each response item And he does this all in a single continuous form, which is impressive.

The single continuous form, though, severely limits the GUI. Hookom had to use a single control - like a combo box - for all answer types. (Read: check boxes, option groups, text and memo boxes not allowed.) Trying to seamless incorporate a variety of controls and other graphical elements like labels and objects in a continuous form is so difficult as to probably not be worth the effort, especially for a short survey. For example, could you implement this GUI in a continuous form?:



Hookom's approach to the data model and GUI differs from other approaches I've seen, which is to explicitly model the data types using, for example, a table like "QuestionTypes" (e.g., multiple choice, free text, Y/N, etc.). For example:



When people ask about developing a questionnaire database, most people on this and other forums seem to recommend this approach. (Because, like you suggested, it better reflects the true model.) But it brings its own set of challenges to the GUI.

Most implementations of this model rely on using a single form for each question (answer question, click next to go to next question, etc.) From a data entry standpoint, this is very inefficient. From a data quality standpoint, it suffers by not adhering at all to the visual design of the original data collection sheet, which the data entry user has propped up in front of him. He is now required to cognitively switch from one schema to the next, thus increasing the likelihood of data entry errors.

For years, properly normalized data models have been proposed to help users create a "proper" questionnaire survey database, but when the user starts asking questions about the GUI, or asks for an example of a GUI that can even closely mirror some basic design elements, the thread dies a slow death.

I agree with others that, with enough VBA and ingenuity, you can probably mirror most any visual design while adhering to at least 3rd normal form. But because no examples seem to exist, I wonder if the costs in time and labor outweigh the benefits.

 

[foxtrot123]

Aything can be done in VBA, clever data modelling and cascading combos or list boxes. There are some good tricks too with hidden textboxes.

I'm inclined to agree. But in years of answering "how do I create a questionnaire database" posts, no one has come forth with a real example. Plenty of models, but no GUIs that can replicate the typical questionnaire that has different types of questions.

Normalized data can be easily converted to any structure using a query and exported.

Very true. No argument here.

I have no doubt that *any* paper interface can be reproduced. Even a single form could be morphed to change from page to page representing the paper form, turning on the controls applicable to the current page.

Moving from page to page isn't the challenge in my experience. The challenge is moving from question type to question type within a single form. I've always suspected the answer is lots of subforms (one for each set of questions that can be logically grouped together by type while still approximating the paper interface). But I'm just not sure ...

 

[gemma-the-husky]

I fully agree. Which is why I was surprised to see that Duane Hookom, in his popular At Your Survey database, used one Answer attribute: a text field called "Rspns" in tblResponses to store all types of answers (numeric, text, date, logical, etc.) He stores the data types and constraints for the answers in tblQuestions, using fields like "RspnsType", "RspnsLength," "LmtLst", and "RspnsValid," (for validation functions), and "QstnMask" (to store an input mask). He uses VBA in the data entry form to dynamically assign these constraints to each response item And he does this all in a single continuous form, which is impressive.

The single continuous form, though, severely limits the GUI. Hookom had to use a single control - like a combo box - for all answer types. (Read: check boxes, option groups, text and memo boxes not allowed.) Trying to seamless incorporate a variety of controls and other graphical elements like labels and objects in a continuous form is so difficult as to probably not be worth the effort, especially for a short survey. For example, could you implement this GUI in a continuous form?:



Hookom's approach to the data model and GUI differs from other approaches I've seen, which is to explicitly model the data types using, for example, a table like "QuestionTypes" (e.g., multiple choice, free text, Y/N, etc.). For example:



When people ask about developing a questionnaire database, most people on this and other forums seem to recommend this approach. (Because, like you suggested, it better reflects the true model.) But it brings its own set of challenges to the GUI.

Most implementations of this model rely on using a single form for each question (answer question, click next to go to next question, etc.) From a data entry standpoint, this is very inefficient. From a data quality standpoint, it suffers by not adhering at all to the visual design of the original data collection sheet, which the data entry user has propped up in front of him. He is now required to cognitively switch from one schema to the next, thus increasing the likelihood of data entry errors.

For years, properly normalized data models have been proposed to help users create a "proper" questionnaire survey database, but when the user starts asking questions about the GUI, or asks for an example of a GUI that can even closely mirror some basic design elements, the thread dies a slow death.

I agree with others that, with enough VBA and ingenuity, you can probably mirror most any visual design while adhering to at least 3rd normal form. But because no examples seem to exist, I wonder if the costs in time and labor outweigh the benefits.

I think it depends exactly what you are trying to do

Are you trying to
a) enter details of a previously written questionaire into a database for analysis
b) do the questionaire IN the database itself

It still comes back to
1) representing the data in the database (for which the example you quoted may or may not be useful - personally i think overloading a single datra field for multiple answer types is possible not optimal) and
2) representing the data to the user

but in either case (ie the reason for the datbaase application), it is probably a mistake to think that a computer form should look at all like a written form, and it is definitely a mistake to think that it HAS to look like the written form.

-------------
I shouldnt think that its hard - its probably just that people design these things for their own use, and certainly wont give stuff like this away.


--------------
further - I am intrigued - I have downloaded the dbs you mention, and I will have a look at it.

 

[foxtrot123]

I think it depends exactly what you are trying to do

Are you trying to
a) enter details of a previously written questionaire into a database for analysis
b) do the questionaire IN the database itself

In my case, almost always a). But in both cases most Access experts recommend the similar, super-normalized (for lack of a better term) data model.

further - I am intrigued - I have downloaded the dbs you mention, and I will have a look at it.

To give you some ideas, I've attached two interesting approaches to improve the GUI of a questionnaire database. I got both from the Utter Access forum.

1. The first - "InsteadOfMultipleYesNoFields" - shows three examples of simulating "check all that apply" questions. I think simulating the look and feel of check boxes, which many clients prefer, has posed the most challenge. This example has some clever solutions.

2. The second - "FOFSurvey ..." - allows for three data types and corresponding controls (text, integer, and YN) in a continuous form. The designer has the right idea, but the implementation needs work. (When you click in each question, the appropriate control is made visible and the others are hidden, but the condition cascades across all questions.)

I also attached a sample survey I put together (word .doc), which I've been using to try to test out various data models and GUIs. I've had no success getting a GUI that can even approach what I see are basic visual and structural elements common to most surveys.

 

[gemma-the-husky]

foxtrot - just to go back to your very first post

Well, this question gets at the issue a little differently.

The normalizated structure for a typical questionnaire database has (at a minimum) these three tables:

tblQuestions
tblResponseOptions
tblActualResponses

Why is this structure not typically recommended for other types of databases that collect a lot of data related to an individual or entity (which is, well, pretty much every database out there). An example would be a contact database that collects each person's name, age, race, gender, family history, favorite pets, etc. You rarely see someone advise against creating a table like:

tblContacts
-----------
ContactID
FirstName
LastName
Gender
Race
etc.

Is the recommended questionnaire structure usually limited to questionnaire databases because of the usual need to calculate summary statistics, or to easily reuse the database structure for other surveys?

given a 3 table structure

tblquestions (questionID, quesdtionText)
tblpossibleresponses(questionid, come back to the details ....)
responses(questionid, response)

I do not see how is this different to any other database - this is completely minimal and normalised. The only issues seems to be

a) how to offer/store the potential question responses, because they are/may be of different types
b) how to record the responses, which again are/may be of different types

it seems to me that you WOULD have EAXCTLY the same problem with the contacts database IF you could ONLY store ONE of the factors of name, age, race, gender, family history, favorite pets - for the same reason that the data types may be different for each potential item.

 

[foxtrot123]

foxtrot - just to go back to your very first post

given a 3 table structure

tblquestions (questionID, quesdtionText)
tblpossibleresponses(questionid, come back to the details ....)
responses(questionid, response)

I do not see how is this different to any other database - this is completely minimal and normalised.

The typical contact database would have most attributes hardcoded as field names:

tblContacts
-----------
ContactID
FirstName
LastName
Age
Gender
NoChildren
ContactYN
etc.

The "questionnaire" version would structure it this way:

tblAttributes (~ to tblQuestions)
------------
AttributeID
Attribute (e.g., "First Name", "Last Name", "Age", "Gender", "Number of Children", "Contact this person?")

tblPossibleResponses (stores responses only for questions that have a predetermined list)
--------------------
PossibleResponseID
AttributeID (FK to tblAttributes)
PossibleResponse (e.g., "<18" "18-25", etc. ; "Male", "Female" ; "0", "1", "2", "3 or More" ; "Yes", "No", etc.)

tblActualResponses
-------------------
ResponseID
AttributeID (FK to tblAttributes)
Response (e.g., "John", "Smith", "18-25", "Male", "1", "Yes")

name, age, race, gender, family history, favorite pets[/b] - for the same reason that the data types may be different for each potential item.

If you "questionnaire-rized" the contacts database, yes - you would have the same challenge storing different data types and implementing the GUI.

 

[dfenton]

If you control design of the paper form, I'd say it should be designed to reflect the UI of the data entry application. If you don't have control of the form, then you'll always be chasing a moving target, and I say model the survey and not the physical tool used to collect the responses.

As the iPad type of device gradually gets thinner and thinner and we enventually have computers that have the form factor of a piece of paper (See 2001: A Space Odyssey, or current TV show Caprica), this will change.

Access's form model is not well-adapted to that kind of thing. An HTML form is easier to use to replicate a paper form.

As to continuous forms, the problem mentioned above is exactly why I don't use continuous forms for editing data except in a few very limited cases. In general, I use a read-only list form (either a listbox or a datasheet/continous form) and a detail form. The A2007 split form is an implementation that makes this kind of thing pretty easy, in fact, and allows you to set the list to being uneditable and allowing edits only in the detail, so it makes implementing this kind of thing easier than it used to be.

When I've created survey databases I've used a wizard interface to collect the data, with <<Previous/Next>> buttons that load the choices dynamically for each question based on its definition (including showing/hiding the appropriate controls for controlling the entry of data). I've also helped design the data collection forms so that the interface and the form are easy to use together. But I don't replicate the exact layout of the form, because that seems to me to be confusing two user interfaces with each other. Yes, there are things you can do in terms of organization that make it easy to use the two together, but slavishly replicating the paper form in the database application is not one of them, in my opinion.

 

[gemma-the-husky]

If you control design of the paper form, I'd say it should be designed to reflect the UI of the data entry application. If you don't have control of the form, then you'll always be chasing a moving target, and I say model the survey and not the physical tool used to collect the responses.

As the iPad type of device gradually gets thinner and thinner and we enventually have computers that have the form factor of a piece of paper (See 2001: A Space Odyssey, or current TV show Caprica), this will change.

Access's form model is not well-adapted to that kind of thing. An HTML form is easier to use to replicate a paper form.

As to continuous forms, the problem mentioned above is exactly why I don't use continuous forms for editing data except in a few very limited cases. In general, I use a read-only list form (either a listbox or a datasheet/continous form) and a detail form. The A2007 split form is an implementation that makes this kind of thing pretty easy, in fact, and allows you to set the list to being uneditable and allowing edits only in the detail, so it makes implementing this kind of thing easier than it used to be.

When I've created survey databases I've used a wizard interface to collect the data, with <<Previous/Next>> buttons that load the choices dynamically for each question based on its definition (including showing/hiding the appropriate controls for controlling the entry of data). I've also helped design the data collection forms so that the interface and the form are easy to use together. But I don't replicate the exact layout of the form, because that seems to me to be confusing two user interfaces with each other. Yes, there are things you can do in terms of organization that make it easy to use the two together, but slavishly replicating the paper form in the database application is not one of them, in my opinion.

David

I couldnt agree more - i've just gone back and highlighted a simlar point I made in posting 5 in this thread. I doubt if a questionaire is any more difficult to do than any other [complex] database, but the underlying structure needs some careful thought.

 

[foxtrot123]

If you control design of the paper form, I'd say it should be designed to reflect the UI of the data entry application. If you don't have control of the form, then you'll always be chasing a moving target, and I say model the survey and not the physical tool used to collect the responses.

Often database developers do not have control of the paper form. In my case, I am usually contracted to develop a data entry platform for a survey project already completed. The client has 1,000 completed surveys and they want to enter them in a reliable, quality-controlled environment.

But even if I were consulted at the start, and had a say in designing the paper form, I would argue that the paper form should be designed to reflect best practices in visual design for questionnaires. In fact, I would argue the same for designing an electronic data entry form, like in Access, as well.

Dillman et al. (2007) provide a good review of these best practices, many of which have been used to change how questions and instructions on the Census form are presented. The result has been more reliable census data.

Just recently, the Commerce Department’s National Institute for Standards and Technology (NIST) is trying to develop usability (i.e., ease of use) standards to help improve the data entry interface of electronic medical record systems. Many of the current interfaces are so poorly designed that the amount of user error, and consequently data quality, is significant. The NIST standards are probably going to suggest guidelines such as font sizes and styles, use of spacing, using visual design elements to emphasize important elements and demphasize others, and so on.

I think we would agree that an HTML data entry interface could incorporate these standards much easier than an Access interface. But I'm just not ready to resign myself to this.

These visual elements are important. A growing body of research has shown that manipulating various aspects of the visual design and layout of survey questions influence how people respond. This is true in both paper and web-based surveys. As a survey researcher, I am very concerned about item-nonresponse, as well as errors of commission and omission. So I am pretty meticulous when developing paper questionnaires, and I do so only with the user in mind - not the data entry interface.

 

[dfenton]

The only way I can think to do the paper form replication is with an unbound form. It might be possible to get repeating rows in a subform by embedding a form in the subform, set the first-level subform to be datasheet, and the second level to be single form. This would mean you'd avoid the problems that come with continuous forms.

But, again, this is only a workaround.

I think it's a goal guaranteed to be missed, as the paradigm for Access forms doesn't fit the conventions of paper survey forms.

 

[gemma-the-husky]

Often database developers do not have control of the paper form. In my case, I am usually contracted to develop a data entry platform for a survey project already completed. The client has 1,000 completed surveys and they want to enter them in a reliable, quality-controlled environment.

But even if I were consulted at the start, and had a say in designing the paper form, I would argue that the paper form should be designed to reflect best practices in visual design for questionnaires. In fact, I would argue the same for designing an electronic data entry form, like in Access, as well.

Dillman et al. (2007) provide a good review of these best practices, many of which have been used to change how questions and instructions on the Census form are presented. The result has been more reliable census data.

Just recently, the Commerce Department’s National Institute for Standards and Technology (NIST) is trying to develop usability (i.e., ease of use) standards to help improve the data entry interface of electronic medical record systems. Many of the current interfaces are so poorly designed that the amount of user error, and consequently data quality, is significant. The NIST standards are probably going to suggest guidelines such as font sizes and styles, use of spacing, using visual design elements to emphasize important elements and demphasize others, and so on.

I think we would agree that an HTML data entry interface could incorporate these standards much easier than an Access interface. But I'm just not ready to resign myself to this.

These visual elements are important. A growing body of research has shown that manipulating various aspects of the visual design and layout of survey questions influence how people respond. This is true in both paper and web-based surveys. As a survey researcher, I am very concerned about item-nonresponse, as well as errors of commission and omission. So I am pretty meticulous when developing paper questionnaires, and I do so only with the user in mind - not the data entry interface.

I may be talking rubbish here, as I haven't ever tried to design a questionaire. But it MUST be plain wrong to assume that a debrief mechanism must look like the questionairre. Foxtrot, can I ask how expert are you in database development? You say you do a lot of work in questionaire capture mechanisms, so do you present the capture mechanism to resemble the original questionairre? Why would you do that?

You see, database developers REALLY DO NOT need to bother about the PAPER form. They do need to be bothered about how the responses are debriefed into the database. (on the other hand, If the questions are presented via the app, then obviously they do need to be involved)


So, Lets say the questionairre consists of 100 multiple choices, where the answer can be a number in the range 1 to 10, or N/A, or some text

-----------
So when the debriefer inputs the questionairre into the database, why would he even need to see the questions themselves

All he needs to see is a 100 boxes, in which he can enter the appropriate value.

You could even do this by entering the answers directly onto 100 rows of a spreadsheet, and then importing the spreadsheet into the database.


It would also be nice to get some sort of hash-total on the input form, to control/prove the input - although I can see that this isnt straightforward in many cases.

-----------
what he does need to do (maybe ALL he needs to do, if you like) is to consider the structure in which the answers are finally stored, so that the questionairre analysis can generate meaningful data. Clearly, this analyis is completely independent of the physical presentation of the questionaire.

 

[foxtrot123]

But it MUST be plain wrong to assume that a debrief mechanism must look like the questionairre. Foxtrot, can I ask how expert are you in database development?

I would say I'm fairly knowledgeable regarding database development. I have probably built about 100 databases, most designed to handle data entry related to research studies, either directly in the field (i.e., using a laptop in real-time) or from data collected on paper forms (e.g., questionnaires, medical chart audit sheets). I've also been doing survey research and questionnaire development for about 10 years. I'm also MS Certified in Access.

... You see, database developers REALLY DO NOT need to bother about the PAPER form. They do need to be bothered about how the responses are debriefed into the database. (on the other hand, If the questions are presented via the app, then obviously they do need to be involved)

So, Lets say the questionairre consists of 100 multiple choices, where the answer can be a number in the range 1 to 10, or N/A, or some text

-----------
So when the debriefer inputs the questionairre into the database, why would he even need to see the questions themselves

All he needs to see is a 100 boxes, in which he can enter the appropriate value.

I would agree that making the two interfaces look similar isn't as critical for simple questionnaires, such as one with 100 questions that all have the same response format. But for questionnaires with varying types of response formats, questions with sub-questions, and varying instructions and skip logic, switching back and forth between two different visual schema requires a larger cognitive leap, which can decrease speed and increase error. This is true even when you've added features to help with navigation, like using tab to move across controls, setting combo boxes to drop down automatically, and using the number pad to select answers.

In my 10 years of working in data entry/survey research environments, data entry always goes much quicker and with fewer errors when the data entry interface resembles the paper interface (unless the paper interface is horrible to begin with).

You could even do this by entering the answers directly onto 100 rows of a spreadsheet, and then importing the spreadsheet into the database.

A spreadsheet *may* be okay for a simple questionnaire. But even then, I'd still want to enforce range checks, limit to list constraints, and help automate skip logic conditions. Access is much better at this than spreadsheet software. Also, if the questionnaire includes responses best handled in a one-to-many structure (like "Please list your favorite colors"), the spreadsheet would be a terrible data entry platform.

And to your earlier point ...

(on the other hand, If the questions are presented via the app, then obviously they do need to be involved)

... perhaps this is a the best argument for trying to improve the GUI of the typical questionnaire date entry interface (e.g., something more flexible than the continuous form approach). More and more people have laptops these days, and my clients are increasingly asking for a database they can take into the field to do data entry in real-time.