Modello di dati dell'officina di riparazione di automobili

Gestire un'officina di riparazione auto/auto è un'attività davvero complessa. Dovrai fissare appuntamenti mentre alcuni clienti arriveranno e non vorrai farli aspettare per ore. Inoltre, dovrai organizzare i dipendenti, tenere traccia delle riparazioni, dei materiali, addebitare i costi ai clienti, ecc. Avrai sicuramente bisogno di una soluzione IT e, naturalmente, di un modello di dati in background. Oggi parleremo di uno di questi modelli.

L'idea

Ho già detto che questo modello di business è davvero complesso. Pertanto, non cercherò di coprire tutto. Ho omesso intenzionalmente il tracciamento dei materiali e dei pezzi di ricambio e ho anche semplificato alcune parti del modello. Il motivo è piuttosto semplice. Se avessi incluso davvero tutto, il modello sarebbe semplicemente troppo grande per un articolo di dimensioni ragionevoli. Quindi, iniziamo.

Modello di dati

Il modello si compone di 5 aree tematiche:

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

Descriveremo ciascuna di queste 5 aree tematiche nell'ordine in cui sono state elencate.

Sezione 1:Officine e dipendenti

La prima area tematica da cui inizieremo è Repair shops & employees argomento. È abbastanza ovvio che dobbiamo sapere cosa abbiamo a disposizione prima di poter fare offerte ai clienti.

La city Il dizionario viene utilizzato per memorizzare tutte le città distinte in cui abbiamo officine di riparazione o da cui provengono i nostri clienti. Ogni città è definita in modo univoco dalla coppia postal_code – city_name . Potremmo decidere di avere un solo ingresso per ogni città, anche se quella città ha più codici postali. In tal caso, utilizzeremo solo il codice postale "principale" di quella città. Tuttavia, abbiamo la possibilità di avere più voci per la stessa città e codici postali diversi, nel caso lo desideriamo.

Il repair_shop table è il luogo in cui memorizzeremo un elenco di tutte le nostre officine. Possiamo aspettarci di operare più di uno ad un certo punto. Ogni negozio è definito in modo univoco dal suo shop_name e l'id della città a cui appartiene (city_id ). Conserveremo anche l'indirizzo del negozio e ulteriori details nel formato testuale se presente.

La position dizionario viene utilizzato per memorizzare position_names univoci che potrebbero essere assegnati ai nostri dipendenti. Sebbene la maggior parte delle posizioni sia correlata al nostro core business, ne avremo anche alcune che non fanno parte del core business (ruoli/posizioni tecniche) ma sono anche essenziali (amministrazione, vendite, ecc.).

Un elenco di tutti i nostri dipendenti è memorizzato nel employee tavolo. Per ogni dipendente, memorizzeremo il suo:

first_name &last_name – Il nome e il cognome del dipendente.
employment_start_date &employment_end_date – Data di inizio e fine del dipendente in azienda. La data di fine conterrà il valore NULL finché non sarà possibile definirlo.
position_id – Un riferimento alla posizione attuale in azienda.
city_id – Un riferimento alla città in cui attualmente vive il dipendente.
is_active – Un flag che indica se il dipendente è attualmente attivo o meno.

L'ultima tabella in questa area tematica è il schedule tavolo. In questa tabella, memorizzeremo gli orari esatti per tutti i nostri dipendenti a livello giornaliero. Avremo anche la possibilità di memorizzare più intervalli per lo stesso dipendente durante lo stesso giorno. Per raggiungere questo obiettivo, utilizzeremo i seguenti attributi:

repair_shop_id – Un riferimento alla relativa officina di riparazione.
employee_id – Un riferimento al relativo dipendente.
position_id – Un riferimento alla relativa posizione che il dipendente avrebbe durante il periodo di tempo definito. Nella maggior parte dei casi, questa sarebbe la sua posizione attuale, ma abbiamo la flessibilità di assegnare un'altra posizione qui.
schedule_date – Una data a cui è correlata questa voce.
time_from &time_to – Questa coppia definisce il periodo di tempo a cui è correlata questa voce.
plan – Un flag che indica se questo era un ingresso pianificato. L'ingresso non deve essere pianificato solo se lo abbiamo inserito ad hoc.
actual – Questo flag indica se questa voce è stata realizzata. Si noti che nella maggior parte dei casi, entrambi i flag, piano e effettivo, sarebbero impostati su True. Questo indicherebbe che abbiamo pianificato e realizzato quel piano.
insert_ts – Un timestamp che denota il momento in cui questo record è stato inserito nella tabella.

La combinazione repair_shop_id - employee_id - schedule_date - time_from costituisce la chiave UNICA/alternativa di questa tabella. Prima di inserire un nuovo record, dovremmo anche controllare quel nuovo intervallo time_from – time_to non si sovrappone a nessun intervallo esistente per lo stesso dipendente e data.

Sezione 2:Clienti e contatti

Ora siamo pronti per passare alla parte del modello relativa al cliente.

Conserveremo tutti i clienti con cui abbiamo lavorato prima o con cui abbiamo avuto contatti, nel customer tavolo. Per ogni cliente memorizzeremo:

first_name &last_name – Il nome e il cognome del cliente, nel caso in cui il nostro cliente sia un privato.
company_name – Il nome di un'azienda, in un caso a parte il cliente è un'azienda e non un privato.
address – L'indirizzo del cliente.
mobile – Il numero di cellulare del cliente.
email – L'e-mail del cliente
details – Tutti i dettagli aggiuntivi del cliente, se presenti, in formato testuale.
insert_ts – Un timestamp che denota il momento in cui questo record è stato inserito nella tabella.

La maggior parte degli attributi in questa tabella sono annullabili perché probabilmente non ne avremo alcuni e alcuni (first_name &last_name rispetto a company_name ) escludi gli altri.

Dovremo tenere traccia di tutti i contatti che abbiamo stabilito con ciascun cliente. Per fare ciò, utilizzeremo due tabelle. Il primo, il contact_type table, è un semplice dizionario contenente solo il type_name UNICO valore.

I dati di contatto reali sono memorizzati nel contact tavolo. Conserveremo i riferimenti al tipo di quel contatto (contact_type_id ), un cliente con cui abbiamo avuto contatti (customer_id ), un dipendente che ha stabilito quel contatto (schedule_id ), e memorizza anche i dettagli di contatto e l'ora in cui questo record è stato inserito nella tabella (insert_ts ).

Sezione 3:Veicoli

Dopo aver conosciuto le nostre risorse e i nostri clienti, dobbiamo immagazzinare i veicoli con cui lavoreremo. Oltre a tracciare i dati e creare rapporti interni, nella maggior parte dei paesi dovremo anche creare rapporti per agenzie di regolamentazione, compagnie assicurative e polizia.

Per prima cosa, definiremo i modelli dei nostri veicoli. Useremo 3 tabelle per raggiungere questo obiettivo. Nel make dizionario, elencheremo make_names univoci per tutti i produttori/le marche di auto/veicoli. Oltre a ciò, dovremo conoscere i tipi di veicoli, quindi utilizzeremo un altro dizionario con un solo attributo di valore univoco:type_name . Il 3 dizionario utilizzato è il model dizionario. Questo conterrà l'elenco di tutti i modelli che sono passati dalle nostre porte. Per ogni modello, definiremo la combinazione univoca model_name – make_id – vechicle_type_id .

Concluderemo la descrizione di questo argomento con il vehicle tavolo. Questa è l'unica tabella in questa area tematica contenente dati "reali". Utilizzeremo questa tabella per memorizzare i seguenti dettagli:

vin – Un numero di identificazione del veicolo, che definisce in modo univoco questo veicolo.
license_plate – Un numero di targa attuale.
customer_id – Un riferimento al cliente a cui appartiene questo veicolo. Nel caso in cui il veicolo cambi proprietario, lo inseriremo come nuovo record, ma sapremo che si tratta dello stesso veicolo in base al numero di serie.
model_id – Un riferimento al dizionario modello.
manufactured_year &manufactured_month – Indica l'anno e il mese di produzione di questo veicolo.
details – Tutti i dettagli aggiuntivi nel formato testuale.
insert_ts – Un timestamp che denota il momento in cui questo record è stato inserito nella tabella.

Sezione 4:Servizi e offerte

Siamo pronti per fare il prossimo grande passo. Dobbiamo definire cosa offriamo ai nostri (potenziali) clienti. Potrebbero essere singole attività o un insieme di attività – servizi.

L'elenco di tutti i servizi è memorizzato nel service_catalog dizionario. Ogni servizio è costituito da poche attività ed è definito in modo univoco dal suo service_name . Oltre al nome, memorizzeremo anche una descrizione, se ne abbiamo, la percentuale di service_discount e is_active bandiera. Lo sconto sul servizio sarà utilizzato per tutte le attività incluse in questo servizio.

Successivamente, definiremo le attività. Le attività fanno parte dei nostri servizi. Sono l'azione di base che potrebbe essere eseguita autonomamente. Ogni attività è definita da questi valori nel task_catalog tabella:

task_name &service_catalog_id – Un nome che useremo per descrivere questa attività e il servizio a cui appartiene. Questa coppia di attributi costituisce la chiave univoca della tabella.
description – L'eventuale descrizione testuale aggiuntiva utilizzata per descrivere questa attività.
ref_interval – Un flag che indica se misureremo l'intervallo per questa attività.
ref_interval_min &ref_interval_max – Il limite minimo e massimo dell'intervallo di riferimento.
describe – Un flag che indica se dobbiamo aggiungere un commento testuale per questa attività.
task_price – Un prezzo attuale, senza sconti sui servizi, per questa attività.
is_active – Un flag che indica se l'attività è attualmente attiva (nella nostra offerta) o meno.

Dopo il contatto con i clienti, faremo loro delle offerte. L'offerta potrebbe essere un servizio completo, con tutti i suoi compiti o un insieme di compiti. Tutte le offerte sono memorizzate nella offer tavolo. Per ogni offerta memorizzeremo:

customer_id – Un id del relativo cliente.
contact_id – Un id del relativo contatto, se presente. Questa potrebbe essere un'informazione importante per determinare quante offerte sono arrivate a seguito di contatti precedenti.
offer_description – Una descrizione testuale aggiuntiva di questa offerta.
service_catalog_id – Un id del servizio che abbiamo offerto al cliente. Questo ID potrebbe essere NULL nel caso in cui non gli abbiamo offerto un servizio completo, ma una o più attività che non fanno parte del servizio.
service_discount – Lo sconto del servizio al momento della creazione dell'offerta. Questo valore deve contenere NULL nel caso in cui l'offerta non fosse correlata al servizio.
offer_price – Un prezzo finale di quell'offerta. Potrebbe essere calcolato come la somma di tutte le attività meno lo sconto sul servizio.
insert_ts – Un timestamp che denota il momento in cui questo record è stato inserito nella tabella.

L'ultima tabella in questa area tematica è offer_task tavolo. Per ogni offerta, indipendentemente dal fatto che abbiamo offerto un servizio completo o meno, memorizzeremo l'insieme di tutte le attività. Dobbiamo memorizzare i seguenti dettagli:

offer_id – Un id della relativa offerta.
task_catalog_id – Un id del relativo compito. Insieme a offer_id , costituisce la chiave univoca/alternativa di questa tabella
task_price – Un prezzo corrente di quell'attività al momento dell'inserimento di questo record.
insert_ts - Un timestamp che denota il momento in cui questo record è stato inserito nella tabella.

Sezione 5:Visite

L'ultima area tematica del nostro modello viene utilizzata per memorizzare le visite effettive dei clienti alla nostra officina. Sebbene sembri complesso, abbiamo solo 2 nuove tabelle qui, visit e visit_task .

Quando il cliente accetta la nostra offerta o viene semplicemente nel nostro negozio, lo tratteremo come una visit . Per ciascuno di questi eventi, memorizzeremo i seguenti dettagli:

repair_shop_id – Un riferimento alla relativa officina di riparazione.
customer_id – Un riferimento al cliente a cui è correlata questa visita.
vehicle_id – Un riferimento al veicolo a cui è correlata questa visita.
visit_start_date – Una data di inizio della visita (pianificata).
visit_start_time – L'ora di inizio della visita (pianificata).
visit_end_date – Una data di inizio della visita (effettiva). Questo valore deve essere impostato al termine effettivo della visita.
visit_end_time – L'ora di inizio della visita (effettiva). Questo valore deve essere impostato al termine effettivo della visita.
license_plate – Un numero di targa al momento della visita. Nota che le targhe cambiano nel tempo.
offer_id – Un id della relativa offerta, se presente.
service_catalog_id – Un id del relativo servizio, se presente.
service_discount – Una percentuale di sconto al momento dell'aggiunta di questo record e nel caso in cui offriamo un servizio completo.
visit_price – Un prezzo totale che un cliente dovrebbe pagare per quella visita.
invoice_created – Un timestamp in cui è stata generata la fattura.
invoice_due – Un timestamp di scadenza della fattura.
invoice_charged – Un timestamp in cui è stata addebitata la fattura.
insert_ts – Un timestamp che denota il momento in cui questo record è stato inserito nella tabella.

L'ultima tabella nel nostro modello è visit_task tavolo. Questo è il posto dove archiviare tutte le attività che facevano effettivamente parte di quella visita. Per ogni record qui, memorizzeremo i seguenti valori:

visit_id – Un riferimento a quella visita.
task_catalog_id – Un riferimento all'attività correlata
value_measured – Un valore che è stato misurato durante questa attività, se l'attività richiedeva la misurazione.
task_description – Una descrizione correlata a quell'attività se l'attività richiedeva una descrizione.
pass – Un flag che indica se questa attività era nell'intervallo previsto o meno.
task_price – Un prezzo effettivo di tale attività al momento inserito in questa tabella.
insert_ts – Un timestamp che denota il momento in cui questo record è stato inserito nella tabella.

Sebbene questo modello sia piuttosto semplificato, contiene tutti gli elementi necessari di cui avrai bisogno per costruire un modello completo attorno ad esso. Le parti che richiedono miglioramenti sono sicuramente il materiale utilizzato e l'elaborazione dei pagamenti. Aggiungeresti qualcosa in più a questo modello?