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

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

V tomto posledním článku ze čtyřdílné série dokončuji návrh online databáze průzkumů, která poskytuje flexibilitu pro více průzkumů, opakované použití otázek, odpovědi s více možnostmi, řazení otázek, podmíněné skoky v průzkumu na základě odpovědí a kontrolu nad přístupem uživatelů k průzkumům prostřednictvím skupin vlastníků průzkumů.

Úvod

V závěru 3. části této série článků jsem zmínil, že do tohoto článku přidám pokročilejší funkce. Tyto pokročilé funkce jsou:

  • administrace z průzkumů
  • přehledy a analytika

Pro připomenutí, zde byl model po části 3:



Administrace

Mým cílem v administraci průzkumů je umožnit, aby průzkum a jeho odpovídající informace byly spravovány skupinou. Umožním tedy administrátorovi definovat skupiny uživatelů, kteří mohou společně spravovat online průzkum a jeho otázky. Vlastník skupiny může definovat, jaké funkce mohou provádět ostatní uživatelé skupiny; Jeff může například měnit a mazat průzkumy a otázky, ale Joe může průzkumy a otázky pouze prohlížet, ale nemůže je měnit ani mazat.

Jedna věc, které si můžete všimnout, je, že uživatelé jsou odděleni od respondentů průzkumu. Uživatel může samozřejmě také odpovědět na průzkum, ale chtěl bych je ponechat odděleně, abych mohl od respondenta vyžadovat méně informací než od uživatele (například jsem od respondenta odstranil pole pro heslo, aby je pro lidi snazší odpovídat na průzkum, aniž by si museli vytvářet přihlašovací jméno/účet).

V podstatě pro tuto administraci vytvořím tabulky pro skupiny a uživatele a role a odpovídající oprávnění nebo akce, které jsou povoleny. To umožňuje flexibilitu spíše než pevně zakódované propojení mezi rolemi a akcemi, které každá role umožňuje. Odpovídající aplikace musí být samozřejmě sestavena tak, aby pochopila, jakou funkcionalitu povolují jednotlivá oprávnění, a musí být přizpůsobena, když je přidána nová funkce, ale při přidávání funkcí nebude nutné měnit návrh databáze – do souboru budou přidány nové řádky. tabulka propojující role s oprávněními.

Můžete si také všimnout, že jsem použil lichou délku pro email ve sloupci user a respondent tabulky a lichou hodnotu pro ip_address sloupec pro respondent; 254 je maximální délka, kterou může mít e-mailová adresa podle definic RFC, zatímco 45 je maximální délka adresy IPv6 (s tunelováním IPv4).




Navíc přidám odkaz ze group tabulky do survey tabulka, ze které jdou odkazy na všechny přidružené tabulky (question_order , survey_response , conditional_order , question_type , response_choice ). Tímto způsobem, když je skupina mazána, mohu varovat vlastníka skupiny, že všechny odpovídající informace budou smazány.

Dávám přednost tomuto přístupu propojení dat tabulky s něčím jiným, než je konkrétní uživatel, než nepropojování dat s ničím. Pokud jsme data nepropojili s ničím (ani skupinou, ani uživatelem), jak se mi zdálo v předchozích částech této série článků, pak budeme mít problém „vyčistit“ zastaralá data, když je uživatel smazán z online průzkumu. aplikace. Propojením s abstraktnějším pojmem „skupina“ je pak pro vlastníka možné v případě potřeby znovu přiřadit vlastnictví skupiny a všech odpovídajících dat (průzkumy, otázky, odpovědi atd.) na jiného člena skupiny.

Formální design

Poté rozšíříme ERD, který byl vytvořen v dalších částech této série článků.




Tabulky, které byly vytvořeny v článku 1. části, jsem vybarvil žlutě, tabulky přidané v 2. části oranžově, tabulky přidané v části 3 jsem vybarvil zeleně a nově přidané tabulky světle modrou, aby bylo snazší viz dodatky. Barva nebyla přidána do sloupců a cizích klíčů, které byly přidány v tomto posledním článku, takže budete muset porovnat aktuální model s předchozím z části 3, abyste viděli rozdíly.

Přehledy a analýzy

Máme dostatek informací, které lze z tabulek extrahovat, abychom vytvořili několik zpráv.

Například, které otázky byly zodpovězeny konkrétním způsobem („v průzkumu 7, kolikrát respondenti odpověděli „Ano“ na otázku 10?“). Tato úroveň informací je pravděpodobně v pořádku pro základní zprávy o odpovědích na průzkum.

Můžeme také extrahovat, jak dlouho trvalo respondentům odpovědět na konkrétní průzkum („v průzkumu 5 byla průměrná doba strávená průzkumem 13 minut“); opět to může být užitečná informace, aby majitelé průzkumu mohli upravit otázky průzkumu tak, aby nevyžadovaly více času, než kolik je ochoten utratit typický respondent nebo co průzkumník „slíbil“ respondentům (např. „tento průzkum by mělo trvat 5 až 10 minut“). Vím, že když mi někdo řekne, že bych měl být hotový za méně než 10 minut, a já se ještě o 15 minut později probírám otázkami, pak se rozzlobím a obecně nejsem ochoten odpovídat na další průzkum od něj.

Na základě IP adres respondentů bychom mohli provést nějaké zpětné vyhledávání, abychom měli přibližnou představu o tom, odkud respondenti jsou nebo alespoň odkud se zdá, že jejich IP adresa je, když odpověděli. Uvědomte si, že tyto informace nejsou zcela spolehlivé, protože lidé se mohou připojit prostřednictvím sítí VPN nebo jiných mechanismů, které oddělují jejich IP adresu od jejich fyzického umístění.

Můžeme dokonce extrahovat, jak na otázky odpovídali první respondenti oproti tomu, jak na ně odpovídali druzí respondenti. To by mohlo představovat zajímavý úhel pohledu na váš průzkum – například:Odpovídali dychtiví lidé, kteří na průzkum odpověděli nejprve jinak, než lidé, kteří tak dychtiví nebyli a odpověděli na průzkum později?

V této fázi si myslím, že tyto zprávy budou stačit a pokročilejší analýzy nejsou nutné, protože nejdůležitější informací je samozřejmě základní zpráva o tom, jaké byly odpovědi na jednotlivé otázky v průzkumu. Pokud požadujete pokročilejší analýzu, zvažte, jaké jsou vaše požadavky a jak mohou stávající data nebo nové struktury tyto analýzy podpořit.

Závěr

A tady to máte. Nebudu tvrdit, že se jedná o návrh ideální databáze online průzkumů, ale bude vyhovovat mým potřebám z hlediska flexibility:vícenásobné průzkumy, opakované použití otázek, odpovědi s výběrem odpovědí, řazení otázek, podmíněné skoky v průzkumu na základě odpovědi a kontrolu nad přístupem uživatelů k průzkumům prostřednictvím skupin vlastníků průzkumů.

Stejně jako v každé předchozí části této série článků zdůrazním, že můžete mít jiné požadavky. Identifikujte své požadavky a implementujte nebo přizpůsobte to, co potřebujete. Pevně ​​věřím v opětovné použití a ne ve znovuvynalézání kola.


Pokud byste chtěli, abychom tento model přepracovali nebo rozšířili podle potřeb vaší aplikace, dejte nám vědět. Můžeme vám pomoci.


Databázový model pro online průzkum – celá série

Část 1 Část 2 Část 3 Část 4

  1. Postgresql - zálohování databáze a obnova u jiného vlastníka?

  2. Jak zrušit všechny uživatelské tabulky?

  3. Příklad APEX_ZIP

  4. Příklady DAYOFYEAR() – MySQL