Låt oss bygga ytterligare förändringar i datamodellen, som jag skapade i mitt tidigare blogginlägg, som att ha en automatiserad metod för att tilldela en instruktör och ett fordon till en lektion, fakturera kunder och spåra dem.
Först och främst måste jag bygga logik på applikationssidan för att tilldela en instruktör och ett fordon till lektioner innan de faktiskt äger rum. Det viktigaste att säkerställa här är tillgänglighet, det vill säga att en instruktör eller ett fordon kan tilldelas en lektion endast om båda är tillgängliga på den schemalagda tiden för lektionen.
Jag behöver konstruera två separata tabeller för att hålla reda på beläggning för instruktörer respektive fordon. Du kanske undrar varför jag tänker hålla koll på beläggning istället för tillgänglighet. Svaret är, om vi spårar beläggning istället för tillgänglighet, så behöver vi inte skapa fler tabeller för att lagra otillgängligheten av resurser på grund av ledighet planerad av instruktörer eller någon schemalagd service för fordon. I händelse av planerad otillgänglighet infogas poster i beläggningstabeller i enlighet med detta.
Jag antar här att instruktörer och fordon endast är tillgängliga under kontorstid, till exempel 8:00 till 18:00, på arbetsdagar som definieras av skolan. Därför kan jag säga att en instruktör är tillgänglig under en angiven tid på en arbetsdag om jag inte hittar information om beläggningen för den angivna tiden och dagen i staff_occupancy bord.
Strukturen för tabellen staff_occupancy är som följer:
Vissa varianter kan läggas in vid behov. Till exempel bör det finnas minst 15 minuters mellanrum mellan två efterföljande lektioner för en instruktör.
Strukturen för tabellen vehicle_occupancy är som följer:
Tilldelning av instruktör och fordon registreras i reservation tabell. Jag hade redan lagt till två kolumner, staff_id och vehicle_id , i den här tabellen. Dessa tilldelningar kommer uppenbarligen att ske baserat på deras tillgänglighet.
Dessutom kommer jag att behålla reservation_id i staff_occupancy och vehicle_occupancy tabeller, så att vid avbokning av en lektion kan relevant beläggning av personal och fordon enkelt frigöras. Men jag kommer att behålla båda dessa kolumner som nullbara eftersom beläggning av instruktörer och fordon inte nödvändigtvis beror på reservationer. Vad händer om en instruktör går på semester? Eller åker ett av fordonen in i servicecentret för en dag?
För att tillåta mjuk borttagning i sådana scenarier kommer jag att lägga till en kolumn som heter is_active i båda dessa tabeller.
Fakturering
För faktureringskravet kommer jag att skapa en tabell, nämligen invoice , för att hålla faktureringsinformation inklusive customer_id och reservation_id . Här ska fakturering ske till kunder men utifrån de lektioner som genomförs för kunden. Därför behöver vi reservation_id kolumnen även i fakturatabellen, så att man vid varje given tidpunkt kan dra en rapport om detaljerad fakturering utifrån en reservation för en kund. Jag kommer också att skapa en kolumn, nämligen invoice_status_id , i tabellen för att lagra status för fakturor.
Databasmodell
Här är den uppdaterade databasstrukturen designad i Vertabelo:
Slutsats
Vid det här laget måste du ha börjat tro att datamodellering för ett bokningssystem för en trafikskola är lika intressant och charmigt som att lära sig att köra?
Ställ gärna in dina frågor och förslag angående artikeln. Jag svarar mer än gärna på dem och infogar dina förslag i min nästa artikel.