Een databasemodel voor een taxiservice

Noem ze taxi's of taxi's, deze handige ritten te huur bestaan al eeuwen. Tegenwoordig is het een stuk ingewikkelder om een taxiservice te runnen. In dit artikel zullen we kijken naar een databasemodel dat is ontworpen om te voldoen aan de behoeften van een taxibedrijf.

De geschiedenis van het 'bellen van een taxi' begon in het Londen van de 17e eeuw. Op de meeste plaatsen zijn taxi's betaalbaarder dan ooit. Ze worden ook een stuk toegankelijker:we kunnen een taxi bestellen via de telefoon, via mobiele applicaties of op het web. Of we kunnen dezelfde technieken gebruiken die al honderden jaren werken:in de rij gaan staan bij een taxistation of er een markeren op straat.

Het taxibedrijfsmodel staat geenszins stil. Nieuwere concepten zoals Uber en Lyft winnen aan populariteit en zullen zeker een impact hebben op de toekomst van taxidiensten. Dit alles bemoeilijkt natuurlijk het leven van degenen die taxibedrijven runnen. Laten we eens kijken naar de relevante onderdelen van een gegevensmodel dat een taxibedrijf zou kunnen gebruiken om georganiseerd te blijven.

Wat willen we bereiken met dit cab-databasemodel?

Het model dat in dit artikel wordt gepresenteerd, kan:

Maak chauffeursschema's
Beschikbaarheid van chauffeurs in realtime volgen
Bezorg chauffeurs een lijst met mogelijke ritten
Chauffeurs toestaan een rit uit de lijst te selecteren
Bereken de werkuren en inkomsten van chauffeurs
Bewaar verschillende statistieken (bijv. percentage ritten dat wordt geannuleerd, betalingen per bestuurder per maand, enz.)

Wat moeten we weten over taxibedrijven?

Voordat we een datamodel voor een taxibedrijf ontwerpen, moeten we de volgende vragen kunnen beantwoorden:

Wanneer werken chauffeurs?
In de meeste taxibedrijven hebben chauffeurs vooraf gedefinieerde schema's. We weten de exacte tijden waarop de chauffeur een dienst start en eindigt. In sommige gevallen zijn de begin- en eindtijden van de dienst niet vooraf vastgelegd. Leden van een taxivereniging kunnen bijvoorbeeld inloggen en aan de slag gaan wanneer ze maar willen. Ze kunnen ook uitloggen en hun dienst beëindigen wanneer ze dat willen. Ons model zou beide opties moeten kunnen ondersteunen.
Kan een chauffeur meerdere diensten op dezelfde dag werken?
Als de chauffeur lid is van een taxivereniging, kan hij 's ochtends werken, naar huis gaan en dezelfde avond weer werken. In sommige gebieden (zoals New York City) zijn er echter wettelijke beperkingen op de lengte van ploegendiensten en/of het aantal uren dat taxichauffeurs per dag kunnen werken.
3. Wie start een rit?
In de meeste gevallen neemt een klant contact op met het taxi-callcenter en voert de coördinator zijn verzoek in het systeem in. Een ander scenario doet zich voor wanneer de klant direct een taxi bestelt (bijvoorbeeld via mobiele app) en er geen callcentermedewerker bij betrokken is. Een derde optie – die ook het callcenter omzeilt – doet zich voor wanneer een klant een taxi neemt op het station of er een aanhoudt op straat.

Het gegevensmodel

Ons model heeft twee hoofdsecties en drie niet-gecategoriseerde tabellen. We zullen elk van hen nader bekijken.

Sectie 1:Taxi's, chauffeurs en ploegen

Alles begint met taxi's en chauffeurs:we hebben auto's nodig in een taxibedrijf en we hebben chauffeurs nodig. (In de toekomst zullen we waarschijnlijk ons model voor zelfrijdende auto's moeten aanpassen. Maar laten we voorlopig in het heden blijven.)

We beginnen onze verkenning van het datamodel met de driver tafel. In deze tabel nemen we de gebruikelijke attributen op, zoals naam, achternaam en geboortedatum. We hebben ook enkele kenmerken die vrij specifiek zijn voor dit model:

driving_licence_number – Dit is een ID-nummer of alfanumerieke code die u gewoonlijk vindt op een door de overheid uitgegeven vergunning. Aangezien deze ID uniek is in de echte wereld, zal deze ook uniek zijn in onze database. (In sommige gebieden moeten taxichauffeurs een speciaal type exploitatievergunning hebben om te werken; we gaan ervan uit dat ze die hebben.)
expiry_date – Dit is de datum waarop een rijbewijs niet meer rechtsgeldig is. Merk op dat we de licentiegeschiedenis niet opslaan, dus we zullen gewoon driving_licence_number overschrijven en expiry_date indien nodig met nieuwe gegevens. Als we licentiegeschiedenissen willen opslaan, moeten we een andere tabel aan ons model toevoegen.
working – Dit is een Booleaanse waarde die eenvoudig wordt in- en uitgeschakeld wanneer bestuurders inloggen op het systeem. We stellen dit kenmerk standaard in op "Ja" (waarde 1) en wijzigen het alleen in "Nee" als de bestuurder zich niet meer bij het systeem mag aanmelden.

Er zijn veel andere chauffeurgerelateerde details die we in de database kunnen opslaan:gebruikersnamen en wachtwoorden, de datum waarop elke chauffeur begon te werken en het huidige dienstverband van elke chauffeur. We zullen nu niet op deze details ingaan omdat ze niet specifiek gerelateerd zijn aan dit model. Ik zou ze classificeren onder gebruikersbeheer, wat in de meeste systemen hetzelfde is.

Laten we nu verder gaan met de cab en het car_model tafels. Hier slaan we een lijst op van de auto's die ons bedrijf exploiteert. We slaan ook bepaalde details over elk voertuig op. De belangrijkste kenmerken in deze twee tabellen zijn:

model_description – Dit is een tekstattribuut dat een door het bedrijf gespecificeerde beschrijving van een bepaald type auto bijhoudt. Taxibedrijven willen bijvoorbeeld het aantal passagiers dat een auto kan vervoeren, kofferruimte (kofferruimte) en andere feiten opslaan.
license_plate – Het nummer op een kentekenplaat (voertuigkentekenplaat of kentekenplaat) definieert een auto op unieke wijze, zowel voor een bedrijf als voor overheidsdoeleinden. Het kan natuurlijk zijn dat we kentekengegevens moeten wijzigen als een auto wordt gekocht of verkocht. In deze tabel slaan we alleen de huidige voertuigen van het bedrijf op; als we een geschiedenis moeten bijhouden, kunnen we nog een tabel aan ons model toevoegen.
owner_id – Dit attribuut is een verwijzing naar de driver tafel. Het is optioneel omdat we het alleen gebruiken als de chauffeur zijn cabine bezit. (Dit is meestal het geval bij taxiverenigingen).
active – Dit is een Booleaanse waarde die aangeeft of het bedrijf nog steeds een auto gebruikt.

Laten we tot slot eens kijken naar de belangrijkste tabel in deze sectie:de shift tafel. Het idee achter deze tabel is om de werkelijke werkuren en de roosterdiensten van auto's en chauffeurs op te slaan. Elke ploeg heeft ten minste één taxi (cab_id ) en één bestuurder (driver_id ). Afgezien van de primaire sleutel, een uniek ploeg-ID-nummer, zijn dit de enige verplichte kenmerken in deze tabel.

De shift_start_time en shift_end_time attributen zijn de feitelijke momenten waarop een dienst begint en eindigt. Vaak zijn deze vooraf ingesteld. Als er geen schema is, zoals in een taxivereniging, zijn deze tijden hetzelfde als de login_time en logout_time attributen resp. De login_time en de logout_time zijn de werkelijke tijden dat de chauffeurs inloggen (via een mobiel apparaat in hun auto of welke methode het taxibedrijf ook gebruikt). Wanneer de chauffeur zich aanmeldt bij het systeem, verschijnt er een lijst met beschikbare ritten en kiest de chauffeur er een. Natuurlijk wordt de coördinator ook op de hoogte gebracht dat de chauffeur nu aan het werk is.

Sectie 2:Ritten

Deze sectie bestaat uit slechts twee tabellen, maar ze vormen het ware hart van dit model.

In de cab_ride tabel, slaan we één record op voor elke potentiële rit. We zullen dit record bijwerken op basis van wat er gebeurt. Laten we een snel overzicht geven van de kenmerken:

shift_id – Dit is een verwijzing naar de shift tafel; het geeft ons chauffeurs- en taxigegevens voor een bepaalde rit.
ride_start_time en ride_end_time – Deze worden bijgewerkt wanneer chauffeurs aangeven dat ze momenteel bezig zijn (rit start) en vervolgens weer beschikbaar zijn (rit einde).
address_starting_point en address_destination – Dit zijn de locaties waar een rit begint en eindigt. De bestuurder zal waarschijnlijk naar beide locaties zoeken om de navigatie op zijn tablet of GPS te krijgen, dus waarschijnlijk zullen we deze twee kenmerken bijwerken.
GPS_starting_point en GPS_destination – Dit zijn de GPS-coördinaten van de hierboven beschreven start- en eindlocaties. Deze waarden zijn optioneel omdat we ze alleen bijwerken als we over gegevens beschikken.
canceled – Dit is een eenvoudige Ja/Nee-waarde die ons vertelt of een rit is geannuleerd. We hebben al een record voor die rit in onze tabel, dus we kunnen de rit gewoon markeren als geannuleerd.
payment_type_id en price – Deze geven informatie over het betaalde bedrag voor een rit en de door de klant gebruikte betaalmethode.

De meeste kenmerken in de cab_ride tabel kan een NULL-waarde bevatten. Hier zijn twee redenen voor:

Ritten worden geannuleerd, wat betekent dat er geen gegevens in deze velden worden ingevoerd;
Zelfs als we uiteindelijk alle gegevens zullen hebben, hebben we ze niet allemaal wanneer het record voor het eerst wordt ingevoegd. We zullen elk record meerdere keren bijwerken - we zullen het op zijn minst bijwerken wanneer de rit begint en eindigt (of wordt geannuleerd).

De tweede tabel in deze sectie is de cab_ride_status tafel. Hier wordt een record toegevoegd voor elke wijziging die betrekking heeft op een enkele rit. Wanneer de coördinator een nieuwe rit in het systeem invoert, voegen ze een record toe aan de cab_ride tabel, maar er wordt ook een gerelateerd record aangemaakt in de cab_ride_status tabel (samen met de bijbehorende status). Na elke wijziging met betrekking tot die rit, wordt er nog een record aan deze tabel toegevoegd. De attributen zijn:

cab_ride_id en status_id – Dit zijn externe sleutels die gerelateerd zijn aan het id-attribuut in de ride tabel en het id-attribuut in de status tabel (die we hieronder zullen behandelen). Beide zijn verplicht.
status_time – Dit slaat de werkelijke tijd op waarop de record werd ingevoegd. Het is ook verplicht.
cc_agent_id en shift_id – Dit zijn verwijzingen naar de medewerker die een statusupdate heeft ingevoegd. Dit kan zowel een dispatcher als een chauffeur zijn. Waarschijnlijk zal de coördinator de initiële status invoegen en de chauffeur alle volgende statussen.
status_details – Dit is een tekstkenmerk dat kan worden gebruikt om aanvullende informatie op te slaan. Een coördinator kan dit kenmerk bijvoorbeeld gebruiken om speciale instructies over een rit vast te leggen.

Niet-gecategoriseerde tabellen

Laten we tot slot snel onze niet-gecategoriseerde tabellen doornemen.

De cc_agent tabel bevat een lijst met callcentermedewerkers of coördinatoren die nieuwe records kunnen toevoegen in de cab_ride en cab_ride_status tabellen.

In de status woordenboek, slaan we een lijst op met alle mogelijke statussen die we aan een rit kunnen toewijzen. Sommige waarden bevatten 'nieuwe rit' , “rit toegewezen aan chauffeur” , “rit gestart” , “rit beëindigd” , of “rit geannuleerd” .

Payment_type is een andere woordenboektabel. De inhoud ervan wordt gebruikt om de payment_type_id . bij te werken attribuut in de cab_ride tafel. Veelvoorkomende waarden zijn “cash” en “creditcard” .

Hoe zou u het taxigegevensmodel verbeteren?

Het cab/taxi-databasemodel dat in dit artikel wordt gepresenteerd, is alleen gericht op de belangrijkste functionaliteiten. Er zijn tal van verbeteringen die we zouden kunnen aanbrengen. Routes zijn er maar één die ik kan bedenken.

In de toekomst zullen we waarschijnlijk chauffeursloze cabines hebben. In dat geval zouden we de bestuurder uit het model laten vallen en dingen als oplaad- en reparatietijden vervangen.

Voel je vrij om commentaar te geven en je ideeën toe te voegen.