Sto realizzando il modello concettuale per un database di sondaggi.

L'obiettivo è memorizzare le risposte fornite dagli utenti (sarà un'app per Android).

Ho tre entità: utente, domanda e opzione.

Una domanda avrà una o più opzioni (ad esempio: quanti dipendenti hai? 1-40, 40-1000, +1000).

Le opzioni avranno un testo (1-40) e un valore (il valore selezionato dall'utente).

L'utente selezionerà una (o più) di queste opzioni.

Il mio design concettuale è:

Non so come associare una risposta a un utente.

Come posso rappresentare quella relazione?
Ho un'altra entità per rappresentare il valore dell'opzione?

Questo modello memorizza le domande e le risposte predefinite (risposte offerte) e consente di riutilizzarle in diversi sondaggi.

Devo rappresentare una domanda come questa:

Questa domanda è collegata a questa: Progettazione del database dei sondaggi: prima versione. Ci sono errori?

Devi fare una distinzione tra le possibili risposte e le risposte selezionate .

La Optiontabella deve essere composta da due tabelle. La Optiontabella dovrebbe essere 1: M a Questione dovrebbe includere le possibili risposte a quella domanda.

Quindi è necessario creare una nuova entità di intersezione, chiamarla Selected_Optionche si trova tra Usere Option.

Se la tua domanda offre all'utente la possibilità di inserire un valore come risposta (es. "ALTRO: ..."), questo valore verrebbe memorizzato nella Selected_Optiontabella. Altrimenti il ​​valore scelto dall'utente sarebbe il valore trovato in Option.

MODIFICARE:

Sulla base del chiarimento dei requisiti del PO: ciò di cui hai bisogno non è come un tipico modello di questionario nei seguenti modi:

• Le tue domande hanno tutte le stesse serie di risposte (colonne)
• Alcune delle tue risposte (colonne) sono raggruppate insieme.
• I blocchi di domande sono raggruppati insieme.

Prendendo la tua istantanea del modulo come guida, ho diviso gli elementi del tuo modulo in entità che ho codificato a colori:

Questo potrebbe essere soddisfatto dal seguente ERD logico:

Si noti che ho codificato a colori le entità nell'ERD per corrispondere all'istantanea del modulo di esempio per mostrare la correlazione.

Una delle ipotesi in questo modello è che ogni blocco ha un solo set di quesitoni (cioè uno QUESTION_GROUP) che corrisponde alla colonna di sinistra nel blocco. Questo è un presupposto semplificativo.

Schema del database dei sondaggi.

Questo è un vero classico, fatto da migliaia. Sembrano sempre "abbastanza semplici", ma per essere buoni è in realtà piuttosto complesso. Per fare questo in Rails userei il modello mostrato nello schema allegato. Sono sicuro che sembra complicato per alcuni, ma una volta che ne hai costruiti alcuni, nel corso degli anni, ti rendi conto che la maggior parte delle decisioni di progettazione sono modelli molto classici, meglio affrontati da una struttura di dati dinamica dinamica fin.
Maggiori dettagli di seguito:

Dettagli della tabella per le tabelle chiave

risposte

La tabella delle risposte è fondamentale in quanto acquisisce le risposte effettive da parte degli utenti. Noterai che risponde ai link a question_options , non a domande . Questo è intenzionale.

input_types

input_types sono i tipi di domande. Ogni domanda può essere solo di 1 tipo, ad esempio tutte le selezioni radio, tutti i campi di testo, ecc. Usa domande aggiuntive per quando ci sono (diciamo) 5 composizioni radio e 1 casella di controllo per un "include?" opzione o una tale combinazione. Etichetta le due domande nella vista degli utenti come una, ma internamente hanno due domande, una per i quadranti radio, una per la casella di controllo. La casella di controllo avrà un gruppo di 1 in questo caso.

option_groups

option_groups e option_choices ti consentono di creare gruppi "comuni". Un esempio, in un'applicazione immobiliare potrebbe esserci la domanda "Quanti anni ha la proprietà?". Le risposte potrebbero essere desiderate negli intervalli: 1-5 6-10 10-25 25-100 100+

Quindi, ad esempio, se c'è una domanda sull'età della proprietà adiacente, il sondaggio vorrà "riutilizzare" gli intervalli di cui sopra, in modo che vengano utilizzati lo stesso gruppo_opzioni e opzioni.

unità di misura

units_of_measure è come sembra. Che si tratti di pollici, tazze, pixel, mattoni o altro, puoi definirlo una volta qui.

Cordiali saluti: Sebbene di natura generica, è possibile creare un'applicazione in aggiunta a questo, e questo schema è adatto al framework Ruby On Rails con convenzioni come "id" per la chiave primaria per ogni tabella. Inoltre, le relazioni sono tutte semplici one_to_many senza molte_to_many o has_many through necessarie. Vorrei probabilmente aggiungere has_many: throughs e / o: delegates per ottenere facilmente cose come survey_name da una singola risposta senza più.

Dai un'occhiata a questa idea generale:

(Solo i campi più essenziali sono inclusi nel modello sopra, per brevità).

Questo modello ha le seguenti caratteristiche:

• Una singola domanda può essere condivisa tra più sondaggi (e il singolo sondaggio, ovviamente, può contenere più domande). SURVEY_QUESTION è la tabella "link" che implementa questa relazione M: N.
• L'ordine delle domande nel sondaggio è determinato da SURVEY_QUESTION.QUESTION_NO. Poiché {SURVEY_NO, QUESTION_NO} è un tasto (alternativo), indicato dal U1diagramma sopra, nessuna domanda può occupare lo stesso "spazio" nello stesso sondaggio. Sondaggi diversi possono avere le stesse domande in un ordine diverso.
• Ogni domanda ha una serie di possibili risposte o "opzioni". L'ordine visivo delle opzioni è determinato da OPTION.OPTION_NO e, poiché si trova nel PK, non ci sono due opzioni che possono occupare lo stesso "slot" sotto la stessa domanda.
• Utenti diversi possono fornire risposte diverse alla stessa domanda (e, ovviamente, un utente può rispondere a più domande). Questa relazione M: N viene implementata tramite la tabella "link" ANSWER.
• Un utente risponde alla domanda scegliendo al massimo una delle sue opzioni. Ciò è garantito escludendo OPTION_NO dal PK di ANSWER. Se si desidera consentire all'utente di selezionare più opzioni, includere OPTION_NO nel PK.

Non c'è nulla in questo modello di dati che costringa l'utente a rispondere a tutte le domande - questo è qualcosa che devi fare a livello di applicazione. Tuttavia, questo modello dovrebbe essere un buon inizio per quello che devi fare ...

Avrai bisogno di un'altra tabella per contenere le risposte degli utenti.

user_answers
------------
  user_answer_id - chiave primaria univoca
  user_id - FK alla tabella utente
  chosen_option_id - FK nella tabella delle opzioni
  question_id - FK alla tabella delle domande

Se decidi di volere che gli utenti siano in grado di selezionare "Altro" come opzione e inserire il proprio valore, ti consiglio una tabella separata per questo:

user_alt_answers
----------------
  user_alt_answer_id - PK
  alt_answer_text: testo inserito dall'utente per un'opzione "altro".
  user_answeR_id - FK nella tabella user_answers

[Non posso ancora commentare, quindi questa come risposta]

Per la soluzione presentata da VansFannel, lì ho realizzato un modello più completo.

Per favore, controlla qui .