sql >> Databáze >  >> RDS >> Database

Databázový model pro online průzkum. Část 3

Na závěr k 2. části v této sérii článků jsem zmínil, že bych přidal pokročilejší funkce, jako například:

  • Podmíněné řazení otázek v průzkumu nebo jinými slovy možnost podmíněné cesty průzkumem
  • Administrace průzkumu
  • Přehledy a analytika

Tento třetí článek souvisí s online průzkumem , rozšířím funkcionalitu o podporu podmíněného řazení otázek.

V budoucnu můžeme přidat otázky, které vyžadují hodnocenou odpověď. Například:„Jak moc se vám líbí návrh databáze, ohodnoťte 1 až 100 (přičemž 1 znamená, že se vám líbí velmi málo a 100 znamená, že se vám líbí nesmírně)?“

Podmíněná cesta

Chceme nastavit určité podmínky pro otázky kladené uživateli na základě uživatelských odpovědí. Pokud je například odpověď na otázku 4 „ano“, položíme otázku 5 a přeskočíme otázku 6; pokud je odpověď na otázku 4 „ne“, pak otázku 5 přeskočíme a položíme otázku 6).

Musíme tedy definovat, které otázky jsou podmíněné a jak otázky „přeskočit“ na základě odpovědi na otázku.

Zpočátku, aby byla podmíněná cesta jednoduchá, nepovolíme podmínky založené na otázkách s výběrem odpovědí, ale pouze pro polární otázky (ano nebo ne). Návrh lze rozšířit tak, aby podporoval podmíněné cesty založené na otázkách s více možnostmi, ale to je složitější a chci začít jednoduše.

Je důležité, aby aplikace kontrolovala tento tok u každé otázky, protože odpověď na předchozí otázku může rozhodnout o toku aktuální otázky (pro přeskočení otázky na základě předchozí odpovědi).

Administrace a sestavy

Prozatím nebudeme přidávat administrátory online průzkumů, ale necháme si to pro příští rozšíření.

Budou potřeba nějaké reporty a analýzy; ponechám si to však pro příští verzi, protože si chci nejprve uložit nějaké informace, abych mohl později provádět analýzy.

Entity a vztahy

Pro podmíněnou cestu průzkumem rozšířím question_order který je definován pro každý průzkum a spojuje průzkum s otázkami. Jak již bylo zmíněno, prozatím podmíněný skok bude založeno pouze na polárních otázkách, takže mohu definovat další otázku, která se zobrazí v případě kladné odpovědi, a další otázku, která se zobrazí v případě záporné odpovědi.

Formální design

Pojďme rozšířit ERD, který byl vytvořen v Části 1 této série článků.

Přidám conditional_order propojeno s question_order; jak jsem již zmínil dříve, budu podporovat pouze podmíněné pořadí prostřednictvím průzkumu založeného na polárních otázkách. Nyní existuje několik způsobů, jak to lze implementovat. Mé potřeby jsou přímočaré, proto zvolím přímočarou implementaci. Pokud jsou vaše potřeby složitější, budete potřebovat složitější řešení.

Bylo by hezké pouze definovat „další“ otázku, která má být položena na základě odpovědi na aktuální otázku, ale to nám nedovolí přeskočit otázku později v průzkumu, takže potřebujeme větší flexibilitu.

Jedním ze způsobů je určit, kolik otázek se má posunout vpřed v případě kladné odpovědi a kolik se posunout vpřed v případě záporné odpovědi; musím však upřesnit, na kterou otázku se skok vztahuje a na kterou odpověď se má použít. Abych podpořil svůj příklad:pokud je odpověď na otázku 4 „ano“, položíme otázku 5 a přeskočíme otázku 6, zatímco pokud je odpověď na otázku 4 „ne“, přeskočíme otázku 5 a položíme otázku 6 -- to vyžaduje dva záznamy, z nichž oba kontrolují odpověď na otázku 4, jeden posun o jednu otázku vpřed (jako obvykle) a jeden přeskočení o dvě otázky vpřed (pro přeskočení otázky) a druhou podmínku, kterou je třeba zkontrolovat po zodpovězení otázky 5, která otázku přeskakuje 6.

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

Alternativou je zadat ID další otázky, na kterou má průzkum přejít v případě konkrétní odpovědi:další otázka v případě kladné odpovědi a další otázka v případě záporné odpovědi Odezva. Tento přístup má klady i zápory. Umožnilo by to vznik smyček, kterých si správce nemusí všimnout. Žádoucím efektem však mohou být smyčky, takže se můžete v závěrečné otázce zeptat respondenta, zda skončil s průzkumem, a pokud odpoví „ne“, pak se vraťte k první otázce. Otázky, na které se v případě kladné nebo záporné odpovědi přeskočí, lze navíc nastavit jako cizí klíče k pořadí otázek zadaných pro průzkum, abychom s jistotou věděli, že zadaná otázka je v průzkumu definována. Toto je pěkná kontrola v logice implementovaná prostřednictvím referenční integrity. Myslím, že toto je pravděpodobně lepší řešení, takže to najdete v ERD.

Pro podporu mého příkladu:pokud je odpověď na otázku 4 „ano“, položíme otázku 5 a přeskočíme otázku 6, zatímco pokud je odpověď na otázku 4 „ne“, přeskočíme otázku 5 a položíme otázku 6.

Jak již bylo zmíněno, máme dva řádky:

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                          |
  +--------+----------+----------------------+-------------------------------+-------------------------------+

Při nastavování podmínky použijeme cizí klíč (není povinný), abychom zajistili existenci další otázky. Hodnota null se používá pro cestu, která není možná, nebo pokud není zadána žádná další otázka, pro podmíněné ukončení průzkumu.




Vybarvil jsem tabulky, které byly vytvořeny v Části 1 ze série článků ve  žluté , tabulky přidané v 2. části v oranžové barvě a nově přidaná tabulka v  zelené barvě, aby bylo snazší vidět doplňky.

Závěr

Žádné z řešení, která jsou popsána pro správu podmíněných kroků prostřednictvím průzkumu, není konečným systémem založeným na pravidlech, ale jedním z mých cílů je udržet věci jednoduché a přímočaré. Umožňuje flexibilitu, aniž by to zahlcovalo složitost věcí. A budu se opakovat, možná budete mít jiné požadavky. Identifikujte své požadavky; implementovat nebo přizpůsobit to, co potřebujete. Pevně ​​věřím v opětovné použití a ne ve znovuvynalézání kola.

Nyní jsme začali implementovat vylepšení, která byla diskutována v částech 1 a 2 této série článků.

V dalších článcích přidám podporu pro tyto funkce:

  • Administrace průzkumů
  • Přehledy a analýzy

  1. Číslo řádku na skupinu v mysql

  2. SQL Server POKUD NEEXISTUJE Použití?

  3. Jak připravit příkazy a parametry vazby v Postgresql pro C++

  4. Příklady HOUR() – MySQL