Databasmodell för en trafikskolas bokningssystem. Del 1

Jag behöver designa en datamodell för ett bokningssystem för en trafikskola. Ämnesområdet ser ganska okomplicerat ut, men komplexiteten är fortfarande inblandad. Du måste spåra alla förfrågningar från kunder och hålla reda på resurser (fordon, tid och instruktör) som förbrukas under lektionerna.

Introduktion

Jag gillar att använda ett domändrivet tillvägagångssätt för att utforma en datamodell. Det får mig att lägga teknikbesattheten åt sidan och i första hand koncentrera mig på att modellera ämnesområdet som kretsar kring dess associerade enheter och relationer sinsemellan.

Krav i ett nötskal

Låt mig först skriva ner kravet på vanlig engelska först.

Jag behöver en datamodell för en trafikskola för att tillåta kunder för att göra reservationer för lektioner uppkopplad. Trafikskolan kan ha mer än en instruktör och mer än ett fordon . Instruktören tilldelas lektionen vid bokning. Systemet bör tillåta kunder att avboka reservationer när som helst före den planerade dagen. Fordonet som tilldelats lektionen bör också registreras om lektionen äger rum.

Inblandade enheter och relationer

När jag tänker på ämnet är de enheter som jag tänker på först, "Kund" , "Instruktör" , "Körlektion" , “Bokningsbegäran” och "Fordon" . Låt mig börja med min allra första tabell för den här modellen, och det är customer . Det är för att lagra masterdata för kunder. Jag skulle förmodligen behöva en annan tabell för att lagra instruktörsinformation, men istället för att skapa en tabell med namnet på instruktören, kommer jag att skapa en generisk tabell som heter staff för personalinformation och behåll "Instruktör" som jobbtitel. Det kommer att göra min datamodell utbyggbar för att tillgodose andra tjänsteområden, som administrativt och juridiskt arbete, på en trafikskola.

Jag överväger "körkurs" som en av tjänsterna, så skapar jag en annan tabell som heter service . En tjänst, "körkurs" i det här fallet kan ha flera lektioner. För att hantera detta krav behöver jag verkligen en annan huvudtabell, nämligen lesson , och en relationstabell, nämligen service_lesson , för att hantera många till många relationer mellan båda dessa masterenheter, dvs en tjänst kan definitivt ha flera lektioner, men å andra sidan kan en lektion också vara en del av mer än en tjänst.

När man skickar en reservationsförfrågan ombeds han/hon att fylla i sina uppgifter och preliminära preferenser som vilken typ av tjänst han/hon vill ha, val av fordon och startdatum. Kundens uppgifter lagras i kundtabellen. Därefter skapas en begäran i request tabell, och alla inställningar lagras mot begäran i samma tabell. Det finns vissa statuser kopplade till varje begäran, som "skicka", "pågår", "avbryt" och "slutför". Jag kommer att skapa en stödtabell för den som heter request_status .

Vid tidpunkten för inlämnandet av begäran anger man en preferens för fordon, dvs typ av fordon. Men fordonet skulle faktiskt tilldelas en lektion när den äger rum. Därför behåller jag vehicle_type_id som en av kolumnerna i request tabell för nu.

När en begäran behandlas görs reservationer för varje lektion av tjänsteförfrågan. Dessutom tilldelas instruktörer och fordon till varje lektion baserat på tillgången på instruktörer och kundernas preferenser för fordon. Lektioner är schemalagda för framtida datum med status "Öppen". Alla dessa detaljer finns samlade i en annan transaktionstabell som heter reservation . Jag har markerat alla transaktionstabeller med en annan färg än alla huvudtabeller.

En huvudtabell, reservation_status , skapas för att lagra alla möjliga värden för reservationsstatus som "öppen", "pågår", "avbryt" och "slutför".

Denna modell gör det möjligt för en kund att avbryta en individuell lektion såväl som tjänsteförfrågan som helhet. Om kunden avbryter servicebegäran, avbokas alla återstående lektioner, som är schemalagda för kunden, i bokningstabellen.

Se datamodellen skapad av mig med Vertabelo för detaljer på kolumnnivå för alla dessa tabeller. Några punkter om att skapa kolumner:

• En flaggkolumn med namnet is_active läggs till i alla huvudtabeller för att möjliggöra mjuk radering av poster. Så till exempel, om någon instruktör lämnar skolan kommer vi att vända flaggan till "N" för att göra hans post inaktiv.
• Vissa kolumner som created_date , created_by , last_modified_date och last_modified_by läggs till i alla transaktionstabeller för att möjliggöra en revisionsspår för ändringar i poster. Transaktionstabeller är markerade i blått i datamodellen som skapats i Vertabelo.
• Du kanske undrar vad address_id är kolumnen i staff bordet är för. Jag har avsiktligt lagt den här kolumnen i staff tabell så att jag kan utöka min datamodell för att stödja en automatiserad process för att tilldela instruktör till en förfrågan baserat på hans eller hennes plats. Anta till exempel att en förfrågan från White Plains kommer in i New York City. Mitt system bör först leta efter en tillgänglig instruktör i samma eller närmaste närhet. Mitt system ska aldrig tilldela en instruktör som vistas på Manhattan, som är nästan 80 mil bort från förfrågans plats.

Framträdande egenskaper hos denna modell

• Med den här modellen kan kunder lägga in reservationsförfrågningar enligt deras preferenser för startdatum och fordon.
• Det låter dem avbryta en eller flera lektioner av sin kurs, eller hela kursen.
• Denna modell fångar instruktörs- och fordonsdetaljer för varje lektion.
• Denna modell är utbyggbar för att hantera alla möjliga tjänster som tillhandahålls av en trafikskola.
• Det gör det möjligt för oss att utforma utbildningar och planera lektioner effektivt.

Databasmodell

Här är databasdesignen för vårt bokningssystem. Modellen skapades i Vertabelo för Oracle-databas men samma design kan implementeras för andra databasmotorer utan betydande förändringar.

Slutsats

Det finns vissa ämnesområden som vi inte täckte i den här artikeln, till exempel:

• Kan vi bygga ett automatiserat tillvägagångssätt för att allokera fordon och instruktörer till lektioner?
• Vad sägs om att fakturera kunder? Vad händer om en kund inte vill betala för hela kursen utan för ett par lektioner av den? Kan vi göra dessa lektioner tillgängliga för honom?

Stöder vår befintliga modell sådana funktioner? Svaret är nej. Jag kommer förmodligen att täcka dessa ämnesområden i min nästa artikel.