Datenmodell für Kfz-Werkstätten

Das Betreiben einer Autowerkstatt ist ein sehr komplexes Geschäft. Sie müssen Termine vereinbaren, während einige Kunden vorbeifahren, und Sie möchten nicht, dass sie stundenlang warten. Außerdem müssen Sie Mitarbeiter organisieren, Reparaturen, Materialien verfolgen, Kunden abrechnen usw. Sie benötigen auf jeden Fall eine IT-Lösung und natürlich ein Datenmodell im Hintergrund. Heute sprechen wir über ein solches Modell.

Die Idee

Ich habe bereits erwähnt, dass dieses Geschäftsmodell sehr komplex ist. Daher werde ich nicht versuchen, alles abzudecken. Ich habe bewusst auf Nachverfolgungsmaterialien und Ersatzteile verzichtet und auch einige Teile des Modells vereinfacht. Der Grund dafür ist ziemlich einfach. Wenn ich wirklich alles aufgenommen habe, wäre das Modell einfach zu groß für einen Artikel der angemessenen Größe. Fangen wir also an.

Datenmodell

Das Modell besteht aus 5 Themenbereichen:

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

Wir beschreiben jeden dieser 5 Themenbereiche in der Reihenfolge, in der sie aufgelistet wurden.

Abschnitt 1:Werkstätten &Mitarbeiter

Der erste Themenbereich, mit dem wir beginnen, ist die Repair shops & employees Fachbereich. Es ist ziemlich offensichtlich, dass wir wissen müssen, was wir zur Verfügung haben, bevor wir Kunden Angebote machen können.

Die city Wörterbuch wird verwendet, um alle verschiedenen Städte zu speichern, in denen wir Werkstätten haben oder aus denen unsere Kunden kommen. Jede Stadt wird durch das Paar postal_code eindeutig definiert – city_name . Wir könnten entscheiden, nur einen Eintrag pro Stadt zu haben, selbst wenn diese Stadt mehrere Postleitzahlen hat. In diesem Fall würden wir nur die „Haupt“-Postleitzahl für diese Stadt verwenden. Dennoch haben wir die Möglichkeit, mehrere Einträge für dieselbe Stadt und unterschiedliche Postleitzahlen zu haben – falls wir das möchten.

Der repair_shop Tabelle ist der Ort, an dem wir eine Liste aller unserer Reparaturwerkstätten speichern. Wir können davon ausgehen, dass wir irgendwann mehr als eine betreiben werden. Jeder Shop ist durch seinen shop_name eindeutig definiert und die ID der Stadt, zu der sie gehört (city_id ). Wir speichern auch die Adresse des Shops und weitere details im Textformat, falls vorhanden.

Die position Dictionary wird verwendet, um eindeutige position_names zu speichern die unseren Mitarbeitern zugeordnet werden konnten. Während sich die meisten Positionen auf unser Kerngeschäft beziehen, werden wir auch einige haben, die nicht Teil des Kerngeschäfts sind (technische Rollen/Positionen), aber auch wesentlich sind (Verwaltung, Verkauf usw.).

Eine Liste aller unserer Mitarbeiter ist im employee Tisch. Für jeden Mitarbeiter speichern wir seine:

• first_name &last_name – Vor- und Nachname des Mitarbeiters.
• employment_start_date &employment_end_date – Eintritts- und Enddatum des Mitarbeiters im Unternehmen. Das Enddatum muss einen NULL-Wert enthalten, bis wir es definieren können.
• position_id – Ein Hinweis auf die aktuelle Position im Unternehmen.
• city_id – Ein Hinweis auf die Stadt, in der der Mitarbeiter derzeit lebt.
• is_active – Ein Flag, das angibt, ob der Mitarbeiter derzeit aktiv ist oder nicht.

Die letzte Tabelle in diesem Themenbereich ist der schedule Tisch. In dieser Tabelle speichern wir genaue Zeitpläne für alle unsere Mitarbeiter auf Tagesebene. Wir haben auch die Möglichkeit, mehrere Intervalle für denselben Mitarbeiter am selben Tag zu speichern. Um dies zu erreichen, verwenden wir die folgenden Attribute:

• repair_shop_id – Ein Hinweis auf die zuständige Werkstatt.
• employee_id – Ein Verweis auf den betreffenden Mitarbeiter.
• position_id – Ein Bezug auf die entsprechende Position, die der Mitarbeiter im definierten Zeitraum haben würde. In den meisten Fällen wäre dies seine aktuelle Position, aber wir haben die Flexibilität, hier eine andere Position zuzuweisen.
• schedule_date – Ein Datum, auf das sich dieser Eintrag bezieht.
• time_from &time_to – Dieses Paar definiert den Zeitraum, auf den sich dieser Eintrag bezieht.
• plan – Ein Flag, das angibt, ob dies ein geplanter Eintrag war. Ein Eintrag ist nur dann nicht geplant, wenn wir ihn ad hoc eingefügt haben.
• actual – Dieses Flag zeigt an, ob dieser Eintrag realisiert wurde. Beachten Sie, dass in den meisten Fällen beide Flags, Plan und Ist, auf True gesetzt würden. Dies würde darauf hinweisen, dass wir diesen Plan geplant und tatsächlich umgesetzt haben.
• insert_ts – Ein Zeitstempel, der den Zeitpunkt angibt, an dem dieser Datensatz in die Tabelle eingefügt wurde.

Die Kombination repair_shop_id - employee_id - schedule_date - time_from bildet den EINZIGARTIGEN/alternativen Schlüssel dieser Tabelle. Bevor wir einen neuen Datensatz einfügen, sollten wir auch das neue Intervall time_from überprüfen – time_to sich nicht mit einem bestehenden Intervall für denselben Mitarbeiter und dasselbe Datum überschneidet.

Abschnitt 2:Kunden &Kontakte

Jetzt können wir zum kundenbezogenen Teil des Modells übergehen.

Wir speichern alle Kunden, mit denen wir zuvor zusammengearbeitet haben oder mit denen wir Kontakt hatten, im customer Tisch. Für jeden Kunden speichern wir:

• first_name &last_name – Vor- und Nachname des Kunden, falls unser Kunde eine Privatperson ist.
• company_name – Ein Firmenname, in einem Fall ist der Kunde ein Unternehmen und keine Privatperson.
• address – Die Adresse des Kunden.
• mobile – Die Handynummer des Kunden.
• email – Die E-Mail des Kunden
• details – Alle zusätzlichen Kundendetails, falls vorhanden, im Textformat.
• insert_ts – Ein Zeitstempel, der den Zeitpunkt angibt, an dem dieser Datensatz in die Tabelle eingefügt wurde.

Die meisten Attribute in dieser Tabelle sind nullable, da wir einige davon wahrscheinlich nicht haben werden und einige (first_name &last_name vs. company_name ) andere ausschließen.

Wir müssen alle Kontakte verfolgen, die wir mit jedem Kunden gemacht haben. Dazu verwenden wir zwei Tabellen. Der erste, der contact_type Tabelle, ist ein einfaches Wörterbuch, das nur den EINZIGARTIGEN type_name enthält Wert.

Echte Kontaktdaten werden im contact Tisch. Wir speichern Verweise auf die Art dieses Kontakts (contact_type_id ), ein Kunde, mit dem wir Kontakt hatten (customer_id ), ein Mitarbeiter, der diesen Kontakt hergestellt hat (schedule_id ) und auch Kontaktdaten und den Zeitpunkt speichern, zu dem dieser Datensatz in die Tabelle eingefügt wurde (insert_ts ).

Abschnitt 3:Fahrzeuge

Nachdem wir unsere Ressourcen und Kunden kennen, müssen wir Fahrzeuge lagern, mit denen wir arbeiten werden. Neben der Verfolgung von Daten und der Erstellung interner Berichte müssen wir in den meisten Ländern auch Berichte für Aufsichtsbehörden, Versicherungsunternehmen und die Polizei erstellen.

Zuerst definieren wir Modelle unserer Fahrzeuge. Wir werden 3 Tabellen verwenden, um dies zu erreichen. Im make Wörterbuch werden wir eindeutige make_names auflisten für alle Auto-/Fahrzeughersteller/Marken. Außerdem müssen wir die Fahrzeugtypen kennen, also verwenden wir ein weiteres Wörterbuch mit nur einem eindeutigen Wertattribut – type_name . Das 3 verwendete Wörterbuch ist das model Wörterbuch. Dieses soll die Liste aller Modelle enthalten, die durch unsere Türen gekommen sind. Für jedes Modell definieren wir die eindeutige Kombination model_name – make_id – vechicle_type_id .

Wir werden dieses Themengebiet mit dem vehicle Tisch. Dies ist die einzige Tabelle in diesem Themenbereich, die „echte“ Daten enthält. Wir verwenden diese Tabelle, um die folgenden Details zu speichern:

• vin – Eine Fahrzeugidentifikationsnummer, die dieses Fahrzeug eindeutig definiert.
• license_plate – Ein aktuelles Kennzeichen.
• customer_id – Ein Hinweis auf den Kunden, dem dieses Fahrzeug gehört. Falls das Fahrzeug den Besitzer wechselt, fügen wir es als neuen Datensatz ein, wissen aber anhand der Seriennummer, dass es sich um dasselbe Fahrzeug handelt.
• model_id – Ein Verweis auf das Modellwörterbuch.
• manufactured_year &manufactured_month – Geben Sie das Jahr und den Monat an, in dem dieses Fahrzeug hergestellt wurde.
• details – Alle weiteren Angaben im Textformat.
• insert_ts – Ein Zeitstempel, der den Zeitpunkt angibt, an dem dieser Datensatz in die Tabelle eingefügt wurde.

Abschnitt 4:Leistungen &Angebote

Wir sind bereit für den nächsten großen Schritt. Wir müssen definieren, was wir unseren (potenziellen) Kunden anbieten. Dies können einzelne Aufgaben oder eine Reihe von Aufgaben sein – Dienste.

Die Liste aller Dienste wird im service_catalog Wörterbuch. Jeder Dienst besteht aus einigen Aufgaben und wird eindeutig durch seinen service_name definiert . Neben dem Namen speichern wir auch eine Beschreibung, falls vorhanden, den Prozentsatz von service_discount und der is_active Flagge. Der Servicerabatt wird für alle in diesem Service enthaltenen Aufgaben verwendet.

Als Nächstes definieren wir Aufgaben. Aufgaben sind Teil unserer Dienstleistungen. Sie sind die grundlegende Aktion, die eigenständig durchgeführt werden könnte. Jede Aufgabe wird durch diese Werte im task_catalog Tabelle:

• task_name &service_catalog_id – Ein Name, den wir verwenden, um diese Aufgabe und den Dienst, zu dem sie gehört, zu beschreiben. Dieses Attributpaar bildet den eindeutigen Schlüssel der Tabelle.
• description – Die zusätzliche Textbeschreibung, falls vorhanden, die zur Beschreibung dieser Aufgabe verwendet wurde.
• ref_interval – Ein Flag, das angibt, ob wir das Intervall für diese Aufgabe messen.
• ref_interval_min &ref_interval_max – Die minimale und die maximale Grenze des Referenzbereichs.
• describe – Ein Flag, das angibt, ob wir einen Textkommentar für diese Aufgabe hinzufügen sollen.
• task_price – Ein aktueller Preis ohne Servicerabatte für diese Aufgabe.
• is_active – Ein Flag, das angibt, ob die Aufgabe derzeit aktiv ist (in unserem Angebot) oder nicht.

Nach dem Kontakt mit den Kunden machen wir ihnen Angebote. Das Angebot kann eine komplette Dienstleistung mit all ihren Aufgaben oder eine Reihe von Aufgaben sein. Alle Angebote sind im offer Tisch. Für jedes Angebot speichern wir:

• customer_id – Eine ID des zugehörigen Kunden.
• contact_id – Eine ID des zugehörigen Kontakts, falls vorhanden. Dies könnte eine wichtige Information sein, um festzustellen, wie viele Angebote aufgrund früherer Kontakte eingegangen sind.
• offer_description – Eine zusätzliche textliche Beschreibung dieses Angebots.
• service_catalog_id – Eine ID des Dienstes, den wir dem Kunden angeboten haben. Diese ID könnte NULL sein, falls wir ihm keinen kompletten Service angeboten haben, sondern eine oder mehrere Aufgaben, die nicht Teil des Service sind.
• service_discount – Das Servicerabatt im Moment Angebot wurde erstellt. Dieser Wert muss NULL enthalten, falls sich das Angebot nicht auf den Dienst bezieht.
• offer_price – Ein Endpreis dieses Angebots. Er könnte als Summe aller Aufgaben minus Servicerabatt berechnet werden.
• insert_ts – Ein Zeitstempel, der den Zeitpunkt angibt, an dem dieser Datensatz in die Tabelle eingefügt wurde.

Die letzte Tabelle in diesem Themenbereich ist offer_task Tisch. Für jedes Angebot, egal ob wir eine Komplettleistung angeboten haben oder nicht, speichern wir das Set aller Aufgaben. Wir müssen die folgenden Details speichern:

• offer_id – Eine ID des zugehörigen Angebots.
• task_catalog_id – Eine ID der zugehörigen Aufgabe. Zusammen mit der offer_id , es bildet den eindeutigen/alternativen Schlüssel dieser Tabelle
• task_price – Ein aktueller Preis dieser Aufgabe zum Zeitpunkt der Eingabe dieses Datensatzes.
• insert_ts - Ein Zeitstempel, der den Zeitpunkt angibt, an dem dieser Datensatz in die Tabelle eingefügt wurde.

Abschnitt 5:Besuche

Der letzte Themenbereich in unserem Modell dient dazu, tatsächliche Kundenbesuche in unserer Werkstatt zu speichern. Obwohl es kompliziert aussieht, haben wir hier nur 2 neue Tabellen, visit und visit_task .

Wenn der Kunde unserem Angebot zustimmt oder einfach nur in unser Geschäft kommt, behandeln wir das als visit . Für jedes derartige Ereignis speichern wir die folgenden Details:

• repair_shop_id – Ein Hinweis auf die zuständige Werkstatt.
• customer_id – Ein Verweis auf den Kunden, auf den sich dieser Besuch bezieht.
• vehicle_id – Ein Verweis auf das Fahrzeug, auf das sich dieser Besuch bezieht.
• visit_start_date – Ein Besuchsstartdatum (geplant).
• visit_start_time – Eine Besuchsstartzeit (geplant).
• visit_end_date – Ein Besuchsstartdatum (tatsächlich). Dieser Wert wird gesetzt, wenn der Besuch tatsächlich endet.
• visit_end_time – Eine Besuchsstartzeit (tatsächlich). Dieser Wert wird gesetzt, wenn der Besuch tatsächlich endet.
• license_plate – Ein Kennzeichen im Moment des Besuchs passiert. Beachten Sie, dass sich die Nummernschilder im Laufe der Zeit ändern.
• offer_id – Eine ID des zugehörigen Angebots, falls vorhanden.
• service_catalog_id – Eine ID des zugehörigen Dienstes, falls vorhanden.
• service_discount – Ein prozentualer Rabatt in dem Moment, in dem dieser Eintrag hinzugefügt wurde und falls wir einen kompletten Service anbieten.
• visit_price – Ein Gesamtpreis, den ein Kunde für diesen Besuch zahlen sollte.
• invoice_created – Ein Zeitstempel, wann die Rechnung erstellt wurde.
• invoice_due – Ein Zeitstempel, wann die Rechnung fällig wurde.
• invoice_charged – Ein Zeitstempel, wann die Rechnung belastet wurde.
• insert_ts – Ein Zeitstempel, der den Zeitpunkt angibt, an dem dieser Datensatz in die Tabelle eingefügt wurde.

Die letzte Tabelle in unserem Modell ist visit_task Tisch. Hier werden alle Aufgaben gespeichert, die tatsächlich Teil dieses Besuchs waren. Für jeden Datensatz hier speichern wir die folgenden Werte:

• visit_id – Ein Hinweis auf diesen Besuch.
• task_catalog_id – Ein Verweis auf die zugehörige Aufgabe
• value_measured – Ein Wert, der während dieser Aufgabe gemessen wurde, falls die Aufgabe eine Messung erforderte.
• task_description – Eine Beschreibung zu dieser Aufgabe, falls die Aufgabe eine Beschreibung erforderte.
• pass – Ein Flag, das angibt, ob diese Aufgabe im erwarteten Intervall war oder nicht.
• task_price – Ein aktueller Preis für diese Aufgabe, der in diese Tabelle eingefügt wird.
• insert_ts – Ein Zeitstempel, der den Zeitpunkt angibt, an dem dieser Datensatz in die Tabelle eingefügt wurde.

Obwohl dieses Modell ziemlich vereinfacht ist, enthält es alle notwendigen Elemente, die Sie benötigen, um ein vollständiges Modell darum herum zu erstellen. Teile, die Verbesserungen erfordern, sind definitiv das verwendete Material und die Zahlungsabwicklung. Würden Sie diesem Modell noch etwas hinzufügen?