В тази последна статия от поредица от четири части завършвам дизайна на база данни за онлайн анкети, за да осигуря гъвкавост за множество анкети, повторно използване на въпроси, отговори с множество възможности за избор, подреждане на въпроси, условни скокове в анкетата въз основа на отговорите и контрол върху достъпа на потребителите до анкети чрез групи собственици на анкети.
Въведение
В заключение на част 3 от тази поредица от статии споменах, че ще добавя по-разширени функции в тази статия. Тези разширени функции са:
- администриране от проучванията
- доклади и анализ
Като напомняне, ето модела след част 3:
Администрация
Моята цел при администрирането на анкети е да позволя едно проучване и съответната информация да се управлява от група. Така че ще дам възможност на административен потребител да дефинира групи потребители, които могат съвместно да поддържат онлайн анкета и въпросите към нея. Собственикът на групата може да определи какви функции могат да изпълняват другите потребители на групата; например Джеф може да променя и изтрива анкети и въпроси, но Джо може само да преглежда анкети и въпроси, но не и да ги променя или изтрива.
Едно нещо, което може да забележите е, че потребителите са отделени от респондентите в анкетата. Разбира се, потребител може също да отговори на анкета, но бих искал да ги запазя отделно, за да мога да изисквам по-малко информация от респондент, отколкото от потребител (например премахнах полето за парола от респондент, така че да е по-лесно за хората да отговорят на анкетата, без да създават вход/акаунт).
По принцип за тази администрация ще създам таблици за групи и потребители, както и ролите и съответните разрешения или действия, които са разрешени. Това позволява гъвкавост, а не твърдо кодирана връзка между ролите и действията, разрешени от всяка роля. Разбира се, съответното приложение трябва да бъде създадено, за да разбере каква функционалност е разрешено от всяко разрешение и трябва да бъде адаптирано, когато се добави нова функционалност, но дизайнът на базата данни няма да е необходимо да се променя при добавяне на функционалност – нови редове ще бъдат добавени към таблица, свързваща ролите с разрешенията.
Може също да забележите, че съм използвал странна дължина за email колона на user и respondent таблици и нечетна стойност за ip_address колона за respondent; 254 е максималната дължина, която един имейл адрес може да бъде според дефинициите на RFC, докато 45 е максималната дължина, която може да бъде IPv6 адрес (с IPv4 тунелиране).
Освен това ще добавя връзка от group таблица към survey таблица, от която връзките отиват към всички свързани таблици (question_order , survey_response , conditional_order , question_type , response_choice ). По този начин, когато групата се изтрива, мога да предупредя собственика на групата, че цялата съответна информация ще бъде изтрита.
Предпочитам този подход на свързване на данните в таблицата с нещо различно от конкретния потребител, вместо да не свързвам данните с нищо. Ако не свързахме данните с нищо (нито група, нито потребител), както изглежда правех в предишните части на тази поредица от статии, тогава ще имаме предизвикателство да „почистим“ остарели данни, когато потребител бъде изтрит от онлайн анкетата приложение. Като го свърже с по-абстрактното понятие „група“, тогава става възможно собственикът да преотстъпи собствеността върху групата и всички съответни данни (анкети, въпроси, отговори и т.н.) на друг член на групата, ако е необходимо.
Официален дизайн
След това разширяваме ERD, който беше създаден в другите части на тази поредица от статии.
Оцветих таблиците, които бяха създадени в статията част 1, в жълто, оцветих таблиците, добавени в част 2, в оранжево, оцветих таблиците, добавени в част 3, в зелено, а новодобавените таблици в светлосиньо, за да е по-лесно вижте допълненията. Цвят не беше добавен към колоните и външните ключове, които бяха добавени в тази последна статия, така че ще трябва да сравните текущия модел с предишния от част 3, за да видите разликите.
Отчети и анализи
Имаме достатъчно информация, която може да бъде извлечена от таблиците, за да създадем няколко отчета.
Например, на кои въпроси е отговорено по определен начин („при анкета 7, колко пъти респондентите са отговорили с „Да“ на въпрос 10?“). Това ниво на информация вероятно е подходящо за основни отчети за отговорите на анкетата.
Можем също да извлечем колко време е било необходимо на респондентите, за да отговорят на конкретно проучване („при анкета 5 средното време, прекарано в анкетата е 13 минути“); отново, това може да бъде полезна информация, така че собствениците на анкета да могат да коригират въпросите на анкетата, така че да не изискват повече време от това, което типичният респондент е готов да похарчи или това, което анкетьорът е „обещал“ на респондентите (напр. „това анкета трябва да отнеме между 5 и 10 минути”). Знам, че когато някой ми каже, че трябва да свърша за по-малко от 10 минути, а аз все още разглеждам въпроси 15 минути по-късно, тогава се ядосвам и по принцип не искам да отговарям на друга анкета от тях.
Въз основа на IP адресите на респондентите бихме могли да направим малко обратно търсене, за да имаме приблизителна представа откъде са респондентите или поне откъде изглежда техният IP адрес, когато са отговорили. Имайте предвид, че тази информация не е напълно надеждна, тъй като хората могат да се свързват чрез VPN мрежи или други механизми, които отделят техния IP адрес от физическото им местоположение.
Можем дори да извлечем как се отговаря на въпросите от първите респонденти в сравнение с това как е отговорено от последните респонденти. Това може да представлява интересен ъгъл на вашето проучване – например, нетърпеливите хора, които отговориха на анкетата първо, отговориха ли по различен начин от хората, които не бяха толкова нетърпеливи и отговориха на анкетата по-късно?
На този етап смятам, че тези отчети ще са достатъчни и че по-напреднали анализи не са необходими, тъй като най-важната информация очевидно е основният отчет за това какви отговори са дадени на всеки въпрос в една анкета. Ако имате нужда от по-разширени анализи, тогава помислете какви са вашите изисквания и как съществуващите данни или новите структури могат да поддържат тези анализи.
Заключение
И ето го. Няма да твърдя, че това е дизайнът за идеалната база данни за онлайн анкети, но това ще отговори на моите нужди по отношение на гъвкавостта:множество анкети, повторно използване на въпроси, отговори с множество възможности за избор, подреждане на въпроси, условни скокове в анкетата въз основа на отговори и контрол върху достъпа на потребителите до анкети чрез групи собственици на анкети.
Както направих във всяка предходна част от тази поредица от статии, ще отбележа, че може да имате други изисквания. Идентифицирайте вашите изисквания и приложете или адаптирайте това, от което се нуждаете. Силно вярвам в повторната употреба, а не в преоткриването на колелото.
Ако искате да преработим или разширим този модел според нуждите на вашето приложение, уведомете ни. Ние можем да ви помогнем.
Модел на база данни за онлайн проучване – €“ цялата серия
 Част 1 | Част 2 |  Част 3 |  Част 4 |
