Introduciamo ulteriori modifiche al modello di dati, che ho creato nel mio precedente post sul blog, come avere un approccio automatizzato per assegnare un istruttore e un veicolo a una lezione, fatturare ai clienti e tenerne traccia.
Prima di tutto, ho bisogno di costruire una logica sul lato dell'applicazione per assegnare un istruttore e un veicolo alle lezioni prima che abbiano effettivamente luogo. La cosa principale da garantire qui è la disponibilità, ovvero un istruttore o un veicolo può essere assegnato a una lezione solo se entrambi sono disponibili nell'orario previsto per la lezione.
Devo costruire due tabelle separate per tenere traccia dell'occupazione rispettivamente degli istruttori e del veicolo. Ti starai chiedendo perché intendo tenere traccia dell'occupazione anziché della disponibilità. La risposta è che se si tiene traccia dell'occupazione anziché della disponibilità, non è necessario creare più tavoli per memorizzare l'indisponibilità di risorse a causa di congedi pianificati dagli istruttori o di qualche servizio di linea per i veicoli. In caso di indisponibilità programmata, i record vengono inseriti di conseguenza nelle tabelle di occupazione.
Presumo qui che gli istruttori e i veicoli siano disponibili solo durante l'orario lavorativo, diciamo dalle 8:00 alle 18:00, nei giorni lavorativi definiti dalla scuola. Pertanto posso dire che un istruttore è disponibile in un orario specifico in un giorno lavorativo se non trovo i dettagli sulla sua occupazione per l'ora e il giorno specificati in staff_occupancy tabella.
La struttura per la tabella staff_occupancy è il seguente:
Alcune variazioni possono essere inserite in base alle necessità. Ad esempio, dovrebbe esserci un intervallo di almeno 15 minuti tra due lezioni successive per un istruttore.
La struttura per la tabella vehicle_occupancy è il seguente:
L'assegnazione dell'istruttore e del veicolo è registrata nella reservation tavolo. Avevo già aggiunto due colonne, staff_id e vehicle_id , in questa tabella. Queste assegnazioni avverranno ovviamente in base alla loro disponibilità.
Inoltre, manterrò reservation_id nella staff_occupancy e vehicle_occupancy tabelle, in modo che in caso di annullamento di una lezione, la relativa occupazione del personale e del veicolo possa essere facilmente svincolata. Ma manterrò entrambe queste colonne come annullabili in quanto l'occupazione di istruttori e veicoli non sarà necessariamente dovuta a prenotazioni. E se un istruttore va in congedo? Oppure uno dei veicoli va al centro assistenza per un giorno?
Per consentire l'eliminazione graduale in tali scenari, aggiungerò una colonna chiamata is_active in entrambe queste tabelle.
Fatturazione
Per il requisito di fatturazione, creerò una tabella, ovvero invoice , per conservare i dettagli di fatturazione incluso customer_id e reservation_id . Qui la fatturazione è da fare ai clienti ma in base alle lezioni svolte per il cliente. Quindi abbiamo bisogno del reservation_id colonna anche nella tabella delle fatture, in modo che in qualsiasi momento si possa estrarre un report sulla fatturazione dettagliata in base a una prenotazione per un cliente. Creerò anche una colonna, ovvero invoice_status_id , nella tabella per memorizzare lo stato delle fatture.
Modello di database
Ecco la struttura del database aggiornata progettata in Vertabelo:
Conclusione
A questo punto devi aver iniziato a credere che la modellazione dei dati per un sistema di prenotazione di una scuola guida sia interessante e affascinante quanto imparare a guidare?
Sentiti libero di inviare le tue domande e suggerimenti sull'articolo. Sono più che felice di rispondere e di incorporare i tuoi suggerimenti nel mio prossimo articolo.
