Ich mache das konzeptionelle Modell für eine Umfragedatenbank.

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

Ich habe drei Einheiten: Benutzer, Frage und Option.

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

Die Optionen haben einen Text (1-40) und einen Wert (der vom Benutzer ausgewählte Wert).

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

Mein konzeptionelles Design ist:

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

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

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

Ich muss eine Frage wie diese darstellen:

Diese Frage bezieht sich auf folgende Frage: Entwurf der Umfragedatenbank : erste Version. Gibt es fehler

Sie müssen zwischen den möglichen Antworten und den ausgewählten Antworten unterscheiden.

Die OptionTabelle muss aus zwei Tabellen bestehen. Die OptionTabelle sollte 1: M sein Questionund die möglichen Antworten für diese Frage enthalten.

Dann müssen Sie eine neue Kreuzungsentität erstellen, Selected_Optiondie sich zwischen Userund befindet Option.

Wenn Ihre Frage dem Benutzer die Möglichkeit gibt, einen Wert als Antwort einzugeben (dh "OTHER: ..."), wird dieser Wert in der Selected_OptionTabelle gespeichert . Andernfalls würde der vom Benutzer gewählte Wert dem Wert in entsprechen Option.

BEARBEITEN:

Basierend auf der Klärung der Anforderungen durch OP: Was Sie benötigen, ist in den folgenden Punkten kein typisches Fragebogenmodell:

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

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

Dies könnte durch die folgende logische ERD ausgeglichen werden:

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

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

Umfragedatenbank-Schema.

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 mir sicher, dass es für einige viel zu kompliziert erscheint, aber wenn Sie im Laufe der Jahre ein paar davon zusammengestellt haben, werden Sie feststellen, dass die meisten Entwurfsentscheidungen sehr klassische Muster sind, die am besten durch eine dynamische, flexible Datenstruktur am besten angegangen werden Anfang.
Weitere Details unten:

Tabellendetails für Schlüsseltabellen

Antworten

Die Antworten Tabelle ist von entscheidender Bedeutung , da sie die tatsächlichen Antworten von Nutzern erfasst. Sie werden feststellen, dass Antworten auf Fragenoptionen verweisen , nicht auf Fragen . Das ist beabsichtigt.

eingabetypen

input_types sind die Arten von Fragen. Jede Frage kann nur von einem Typ sein, z. B. alle Radiowahlen, alle Textfelder usw. Verwenden Sie zusätzliche Fragen, wenn beispielsweise 5 Radiowahlen 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 Radiowahl und eine für das Kontrollkästchen. Das Kontrollkästchen hat in diesem Fall eine Gruppe von 1.

option_groups

Mit option_groups und option_choices können Sie "gemeinsame" Gruppen erstellen . In einer Immobilienanwendung könnte beispielsweise die Frage "Wie alt ist die Immobilie?" Die Antworten können in den Bereichen 1-5 6-10 10-25 25-100 100+ erwünscht sein

Wenn es dann zum Beispiel eine Frage zum Alter der angrenzenden Immobilien gibt, wird die Umfrage die obigen Bereiche "wiederverwenden" wollen, damit dieselbe Optionsgruppe und dieselben Optionen verwendet werden.

Maßeinheiten

units_of_measure ist so, wie es sich anhört. Ob Zoll, Cups, Pixel, Bricks oder was auch immer, Sie können es hier einmal definieren.

Zu Ihrer Information: Obwohl es sich um eine generische Anwendung handelt, kann darüber hinaus eine Anwendung erstellt werden. Dieses Schema eignet sich gut für das Ruby On Rails- Framework mit Konventionen wie "id" für den Primärschlüssel für jede Tabelle. Auch die Beziehungen sind alle einfach, ohne dass viele oder viele Durchgänge erforderlich sind. Ich würde wahrscheinlich has_many: throughs und / oder: delegates hinzufügen, um Dinge wie survey_name einfach aus einer einzelnen Antwort zu erhalten, ohne dass .multiple.chaining.

Sehen Sie sich diese allgemeine Idee an:

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

Dieses Modell hat folgende 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 es sich bei {SURVEY_NO, QUESTION_NO} um einen (alternativen) Schlüssel handelt, der U1im obigen Diagramm mit gekennzeichnet ist, können in derselben Umfrage keine zwei Fragen denselben "Slot" belegen. Verschiedene Umfragen können die gleichen Fragen in einer anderen Reihenfolge haben.
• Jede Frage hat eine Reihe von möglichen Antworten oder "Optionen". Die visuelle Reihenfolge der Optionen wird durch OPTION.OPTION_NO bestimmt. Da sich diese in der PK befindet, können unter derselben Frage keine zwei Optionen 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 durch die "Link" -Tabelle ANTWORT implementiert.
• Ein Benutzer beantwortet die Frage, indem er höchstens eine seiner Optionen auswählt. Dies wird durch den Ausschluss von OPTION_NO von der ANTWORT-PK sichergestellt . Wenn Sie dem Benutzer erlauben möchten, mehrere Optionen auszuwählen, fügen Sie OPTION_NO in die PK ein.

In diesem Datenmodell gibt es nichts, was den Benutzer dazu zwingt, alle Fragen zu beantworten. Dies müssen Sie auf Anwendungsebene tun. Dennoch sollte dieses Modell ein guter Anfang für das sein, was Sie tun müssen ...

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
  chosen_option_id - FK zur Optionstabelle
  question_id - FK zur Fragentabelle

Wenn Sie möchten, dass Benutzer die Option "Andere" auswählen und ihren eigenen Wert eingeben können, empfehle ich eine separate Tabelle:

user_alt_answers
----------------
  user_alt_answer_id - PK
  alt_answer_text - Text, den der Benutzer für eine "andere" Option eingegeben hat.
  user_answeR_id - FK zur user_answers-Tabelle

[Ich kann noch nicht kommentieren, daher dies als Antwort]

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

Bitte überprüfen Sie es hier .