Geïntegreerd transportgegevensmodel

Geïntegreerd vervoer horen we vaak op internet of in het nieuws. Hoewel het niet iets nieuws is, is het zeker een continu proces, waarbij voortdurend veranderingen worden doorgevoerd. Vandaag bekijken we een datamodel dat zone-, passagiers- en ticketinformatie kan verwerken.

Laten we ons eens verdiepen in ons geïntegreerde transportdatamodel, te beginnen met het idee erachter.

Idee

Het integreren van transport is noodzakelijk om de efficiëntie en, voor klanten, het gebruiksgemak te maximaliseren. Integratie heeft te maken met kosten, maar ook met tijd, bereikbaarheid, comfort en veiligheid. Dit geldt zowel voor grotere steden als voor kleinere. Het idee is om de bestaande transportinfrastructuur te gebruiken en te optimaliseren voor betere resultaten; dit kan betekenen dat je nieuwe dienstregelingen, meldingen, lijnen of stations moet bedenken. Misschien is het hebben van wat informatie voldoende om te besluiten op de bus te wachten, een fiets te huren of gewoon naar je bestemming te lopen.

Laten we dit uitleggen aan de hand van twee voorbeelden.

In het geval van een grote stad zijn er meestal veel verschillende vervoersmiddelen beschikbaar:bussen, taxi's, trams, spoorwegen, de metro, enz. Dit kan ertoe leiden dat veel verschillende particuliere bedrijven verschillende vervoersdiensten aanbieden. Het combineren van zelfs maar een paar van deze services zou zeker voordelen opleveren voor passagiers en bedrijven door de kosten te verlagen, de efficiëntie te verhogen en meer service per ticket te bieden.

Er zijn ook vergelijkbare voordelen voor een kleinere stad. Er zijn misschien niet hetzelfde aantal opties om te combineren, maar ze kunnen worden georganiseerd om maximale efficiëntie te bereiken.

Dit artikel zal zich voornamelijk richten op geïntegreerde vervoerbewijzen. We gaan niet in op alle aspecten van integratie en de verschillende soorten vervoer; dat zou te ingewikkeld zijn.

Laten we met dit in gedachten naar ons model gaan.

Gegevensmodel

Het model bestaat uit twee vakgebieden:

• Cities & companies
• Tickets

We beschrijven ze in de volgorde waarin ze worden vermeld.

Steden en bedrijven

In het eerste onderwerpgebied slaan we alle tabellen op die nodig zijn om transportzones in steden in te stellen.

Het country tabel bevat een lijst van UNIEKE country_name waarden. Deze tabel wordt alleen gebruikt als referentie in de city tafel. Hoewel we kunnen verwachten dat ons model transport in slechts één land dekt, willen we de mogelijkheid hebben om meerdere landen op te nemen. Voor elke stad slaan we de UNIEKE combinatie city_name op – country_id .

Kleinere steden zullen waarschijnlijk maar één zone hebben, terwijl grotere steden meerdere zones zullen hebben. Een lijst van alle mogelijke zones wordt opgeslagen in de zone tafel. Voor elke zone slaan we de zone_name op en een verwijzing naar de betreffende stad. Dit paar vormt de alternatieve sleutel van deze tabel.

We kunnen verwachten dat ons systeem informatie opslaat over meerdere transportbedrijven. Bedrijven zullen hun eigen tickets uitgeven, maar ze zullen ook samen met andere bedrijven tickets kunnen uitgeven. Voor elk company , slaan we de UNIEKE combinatie van company_name op en de city_id waar is het. Alle benodigde aanvullende informatie kan worden opgeslagen in de tekstuele details veld.

Het laatste dat we moeten definiëren, is de vorm van transport die elk bedrijf biedt. Enkele verwachte waarden zijn "bus", "tram", "metro" en "spoor". Voor elke waarde in de transport_form tabel, slaan we de UNIEKE form_name op.

• zone_id – Verwijst naar de zone tabel en geeft het gebied aan waar deze vorm van transport wordt verzorgd door dit bedrijf.
• company_id – Verwijst naar het company het leveren van deze service in deze zone.
• transport_form_id – Verwijst naar de transport_form tabel en geeft het type service aan dat wordt geleverd.
• date_from en date_to – De periode waarin deze dienst door dit bedrijf is geleverd. Merk op dat date_to kan een NULL-waarde bevatten als deze service nog steeds beschikbaar is en/of geen verwachte vervaldatum heeft.
• details – Alle andere details, in een ongestructureerd tekstueel formaat.
• is_active – Of deze dienst actief is (lopend) of niet. Dit is een eenvoudige aan/uit-schakelaar die we in sommige gevallen kunnen gebruiken in plaats van de date_from – date_to service-activiteitsinterval. Het beste gebruik van dit kenmerk zou zijn om zoekopdrachten te vereenvoudigen, d.w.z. door deze waarde te testen in plaats van het datuminterval te testen en te "spelen" met NULL-waarden.

Tickets

Het vorige onderwerp was slechts een voorbereiding op het belangrijkste:tickets. En dat is wat dit onderwerp zal behandelen.

We hebben bedrijven, zones en vervoersvormen gedefinieerd, maar we hebben geen voorzieningen voor passagiers en tickets - de kern van dit model. We gaan ervan uit dat één ticket kan worden gebruikt voor een of meer zones die door een of meer bedrijven worden gedekt.

Daarom moeten we eerst elk ticket_type . In deze tabel geven we een overzicht van alle mogelijke soorten tickets die worden verkocht door de bedrijven in onze database. Voor elk type slaan we de volgende waarden op:

• type_name – Een naam die UNIEK dit type aanduidt.
• valid_from en valid_to – De periode waarin dit tickettype geldig is (of was). Beide velden zijn nullable; een NULL-waarde betekent dat er geen begin- (of eind)datum is waarop dit geldig was.
• details – Alle noodzakelijke details, in ongestructureerd tekstueel formaat.
• recurring – Een vlag die aangeeft of dit type ticket terugkerend is (bijvoorbeeld jaarlijks, maandelijks) of niet.
• interval_month – Als het type ticket terugkerend is, bevat dit kenmerk het interval, in maanden, wanneer het terugkeert (bijv. "1" voor een maandelijks ticket, "12" voor een jaarticket).

Nu zijn we klaar om de zones te definiëren die onder elk tickettype vallen. In de service_included tabel, slaan we alleen het UNIEKE paar ticket_type_id op – service_available_id . Deze laatste zal ook het bedrijf en de zone aangeven waar dit ticket kan worden gebruikt. Met deze tabel kunnen we meerdere zones per ticket definiëren; zones kunnen van verschillende bedrijven zijn. Aangezien dit vooraf gedefinieerde tickettypes zijn, heeft elk tickettype de hier gedefinieerde zones (niet voor elke individuele passagier).

We zullen in dit model niet te veel passagiersgegevens opslaan. Voor elke passenger , slaan we alleen hun first_name op , last_name , address , en een verwijzing naar de stad waar ze wonen. Al deze gegevens worden op het ticket weergegeven.

De laatste tafel in ons model is het ticket tafel. We zullen ons hier niet concentreren op tickets voor eenmalig gebruik; in plaats daarvan behandelen we abonnements- en prepaid-tickets. Deze tickets hebben een saldo, een geldigheidsdatum of beide. Dit kan aanzienlijk verschillen, afhankelijk van het bedrijf en zijn regels. Als een paar bedrijven besluiten een ticket uit te geven, kunnen we dat in deze tabel ondersteunen - we zullen alle belangrijke details kennen. Voor elk ticket slaan we op:

• serial_number – Een UNIEKE aanduiding voor elk ticket. Dit kan een combinatie van cijfers en letters zijn.
• ticket_type_id – Verwijst naar het type van dat ticket.
• passenger_id – Verwijst naar de eventuele passagier die eigenaar is van dat ticket. In het geval van een prepaid ticket, kan er geen eigenaar zijn.
• valid_from en valid_to – Geeft de periode aan waarin dit ticket geldig is. NULL-waarden geven aan dat er geen onder- of bovengrens is.
• credits – De tegoeden (als een numerieke waarde) die momenteel beschikbaar zijn op dat ticket. Als het een prepaid ticket is, kunnen we ervan uitgaan dat passagiers extra credits op het ticket kopen. Als het ticket de hele maand (of een andere periode) geldig is zonder gebruiksbeperkingen, kan deze waarde NULL zijn.

Verbeteringen aan het Integrated Transport Data Model

Je merkt dat dit model sterk vereenvoudigd is. Geïntegreerd transport is namelijk simpelweg te groot om in één artikel te behandelen. Er zijn enkele dingen waarvan ik denk dat ze in dit model kunnen worden veranderd:

• Zones zijn te vereenvoudigd; we zouden ze dynamischer moeten kunnen definiëren.
• We dekken geen lijnen (bijv. buslijnen). Wat als ze van de ene zone naar de andere gaan, enz.?
• We slaan de geschiedenis van het gebruik van tickets niet op.
• Er is geen registratie voor bedrijven en passagiers.

Dit alles zou ertoe leiden dat we belangrijke gegevens zouden missen en geen diepere analyse zouden kunnen maken. Dus wat denk je? Wat heeft dit model nodig? Wat zou je toevoegen of verwijderen? Deel uw ideeën in de opmerkingen.