it-swarm-eu.dev

Umfragedatenbankdesign: Ordnen Sie einem Benutzer eine Antwort zu

Ich mache das konzeptionelle Modell für eine Umfragedatenbank.

Das Ziel ist es, die Antworten der Benutzer zu speichern (es wird eine Android App) sein.

Ich habe drei Entitäten: Benutzer, Frage und Option.

Eine Frage hat eine oder mehrere Optionen (zum Beispiel: Wie viele Mitarbeiter haben Sie? 1-40, 40-1000, +1000).

Optionen haben einen Text (1-40) und einen Wert (den vom Benutzer ausgewählten Wert).

Der Benutzer wählt eine (oder mehrere) dieser Optionen aus.

Mein Konzeptentwurf lautet:

enter image description here

Ich weiß nicht, wie ich einem Benutzer eine Antwort zuordnen soll.

Wie kann ich diese Beziehung darstellen?
Habe ich eine andere Entität, die den Optionswert darstellt?

Dieses Modell speichert Fragen und vorgefertigte Antworten (angebotene Antworten) und ermöglicht die Wiederverwendung in verschiedenen Umfragen.

Ich muss eine Frage wie diese darstellen:

enter image description here

Diese Frage bezieht sich auf diese: mfragedatenbankdesign: erste Version. Gibt es Fehler?

12
VansFannel

Sie müssen zwischen den Antworten möglich und den Antworten ausgewählt unterscheiden.

Die Tabelle Option muss aus zwei Tabellen bestehen. Die Tabelle Option sollte 1: M bis Question sein und die möglichen Antworten auf diese Frage enthalten.

Dann müssen Sie eine neue Schnittpunktentität erstellen und sie Selected_Option Nennen, die zwischen User und Option liegt.

Wenn Ihre Frage dem Benutzer die Möglichkeit gibt, einen Wert als Antwort einzugeben (d. H. "SONSTIGES: ..."), wird dieser Wert in der Tabelle Selected_Option Gespeichert. Andernfalls wäre der vom Benutzer gewählte Wert der in Option gefundene Wert.


EDIT :

Basierend auf der Klärung der Anforderungen durch OP: Was Sie benötigen, ist nicht wie ein typisches Fragebogenmodell auf folgende Weise:

  • Ihre Fragen haben alle die gleichen Antworten (Spalten)
  • Einige Ihrer Antworten (Spalten) sind zusammengefasst.
  • Fragenblöcke werden zusammengefasst.

Ausgehend von Ihrem Formular-Snapshot habe ich die Elemente Ihres Formulars in Entitäten unterteilt, die ich farbcodiert habe:

Colour Coded Form Example

Dies könnte durch die folgende logische ERD berücksichtigt werden:

Logical ERD

Beachten Sie, dass ich die Entitäten in der ERD farbcodiert habe, um dem Schnappschuss Ihres Beispielformulars zu entsprechen und die Korrelation anzuzeigen.

Eine der Annahmen in diesem Modell ist, dass jeder Block nur einen Satz von Quesitons hat (d. H. Einen QUESTION_GROUP), Der der linken Spalte im Block entspricht. Dies ist eine vereinfachende Annahme.

7
Joel Brown

Umfragedatenbankschema.

Dies ist ein echter Klassiker, der von Tausenden gemacht wird. Sie scheinen immer "ziemlich einfach" zu sein, aber um gut zu sein, ist es eigentlich ziemlich komplex. Um dies in Rails] zu tun, würde ich das im beigefügten Diagramm gezeigte Modell verwenden. Ich bin sicher, dass es für einige viel zu kompliziert erscheint, aber wenn Sie einige davon erstellt haben, über das Jahre erkennen Sie, dass die meisten Entwurfsentscheidungen sehr klassische Muster sind, die am besten durch eine dynamische, flexible Datenstruktur am Anfang berücksichtigt werden.
Weitere Details unten:

enter image description here

Tabellendetails für Schlüsseltabellen

antworten

Die Tabelle answers ist wichtig, da sie die tatsächlichen Antworten der Benutzer erfasst. Sie werden feststellen, dass Antworten Links zu question_options, nicht zu Fragen enthalten. Dies ist beabsichtigt.

input_types

input_types sind die Arten von Fragen. Jede Frage kann nur von einem Typ sein, z. Alle Radiowählscheiben, alle Textfelder usw. Verwenden Sie zusätzliche Fragen, wenn (sagen wir) 5 Radiowählscheiben und 1 Kontrollkästchen für ein "Einschließen?" Option oder eine solche Kombination. Beschriften Sie die beiden Fragen in der Benutzeransicht als eine, haben Sie jedoch intern zwei Fragen, eine für die Radiowählscheiben und eine für das Kontrollkästchen. Das Kontrollkästchen hat in diesem Fall eine Gruppe von 1.

option_groups

option_groups und option_choices lassen Sie 'gemeinsame' Gruppen erstellen. Ein Beispiel in einer Immobilienanwendung könnte die Frage sein, wie alt die Immobilie ist. Die Antworten könnten in den Bereichen 1-5 6-10 10-25 25-100 100+ erwünscht sein

Wenn dann beispielsweise eine Frage zum Alter der angrenzenden Immobilien vorliegt, möchte die Umfrage die oben genannten Bereiche wiederverwenden, damit dieselbe Optionsgruppe und dieselben Optionen verwendet werden.

maßeinheiten

nit_of_measure ist so wie es sich anhört. Ob es sich um Zoll, Tassen, Pixel, Steine ​​oder was auch immer handelt, Sie können es hier einmal definieren.

Zu Ihrer Information: Obwohl generischer Natur, kann darüber hinaus eine Anwendung erstellt werden, und dieses Schema eignet sich gut für das Framework Ruby on Rails mit Konventionen wie "id" für den Primärschlüssel Tabelle. Außerdem sind die Beziehungen alle einfach eins zu viele, ohne dass viele oder viele Durchgänge erforderlich sind. Ich würde wahrscheinlich has_many: throughs und/oder: delegates hinzufügen, um Dinge wie poll_name einfach aus einer einzelnen Antwort zu erhalten, ohne mehrfache Verkettung.

13
Michael Durrant

Schauen Sie sich diese allgemeine Idee an:

enter image description here

(Der Kürze halber sind im obigen Modell nur die wichtigsten Felder enthalten.)

Dieses Modell hat die folgenden Eigenschaften:

  • Eine einzelne Frage kann von mehreren Umfragen geteilt werden (und eine einzelne Umfrage kann natürlich mehrere Fragen enthalten). Die SURVEY_QUESTION ist die "Link" -Tabelle, die diese M: N-Beziehung implementiert.
  • Die Reihenfolge der Fragen in der Umfrage wird durch SURVEY_QUESTION.QUESTION_NO bestimmt. Da {SURVEY_NO, QUESTION_NO} ein (alternativer) Schlüssel ist, der im obigen Diagramm mit U1 Bezeichnet ist, können keine zwei Fragen denselben "Slot" in derselben Umfrage belegen. Verschiedene Umfragen können dieselben Fragen in unterschiedlicher Reihenfolge haben.
  • Jede Frage hat eine Reihe möglicher Antworten oder "Optionen". Die visuelle Reihenfolge der Optionen wird durch OPTION.OPTION_NO bestimmt, und da es sich in der PK befindet, können keine zwei Optionen unter derselben Frage denselben "Steckplatz" belegen.
  • Verschiedene Benutzer können unterschiedliche Antworten auf dieselbe Frage geben (und natürlich kann ein Benutzer mehrere Fragen beantworten). Diese M: N-Beziehung wird über die "Link" -Tabelle ANTWORT implementiert.
  • Ein Benutzer beantwortet die Frage, indem er höchstens eine seiner Optionen wählt. Dies wird durch ohne OPTION_NO aus der PK der ANTWORT sichergestellt. Wenn Sie dem Benutzer die Auswahl mehrerer Optionen ermöglichen möchten, fügen Sie OPTION_NO in die PK ein.

In diesem Datenmodell gibt es nichts, was den Benutzer dazu zwingt, all die Fragen zu beantworten - dies ist etwas, was Sie auf Anwendungsebene tun müssen. Trotzdem sollte dieses Modell ein guter Anfang für das sein, was Sie tun müssen ...

2

Sie benötigen eine weitere Tabelle, um die Antworten der Benutzer zu speichern.

 user_answers 
 ------------ 
 user_answer_id - eindeutiger Primärschlüssel 
 user_id - FK zur Benutzertabelle 
 selected_option_id - FK zur Optionstabelle 
 Question_id - FK zur Fragentabelle 

Wenn Sie möchten, dass Benutzer "Andere" als Option auswählen und ihren eigenen Wert eingeben können, würde ich eine separate Tabelle dafür empfehlen:

 user_alt_answers 
 ---------------- 
 user_alt_answer_id - PK 
 Alt_answer_text - Text, den der Benutzer für ein " andere "Option. 
 user_answeR_id - FK zur Tabelle user_answers 

[Ich kann noch keinen Kommentar abgeben, daher dies als Antwort]

Für die von VansFannel vorgestellte Lösung habe ich dort ein vollständigeres Modell erstellt.

Bitte hier überprüfen .