Jeg skal designe en datamodel til et reservationssystem til en køreskole. Fagområdet ser ret ligetil ud, men kompleksiteten er stadig involveret. Du skal spore alle anmodninger fra kunder og holde styr på de ressourcer (køretøj, tid og instruktør), der forbruges under undervisningen.
Introduktion
Jeg kan godt lide at bruge en domænedrevet tilgang til at designe en datamodel. Det får mig til at lægge teknologibesættelsen til side og primært koncentrere mig om at modellere emneområdet, der drejer sig om dets tilknyttede enheder og indbyrdes forhold.
Krav i en nøddeskal
Lad mig først nedsætte kravet på almindeligt engelsk først.
Jeg har brug for en datamodel til en køreskole for at tillade kunder for at foretage reservationer til lektioner online. Køreskolen kan have mere end én instruktør og mere end ét køretøj . Underviseren tildeles lektionen ved reservation. Systemet bør give kunder mulighed for at annullere reservation(er) når som helst før den planlagte dag. Det køretøj, der er tildelt lektionen, skal også registreres, hvis lektionen finder sted.
Involverede enheder og relationer
Når jeg tænker på emnet, er de entiteter, der kommer først til mit sind, "Kunde" , "Instruktør" , "Køreundervisning" , "Reservationsanmodning" og "Køretøj" . Lad mig starte med min allerførste tabel for denne model, og det er customer . Det er til at gemme stamdata for kunder. Jeg ville sandsynligvis have brug for en anden tabel til at gemme instruktørdetaljer, men i stedet for at oprette en tabel med navnet på instruktøren, vil jeg oprette en generisk tabel kaldet staff for personaledetaljer og behold "Instruktør" som en stillingsbetegnelse. Det vil gøre min datamodel udvidelig til også at imødekomme andre serviceområder, såsom administrativt og juridisk arbejde, på en køreskole.
Jeg overvejer "kørekursus" som en af tjenesterne, derfor opretter jeg en anden tabel kaldet service . En service, "kørekursus" i dette tilfælde kan have flere lektioner. For at håndtere dette krav har jeg bestemt brug for en anden mastertabel, nemlig lesson , og én relationstabel, nemlig service_lesson , for at styre mange til mange forhold mellem begge disse masterentiteter, dvs. én tjeneste kan bestemt have flere lektioner, men på den anden side kan én lektion også være en del af mere end én tjeneste.
Når man indsender en reservationsanmodning, bliver han/hun bedt om at udfylde sine detaljer og foreløbige præferencer, såsom hvilken type service han/hun ønsker, valg af køretøj og startdato. Kundens oplysninger gemmes i kundetabellen. Efterfølgende oprettes en anmodning i request tabel, og alle præferencer gemmes mod anmodningen i samme tabel. Der er visse statusser knyttet til hver anmodning, såsom "send", "igangværende", "annuller" og "fuldfør". Jeg vil oprette en understøttende tabel til den kaldet request_status .
På tidspunktet for anmodningens indsendelse, sætter man en præference for køretøj, dvs. type køretøj. Men køretøjet ville faktisk blive tildelt en lektion, når den finder sted. Derfor beholder jeg vehicle_type_id som en af kolonnerne i request tabel for nu.
Når en anmodning behandles, foretages reservationer for hver lektion af serviceanmodningen. Derudover tildeles instruktører og køretøjer til hver lektion baseret på tilgængeligheden af instruktører og kundernes præferencer for køretøjer. Lektioner er planlagt til fremtidige datoer med status "Åben". Alle disse detaljer er fanget i en anden transaktionstabel kaldet reservation . Jeg har fremhævet alle transaktionstabeller med en anden farve end alle mastertabeller.
Én hovedtabel, reservation_status , er oprettet for at gemme alle mulige værdier for reservationsstatusser som "åben", "igangværende", "annuller" og "fuldført".
Denne model giver en kunde mulighed for at annullere en individuel lektion såvel som serviceanmodningen som helhed. Hvis kunden annullerer serviceanmodningen, annulleres alle resterende lektioner, som er planlagt til kunden, i reservationstabellen.
Se venligst datamodellen oprettet af mig ved hjælp af Vertabelo for detaljer på kolonneniveau for alle disse tabeller. Et par punkter vedrørende oprettelse af kolonner:
- En flagkolonne med navnet
is_activeføjes til alle mastertabeller for at muliggøre blød sletning af poster. Så hvis en instruktør for eksempel forlader skolen, vender vi flaget til "N" for at gøre hans rekord inaktiv. - Visse kolonner som f.eks.
created_date,created_by,last_modified_dateoglast_modified_bytilføjes i alle transaktionstabeller for at muliggøre et revisionsspor for ændringer i poster. Transaktionstabeller er fremhævet med blåt i den datamodel, der er oprettet i Vertabelo. - Du undrer dig måske over, hvad
address_ider kolonne istaffbord er til. Jeg har med vilje lagt denne kolonne istafftabel, så jeg kan udvide min datamodel til at understøtte en automatiseret proces til at tildele instruktør til en anmodning baseret på hans eller hendes placering. Antag for eksempel, at der i New York City kommer en anmodning fra White Plains. Mit system skal først lede efter en ledig instruktør i samme eller nærmeste nærhed. Mit system bør aldrig tildele en instruktør, der opholder sig på Manhattan, som er næsten 50 miles væk fra anmoderens sted.
Vigtige træk ved denne model
- Denne model giver kunderne mulighed for at indsætte reservationsanmodninger i henhold til deres præferencer for startdato og køretøj.
- Det giver dem mulighed for at annullere en eller flere lektioner af deres kursus eller hele kurset.
- Denne model fanger instruktør- og køretøjsdetaljer for hver lektion.
- Denne model kan udvides til at håndtere alle mulige tjenester leveret af en køreskole.
- Det sætter os i stand til at designe træningskurser og planlægge lektioner effektivt.
Databasemodel
Her er databasedesignet til vores reservationssystem. Modellen blev oprettet i Vertabelo til Oracle-databasen, men det samme design kan implementeres for andre databasemotorer uden væsentlige ændringer.
Konklusion
Der er visse emneområder, som vi ikke dækkede i denne artikel, såsom:
- Kan vi opbygge en automatiseret tilgang til at allokere køretøjer og instruktører til lektioner?
- Hvad med at fakturere kunder? Hvad hvis en kunde ikke ønsker at betale for hele kurset, men for et par lektioner af det? Kan vi stille disse lektioner til rådighed for ham?
Understøtter vores eksisterende model sådanne funktioner? Svaret er NEJ. Jeg vil sandsynligvis dække disse emneområder i min næste artikel.