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, il est beaucoup plus compliqué de gérer 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 entreprise de taxi.

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 aussi beaucoup plus accessibles :on peut 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 taxi ou en signaler un dans la rue.

Le modèle commercial des taxis n'est en aucun cas stagnant. 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 taxi. Examinons les parties pertinentes d'un modèle de données qu'une compagnie de taxi 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 des horaires de chauffeurs
Suivez la disponibilité des chauffeurs en temps réel
Fournir aux conducteurs une liste de trajets potentiels
Autoriser les conducteurs à sélectionner un trajet dans la liste
Calculer les heures de travail et les revenus des chauffeurs
Stocker diverses statistiques (par exemple, pourcentage de courses annulées, paiements par conducteur par mois, etc.)

Que devons-nous savoir sur les compagnies de taxi ?

Avant de concevoir un modèle de données pour une entreprise de taxis, nous devrions être en mesure de répondre aux questions suivantes :

Quand les chauffeurs fonctionnent-ils ?
Dans la plupart des compagnies de taxis, les chauffeurs ont des horaires prédéfinis. Nous connaîtrons les heures exactes auxquelles le conducteur commence et termine un 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 effectuer plusieurs quarts de travail le même jour ?
Si le chauffeur est membre d'une association de taxis, il peut être en mesure de travailler le matin, de rentrer chez lui, puis de retravailler le soir même. Cependant, 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.
3. Qui initie un trajet ?
Dans la plupart des cas, un client contactera le centre d'appels de taxi et le répartiteur saisira sa demande dans le système. Un autre scénario se produit lorsque le client commande directement un taxi (via 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 prend un taxi à la gare ou en hèle un dans la rue.

Le modèle de données

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

Section 1 :Taxis, chauffeurs et quarts de travail

Tout commence par les taxis et les chauffeurs :nous avons besoin de voitures dans une compagnie de taxis et nous avons besoin de chauffeurs. (À l'avenir, nous devrons probablement ajuster notre modèle pour les voitures autonomes. Mais restons dans le présent pour l'instant.)

Nous allons commencer notre exploration du modèle de données avec le driver table. Dans ce tableau, nous inclurons les attributs habituels comme le nom, le prénom et la date de naissance. Nous aurons également quelques attributs assez spécifiques à ce modèle :

driving_licence_number – Il s'agit d'un numéro d'identification ou d'un code alphanumérique que l'on trouve généralement sur une licence délivrée par le gouvernement. Étant donné que cet ID 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 avoir un type spécial de permis d'exploitation pour travailler ; nous supposerons qu'ils l'ont.)
expiry_date – Il s'agit de la date à laquelle un permis de conduire n'est plus valable légalement. Notez que nous ne stockerons pas l'historique des licences, nous allons donc simplement écraser driving_licence_number et expiry_date avec de nouvelles données si nécessaire. Si nous voulons stocker des historiques de licences, nous aurions besoin d'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 les conducteurs se connectent au système. Nous définirons cet attribut par défaut sur "Oui" (valeur 1) et le modifierons sur "Non" uniquement lorsque le conducteur n'est plus autorisé à se connecter au système.

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

Passons maintenant au cab et le car_model les tables. C'est ici que nous stockerons une liste des voitures que notre entreprise exploite. Nous stockerons également certains détails sur chaque véhicule. Les attributs les plus importants dans ces deux tables 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 taxi peuvent souhaiter stocker le nombre de passagers qu'une voiture peut transporter, l'espace du coffre (coffre) et d'autres informations.
license_plate - Le numéro sur une plaque d'immatriculation (plaque d'immatriculation du véhicule ou plaque d'immatriculation) définit de manière unique une voiture, à la fois pour une entreprise et à des fins gouvernementales. Bien sûr, nous devrons peut-être modifier les informations de la plaque d'immatriculation si une voiture est achetée ou vendue. Dans ce tableau, nous ne stockerons que les véhicules actuels de l'entreprise ; si nous devons conserver un historique, nous pouvons ajouter une table supplémentaire à notre modèle.
owner_id – Cet attribut est une référence au driver table. Il est facultatif car nous ne l'utiliserons que lorsque le conducteur possè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, examinons le tableau le plus important de cette section :le shift table. L'idée derrière cette table est de stocker les heures de travail réelles et les changements d'horaire pour les voitures et les chauffeurs. Chaque équipe aura au moins un taxi (cab_id ) et un pilote (driver_id ). Hormis la clé primaire, qui est un numéro d'identification d'équipe unique, ce sont les seuls attributs obligatoires dans ce tableau.

Le shift_start_time et shift_end_time les attributs sont les moments réels où un quart de travail commence et se termine. Souvent, ceux-ci sont prédéfinis. Dans le cas où il n'y a pas d'horaire, comme dans une association de taxis, ces heures seraient les mêmes que le login_time et logout_time attributs, respectivement. Le login_time et le logout_time sont les heures réelles auxquelles les chauffeurs se connectent (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 apparaîtra et le conducteur en choisira un. Bien sûr, le répartiteur sera également informé que le chauffeur travaille maintenant.

Section 2 :Courses

Cette section est composée de seulement deux tables, mais elles sont le véritable cœur de ce modèle.

Dans le cab_ride table, nous stockerons un enregistrement pour chaque course potentielle. Nous mettrons à jour cet enregistrement en fonction de ce qui se passe. Passons rapidement en revue les attributs :

shift_id – Il s'agit d'une référence au shift table; il 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 du trajet) et ensuite à nouveau disponibles (fin du trajet).
address_starting_point et address_destination – Ce sont les endroits où un trajet commence et se termine. Le conducteur recherchera probablement les deux emplacements pour obtenir la navigation sur sa tablette ou son GPS, c'est donc probablement à ce moment-là que nous mettrons à jour ces deux attributs.
GPS_starting_point et GPS_destination – Ce sont les coordonnées GPS des lieux 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.
canceled – Il s'agit d'une simple valeur Oui/Non qui nous indique si un trajet a été annulé. Nous aurons déjà un enregistrement pour ce trajet dans notre tableau, nous pouvons donc simplement marquer le trajet comme annulé.
payment_type_id et price – Ceux-ci fournissent des informations sur le montant payé pour une course et le mode de paiement utilisé par le client.

La plupart des attributs du cab_ride table peut contenir une valeur NULL. Il y a deux raisons à cela :

Les courses sont annulées, 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 lors de l'insertion initiale de l'enregistrement. Nous mettrons à jour chaque enregistrement plusieurs fois - à tout le moins, nous le mettrons à jour lorsque le trajet commencera et se terminera (ou sera annulé).

Le deuxième tableau de cette section est le cab_ride_status table. Ici, un enregistrement est ajouté pour chaque changement lié à un seul trajet. Lorsque le répartiteur entre un nouveau trajet dans le système, il ajoute un enregistrement au cab_ride table, mais un enregistrement associé sera également créé dans le cab_ride_status tableau (avec le statut correspondant). Après chaque changement lié à ce trajet, un enregistrement supplémentaire sera ajouté à ce tableau. Les attributs sont :

cab_ride_id et status_id – Il s'agit de clés étrangères liées à l'attribut id dans le ride table et l'attribut id dans le status tableau (que nous aborderons ci-dessous). Les deux sont obligatoires.
status_time – Cela stocke l'heure réelle à laquelle l'enregistrement a été inséré. Il 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 soit d'un répartiteur, soit d'un chauffeur. Le répartiteur insérera probablement le statut initial et le chauffeur insérera tous les statuts suivants.
status_details – Il s'agit d'un attribut de texte qui peut être utilisé pour stocker des informations supplémentaires. Par exemple, un répartiteur peut utiliser cet attribut pour enregistrer des instructions spéciales concernant un trajet.

Tableaux non classés

Enfin, passons rapidement en revue nos tableaux non classés.

Le cc_agent la table contient une liste d'agents de centre d'appels ou de répartiteurs qui peuvent ajouter de nouveaux enregistrements dans le cab_ride et cab_ride_status tableaux.

Dans le status dictionnaire, nous stockerons une liste de tous les statuts possibles que nous pourrions attribuer à un trajet. Certaines valeurs incluent "nouveau trajet" , "course attribuée au conducteur" , "course commencée" , "course terminée" , ou "course annulée" .

Payment_type est une autre table de dictionnaire. Son contenu est utilisé pour mettre à jour le payment_type_id attribut dans le cab_ride table. Les valeurs courantes sont "cash" et "carte de crédit" .

Comment amélioreriez-vous le modèle de données de taxi ?

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 itinéraires ne sont qu'un exemple auquel je peux penser.

À l'avenir, nous aurons probablement des taxis sans conducteur. Dans ce cas, nous supprimerions le pilote du modèle et remplacerions des éléments tels que les temps de recharge et de réparation.

N'hésitez pas à commenter et ajouter vos idées.