Lad os bygge yderligere ændringer ind i datamodellen, som jeg oprettede i mit tidligere blogindlæg, såsom at have en automatiseret tilgang til at tildele en instruktør og et køretøj til en lektion, fakturering til kunder og sporing af dem.
Først og fremmest skal jeg bygge logik på applikationssiden for at tildele en instruktør og et køretøj til lektioner, før de rent faktisk finder sted. Det vigtigste at sikre her er tilgængelighed, dvs. en instruktør eller et køretøj kan kun tildeles en lektion, hvis begge er tilgængelige på det planlagte tidspunkt for lektionen.
Jeg skal konstruere to separate tabeller for at holde styr på belægning for henholdsvis instruktører og køretøj. Du undrer dig måske over, hvorfor jeg har tænkt mig at holde styr på belægning i stedet for tilgængelighed. Svaret er, hvis vi sporer belægning i stedet for tilgængelighed, så behøver vi ikke oprette flere tabeller for at gemme utilgængeligheden af ressourcer på grund af orlov planlagt af instruktører eller en planlagt service for køretøjer. I tilfælde af planlagt utilgængelighed, indsættes poster i belægningstabeller i overensstemmelse hermed.
Jeg antager her, at instruktører og køretøjer kun er tilgængelige i åbningstiden, f.eks. 8:00 til 18:00, på hverdage defineret af skolen. Derfor kan jeg sige, at en instruktør er tilgængelig på et bestemt tidspunkt på en hverdag, hvis jeg ikke kan finde dens belægningsdetaljer for det angivne tidspunkt og dag i staff_occupancy tabel.
Strukturen for tabel staff_occupancy er som følger:
Nogle variationer kan indsættes efter behov. For eksempel bør der være mindst 15 minutters mellemrum mellem to efterfølgende lektioner for en instruktør.
Strukturen for tabel vehicle_occupancy er som følger:
Tildeling af instruktør og køretøj registreres i reservation bord. Jeg havde allerede tilføjet to kolonner, staff_id og vehicle_id , i denne tabel. Disse tildelinger vil naturligvis ske baseret på deres tilgængelighed.
Derudover beholder jeg reservation_id i staff_occupancy og vehicle_occupancy tabeller, så i tilfælde af aflysning af en lektion kan den relevante belægning af personale og køretøj let frigives. Men jeg vil beholde begge disse kolonner som nullable da belægning af instruktører og køretøjer ikke nødvendigvis vil være på grund af reservationer. Hvad hvis en instruktør tager på orlov? Eller går et af køretøjerne ind i servicecentret for en dag?
For at tillade blød sletning i sådanne scenarier vil jeg tilføje en kolonne kaldet is_active i begge disse tabeller.
Fakturering
Til faktureringskravet vil jeg oprette én tabel, nemlig invoice , for at opbevare faktureringsoplysninger inklusive customer_id og reservation_id . Her skal fakturering ske til kunder men ud fra de lektioner, der er udført for kunden. Derfor har vi brug for reservation_id kolonne også i fakturatabellen, så man på ethvert givet tidspunkt kan trække en rapport om detaljeret fakturering på ud fra en reservation til en kunde. Jeg vil også oprette en kolonne, nemlig invoice_status_id , i tabellen for at gemme status for fakturaer.
Databasemodel
Her er den opdaterede databasestruktur designet i Vertabelo:
Konklusion
Nu må du være begyndt at tro, at datamodellering for et reservationssystem på en køreskole er lige så interessant og charmerende som at lære at køre?
Du er velkommen til at stille dine spørgsmål og forslag til artiklen. Jeg svarer mere end gerne på dem og inkorporerer dine forslag i min næste artikel.