sql >> Database teknologi >  >> RDS >> Database

En databasemodel til en onlineundersøgelse. Del 4

I denne sidste artikel i en serie i fire dele færdiggør jeg designet til en online undersøgelsesdatabase for at give fleksibilitet til flere undersøgelser, genbrug af spørgsmål, svar med flere valg, rækkefølge af spørgsmål, betingede spring i undersøgelsen baseret på svar og kontrol over brugernes adgang til undersøgelser via grupper af undersøgelsesejere.

Introduktion

I konklusionen på del 3 af denne serie af artikler nævnte jeg, at jeg ville tilføje mere avancerede funktioner i denne artikel. Disse avancerede funktioner er:

  • administration af undersøgelserne
  • rapporter og analyse

Som en påmindelse var her modellen efter del 3:



Administration

Mit mål i administrationen af ​​undersøgelser er at tillade, at en undersøgelse og dens tilsvarende information kan administreres af en gruppe. Så jeg vil gøre det muligt for en administrativ bruger at definere grupper af brugere, der i fællesskab kan vedligeholde en online-undersøgelse og dens spørgsmål. Ejeren af ​​gruppen kan definere, hvilke funktioner de andre brugere af gruppen kan udføre; Jeff kan f.eks. ændre og slette undersøgelser og spørgsmål, men Joe kan kun se undersøgelser og spørgsmål, men ikke ændre eller slette dem.

En ting, du måske bemærker, er, at brugerne er adskilt fra respondenterne i undersøgelsen. En bruger kan selvfølgelig også svare på en undersøgelse, men jeg vil gerne holde dem adskilt, så jeg kan kræve færre oplysninger fra en respondent end fra en bruger (jeg har f.eks. fjernet adgangskodefeltet fra en respondent, så det er nemmere for folk at svare på undersøgelsen uden at oprette et login/konto).

Grundlæggende vil jeg til denne administration oprette tabeller for grupper og brugere, og de roller og tilsvarende tilladelser eller handlinger, der er tilladt. Dette giver mulighed for fleksibilitet snarere end en hårdkodet forbindelse mellem rollerne og de handlinger, der er tilladt af hver rolle. Selvfølgelig skal den tilsvarende applikation bygges for at forstå, hvilken funktionalitet der er tilladt af hver tilladelse og skal tilpasses, når ny funktionalitet tilføjes, men databasedesignet skal ikke ændres, når funktionalitet tilføjes - nye rækker vil blive tilføjet til tabel, der forbinder roller med tilladelser.

Du vil måske også bemærke, at jeg har brugt en ulige længde for email kolonne på user og respondent tabeller og en ulige værdi for ip_address kolonne for respondent; 254 er den maksimale længde, som en e-mailadresse kan være i henhold til RFC-definitionerne, mens 45 er den maksimale længde, som en IPv6-adresse (med IPv4-tunneling) kan være.




Derudover vil jeg tilføje et link fra group tabel til survey tabel, hvorfra links går til alle tilknyttede tabeller (question_order , survey_response , conditional_order , question_type , response_choice ). På den måde, når gruppen bliver slettet, kan jeg advare ejeren af ​​gruppen om, at alle tilsvarende oplysninger vil blive slettet.

Jeg foretrækker denne tilgang med at linke tabeldataene til noget andet end den specifikke bruger frem for ikke at linke dataene til noget. Hvis vi ikke linkede dataene til noget (hverken gruppe eller bruger), som jeg så ud til at gøre i tidligere dele af denne serie af artikler, så vil vi have en udfordring med at "rydde op" for uaktuelle data, når en bruger bliver slettet fra onlineundersøgelsen Ansøgning. Ved at knytte det til det mere abstrakte begreb "gruppe", så bliver det muligt for ejeren at tildele ejerskabet af gruppen og alle tilsvarende data (undersøgelser, spørgsmål, svar osv.) til et andet medlem af gruppen, hvis det er nødvendigt.

Formelt design

Så udvider vi den ERD, der blev oprettet i de andre dele af denne serie af artikler.




Jeg har farvet de tabeller, der blev oprettet i del 1-artiklen i gult, farvet tabellerne tilføjet i del 2 i orange, farvet tabellerne tilføjet i del 3 i grøn og de nyligt tilføjede tabeller i lyseblå, så det er nemmere at se tilføjelserne. Farve blev ikke tilføjet til kolonnerne og fremmednøglerne, som blev tilføjet i denne sidste artikel, så du skulle sammenligne den nuværende model med den forrige fra del 3 for at se forskellene.

Rapporter og analyse

Vi har nok information, der kan udtrækkes fra tabellerne til at producere flere rapporter.

For eksempel hvilke spørgsmål blev besvaret på en bestemt måde ("på undersøgelse 7, hvor mange gange svarede respondenterne 'Ja' til spørgsmål 10?"). Dette informationsniveau er sandsynligvis fint til grundlæggende rapporter om undersøgelsessvar.

Vi kan også udtrække, hvor lang tid det tog respondenterne at svare på en bestemt undersøgelse ("på undersøgelse 5 var den gennemsnitlige tid brugt på undersøgelsen 13 minutter"); igen, dette kan være nyttig information, så ejere af en undersøgelse kan justere undersøgelsesspørgsmål, så de ikke kræver mere tid, end hvad en typisk respondent er villig til at bruge, eller hvad surveyor har "lovet" til respondenterne (f.eks. "denne undersøgelse" bør tage mellem 5 og 10 minutter"). Jeg ved, at når nogen fortæller mig, at jeg skal være færdig på mindre end 10 minutter, og jeg stadig pløjer mig igennem spørgsmål 15 minutter senere, så bliver jeg vred, og jeg er generelt ikke villig til at svare på en anden undersøgelse fra dem.

Baseret på respondenternes IP-adresser kunne vi lave et omvendt opslag for at få en omtrentlig idé om, hvor respondenterne er fra, eller i det mindste hvor deres IP-adresse ser ud til at være fra, da de svarede. Vær opmærksom på, at disse oplysninger ikke er helt pålidelige, da folk kan oprette forbindelse via VPN'er eller andre mekanismer, der adskiller deres IP-adresse fra deres fysiske placering.

Vi kan endda uddrage, hvordan spørgsmål besvares af de første respondenter versus hvordan det blev besvaret af de sidstnævnte. Dette kunne præsentere en interessant vinkel på din undersøgelse – for eksempel, svarede de ivrige mennesker, der svarede på undersøgelsen, først anderledes end folk, der ikke var så ivrige og svarede på undersøgelsen senere?

På nuværende tidspunkt tror jeg, at disse rapporter vil være nok, og at mere avancerede analyser ikke er nødvendige, da den vigtigste information naturligvis er den grundlæggende rapport om, hvilke svar der blev givet til hvert spørgsmål i en undersøgelse. Hvis du har brug for mere avancerede analyser, så overvej, hvad dine krav er, og hvordan eksisterende data eller nye strukturer kan understøtte disse analyser.

Konklusion

Og der har du det. Jeg vil ikke påstå, at dette er designet til den ideelle online-undersøgelsesdatabase, men dette vil opfylde mine behov med hensyn til fleksibilitet:flere undersøgelser, genbrug af spørgsmål, svar med flere valg, rækkefølge af spørgsmål, betingede spring i undersøgelsen baseret på svar og kontrol over brugernes adgang til undersøgelser via grupper af undersøgelsesejere.

Som jeg har gjort i hver tidligere del af denne artikelserie, vil jeg påpege, at du måske har andre krav. Identificer dine krav og implementer eller tilpas det, du har brug for. Jeg tror stærkt på genbrug og ikke at genopfinde hjulet.


Hvis du gerne vil have, at vi redesigner eller udvider denne model i overensstemmelse med din applikations behov, så lad os det vide. Vi kan hjælpe dig.


En databasemodel til en onlineundersøgelse –€“ hele serien

Del 1 Del 2 Del 3 Del 4

  1. PostgreSQL – Sådan fjerner du gentagne værdier

  2. Hvordan kan jeg indsætte mange rækker i en MySQL-tabel og returnere de nye id'er?

  3. JDBCTemplate sæt indlejret POJO med BeanPropertyRowMapper

  4. Skjulte funktioner i Oracle