Apportons d'autres modifications au modèle de données, que j'ai créé dans mon article de blog précédent, comme une approche automatisée pour affecter un instructeur et un véhicule à une leçon, facturer aux clients et les suivre.
Tout d'abord, je dois créer une logique du côté de l'application pour affecter un instructeur et un véhicule aux leçons avant qu'elles n'aient lieu. La principale chose à assurer ici est la disponibilité, c'est-à-dire qu'un moniteur ou un véhicule ne peut être affecté à une leçon que si les deux sont disponibles à l'heure prévue de la leçon.
Je dois construire deux tables distinctes pour suivre l'occupation des instructeurs et du véhicule respectivement. Vous vous demandez peut-être pourquoi j'ai l'intention de suivre l'occupation au lieu de la disponibilité. La réponse est que si nous suivons l'occupation au lieu de la disponibilité, nous n'avons pas besoin de créer plus de tables pour stocker l'indisponibilité des ressources en raison d'un congé planifié par les instructeurs ou d'un service programmé pour les véhicules. En cas d'indisponibilité planifiée, les enregistrements sont insérés dans les tableaux d'occupation en conséquence.
Je suppose ici que les instructeurs et les véhicules ne sont disponibles que pendant les heures ouvrables, disons de 8h00 à 18h00, les jours ouvrables définis par l'école. Par conséquent, je peux dire qu'un instructeur est disponible à une heure spécifiée un jour ouvrable si je ne trouve pas son détail d'occupation pour l'heure et le jour spécifiés dans le staff_occupancy tableau.
La structure de la table staff_occupancy est le suivant :
Certaines variantes peuvent être ajoutées selon les besoins. Par exemple, il devrait y avoir au moins 15 minutes d'intervalle entre deux leçons consécutives pour un instructeur.
La structure de la table vehicle_occupancy est le suivant :
L'attribution de l'instructeur et du véhicule est enregistrée dans le reservation table. J'avais déjà ajouté deux colonnes, staff_id et vehicle_id , dans ce tableau. Ces allocations se feront évidemment en fonction de leur disponibilité.
De plus, je conserverai reservation_id dans le staff_occupancy et vehicle_occupancy tables, de sorte qu'en cas d'annulation d'une leçon, l'occupation correspondante du personnel et du véhicule puisse être facilement libérée. Mais je garderai ces deux colonnes comme nullable car l'occupation des instructeurs et des véhicules ne sera pas nécessairement due aux réservations. Que se passe-t-il si un instructeur part en congé? Ou l'un des véhicules passe une journée au centre de service ?
Afin de permettre la suppression réversible dans de tels scénarios, j'ajouterai une colonne appelée is_active dans ces deux tableaux.
Facturation
Pour l'exigence de facturation, je vais créer une table, à savoir invoice , pour conserver les détails de facturation, y compris customer_id et reservation_id . Ici, la facturation est à faire aux clients mais sur la base des cours effectués pour le client. Nous avons donc besoin du reservation_id également dans la table des factures, de sorte qu'à tout moment, on peut extraire un rapport sur la facturation détaillée en fonction d'une réservation pour un client. Je vais également créer une colonne, à savoir invoice_status_id , dans le tableau pour stocker le statut des factures.
Modèle de base de données
Voici la structure de base de données mise à jour conçue dans Vertabelo :
Conclusion
Vous devez déjà commencer à croire que la modélisation des données pour un système de réservation d'une auto-école est aussi intéressante et charmante qu'apprendre à conduire ?
N'hésitez pas à poster vos questions et suggestions concernant l'article. Je me ferai un plaisir d'y répondre et d'intégrer vos suggestions dans mon prochain article.
