Datenbankmodell für das Reservierungssystem einer Fahrschule. Teil 1

Ich muss ein Datenmodell für ein Reservierungssystem für eine Fahrschule entwerfen. Das Themengebiet sieht recht einfach aus, aber es gibt immer noch Komplexitäten. Sie müssen alle Anfragen von Kunden verfolgen und die während des Unterrichts verbrauchten Ressourcen (Fahrzeug, Zeit und Ausbilder) im Auge behalten.

Einführung

Ich verwende gerne einen domänengesteuerten Ansatz zum Entwerfen eines Datenmodells. Es veranlasst mich, die Technologiebesessenheit beiseite zu legen und mich hauptsächlich auf die Modellierung des Fachgebiets zu konzentrieren, das sich um die zugehörigen Einheiten und Beziehungen untereinander dreht.

Anforderungen auf den Punkt gebracht

Lassen Sie mich zuerst die Anforderung in einfachem Englisch formulieren.

Ich benötige ein Datenmodell für eine Fahrschule, um Kunden zuzulassen um Reservierungen vorzunehmen für Unterricht online. Die Fahrschule kann mehr als einen Lehrer haben und mehr als ein Fahrzeug . Der Lehrer wird bei der Reservierung dem Unterricht zugeteilt. Das System sollte es Kunden ermöglichen, Reservierungen jederzeit vor dem geplanten Tag zu stornieren. Das dem Unterricht zugewiesene Fahrzeug sollte auch erfasst werden, wenn der Unterricht stattfindet.

Beteiligte Organisationen und Beziehungen

Wenn ich an das Thema denke, fallen mir als erstes folgende Entitäten ein:„Kunde“ , "Lehrer" , "Fahrstunde" , "Reservierungsanfrage" und "Fahrzeug" . Lassen Sie mich mit meiner allerersten Tabelle für dieses Modell beginnen, und das ist customer . Es soll Stammdaten für Kunden speichern. Ich würde wahrscheinlich eine weitere Tabelle zum Speichern der Dozentendetails benötigen, aber anstatt eine Tabelle mit dem Namen des Dozenten zu erstellen, werde ich eine generische Tabelle mit dem Namen staff für Personaldetails und behalten Sie „Ausbilder“ als Berufsbezeichnung bei. Es wird mein Datenmodell erweiterbar machen, um auch andere Dienstleistungsbereiche, wie Verwaltungs- und Rechtsarbeit, einer Fahrschule zu bedienen.

Ich betrachte "Fahrkurs" als einen der Dienste, also erstelle ich eine weitere Tabelle namens service . Ein Service, „Fahrkurs“ in diesem Fall kann es mehrere Unterrichtsstunden geben. Um dieser Anforderung gerecht zu werden, brauche ich sicherlich eine weitere Master-Tabelle, nämlich lesson , und eine Beziehungstabelle, nämlich service_lesson , um viele-zu-viele-Beziehungen zwischen diesen beiden Master-Entitäten zu verwalten, d. h. ein Dienst kann definitiv mehrere Lektionen haben, aber andererseits kann eine Lektion auch Teil von mehr als einem Dienst sein.

Wenn jemand eine Reservierungsanfrage einreicht, wird er/sie gebeten, seine/ihre Daten und vorläufigen Präferenzen einzugeben, wie z. B. welche Art von Service er/sie wünscht, die Wahl des Fahrzeugs und das Startdatum. Die Kundendaten werden in der Kundentabelle gespeichert. Anschließend wird im request Tabelle, und alle Präferenzen werden für die Anfrage in derselben Tabelle gespeichert. Mit jeder Anfrage sind bestimmte Status verbunden, wie „Senden“, „In Bearbeitung“, „Abbrechen“ und „Abgeschlossen“. Ich werde dafür eine unterstützende Tabelle mit dem Namen request_status .

Zum Zeitpunkt der Antragstellung gibt man eine Fahrzeugpräferenz, d. h. den Fahrzeugtyp, an. Allerdings würde das Fahrzeug tatsächlich einer Unterrichtsstunde zugeordnet werden, wenn diese stattfindet. Daher behalte ich vehicle_type_id als eine der Spalten in request Tabelle vorerst.

Wenn eine Anfrage bearbeitet wird, werden Reservierungen für jede Unterrichtsstunde der Serviceanfrage vorgenommen. Darüber hinaus werden jeder Lektion Instruktoren und Fahrzeuge basierend auf der Verfügbarkeit von Instruktoren und den Präferenzen der Kunden für Fahrzeuge zugewiesen. Unterrichtsstunden sind für zukünftige Termine mit dem Status „Offen“ geplant. All diese Details werden in einer weiteren Transaktionstabelle namens reservation . Ich habe alle Transaktionstabellen mit einer anderen Farbe als alle Haupttabellen hervorgehoben.

Eine Haupttabelle, reservation_status , wird erstellt, um alle möglichen Werte für Reservierungsstatus wie „Offen“, „In Bearbeitung“, „Stornieren“ und „Abgeschlossen“ zu speichern.

Dieses Modell ermöglicht es einem Kunden, sowohl eine einzelne Lektion als auch die Serviceanfrage als Ganzes zu stornieren. Wenn der Kunde die Serviceanfrage storniert, werden alle verbleibenden Stunden, die für den Kunden geplant sind, in der Reservierungstabelle storniert.

Bitte beziehen Sie sich auf das von mir mit Vertabelo erstellte Datenmodell für Details auf Spaltenebene all dieser Tabellen. Ein paar Punkte zur Spaltenerstellung:

• Eine Flag-Spalte namens is_active wird allen Haupttabellen hinzugefügt, um das vorläufige Löschen von Datensätzen zu ermöglichen. Wenn also beispielsweise ein Lehrer die Schule verlässt, setzen wir das Flag auf „N“, um seinen Datensatz zu inaktivieren.
• Bestimmte Spalten wie created_date , created_by , last_modified_date und last_modified_by werden in allen Transaktionstabellen hinzugefügt, um einen Prüfpfad für Änderungen in Aufzeichnungen zu ermöglichen. Transaktionstabellen sind im in Vertabelo erstellten Datenmodell blau hervorgehoben.
• Sie fragen sich vielleicht, was die address_id ist Spalte im staff Tisch ist für. Ich habe diese Spalte absichtlich in den staff Tabelle, damit ich mein Datenmodell erweitern kann, um einen automatisierten Prozess zu unterstützen, um einen Lehrer basierend auf seinem Standort einer Anfrage zuzuweisen. Angenommen, in New York City geht eine Anfrage von White Plains ein. Mein System sollte zuerst nach einem verfügbaren Ausbilder in derselben oder in der nächsten Umgebung suchen. Mein System sollte niemals einen Lehrer zuweisen, der sich in Manhattan aufhält, das fast 50 Meilen von der Wohnung des Anforderers entfernt ist.

Hervorragende Merkmale dieses Modells

• Dieses Modell ermöglicht es Kunden, Reservierungsanfragen gemäß ihren Präferenzen für Startdatum und Fahrzeug einzugeben.
• Es ermöglicht ihnen, eine oder mehrere Lektionen ihres Kurses oder den gesamten Kurs selbst zu stornieren.
• Dieses Modell erfasst Ausbilder- und Fahrzeugdetails für jede Lektion.
• Dieses Modell ist erweiterbar, um alle möglichen Dienstleistungen einer Fahrschule abzudecken.
• Es ermöglicht uns, Schulungen und Unterricht effektiv zu gestalten.

Datenbankmodell

Hier ist das Datenbankdesign für unser Reservierungssystem. Das Modell wurde in Vertabelo für die Oracle-Datenbank erstellt, aber das gleiche Design kann ohne wesentliche Änderungen für andere Datenbank-Engines implementiert werden.

Schlussfolgerung

Es gibt bestimmte Themenbereiche, die wir in diesem Artikel nicht behandelt haben, wie zum Beispiel:

• Können wir einen automatisierten Ansatz entwickeln, um Fahrzeuge und Ausbilder den Unterrichtseinheiten zuzuweisen?
• Wie sieht es mit der Rechnungsstellung an Kunden aus? Was ist, wenn ein Kunde nicht den gesamten Kurs bezahlen möchte, sondern nur einige Unterrichtsstunden davon? Können wir ihm diese Lektionen zur Verfügung stellen?

Unterstützt unser vorhandenes Modell solche Funktionen? Die Antwort ist nein. Ich werde diese Themenbereiche wahrscheinlich in meinem nächsten Artikel behandeln.