sql >> Databasteknik >  >> RDS >> Database

En databasmodell för en onlineundersökning. Del 3

I avslutningen till Del 2 av den här artikelserien nämnde jag att jag skulle lägga till mer avancerade funktioner, som:

  • Villkorlig ordning av frågor i en undersökning eller, med andra ord, möjligheten till en villkorad väg genom undersökningen
  • Administration av undersökningen
  • Rapporter och analys

I denna tredje artikel relaterad till en onlineundersökning , jag kommer att utöka funktionaliteten för att stödja villkorad ordning av frågor.

I framtiden kan vi lägga till frågor som kräver ett betygsatt svar. Till exempel:"Hur mycket gillar du databasdesign, betygsätt mellan 1 och 100 (med 1 indikerar att du gillar det väldigt lite och 100 indikerar att du gillar det oerhört)?"

Villkorlig sökväg

Vi vill ställa vissa villkor för de frågor som ställs till användaren baserat på användarnas svar. Till exempel, om svaret på fråga 4 är ”ja”, ställer vi fråga 5 och hoppar över fråga 6; medan om svaret på fråga 4 är "nej", hoppar vi över fråga 5 och ställer fråga 6).

Så vi måste definiera vilka frågor som är villkorade och hur man "hoppar över" frågor baserat på svaret på en fråga.

Inledningsvis, för att hålla den villkorliga vägen enkel, kommer vi inte att tillåta villkor baserade på flervalsfrågor, utan endast för polära (ja eller nej) frågor. Designen kan utökas för att stödja villkorade vägar baserade på flervalsfrågor, men det är mer komplext och jag vill börja enkelt.

Det är viktigt att applikationen kontrollerar detta flöde för varje fråga, eftersom svaret på en tidigare fråga kan avgöra flödet för den aktuella frågan (för att hoppa över en fråga baserat på ett tidigare svar).

Administration och rapporter

För tillfället kommer vi inte att lägga till administratörer för online-undersökningarna, men behåller det för nästa tillägg.

Det kommer att behöva finnas några rapporter och analyser; Jag kommer dock att behålla detta för nästa version eftersom jag vill lagra lite information först för att utföra analyser senare.

Entiteter och relationer

För den villkorliga vägen genom undersökningen kommer jag att utöka question_order som definieras för varje undersökning och kopplar undersökningen till frågorna. Som nämnts, för nu, det villkorliga hoppet kommer bara att baseras på polära frågor, så jag kan definiera nästa fråga som ska visas vid ett positivt svar och nästa fråga som ska visas vid ett negativt svar.

Formell design

Låt oss utöka ERD som skapades i Del 1 av denna artikelserie.

Jag lägger till conditional_order länkad till question_order; som jag nämnde tidigare kommer jag endast att stödja villkorlig ordning genom undersökningen baserad på polära frågor. Nu finns det några sätt detta kan implementeras. Mina behov är enkla, så jag kommer att välja en enkel implementering. Om dina behov är mer komplexa skulle du behöva en mer komplex lösning.

Det skulle vara trevligt att bara definiera "nästa" fråga som ska ställas baserat på svaret på den aktuella frågan, men det kommer inte att tillåta oss att hoppa över en fråga senare i undersökningen, så vi behöver mer flexibilitet.

Ett sätt är att specificera hur många frågor som ska gå vidare vid ett positivt svar och hur många som ska gå vidare på ett negativt svar; dock måste jag specificera för vilken fråga hoppet gäller och svaret på vilken fråga som ska användas. Så för att stödja mitt exempel:om svaret på fråga 4 är "ja" så ställer vi fråga 5 och hoppar över fråga 6, medan om svaret på fråga 4 är "nej" hoppar vi över fråga 5 och ställer fråga 6 -- detta kräver två poster som båda kontrollerar svaret på fråga 4, en flyttar fram en fråga (som vanligt) och en hoppar framåt två frågor (för att hoppa över en fråga), och det andra villkoret som kontrolleras efter att ha svarat på fråga 5 som hoppar över fråga 6.

  +-------------------+----------------------+------------------------+------------------------+ 
  | question_order_id | response_to_question | positive_response_jump | negative_response_jump |
  +-------------------+----------------------+------------------------+------------------------+
  | 4                 | 4                    | 1                      | 2                      |
  +-------------------+----------------------+------------------------+------------------------+
  | 5                 | 4                    | 1                      | null                   |
  +-------------------+----------------------+------------------------+------------------------+

Ett alternativ är att ange ID för nästa fråga som undersökningen ska hoppa till vid ett visst svar:nästa fråga vid positivt svar och nästa fråga vid negativt svar svar. Detta tillvägagångssätt har för- och nackdelar. Det skulle tillåta loopar att uppstå, som en administratör kanske inte märker. Men loopar kan vara en önskad effekt så att du kan få den sista frågan att fråga respondenten om de är klara med undersökningen och om de svarar "nej", återgå sedan till den första frågan. Dessutom kan frågorna att hoppa till vid ett positivt eller negativt svar ställas in som främmande nycklar till den ordning av frågor som anges för undersökningen så att vi med säkerhet vet att den angivna frågan är definierad i undersökningen. Detta är en trevlig incheckningslogik implementerad genom referensintegritet. Jag tror att detta förmodligen är den bättre lösningen, så det är vad du hittar i ERD.

Så för att stödja mitt exempel:om svaret på fråga 4 är "ja" så ställer vi fråga 5 och hoppar över fråga 6, medan om svaret på fråga 4 är "nej" hoppar vi över fråga 5 och ställer fråga 6.

Som nämnts har vi två rader:

Survey #1, question #4, response to question #4, positive response: next question order id = 5, negative response: next question order id = 6.

Survey #1, question #5, response to question #4, positive response: next question order id = 7. We will never get to question #5 if the response to question #4 was negative, so we always skip question #6 after asking question #5.

  +--------+----------+----------------------+-------------------------------+-------------------------------+
  | survey | question | response_to_question | positive_response_question_id | negative_response_question_id |
  +--------+----------+----------------------+-------------------------------+-------------------------------+
  | 1      | 4        | 4                    | 5                             | 6                             |
  +--------+----------+----------------------+-------------------------------+-------------------------------+
  |        | 5        | 4                    | 7                             | null                          |
  +--------+----------+----------------------+-------------------------------+-------------------------------+

När vi ställer in villkoret kommer vi att använda en främmande nyckel (inte obligatorisk) för att säkerställa att nästa fråga finns. Ett nollvärde används för en sökväg som inte är möjlig eller, om ingen nästa fråga anges, för att villkorligt avsluta undersökningen.




Jag har färglagt tabellerna som skapades i Del 1 av artikelserien i gul , tabellerna som lagts till i Del 2 i  orange  och den nyligen tillagda tabellen i  grön  så att det är lättare att se tilläggen.

Slutsats

Ingen av lösningarna som beskrivs för att hantera villkorade steg genom en undersökning är det ultimata regelbaserade systemet, men ett av mina mål är att hålla saker och ting enkelt och okomplicerat. Tillåter flexibilitet utan att överväldigande saker i komplexitet. Och jag upprepar mig själv, du kanske har andra krav. Identifiera dina krav; implementera eller anpassa det du behöver. Jag tror starkt på återanvändning och inte att återuppfinna hjulet.

Nu har vi börjat implementera förbättringarna som diskuterades i del 1 och 2 av denna artikelserie.

I nästa artiklar kommer jag att lägga till stöd för dessa funktioner:

  • Administration av undersökningarna
  • Rapporter och analyser

  1. Kontrollera om en tabell har en TIMESTAMP-kolumn i SQL Server med OBJECTPROPERTY()

  2. Hur får man den senaste posten i varje grupp med GROUP BY?

  3. Hur man sammanfogar strängar i SQL Server med CONCAT()

  4. PHP PDOException:SQLSTATE[HY093]:Ogiltigt parameternummer