Modello di database per il sistema di prenotazione di una scuola guida. Parte 1

Ho bisogno di progettare un modello di dati per un sistema di prenotazione per una scuola guida. L'area tematica sembra abbastanza semplice, ma le complessità sono ancora coinvolte. Devi tenere traccia di tutte le richieste dei clienti e tenere traccia delle risorse (veicolo, tempo e istruttore) consumate durante le lezioni.

Introduzione

Mi piace utilizzare un approccio basato sul dominio per la progettazione di un modello di dati. Mi fa mettere da parte l'ossessione della tecnologia e concentrarmi principalmente sulla modellazione dell'area tematica che ruota attorno alle sue entità associate e alle relazioni tra di loro.

Requisiti in breve

Vorrei prima scrivere il requisito in un inglese semplice.

Ho bisogno di un modello di dati per una scuola guida per consentire ai clienti per effettuare prenotazioni per lezioni in linea. La scuola guida può avere più di un istruttore e più di un veicolo . L'istruttore è assegnato alla lezione su prenotazione. Il sistema dovrebbe consentire ai clienti di annullare la prenotazione in qualsiasi momento prima del giorno programmato. Se la lezione si svolge, deve essere registrato anche il veicolo assegnato alla lezione.

Entità e relazioni coinvolte

Quando penso all'argomento, le entità che mi vengono in mente per prime sono "Cliente" , "Istruttore" , "Lezione di guida" , "Richiesta di prenotazione" e "Veicolo" . Vorrei iniziare con il mio primo tavolo per questo modello, e cioè customer . Serve per memorizzare i dati anagrafici per i clienti. Probabilmente avrei bisogno di un'altra tabella per memorizzare i dettagli dell'istruttore, ma invece di creare una tabella con il nome dell'istruttore, creerò una tabella generica chiamata staff per i dettagli del personale e mantieni "Istruttore" come titolo di lavoro. Renderà il mio modello di dati estensibile per soddisfare anche altre aree di servizio, come il lavoro amministrativo e legale, di una scuola guida.

Considero "corso di guida" come uno dei servizi, quindi creo un'altra tabella chiamata service . Un servizio, “corso di guida” in questo caso, può avere più lezioni. Per gestire questo requisito, ho sicuramente bisogno di un'altra tabella principale, vale a dire, lesson e una tabella di relazione, ovvero service_lesson , per gestire molti a molti rapporti tra entrambe queste entità master, ovvero un servizio può sicuramente avere più lezioni, ma d'altra parte, una lezione può anche far parte di più di un servizio.

Quando si invia una richiesta di prenotazione, gli viene chiesto di inserire i propri dettagli e le preferenze preliminari come il tipo di servizio desiderato, la scelta del veicolo e la data di inizio. I dettagli del cliente sono memorizzati nella tabella cliente. Successivamente, viene creata una richiesta nella request tabella e tutte le preferenze vengono archiviate rispetto alla richiesta nella stessa tabella. Ci sono determinati stati associati a ciascuna richiesta, come "invia", "in corso", "annulla" e "completato". Creerò una tabella di supporto chiamata request_status .

Al momento della presentazione della richiesta si pone la preferenza per veicolo, ovvero tipo di veicolo. Tuttavia, il veicolo verrebbe effettivamente assegnato a una lezione quando si svolge. Pertanto conservo vehicle_type_id come una delle colonne in request tabella per ora.

Quando una richiesta viene elaborata, le prenotazioni vengono effettuate per ogni lezione della richiesta di servizio. Inoltre, a ciascuna lezione vengono assegnati istruttori e veicoli in base alla disponibilità degli istruttori e alle preferenze dei clienti per i veicoli. Le lezioni sono programmate per date future con stato “Aperto”. Tutti questi dettagli vengono acquisiti in un'altra tabella delle transazioni denominata reservation . Ho evidenziato tutte le tabelle delle transazioni con un colore diverso rispetto a tutte le tabelle principali.

Una tabella principale, reservation_status , viene creato per memorizzare tutti i valori possibili per gli stati di prenotazione come "aperto", "in corso", "annulla" e "completato".

Questo modello consente al cliente di annullare una singola lezione e la richiesta di servizio nel suo insieme. Se il cliente annulla la richiesta di servizio, tutte le lezioni rimanenti, che sono programmate per il cliente, vengono annullate nella tabella di prenotazione.

Si prega di fare riferimento al modello di dati creato da me utilizzando Vertabelo per i dettagli a livello di colonna di tutte queste tabelle. Alcuni punti sulla creazione delle colonne:

Una colonna flag denominata is_active viene aggiunto a tutte le tabelle principali per consentire l'eliminazione temporanea dei record. Quindi, ad esempio, se un istruttore lascia la scuola, gireremo la bandierina su "N" per rendere inattivo il suo record.
Alcune colonne come created_date , created_by , last_modified_date e last_modified_by vengono aggiunti in tutte le tabelle delle transazioni per abilitare un audit trail per le modifiche ai record. Le tabelle delle transazioni sono evidenziate in blu nel modello di dati creato in Vertabelo.
Ti starai chiedendo quale sia l'address_id colonna nel staff il tavolo è per. Ho inserito di proposito questa colonna nel staff tabella in modo da poter estendere il mio modello di dati per supportare un processo automatizzato per assegnare l'istruttore a una richiesta in base alla sua posizione. Ad esempio, supponiamo che a New York City arrivi una richiesta da White Plains. Il mio sistema dovrebbe prima cercare un istruttore disponibile nelle stesse vicinanze o nelle vicinanze. Il mio sistema non dovrebbe mai assegnare un istruttore che soggiorna a Manhattan, che dista quasi 50 miglia dal luogo del richiedente.

Caratteristiche salienti di questo modello

Questo modello consente ai clienti di inserire richieste di prenotazione in base alle loro preferenze per data di inizio e veicolo.
Permette loro di cancellare una o più lezioni del loro corso, o l'intero corso stesso.
Questo modello acquisisce i dettagli dell'istruttore e del veicolo per ogni lezione.
Questo modello è estensibile per gestire tutti i possibili servizi forniti da una scuola guida.
Ci consente di progettare corsi di formazione e pianificare le lezioni in modo efficace.

Modello di database

Ecco il design del database per il nostro sistema di prenotazione. Il modello è stato creato in Vertabelo per il database Oracle, ma lo stesso design può essere implementato per altri motori di database senza modifiche significative.

Conclusione

Ci sono alcune aree tematiche che non abbiamo trattato in questo articolo, come:

Possiamo creare un approccio automatizzato per assegnare veicoli e istruttori alle lezioni?
Che ne dici di fatturare i clienti? Cosa succede se un cliente non vuole pagare l'intero corso ma solo un paio di lezioni? Possiamo mettergli a disposizione queste lezioni?

Il nostro modello esistente supporta tali funzionalità? La risposta è no. Probabilmente tratterò queste aree tematiche nel mio prossimo articolo.