Creazione di un modello di dati per il carpooling

Al giorno d'oggi, il carpooling è accettato e promosso da persone in tutto il mondo. Sicuramente riduce la propria impronta di carbonio personale e può essere più conveniente rispetto al noleggio o all'acquisto di un'auto.

Anche il carpooling richiede molto lavoro:un lavoro organizzativo che può essere svolto facilmente da un database ben progettato. Questo articolo spiega un modello di dati dettagliato che potrebbe essere utilizzato da un sito Web di carpooling.

Progettazione dei dati, incontra il carpooling

Quindi, dobbiamo progettare un modello di dati per un sito Web di condivisione di corse (noto anche come carpooling).

Il carpooling è un po' diverso dal noleggio auto. Nel carpooling, l'auto è di proprietà di una persona e offrono passaggi ad altri. Eventuali co-viaggiatori pagano per il costo della corsa, inclusi carburante, pedaggi stradali, ecc.

Requisiti del progetto:

Il sito web dovrebbe consentire agli utenti (alias membri del ride-share) per registrarsi utilizzando il proprio nome, numero di telefono, indirizzo e-mail, numero di patente, ecc.
I membri dovrebbero poter impostare le proprie preferenze per quanto riguarda le giostre e i co-viaggiatori.
I membri chiamati proprietari di una corsa possono creare una corsa inserendo i dettagli del viaggio (ovvero, punti di partenza e di destinazione, ora di inizio, costi per ciclista, ecc.)
Gli altri membri possono cercare le corse disponibili verso una città di destinazione .
I membri che cercano una corsa possono contattare il proprietario della corsa e inserire una prenotazione per i loro posti.
Il proprietario della corsa dovrebbe essere in grado di approvare o rifiutare le richieste di prenotazione.
In base all'azione intrapresa dal proprietario della corsa sulla richiesta di prenotazione, il conteggio dei posti disponibili dovrebbe essere aggiornato.
Il proprietario della corsa può anche contrassegnare le città lungo il percorso, ovvero le città lungo il percorso dal punto di partenza alla destinazione. Se lo desiderano, i proprietari delle corse dovrebbero anche essere in grado di ospitare persone per le città in viaggio.

Tenendo presenti questi parametri, identifichiamo le principali entità e relazioni per il nostro modello di dati di carpooling.

Identificazione di entità e relazioni

Quando vedo i requisiti nel loro insieme, posso facilmente capire le entità principali. Sono:

membri (inclusi proprietari di motociclisti e co-viaggiatori )
auto
preferenze
corri
città
Richiesta di corsa

Membro – Tutti coloro che visitano questo sito Web devono registrarsi prima di utilizzarlo. In questo processo, devono fornire dettagli come first_name , last_name , gender , email e contact number . Per i compagni di viaggio, questi articoli sono sufficienti. I proprietari di auto, che presumibilmente guideranno, devono inserire alcuni dettagli aggiuntivi come driving_license_number e driving_license_valid_from dovrebbe anche essere incluso. Le informazioni sulla licenza raccontano ai co-viaggiatori qualcosa sull'esperienza di guida del proprietario della corsa. Questo aiuterà i co-viaggiatori a selezionare la migliore corsa disponibile. Aggiungerò una tabella denominata member con tutte le colonne richieste.

Auto – Il proprietario della corsa deve aggiungere i dettagli per almeno un'auto prima di creare una corsa. Creiamo quindi un'altra tabella, chiamata car , per memorizzare queste informazioni. Un membro può possedere più di un'auto. Una corsa può dipendere da una coppia membro-auto, quindi abbiamo bisogno di un'altra tabella per stabilire questa relazione. Chiameremo questa tabella member_car . Farò riferimento alla chiave primaria di questa tabella nel mio ride tabella dove memorizzerò i dettagli della corsa. Aggiungerò anche una colonna, ovvero comfort_level , che memorizza il livello di comfort di un'auto su una scala da 0 a 5. Questo livello viene calcolato automaticamente dal sistema, in base ai dettagli dell'auto forniti dagli altri membri.

Preferenze – Le preferenze contano per tutti. Il sito Web consente ai membri di inserire le loro preferenze sull'auto e sui loro compagni di viaggio. Questi dettagli rimangono facoltativi al momento della registrazione, ma devono essere inseriti prima di creare una corsa . Il proprietario della corsa cercherà probabilmente persone con preferenze simili in modo che tutti viaggino comodamente. Le persone che cercano un passaggio fanno lo stesso.

Alcune preferenze di base per i viaggi in auto sono:

È consentito fumare all'interno dell'auto?
Sono ammessi animali domestici?
Quanto è loquace il proprietario della corsa? Che livello di chiacchiere è accettabile durante la corsa? (Le possibili risposte qui includono nessuna, chiacchiere leggere, gabfest.)
Che tipo di musica piace al proprietario della corsa?
Quale volume della musica consente il proprietario della corsa?

Poiché questi dettagli sono facoltativi durante la registrazione, creerò un'altra tabella denominata member_preference per memorizzare questi dettagli. Due tabelle aggiuntive memorizzano le possibili opzioni per la musica (music_preference ) e conversazione in auto (chitchat_preference ).

Facciamo una relazione zero-a-uno tra il member e member_preference tabelle, poiché i membri possono o meno impostare le proprie preferenze nel sistema al momento dell'iscrizione e c'è un solo record per le preferenze per membro.

Città – Una tabella principale, city , è necessario per memorizzare un elenco di tutte le città servite dal sito web. Dovrebbe includere le informazioni relative allo stato e al paese per ciascuna città.

Corsa – Un membro può creare una corsa riempiendo l'auto con cui sta viaggiando; da quale città sta partendo; verso quale città si sta dirigendo; la data e l'ora del viaggio; il numero di posti disponibili; e contributo pro capite. Il contributo pro capite è l'importo che ogni co-viaggiatore deve pagare per le spese di viaggio. Il proprietario della corsa può anche menzionare la quantità di bagaglio che si aspetta dai co-viaggiatori in modo che tutto si adatti all'auto. Quindi aggiungiamo una colonna, luggage_size_allowed , per questo articolo. I valori possibili per questa colonna sarebbero light, medium e heavy.

Richiesta di corsa – I membri possono consultare l'elenco delle corse disponibili da una città all'altra o inviare una richiesta per un viaggio specifico. Abbiamo sicuramente bisogno di una tabella per memorizzare i dettagli su tali richieste. Una tabella chiamata request si adatta allo scopo. La richiesta viene inizialmente inserita come richiesta "inviata" e il proprietario della corsa è l'unica persona autorizzata ad approvarla o rifiutarla. Il numero di posti disponibili nella tabella delle corse sarà adeguato per ogni approvazione e/o rifiuto.

Città lungo il percorso – Il ride sharing non significa solo andare direttamente dal punto di partenza alla destinazione. Si può condividere un giro con gli altri anche per le città in rotta. Ad esempio, se un uomo sta viaggiando da Chicago a Miami, può ospitare qualcuno che vuole andare da Chicago a Nashville. Nashville è una delle città che attraverserà lungo il suo percorso, quindi è una città di passaggio. Il nostro sistema dovrebbe consentire ai proprietari delle corse di impostare le città lungo il percorso in base al percorso che seguiranno per raggiungere la loro destinazione. Se i compagni di viaggio lo desiderano, possono scendere in una qualsiasi delle città lungo il percorso; le loro spese di viaggio saranno ripartite proporzionalmente.

Creeremo un'altra tabella chiamata enroute_city per questo scopo. I record verranno aggiunti quando il proprietario della corsa aggiunge le città lungo il percorso alla propria corsa. I membri possono quindi richiedere la prenotazione per viaggiare in una delle città lungo il percorso. Pertanto, rimando la chiave primaria di questa tabella nella request tavolo.

Il order_from_source colonna in enroute_city tabella indica il percorso che il proprietario della corsa seguirà per il viaggio.

Rapporti sul sito web:

Ci sono vari rapporti (estratti di dati) che possono essere mostrati su questo sito web. Ve ne spiego alcuni:

Corse disponibili da una città specifica all'altra – Questo è uno dei rapporti che verrà estratto abbastanza frequentemente, poiché descrive l'essenza di questo sito Web. La maggior parte dei membri accederà a questo sito Web per cercare alternative di viaggio o condivisioni di corse. Durante l'estrazione di questo rapporto, i membri devono inserire i nomi delle città di partenza e di destinazione. L'SQL segue:

Select m.first_name || ‘ ‘ || m.last_name as “Ride Owner”, c.name as “Car”, c.comfort_level as “Comfort Level”, mp.is_smoking_allowed, mp.is_pet_allowed, r.travel_start_time, r.contribution_per_head, seats_offered 
from ride r, member_car mc, car c, member m, member_preference mp
where r.member_car_id = mc.id and mc.member_id = u.id 
and mc.car_id = c.id and m.id = mp.member_id
and source_city_id = (select city_id from city where city_name = ‘CHICAGO’)
and destination_city_id = (select city_id from city where city_name = ‘MIAMI’)
and seats_offered > (select count(id) from request req, request_status reqs where req.request_status_id = reqs.id and upper(reqs.description) = ‘APPROVE’ and req.ride_id = r.id);

Elenco delle richieste inviate/approvate per una corsa – Questo rapporto verrà visualizzato al proprietario della corsa. Mostrerà chi ha inviato la richiesta di corsa e il proprietario può agire solo sulle richieste di questo rapporto. L'SQL per questo segue:

select first_name || ‘ ‘ || last_name as “Submitter”,  req.created_on as “Submitted on”, rs.description as “Request Status” 
from member m, request req, request_status rs
where m.id = req.requester_id and rs.id = req.request_status_id
and req.ride_id = ;

Corse precedenti e attuali offerte – Questi rapporti verranno visualizzati per i proprietari di auto sui propri dashboard. Il seguente SQL può essere utilizzato per generare un elenco di corse attualmente offerte dal proprietario della corsa:

Select m.first_name || ‘ ‘ || m.last_name as “Ride Owner”, c.name as “Car”, c.comfort_level as “Comfort Level”, mp.is_smoking_allowed, mp.is_pet_allowed, r.travel_start_time, r.contribution_per_head, decode(seats_offered,0,’FULL’, seats_offered || ‘ seats available‘) from ride r, member_car mc, car c, member m, member_preference mp
where r.member_car_id = mc.id and mc.member_id = m.id 
and mc.car_id = c.id and u.id = mp.member_id
and r.travel_start_time >= sysdate
and m.id = ;

E questo SQL può essere utilizzato per estrarre un elenco di corse precedentemente offerte:

Select m.first_name || ‘ ‘ || m.last_name as “Ride Owner”, c.name as “Car”, c.comfort_level as “Comfort Level”, mp.is_smoking_allowed, mp.is_pet_allowed, r.travel_start_time, r.contribution_per_head, decode(seats_offered,0,’FULL’, seats_offered || ‘ seats available‘) from ride r, member_car mc, car c, member m, member_preference mp
where r.member_car_id = mc.id and mc.member_id = m.id 
and mc.car_id = c.id and u.id = mp.member_id
and r.travel_start_time < sysdate
and m.id = ;

Elenco dei co-viaggiatori per un passaggio – Questo rapporto sarà disponibile per tutti i co-viaggiatori, incluso il proprietario della corsa. Tutti possono generare un elenco di tutti i co-viaggiatori per le loro corse passate o future.

select first_name || ‘ ‘ || last_name 
from member m, request req, request_status rs
where m.id = req.requester_id and rs.id = req.request_status_id
and rs.description = ‘APPROVED’
and req.ride_id = 
UNION
select first_name || ‘ ‘ || last_name 
from member m, member_car mc, ride r
where m.id = mc.member_id and mc.id = r.member_car_id 
and r.id = ;

Il modello di dati finale

E i miglioramenti?

Possiamo migliorare ulteriormente questo modello? Sì possiamo! Ci sono ancora alcune aree che devono essere curate.

E se si desidera creare richieste di corsa ricorrenti? Supponiamo che un guidatore viaggi da una città all'altra ogni fine settimana e sia sempre disposto a condividere questo viaggio. Sarebbe più conveniente una richiesta ricorrente.

Come può una persona fare affidamento su un ragazzo sconosciuto che offre un passaggio? Dovrebbe esserci un modo per aiutare le persone a valutare gli altri prima di richiedere un passaggio. Un meccanismo praticabile è pubblicare e condividere feedback sui proprietari di corse e sui co-viaggiatori. Questi dettagli aiuteranno sicuramente gli altri a prenotare un passaggio con estranei con maggiore sicurezza. Affinché ciò avvenga, quali modifiche sono necessarie al nostro modello di dati?

Sentiti libero di condividere i tuoi input su questo modello.