Modèle de données d'atelier de réparation automobile

Gérer un atelier de réparation automobile est une activité très complexe. Vous devrez prendre rendez-vous pendant que certains clients arriveront et vous ne voulez pas les faire attendre pendant des heures. De plus, vous devrez organiser les employés, suivre les réparations, les matériaux, facturer les clients, etc. Vous aurez certainement besoin d'une solution informatique et, bien sûr, d'un modèle de données en arrière-plan. Aujourd'hui, nous allons parler d'un de ces modèles.

L'idée

J'ai déjà mentionné que ce modèle d'affaires est vraiment complexe. Par conséquent, je n'essaierai pas de tout couvrir. J'ai intentionnellement omis les matériaux de suivi et les pièces de rechange et j'ai également simplifié certaines parties du modèle. La raison en est assez simple. Si j'avais vraiment tout inclus, le modèle serait tout simplement trop grand pour un article de taille raisonnable. Alors, commençons.

Modèle de données

Le modèle se compose de 5 domaines :

Repair shops & employees
Customers & contacts
Vehicles
Services & offers et
Visits

Nous décrirons chacun de ces 5 domaines dans l'ordre dans lequel ils ont été répertoriés.

Section 1 :Ateliers de réparation et employés

Le premier domaine par lequel nous allons commencer est le Repair shops & employees Domaine. Il est assez évident que nous devons savoir ce dont nous disposons avant de pouvoir faire des offres aux clients.

La city dictionnaire est utilisé pour stocker toutes les villes distinctes où nous avons des ateliers de réparation ou d'où viennent nos clients. Chaque ville est définie de manière unique par la paire postal_code – city_name . Nous pourrions décider de n'avoir qu'une seule entrée par ville, même si cette ville a plusieurs codes postaux. Dans ce cas, nous n'utiliserions que le code postal « principal » de cette ville. Néanmoins, nous avons la possibilité d'avoir plusieurs entrées pour la même ville et différents codes postaux - au cas où nous le voudrions.

Le repair_shop table est l'endroit où nous allons stocker une liste de tous nos ateliers de réparation. Nous pouvons nous attendre à en exploiter plusieurs à un moment donné. Chaque boutique est définie de manière unique par son shop_name et l'id de la ville à laquelle il appartient (city_id ). Nous enregistrerons également l'adresse du magasin et des details supplémentaires au format texte le cas échéant.

La position dictionnaire est utilisé pour stocker des position_names uniques qui pourraient être attribués à nos employés. Bien que la plupart des postes soient liés à notre cœur de métier, nous en aurons également certains qui ne font pas partie du cœur de métier (rôles/postes techniques) mais qui sont également essentiels (administration, ventes, etc.).

Une liste de tous nos employés est stockée dans le employee table. Pour chaque employé, nous stockerons son :

first_name &last_name – Le prénom et le nom de l'employé.
employment_start_date &employment_end_date – Date de début et de fin de l'employé dans l'entreprise. La date de fin doit contenir la valeur NULL jusqu'à ce que nous puissions la définir.
position_id – Une référence au poste actuel dans l'entreprise.
city_id – Une référence à la ville où vit actuellement l'employé.
is_active – Un indicateur indiquant si l'employé est actuellement actif ou non.

Le dernier tableau de ce domaine est le schedule table. Dans ce tableau, nous stockerons les horaires exacts de tous nos employés au niveau quotidien. Nous aurons également la possibilité de stocker plusieurs intervalles pour le même employé au cours de la même journée. Pour ce faire, nous utiliserons les attributs suivants :

repair_shop_id – Une référence à l'atelier de réparation concerné.
employee_id – Une référence à l'employé concerné.
position_id – Une référence au poste connexe que l'employé aurait occupé pendant la période définie. Dans la plupart des cas, il s'agirait de son poste actuel, mais nous avons la possibilité d'attribuer un autre poste ici.
schedule_date – Une date à laquelle cette entrée est liée.
time_from &time_to – Cette paire définit la période à laquelle cette entrée est liée.
plan – Un indicateur indiquant s'il s'agissait d'une entrée planifiée. L'entrée ne sera pas planifiée uniquement si nous l'insérons ad-hoc.
actual – Cet indicateur indique si cette entrée a été réalisée. Notez que dans la plupart des cas, les indicateurs, planifié et réel, seraient définis sur True. Cela indiquerait que nous avons planifié et effectivement réalisé ce plan.
insert_ts – Un horodatage indiquant le moment où cet enregistrement a été inséré dans la table.

La combinaison repair_shop_id - employee_id - schedule_date - time_from forme la clé UNIQUE/alternative de cette table. Avant d'insérer un nouvel enregistrement, nous devons également vérifier que le nouvel intervalle time_from – time_to ne chevauche aucun intervalle existant pour le même employé et la même date.

Section 2 :Clients et contacts

Nous sommes maintenant prêts à passer à la partie du modèle relative au client.

Nous enregistrerons tous les clients avec lesquels nous avons travaillé auparavant ou avec lesquels nous avons eu des contacts dans le customer table. Pour chaque client, nous stockerons :

first_name &last_name – Le prénom et le nom du client, dans le cas où notre client est un particulier.
company_name – Un nom d'entreprise, dans le cas contraire le client est une entreprise et non un particulier.
address – L'adresse du client.
mobile – Le numéro de téléphone mobile du client.
email – L'e-mail du client
details – Toutes les informations client supplémentaires, le cas échéant, au format texte.
insert_ts – Un horodatage indiquant le moment où cet enregistrement a été inséré dans la table.

La plupart des attributs de ce tableau sont nullables car nous n'en aurons probablement pas certains et certains (first_name &last_name vs company_name ) exclure les autres.

Nous devrons suivre tous les contacts que nous avons établis avec chaque client. Pour ce faire, nous utiliserons deux tableaux. Le premier, le contact_type table, est un simple dictionnaire contenant uniquement le type_name UNIQUE valeur.

Les données de contact réelles sont stockées dans le contact table. Nous stockerons les références au type de ce contact (contact_type_id ), un client avec lequel nous avons été en contact (customer_id ), un employé qui a établi ce contact (schedule_id ), et stocke également les coordonnées et l'heure à laquelle cet enregistrement a été inséré dans la table (insert_ts ).

Section 3 :Véhicules

Après avoir connu nos ressources et nos clients, nous devons stocker les véhicules avec lesquels nous allons travailler. Outre le suivi des données et la création de rapports internes, dans la plupart des pays, nous devrons également créer des rapports pour les organismes de réglementation, les compagnies d'assurance et la police.

Tout d'abord, nous définirons les modèles de nos véhicules. Nous utiliserons 3 tableaux pour y parvenir. Dans le make dictionnaire, nous listerons les make_names uniques pour tous les constructeurs/marques de voitures/véhicules. En plus de cela, nous aurons besoin de connaître les types de véhicules, nous utiliserons donc un autre dictionnaire avec un seul attribut de valeur unique - type_name . Le 3 dictionnaire utilisé est le model dictionnaire. Celui-ci contiendra la liste de tous les modèles qui ont franchi nos portes. Pour chaque modèle, nous définirons la combinaison unique model_name – make_id – vechicle_type_id .

Nous terminerons la description de ce domaine avec le vehicle table. Il s'agit du seul tableau de ce domaine contenant des données « réelles ». Nous utiliserons ce tableau pour stocker les détails suivants :

vin – Un numéro d'identification du véhicule, définissant de manière unique ce véhicule.
license_plate – Un numéro de plaque d'immatriculation actuel.
customer_id – Une référence au client auquel appartient ce véhicule. Si le véhicule change de propriétaire, nous l'insérerons en tant que nouvel enregistrement, mais nous saurons qu'il s'agit du même véhicule d'après le numéro de série.
model_id – Une référence au dictionnaire du modèle.
manufactured_year &manufactured_month – Indiquez l'année et le mois de production de ce véhicule.
details – Tous les détails supplémentaires au format textuel.
insert_ts – Un horodatage indiquant le moment où cet enregistrement a été inséré dans la table.

Section 4 :Services et offres

Nous sommes prêts à franchir la prochaine grande étape. Nous devons définir ce que nous offrons à nos clients (potentiels). Il peut s'agir de tâches uniques ou d'un ensemble de tâches – des services.

La liste de tous les services est stockée dans le service_catalog dictionnaire. Chaque service se compose de quelques tâches et est défini de manière unique par son service_name . Outre le nom, nous stockerons également une description, si nous en avons, le pourcentage de service_discount et le is_active drapeau. La remise de service doit être utilisée pour toutes les tâches incluses dans ce service.

Ensuite, nous définirons les tâches. Les tâches font partie de nos services. Il s'agit de l'action de base qui pourrait être effectuée de manière autonome. Chaque tâche est définie par ces valeurs dans le task_catalog tableau :

task_name &service_catalog_id – Un nom que nous utiliserons pour décrire cette tâche et le service auquel elle appartient. Cette paire d'attributs forme la clé unique de la table.
description – La description textuelle supplémentaire, le cas échéant, utilisée pour décrire cette tâche.
ref_interval – Un indicateur indiquant si nous allons mesurer l'intervalle pour cette tâche.
ref_interval_min &ref_interval_max – La limite minimale et maximale de la plage de référence.
describe – Un indicateur indiquant si nous devons ajouter un commentaire textuel pour cette tâche.
task_price – Un prix actuel, sans remises sur les services, pour cette tâche.
is_active – Un indicateur indiquant si la tâche est actuellement active (dans notre offre) ou non.

Après le contact avec les clients, nous leur ferons des offres. L'offre peut être un service complet, avec toutes ses tâches ou un ensemble de tâches. Toutes les offres sont stockées dans le offer table. Pour chaque offre, nous stockons :

customer_id – Un identifiant du client associé.
contact_id – Un identifiant du contact associé, s'il y en avait un. Il peut s'agir d'informations importantes pour déterminer le nombre d'offres résultant de contacts précédents.
offer_description – Une description textuelle supplémentaire de cette offre.
service_catalog_id – Un identifiant du service que nous avons proposé au client. Cet identifiant peut être NULL dans le cas où nous ne lui avons pas proposé un service complet, mais une ou plusieurs tâches qui ne font pas partie du service.
service_discount – L'offre de remise sur le service en ce moment a été créée. Cette valeur doit contenir NULL si l'offre n'est pas liée au service.
offer_price – Un prix final de cette offre. Il peut être calculé comme la somme de toutes les tâches moins la remise sur le service.
insert_ts – Un horodatage indiquant le moment où cet enregistrement a été inséré dans la table.

Le dernier tableau de ce domaine est le offer_task table. Pour chaque offre, peu importe si nous avons offert un service complet ou non, nous stockerons l'ensemble de toutes les tâches. Nous devons stocker les détails suivants :

offer_id – Un identifiant de l'offre associée.
task_catalog_id – Un identifiant de la tâche associée. Avec le offer_id , il constitue la clé unique/alternative de cette table
task_price – Un prix actuel de cette tâche au moment où cet enregistrement a été inséré.
insert_ts - Un horodatage indiquant le moment où cet enregistrement a été inséré dans la table.

Section 5 :Visites

Le dernier domaine de notre modèle est utilisé pour stocker les visites réelles des clients dans notre atelier de réparation. Bien que cela semble complexe, nous n'avons que 2 nouveaux tableaux ici, visit et visit_task .

Lorsque le client accepte notre offre ou vient simplement dans notre boutique, nous traiterons cela comme une visit . Pour chacun de ces événements, nous stockerons les détails suivants :

repair_shop_id – Une référence à l'atelier de réparation concerné.
customer_id – Une référence au client auquel cette visite est liée.
vehicle_id – Une référence au véhicule auquel cette visite est liée.
visit_start_date – Une date de début de visite (prévue).
visit_start_time – Une heure de début de visite (prévue).
visit_end_date – Une date de début de visite (réelle). Cette valeur doit être définie à la fin effective de la visite.
visit_end_time – Une heure de début de visite (réelle). Cette valeur doit être définie à la fin effective de la visite.
license_plate - Un numéro de plaque d'immatriculation au moment de la visite. Remarquez que les plaques d'immatriculation changent avec le temps.
offer_id – Un identifiant de l'offre associée, le cas échéant.
service_catalog_id – Un identifiant du service associé, le cas échéant.
service_discount – Un pourcentage de réduction au moment où cet enregistrement a été ajouté et dans le cas où nous offrons un service complet.
visit_price – Un prix total qu'un client devrait payer pour cette visite.
invoice_created – Un horodatage lorsque la facture a été générée.
invoice_due – Un horodatage de la date d'échéance de la facture.
invoice_charged – Un horodatage lorsque la facture a été débitée.
insert_ts – Un horodatage indiquant le moment où cet enregistrement a été inséré dans la table.

La dernière table de notre modèle est le visit_task table. C'est l'endroit où stocker toutes les tâches qui faisaient réellement partie de cette visite. Pour chaque enregistrement ici, nous stockerons les valeurs suivantes :

visit_id – Une référence à cette visite.
task_catalog_id – Une référence à la tâche associée
value_measured – Une valeur qui a été mesurée au cours de cette tâche, si la tâche nécessitait une mesure.
task_description – Une description liée à cette tâche si la tâche nécessitait une description.
pass – Un indicateur indiquant si cette tâche était dans l'intervalle prévu ou non.
task_price – Un prix réel de cette tâche au moment inséré dans ce tableau.
insert_ts – Un horodatage indiquant le moment où cet enregistrement a été inséré dans la table.

Bien que ce modèle soit assez simplifié, il contient tous les éléments nécessaires dont vous aurez besoin pour construire un modèle complet autour de lui. Les pièces qui nécessitent des améliorations sont certainement le matériel utilisé et le traitement des paiements. Souhaitez-vous ajouter quelque chose de plus à ce modèle ?