Verbesserung des Datenbankdesigns für Online-Prüfungen

Anfangsantwort

Die Daten verstehen

Sie haben gute Arbeit geleistet. Soweit die Daten betroffen sind, ist das Design korrekt, aber unvollständig. Es gibt zwei Fehler:

1. opt1…opt4 ist eine sich wiederholende Gruppe, die 2NF bricht. Es muss in einer separaten Tabelle platziert werden.

   • Außerdem scheint es keinen Optionsnamen oder -deskriptor zu geben, der seltsam ist (was malt man auf der Seite neben jedem Optionsfeld?)

   • Wenn Sie jemals eine fünfte Option hinzufügen, ist das nun möglich; Wenn Sie Fragen mit weniger als vier Optionen haben, ist dies jetzt möglich.

   • Umgekehrt haben Sie eine feste Anzahl von Spalten, und wenn solche Änderungen in der Zukunft auftreten, müssen Sie sowohl die Datenbank als auch den vorhandenen Code ändern. Und der Code wird horrend sein (zusätzliche Verarbeitung statt direkter SELECTs)

2. Ihre Tabelle answers hat keine Integrität. So wie es aussieht, können Antworten auf eine Frage aufgezeichnet werden, die der Schüler nicht gefragt wurde, oder auf einen Test, bei dem der Schüler nicht saß. Die Vermeidung dieses Fehlertyps ist ein gewöhnlicher Tarif in einer relationalen Datenbank und in einem Datensatzanmeldungssystem nicht möglich.

   • In diesen dunklen Tagen der IT ist dies ein allgemeiner Trend. Menschen konzentrieren sich auf die Daten -Werte ; Sie stellen sich die -Werte in Tabellenform vor und sie gehen direkt zum implementierenden Objekt, das diese -Werte enthält . Anstatt die Daten zu verstehen und was es bedeutet.

   • answers(stud_id, que_id, answer) hat keine Bedeutung, keine Integrität, es sei denn, der Kontext eines student_test wird bestätigt.

3. Das dritte Element ist kein Fehler, weil Sie es nicht als Voraussetzung angegeben haben. Es scheint mir jedoch, dass eine Frage in mehr als einem Test verwendet werden kann. Wie Sie es eingerichtet haben, werden solche Fragen dupliziert (der ganze Sinn einer Datenbank besteht darin, sie zu normalisieren, so dass es keine Duplizierung gibt).

   • Die Konsequenz ist natürlich eine assoziative Tabelle, test_question.

Fragen

  

Auf diese Weise können Antworten gespeichert werden, aber sie erhöhen die Anzahl der Datensätze, da für jede vom Schüler gelöste Frage ein neuer Datensatz in der Antworttabelle hinzugefügt wird.

Ja. Das ist normal für eine Datenbank.

  

Gibt es einen besseren Weg, dies zu tun, wenn die Anzahl der Datensätze geringer ist.

Für ein Record Filing System, ja. Für eine Datenbank, nein. Da Sie Ihre Frage als Datenbank-Design markiert haben, gehe ich davon aus, dass Sie das wollen.

Eine Datenbank ist eine Sammlung von Fakten, nicht von Datensätzen mit verwandten Feldern. Die Fakten beziehen sich auf die reale Welt, beschränkt auf den Umfang der Datenbank und App.

Es ist wichtig, die diskreten Fakten zu bestimmen, die wir brauchen, weil untergeordnete Fakten von Fakten höherer Ordnung abhängen. Das ist Datenbank-Design. Und wir normalisieren die Daten, während wir Fortschritte machen, als Teil ein und derselben Übung. Normalisierung hat den Zweck, Duplikate zu eliminieren, ansonsten haben Sie Update Anomalien. Und wir bestimmen relationale Schlüssel, wenn wir Fortschritte machen, wieder als Teil ein und derselben Übung. Relationale Schlüssel stellen die logische Struktur einer relationalen Datenbank dar, d. die logische Integrität.

  

z.B. Ein Test besteht aus 100 Fragen und 1000 Studenten machen diesen Test, für jeden Studenten gibt es 100 Datensätze für jede Frage und für 1000 Studenten 100k Datensätze.

Ja. Aber das drückt sich in den ISAM-Satzverarbeitungsbedingungen aus. In Bezug auf die Datenbank können Sie nicht die Tatsache umgehen, dass die Datenbank speichert:

• Fakten über 100 Fragen

• Fakten über 1.000 Studenten

• Fakten über 1.000 Studenten mal die 100 Entscheidungen, die sie getroffen haben

Sie müssen sich mit zwei Dingen beschäftigen: mit der großen Anzahl von diskreten Fakten; und die Verwendung von zusammengesetzten Schlüsseln. Beide sind wichtig für relationale Datenbanken. Wenn einer dieser Faktoren fehlt oder Sie ihn widerstrebend implementieren, haben Sie nicht die Integrität, Leistung oder Geschwindigkeit einer relationalen Datenbank. Sie verfügen über ein ISAM-Registrierungssystem vor 1970.

Außerdem sind die SQL-Plattformen und bis zu einem gewissen Grad die NONsql-Plattformen wie myNONsql stark für die Verarbeitung von Datensätzen optimiert (nicht Datensatz für Datensatz). Schweres I / O und Caching; usw. Wenn Sie die Strukturen implementieren, die für hohe Parallelität erforderlich sind, erhalten Sie noch mehr Leistung.

Implementierung

Was die Implementierung und insbesondere die Leistung angeht, gibt es Fehler. Eine Neuformulierung wäre, die Implementierung sollte nicht versucht werden, bis die Daten richtig verstanden und modelliert sind.

Das Problem auf der ganzen Linie besteht darin, dass Sie ein Ersatzzeichen hinzugefügt haben (es gibt keinen "Ersatzschlüssel", es ist einfach ein Ersatzzeichen, eine physische Datensatz-ID).Es ist viel zu früh in der Modellierung; es ist nicht genug fortgeschritten; das Modell ist nicht stabil, um Surrogate hinzuzufügen.

• Surrogate sind immer eine zusätzliche Spalte und der zugrunde liegende Index. Offensichtlich verbraucht das Ressourcen und hat Kosten für Einfügen und Löschen.

• Surrogate bieten keine Zeileneindeutigkeit , die in einer relationalen Datenbank verlangt wird.

• Das relationale Modell verlangt, dass Keys aus den Daten bestehen. Relationale Schlüssel bieten Zeileneindeutigkeit.

• Ein Surrogat besteht nicht aus den Daten. Daher ist es kein relationaler Schlüssel und bietet keine der Eigenschaften eines.

• Wenn ein Ersatzzeichen verwendet wird, ersetzt es nicht den Schlüssel, es ist zusätzlich für den Schlüssel. Deshalb evaluieren wir die Notwendigkeit von Surrogaten erst nach der Modellierung der Daten. Es handelt sich um eine Implementierung, nicht um eine Modellierung.