Datamodel for autoværksted

At drive et bil-/bilværksted er en virkelig kompleks forretning. Du bliver nødt til at lave aftaler, mens nogle kunder kører ind, og du vil ikke have dem til at vente i timevis. Du skal også organisere medarbejdere, spore reparationer, materialer, opkræve kunder osv. Du skal helt sikkert have en it-løsning og selvfølgelig en datamodel i baggrunden. I dag vil vi tale om en sådan model.

Idéen

Jeg har allerede nævnt, at denne forretningsmodel er virkelig kompleks. Derfor vil jeg ikke forsøge at dække alt. Jeg har med vilje udeladt sporingsmaterialer og reservedele og har også forenklet nogle dele af modellen. Grunden til det er ret simpel. Hvis jeg har medtaget virkelig alt, ville modellen simpelthen være for stor til en artikel af den rimelige størrelse. Så lad os starte.

Datamodel

Modellen består af 5 fagområder:

Repair shops & employees
Customers & contacts
Vehicles
Services & offers og
Visits

Vi vil beskrive hvert af disse 5 emneområder i den rækkefølge, de blev anført.

Afsnit 1:Reparationsværksteder og medarbejdere

Det første emneområde, vi begynder med, er Repair shops & employees emneområde. Det er ret indlysende, at vi skal vide, hvad vi har til rådighed, før vi kan give tilbud til kunderne.

city ordbog bruges til at gemme alle adskilte byer, hvor vi har værksteder eller vores kunder kommer fra. Hver by er unikt defineret af parret postal_code – city_name . Vi kunne beslutte kun at have én indgang pr. hver by, selvom den by har flere postnumre. I så fald ville vi kun bruge "hoved" postnummeret for den by. Alligevel har vi mulighed for at have flere poster for den samme by og forskellige postnumre – hvis vi ønsker det.

repair_shop tabellen er stedet, hvor vi gemmer en liste over alle vores værksteder. Vi kan forvente, at vi vil operere mere end én på et tidspunkt. Hver butik er unikt defineret af dens shop_name og id'et for den by, den tilhører (city_id ). Vi gemmer også butikkens adresse og yderligere details i tekstformatet, hvis nogen.

position ordbog bruges til at gemme unikke position_names som kunne tildeles vores medarbejdere. Mens de fleste stillinger skal være relateret til vores kerneforretning, vil vi også have nogle, der ikke er en del af kerneforretningen (tekniske roller/stillinger), men som også er væsentlige (administration, salg osv.).

En liste over alle vores medarbejdere er gemt i employee bord. For hver medarbejder gemmer vi hans:

first_name &last_name – Medarbejderens for- og efternavn.
employment_start_date &employment_end_date – Medarbejders start- og slutdato i virksomheden. Slutdatoen skal indeholde NULL-værdi, indtil vi kan definere den.
position_id – En reference til den aktuelle stilling i virksomheden.
city_id – En henvisning til den by, hvor medarbejderen bor i øjeblikket.
is_active – Et flag, der angiver, om medarbejderen i øjeblikket er aktiv eller ej.

Den sidste tabel i dette emneområde er schedule bord. I denne tabel gemmer vi nøjagtige tidsplaner for alle vores medarbejdere på dagligt niveau. Vi har også mulighed for at gemme flere intervaller for den samme medarbejder i løbet af samme dag. For at opnå dette bruger vi følgende attributter:

repair_shop_id – En henvisning til det relaterede værksted.
employee_id – En reference til den relaterede medarbejder.
position_id – En reference til den relaterede stilling, medarbejderen ville have i den definerede tidsperiode. I de fleste tilfælde vil dette være hans nuværende stilling, men vi har fleksibiliteten til at tildele en anden stilling her.
schedule_date – En dato, som denne post er relateret til.
time_from &time_to – Dette par definerer den tidsperiode, denne post er relateret til.
plan – Et flag, der angiver, om dette var planlagt indrejse. Adgang planlægges ikke kun, hvis vi har indsat det ad hoc.
actual – Dette flag angiver, om denne indtastning blev realiseret. Bemærk, at i de fleste tilfælde vil både flag, plan og faktisk, være sat til True. Dette ville påpege, at vi planlagde og faktisk realiserede den plan.
insert_ts – Et tidsstempel, der angiver det øjeblik, hvor denne post blev indsat i tabellen.

Kombinationen repair_shop_id - employee_id - schedule_date - time_from danner den UNIQUE/alternative nøgle i denne tabel. Før vi indsætter en ny post, bør vi også kontrollere det nye interval time_from – time_to overlapper ikke med noget eksisterende interval for den samme medarbejder og dato.

Afsnit 2:Kunder og kontakter

Nu er vi klar til at gå over til den kunderelaterede del af modellen.

Vi gemmer alle kunder, vi har arbejdet med før, eller vi havde kontakt med, i customer bord. For hver kunde gemmer vi:

first_name &last_name – Kundens for- og efternavn, hvis vores kunde er en privatperson.
company_name – Et firmanavn, i en sag ude kunde kunden er en virksomhed og ikke en privatperson.
address – Kundens adresse.
mobile – Kundens mobiltelefonnummer.
email – Kundens e-mail
details – Alle yderligere kundeoplysninger, hvis nogen, i tekstformat.
insert_ts – Et tidsstempel, der angiver det øjeblik, hvor denne post blev indsat i tabellen.

De fleste af attributterne i denne tabel er nullable, fordi vi sandsynligvis ikke vil have nogle af dem og nogle (first_name &last_name vs. company_name ) udelukke andre.

Vi bliver nødt til at spore alle kontakter, vi har haft med hver enkelt kunde. For at gøre det bruger vi to tabeller. Den første, contact_type tabel, er en simpel ordbog, der kun indeholder det UNIKKE type_name værdi.

Reelle kontaktdata gemmes i contact bord. Vi gemmer referencer til typen af denne kontakt (contact_type_id ), en kunde, vi havde kontakt med (customer_id ), en medarbejder, der tog kontakten (schedule_id ), og gemmer også kontaktoplysninger og tidspunktet for, hvornår denne post blev indsat i tabellen (insert_ts ).

Afsnit 3:Køretøjer

Efter at have kendskab til vores ressourcer og kunder, skal vi opbevare køretøjer, vi arbejder med. Udover at spore data og oprette interne rapporter, er vi i de fleste lande også nødt til at oprette rapporter til regulerende agenturer, forsikringsselskaber, politi.

Først vil vi definere modeller af vores køretøjer. Vi bruger 3 tabeller til at opnå det. I make ordbog, vil vi liste unikke make_names for alle bil-/køretøjsfabrikanter/-mærker. Udover det skal vi kende køretøjstyper, så vi bruger endnu en ordbog med kun én unik værdiattribut - type_name . De 3 anvendte ordbog er model ordbog. Denne skal indeholde listen over alle modeller, der kom gennem vores døre. For hver model definerer vi den unikke kombination model_name – make_id – vechicle_type_id .

Vi afslutter beskrivelsen af dette emneområde med vehicle bord. Dette er den eneste tabel i dette emneområde, der indeholder "rigtige" data. Vi bruger denne tabel til at gemme følgende detaljer:

vin – Et køretøjs identifikationsnummer, der entydigt definerer dette køretøj.
license_plate – Et aktuelt nummerpladenummer.
customer_id – En reference til den kunde, dette køretøj tilhører. Hvis køretøjet skifter ejer, indsætter vi det som en ny rekord, men vi ved, at dette er det samme køretøj baseret på serienummeret.
model_id – En henvisning til modelordbogen.
manufactured_year &manufactured_month – Angiv år og måned, hvor dette køretøj blev produceret.
details – Alle yderligere detaljer i tekstformatet.
insert_ts – Et tidsstempel, der angiver det øjeblik, hvor denne post blev indsat i tabellen.

Afsnit 4:Tjenester og tilbud

Vi er klar til at tage det næste store skridt. Vi skal definere, hvad vi tilbyder til vores (potentielle) kunder. Disse kunne være enkelte opgaver eller et sæt opgaver – tjenester.

Listen over alle tjenester er gemt i service_catalog ordbog. Hver tjeneste består af nogle få opgaver og er unikt defineret af dens service_name . Udover navnet gemmer vi også en beskrivelse, hvis vi har nogen, procentdelen af service_discount og is_active flag. Servicerabatten skal bruges til alle opgaver, der er inkluderet i denne service.

Dernæst definerer vi opgaver. Opgaver er en del af vores ydelser. De er den grundlæggende handling, der kunne udføres selvstændigt. Hver opgave er defineret af disse værdier i task_catalog tabel:

task_name &service_catalog_id – Et navn, vi vil bruge til at beskrive denne opgave og den tjeneste, den tilhører. Dette attributpar danner tabellens unikke nøgle.
description – Eventuel yderligere tekstbeskrivelse, der bruges til at beskrive denne opgave.
ref_interval – Et flag, der angiver, om vi vil måle interval for denne opgave.
ref_interval_min &ref_interval_max – Den minimale og den maksimale grænse for referenceområdet.
describe – Et flag, der angiver, om vi skal tilføje en tekstkommentar til denne opgave.
task_price – En aktuel pris uden servicerabatter for denne opgave.
is_active – Et flag, der angiver, om opgaven i øjeblikket er aktiv (i vores tilbud) eller ej.

Efter kontakten med kunderne kommer vi med tilbud til dem. Tilbuddet kan være en komplet service, med alle dens opgaver eller et sæt opgaver. Alle tilbud gemmes i offer bord. For hvert tilbud gemmer vi:

customer_id – Et id for den relaterede kunde.
contact_id – Et id for den relaterede kontakt, hvis der var nogen. Dette kan være vigtig information for at afgøre, hvor mange tilbud der kom som følge af tidligere kontakter.
offer_description – En yderligere tekstbeskrivelse af dette tilbud.
service_catalog_id – Et id for den service, vi har tilbudt kunden. Dette id kan være NULL, hvis vi ikke har tilbudt ham en komplet tjeneste, men en eller flere opgaver, der ikke er en del af tjenesten.
service_discount – Servicerabatten på det tidspunkt, tilbuddet blev oprettet. Denne værdi skal indeholde NULL, hvis tilbuddet ikke var relateret til tjenesten.
offer_price – En endelig pris på det tilbud. Det kunne beregnes som summen af alle opgaver minus servicerabat.
insert_ts – Et tidsstempel, der angiver det øjeblik, hvor denne post blev indsat i tabellen.

Den sidste tabel i dette emneområde er offer_task bord. For hvert tilbud, uanset om vi tilbød en komplet service eller ej, gemmer vi sættet af alle opgaver. Vi skal gemme følgende detaljer:

offer_id – Et id for det relaterede tilbud.
task_catalog_id – Et id for den relaterede opgave. Sammen med offer_id , den danner den unikke/alternative nøgle for denne tabel
task_price – En aktuel pris på den opgave i det øjeblik, denne post blev indsat.
insert_ts - Et tidsstempel, der angiver det øjeblik, hvor denne post blev indsat i tabellen.

Afsnit 5:Besøg

Det sidste emneområde i vores model bruges til at gemme faktiske kundebesøg på vores værksted. Selvom det ser komplekst ud, har vi kun 2 nye borde her, visit og visit_task .

Når kunden accepterer vores tilbud eller bare kommer ind i vores butik, behandler vi det som et visit . For hver sådan begivenhed gemmer vi følgende detaljer:

repair_shop_id – En henvisning til det relaterede værksted.
customer_id – En reference til kunden, som dette besøg er relateret til.
vehicle_id – En reference til det køretøj, dette besøg er relateret til.
visit_start_date – En startdato for et besøg (planlagt).
visit_start_time – Et besøgs starttidspunkt (planlagt).
visit_end_date – Et besøgs startdato (faktisk). Denne værdi skal indstilles, når besøget faktisk slutter.
visit_end_time – Et besøgs starttidspunkt (faktisk). Denne værdi skal indstilles, når besøget faktisk slutter.
license_plate – Et nummerpladenummer i det øjeblik, besøget fandt sted. Bemærk, at nummerpladerne ændres i løbet af tiden.
offer_id – Et id for det relaterede tilbud, hvis nogen.
service_catalog_id – Et id for den relaterede tjeneste, hvis nogen.
service_discount – Et procentuelt rabatbeløb på det tidspunkt, hvor denne post blev tilføjet, og hvis vi tilbyder en komplet service.
visit_price – En samlet pris, som en kunde skal betale for det besøg.
invoice_created – Et tidsstempel, når fakturaen blev genereret.
invoice_due – Et tidsstempel, hvornår fakturaen forfaldt.
invoice_charged – Et tidsstempel, hvornår fakturaen blev debiteret.
insert_ts – Et tidsstempel, der angiver det øjeblik, hvor denne post blev indsat i tabellen.

Den sidste tabel i vores model er visit_task bord. Dette er stedet for at opbevare alle opgaver, der faktisk var en del af det besøg. For hver post her gemmer vi følgende værdier:

visit_id – En henvisning til det besøg.
task_catalog_id – En reference til den relaterede opgave
value_measured – En værdi, der blev målt under denne opgave, hvis opgaven krævede måling.
task_description – En beskrivelse relateret til den pågældende opgave, hvis opgaven krævede en beskrivelse.
pass – Et flag, der angiver, om denne opgave var i det forventede interval eller ej.
task_price – En faktisk pris for den opgave i øjeblikket indsat i denne tabel.
insert_ts – Et tidsstempel, der angiver det øjeblik, hvor denne post blev indsat i tabellen.

Selvom denne model er ret forenklet, indeholder den alle de nødvendige elementer, du skal bruge for at bygge en komplet model omkring den. Dele, der kræver forbedringer, er bestemt materiale, der bruges og betalingsbehandling. Vil du tilføje noget mere til denne model?