it-swarm-eu.dev

Návrh databáze průzkumu: přiřaďte odpověď uživateli

Dělám koncepční model pro průzkumovou databázi.

Cílem je uložit odpovědi poskytnuté uživateli (bude to aplikace Android)).

Mám tři entity: uživatel, otázka a možnost.

Otázka bude mít jednu nebo více možností (například: Kolik zaměstnanců máte? 1-40, 40-1000, +1000).

Možnosti budou mít text (1-40) a hodnotu (hodnota vybraná uživatelem).

Uživatel vybere jednu (nebo více) z těchto možností.

Můj koncepční návrh je:

enter image description here

Nevím, jak přiřadit odpověď k uživateli.

Jak mohu tento vztah reprezentovat?
Mám jinou entitu, která představuje hodnotu opce?

Tento model bude ukládat otázky a předem připravené odpovědi (nabízené odpovědi) a umožňuje je znovu použít v různých průzkumech.

Musím reprezentovat takovou otázku:

enter image description here

Tato otázka se týká této otázky: Návrh databáze průzkumu: první verze. Existují chyby?

12
VansFannel

Musíte rozlišovat mezi možnými odpověďmi a vybranými odpověďmi.

Tabulka Option musí být dvě tabulky. Tabulka Option by měla být 1: M až Question a měla by zahrnovat možné odpovědi na tuto otázku.

Pak musíte vytvořit novou průnikovou entitu, nazvat ji Selected_Option, která leží mezi User a Option.

Pokud vaše otázka dává uživateli příležitost vyplnit hodnotu jako odpověď (tj. „JINÉ: ...“), bude tato hodnota uložena do Selected_Option stůl. Jinak by hodnota vybraná uživatelem byla hodnota nalezená v Option.


ÚPRAVA:

Na základě vyjasnění požadavků OP: Co potřebujete, není jako typický model dotazníku následujícími způsoby:

  • Všechny vaše otázky mají stejné sady odpovědí (sloupce)
  • Některé z vašich odpovědí (sloupců) jsou seskupeny dohromady.
  • Bloky otázek jsou seskupeny dohromady.

Jako vodítko jsem použil snímek formuláře a rozdělil jsem prvky vašeho formuláře na entity, které jsem barevně označil:

Colour Coded Form Example

To by mohlo být doplněno následující logickou ERD:

Logical ERD

Všimněte si, že jsem barevně kódoval entity v ERD tak, aby odpovídaly snímku vašeho vzorového formuláře, abych ukázal korelaci.

Jedním z předpokladů v tomto modelu je, že každý blok má pouze jednu sadu quesitons (tj. Jeden QUESTION_GROUP), která odpovídá levému sloupci v bloku. To je trochu zjednodušující předpoklad.

7
Joel Brown

Schéma databáze průzkumu.

Toto je skutečná klasika, kterou provedli tisíce. Na začátku se vždy zdá být „docela jednoduché“, ale být dobrý, je to vlastně docela složité. Chcete-li to provést v Rails, použil bych model zobrazený v přiloženém diagramu. Jsem si jist, že se zdá, že pro některé z nich je to komplikovanější, ale jakmile některé z nich postavíte, let, si uvědomujete, že většina rozhodnutí o designu jsou velmi klasické vzory, nejlépe řešené dynamickou flexibilní datovou strukturou na začátku.
Další podrobnosti níže:

enter image description here

Podrobnosti tabulky pro klíčové tabulky

odpovědi

Tabulka odpovědi je kritická, protože zachycuje skutečné odpovědi uživatelů. Zjistíte, že odpovědi odkazují na question_options, nikoli otázky. To je záměrné.

input_types

input_types jsou typy otázek. Každá otázka může být pouze 1 typu, např. všechny rádiové volby, všechna textová pole, atd. Použijte další otázky pro případ, kdy existuje (řekněte) 5 rádiových čísel a 1 zaškrtávací políčko pro "zahrnout?" možnost nebo nějakou takovou kombinaci. Označte dvě otázky v pohledu uživatelů jako jednu, ale interně mají dvě otázky, jednu pro rádiové vytáčení a druhou pro zaškrtávací políčko. Zaškrtávací políčko bude mít v tomto případě skupinu 1.

option_groups

option_groups a option_choices vám umožní vytvářet 'běžné' skupiny. Jedním z příkladů je, že v realitní aplikaci může být otázka „Jak starý je majetek?“. Odpovědi mohou být požadovány v rozsahu: 1-5 6-10 10-25 25-100 100+

Pak například, pokud existuje otázka týkající se přilehlého věku majetku, průzkum bude chtít „znovu použít“ výše uvedené rozsahy, aby se využila stejná volba_skupiny a možností.

jednotky měření

nits_of_measure zní, jak to zní. Ať už se jedná o palce, poháry, pixely, cihly nebo cokoli, můžete to jednou definovat zde.

FYI: Ačkoli je to v podstatě druhové, lze vytvořit aplikaci navíc a toto schéma je vhodné pro rámec Ruby on Rails s konvencemi, jako je „id“ pro primární klíč pro každý stůl. Vztahy jsou také jednoduché one_to_many's bez potřeby many_to_many nebo has_many. Pravděpodobně bych přidal has_many: throughs a/nebo: delegates ačkoli získat věci, jako je průzkum_name z individuální odpovědi snadno bez.multiple.chaining.

13
Michael Durrant

Podívejte se na tento obecný nápad:

enter image description here

(Pro stručnost jsou ve výše uvedeném modelu zahrnuta pouze nejdůležitější pole)

Tento model má následující vlastnosti:

  • Jedna otázka může být sdílena mezi více průzkumy (a jediný průzkum samozřejmě může obsahovat více otázek). SURVEY_QUESTION je tabulka "link", která implementuje tento vztah M: N.
  • Pořadí otázek v průzkumu určuje SURVEY_QUESTION.QUESTION_NO. Protože {SURVEY_NO, QUESTION_NO} je (alternativní) klíč, označený U1 ve výše uvedeném diagramu nemohou ve stejném průzkumu obsáhnout stejný „slot“ dvě otázky. Různé průzkumy mohou mít stejné otázky v jiném pořadí.
  • Každá otázka má řadu možných odpovědí nebo „možností“. Vizuální pořadí voleb je určeno OPTION.OPTION_NO a protože je v PK, nemohou dvě stejné možnosti obsáhnout stejný „slot“ pod stejnou otázkou.
  • Různí uživatelé mohou poskytnout různé odpovědi na stejnou otázku (a samozřejmě jeden uživatel může odpovědět na více otázek). Tento vztah M: N je implementován pomocí tabulky „ODPOVĚĎ“ ODPOVĚĎ.
  • Uživatel odpoví na otázku výběrem maximálně jednoho jeho možností. Toto je zajištěno kromě OPTION_NO z PK ODPOVĚDI. Pokud chcete uživateli umožnit výběr více možností, přidejte do PK OPTION_NO.

V tomto datovém modelu není nic, co nutí uživatele odpovídat na všechny otázky - to je něco, co musíte udělat na úrovni aplikace. Tento model by však měl být dobrým začátkem toho, co musíte udělat ...

2

K zodpovězení odpovědí uživatelů budete potřebovat další tabulku.

 user_answers 
 ------------ 
 user_answer_id - jedinečný primární klíč 
 user_id - FK do tabulky uživatelů 
 selected_option_id - FK na tabulku možností 
 Question_id - FK na tabulku otázek 

Pokud se rozhodnete, že uživatelé budou mít možnost vybrat možnost „Jiné“ a vyplnit vlastní hodnotu, doporučuji k tomu samostatnou tabulku:

 user_alt_answers 
 ---------------- 
 user_alt_answer_id - PK 
 alt_answer_text - text, který uživatel zadal pro text „ jiná "možnost. 
 user_answeR_id - FK do tabulky user_answers 

[Nemohu zatím komentovat, proto to jako odpověď]

Pro řešení, které VansFannel představil, jsem tam vytvořil kompletnější model.

Prosím zaškrtněte zde .