Ich suche nach Ratschlägen zum besten relationalen Modellierungsansatz zum Speichern von Umfragen, Fragen und Antworten.

Ich suche nach einem der beiden folgenden Ansätze oder nach einem alternativen Ansatz.

Ich habe mindestens diese Entitäten:

• Frage
• Umfrage
• Person

Und zumindest diese Beziehungen:

• Jede Umfrage hat 1 oder mehr Fragen.
• Jede Frage kann in 0 oder mehr Umfragen verwendet werden.
• Jede Person kann an 0 oder mehr Umfragen teilnehmen.

Hier stoße ich auf Probleme: Wie modelliere ich die Antworten auf Umfragefragen einer Person?

Hier sind zwei Ansätze, die ich in Betracht gezogen habe, von denen mir keiner sehr gut erscheint. Die Diagramme hier sind stark vereinfacht, um das Problem zu veranschaulichen.

Ansatz 1:

Was ich an diesem Ansatz nicht mag:

• Die survey_person_question_responseTabelle enthält zwei verschiedene Spalten, die sich auf eine Umfrage beziehen: survey_question_survey_idundsurvey_person_survey_id
  • Es wäre ein Fehler, wenn survey_idfür diese beiden Spalten in einer Zeile unterschiedliche Verweise vorhanden wären . Die Umfrage_Frage muss aus derselben Umfrage stammen wie die Person, die an der Umfrage_Person teilgenommen hat. Ich sehe keinen guten Weg, dies durchzusetzen.
• Es scheint, als würde ich hier eine Beziehung zwischen zwei Beziehungen herstellen. Das fühlt sich für mich aus irgendeinem Grund falsch an.

Ansatz 2:

Versuchen Sie, zwei FKs aus Ansatz 1 zu vermeiden, die sich auf denselben Wert beziehen sollten ...

Was ich an diesem Ansatz nicht mag:

• Es gibt keine Durchsetzung, dass die question_idund survey_idFKs von einem gültigen survey_questionPaar stammen
• Es gibt keine Durchsetzung, dass die survey_idund person_idFKs von einem gültigen survey_personPaar stammen

Irgendwelche Ratschläge zu:

• Ob einer dieser Ansätze ein typischer Ansatz ist
• Die Vor- und Nachteile eines dieser Ansätze gegenüber dem anderen
• Eine bessere Möglichkeit, diese Daten vollständig anzuordnen

Würde mich sehr freuen!

Nach meinem Verständnis Ihrer Spezifikationen umfasst Ihr Geschäftsumfeld eine ternäre Beziehung auf konzeptioneller Ebene . In diesem Zusammenhang müssen Sie Folgendes definieren:

1. den Beziehungstyp (oder Assoziationstyp ) zwischen den Entitätstypen Person und Umfrage ;
2. der Beziehungstyp zwischen Umfrage und Frage ;
3. der Beziehungstyp, der die Verbindung zwischen den beiden oben genannten Beziehungstypen und folglich zwischen Person , Umfrage und Frage herstellt , dh Antwort (ein kürzerer Name, der aus meiner Sicht die Interpretation vereinfacht).

Ich bin also der Meinung, dass Sie mit Ihrem Ansatz 1 auf dem richtigen Weg sind , obwohl einige kleine (aber wichtige) Verbesserungen erforderlich sind, um ihn genauer zu machen. Ich werde solche Verfeinerungen und andere relevante Überlegungen in den folgenden Abschnitten detailliert beschreiben.

Geschäftsregeln

Lassen Sie uns die geltenden Geschäftsregeln ein wenig erweitern und sie folgendermaßen umformulieren:

• Eine Person registriert sich in Null-Eins-oder-Viele- Umfragen
• Bei einer Umfrage werden null, eins oder viele Personen registriert
• Eine Umfrage wird durch Eins-zu-Viele- Fragen integriert
• Eine Frage integriert Null-Eins-oder-Viele- Umfragen
• Eine Frage erhält null, eins oder viele Antworten
• Eine Antwort wird von genau einer Person im Rahmen von genau einer Umfrage bereitgestellt

Expository IDEF1X-Diagramm

Dann habe ich mit dem IDEF1X ^ein Diagramm erstellt, das in Abbildung 1 dargestellt ist und die oben formulierten Geschäftsregeln zusammenfasst:

_{^eine Definition Integration für Information Modeling ( IDEF1X ) ist eine sehr empfehlenswert Modellierungstechnik, die als etabliert wurde Standard im Dezember 1993 von dem Vereinigten Staaten National Institute of Standards and Technology ( NIST ). Es basiert solide auf theoretischen Arbeiten, die vom alleinigen Gründer des relationalen Modells , dh Dr. EF Codd, verfasst wurden, sowie auf dervon Dr. PP Chen entwickelten Sicht auf Entitätsbeziehungen .}

Die PersonSurvey- Beziehung

Aus meiner Sicht muss die PersonSurvey- Beziehung ein Autorisierungsmittel bereitstellen, damit eine Person an einer bestimmten Umfrage teilnehmen kann . Auf diese Weise ist eine bestimmte Person , sobald sie in einer bestimmten Umfrage registriert wurde , berechtigt, Antworten auf die Fragen zu geben , die die jeweilige Umfrage integrieren .

Die SurveyQuestion- Beziehung

Ich gehe davon aus, dass die Eigenschaft (oder Attribut) genannt suvery_question.question_number in Ihrem Diagramm verwendet wird , um das darzustellen Auftrag der Darstellung einer bestimmten Frage wiese im Hinblick auf eine bestimmte Umfrage . Wie Sie sehen können, habe ich eine solche Eigenschaft als SurveyQuestion.PresentationOrder bezeichnet , und ich denke, Sie sollten verhindern, dass (i) zwei oder mehr Question.QuestionNumber- Werte (ii) denselben PresentationOrder- Wert in (iii) demselben SurveyQuestion- Vorkommen aufweisen.

Um diesen Bedarf darzustellen, habe ich einen zusammengesetzten ALTERNATIVEN SCHLÜSSEL (AK) in das Feld für diesen Entitätstyp aufgenommen, der aus der Kombination von Eigenschaften ( SurveyNumber, QuestionNumber, PresentationOrder ) besteht. Wie Sie wissen, kann ein zusammengesetzter AK mithilfe einer mehrspaltigen UNIQUE-Einschränkung in einem logischen DDL-Entwurf deklariert werden (wie ich in der SurveyQuestionTabelle veranschaulicht habe, die Teil des DDL-Layouts des Expository ist, das in den folgenden Abschnitten erläutert wird).

Die Antwort Entitätstyp

Ja, mit dem Entitätstyp " Antwort" zeige ich eine Beziehung zwischen zwei anderen Beziehungen . es kann auf den ersten Blick umständlich erscheinen , aber es ist nichts falsch mit diesem Ansatz, solange sie (a) die Merkmale des Business - Kontext von Interesse genau darstellt und (b) ordnungsgemäß in einer logischen Ebene Layout dargestellt.

Ja, Sie haben völlig Recht. Es wäre ein Fehler, diesen Teil des Szenarios auf der logischen Abstraktionsebene mithilfe von zwei Response.SurveyNumber(oder beispielsweise Response.SurveyId) Werten darzustellen, auf die aus zwei verschiedenen Spalten in derselben ResponseZeile verwiesen wird .

Abgeleitetes logisches SQL-DDL-Layout

-- You should determine which are the most fitting 
-- data types and sizes for all your table columns 
-- depending on your business context characteristics.

-- As one would expect, you are free to make use of 
-- your preferred (or required) naming conventions.

CREATE TABLE Person (
    PersonId        INT      NOT NULL,
    FirstName       CHAR(30) NOT NULL,
    LastName        CHAR(30) NOT NULL,
    GenderCode      CHAR(3)  NOT NULL,
    BirthDate       DATE     NOT NULL,
    CreatedDateTime DATETIME NOT NULL,
    --
    CONSTRAINT Person_PK PRIMARY KEY (PersonId),
    CONSTRAINT Person_AK UNIQUE      (
        FirstName,
        LastName,
        GenderCode,
        BirthDate
    )
);

CREATE TABLE Survey (
    SurveyNumber    INT       NOT NULL,
    Description     CHAR(255) NOT NULL,
    CreatedDateTime DATETIME  NOT NULL,
    --
    CONSTRAINT Survey_PK PRIMARY KEY (SurveyNumber),
    CONSTRAINT Survey_AK UNIQUE      (Description)
);

CREATE TABLE PersonSurvey (
    PersonId           INT      NOT NULL,
    SurveyNumber       INT      NOT NULL,
    RegisteredDateTime DATETIME NOT NULL,
    --
    CONSTRAINT PersonSurvey_PK         PRIMARY KEY (PersonId, SurveyNumber),
    CONSTRAINT PersonSurveyToPerson_FK FOREIGN KEY (PersonId)
        REFERENCES Person (PersonId),
    CONSTRAINT PersonSurveyToSurvey_FK FOREIGN KEY (SurveyNumber)
        REFERENCES Survey (SurveyNumber)
);

CREATE TABLE Question (
    QuestionNumber  INT       NOT NULL,
    Wording         CHAR(255) NOT NULL,
    CreatedDateTime DATETIME  NOT NULL,
    --
    CONSTRAINT Question_PK PRIMARY KEY (QuestionNumber),
    CONSTRAINT Question_AK UNIQUE      (Wording)
);

CREATE TABLE SurveyQuestion (
    SurveyNumber       INT      NOT NULL,
    QuestionNumber     INT      NOT NULL,
    PresentationOrder  TINYINT  NOT NULL,
    IsMandatory        BIT      NOT NULL,
    IntegratedDateTime DATETIME NOT NULL,
    --
    CONSTRAINT SurveyQuestion_PK PRIMARY KEY (SurveyNumber, QuestionNumber),
    CONSTRAINT SurveyQuestion_AK UNIQUE      (
        QuestionNumber,
        SurveyNumber,
        PresentationOrder
    ),
    CONSTRAINT SurveyQuestionToSurvey_FK   FOREIGN KEY (SurveyNumber)
        REFERENCES Survey   (SurveyNumber),
    CONSTRAINT SurveyQuestionToQuestion_FK FOREIGN KEY (QuestionNumber)
        REFERENCES Question (QuestionNumber)
);

CREATE TABLE Response (
    SurveyNumber     INT      NOT NULL,
    QuestionNumber   INT      NOT NULL,
    PersonId         INT      NOT NULL,
    Content          TEXT     NOT NULL,
    ProvidedDateTime DATETIME NOT NULL,
    --
    CONSTRAINT Response_PK                 PRIMARY KEY (SurveyNumber, QuestionNumber, PersonId),
    CONSTRAINT ResponseToPersonSurvey_FK   FOREIGN KEY (PersonId, SurveyNumber)
        REFERENCES PersonSurvey   (PersonId, SurveyNumber),
    CONSTRAINT ResponseToSurveyQuestion_FK FOREIGN KEY (SurveyNumber, QuestionNumber)
        REFERENCES SurveyQuestion (SurveyNumber, QuestionNumber)
);

Zwei zusammengesetzte AUSLÄNDISCHE SCHLÜSSEL in der ResponseTabelle

Dies ist wahrscheinlich der wichtigste Punkt, den es zu diskutieren gilt: die Verweise, die aus einer bestimmten ResponseZeile an stammen

1. SurveyQuestion.SurveyNumber, und
2. SurveyPerson.SurveyNumber

muss übereinstimmende Werte haben . Für mich besteht die beste Möglichkeit, diese Bedingung deklarativ durchzusetzen, darin, zwei zusammengesetzte AUSLÄNDISCHE SCHLÜSSEL (FKs) zu verwenden.

Wie im DDL-Entwurf gezeigt, verweist der erste FK auf die PersonSurveyTabelle PRIMARY KEY (PK), dh (PersonId, SurveyNumber), und wird durch die Spalten Response.PersonIdund angepasst Response.SurveyNumber.

Die zweite FK zeigt auf die SurveyQuestionTabelle PK, dh, (SurveyNumber, QuestionNumber)und besteht dementsprechend aus den Spalten Response.SurveyNumberund Response.QuestionNumber.

Auf diese Weise ist die Response.SurveyNumberSpalte sehr hilfreich, da sie als Teil einer FK-Referenz in zwei verschiedenen Einschränkungen verwendet wird.

Mit dieser Methode wird eine vom Datenbankverwaltungssystem garantierte referenzielle Integrität von sichergestellt

• (a) Responsean die PersonSurvey;
• (b) Responsean die SurveyQuestion; und
• (c) jeder der Tabellen repräsentiert ein assoziatives Entitätstyp auf die Tabellen für unabhängige Entitätstypen stehen, und zwar Person, Surveyund Question.

Abgeleitete Daten, um Aktualisierungsanomalien zu vermeiden

Ich habe in Ihrem Diagramm zwei Elemente festgestellt, die meiner Meinung nach erwähnenswert sind. Diese Elemente beziehen sich auf zwei PersonSurveySpalten, die abgeleitet werden können (sollten) .

In dieser Hinsicht können Sie die Ableitung PersonSurvey.IsStartedDatum durch Abfrage , ob ein bestimmtes PersonEreignis einen oder mehr zur Verfügung gestellt hat , Responsesum QuestionsDASS integriert einen exakte Surveyüber den SurveyQuestionTisch.

Sie können den PersonSurvey.IsCompletedDatenpunkt auch erhalten , indem Sie bestimmen, ob eine bestimmte PersonInstanz Responseallen, die Questionseinen Wert von 'TRUE' in der IsMandatorySpalte in einer bestimmten SurveyQuestionZeile enthalten, einen Wert geliefert hat .

Durch die Ableitung dieser Werte verhindern Sie einige Aktualisierungsanomalien, die eventuell aufgetreten wären, wenn Sie solche Werte in der SurveyQuestionSpalte behalten hätten .

Wichtige Überlegung

Wie @Dave in seinem Kommentar zu Recht hervorhebt , müssen Sie dieses Datenbanklayout erweitern, wenn Sie einer zukünftigen Anforderung gegenüberstehen, die die Verwaltung verschiedener Arten von Antworten erfordert, die die Verwaltung von Daten, numerischen Werten, Multiple-Choice und anderen möglichen Aspekten beinhalten.

Dies ist ein Grund, warum ich Spalten bei der Migration als Fremdschlüssel nicht gerne voranstellen möchte. In Ihrem ersten Fall erzwingt das Modellierungswerkzeug möglicherweise, dass Sie einer der survey_idSpalten in der survey_person_question_responseTabelle ein Präfix voranstellen . Möglicherweise können Sie dies anpassen, nachdem die Beziehung hergestellt wurde.

Entfernen Sie gegebenenfalls das Feld für die redundante Umfrage-ID, wenn Sie das physische Modell erstellen, für das Sie die duplizierte Spalte nicht benötigen. Wie Sie festgestellt haben, haben beide Modelle Probleme, aber ich glaube, das erste Modell ist insgesamt besser.