Gegevensmodel autoreparatiewerkplaats

Het runnen van een auto-/autoreparatiewerkplaats is een zeer complexe aangelegenheid. U moet afspraken maken terwijl sommige klanten binnenkomen en u wilt niet dat ze uren moeten wachten. Ook moet je medewerkers organiseren, reparaties, materialen volgen, klanten factureren, enz. Je hebt zeker een IT-oplossing nodig en natuurlijk een datamodel op de achtergrond. Vandaag zullen we het hebben over zo'n model.

Het idee

Ik heb al gezegd dat dit bedrijfsmodel erg complex is. Daarom zal ik niet proberen alles te dekken. Ik heb opzettelijk trackingmaterialen en reserveonderdelen weggelaten en ook sommige delen van het model vereenvoudigd. De reden daarvoor is vrij simpel. Als ik echt alles heb opgenomen, zou het model gewoon te groot zijn voor een artikel van redelijk formaat. Laten we beginnen.

Gegevensmodel

Het model bestaat uit 5 vakgebieden:

• Repair shops & employees
• Customers & contacts
• Vehicles
• Services & offers en
• Visits

We zullen elk van deze 5 onderwerpgebieden beschrijven in de volgorde waarin ze werden vermeld.

Sectie 1:Reparatiewerkplaatsen en werknemers

Het eerste onderwerp waar we mee beginnen is de Repair shops & employees gebied. Het is vrij duidelijk dat we moeten weten wat we tot onze beschikking hebben voordat we klanten aanbiedingen kunnen doen.

De city woordenboek wordt gebruikt om alle verschillende steden op te slaan waar we reparatiewerkplaatsen hebben of waar onze klanten vandaan komen. Elke stad wordt uniek gedefinieerd door het paar postal_code – city_name . We zouden kunnen besluiten om slechts één vermelding per stad te hebben, zelfs als die stad meerdere postcodes heeft. In dat geval zouden we alleen de "hoofd" postcode voor die stad gebruiken. Toch hebben we een optie om meerdere vermeldingen voor dezelfde stad en verschillende postcodes te hebben - voor het geval we dat willen.

De repair_shop table is de plaats waar we een lijst van al onze reparatiewerkplaatsen zullen opslaan. We kunnen verwachten dat we er op een gegeven moment meer dan één zullen bedienen. Elke winkel wordt uniek gedefinieerd door zijn shop_name en de id van de stad waartoe het behoort (city_id ). We slaan ook het adres van de winkel op en aanvullende details in de tekstuele indeling, indien van toepassing.

De position woordenboek wordt gebruikt om unieke position_names op te slaan die aan onze medewerkers kunnen worden toegewezen. Hoewel de meeste functies gerelateerd zullen zijn aan onze kernactiviteiten, zullen we er ook enkele hebben die geen deel uitmaken van de kernactiviteiten (technische rollen/functies) maar die ook essentieel zijn (administratie, verkoop, enz.).

Een lijst van al onze medewerkers wordt opgeslagen in de employee tafel. Voor elke medewerker bewaren we zijn:

• first_name &last_name – De voor- en achternaam van de medewerker.
• employment_start_date &employment_end_date – Begin- en einddatum van de werknemer in het bedrijf. De einddatum zal een NULL-waarde bevatten totdat we deze kunnen definiëren.
• position_id – Een verwijzing naar de huidige functie in het bedrijf.
• city_id – Een verwijzing naar de stad waar de werknemer momenteel woont.
• is_active – Een vlag die aangeeft of de werknemer momenteel actief is of niet.

De laatste tabel in dit onderwerpgebied is het schedule tafel. In deze tabel slaan we de exacte roosters op van al onze medewerkers op dagniveau. We hebben ook de mogelijkheid om meerdere intervallen voor dezelfde medewerker op dezelfde dag op te slaan. Om dit te bereiken, gebruiken we de volgende attributen:

• repair_shop_id – Een verwijzing naar de gerelateerde reparatiewerkplaats.
• employee_id – Een verwijzing naar de betreffende medewerker.
• position_id – Een verwijzing naar de gerelateerde functie die de werknemer zou hebben gedurende de gedefinieerde periode. In de meeste gevallen zou dit zijn huidige functie zijn, maar we hebben de flexibiliteit om hier een andere functie toe te wijzen.
• schedule_date – Een datum waarop dit bericht betrekking heeft.
• time_from &time_to – Dit paar definieert de tijdsperiode waaraan dit item is gerelateerd.
• plan – Een vlag die aangeeft of dit een geplande binnenkomst was. Toegang wordt niet alleen gepland als we het ad-hoc hebben ingevoegd.
• actual – Deze vlag geeft aan of deze invoer is gerealiseerd. Merk op dat in de meeste gevallen beide vlaggen, plan en actueel, worden ingesteld op True. Dit zou erop wijzen dat we dat plan hebben gepland en ook daadwerkelijk hebben gerealiseerd.
• insert_ts – Een tijdstempel dat het moment aangeeft waarop dit record in de tabel is ingevoegd.

De combinatie repair_shop_id - employee_id - schedule_date - time_from vormt de UNIEKE/alternatieve sleutel van deze tabel. Voordat we een nieuw record invoegen, moeten we ook dat nieuwe interval time_from . controleren – time_to overlapt niet met een bestaand interval voor diezelfde werknemer en datum.

Sectie 2:Klanten &contacten

Nu zijn we klaar om over te gaan naar het klantgerelateerde deel van het model.

We slaan alle klanten, waarmee we eerder hebben gewerkt of waarmee we contact hebben gehad, op in de customer tafel. Voor elke klant slaan we op:

• first_name &last_name – De voor- en achternaam van de klant, indien onze klant een particulier is.
• company_name – Een bedrijfsnaam, in het geval dat de klant een bedrijf is en geen particulier.
• address – Het adres van de klant.
• mobile – Het mobiele telefoonnummer van de klant.
• email – Het e-mailadres van de klant
• details – Alle eventuele aanvullende klantgegevens in tekstvorm.
• insert_ts – Een tijdstempel dat het moment aangeeft waarop dit record in de tabel is ingevoegd.

De meeste attributen in deze tabel zijn nullable omdat we er waarschijnlijk niet een hebben en sommige (first_name &last_name vs. company_name ) anderen uitsluiten.

We moeten alle contacten bijhouden die we met elke klant hebben gemaakt. Om dat te doen, gebruiken we twee tabellen. De eerste, de contact_type tabel, is een eenvoudig woordenboek met alleen de UNIEKE type_name waarde.

Echte contactgegevens worden opgeslagen in het contact tafel. We slaan verwijzingen op naar het type van dat contact (contact_type_id ), een klant waarmee we contact hadden (customer_id ), een medewerker die dat contact heeft gelegd (schedule_id ), en bewaar ook contactgegevens en het tijdstip waarop dit record in de tabel werd ingevoegd (insert_ts ).

Sectie 3:Voertuigen

Nadat we onze middelen en klanten kennen, moeten we voertuigen opslaan waarmee we zullen werken. Naast het bijhouden van gegevens en het maken van interne rapporten, moeten we in de meeste landen ook rapporten maken voor regelgevende instanties, verzekeringsmaatschappijen, politie.

Eerst zullen we modellen van onze voertuigen definiëren. We gebruiken 3 tabellen om dat te bereiken. In de make woordenboek, geven we een lijst met unieke make_names voor alle auto-/voertuigfabrikanten/merken. Daarnaast moeten we voertuigtypes kennen, dus gebruiken we nog een woordenboek met slechts één uniek waardekenmerk:type_name . Het 3 gebruikte woordenboek is het model woordenboek. Deze zal de lijst bevatten van alle modellen die door onze deuren zijn gekomen. Voor elk model definiëren we de unieke combinatie model_name – make_id – vechicle_type_id .

We eindigen de beschrijving van dit onderwerp met het vehicle tafel. Dit is de enige tabel in dit onderwerpgebied die "echte" gegevens bevat. We gebruiken deze tabel om de volgende details op te slaan:

• vin – Een voertuigidentificatienummer dat dit voertuig uniek definieert.
• license_plate – Een actueel kenteken.
• customer_id – Een verwijzing naar de klant waartoe dit voertuig behoort. Als het voertuig van eigenaar verandert, voegen we het in als een nieuw record, maar we weten dat dit hetzelfde voertuig is op basis van het serienummer.
• model_id – Een verwijzing naar het modelwoordenboek.
• manufactured_year &manufactured_month – Geef het jaar en de maand aan waarin dit voertuig is geproduceerd.
• details – Alle aanvullende details in tekstformaat.
• insert_ts – Een tijdstempel dat het moment aangeeft waarop dit record in de tabel is ingevoegd.

Sectie 4:Diensten en aanbiedingen

We zijn klaar voor de volgende grote stap. We moeten definiëren wat we onze (potentiële) klanten aanbieden. Dit kunnen afzonderlijke taken zijn of een reeks taken – services.

De lijst met alle services wordt opgeslagen in de service_catalog woordenboek. Elke service bestaat uit een paar taken en is uniek gedefinieerd door zijn service_name . Naast de naam slaan we ook een beschrijving op, als die er is, het percentage van service_discount en de is_active vlag. De servicekorting wordt gebruikt voor alle taken die bij deze service zijn inbegrepen.

Vervolgens zullen we taken definiëren. Taken zijn onderdeel van onze dienstverlening. Dit zijn de basisacties die op zichzelf kunnen worden uitgevoerd. Elke taak wordt gedefinieerd door deze waarden in de task_catalog tafel:

• task_name &service_catalog_id – Een naam die we zullen gebruiken om deze taak en de service waartoe deze behoort te beschrijven. Dit attributenpaar vormt de unieke sleutel van de tabel.
• description – De eventuele aanvullende tekstuele beschrijving die wordt gebruikt om deze taak te beschrijven.
• ref_interval – Een vlag die aangeeft of we het interval voor deze taak gaan meten.
• ref_interval_min &ref_interval_max – De minimale en maximale grens van het referentiebereik.
• describe – Een vlag die aangeeft of we een tekstuele opmerking voor deze taak moeten toevoegen.
• task_price – Een actuele prijs, zonder servicekortingen, voor deze taak.
• is_active – Een vlag die aangeeft of de taak momenteel actief is (in ons aanbod) of niet.

Na het contact met klanten zullen we hen aanbiedingen doen. Het aanbod kan een complete dienst zijn, met al zijn taken of een takenpakket. Alle aanbiedingen worden opgeslagen in de offer tafel. Voor elke aanbieding slaan we op:

• customer_id – Een id van de gerelateerde klant.
• contact_id – Een id van de gerelateerde contactpersoon, als die er was. Dit kan belangrijke informatie zijn om te bepalen hoeveel aanbiedingen er zijn gekomen als gevolg van eerdere contacten.
• offer_description – Een aanvullende tekstuele beschrijving van deze aanbieding.
• service_catalog_id – Een id van de service die we aan de klant hebben aangeboden. Deze id kan NULL zijn als we hem geen volledige service hebben aangeboden, maar een of meer taken die geen deel uitmaken van de service.
• service_discount – De servicekorting op het moment dat de aanbieding is gemaakt. Deze waarde bevat NULL voor het geval de aanbieding niet gerelateerd was aan de service.
• offer_price – Een definitieve prijs van dat aanbod. Het kan worden berekend als de som van alle taken minus servicekorting.
• insert_ts – Een tijdstempel dat het moment aangeeft waarop dit record in de tabel is ingevoegd.

De laatste tabel in dit onderwerpgebied is de offer_task tafel. Voor elke aanbieding, of we nu een complete service hebben aangeboden of niet, slaan we alle taken op. We moeten de volgende gegevens opslaan:

• offer_id – Een id van de gerelateerde aanbieding.
• task_catalog_id – Een id van de gerelateerde taak. Samen met de offer_id , het vormt de unieke/alternatieve sleutel van deze tabel
• task_price – Een huidige prijs van die taak op het moment dat dit record werd ingevoegd.
• insert_ts - Een tijdstempel dat het moment aangeeft waarop dit record in de tabel is ingevoegd.

Sectie 5:Bezoeken

Het laatste onderwerpgebied in ons model wordt gebruikt om werkelijke klantbezoeken aan onze reparatiewerkplaats op te slaan. Hoewel het er ingewikkeld uitziet, hebben we hier slechts 2 nieuwe tabellen, visit en visit_task .

Wanneer de klant akkoord gaat met ons aanbod of gewoon onze winkel binnenkomt, behandelen we dat als een visit . Voor elk van deze gebeurtenissen slaan we de volgende gegevens op:

• repair_shop_id – Een verwijzing naar de gerelateerde reparatiewerkplaats.
• customer_id – Een verwijzing naar de klant waar dit bezoek betrekking op heeft.
• vehicle_id – Een verwijzing naar het voertuig waaraan dit bezoek is gerelateerd.
• visit_start_date – Een startdatum van het bezoek (gepland).
• visit_start_time – Een begintijd van het bezoek (gepland).
• visit_end_date – Een startdatum van het bezoek (actueel). Deze waarde wordt ingesteld wanneer het bezoek daadwerkelijk eindigt.
• visit_end_time – Een begintijd van het bezoek (actueel). Deze waarde wordt ingesteld wanneer het bezoek daadwerkelijk eindigt.
• license_plate – Een kenteken op het moment van bezoek. Merk op dat kentekenplaten in de loop van de tijd veranderen.
• offer_id – Een id van de gerelateerde aanbieding, indien van toepassing.
• service_catalog_id – Een id van de gerelateerde service, indien aanwezig.
• service_discount – Een percentage korting op het moment dat dit record is toegevoegd en voor het geval we een complete service bieden.
• visit_price – Een totale prijs die een klant voor dat bezoek moet betalen.
• invoice_created – Een tijdstempel wanneer de factuur is gegenereerd.
• invoice_due – Een tijdstempel wanneer de factuur opeisbaar werd.
• invoice_charged – Een tijdstempel wanneer de factuur in rekening is gebracht.
• insert_ts – Een tijdstempel dat het moment aangeeft waarop dit record in de tabel is ingevoegd.

De laatste tabel in ons model is de visit_task tafel. Dit is de plek om alle taken op te slaan die daadwerkelijk deel uitmaakten van dat bezoek. Voor elk record hier slaan we de volgende waarden op:

• visit_id – Een verwijzing naar dat bezoek.
• task_catalog_id – Een verwijzing naar de gerelateerde taak
• value_measured – Een waarde die tijdens deze taak werd gemeten, als de taak meting vereiste.
• task_description – Een beschrijving met betrekking tot die taak als de taak een beschrijving vereiste.
• pass – Een vlag die aangeeft of deze taak binnen het verwachte interval viel of niet.
• task_price – Een actuele prijs van die taak op het moment ingevoegd in deze tabel.
• insert_ts – Een tijdstempel dat het moment aangeeft waarop dit record in de tabel is ingevoegd.

Hoewel dit model behoorlijk vereenvoudigd is, bevat het alle noodzakelijke elementen die je nodig hebt om er een compleet model omheen te bouwen. Onderdelen die verbeteringen behoeven, zijn zeker het gebruikte materiaal en de betalingsverwerking. Zou je nog iets aan dit model willen toevoegen?