In dit laatste artikel in een vierdelige serie voltooi ik het ontwerp voor een online enquêtedatabase om flexibiliteit te bieden voor meerdere enquêtes, hergebruik van vragen, meerkeuzeantwoorden, volgorde van vragen, voorwaardelijke sprongen in de enquête op basis van antwoorden, en controle over de toegang van gebruikers tot enquêtes via groepen enquête-eigenaren.
Inleiding
In de conclusie van deel 3 van deze serie artikelen zei ik dat ik meer geavanceerde functies in dit artikel zou toevoegen. Die geavanceerde functies zijn:
- administratie van de enquêtes
- rapporten en analyse
Ter herinnering, hier was het model na deel 3:
Beheer
Mijn doel bij de administratie van enquêtes is om een enquête en de bijbehorende informatie door een groep te laten beheren. Ik zal een administratieve gebruiker dus in staat stellen om groepen gebruikers te definiëren die gezamenlijk een online enquête en de bijbehorende vragen kunnen bijhouden. De eigenaar van de groep kan bepalen welke functies de andere gebruikers van de groep kunnen uitvoeren; Jeff kan bijvoorbeeld enquêtes en vragen wijzigen en verwijderen, maar Joe kan enquêtes en vragen alleen bekijken, maar niet wijzigen of verwijderen.
Een ding dat u misschien opvalt, is dat gebruikers gescheiden zijn van respondenten van de enquête. Natuurlijk kan een gebruiker ook reageren op een enquête, maar ik zou ze graag gescheiden houden zodat ik minder informatie van een respondent kan vragen dan van een gebruiker (ik heb bijvoorbeeld het wachtwoordveld van een respondent verwijderd zodat het is gemakkelijker voor mensen om op de enquête te reageren zonder een login/account aan te maken).
In principe zal ik voor dit beheer tabellen maken voor groepen en gebruikers, en de rollen en bijbehorende machtigingen of acties die zijn toegestaan. Dit zorgt voor flexibiliteit in plaats van een vastgecodeerde koppeling tussen de rollen en de acties die door elke rol zijn toegestaan. Natuurlijk moet de bijbehorende applicatie worden gebouwd om te begrijpen welke functionaliteit door elke machtiging is toegestaan en moet deze worden aangepast wanneer nieuwe functionaliteit wordt toegevoegd, maar het databaseontwerp hoeft niet te worden gewijzigd wanneer functionaliteit wordt toegevoegd - nieuwe rijen worden toegevoegd aan de tabel die rollen aan rechten koppelt.
Het is je misschien ook opgevallen dat ik een oneven lengte heb gebruikt voor de email kolom op de user en respondent tabellen en een oneven waarde voor het ip_address kolom voor de respondent; 254 is de maximale lengte die een e-mailadres kan hebben volgens de RFC-definities, terwijl 45 de maximale lengte is die een IPv6-adres (met IPv4-tunneling) kan zijn.
Daarnaast zal ik een link toevoegen uit de group tabel naar de survey tabel van waaruit links naar alle bijbehorende tabellen gaan (question_order , survey_response , conditional_order , question_type , response_choice ). Op die manier kan ik, wanneer de groep wordt verwijderd, de eigenaar van de groep waarschuwen dat alle bijbehorende informatie wordt verwijderd.
Ik geef de voorkeur aan deze benadering om de tabelgegevens aan iets anders dan de specifieke gebruiker te koppelen, in plaats van de gegevens nergens aan te koppelen. Als we de gegevens nergens aan hebben gekoppeld (noch groep noch gebruiker) zoals ik in eerdere delen van deze serie artikelen leek te doen, dan zullen we een uitdaging hebben om verouderde gegevens op te schonen wanneer een gebruiker wordt verwijderd uit de online enquête sollicitatie. Door het te koppelen aan het meer abstracte concept 'groep', wordt het voor de eigenaar mogelijk om het eigendom van de groep en alle bijbehorende gegevens (enquêtes, vragen, antwoorden, enz.) Indien nodig opnieuw toe te wijzen aan een ander lid van de groep.
Formeel ontwerp
Dan breiden we de ERD uit die in de andere delen van deze serie artikelen is gemaakt.
Ik heb de tabellen die in het artikel van deel 1 zijn gemaakt geel gekleurd, de tabellen die in deel 2 zijn toegevoegd oranje, de tabellen die in deel 3 zijn toegevoegd groen en de nieuw toegevoegde tabellen lichtblauw, zodat het gemakkelijker is om zie de aanvullingen. Er is geen kleur toegevoegd aan de kolommen en externe sleutels die in dit laatste artikel zijn toegevoegd, dus je zou het huidige model moeten vergelijken met het vorige uit deel 3 om de verschillen te zien.
Rapporten en analyses
We hebben genoeg informatie die uit de tabellen kan worden gehaald om meerdere rapporten te maken.
Welke vragen zijn bijvoorbeeld op een bepaalde manier beantwoord (“hoe vaak hebben respondenten bij enquête 7 vraag 10 met ‘Ja’ beantwoord?”). Dit informatieniveau is waarschijnlijk prima voor basisrapporten over enquêtereacties.
We kunnen ook extraheren hoe lang het duurde voordat respondenten op een bepaalde enquête reageerden (“in enquête 5 was de gemiddelde tijd die aan de enquête werd besteed 13 minuten”); nogmaals, dit kan nuttige informatie zijn zodat eigenaren van een enquête enquêtevragen kunnen aanpassen zodat ze niet meer tijd nodig hebben dan wat een typische respondent bereid is te besteden of wat de enquêteur aan respondenten heeft "beloofd" (bijvoorbeeld "deze enquête" duurt tussen de 5 en 10 minuten"). Ik weet dat wanneer iemand me zegt dat ik in minder dan 10 minuten klaar moet zijn en ik 15 minuten later nog steeds vragen doorwerk, dan word ik boos en ben ik over het algemeen niet bereid om op een andere enquête van hen te reageren.
Op basis van de IP-adressen van de respondenten zouden we wat omgekeerd kunnen opzoeken om een idee te krijgen van waar de respondenten vandaan komen of in ieder geval waar hun IP-adres vandaan lijkt te komen toen ze reageerden. Houd er rekening mee dat deze informatie niet helemaal betrouwbaar is, omdat mensen verbinding kunnen maken via VPN's of andere mechanismen die hun IP-adres loskoppelen van hun fysieke locatie.
We kunnen zelfs extraheren hoe vragen zijn beantwoord door de eerste respondenten versus hoe deze zijn beantwoord door de laatste respondenten. Dit zou een interessante invalshoek op uw enquête kunnen zijn –€“ reageerden bijvoorbeeld de enthousiaste mensen die op de enquête reageerden eerst anders dan mensen die niet zo enthousiast waren en later op de enquête reageerden?
In dit stadium denk ik dat deze rapporten voldoende zullen zijn en dat meer geavanceerde analyses niet nodig zijn, aangezien de belangrijkste informatie uiteraard het basisrapport is van welke antwoorden op elke vraag in een enquête zijn gegeven. Als u meer geavanceerde analyses nodig heeft, overweeg dan wat uw vereisten zijn en hoe bestaande gegevens of nieuwe structuren die analyses kunnen ondersteunen.
Conclusie
En daar heb je het. Ik zal niet beweren dat dit het ontwerp is voor de ideale online enquêtedatabase, maar dit zal voldoen aan mijn behoeften op het gebied van flexibiliteit:meerdere enquêtes, hergebruik van vragen, meerkeuzeantwoorden, volgorde van vragen, voorwaardelijke sprongen in de enquête op basis van reacties en controle over de toegang van gebruikers tot enquêtes via groepen enquête-eigenaren.
Zoals ik in elk vorig deel van deze serie artikelen heb gedaan, zal ik u erop wijzen dat u mogelijk andere vereisten heeft. Identificeer uw vereisten en implementeer of pas aan wat u nodig heeft. Ik geloof sterk in hergebruik en niet het wiel opnieuw uitvinden.
Als u wilt dat wij dit model opnieuw ontwerpen of uitbreiden volgens de behoeften van uw toepassing, laat het ons dan weten. Wij kunnen u helpen.
Een databasemodel voor een online enquête –€“ de hele serie
 Deel 1 | Deel 2 |  Deel 3 |  Deel 4 |