Créer un modèle de données pour le covoiturage

De nos jours, le covoiturage est accepté et promu par les gens du monde entier. Cela réduit certainement son empreinte carbone personnelle, et cela peut être plus rentable que la location ou l'achat d'une voiture.

Le covoiturage demande également beaucoup de travail – un travail d'organisation qui peut facilement être effectué par une base de données bien conçue. Cet article explique un modèle de données détaillé qu'un site Web de covoiturage pourrait utiliser.

Conception de données, rencontrez le covoiturage

Nous devons donc concevoir un modèle de données pour un site Web de covoiturage (c'est-à-dire de covoiturage).

Le covoiturage est un peu différent d'une location de voiture. Dans le covoiturage, la voiture appartient à une personne et elle propose des trajets à d'autres. Tous les co-voyageurs paient le coût du trajet, y compris le carburant, les péages routiers, etc.

Exigences du projet :

Le site Web doit permettre aux utilisateurs (c'est-à-dire les membres du covoiturage) de s'inscrire en utilisant leur nom, leur numéro de téléphone, leur adresse e-mail, leur numéro de permis de conduire, etc.
Les membres doivent être autorisés à définir leurs préférences concernant les covoiturages et les co-voyageurs.
Les membres appelés propriétaires de trajet peuvent créer un trajet en saisissant les détails de leur voyage (c'est-à-dire les points de départ et de destination, l'heure de départ, les coûts par passager, etc.)
Les autres membres peuvent rechercher des covoiturages disponibles vers une ville de destination .
Les membres qui recherchent une course peuvent contacter le propriétaire de la course et effectuer une réservation pour leurs sièges.
Le propriétaire du trajet doit pouvoir approuver ou rejeter les demandes de réservation.
En fonction de l'action entreprise par le propriétaire du trajet sur la demande de réservation, le nombre de sièges disponibles doit être mis à jour.
Le propriétaire du trajet peut également marquer les villes en route, c'est-à-dire les villes sur le chemin entre leur point de départ et leur destination. S'ils le souhaitent, les propriétaires de manèges doivent également être en mesure d'accueillir des personnes pour les villes en route.

Avec ces paramètres à l'esprit, identifions les principales entités et relations pour notre modèle de données de covoiturage.

Identifier les entités et les relations

Lorsque je vois les exigences dans leur ensemble, je peux facilement identifier les principales entités. Ce sont :

membres (y compris les propriétaires de passagers et co-voyageurs )
voiture
préférences
rouler
ville
demande de covoiturage

Membre – Toute personne visitant ce site Web doit s'inscrire avant de l'utiliser. Dans ce processus, ils doivent fournir des détails tels que first_name , last_name , gender , email , et contact number . Pour les co-voyageurs, ces articles sont suffisants. Les propriétaires de manèges, qui conduiront vraisemblablement, doivent fournir des informations supplémentaires telles que driving_license_number et driving_license_valid_from devrait également être inclus. Les informations sur la licence renseignent les co-voyageurs sur l'expérience de conduite du propriétaire du trajet. Cela aidera les co-voyageurs à sélectionner le meilleur trajet disponible. Je vais ajouter une table nommée member avec toutes les colonnes requises.

Voiture – Le propriétaire du trajet doit ajouter des détails pour au moins une voiture avant de créer un trajet. Créons donc une autre table, appelée car , pour stocker ces informations. Un membre peut posséder plus d'une voiture. Un trajet peut dépendre d'une paire membre-voiture, nous avons donc besoin d'une autre table pour établir cette relation. Nous appellerons cette table member_car . Je ferai référence à la clé primaire de cette table dans mon ride table où je stockerai les détails du trajet. Je vais également ajouter une colonne, à savoir comfort_level , qui stocke le niveau de confort d'une voiture sur une échelle de 0 à 5. Ce niveau est automatiquement calculé par le système, sur la base des autres détails fournis par les membres sur la voiture.

Préférences – Les préférences comptent pour tout le monde. Le site Web permet aux membres de remplir leurs préférences concernant la voiture et leurs co-voyageurs. Ces informations restent facultatives au moment de l'inscription, mais doivent être renseignées avant de créer un trajet . Le propriétaire du manège cherchera probablement des personnes ayant des préférences similaires afin que tout le monde voyage confortablement. Les personnes qui recherchent des covoiturages font de même.

Voici quelques préférences de base pour les déplacements en voiture :

Est-il permis de fumer à l'intérieur de la voiture ?
Les animaux domestiques sont-ils autorisés ?
Dans quelle mesure le propriétaire du manège est-il bavard ? Quel niveau de bavardage est acceptable pendant le trajet ? (Les réponses possibles ici incluent aucune, bavardage léger, bavardage.)
Quel type de musique le propriétaire du manège aime-t-il ?
Quel volume de musique le propriétaire du trajet autorise-t-il ?

Étant donné que ces détails sont facultatifs lors de l'inscription, je vais créer une autre table nommée member_preference pour stocker ces détails. Deux tables supplémentaires stockent les options possibles pour la musique (music_preference ) et conversation en voiture (chitchat_preference ).

Ayons une relation de zéro à un entre le member et member_preference tables, car les membres peuvent ou non définir leurs préférences dans le système lorsqu'ils s'inscrivent, et il n'y a qu'un seul enregistrement pour les préférences par membre.

Ville – Une table principale, city , est nécessaire pour stocker une liste de toutes les villes desservies par le site Web. Il doit inclure les informations pertinentes sur l'état et le pays pour chaque ville.

Traverser – Un membre peut créer un trajet en renseignant avec quelle voiture il voyage; de quelle ville il part; vers quelle ville il se dirige; la date et l'heure du voyage; le nombre de places disponibles; et contribution par tête. La contribution par personne est le montant que chaque covoyageur doit payer pour les frais de transport. Le propriétaire du trajet peut également mentionner la quantité de bagages qu'il attend des co-voyageurs afin que tout rentre dans la voiture. Nous ajoutons donc une colonne, luggage_size_allowed , pour cet article. Les valeurs possibles pour cette colonne seraient légères, moyennes et lourdes.

Demande de covoiturage – Les membres peuvent consulter la liste des trajets disponibles d'une ville à l'autre ou faire une demande pour un trajet spécifique. Nous avons certainement besoin d'une table pour stocker les détails de ces demandes. Une table appelée request correspond à l'objectif. La demande est initialement saisie comme une demande "soumise" et le propriétaire du trajet est la seule personne autorisée à l'approuver ou à la rejeter. Le nombre de places disponibles dans le tableau des trajets sera ajusté pour chaque approbation et/ou refus.

Villes en route – Le covoiturage ne consiste pas uniquement à aller directement du point de départ à la destination. On peut également partager un trajet avec d'autres pour les villes en route. Par exemple, si un homme voyage de Chicago à Miami, il peut accueillir quelqu'un qui veut aller de Chicago à Nashville. Nashville est l'une des villes qu'il traversera sur sa route, c'est donc une ville en route. Notre système devrait permettre aux propriétaires de trajets de définir des villes en route en fonction de l'itinéraire qu'ils vont suivre pour atteindre leur destination. Si les co-voyageurs le souhaitent, ils peuvent descendre dans n'importe quelle ville en route; leurs frais de déplacement seront calculés au prorata en conséquence.

Nous allons créer une autre table appelée enroute_city dans ce but. Les enregistrements seront ajoutés lorsque le propriétaire du trajet ajoutera des villes en cours de route à son trajet. Les membres peuvent ensuite demander des réservations pour se rendre dans l'une des villes en route. Par conséquent, je renvoie la clé primaire de cette table dans la request table.

Le order_from_source colonne dans enroute_city le tableau indique le parcours que le propriétaire du manège va suivre pour le trajet.

Rapports sur le site Web :

Divers rapports (extraits de données) peuvent être affichés sur ce site Web. Permettez-moi d'en expliquer quelques-uns :

Trajets disponibles d'une ville spécifique à une autre - C'est l'un des rapports qui seront extraits assez fréquemment, car il décrit l'essentiel de ce site Web. La plupart des membres accéderont à ce site Web afin de rechercher des alternatives de voyage ou de covoiturage. Lors de l'extraction de ce rapport, les membres doivent entrer leurs noms de ville de départ et de destination. Le SQL suit :

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);

Liste des demandes de covoiturage soumises/approuvées – Ce rapport sera affiché au propriétaire du trajet. Il indiquera qui a soumis la demande de covoiturage et le propriétaire ne peut agir que sur les demandes de ce rapport. Le SQL pour cela suit :

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 = ;

Covoiturages précédents et actuels proposés – Ces rapports seront affichés pour les propriétaires de trajets sur leurs propres tableaux de bord. Le SQL suivant peut être utilisé pour générer une liste des courses que le propriétaire de la course propose actuellement :

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 = ;

Et ce SQL peut être utilisé pour extraire une liste de courses précédemment proposées :

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 = ;

Liste des co-voyageurs pour un trajet – Ce rapport sera disponible pour tous les co-voyageurs, y compris le propriétaire du trajet. Tous peuvent générer une liste de tous les co-voyageurs pour n'importe lequel de leurs trajets passés ou futurs.

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 = ;

Le modèle de données final

Qu'en est-il des améliorations ?

Peut-on encore améliorer ce modèle ? Oui nous pouvons! Il y a encore des domaines qui doivent être pris en charge.

Que se passe-t-il si l'on souhaite créer des demandes de trajet récurrentes ? Supposons qu'un conducteur voyage d'une ville à l'autre chaque week-end et qu'il soit toujours prêt à partager ce trajet. Une demande récurrente serait plus pratique.

Comment une personne peut-elle compter sur un inconnu qui propose un tour ? Il devrait y avoir un moyen d'aider les gens à évaluer les autres avant de demander une course. Un mécanisme viable consiste à publier et à partager des commentaires sur les propriétaires de manèges et les co-voyageurs. Ces détails aideront sûrement les autres à réserver un trajet avec des inconnus avec plus de confiance. Pour que cela se produise, quels changements doivent être apportés à notre modèle de données ?

N'hésitez pas à partager vos contributions sur ce modèle.