I del 1 i denne artikelserie diskuterede vi et grundlæggende design for en online undersøgelse. I konklusionen på den artikel nævnte jeg, at del 2 ville dække mere avancerede funktioner til vores undersøgelse, såsom:
- Forskellige typer spørgsmål såsom multiple choice-spørgsmål
- Betinget rækkefølge af spørgsmål i en undersøgelse eller med andre ord muligheden for en betinget vej gennem undersøgelsen
- Administration af undersøgelserne
- Rapporter og analyse
Lad os starte med at udvide funktionaliteten til at understøtte forskellige typer spørgsmål.
Spørgsmålstyper
I del 1 af denne serie af artikler brugte vi kun åbne spørgsmål, der bestod af et spørgsmål og et svar. I denne artikel vil vi definere forskellige typer spørgsmål såsom polære (ja-nej) spørgsmål og flervalgsspørgsmål . Hvert spørgsmål vil være knyttet til en type. For polære spørgsmål vil vi kun tillade ja/nej som svar, men i fremtiden kan vi tillade variationer som sand/falsk. Spørgsmål, som ikke er åbne, vil have mulige svar, som respondenten kan vælge imellem.
I fremtiden vil vi tilføje spørgsmål, der kræver et bedømt svar. For eksempel, "Hvor meget kan du lide databasedesign; rate mellem 1 og 100 (hvor 1 indikerer, at du kan lide det meget lidt, og 100 indikerer, at du kan lide det utroligt)?"
Enheder og relationer
For de forskellige typer spørgsmål i undersøgelsen vil jeg udvide området "spørgsmål" med typer og svarvalg.
Ideelt set vil jeg gerne lave en fremmednøgle mellem de faktiske svar og de mulige svar for multiple choice-spørgsmål (response_choice) for at sikre dataintegritet. Dette ville fungere, hvis alle spørgsmål havde svarvalg, og åbne spørgsmål ikke var tilladt. Da jeg har brug for at understøtte åbne spørgsmål, bliver jeg nødt til at sikre integriteten af svarene i applikationskoden.
Formelt design
Vi er nødt til at udvide den ERD, der blev oprettet i del 1 af denne artikelserie. Som før vil jeg bruge Vertabelo, en online database modeler. Hvis du ikke har en Vertabelo-konto endnu, kan du tilmelde dig en gratis prøveperiode her.
Jeg vil komme med en kommentar; du vil opdage, at jeg generelt bruger runde tal som 100 eller 1000 til at definere længden af varchar-felter; Jeg foreslår ikke, at disse nødvendigvis er den passende størrelse, men snarere bruger jeg dette som en stenografi i stedet for at lade længden være udefineret. Når du bruger denne model, bedes du tilpasse længderne til dine særlige krav. Vil du for eksempel tillade en respondent at indtaste et meget, meget langt svar på et åbent spørgsmål - eller vil du begrænse dem til, lad os sige, 1000 tegn? Dette kan afhænge af det program, du bygger til at bruge databasen, da det kan have begrænsninger på feltlængder.
Jeg tilføjer en question_type-tabel, der er knyttet til spørgsmålet:disse kan have navnet "åbent", "ja-nej", "multiple choice" og i fremtiden "rating." For multiple choice-spørgsmål vil hvert spørgsmål have response_choices at vælge imellem.
Du kunne endda bruge dette til at implementere polære spørgsmål, men jeg synes, det er overkill. En anden løsning ville være at linke response_valg til spørgsmålstype, så spørgsmålstype rækken “ja-nej” ville blive linket til svarvalg rækkerne “Ja” og “Nej”, men igen, det føler jeg ikke er nødvendigt – men du kan evt. du ønsker flersprogede muligheder. Du vil derefter inkludere et felt for respondentens sprog i response_choice-tabellen eller administrere internationalisering på brugergrænsefladen.
Jeg har farvelagt tabellerne oprettet i del 1 i gul og de nyligt tilføjede tabeller i orange , så det er nemmere at se tilføjelserne.
Konklusion
Nu er vi begyndt at implementere de forbedringer, som blev diskuteret i del 1 af denne artikelserie.
I den næste artikel vil jeg tilføje mere støtte til følgende funktioner:
- Betinget rækkefølge af spørgsmål i en undersøgelse
- Administration af undersøgelserne
- Rapporter og analyser