Integriertes Verkehrsdatenmodell

Integrierter Verkehr ist etwas, von dem wir oft im Internet oder in den Nachrichten hören. Es ist zwar nichts Neues, aber definitiv ein fortlaufender Prozess, bei dem ständig Änderungen vorgenommen werden. Heute werfen wir einen Blick auf ein Datenmodell, das Zonen-, Passagier- und Ticketinformationen verarbeiten kann.

Lassen Sie uns direkt in unser integriertes Transportdatenmodell eintauchen, beginnend mit der Idee dahinter.

Idee

Die Integration des Transportwesens ist notwendig, um seine Effizienz und für die Kunden seine einfache Nutzung zu maximieren. Integration ist mit Kosten verbunden, aber auch mit Zeit, Zugänglichkeit, Komfort und Sicherheit. Das gilt für größere Städte ebenso wie für kleinere. Die Idee ist, die vorhandene Transportinfrastruktur zu nutzen und für bessere Ergebnisse zu optimieren; Dies könnte bedeuten, neue Fahrpläne, Benachrichtigungen, Linien oder Bahnhöfe zu erstellen. Vielleicht reicht es schon, ein paar Informationen zu haben, damit Sie sich entscheiden, auf den Bus zu warten, ein Fahrrad zu mieten oder einfach zu Fuß zu Ihrem Ziel zu gehen.

Lassen Sie uns dies anhand von zwei Beispielen erläutern.

In einer Großstadt stehen normalerweise viele verschiedene Transportmittel zur Verfügung:Busse, Taxis, Straßenbahnen, Eisenbahnen, die U-Bahn usw. Dies kann dazu führen, dass viele verschiedene private Unternehmen verschiedene Transportdienste anbieten. Die Kombination auch nur einiger dieser Dienste würde Passagieren und Unternehmen definitiv zugute kommen, da sie die Kosten senken, die Effizienz steigern und mehr Service pro Ticket bieten.

Es gibt auch ähnliche Vorteile für eine kleinere Stadt. Es gibt vielleicht nicht die gleiche Anzahl von Optionen, die kombiniert werden können, aber sie könnten organisiert werden, um maximale Effizienz zu erreichen.

Dieser Artikel konzentriert sich hauptsächlich auf integrierte Fahrkartensysteme. Wir werden uns nicht auf alle Aspekte der Integration und die verschiedenen Verkehrsarten konzentrieren; das wäre zu komplex.

Kommen wir in diesem Sinne zu unserem Modell.

Datenmodell

Das Modell besteht aus zwei Themenbereichen:

• Cities & companies
• Tickets

Wir beschreiben sie in der Reihenfolge, in der sie aufgelistet sind.

Städte und Unternehmen

Im ersten Themenbereich hinterlegen wir alle Tabellen, die zum Einrichten von Verkehrszonen in Städten benötigt werden.

Das country Tabelle enthält eine Liste von UNIQUE country_name Werte. Diese Tabelle dient nur als Referenz im city Tisch. Obwohl wir davon ausgehen können, dass unser Modell den Transport in nur einem Land abdeckt, möchten wir die Möglichkeit haben, mehrere Länder einzubeziehen. Für jede Stadt speichern wir die EINZIGARTIGE Kombination city_name – country_id .

Kleinere Städte werden wahrscheinlich nur eine Zone haben, während größere Städte mehrere Zonen haben werden. Eine Liste aller möglichen Zonen ist im zone Tisch. Für jede Zone speichern wir ihren zone_name und einen Hinweis auf die jeweilige Stadt. Dieses Paar bildet den alternativen Schlüssel dieser Tabelle.

Wir können davon ausgehen, dass unser System Informationen zu mehreren Transportunternehmen speichert. Unternehmen werden ihre eigenen Tickets ausstellen, sie können aber auch gemeinsam mit anderen Unternehmen Tickets ausstellen. Für jedes company speichern wir die EINZIGARTIGE Kombination von company_name und die city_id wo es sich befindet. Eventuell benötigte Zusatzinformationen können in den textuellen details hinterlegt werden Feld.

Das letzte, was wir definieren müssen, ist die Art des Transports, die jedes Unternehmen anbietet. Einige erwartete Werte sind „Bus“, „Straßenbahn“, „U-Bahn“ und „Eisenbahn“. Für jeden Wert im transport_form Tabelle speichern wir den UNIQUE form_name.

• zone_id – Verweist auf die zone Tabelle und bezeichnet den Bereich, in dem dieses Transportmittel von diesem Unternehmen angeboten wird.
• company_id – Verweist auf company Bereitstellung dieses Dienstes in dieser Zone.
• transport_form_id – Referenziert das transport_form Tabelle und bezeichnet die Art der erbrachten Dienstleistung.
• date_from und date_to – Der Zeitraum, in dem diese Dienstleistung von diesem Unternehmen erbracht wurde. Beachten Sie, dass date_to kann einen NULL-Wert enthalten, wenn dieser Dienst noch verfügbar ist und/oder kein voraussichtliches Ablaufdatum hat.
• details – Alle anderen Details in einem unstrukturierten Textformat.
• is_active – Ob dieser Dienst aktiv (laufend) ist oder nicht. Dies ist ein einfacher Ein/Aus-Schalter, den wir in einigen Fällen anstelle von date_from verwenden können – date_to Service-Aktivitätsintervall. Die beste Verwendung dieses Attributs wäre, Abfragen zu vereinfachen, d. h. diesen Wert zu testen, anstatt das Datumsintervall zu testen und mit NULL-Werten zu „spielen“.

Tickets

Der bisherige Themenbereich war nur die Vorbereitung auf die Hauptsache:Tickets. Und darum geht es in diesem Themenbereich.

Wir haben Unternehmen, Zonen und Transportformen definiert, aber wir haben keine Vorkehrungen für Passagiere und Tickets – den Kern dieses Modells. Wir gehen davon aus, dass ein Ticket für eine oder mehrere Zonen verwendet werden kann, die von einem oder mehreren Unternehmen abgedeckt werden.

Daher müssen wir zuerst jeden ticket_type . In dieser Tabelle listen wir alle möglichen Arten von Tickets auf, die von den Unternehmen in unserer Datenbank verkauft werden. Für jeden Typ speichern wir die folgenden Werte:

• type_name – Ein Name, der diesen Typ EINZIGARTIG bezeichnet.
• valid_from und valid_to – Der Zeitraum, in dem dieser Tickettyp gültig ist (oder war). Beide Felder sind nullable; ein NULL-Wert bedeutet, dass es kein Start- (oder End-) Datum gibt, an dem dies gültig war.
• details – Alle notwendigen Details in unstrukturiertem Textformat.
• recurring – Ein Flag, das angibt, ob dieser Tickettyp wiederkehrend ist (z. B. jährlich, monatlich) oder nicht.
• interval_month – Wenn der Tickettyp wiederkehrend ist, enthält dieses Attribut das Intervall in Monaten, in dem es wiederkehrt (z. B. „1“ für ein Monatsticket, „12“ für ein Jahresticket).

Jetzt können wir die Zonen definieren, die von jedem Tickettyp abgedeckt werden. Im service_included Tabelle speichern wir nur das EINZIGARTIGE Paar ticket_type_id – service_available_id . Letzterer gibt auch das Unternehmen und die Zone an, in der diese Fahrkarte verwendet werden kann. Diese Tabelle ermöglicht es uns, mehrere Zonen pro Ticket zu definieren; Zonen können verschiedenen Unternehmen gehören. Da es sich um vordefinierte Tickettypen handelt, werden für jeden Tickettyp die hier definierten Zonen definiert (nicht für jeden einzelnen Passagier).

Wir werden in diesem Modell nicht zu viele Passagierdaten speichern. Für jeden passenger , speichern wir nur ihren first_name , last_name , address , und ein Verweis auf die Stadt, in der sie leben. All diese Daten werden auf dem Ticket angezeigt.

Die letzte Tabelle in unserem Modell ist ticket Tisch. Wir konzentrieren uns hier nicht auf Einwegtickets; Stattdessen kümmern wir uns um Abonnement- und Prepaid-Tickets. Diese Tickets haben ein Guthaben, ein Gültigkeitsdatum oder beides. Dies kann je nach Unternehmen und seinen Regeln erheblich abweichen. Wenn sich einige Unternehmen entscheiden, ein Ticket auszustellen, könnten wir das in dieser Tabelle unterstützen – wir kennen alle wichtigen Details. Für jedes Ticket speichern wir:

• serial_number – Eine EINZIGARTIGE Bezeichnung für jedes Ticket. Dies kann eine Kombination aus Zahlen und Buchstaben sein.
• ticket_type_id – Verweist auf die Art dieses Tickets.
• passenger_id – Verweist auf den Passagier, falls vorhanden, der dieses Ticket besitzt. Im Falle eines Prepaid-Tickets kann es keinen Besitzer geben.
• valid_from und valid_to – Bezeichnet den Gültigkeitszeitraum dieses Tickets. NULL-Werte bedeuten, dass es keine untere oder obere Grenze gibt.
• credits – Das aktuell verfügbare Guthaben (als Zahlenwert) auf diesem Ticket. Wenn es sich um ein Prepaid-Ticket handelt, können wir davon ausgehen, dass die Passagiere zusätzliche Guthaben auf dem Ticket kaufen. Wenn das Ticket den ganzen Monat (oder einen anderen Zeitraum) ohne Nutzungsbeschränkung gültig ist, könnte dieser Wert NULL sein.

Verbesserungen des integrierten Transportdatenmodells

Sie können feststellen, dass dieses Modell stark vereinfacht wurde. Das liegt daran, dass der integrierte Verkehr einfach zu groß ist, um ihn in einem Artikel zu behandeln. Es gibt einige Dinge, die meiner Meinung nach an diesem Modell geändert werden könnten:

• Zonen sind zu vereinfacht; wir sollten in der Lage sein, sie dynamischer zu definieren.
• Wir decken keine Linien ab (z. B. Buslinien). Was ist, wenn sie von einer Zone in eine andere gehen usw.?
• Wir speichern den Verlauf der Ticketnutzung nicht.
• Es gibt keine Registrierung für Unternehmen und Passagiere.

All dies würde dazu führen, dass uns wichtige Daten fehlen und wir keine tieferen Analysen vornehmen könnten. Also was denkst du? Was braucht dieses Modell? Was würden Sie hinzufügen oder entfernen? Teilen Sie Ihre Ideen in den Kommentaren.