En databasemodel for en taxatjeneste

Kald dem taxaer eller førerhuse, disse bekvemme forlystelser til leje har eksisteret i århundreder. I dag er det meget mere kompliceret at drive taxa. I denne artikel vil vi se på en databasemodel, der er designet til at imødekomme behovene hos et førerhusfirma.

Historien om at "kalde en taxa" begyndte i London fra det 17. århundrede. De fleste steder er førerhuse mere overkommelige end nogensinde før. De bliver også meget mere tilgængelige:Vi kan bestille en taxa via telefon, via mobilapplikationer eller på nettet. Eller vi kan bruge de samme teknikker, som har virket i hundreder af år – stille op ved en førerhusstation eller flag en nede på gaden.

Taxa-forretningsmodellen er på ingen måde stillestående. Nyere koncepter som Uber og Lyft vinder popularitet og vil helt sikkert have indflydelse på fremtiden for taxitjenester. Alt dette komplicerer selvfølgelig livet for dem, der driver førerhusfirmaer. Lad os tage et kig på de relevante dele af en datamodel, som et førerhusfirma kunne bruge til at forblive organiseret.

Hvad ønsker vi at opnå med denne førerhusdatabasemodel?

Modellen præsenteret i denne artikel vil være i stand til at:

Opret chaufførplaner
Spor drivertilgængelighed i realtid
Giv chauffører en liste over potentielle ture
Tillad chauffører at vælge en tur fra listen
Beregn chaufførers arbejdstid og indtjening
Gem forskellige statistikker (f.eks. procentdel af aflyste ture, betalinger pr. chauffør pr. måned osv.)

Hvad skal vi vide om taxaselskaber?

Før vi designer en datamodel for et førerhusfirma, bør vi være i stand til at besvare følgende spørgsmål:

Hvornår virker drivere?
I de fleste førerhusfirmaer har chaufførerne foruddefinerede køreplaner. Vi kender de nøjagtige tidspunkter, hvor chaufføren starter og slutter et skift. I nogle tilfælde er skiftets start- og sluttidspunkter ikke defineret på forhånd. For eksempel kan medlemmer af en førerhusforening logge ind og begynde at arbejde, når de vil. De kan også logge ud og afslutte deres vagt, når de ønsker det. Vores model burde kunne understøtte begge muligheder.
Kan en chauffør arbejde flere skift på samme dag?
Hvis chaufføren er medlem af en førerhusforening, kan de måske arbejde om morgenen, tage hjem og så arbejde igen samme aften. I nogle områder (såsom New York City) er der dog lovmæssige begrænsninger på vagtlængde og/eller hvor mange timer taxachauffører kan arbejde hver dag.
3. Hvem starter en tur?
I de fleste tilfælde vil en kunde kontakte taxaens callcenter, og ekspeditøren vil indtaste deres anmodning i systemet. Et andet scenarie opstår, når kunden bestiller en taxa direkte (f.eks. via mobilapp), og der ikke er nogen callcenter-medarbejder involveret i processen. En tredje mulighed – som også går uden om callcenteret – opstår, når en kunde får en taxa på stationen eller prajer en på gaden.

Datamodellen

Vores model har to hovedsektioner og tre ukategoriserede tabeller. Vi vil se nærmere på hver af dem.

Sektion 1:Førerhuse, chauffører og skift

Alt starter med førerhuse og chauffører:Vi har brug for biler i et taxaselskab, og vi har brug for chauffører. (I fremtiden bliver vi nok nødt til at justere vores model til selvkørende biler. Men lad os blive i nuet for nu.)

Vi begynder vores udforskning af datamodellen med driver bord. I denne tabel inkluderer vi de sædvanlige attributter som navn, efternavn og fødselsdato. Vi har også nogle egenskaber, der er ret specifikke for denne model:

driving_licence_number – Dette er et id-nummer eller en alfanumerisk kode, der normalt findes på en offentligt udstedt licens. Da dette ID er unikt i den virkelige verden, vil det også være unikt i vores database. (I nogle områder skal taxachauffører have en særlig type driftslicens for at arbejde; vi antager, at de har det.)
expiry_date - Dette er den dato, hvor et kørekort ikke længere er juridisk gyldigt. Bemærk, at vi ikke gemmer licenshistorikken, så vi overskriver simpelthen driving_licence_number og expiry_date med nye data efter behov. Hvis vi vil gemme licenshistorier, skal vi tilføje en anden tabel til vores model.
working – Dette er en boolsk værdi, der blot tændes og slukkes, når chauffører logger ind på systemet. Vi indstiller denne egenskab som standard til "Ja" (værdi 1) og ændrer den kun til "Nej", når chaufføren ikke længere har tilladelse til at logge ind på systemet.

Der er mange andre chaufførrelaterede detaljer, vi kunne gemme i databasen:brugernavne og adgangskoder, datoen for hver chauffør begyndte at arbejde, og hver chaufførs aktuelle ansættelsestype. Vi vil ikke gå ind i disse detaljer nu, fordi de ikke er specifikt relateret til denne model. Jeg vil klassificere dem under brugeradministration, hvilket er det samme i de fleste systemer.

Lad os nu gå videre til cab og car_model tabeller. Det er her, vi gemmer en liste over de biler, som vores virksomhed driver. Vi gemmer også visse detaljer om hvert køretøj. De vigtigste egenskaber i disse to tabeller er:

model_description – Dette er en tekstattribut, der holder en virksomhedsspecificeret beskrivelse af en bestemt type bil. For eksempel vil førerhusfirmaer måske gemme antallet af passagerer, en bil kan transportere, bagagerumsplads og andre fakta.
license_plate – Nummeret på en nummerplade (køretøjets nummerplade eller nummerplade) definerer entydigt en bil, både for en virksomhed og til offentlige formål. Det kan selvfølgelig være, at vi skal ændre nummerpladeoplysninger, hvis en bil bliver købt eller solgt. I denne tabel gemmer vi kun virksomhedens nuværende køretøjer; hvis vi har brug for at beholde en historik, kan vi tilføje en tabel mere til vores model.
owner_id – Denne attribut er en reference til driver bord. Det er valgfrit, fordi vi kun bruger det, når chaufføren ejer deres førerhus. (Dette er normalt tilfældet i førerhusforeninger).
active – Dette er en boolsk værdi, der angiver, om virksomheden stadig bruger en bil.

Lad os endelig tage et kig på den vigtigste tabel i dette afsnit:shift bord. Tanken bag denne tabel er at gemme den faktiske arbejdstid og tidsplanen vagter for biler og chauffører. Hvert skift vil have mindst én førerhus (cab_id ) og én driver (driver_id ). Bortset fra den primære nøgle, som er et unikt skift-id-nummer, er disse de eneste obligatoriske attributter i denne tabel.

shift_start_time og shift_end_time attributter er de faktiske øjeblikke, hvor et skift starter og slutter. Disse er ofte forudindstillede. Hvis der ikke er nogen tidsplan, som i en førerhusforening, vil disse tider være de samme som login_time og logout_time henholdsvis attributter. login_time og logout_time er de faktiske tidspunkter, chaufførerne logger ind (via en mobil enhed i deres bil eller hvilken metode taxaselskabet bruger). Når chaufføren logger på systemet, vises en liste over tilgængelige ture, og chaufføren vælger en. Afsenderen får selvfølgelig også besked om, at chaufføren nu virker.

Afsnit 2:Forlystelser

Denne sektion består af kun to tabeller, men de er det sande hjerte i denne model.

I cab_ride tabel, gemmer vi én rekord for hver potentiel tur. Vi opdaterer denne post i henhold til, hvad der sker. Lad os få et hurtigt overblik over egenskaberne:

shift_id – Dette er en reference til shift bord; det giver os chauffør- og førerhusdetaljer for en given tur.
ride_start_time og ride_end_time – Disse opdateres, når chauffører signalerer, at de i øjeblikket er optaget (turstart) og efterfølgende tilgængelige igen (turslut).
address_starting_point og address_destination – Det er de steder, hvor en tur starter og slutter. Chaufføren vil sandsynligvis søge efter begge steder for at få navigationen på sin tablet eller GPS, så det er sandsynligvis, når vi opdaterer disse to attributter.
GPS_starting_point og GPS_destination – Dette er GPS-koordinaterne for start- og slutpositionerne beskrevet ovenfor. Disse værdier er valgfrie, fordi vi kun opdaterer dem, når vi har data.
canceled – Dette er en simpel Ja/Nej-værdi, der fortæller os, om en tur er blevet aflyst. Vi har allerede en rekord for den tur i vores tabel, så vi kan bare markere turen som aflyst.
payment_type_id og price – Disse giver oplysninger om det beløb, der er betalt for en tur, og den betalingsmetode, som kunden bruger.

De fleste af attributterne i cab_ride tabel kan indeholde en NULL-værdi. Der er to grunde til dette:

Kørsler bliver aflyst, hvilket betyder, at der ikke vil blive indtastet data i disse felter;
Selv om vi vil have alle data til sidst, vil vi ikke have det hele, når posten oprindeligt indsættes. Vi opdaterer hver rekord flere gange – i det mindste opdaterer vi den, når turen starter og slutter (eller aflyses).

Den anden tabel i dette afsnit er cab_ride_status bord. Her tilføjes en rekord for hver ændring relateret til en enkelt tur. Når kørselslederen indtaster en ny tur i systemet, tilføjer de en registrering til cab_ride tabel, men en relateret post vil også blive oprettet i cab_ride_status tabel (sammen med den tilsvarende status). Efter hver ændring relateret til den tur, vil der blive tilføjet en rekord mere til denne tabel. Attributterne er:

cab_ride_id og status_id – Disse er fremmednøgler, der er relateret til id-attributten i ride tabel og id-attributten i status tabel (som vi vil dække nedenfor). Begge er obligatoriske.
status_time – Dette gemmer det faktiske tidspunkt, hvor posten blev indsat. Det er også obligatorisk.
cc_agent_id og shift_id – Det er referencer til den medarbejder, der har indsat en statusopdatering. Det kan enten være en dispatcher eller en chauffør. Sandsynligvis vil afsenderen indsætte den oprindelige status, og chaufføren vil indsætte alle følgende statusser.
status_details – Dette er en tekstattribut, der kan bruges til at gemme yderligere information. For eksempel kan en koordinator bruge denne egenskab til at registrere særlige instruktioner om en tur.

Ukategoriserede tabeller

Lad os endelig hurtigt gennemgå vores ukategoriserede tabeller.

cc_agent tabel indeholder en liste over call center-agenter eller koordinatorer, der kan tilføje nye poster i cab_ride og cab_ride_status tabeller.

I status ordbog, gemmer vi en liste over alle mulige statusser, som vi kunne tildele en tur. Nogle værdier inkluderer "ny tur" , "tur tildelt chauffør" , "tur startede" , "tur endt" , eller "tur annulleret" .

Payment_type er en anden ordbogstabel. Dens indhold bruges til at opdatere payment_type_id attribut i cab_ride bord. Fælles værdier er "kontanter" og "kreditkort" .

Hvordan ville du forbedre taxadatamodellen?

Cab/taxa-databasemodellen præsenteret i denne artikel er kun fokuseret på de vigtigste funktionaliteter. Der er mange forbedringer, vi kan lave. Ruter er bare én, jeg kan komme i tanke om.

I fremtiden vil vi sandsynligvis have førerløse førerhuse. I så fald ville vi droppe chaufføren fra modellen og erstatte ting som genopladning og reparationstider.

Du er velkommen til at kommentere og tilføje dine ideer.