I den här sista artikeln i en serie i fyra delar slutför jag designen för en onlineundersökningsdatabas för att ge flexibilitet för flera undersökningar, återanvändning av frågor, flervalssvar, ordning av frågor, villkorliga hopp i undersökningen baserat på svar och kontroll över användarnas tillgång till undersökningar via grupper av undersökningsägare.
Introduktion
I avslutningen till del 3 av denna artikelserie nämnde jag att jag skulle lägga till mer avancerade funktioner i den här artikeln. Dessa avancerade funktioner är:
- administration av undersökningarna
- rapporter och analys
Som en påminnelse, här var modellen efter del 3:
Administration
Mitt mål i administrationen av undersökningar är att låta en undersökning och dess motsvarande information hanteras av en grupp. Så jag kommer att göra det möjligt för en administrativ användare att definiera grupper av användare som gemensamt kan underhålla en onlineundersökning och dess frågor. Ägaren av gruppen kan definiera vilka funktioner de andra användarna av gruppen kan utföra; Jeff kan till exempel ändra och ta bort undersökningar och frågor, men Joe kan bara visa undersökningar och frågor, men inte ändra eller ta bort dem.
En sak som du kanske märker är att användarna är åtskilda från respondenterna i undersökningen. Naturligtvis kan en användare också svara på en enkät, men jag skulle vilja hålla dem åtskilda så att jag kan kräva mindre information från en respondent än från en användare (jag har till exempel tagit bort lösenordsfältet från en respondent så att det är lättare för människor att svara på enkäten utan att skapa en inloggning/konto).
I grund och botten, för den här administrationen, kommer jag att skapa tabeller för grupper och användare, och de roller och motsvarande behörigheter eller åtgärder som är tillåtna. Detta möjliggör flexibilitet snarare än en hårdkodad länk mellan rollerna och de åtgärder som tillåts av varje roll. Naturligtvis måste motsvarande applikation byggas för att förstå vilken funktionalitet som tillåts av varje behörighet och måste anpassas när ny funktionalitet läggs till, men databasdesignen behöver inte ändras när funktionalitet läggs till – nya rader kommer att läggas till i tabell som länkar roller till behörigheter.
Du kanske också märker att jag har använt en udda längd för email kolumnen på user och respondent tabeller och ett udda värde för ip_address kolumnen för respondent; 254 är den maximala längden som en e-postadress kan vara enligt RFC-definitionerna, medan 45 är den maximala längden som en IPv6-adress (med IPv4-tunnling) kan vara.
Dessutom kommer jag att lägga till en länk från group tabellen till survey tabell från vilken länkar går till alla associerade tabeller (question_order , survey_response , conditional_order , question_type , response_choice ). På det sättet, när gruppen raderas, kan jag varna ägaren av gruppen att all motsvarande information kommer att raderas.
Jag föredrar detta tillvägagångssätt att länka tabelldata till något annat än den specifika användaren jämfört med att inte länka data till någonting. Om vi inte länkade data till någonting (varken grupp eller användare) som jag verkade göra i tidigare delar av den här artikelserien, då kommer vi att ha en utmaning att "städa bort" inaktuella data när en användare raderas från onlineundersökningen Ansökan. Genom att koppla det till det mer abstrakta begreppet "grupp" blir det möjligt för ägaren att omfördela äganderätten till gruppen och all motsvarande data (undersökningar, frågor, svar, etc.) till en annan medlem i gruppen om det behövs.
Formell design
Sedan utökar vi ERD som skapades i de andra delarna av denna artikelserie.
Jag har färgat tabellerna som skapades i del 1-artikeln i gult, färgat tabellerna som lagts till i del 2 i orange, färgat tabellerna som lagts till i del 3 i grönt och de nyligen tillagda tabellerna i ljusblått så att det är lättare att se tilläggen. Färg lades inte till i kolumnerna och främmande nycklar som lades till i den här sista artikeln, så du måste jämföra den nuvarande modellen med den föregående från del 3 för att se skillnaderna.
Rapporter och analys
Vi har tillräckligt med information som kan extraheras från tabellerna för att producera flera rapporter.
Till exempel, vilka frågor besvarades på ett visst sätt ("på undersökning 7, hur många gånger svarade respondenterna 'Ja' på fråga 10?"). Denna informationsnivå är förmodligen bra för grundläggande rapporter om enkätsvar.
Vi kan också extrahera hur lång tid det tog för respondenterna att svara på en viss undersökning ("på undersökning 5 var den genomsnittliga tiden som spenderades på undersökningen 13 minuter"); återigen, detta kan vara användbar information så att ägare av en undersökning kan justera undersökningsfrågor så att de inte kräver mer tid än vad en typisk respondent är villig att spendera eller vad undersökningsledaren har "lovat" till respondenterna (t.ex. "den här undersökningen" bör ta mellan 5 och 10 minuter”). Jag vet att när någon säger till mig att jag borde vara klar på mindre än 10 minuter och jag fortfarande plöjer igenom frågor 15 minuter senare, då blir jag arg och jag är i allmänhet ovillig att svara på en annan enkät från dem.
Baserat på respondenternas IP-adresser skulle vi kunna göra en omvänd sökning för att få en ungefärlig uppfattning om var respondenterna kommer ifrån eller åtminstone var deras IP-adress verkar vara ifrån när de svarade. Var medveten om att denna information inte är helt tillförlitlig eftersom människor kan ansluta via VPN eller andra mekanismer som dissocierar deras IP-adress från deras fysiska plats.
Vi kan till och med extrahera hur frågor besvaras av de första respondenterna kontra hur det besvarades av de senare respondenterna. Detta kan ge en intressant infallsvinkel på din enkät – till exempel, svarade de ivriga personerna som svarade på enkäten först annorlunda än personer som inte var lika ivriga och svarade på enkäten senare?
I det här skedet tror jag att dessa rapporter kommer att räcka och att mer avancerade analyser inte är nödvändiga, eftersom den viktigaste informationen självklart är grundrapporten om vilka svar som gavs på varje fråga i en undersökning. Om du behöver mer avancerad analys, fundera då över vilka dina krav är och hur befintlig data eller nya strukturer kan stödja dessa analyser.
Slutsats
Och där har du det. Jag kommer inte att hävda att detta är designen för den ideala onlineundersökningsdatabasen, men den kommer att möta mina behov när det gäller flexibilitet:flera undersökningar, återanvändning av frågor, flervalssvar, ordning av frågor, villkorliga hopp i undersökningen baserat på svar och kontroll över användarnas tillgång till undersökningar via grupper av undersökningsägare.
Som jag har gjort i varje tidigare del av denna artikelserie kommer jag att påpeka att du kan ha andra krav. Identifiera dina krav och implementera eller anpassa det du behöver. Jag tror starkt på återanvändning och inte att återuppfinna hjulet.
Om du vill att vi ska designa om eller utöka den här modellen enligt din applikations behov, låt oss veta det. Vi kan hjälpa dig.
En databasmodell för en onlineundersökning –€“ hela serien
 Del 1 | Del 2 |  Del 3 |  Del 4 |