Lassen Sie uns weitere Änderungen in das Datenmodell einbauen, das ich in meinem früheren Blogbeitrag erstellt habe, wie z. B. einen automatisierten Ansatz für die Zuweisung eines Lehrers und eines Fahrzeugs zu einer Unterrichtsstunde, die Rechnungsstellung an Kunden und deren Nachverfolgung.
Zunächst einmal muss ich auf der Anwendungsseite eine Logik aufbauen, um den Unterricht einen Ausbilder und ein Fahrzeug zuzuweisen, bevor sie tatsächlich stattfinden. Hier ist vor allem die Erreichbarkeit zu gewährleisten, d.h. ein Lehrer oder Fahrzeug kann nur dann einer Unterrichtsstunde zugeteilt werden, wenn beide zum geplanten Unterrichtstermin verfügbar sind.
Ich muss zwei separate Tabellen erstellen, um die Belegung für Ausbilder bzw. Fahrzeug zu verfolgen. Sie fragen sich vielleicht, warum ich beabsichtige, die Belegung statt die Verfügbarkeit zu verfolgen. Die Antwort lautet:Wenn wir die Belegung anstelle der Verfügbarkeit verfolgen, müssen wir keine weiteren Tabellen erstellen, um die Nichtverfügbarkeit von Ressourcen aufgrund von Ausbildern geplanter Abwesenheit oder eines planmäßigen Service für Fahrzeuge zu speichern. Im Falle einer geplanten Nichtverfügbarkeit werden die Datensätze entsprechend in Belegungstabellen eingefügt.
Ich gehe hier davon aus, dass Ausbilder und Fahrzeuge nur während der Geschäftszeiten, sagen wir 8:00 bis 18:00 Uhr, an von der Schule festgelegten Werktagen verfügbar sind. Daher kann ich sagen, dass ein Lehrer zu einer bestimmten Zeit an einem Werktag verfügbar ist, wenn ich seine Belegungsdetails für die angegebene Zeit und den angegebenen Tag nicht im staff_occupancy Tabelle.
Die Struktur für die Tabelle staff_occupancy lautet wie folgt:
Einige Variationen können nach Bedarf eingefügt werden. Beispielsweise sollte zwischen zwei aufeinanderfolgenden Unterrichtsstunden für einen Ausbilder mindestens 15 Minuten Pause liegen.
Die Struktur für die Tabelle vehicle_occupancy lautet wie folgt:
Die Zuordnung von Instruktor und Fahrzeug wird im reservation Tisch. Ich hatte bereits zwei Spalten hinzugefügt, staff_id und vehicle_id , in diese Tabelle. Diese Zuweisungen erfolgen natürlich auf der Grundlage ihrer Verfügbarkeit.
Außerdem behalte ich reservation_id in der staff_occupancy und vehicle_occupancy Tabellen, damit bei Unterrichtsausfall die entsprechende Personal- und Fahrzeugbelegung einfach freigegeben werden kann. Aber ich werde diese beiden Spalten als nullable behalten da die Belegung von Instruktoren und Fahrzeugen nicht zwangsläufig auf Reservierungen zurückzuführen ist. Was ist, wenn ein Ausbilder in Urlaub geht? Oder eines der Fahrzeuge geht für einen Tag ins Servicecenter?
Um in solchen Szenarien vorläufiges Löschen zu ermöglichen, füge ich eine Spalte namens is_active hinzu in diesen beiden Tabellen.
Rechnungsstellung
Für die Rechnungsstellung erstelle ich eine Tabelle, nämlich invoice , um Rechnungsdetails einschließlich customer_id zu speichern und reservation_id . Hier soll die Abrechnung gegenüber dem Kunden erfolgen, jedoch auf Basis der für den Kunden durchgeführten Unterrichtseinheiten. Daher benötigen wir die reservation_id Spalte in der Rechnungstabelle, so dass man zu jedem beliebigen Zeitpunkt einen Bericht über die detaillierte Rechnungsstellung basierend auf einer Reservierung für einen Kunden abrufen kann. Ich werde auch eine Spalte erstellen, nämlich invoice_status_id , in der Tabelle zum Speichern des Rechnungsstatus.
Datenbankmodell
Hier ist die aktualisierte Datenbankstruktur, die in Vertabelo entworfen wurde:
Schlussfolgerung
Sicher glauben Sie inzwischen, dass die Datenmodellierung für ein Reservierungssystem einer Fahrschule genauso interessant und charmant ist wie das Fahren lernen?
Sie können gerne Ihre Fragen und Anregungen zum Artikel posten. Gerne beantworte ich sie und baue Ihre Vorschläge in meinen nächsten Artikel ein.
