En databasmodell för en taxitjänst

Kalla dem taxibilar eller taxibilar, dessa bekväma åkturer att hyra har funnits i århundraden. Nuförtiden är det mycket mer komplicerat att driva en taxitjänst. I den här artikeln ska vi titta på en databasmodell utformad för att möta behoven hos ett taxiföretag.

Historien om att "ringa en taxi" började i London på 1600-talet. På de flesta ställen är hytterna billigare än någonsin. De blir också mycket mer tillgängliga:vi kan beställa en taxi via telefon, via mobilapplikationer eller på webben. Eller så kan vi använda samma teknik som har fungerat i hundratals år – ställa upp vid en hyttstation eller flagga en på gatan.

Taxiaffärsmodellen är inte stillastående på något sätt. Nyare koncept som Uber och Lyft blir allt populärare och kommer säkerligen att påverka framtiden för taxitjänster. Allt detta komplicerar naturligtvis livet för dem som driver taxiföretag. Låt oss ta en titt på de relevanta delarna av en datamodell som ett taxiföretag kan använda för att hålla ordning.

Vad vill vi uppnå med denna hyttdatabasmodell?

Modellen som presenteras i den här artikeln kommer att kunna:

Skapa förarscheman
Spåra förarens tillgänglighet i realtid
Ge förarna en lista över potentiella åkningar
Tillåt förare att välja en resa från listan
Beräkna förarnas arbetstid och inkomst
Lagra olika statistik (t.ex. procentandel av turer som ställs in, betalningar per förare och månad, etc.)

Vad behöver vi veta om taxiföretag?

Innan vi designar en datamodell för ett taxiföretag bör vi kunna svara på följande frågor:

När fungerar drivrutiner?
I de flesta taxiföretag har förarna fördefinierade scheman. Vi vet de exakta tidpunkterna när föraren startar och avslutar ett skift. I vissa fall är skiftets start- och sluttider inte definierade i förväg. Medlemmar i en hyttförening kan till exempel logga in och börja jobba när de vill. De kan också logga ut och avsluta sitt skift när de vill. Vår modell bör kunna stödja båda alternativen.
Kan en förare arbeta flera skift på samma dag?
Om chauffören är medlem i en taxiförening kan de kanske jobba på morgonen, gå hem och sedan jobba igen samma kväll. Men i vissa områden (som New York City) finns det lagliga begränsningar för skiftlängden och/eller hur många timmar taxichaufförer kan arbeta varje dag.
3. Vem initierar en åktur?
I de flesta fall kommer en kund att kontakta taxicentralen och transportören kommer att lägga in sin förfrågan i systemet. Ett annat scenario uppstår när kunden beställer en taxi direkt (till exempel via mobilapp) och ingen callcenteranställd är inblandad i processen. Ett tredje alternativ – som också går förbi callcentret – uppstår när en kund får en taxi vid stationen eller ropar en på gatan.

Datamodellen

Vår modell har två huvudsektioner och tre okategoriserade tabeller. Vi kommer att titta närmare på var och en av dem.

Avsnitt 1:Hytter, förare och växlar

Allt börjar med taxibilar och chaufförer:vi behöver bilar i ett taxibolag och vi behöver chaufförer. (I framtiden kommer vi förmodligen att behöva anpassa vår modell för självkörande bilar. Men låt oss stanna i nuet tills vidare.)

Vi börjar vår utforskning av datamodellen med driver tabell. I den här tabellen inkluderar vi de vanliga attributen som namn, efternamn och födelsedatum. Vi kommer också att ha några attribut som är ganska specifika för den här modellen:

driving_licence_number – Det här är ett ID-nummer eller en alfanumerisk kod som vanligtvis finns på en myndighetsutfärdad licens. Eftersom detta ID är unikt i den verkliga världen kommer det också att vara unikt i vår databas. (I vissa områden måste taxichaufförer ha en speciell typ av körkort för att arbeta; vi antar att de har det.)
expiry_date – Detta är det datum då ett körkort inte längre är juridiskt giltigt. Observera att vi inte kommer att lagra licenshistoriken, så vi skriver helt enkelt över driving_licence_number och expiry_date med nya data efter behov. Om vi vill lagra licenshistorik måste vi lägga till ytterligare en tabell till vår modell.
working – Detta är ett booleskt värde som helt enkelt slås på och av när förare loggar in i systemet. Vi ställer in det här attributet som standard till "Ja" (värde 1) och ändrar det till "Nej" endast när föraren inte längre får logga in i systemet.

Det finns många andra förarrelaterade detaljer vi skulle kunna lagra i databasen:användarnamn och lösenord, datumet för varje förare började arbeta och varje förares aktuella anställningstyp. Vi kommer inte att gå in på dessa detaljer nu eftersom de inte är specifikt relaterade till den här modellen. Jag skulle klassificera dem under användaradministration, vilket är samma i de flesta system.

Låt oss nu gå vidare till cab och car_model tabeller. Det är här vi kommer att lagra en lista över de bilar som vårt företag driver. Vi kommer också att lagra vissa uppgifter om varje fordon. De viktigaste attributen i dessa två tabeller är:

model_description – Det här är ett textattribut som håller en företagsspecificerad beskrivning av en viss typ av bil. Till exempel kan taxiföretag vilja lagra antalet passagerare en bil kan bära, bagageutrymmet (bagageutrymme) och andra fakta.
license_plate – Numret på en registreringsskylt (fordons registreringsskylt eller registreringsskylt) definierar en bil unikt, både för ett företag och för statliga ändamål. Naturligtvis kan vi behöva ändra registreringsskyltinformation om en bil köps eller säljs. I den här tabellen kommer vi bara att lagra företagets nuvarande fordon; om vi behöver behålla en historik kan vi lägga till ytterligare en tabell till vår modell.
owner_id – Det här attributet är en referens till driver tabell. Det är valfritt eftersom vi bara använder det när föraren äger sin hytt. (Detta är vanligtvis fallet i hyttföreningar).
active – Det här är ett booleskt värde som anger om företaget fortfarande använder en bil.

Låt oss slutligen ta en titt på den viktigaste tabellen i det här avsnittet:shift tabell. Tanken bakom denna tabell är att lagra de faktiska arbetstiderna och schemaskiften för bilar och förare. Varje skift kommer att ha minst en hytt (cab_id ) och en drivrutin (driver_id ). Förutom primärnyckeln, som är ett unikt skift-ID-nummer, är dessa de enda obligatoriska attributen i denna tabell.

shift_start_time och shift_end_time attribut är de faktiska ögonblicken när ett skift startar och slutar. Ofta är dessa förinställda. Om det inte finns något schema, som i en taxiförening, skulle dessa tider vara desamma som login_time och logout_time attribut, respektive. login_time och logout_time är de faktiska gånger förarna loggar in (via en mobil enhet i bilen eller vilken metod taxibolaget nu använder). När föraren loggar in i systemet visas en lista över tillgängliga turer och föraren väljer en. Självklart kommer avsändaren också att meddelas att föraren nu fungerar.

Avsnitt 2:Åkturer

Det här avsnittet består av endast två tabeller, men de är själva hjärtat i denna modell.

I cab_ride tabell lagrar vi ett rekord för varje potentiell åktur. Vi kommer att uppdatera denna post efter vad som händer. Låt oss få en snabb översikt över attributen:

shift_id – Det här är en referens till shift tabell; den ger oss förar- och hyttdetaljer för en given åktur.
ride_start_time och ride_end_time – Dessa uppdateras när förare signalerar att de för närvarande är upptagna (körstart) och är sedan tillgängliga igen (färdslut).
address_starting_point och address_destination – Det här är de platser där en åktur startar och slutar. Föraren kommer förmodligen att söka efter båda platserna för att få navigering på sin surfplatta eller GPS, så det är troligt att vi kommer att uppdatera dessa två attribut.
GPS_starting_point och GPS_destination – Det här är GPS-koordinaterna för start- och slutplatserna som beskrivs ovan. Dessa värden är valfria eftersom vi bara uppdaterar dem när vi har data.
canceled – Det här är ett enkelt Ja/Nej-värde som talar om för oss om en resa har ställts in. Vi har redan ett rekord för den åkturen i vår tabell, så vi kan bara markera resan som inställd.
payment_type_id och price – Dessa ger information om det belopp som betalats för en resa och vilken betalningsmetod som används av kunden.

De flesta av attributen i cab_ride tabellen kan innehålla ett NULL-värde. Det finns två anledningar till detta:

Åkturer ställs in, vilket innebär att ingen data kommer att anges i dessa fält;
Även om vi kommer att ha all data så småningom kommer vi inte att ha allt när posten initialt infogas. Vi kommer att uppdatera varje post flera gånger – vi uppdaterar det åtminstone när åkturen startar och slutar (eller avbryts).

Den andra tabellen i det här avsnittet är cab_ride_status tabell. Här läggs ett rekord för varje förändring relaterad till en enskild åktur. När samordnaren anger en ny resa i systemet lägger de till en post i cab_ride tabellen, men en relaterad post kommer också att skapas i cab_ride_status tabell (tillsammans med motsvarande status). Efter varje ändring relaterad till den åkturen kommer ytterligare ett rekord att läggas till i tabellen. Attributen är:

cab_ride_id och status_id – Dessa är främmande nycklar som är relaterade till id-attributet i ride tabellen och id-attributet i status tabell (som vi kommer att täcka nedan). Båda är obligatoriska.
status_time – Detta lagrar den faktiska tiden när posten infogades. Det är också obligatoriskt.
cc_agent_id och shift_id – Det här är referenser till den anställde som lagt in en statusuppdatering. Det kan vara antingen en avsändare eller en förare. Förmodligen kommer avsändaren att infoga den initiala statusen och föraren kommer att infoga alla följande statusar.
status_details – Detta är ett textattribut som kan användas för att lagra ytterligare information. En samordnare kan till exempel använda det här attributet för att registrera särskilda instruktioner om en åktur.

Okategoriserade tabeller

Slutligen, låt oss snabbt gå igenom våra okategoriserade tabeller.

cc_agent Tabellen innehåller en lista över callcenteragenter eller samordnare som kan lägga till nya poster i cab_ride och cab_ride_status tabeller.

I status ordbok kommer vi att lagra en lista över alla möjliga statusar som vi kan tilldela en resa. Vissa värden inkluderar "ny resa" , "tur tilldelad förare" , "åkning påbörjad" , "turen avslutad" , eller "tur inställd" .

Payment_type är en annan ordbokstabell. Dess innehåll används för att uppdatera payment_type_id attribut i cab_ride tabell. Vanliga värden är "kontanter" och "kreditkort" .

Hur skulle du förbättra taxidatamodellen?

Hytt-/taxidatabasmodellen som presenteras i den här artikeln fokuserar endast på de viktigaste funktionerna. Det finns många förbättringar vi skulle kunna göra. Rutter är bara en som jag kan tänka mig.

I framtiden kommer vi förmodligen att ha förarlösa hytter. I så fall skulle vi ta bort föraren från modellen och ersätta saker som laddnings- och reparationstider.

Kommentera gärna och lägg till dina idéer.