J'ai besoin de concevoir un modèle de données pour un système de réservation pour une auto-école. Le domaine semble assez simple, mais les complexités sont toujours impliquées. Vous devez suivre toutes les demandes des clients et garder une trace des ressources (véhicule, temps et instructeur) consommées pendant les cours.
Présentation
J'aime utiliser une approche axée sur le domaine pour concevoir un modèle de données. Cela me fait mettre de côté l'obsession technologique et me concentrer principalement sur la modélisation du domaine autour de ses entités associées et des relations entre elles.
Les exigences en bref
Permettez-moi d'abord de formuler d'abord l'exigence en langage clair.
J'ai besoin d'un modèle de données pour une auto-école afin d'autoriser les clients faire des réservations pour leçons en ligne. L'école de conduite peut avoir plus d'un instructeur et plus d'un véhicule . Le moniteur est affecté au cours sur réservation. Le système doit permettre aux clients d'annuler la ou les réservations à tout moment avant le jour prévu. Le véhicule affecté à la leçon doit également être enregistré si la leçon a lieu.
Entités et relations impliquées
Quand je pense au sujet, les entités qui me viennent en premier à l'esprit sont, "Client" , "Instructeur" , "Leçon de conduite" , "Demande de réservation" et "Véhicule" . Permettez-moi de commencer par ma toute première table pour ce modèle, et c'est customer . Il s'agit de stocker des données de base pour les clients. J'aurais probablement besoin d'une autre table pour stocker les détails de l'instructeur, mais au lieu de créer une table avec le nom de l'instructeur, je vais créer une table générique appelée staff pour les détails du personnel et conservez « Instructeur » comme titre de poste. Cela rendra mon modèle de données extensible pour répondre également à d'autres domaines de service, comme le travail administratif et juridique, d'une auto-école.
Je considère "cours de conduite" comme l'un des services, je crée donc une autre table appelée service . Un service, "cours de conduite" dans ce cas, peut avoir plusieurs leçons. Pour gérer cette exigence, j'ai certainement besoin d'une autre table principale, à savoir lesson , et une table de relations, à savoir service_lesson , pour gérer la relation plusieurs à plusieurs entre ces deux entités maîtres, c'est-à-dire qu'un service peut certainement avoir plusieurs leçons, mais d'un autre côté, une leçon peut également faire partie de plus d'un service.
Lorsque l'on soumet une demande de réservation, on lui demande de remplir ses coordonnées et ses préférences préliminaires comme le type de service qu'il souhaite, le choix du véhicule et la date de début. Les détails du client sont stockés dans la table des clients. Par la suite, une requête est créée dans le request table, et toutes les préférences sont stockées par rapport à la demande dans la même table. Il y a certains statuts associés à chaque demande, comme « soumettre », « en cours », « annuler » et « terminer ». Je vais créer une table de support pour cela appelée request_status .
Au moment de la soumission de la demande, on met une préférence pour le véhicule, c'est-à-dire le type de véhicule. Cependant, le véhicule serait en fait affecté à une leçon lorsqu'elle a lieu. Je garde donc vehicle_type_id comme l'une des colonnes de request tableau pour l'instant.
Lorsqu'une demande est traitée, des réservations sont faites pour chaque cours de la demande de service. De plus, les instructeurs et les véhicules sont affectés à chaque leçon en fonction de la disponibilité des instructeurs et des préférences des clients en matière de véhicules. Les cours sont programmés pour des dates futures avec le statut "Ouvert". Tous ces détails sont capturés dans une autre table de transaction appelée reservation . J'ai mis en surbrillance toutes les tables de transaction avec une couleur différente de toutes les tables principales.
Une table principale, reservation_status , est créé pour stocker toutes les valeurs possibles pour les statuts de réservation comme "ouvert", "en cours", "annuler" et "complet".
Ce modèle permet à un client d'annuler une leçon individuelle ainsi que la demande de service dans son ensemble. Si le client annule la demande de service, toutes les leçons restantes, qui sont programmées pour le client, sont annulées dans le tableau de réservation.
Veuillez vous référer au modèle de données que j'ai créé à l'aide de Vertabelo pour les détails au niveau des colonnes de toutes ces tables. Quelques points concernant la création de colonnes :
- Une colonne d'indicateur nommée
is_activeest ajouté à toutes les tables maîtres pour permettre la suppression réversible des enregistrements. Ainsi, par exemple, si un instructeur quitte l'école, nous basculerons le drapeau sur "N" pour rendre son enregistrement inactif. - Certaines colonnes telles que
created_date,created_by,last_modified_dateetlast_modified_bysont ajoutés dans toutes les tables de transactions pour activer une piste d'audit pour les modifications apportées aux enregistrements. Les tables de transactions sont surlignées en bleu dans le modèle de données créé dans Vertabelo. - Vous vous demandez peut-être ce que le
address_idcolonne dans lestaffle tableau est fait pour. J'ai volontairement mis cette colonne dans lestafftable afin que je puisse étendre mon modèle de données pour prendre en charge un processus automatisé pour affecter un instructeur à une demande en fonction de son emplacement. Par exemple, supposons qu'à New York, une demande de White Plains arrive. Mon système doit d'abord rechercher un instructeur disponible dans le même voisinage ou dans le voisinage le plus proche. Mon système ne devrait jamais affecter un instructeur séjournant à Manhattan, qui se trouve à près de 80 kilomètres du domicile du demandeur.
Caractéristiques principales de ce modèle
- Ce modèle permet aux clients d'effectuer des demandes de réservation en fonction de leurs préférences en matière de date de début et de véhicule.
- Cela leur permet d'annuler une ou plusieurs leçons de leur cours, ou la totalité du cours lui-même.
- Ce modèle capture les détails de l'instructeur et du véhicule pour chaque leçon.
- Ce modèle est extensible pour gérer tous les services possibles fournis par une auto-école.
- Cela nous permet de concevoir des cours de formation et de planifier les leçons efficacement.
Modèle de base de données
Voici la conception de la base de données pour notre système de réservation. Le modèle a été créé dans Vertabelo pour la base de données Oracle, mais la même conception peut être implémentée pour d'autres moteurs de base de données sans modifications significatives.
Conclusion
Il y a certains sujets que nous n'avons pas abordés dans cet article, tels que :
- Pouvons-nous mettre en place une approche automatisée pour allouer des véhicules et des instructeurs aux cours ?
- Qu'en est-il de la facturation des clients ? Que se passe-t-il si un client ne veut pas payer pour l'intégralité du cours mais pour quelques leçons ? Pouvons-nous mettre ces leçons à sa disposition ?
Notre modèle existant prend-il en charge ces fonctionnalités ? La réponse est non. Je couvrirai probablement ces sujets dans mon prochain article.
