Un modello di database per un servizio taxi

Chiamali taxi o taxi, queste comode corse in affitto esistono da secoli. Al giorno d'oggi, è molto più complicato gestire un servizio taxi. In questo articolo, esamineremo un modello di database progettato per soddisfare le esigenze di un'azienda di taxi.

La storia del "chiamare un taxi" inizia nella Londra del 17° secolo. Nella maggior parte dei posti, i taxi sono più convenienti che mai. Stanno anche diventando molto più accessibili:possiamo ordinare un taxi per telefono, tramite applicazioni mobili o sul Web. Oppure possiamo usare le stesse tecniche che funzionano da centinaia di anni:fare la fila alla stazione dei taxi o fermarne una per strada.

Il modello di business dei taxi non è affatto stagnante. Nuovi concetti come Uber e Lyft stanno guadagnando popolarità e avranno sicuramente un impatto sul futuro dei servizi di taxi. Naturalmente, tutto questo complica la vita di coloro che gestiscono le compagnie di taxi. Diamo un'occhiata alle parti pertinenti di un modello di dati che un'azienda di taxi potrebbe utilizzare per rimanere organizzata.

Cosa vogliamo ottenere con questo modello di database della cabina?

Il modello presentato in questo articolo sarà in grado di:

Crea orari dei conducenti
Traccia la disponibilità dei conducenti in tempo reale
Fornire ai conducenti un elenco di potenziali corse
Consenti ai conducenti di selezionare una corsa dall'elenco
Calcola l'orario di lavoro e i guadagni degli autisti
Memorizza varie statistiche (ad es. percentuale di corse annullate, pagamenti mensili per conducente, ecc.)

Cosa dobbiamo sapere sulle compagnie di taxi?

Prima di progettare un modello di dati per un'azienda di taxi, dovremmo essere in grado di rispondere alle seguenti domande:

Quando funzionano i conducenti?
Nella maggior parte delle compagnie di taxi, i conducenti hanno orari predefiniti. Sapremo gli orari esatti in cui l'autista inizia e finisce un turno. In alcuni casi, gli orari di inizio e fine turno non sono definiti in anticipo. Ad esempio, i membri di un'associazione di taxi possono accedere e iniziare a lavorare quando vogliono. Possono anche disconnettersi e terminare il loro turno quando lo desiderano. Il nostro modello dovrebbe essere in grado di supportare entrambe le opzioni.
Un autista può lavorare su più turni nello stesso giorno?
Se l'autista è membro di un'associazione di taxi, potrebbe essere in grado di lavorare la mattina, tornare a casa e poi lavorare di nuovo la sera stessa. Tuttavia, in alcune aree (come New York City) ci sono restrizioni legali sulla durata del turno e/o sul numero di ore di lavoro dei tassisti ogni giorno.
3. Chi avvia una corsa?
Nella maggior parte dei casi, un cliente contatterà il call center del taxi e lo spedizioniere inserirà la sua richiesta nel sistema. Un altro scenario si verifica quando il cliente ordina un taxi direttamente (tramite app mobile, ad esempio) e non vi è alcun dipendente del call center coinvolto nel processo. Una terza opzione, che aggira anche il call center, si verifica quando un cliente prende un taxi alla stazione o ne chiama uno per strada.

Il modello dei dati

Il nostro modello ha due sezioni principali e tre tabelle non categorizzate. Daremo un'occhiata più da vicino a ciascuno di essi.

Sezione 1:taxi, autisti e turni

Tutto inizia con taxi e autisti:abbiamo bisogno di auto in una compagnia di taxi e abbiamo bisogno di autisti. (In futuro, probabilmente dovremo adattare il nostro modello alle auto a guida autonoma. Ma per ora rimaniamo nel presente.)

Inizieremo la nostra esplorazione del modello di dati con il driver tavolo. In questa tabella includeremo i soliti attributi come nome, cognome e data di nascita. Avremo anche alcuni attributi abbastanza specifici per questo modello:

driving_licence_number – Questo è un numero ID o un codice alfanumerico che di solito si trova su una licenza rilasciata dal governo. Poiché questo ID è unico nel mondo reale, lo sarà anche nel nostro database. (In alcune aree, i conducenti di taxi devono avere un tipo speciale di licenza operativa per lavorare; supponiamo che lo abbiano.)
expiry_date – Questa è la data in cui una patente di guida non è più legalmente valida. Nota che non memorizzeremo la cronologia delle licenze, quindi sovrascriveremo semplicemente driving_licence_number e expiry_date con nuovi dati secondo necessità. Se vogliamo archiviare le cronologie delle licenze, dovremmo aggiungere un'altra tabella al nostro modello.
working – Questo è un valore booleano che si accende e si spegne semplicemente quando i driver accedono al sistema. Imposteremo questo attributo per impostazione predefinita su "Sì" (valore 1) e lo cambieremo in "No" solo quando al conducente non è più consentito accedere al sistema.

Ci sono molti altri dettagli relativi ai conducenti che potremmo memorizzare nel database:nomi utente e password, la data in cui ogni conducente ha iniziato a lavorare e il tipo di impiego attuale di ciascun conducente. Non entreremo in questi dettagli ora perché non sono specificamente correlati a questo modello. Li classificherei sotto l'amministrazione degli utenti, che è la stessa nella maggior parte dei sistemi.

Passiamo ora al cab e il car_model tavoli. Qui è dove memorizzeremo un elenco delle auto gestite dalla nostra azienda. Conserveremo anche alcuni dettagli su ciascun veicolo. Gli attributi più importanti in queste due tabelle sono:

model_description – Questo è un attributo di testo che mantiene una descrizione specificata dall'azienda di un determinato tipo di auto. Ad esempio, le compagnie di taxi potrebbero voler memorizzare il numero di passeggeri che un'auto può trasportare, lo spazio nel bagagliaio (bagagli) e altri dati.
license_plate – Il numero su una targa (targa di immatricolazione del veicolo o targa) definisce in modo univoco un'auto, sia per un'azienda che per scopi governativi. Naturalmente, potrebbe essere necessario modificare le informazioni sulla targa se un'auto viene acquistata o venduta. In questa tabella conserveremo solo i veicoli attuali dell'azienda; se dobbiamo mantenere una cronologia, possiamo aggiungere un'altra tabella al nostro modello.
owner_id – Questo attributo è un riferimento al driver tavolo. È facoltativo perché lo useremo solo quando l'autista possiede il suo taxi. (Questo di solito è il caso delle associazioni di taxi).
active – Questo è un valore booleano che indica se l'azienda sta ancora utilizzando un'auto.

Infine, diamo un'occhiata alla tabella più importante di questa sezione:il shift tavolo. L'idea alla base di questa tabella è quella di memorizzare l'orario di lavoro effettivo e i turni programmati per auto e conducenti. Ogni turno avrà almeno un taxi (cab_id ) e un driver (driver_id ). A parte la chiave primaria, che è un numero ID turno univoco, questi sono gli unici attributi obbligatori in questa tabella.

Il shift_start_time e shift_end_time gli attributi sono i momenti effettivi in cui inizia e finisce un turno. Spesso, questi sono preimpostati. Nel caso in cui non ci siano orari, come in un'associazione taxi, questi orari sarebbero gli stessi del login_time e logout_time attributi, rispettivamente. Il login_time e il logout_time sono gli orari effettivi in cui i conducenti effettuano l'accesso (tramite un dispositivo mobile nella loro auto o qualsiasi metodo utilizzato dalla compagnia di taxi). Quando il conducente accede al sistema, verrà visualizzato un elenco di corse disponibili e il conducente ne sceglierà una. Naturalmente, anche lo spedizioniere verrà informato che l'autista sta lavorando.

Sezione 2:Corse

Questa sezione è composta da due sole tabelle, ma sono il vero cuore di questo modello.

Nel cab_ride tabella, memorizzeremo un record per ogni potenziale corsa. Aggiorneremo questo record in base a ciò che accade. Diamo una rapida panoramica degli attributi:

shift_id – Questo è un riferimento al shift tavolo; ci fornisce i dettagli del conducente e del taxi per una determinata corsa.
ride_start_time e ride_end_time – Questi vengono aggiornati quando i conducenti segnalano che sono attualmente occupati (inizio corsa) e successivamente nuovamente disponibili (fine corsa).
address_starting_point e address_destination – Questi sono i luoghi in cui inizia e finisce una corsa. L'autista probabilmente cercherà entrambe le posizioni per ottenere la navigazione sul suo tablet o GPS, quindi è probabile che aggiorneremo questi due attributi.
GPS_starting_point e GPS_destination – Queste sono le coordinate GPS delle località di partenza e di arrivo sopra descritte. Questi valori sono facoltativi perché li aggiorneremo solo quando avremo dati.
canceled – Questo è un semplice valore Sì/No che ci dice se una corsa è stata cancellata. Avremo già un record per quella corsa nella nostra tabella, quindi possiamo semplicemente contrassegnare la corsa come annullata.
payment_type_id e price – Questi forniscono informazioni sull'importo pagato per una corsa e sul metodo di pagamento utilizzato dal cliente.

La maggior parte degli attributi nel cab_ride la tabella può contenere un valore NULL. Ci sono due ragioni per questo:

Le corse vengono annullate, il che significa che non verranno inseriti dati in questi campi;
Anche se alla fine avremo tutti i dati, non li avremo tutti quando il record verrà inizialmente inserito. Aggiorneremo ogni record più volte, almeno lo aggiorneremo quando la corsa inizia e finisce (o viene annullata).

La seconda tabella in questa sezione è cab_ride_status tavolo. Qui viene aggiunto un record per ogni modifica relativa a una singola corsa. Quando il committente inserisce una nuova corsa nel sistema, aggiungerà un record al cab_ride tabella, ma verrà creato anche un record correlato nel cab_ride_status tabella (insieme allo stato corrispondente). Dopo ogni modifica relativa a quella corsa, verrà aggiunto un altro record a questa tabella. Gli attributi sono:

cab_ride_id e status_id – Si tratta di chiavi esterne correlate all'attributo id nel ride tabella e l'attributo id nello status tabella (che tratteremo di seguito). Entrambi sono obbligatori.
status_time – Memorizza l'ora effettiva in cui è stato inserito il record. È anche obbligatorio.
cc_agent_id e shift_id – Si tratta di riferimenti al dipendente che ha inserito un aggiornamento di stato. Può essere uno spedizioniere o un autista. Probabilmente il dispatcher inserirà lo stato iniziale e l'autista inserirà tutti gli stati seguenti.
status_details – Questo è un attributo di testo che può essere utilizzato per memorizzare informazioni aggiuntive. Ad esempio, un spedizioniere potrebbe utilizzare questo attributo per registrare istruzioni speciali su una corsa.

Tabelle senza categoria

Infine, esaminiamo rapidamente le nostre tabelle non categorizzate.

Il cc_agent la tabella contiene un elenco di agenti o spedizionieri di call center che possono aggiungere nuovi record nel cab_ride e cab_ride_status tabelle.

Nello status dizionario, memorizzeremo un elenco di tutti i possibili stati che potremmo assegnare a una corsa. Alcuni valori includono "nuova corsa" , "corsa assegnata all'autista" , "corsa iniziata" , "corsa terminata" o "corsa annullata" .

Payment_type è un'altra tabella del dizionario. I suoi contenuti vengono utilizzati per aggiornare il payment_type_id attributo nel cab_ride tavolo. I valori comuni sono "contanti" e "carta di credito" .

Come miglioreresti il modello di dati sui taxi?

Il modello di database taxi/taxi presentato in questo articolo si concentra solo sulle funzionalità più importanti. Ci sono numerosi miglioramenti che potremmo apportare. I percorsi sono solo uno che mi viene in mente.

In futuro, probabilmente avremo taxi senza conducente. In tal caso, elimineremmo il driver dal modello e sostituiremmo cose come i tempi di ricarica e riparazione.

Sentiti libero di commentare e aggiungere le tue idee.