taxii

Qu’est qu’un modèle de base de données pour un service de taxi ?

Appelez-les taxis ou taxis, ces manèges pratiques à louer existent depuis des siècles. De nos jours, c’est beaucoup plus compliqué d’exploiter un service de taxi. Dans cet article, nous examinerons un modèle de base de données conçu pour répondre aux besoins d’une compagnie de taxis.

L’histoire de “l’appel d’un taxi” a commencé au 17ème siècle à Londres. Dans la plupart des endroits, les taxis sont plus abordables que jamais. Ils deviennent également beaucoup plus accessibles : nous pouvons commander un taxi par téléphone, via des applications mobiles ou sur le Web. Ou nous pouvons utiliser les mêmes techniques qui fonctionnent depuis des centaines d’années – faire la queue à une station de taxis ou en signaler une dans la rue.

Le modèle commercial du taxi ne stagne pas du tout. De nouveaux concepts comme Uber et Lyft gagnent en popularité et auront certainement un impact sur l’avenir des services de taxi. Bien sûr, tout cela complique la vie de ceux qui dirigent les compagnies de taxis. Jetons un coup d’oeil aux parties pertinentes d’un modèle de données qu’une compagnie de taxis pourrait utiliser pour rester organisée.

Que voulons-nous réaliser avec ce modèle de base de données de cabine ?
Le modèle présenté dans cet article pourra :
Créer les horaires des chauffeurs
Suivre la disponibilité des chauffeurs en temps réel
Fournir aux conducteurs une liste de promenades possibles
Permettre aux conducteurs de sélectionner un trajet dans la liste
Calculer les heures de travail et les gains des conducteurs
Stockez diverses statistiques (par exemple, le pourcentage de trajets annulés, les paiements par conducteur par mois, etc.)

Que devons-nous savoir sur les compagnies de taxis ?
Avant de concevoir un modèle de données pour une compagnie de taxis, nous devrions être en mesure de répondre aux questions suivantes :

Quand les conducteurs travaillent-ils ?
Dans la plupart des compagnies de taxis, les chauffeurs ont des horaires prédéfinis. Nous connaîtrons l’heure exacte à laquelle le chauffeur commence et finit son quart de travail. Dans certains cas, les heures de début et de fin de quart ne sont pas définies à l’avance. Par exemple, les membres d’une association de taxis peuvent se connecter et commencer à travailler quand ils le souhaitent. Ils peuvent également se déconnecter et terminer leur quart de travail quand ils le souhaitent. Notre modèle devrait pouvoir prendre en charge les deux options.

Un conducteur peut-il travailler plusieurs quarts de travail le même jour ?
Si le conducteur est membre d’une association de taxis, il peut être en mesure de travailler le matin, de rentrer chez lui et de travailler à nouveau le soir même. Toutefois, dans certaines régions (comme New York), il existe des restrictions légales sur la durée des quarts de travail et/ou le nombre d’heures que les chauffeurs de taxi peuvent travailler chaque jour.

Qui est à l’origine d’un voyage ?
Dans la plupart des cas, le client communiquera avec le centre d’appels du taxi et le répartiteur entrera sa demande dans le système. Un autre scénario se produit lorsque le client commande un taxi directement (au moyen d’une application mobile, par exemple) et qu’aucun employé du centre d’appels n’est impliqué dans le processus. Une troisième option – qui contourne également le centre d’appels – se produit lorsqu’un client obtient un taxi à la station ou en appelle un dans la rue.

Le modèle de données

Actualites Taxi Modele base donnees taxi 1

Notre modèle comporte deux sections principales et trois tableaux non catégorisés. Nous allons examiner chacun d’eux de plus près.

Section 1 : Cabines, conducteurs et équipes de travail

Actualites Taxi Modele base donnees taxi 2

Tout commence avec les taxis et les chauffeurs : nous avons besoin de voitures dans une compagnie de taxi et nous avons besoin de chauffeurs. (À l’avenir, nous devrons probablement ajuster notre modèle pour les voitures auto-propulsées. Mais restons dans le présent pour l’instant.)

Nous commencerons notre exploration du modèle de données par le tableau des pilotes. Dans ce tableau, nous inclurons les attributs habituels comme le nom, le prénom et la date de naissance. Nous aurons aussi quelques attributs qui sont assez spécifiques à ce modèle :

driving_licence_number – Il s’agit d’un numéro d’identification ou d’un code alphanumérique qui se trouve habituellement sur un permis délivré par un gouvernement. Comme cet identifiant est unique dans le monde réel, il sera également unique dans notre base de données. (Dans certaines régions, les chauffeurs de taxi doivent posséder un permis d’exploitation spécial pour travailler ; nous supposerons qu’ils l’ont.)

expiry_date – C’est la date à laquelle le permis de conduire n’est plus valide légalement. Notez que nous ne stockerons pas l’historique des permis, donc nous écraserons simplement le numéro de permis de conduire et la date d’expiration avec de nouvelles données si nécessaire. Si nous voulons stocker l’historique des licences, nous devons ajouter une autre table à notre modèle.

working – Il s’agit d’une valeur booléenne qui s’active et se désactive simplement lorsque le conducteur se connecte au système. Par défaut, nous définirons cet attribut sur “Oui” (valeur 1) et le changerons sur “Non” uniquement lorsque le pilote n’est plus autorisé à se connecter au système.

Il y a beaucoup d’autres détails relatifs aux conducteurs que nous pourrions stocker dans la base de données : les noms d’utilisateur et les mots de passe, la date à laquelle chaque conducteur a commencé à travailler et le type d’emploi actuel de chaque conducteur. Nous n’entrerons pas dans ces détails maintenant parce qu’ils ne sont pas spécifiquement liés à ce modèle. Je les classerais sous l’administration des utilisateurs, qui est la même dans la plupart des systèmes.

Passons maintenant au taxi et aux tables car_model. C’est là que nous allons stocker une liste des voitures que notre société exploite. Nous conserverons également certains détails sur chaque véhicule. Les attributs les plus importants dans ces deux tableaux sont :

model_description – Il s’agit d’un attribut de texte qui conserve une description spécifiée par l’entreprise d’un certain type de voiture. Par exemple, les compagnies de taxis peuvent vouloir stocker le nombre de passagers qu’une voiture peut transporter, l’espace du coffre (coffre), et d’autres faits.

plaque_d’immatriculation – Le numéro d’une plaque d’immatriculation (plaque d’immatriculation du véhicule ou plaque d’immatriculation) définit de façon unique une voiture, à la fois pour une entreprise et à des fins gouvernementales. Bien sûr, il se peut que nous ayons besoin de changer les informations de plaque d’immatriculation si une voiture est achetée ou vendue. Dans ce tableau, nous ne stockons que les véhicules actuels de l’entreprise ; si nous avons besoin de garder un historique, nous pouvons ajouter un autre tableau à notre modèle.

owner_id – Cet attribut fait référence à la table des pilotes. C’est optionnel parce que nous ne l’utiliserons que lorsque le chauffeur sera propriétaire de sa cabine. (C’est généralement le cas dans les associations de taxis).
active – Il s’agit d’une valeur booléenne qui indique si l’entreprise utilise toujours une voiture.

Enfin, jetons un coup d’œil au tableau le plus important de cette section : le tableau des quarts de travail. L’idée derrière ce tableau est de stocker les heures de travail réelles et les horaires de travail des voitures et des conducteurs. Chaque équipe aura au moins une cabine (cab_id) et un conducteur (driver_id). Mis à part la clé primaire, qui est un numéro d’identification d’équipe unique, ce sont les seuls attributs obligatoires dans cette table.

Les attributs shift_start_time et shift_end_time sont les moments réels où une équipe commence et finit. Souvent, ils sont préréglés. S’il n’y a pas d’horaire, comme dans une association de taxis, ces heures seraient les mêmes que les attributs login_time et logout_time, respectivement. Le login_time et le logout_time sont les heures effectives de connexion des chauffeurs (via un appareil mobile dans leur voiture ou toute autre méthode utilisée par la compagnie de taxi). Lorsque le conducteur se connecte au système, une liste des trajets disponibles s’affiche et le conducteur en choisit un. Bien entendu, le répartiteur sera également avisé que le chauffeur travaille actuellement.

Section 2 : Manèges

Actualites Taxi Modele base donnees taxi 3

Cette section n’est composée que de deux tableaux, mais ils sont le véritable cœur de ce modèle.

Dans la table cab_ride, nous allons stocker un enregistrement pour chaque trajet potentiel. Nous mettrons à jour ce dossier en fonction de ce qui se passera. Aperçu rapide des attributs :

shift_id – Il s’agit d’une référence à la table des quarts de travail ; elle nous fournit les détails du conducteur et de la cabine pour un trajet donné.

ride_start_time et ride_end_time – Ceux-ci sont mis à jour lorsque les conducteurs signalent qu’ils sont actuellement occupés (début de course) et disponibles à nouveau (fin de course).

address_starting_point et address_destination – Ce sont les endroits où un trajet commence et se termine. Le pilote recherchera probablement les deux emplacements pour obtenir la navigation sur sa tablette ou son GPS, c’est donc probablement le moment où nous mettrons à jour ces deux attributs.

GPS_starting_point et GPS_destination – Ce sont les coordonnées GPS des points de départ et d’arrivée décrits ci-dessus. Ces valeurs sont facultatives car nous ne les mettrons à jour que lorsque nous aurons des données.

annulé – Il s’agit d’une simple valeur Oui/Non qui nous indique si un trajet a été annulé. Nous aurons déjà un record pour ce manège dans notre tableau, alors nous pouvons simplement marquer le manège comme annulé.

payment_type_id et prix – Ils fournissent des informations sur le montant payé pour un trajet et le mode de paiement utilisé par le client.

La plupart des attributs de la table cab_ride peuvent contenir une valeur NULL. Il y a deux raisons à cela :

Les manèges sont annulés, ce qui signifie qu’aucune donnée ne sera saisie dans ces champs ;
Même si nous aurons finalement toutes les données, nous ne les aurons pas toutes au moment de l’insertion initiale de l’enregistrement. Nous mettrons à jour chaque enregistrement plusieurs fois – à tout le moins, nous le mettrons à jour au début et à la fin du parcours (ou lorsque celui-ci sera annulé).

La deuxième table de cette section est la table cab_ride_status. Ici, un enregistrement est ajouté pour chaque changement relatif à un seul trajet. Lorsque le répartiteur saisit un nouveau trajet dans le système, il ajoute un enregistrement à la table cab_ride, mais un enregistrement lié est également créé dans la table cab_ride_status (avec l’état correspondant). Après chaque changement lié à ce parcours, un nouvel enregistrement sera ajouté à ce tableau. Les attributs sont :

cab_ride_id et status_id- Ce sont des clés étrangères qui sont liées à l’attribut id de la table ride et à l’attribut id de la table status (que nous aborderons ci-dessous). Les deux sont obligatoires.

status_time – Enregistre l’heure réelle à laquelle l’enregistrement a été inséré. C’est également obligatoire.

cc_agent_id et shift_id – Ce sont des références à l’employé qui a inséré une mise à jour de statut. Il peut s’agir d’un répartiteur ou d’un chauffeur. Il est probable que le répartiteur insère l’état initial et que le chauffeur insère tous les états suivants.

status_details – Il s’agit d’un attribut texte qui peut être utilisé pour stocker des informations supplémentaires. Par exemple, un répartiteur pourrait utiliser cet attribut pour enregistrer des instructions spéciales sur un trajet.

Tables non classées

Enfin, passons rapidement en revue nos tables non classées.

Actualites Taxi Modele base donnees taxi 4

La table cc_agent contient une liste d’agents de centre d’appels ou de répartiteurs qui peuvent ajouter de nouveaux enregistrements dans les tables cab_ride et cab_ride_status.

Actualites Taxi Modele base donnees taxi 5

Dans le dictionnaire d’état, nous allons stocker une liste de tous les états possibles que nous pourrions assigner à un tour. Certaines valeurs comprennent “nouveau parcours”, “parcours assigné au conducteur”, “parcours commencé”, “parcours terminé” ou “parcours annulé”.
table payment_type

Actualites Taxi Modele base donnees taxi 6

Payment_type est une autre table de dictionnaire. Son contenu est utilisé pour mettre à jour l’attribut payment_type_id dans la table cab_ride. Les valeurs communes sont “cash” et “carte de crédit”.

Comment amélioreriez-vous le modèle de données sur les taxis ?
Le modèle de base de données cab/taxi présenté dans cet article se concentre uniquement sur les fonctionnalités les plus importantes. Il y a de nombreuses améliorations que nous pourrions apporter. Les routes ne sont qu’un exemple parmi tant d’autres.

À l’avenir, nous aurons probablement des taxis sans chauffeur. Dans ce cas, nous laissons tomber le conducteur du modèle et remplaçons les temps de recharge et de réparation par d’autres choses.