Wie hilft Datenbankdesign bei der Organisation von Lehrern, Unterricht und Schülern?

Eine Investition in Wissen bringt die besten Zinsen.

Benjamin Franklin

In der modernen Welt ist Bildung allgegenwärtig. Sie spielt heute mehr denn je eine wichtige Rolle in unserer Gesellschaft. Es ist in der Tat so wichtig, dass viele von uns ihre Ausbildung weit nach Abschluss der Schule oder des Studiums fortsetzen.

Wir alle haben schon von lebenslangem Lernen, informeller Bildung und Workshops für alle Altersgruppen gehört. Diese Methoden unterscheiden sich in vielerlei Hinsicht von der formalen Bildung, haben aber auch Gemeinsamkeiten. Es gibt Klassen, Lektionen, Lehrer und Schüler. Und genau wie in einer traditionellen Umgebung möchten wir den Stundenplan, die Anwesenheitsdaten und die Leistungen von Lehrern oder Schülern im Auge behalten. Wie können wir eine Datenbank entwerfen, die diese Anforderungen erfüllt? Das werden wir in diesem Artikel behandeln.

Wir stellen unser Bildungsdatenbankmodell vor

Das in diesem Artikel vorgestellte Modell ermöglicht es uns, Daten zu speichern über:

• Klassen/Vorträge
• Lehrer/Dozenten
• Schüler
• Vorlesungsbesuch
• Leistung der Studierenden / Dozenten

Wir könnten dieses Modell auch als Stundenplan für die Schule, für andere Gruppenaktivitäten (Schwimmunterricht, Tanzworkshops) oder sogar für Einzelaktivitäten wie Nachhilfe verwenden. Es gibt noch viel Raum für Verbesserungen, wie z. B. das Speichern von Kursortdaten oder Workshop-Dauer; Wir werden diese in den kommenden Artikeln behandeln.

Beginnen wir mit unseren grundlegenden Elementen der Education-Datenbank:den Tabellen.

Die großen Drei:Schüler-, Lehrer- und Klassentabellen

Der student , instructor , und class Tabellen bilden den Kern unserer Datenbank.

Der student Die oben gezeigte Tabelle wird verwendet, um grundlegende Daten über Schüler zu speichern, sie kann jedoch entsprechend den spezifischen Anforderungen erweitert werden. Mit Ausnahme der drei Kontaktattribute sind alle Attribute in der Tabelle erforderlich:

• first_name – Name des Schülers
• last_name – der Nachname des Schülers
• birth_date – das Geburtsdatum des Schülers
• contact_phone – die Telefonnummer des Schülers
• contact_mobile – die Handynummer des Schülers
• contact_mail – die E-Mail-Adresse des Schülers
• category_id – ist ein Verweis auf die category Katalog. Mit dieser Struktur sind wir auf nur eine Kategorie pro Schüler beschränkt. Das funktioniert in den meisten Fällen, aber in einigen Situationen benötigen wir möglicherweise Platz, um mehrere Kategorien aufzulisten. Wie Sie sehen, fügen Sie eine Viele-zu-Viele-Beziehung hinzu, die student Tabelle mit der category Wörterbuch löst dieses Problem. In diesem Szenario müssen wir jedoch etwas komplexere Abfragen schreiben, um mit unseren Daten umzugehen.

Da wir es bereits erwähnt haben, lassen Sie uns fortfahren und die category Tabelle hier.

Diese Tabelle ist ein Wörterbuch, mit dem Schüler nach bestimmten Kriterien gruppiert werden. Der name -Attribut sind die einzigen Daten in der Tabelle (neben id , der Primärschlüssel) und es ist obligatorisch. Ein Satz von Werten, die hier gespeichert werden könnten, ist der Beschäftigungsstatus des Studenten:„Student“, „Beschäftigt“, „Arbeitslos“ und „Rentner“. Wir könnten auch andere Sets verwenden, die auf sehr spezifischen Kriterien basieren, wie „mag Yoga“, „mag Wandern“, „mag Fahrrad fahren“ und „mag nichts“.

Der instructor Tabelle enthält eine Liste aller Ausbilder/Dozenten in der Organisation. Die Attribute in der Tabelle sind:

• first_name – Name des Dozenten
• last_name – Nachname des Dozenten
• title – Titel des Ausbilders (falls vorhanden)
• birth_date – das Geburtsdatum des Ausbilders
• contact_phone – die Telefonnummer des Dozenten
• contact_mobile – die Handynummer des Dozenten
• contact_mail – die E-Mail-Adresse des Dozenten

Der title und alle drei contact Attribute sind nicht obligatorisch.

Der student Tisch und instructor Tabelle haben eine ähnliche Struktur, aber es gibt eine andere Möglichkeit, diese Informationen zu organisieren. Ein zweiter Ansatz wäre, eine person Tabelle (in der alle Mitarbeiter- und Studentendaten gespeichert sind) und hat eine Viele-zu-Viele-Beziehung, die uns alle dieser Person zugewiesenen Rollen mitteilt. Der wichtigste Vorteil des zweiten Ansatzes besteht darin, dass wir Daten nur einmal speichern. Wenn jemand in einer Klasse Lehrer und in einer anderen Schüler ist, erscheint er nur einmal in der Datenbank, aber mit beiden definierten Rollen.

Warum haben wir den Zwei-Tabellen-Ansatz für unser Bildungsdatenbankmodell gewählt? Generell verhalten sich Studierende und Lehrende unterschiedlich, sowohl im realen Leben als auch in unserer Datenbank. Aus diesem Grund kann es sinnvoll sein, ihre Daten separat zu speichern. Wir können andere Möglichkeiten finden, um die Informationen zur gleichen Person, die in beiden Tabellen erscheinen, zusammenzuführen (z. B. ein Paar von Einfüge-/Aktualisierungsabfragen basierend auf einer externen ID, wie z. B. einer Sozialversicherungsnummer oder einer Umsatzsteuer-Identifikationsnummer).

Die class table ist ein Katalog, der Details zu allen Klassen enthält. Wir können mehrere Instanzen jedes Klassentyps haben. Die Attribute in der Tabelle lauten wie folgt (alle sind obligatorisch, außer end_date ):

• class_type_id – ist ein Verweis auf class_type Wörterbuch.
• name – ist ein Kurzname der Klasse.
• description – diese Beschreibung ist spezifischer als die im class_type Tabelle.
• start_date – das Startdatum des Kurses.
• end_date – das Enddatum des Kurses. Es ist nicht obligatorisch, da wir möglicherweise nicht immer das genaue Enddatum für jeden Kurs im Voraus wissen.
• completed – ist ein boolescher Wert, der angibt, ob alle geplanten Unterrichtsaktivitäten abgeschlossen sind. Das ist praktisch, wenn wir die geplante end_time erreicht haben für eine Klasse, aber andere Klassenaktivitäten müssen noch abgeschlossen werden.

Der class_type table ist ein einfacher Katalog, der grundlegende Informationen über die angebotenen Vorlesungen oder Kurse für Studenten speichern soll. Es könnte Werte wie „Englische Sprache (Gruppe)“, „Polnische Sprache (Gruppe)“, „Kroatische Sprache (Gruppe)“, „Englische Sprache (persönlich)“ oder „Tanzunterricht“ enthalten. Es hat nur zwei Pflichtattribute – name und description , die beide keiner weiteren Erklärung bedürfen.

Der class_schedule Tabelle enthält bestimmte Zeiten für Vorlesungen und Kurse. Alle Attribute in der Tabelle sind obligatorisch. Die class_id -Attribut ist ein Verweis auf die class Tabelle, während start_time und end_time sind die Anfangs- und Endzeiten dieser bestimmten Vorlesung.

Wer ist hier? Anwesenheitsbezogene Tabellen

Die attend Tabelle speichert Informationen darüber, welcher Schüler welche Klasse besucht hat, und das Endergebnis. Die Attribute in der Tabelle sind:

• student_id – ist ein Verweis auf student Tabelle
• class_id – ist ein Verweis auf die class Tabelle
• class_enrollment_date – ist das Datum, an dem der Schüler mit dem Besuch dieser Klasse begonnen hat
• class_drop_date – das Datum, an dem der Schüler den Unterricht beendet hat. Dieses Attribut hat nur dann einen Wert, wenn der Schüler den Unterricht vor dem Enddatum des Unterrichts abgebrochen hat. In diesem Fall die drop_class_reason_id Attributwert muss ebenfalls gesetzt werden.
• drop_class_reason_id – ist ein Verweis auf drop_class_reason Tabelle
• attendance_outcome_id – ist ein Verweis auf attendance_outcome Tabelle

Alle Daten außer class_drop_date und drop_class_reason_id erforderlich. Diese beiden werden besetzt, wenn und nur wenn ein Schüler die Klasse abbricht.

Der drop_attendance_reason table ist ein Wörterbuch, das die verschiedenen Gründe enthält, warum ein Student einen Kurs abbrechen könnte. Es hat nur ein Attribut, reason_text , und es ist obligatorisch. Ein Beispielsatz von Werten könnte beinhalten:„Krankheit“, „Interesse verloren“, „hat nicht genug Zeit“ und „andere Gründe“.

Das attendance_outcome Die Tabelle enthält Beschreibungen über die Aktivitäten der Studenten in einem bestimmten Kurs. Der outcome_text ist das einzige Attribut in der Tabelle und erforderlich. Mögliche Werte sind:„in Bearbeitung“, „erfolgreich abgeschlossen“, „teilweise abgeschlossen“ und „Kurs nicht abgeschlossen“.

Wer ist verantwortlich? Unterrichtsbezogene Tabellen

Der teach , drop_teach_reason und teach_outcome Tabellen verwenden dieselbe Logik wie attend , drop_attendance_reason und attendance_outcome Tische. Alle diese Tabellen speichern Daten über die kursbezogenen Aktivitäten der Dozenten.

Der teach Tabelle wird verwendet, um Informationen darüber zu speichern, welcher Lehrer welche Klasse unterrichtet. Die Attribute in der Tabelle sind:

• instructor_id – ist ein Verweis auf den instructor Tabelle.
• class_id – ist ein Verweis auf die class Tabelle.
• start_date – ist das Datum, an dem der Kursleiter mit der Arbeit an diesem Kurs begonnen hat.
• end_date – ist das Datum, an dem der Kursleiter die Arbeit an diesem Kurs eingestellt hat. Es ist nicht obligatorisch, da wir nicht im Voraus wissen können, ob der Kursleiter bis zum Enddatum des Kurses unterrichten wird.
• drop_teach_reason_id – ist ein Verweis auf drop_teach_reason Tisch. Es ist nicht obligatorisch, da der Kursleiter den Kurs nicht abbrechen darf.
• teach_outcome_id – ist ein Verweis auf teach_outcome_reason Tabelle.

Der drop_teach_reason Tabelle ist ein einfaches Wörterbuch. Es enthält eine Reihe möglicher Erklärungen, warum der Kursleiter den Unterricht vor dem Enddatum beendet hat. Es gibt nur ein obligatorisches Attribut:reason_text . Das kann „Krankheit“, „Wechsel zu anderem Projekt/Stelle“, „Aufhören“ oder „anderer Grund“ sein.

Das teach_outcome Tabelle beschreibt den Erfolg des Dozenten in einem bestimmten Kurs. Der outcome_text ist das einzige Attribut der Tabelle und erforderlich. Mögliche Werte für diese Tabelle könnten sein:„in Bearbeitung“, „erfolgreich abgeschlossen“, „teilweise abgeschlossen“ und „nicht abgeschlossene Lehrveranstaltung“.

Der student_presence Tabelle wird verwendet, um Daten über die Anwesenheit von Studenten für eine bestimmte Vorlesung zu speichern. Wir können davon ausgehen, dass der Dozent für jede Vorlesung die An- und/oder Abwesenheit aller Studierenden vermerkt. Die Attribute in der Tabelle sind:

• student_id – ist ein Verweis auf student Tabelle
• class_schedule_id – ist ein Verweis auf class_schedule Tabelle
• present – ist eine boolesche Kennzeichnung, ob der Student in der Vorlesung anwesend ist oder nicht

Wir könnten die Anwesenheit von Schülern in einer bestimmten Klasse mit einer Abfrage wie der folgenden überwachen (vorausgesetzt, dass @id_class die gewünschte Klassen-ID enthält).

SELECT
	a.id, 
	CONCAT(a.first_name, ' ', a.last_name) AS student_name,
	a.number_total, 
	CONCAT(CONVERT(a.number_present / a.number_total * 100, DECIMAL(5,2)), '%') AS percentage,
	a.attendance_outcome
FROM
(
SELECT 
	student.id, 
	student.first_name, 
	student.last_name, 
	SUM(CASE WHEN student_presence.present = True THEN 1 ELSE 0 END) AS number_present,
	COUNT(DISTINCT class_schedule.id) AS number_total,
	attendance_outcome.outcome_text AS attendance_outcome
FROM class
	INNER JOIN attend ON class.id = attend.class_id
	INNER JOIN student ON attend.student_id = student.id
	LEFT JOIN class_schedule ON class_schedule.class_id = class.id
	LEFT JOIN student_presence ON student_presence.student_id = student.id AND student_presence.class_schedule_id = class_schedule.id
	LEFT JOIN attendance_outcome ON attendance_outcome.id = attend.attendance_outcome_id
WHERE class.id = @id_class
GROUP BY 
	student.id, 
	student.first_name, 
	student.last_name, 
	attendance_outcome.outcome_text
) a  

Die Tabelle „instructor_presence“ verwendet die gleiche Logik wie die Tabelle „student_presence“, aber hier wollen wir uns auf die Dozenten konzentrieren. Die Attribute in der Tabelle sind:

• instructor_id – ist ein Verweis auf den instructor Tabelle
• class_schedule_id – ist ein Verweis auf class_schedule Tabelle
• present – ist ein boolescher Wert, der angibt, ob der Dozent in der Vorlesung anwesend ist oder nicht

Wir könnten die folgende Abfrage verwenden, um die Aktivität des Kursleiters im Unterricht zu überwachen:

SELECT
	a.id, 
	CONCAT(a.first_name, ' ', a.last_name) AS instructor_name,
	a.number_total,
	CONCAT(CONVERT(a.number_present / a.number_total * 100, DECIMAL(5,2)), '%') AS percentage,
	a.teach_outcome
FROM
(
SELECT 
	instructor.id, 
	instructor.first_name, 
	instructor.last_name, 
	SUM(CASE WHEN instructor_presence.present = True THEN 1 ELSE 0 END) AS number_present,
	COUNT(DISTINCT class_schedule.id) AS number_total,
	teach_outcome.outcome_text AS teach_outcome
FROM class
	INNER JOIN teach ON class.id = teach.class_id
	INNER JOIN instructor ON teach.instructor_id = instructor.id
	LEFT JOIN class_schedule ON class_schedule.class_id = class.id
	LEFT JOIN instructor_presence ON instructor_presence.instructor_id = instructor.id AND instructor_presence.class_schedule_id = class_schedule.id
	LEFT JOIN teach_outcome ON teach_outcome.id = teach.teach_outcome_id
WHERE class.id = @id_class
GROUP BY 
	instructor.id, 
	instructor.first_name, 
	instructor.last_name, 
	teach_outcome.outcome_text
) a 

Lassen Sie uns nun mit der Besprechung der Kontaktpersonentabellen abschließen.

Wen können wir anrufen? Kontaktpersonentabellen

In den meisten Fällen müssen wir keine Kontaktinformationen für Notfälle speichern (d. h. wenden Sie sich im Notfall an diese Person). Dies ändert sich jedoch, wenn wir Kinder unterrichten. Laut Gesetz oder Sitte müssen wir für jedes Kind, das wir unterrichten, eine Kontaktperson haben. In unseren Mustertabellen – contact_person , contact_person_type und contact_person_student – wir zeigen, wie das geht.

Die contact_person Tabelle ist eine Liste von Personen, die mit Studenten verwandt sind. Natürlich müssen wir nicht alle Verwandten auflisten; Meistens haben wir ein oder zwei Kontakte pro Student. Dies ist ein guter Weg, um herauszufinden, „wen Sie anrufen werden“, wenn der Schüler früher gehen muss oder möchte. Die Attribute in der Tabelle sind:

• first_name – ist der Name der Kontaktperson
• last_name – ist der Nachname der Person
• contact_phone – ist die Telefonnummer der Person
• contact_mobile – ist die Handynummer der Person
• contact_mail – ist die E-Mail-Adresse der Person

Kontaktdaten sind nicht obligatorisch, aber sehr nützlich.

Der contact_person_type table ist ein Wörterbuch mit einem einzigen erforderlichen Attribut:type_name . Beispiele für in dieser Tabelle gespeicherte Werte sind:„Mutter“, „Vater“, „Bruder“, „Schwester“ oder „Onkel“.

Der contact_person_student Tabelle ist eine Viele-zu-Viele-Beziehung, die Kontaktpersonen und deren Typ mit Studenten verbindet. Die Attribute in der Tabelle sind (alle sind obligatorisch):

• contact_person_id – ist ein Verweis auf contact_person Tabelle
• student_id – ist ein Verweis auf student Tabelle
• contact_person_type_id – ist ein Verweis auf contact_person_type Tabelle

Erwähnenswert ist vielleicht, dass diese Viele-zu-Viele-Beziehung drei Tabellen miteinander verbindet. Das Attributpaar contact_person_id und student_id wird als alternativer (EINZIGARTIGER) Schlüssel verwendet. Auf diese Weise deaktivieren wir doppelte Einträge, die einzelne Schüler mit derselben Kontaktperson verbinden. Das Attribut contact_person_type_id ist kein Teil des alternativen Schlüssels. Wenn dies der Fall ist, könnten wir mehrere Beziehungen für dieselbe Kontaktperson und denselben Schüler haben (unter Verwendung verschiedener Arten von Beziehungen), und das macht in Situationen des wirklichen Lebens keinen Sinn.

Das in diesem Artikel vorgestellte Modell sollte in der Lage sein, die häufigsten Anforderungen abzudecken. Dennoch können in einigen Fällen Teile des Modells ausgeschlossen werden, z. Wir würden wahrscheinlich nicht das gesamte Kontaktpersonensegment benötigen, wenn unsere Schüler Erwachsene sind. Wie ich bereits sagte, werden wir mit der Zeit Verbesserungen hinzufügen. Fühlen Sie sich frei, Vorschläge hinzuzufügen und Ihre Erfahrungen in den Diskussionsabschnitten zu teilen.