Ein Datenbankmodell für einen Taxidienst

Nennen Sie sie Taxis oder Taxis, diese bequemen Mietfahrzeuge gibt es schon seit Jahrhunderten. Heutzutage ist es viel komplizierter, einen Taxidienst zu betreiben. In diesem Artikel sehen wir uns ein Datenbankmodell an, das auf die Anforderungen eines Taxiunternehmens zugeschnitten ist.

Die Geschichte des „Rufens eines Taxis“ begann im London des 17. Jahrhunderts. An den meisten Orten sind Taxis erschwinglicher als je zuvor. Sie werden auch viel zugänglicher:Wir können ein Taxi per Telefon, über mobile Anwendungen oder im Internet bestellen. Oder wir können die gleichen Techniken anwenden, die seit Hunderten von Jahren funktionieren – stellen Sie sich an einer Taxistation an oder halten Sie eines auf der Straße an.

Das Geschäftsmodell der Taxis stagniert keineswegs. Neuere Konzepte wie Uber und Lyft werden immer beliebter und werden sicherlich die Zukunft der Taxidienste beeinflussen. All dies verkompliziert natürlich das Leben der Betreiber von Taxiunternehmen. Werfen wir einen Blick auf die relevanten Teile eines Datenmodells, die ein Taxiunternehmen verwenden könnte, um organisiert zu bleiben.

Was wollen wir mit diesem Cab-Datenbankmodell erreichen?

Das in diesem Artikel vorgestellte Modell kann:

• Fahrpläne erstellen
• Fahrerverfügbarkeit in Echtzeit verfolgen
• Stellen Sie den Fahrern eine Liste möglicher Fahrten zur Verfügung
• Fahrern erlauben, eine Fahrt aus der Liste auszuwählen
• Arbeitszeit und Verdienst der Fahrer berechnen
• Speichern Sie verschiedene Statistiken (z. B. Prozentsatz der stornierten Fahrten, Zahlungen pro Fahrer und Monat usw.)

Was müssen wir über Taxiunternehmen wissen?

Bevor wir ein Datenmodell für ein Taxiunternehmen entwerfen, sollten wir in der Lage sein, die folgenden Fragen zu beantworten:

1. Wann arbeiten Fahrer?
   In den meisten Taxiunternehmen haben die Fahrer vordefinierte Fahrpläne. Wir kennen die genauen Zeiten, zu denen der Fahrer eine Schicht beginnt und beendet. In einigen Fällen sind Schichtbeginn und -ende nicht im Voraus festgelegt. Beispielsweise können sich Mitglieder einer Taxigesellschaft anmelden und mit der Arbeit beginnen, wann immer sie wollen. Sie können sich auch abmelden und ihre Schicht beenden, wenn sie möchten. Unser Modell sollte beide Optionen unterstützen können.

2. Kann ein Fahrer am selben Tag in mehreren Schichten arbeiten?
   Wenn der Fahrer Mitglied einer Taxivereinigung ist, kann er möglicherweise morgens arbeiten, nach Hause fahren und am selben Abend wieder arbeiten. In einigen Gegenden (wie New York City) gibt es jedoch gesetzliche Beschränkungen hinsichtlich der Schichtlänge und/oder der Anzahl der Stunden, die Taxifahrer pro Tag arbeiten dürfen.

3. 3. Wer initiiert eine Fahrt?
   In den meisten Fällen wendet sich ein Kunde an das Taxi-Callcenter und der Disponent gibt seine Anfrage in das System ein. Ein anderes Szenario tritt auf, wenn der Kunde direkt ein Taxi bestellt (z. B. über eine mobile App) und kein Call-Center-Mitarbeiter in den Prozess involviert ist. Eine dritte Option – die ebenfalls das Call Center umgeht – ergibt sich, wenn ein Kunde am Bahnhof ein Taxi nimmt oder eines auf der Straße anhält.

Das Datenmodell

Unser Modell hat zwei Hauptabschnitte und drei nicht kategorisierte Tabellen. Wir werden uns jeden von ihnen genauer ansehen.

Abschnitt 1:Kabinen, Fahrer und Schichten

Alles beginnt mit Taxis und Fahrern:Wir brauchen Autos in einem Taxiunternehmen und wir brauchen Fahrer. (In Zukunft werden wir unser Modell wahrscheinlich für selbstfahrende Autos anpassen müssen. Aber bleiben wir vorerst in der Gegenwart.)

Wir beginnen unsere Erkundung des Datenmodells mit dem driver Tisch. In diese Tabelle werden die üblichen Attribute wie Vorname, Nachname und Geburtsdatum aufgenommen. Wir haben auch einige Attribute, die für dieses Modell ziemlich spezifisch sind:

• driving_licence_number – Dies ist eine ID-Nummer oder ein alphanumerischer Code, der normalerweise auf einer von der Regierung ausgestellten Lizenz zu finden ist. Da diese ID in der realen Welt einzigartig ist, wird sie auch in unserer Datenbank einzigartig sein. (In einigen Gebieten müssen Taxifahrer eine spezielle Art von Betriebserlaubnis haben, um arbeiten zu dürfen; wir gehen davon aus, dass sie eine haben.)
• expiry_date – Dies ist das Datum, an dem ein Führerschein nicht mehr gültig ist. Beachten Sie, dass wir den Führerscheinverlauf nicht speichern, also überschreiben wir einfach driving_licence_number und expiry_date mit neuen Daten nach Bedarf. Wenn wir Lizenzverläufe speichern möchten, müssten wir unserem Modell eine weitere Tabelle hinzufügen.
• working – Dies ist ein boolescher Wert, der einfach ein- und ausgeschaltet wird, wenn sich Fahrer beim System anmelden. Wir setzen dieses Attribut standardmäßig auf „Ja“ (Wert 1) und ändern es nur dann auf „Nein“, wenn sich der Fahrer nicht mehr am System anmelden darf.

Es gibt viele andere fahrerbezogene Details, die wir in der Datenbank speichern könnten:Benutzernamen und Passwörter, das Datum, an dem jeder Fahrer seine Arbeit aufgenommen hat, und die aktuelle Beschäftigungsart jedes Fahrers. Wir gehen jetzt nicht auf diese Details ein, da sie sich nicht speziell auf dieses Modell beziehen. Ich würde sie der Benutzerverwaltung zuordnen, was in den meisten Systemen gleich ist.

Kommen wir nun zum cab und das car_model Tische. Hier speichern wir eine Liste der Autos, die unser Unternehmen betreibt. Wir speichern auch bestimmte Details zu jedem Fahrzeug. Die wichtigsten Attribute in diesen beiden Tabellen sind:

• model_description – Dies ist ein Textattribut, das eine unternehmensspezifische Beschreibung eines bestimmten Autotyps enthält. Beispielsweise möchten Taxiunternehmen möglicherweise die Anzahl der Passagiere, die ein Auto befördern kann, den Kofferraum (Kofferraum) und andere Fakten speichern.
• license_plate – Die Nummer auf einem Nummernschild (Fahrzeugkennzeichen oder Nummernschild) definiert ein Auto eindeutig, sowohl für ein Unternehmen als auch für staatliche Zwecke. Natürlich müssen wir möglicherweise die Nummernschildinformationen ändern, wenn ein Auto gekauft oder verkauft wird. In dieser Tabelle speichern wir nur die aktuellen Fahrzeuge des Unternehmens; Wenn wir eine Historie führen müssen, können wir unserem Modell eine weitere Tabelle hinzufügen.
• owner_id – Dieses Attribut ist ein Verweis auf den driver Tisch. Es ist optional, weil wir es nur verwenden, wenn der Fahrer seine Kabine besitzt. (Dies ist in der Regel bei Taxiverbänden der Fall).
• active – Dies ist ein boolescher Wert, der angibt, ob das Unternehmen noch ein Auto nutzt.

Werfen wir abschließend noch einen Blick auf die wichtigste Tabelle in diesem Abschnitt:die shift Tisch. Die Idee hinter dieser Tabelle ist, die tatsächlichen Arbeitszeiten und die Planschichten für Autos und Fahrer zu speichern. Jede Schicht hat mindestens ein Taxi (cab_id ) und einen Treiber (driver_id ). Abgesehen vom Primärschlüssel, der eine eindeutige Schicht-ID-Nummer ist, sind dies die einzigen obligatorischen Attribute in dieser Tabelle.

Die shift_start_time und shift_end_time Attribute sind die tatsächlichen Momente, in denen eine Schicht beginnt und endet. Oft sind diese voreingestellt. Falls es keinen Zeitplan gibt, wie in einer Taxivereinigung, wären diese Zeiten die gleichen wie die login_time und logout_time Attribute bzw. Die login_time und die logout_time sind die tatsächlichen Zeiten, zu denen sich die Fahrer anmelden (über ein mobiles Gerät in ihrem Auto oder eine andere Methode, die das Taxiunternehmen verwendet). Wenn sich der Fahrer in das System einloggt, erscheint eine Liste verfügbarer Fahrten und der Fahrer wählt eine aus. Natürlich wird auch der Disponent benachrichtigt, dass der Fahrer jetzt arbeitet.

Abschnitt 2:Fahrgeschäfte

Dieser Abschnitt besteht nur aus zwei Tabellen, aber sie sind das eigentliche Herzstück dieses Modells.

Im cab_ride Tabelle speichern wir einen Datensatz für jede potenzielle Fahrt. Wir werden diesen Datensatz entsprechend den Ereignissen aktualisieren. Lassen Sie uns einen kurzen Überblick über die Attribute geben:

• shift_id – Dies ist ein Verweis auf shift Tisch; es liefert uns Fahrer- und Kabinendaten für eine bestimmte Fahrt.
• ride_start_time und ride_end_time – Diese werden aktualisiert, wenn der Fahrer signalisiert, dass er gerade beschäftigt ist (Fahrtbeginn) und anschließend wieder verfügbar ist (Fahrtende).
• address_starting_point und address_destination – Dies sind die Orte, an denen eine Fahrt beginnt und endet. Der Fahrer wird wahrscheinlich nach beiden Orten suchen, um die Navigation auf seinem Tablet oder GPS zu erhalten, also werden wir diese beiden Attribute wahrscheinlich aktualisieren.
• GPS_starting_point und GPS_destination – Dies sind die GPS-Koordinaten der oben beschriebenen Start- und Zielorte. Diese Werte sind optional, da wir sie nur aktualisieren, wenn wir Daten haben.
• canceled – Dies ist ein einfacher Ja/Nein-Wert, der uns mitteilt, ob eine Fahrt storniert wurde. Wir haben bereits einen Datensatz für diese Fahrt in unserer Tabelle, sodass wir die Fahrt einfach als storniert markieren können.
• payment_type_id und price – Diese geben Auskunft über den für eine Fahrt bezahlten Betrag und die vom Kunden verwendete Zahlungsmethode.

Die meisten Attribute in cab_ride Tabelle kann einen NULL-Wert enthalten. Dafür gibt es zwei Gründe:

• Fahrten werden storniert, was bedeutet, dass keine Daten in diese Felder eingegeben werden;
• Auch wenn wir irgendwann alle Daten haben werden, haben wir nicht alle, wenn der Datensatz zum ersten Mal eingefügt wird. Wir aktualisieren jeden Datensatz mehrmals – zumindest aktualisieren wir ihn, wenn die Fahrt beginnt und endet (oder abgesagt wird).

Die zweite Tabelle in diesem Abschnitt ist der cab_ride_status Tisch. Hier wird für jede Änderung, die sich auf eine einzelne Fahrt bezieht, ein Datensatz hinzugefügt. Wenn der Disponent eine neue Fahrt in das System eingibt, fügt er einen Datensatz zu cab_ride Tabelle, aber ein zugehöriger Datensatz wird auch in cab_ride_status Tabelle (mit dem entsprechenden Status). Nach jeder Änderung in Bezug auf diese Fahrt wird dieser Tabelle ein weiterer Datensatz hinzugefügt. Die Attribute sind:

• cab_ride_id und status_id – Dies sind Fremdschlüssel, die sich auf das id-Attribut im ride Tabelle und das Attribut id im status Tabelle (auf die wir weiter unten eingehen werden). Beides ist obligatorisch.
• status_time – Hier wird die tatsächliche Zeit gespeichert, zu der der Datensatz eingefügt wurde. Es ist auch obligatorisch.
• cc_agent_id und shift_id – Dies sind Verweise auf den Mitarbeiter, der ein Status-Update eingefügt hat. Es kann entweder ein Disponent oder ein Fahrer sein. Wahrscheinlich fügt der Disponent den Anfangsstatus ein und der Fahrer alle folgenden Status.
• status_details – Dies ist ein Textattribut, in dem zusätzliche Informationen hinterlegt werden können. Beispielsweise könnte ein Fahrdienstleiter dieses Attribut verwenden, um spezielle Anweisungen zu einer Fahrt aufzuzeichnen.

Nicht kategorisierte Tabellen

Lassen Sie uns zum Schluss schnell unsere nicht kategorisierten Tabellen durchgehen.

Der cc_agent Tabelle enthält eine Liste von Call-Center-Agenten oder Dispatchern, die neue Datensätze in cab_ride und cab_ride_status Tabellen.

Im status Wörterbuch speichern wir eine Liste aller möglichen Status, die wir einer Fahrt zuweisen könnten. Einige Werte beinhalten "neue Fahrt" , „Fahrt dem Fahrer zugewiesen“ , "Fahrt gestartet" , "Fahrt beendet" , oder "Fahrt abgebrochen" .

Payment_type ist eine weitere Wörterbuchtabelle. Sein Inhalt wird verwendet, um die payment_type_id zu aktualisieren -Attribut im cab_ride Tisch. Übliche Werte sind Bargeld und "Kreditkarte" .

Wie würden Sie das Taxidatenmodell verbessern?

Das in diesem Artikel vorgestellte Taxi-Datenbankmodell konzentriert sich nur auf die wichtigsten Funktionalitäten. Es gibt zahlreiche Verbesserungen, die wir vornehmen könnten. Routen sind nur eine, die mir einfällt.

In Zukunft werden wir wahrscheinlich fahrerlose Taxis haben. In diesem Fall würden wir den Treiber aus dem Modell streichen und Dinge wie Lade- und Reparaturzeiten ersetzen.

Fühlen Sie sich frei, zu kommentieren und Ihre Ideen hinzuzufügen.