Ein Datenmodell für die Tierpflege

Haustierpflege ist eine riesige Industrie. Gibt es ein Datenmodell, das Haustierbesitzern und Fachleuten helfen kann, ihre Aktivitäten zu verwalten? Es gibt jetzt!

Viele Menschen teilen ihr Leben mit Katzen, Hunden, Vögeln und anderen Tieren. (Ich hatte einmal eine Zeit lang eine Taube, bis ihr Flügel repariert war.) Was viele Tierbesitzer nicht wissen, ist, wie groß ein Geschäft für die Tierpflege ist. In den Vereinigten Staaten gaben Haustierbesitzer 66,75 $ Milliarden aus – und das war erst 2016!

Während die meisten von uns ihre Hamster ohne den Einsatz ausgefeilter Technologie am Leben erhalten können, gibt es viele Unternehmen, die sich auf die Pflege von Haustieren konzentrieren:Tierpensionen (auch bekannt als Tierhotels oder Tierresorts), Tierpfleger, Tiersitter (die bei Ihnen zu Hause bleiben, mit Ihren Haustier, während Sie in den Urlaub fahren), Hundeausführer, Tierverhaltensforscher, sogar Tiermasseure und Therapeuten. Diese bieten Haustieren und ihren Besitzern oft ziemlich komplexe Dienste, und sie würden ein Datenmodell benötigen, um sie zu organisieren. Schauen wir uns also einen an.

Was gehört zu einem Tierpflege-Datenmodell?

Bevor wir mit der Beschreibung der Details des Modells beginnen, lassen Sie uns einige Anforderungen besprechen:

1. Wer wird dieses Datenmodell benötigen?

   Obwohl dieses Datenmodell exotisch klingen mag, ist es gar nicht so ungewöhnlich. Stellen Sie sich vor, Sie führen eines der oben genannten Unternehmen. Unabhängig davon, wie unterschiedlich diese Geschäftsmodelle sind, müssen Sie dennoch:

   • Kommunizieren Sie mit potenziellen Kunden
   • Erläutern Sie Ihre Dienstleistungen und geben Sie deren Preise an
   • Organisieren Sie Ihren Zeitplan
   • Laufende Aufgaben und Aktivitäten nachverfolgen
   • Kunden erbrachte Dienstleistungen in Rechnung stellen

   Also ja, es besteht die Möglichkeit, dass Sie dieses Modell für sich selbst oder für Ihre Kunden benötigen.

   Jetzt können wir weitermachen und einige technische Fragen beantworten.

2. Was sollte in diesem Modell abgedeckt werden?

   Es wird allgemein genug sein, um viele verschiedene Situationen abzudecken. Ich gehe davon aus, dass wir einen physischen Ort haben, an dem wir Dienstleistungen erbringen (z. B. ein Tierhotel) oder der als Ausgangspunkt für die Erbringung von Dienstleistungen dient (z. B. für einen Hundeausführer).

   Wir müssen auch Aufzeichnungen über einzelne Haustiere und ihre Besitzer sowie Aufzeichnungen über die von uns erbrachten Dienstleistungen speichern. All dies zu erzählen, sollte die meisten Tierpflegefälle abdecken.

3. Warum ist dieses Modell wichtig?

   Lassen Sie mich zur Erklärung von einer „Prophezeiung“ erzählen, von der ich glaube, dass sie wahr werden wird.

   Wir alle wissen, wie Technologie das Geschäft verändert. Wir sehen Artikel über Jobs, die die Automatisierung in den nächsten 10 oder 20 Jahren übernehmen wird. Die meisten dieser Jobs werden wahrscheinlich solche sein, die nicht vom Kontakt mit Menschen abhängen. Beispielsweise haben viele Geschäfte jetzt Self-Checkout-Kassen, an denen ein menschlicher Mitarbeiter 5 oder 10 Kassen überwachen kann. Früher hätte jede dieser Kassen einen Kassierer gehabt. Aber in der Schlange zu stehen, um Ihre Lebensmittel zu bezahlen, ist wahrscheinlich nicht der beste Moment Ihres Tages. Außerdem ist dieser Job sehr ermüdend und unterbezahlt, sodass die Kassierer nicht wirklich begeistert sind, Sie zu sehen. Diese Art von Jobs können und werden automatisiert.

   Die anderen Jobs, die automatisiert werden, sind intellektuell anspruchsvoller, aber etwas repetitiv – z. fast alle Finanzdienstleistungen, die meisten Computerprogramme und sogar das Schreiben.

   Meine „Prophezeiung“ lautet also, dass Jobs, die viel menschlichen (oder in diesem Fall Haustier-) Kontakt erfordern, nicht nur überleben, sondern „Jobs der Zukunft“ werden; Wir sprechen von Psychologen, Friseuren, Hundefriseuren und Tiersittern usw. Aber sie brauchen einige Technologie, um ihre Geschäfte zu führen. Und hier kommt dieses Modell ins Spiel.

Das Datenmodell

Dieses Datenmodell besteht aus vier Themenbereichen:

• Pets
• Facilities & services
• Cases
• Planned & provided

Wir beginnen mit den Pets Bereich, weil Haustiere offensichtlich der wichtigste Teil dieses Geschäftsmodells sind. Danach fahren wir in der gleichen Reihenfolge fort, in der die Themenbereiche aufgelistet sind.

Abschnitt 1:Haustiere

Ich beginne mit den Pets Fachbereich; schließlich ist dieses Modell wegen unserer kleinen Freunde in ihren Pelzen und Federn hier. Ich werde es einfach halten, obwohl dieses Themengebiet erweitert werden könnte. Zum Beispiel könnten wir viele weitere Details speichern, die Haustiere, ihre Eigenschaften und die Haustierbesitzer (und ihre Eigenschaften 😊 ) beschreiben.

Die wichtigste Tabelle im gesamten Modell ist pet Tisch. Für jedes Haustier speichern wir:

• name – Der Name, den der Besitzer seinem Haustier gegeben hat.
• species_id – Verweist auf die species Wörterbuch und bezeichnet die Heimtierart.
• birth_date – Geburtsdatum des Haustiers, falls verfügbar.
• notes – Alle zusätzlichen Anmerkungen zu diesem Haustier im freien Textformat.

Im owner Tabelle speichern wir eine Liste aller unserer früheren, aktuellen und potenziellen Kunden. Ich persönlich mag das Wort „Besitzer“ nicht, denn nachdem Sie mit Ihren Haustieren zusammengelebt haben, sind sie eher wie Familienmitglieder. Aber ich kann es im Datenmodell verwenden. Daher speichern wir für jeden Eigentümer seinen first_name und last_name , Kontaktdetails (wie wir sie kennen, kennen wir sie möglicherweise nicht alle) und alle zusätzlichen Details in den notes Attribut.

Wir verknüpfen Besitzer und Haustiere mit dem pet_owner Tisch. Ein Besitzer könnte viele Haustiere haben und ein Haustier könnte ein paar Besitzer haben, also müssen wir hier eine Viele-zu-Viele-Beziehung einfügen. Für jeden Datensatz speichern wir eine EINZIGARTIGE pet_id – owner_id Paar.

Die dritte und letzte Tabelle in diesem Themenbereich ist die species Wörterbuch. Neben dem Primärschlüsselattribut id enthält er nur den EINZIGARTIGEN species_name Wert. Wir verwenden dieses Wörterbuch, um die Arteninformationen auf dem für das Unternehmen erforderlichen Niveau zu speichern. Wir könnten mit einer Reihe einfacher Werte wie „Katze“, „Hund“, „Pferd“ und „Vogel“ arbeiten. Oder wir könnten beschreibendere Werte wie „Katze – Maine Coon“, „Katze – Munchkin“ usw. verwenden. Wir könnten eine komplexere Struktur verwenden – d. h. eine Tabelle für Arten und eine andere für Rassen – aber ich denke nicht, dass dieser Ansatz wird dem Modell etwas Neues bringen.

Abschnitt 2:Einrichtungen und Dienste

Das Zweitwichtigste in diesem Modell sind die Dienstleistungen, die wir anbieten. Wir brauchen auch Einrichtungen, ganz gleich, was wir Haustierbesitzern anbieten. Dies kann ein Ort sein, z. B. ein Tierhotel, oder ein Ort, an dem wir Haustiere abholen oder abgeben (z. B. ein Hundeausführer). Wir speichern diese Informationen in den Facilities & services Fachgebiet.

Ich beginne mit dem service Tisch. Dies ist ein Wörterbuch, das wir verwenden, um eine Liste aller Dienstleistungen zu speichern, die wir unseren Kunden anbieten. Für jeden Dienst benötigen wir:

• service_name – Ein Name, der einen Dienst EINZIGARTIG definiert.
• has_limit – Ein Wert, der angibt, ob dieser Service begrenzt ist (z. B. die Anzahl der „Betten“ im Tierhotel).
• unit_id – Die Einheit, die wir verwenden, um diesen Service zu messen. Es hängt von der Art der Dienstleistung ab, die wir anbieten, und davon, ob sie Zeit oder Material (oder beides) erfordert. In den meisten Fällen werden wir uns Sorgen um die Zeit machen. Wenn beispielsweise ein Hund in einem Haustierhotel übernachtet, sollte die verwendete Einheit ein „Tag“ sein. Wenn wir dagegen mit einem Hund spazieren gehen, sollte die Einheit eine „Stunde“ oder eine „Minute“ sein. Neben Zeiteinheiten könnten wir auch andere Maße verwenden, z. wenn wir die Anzahl der Leckereien definieren wollen, die der Hund „versorgt“ bekommt.
• cost_per_unit – Die aktuellen Kosten pro Einheit für diesen Service.

Die unit Das Wörterbuch wird verwendet, um die Liste der EINZIGARTIGEN unit_name zu speichern Werte. Auf Werte aus diesem Wörterbuch wird nur im service Tabelle, aber sie sind sehr wichtig in der Planungsphase und wenn wir Kunden erbrachte Dienstleistungen in Rechnung stellen.

Für jeden Dienst müssen wir auch alle akzeptierten Arten definieren. Vielleicht bieten wir zum Beispiel einen Tierhotelservice nur für Katzen und nicht für Hunde an. Dies kann unabhängig davon der Fall sein, dass wir Gassi gehen und Pflegen anbieten. Wir speichern alle EINZIGARTIGEN service_id – speices_id Paare im available_for Tabelle.

Nachdem wir alle unsere Dienstleistungen und ihre Einzelheiten beschrieben haben, beschreiben wir nun die Einrichtungen (Orte), an denen wir diese Dienstleistungen anbieten.

Es besteht eine gute Chance, dass wir mehr als eine Einrichtung betreiben und mehr als einen Service anbieten. Aus diesem Grund müssen wir alle unsere Einrichtungen und die zugehörigen Details speichern. Wir verwenden die facility Tabelle zum Nachverfolgen von:

• facility_name – Ein Name, den wir intern verwenden, um diese Einrichtung EINZIGARTIG zu kennzeichnen.
• address , phone , email und contact_person – Standort- und Kontaktinformationen, die ziemlich selbsterklärend sind.

Für jede Einrichtung speichern wir, welche Dienstleistungen sie anbietet. Wir könnten eine Einrichtung nur für Katzen und eine andere nur für Hunde haben. Oder wir könnten einen Veterinärtechniker in einer Einrichtung haben und nicht in der anderen. In jedem Fall müssen wir alle Dienstleistungen speichern, die wir in jeder Einrichtung anbieten können. In den provides Tabelle speichern wir eine EINZIGARTIGE facility_id - service_id Paar. Für den Fall, dass service .has_limit für den referenzierten Dienst wahr ist, müssen wir auch das service_limit definieren für diese Einrichtung auch den currently_used Anzahl. Dieser Wert sollte jedes Mal neu berechnet werden, wenn wir beginnen, diesen Service für ein weiteres Haustier in dieser Einrichtung bereitzustellen (z. B. wenn ein weiterer Platz im Tierhotel belegt ist) oder wenn wir die Bereitstellung für ein Haustier einstellen (z. B. die Anzahl der verfügbaren Haustierbetten im Hotel). um eins erhöht).

Abschnitt 3:Fälle

Die Cases Im Themenbereich beschreiben und speichern wir alle Daten im Zusammenhang mit Besuchen oder Sitzungen (d. h. ein Besuch ist ein Aufenthalt in unserem Hundehotel, eine Pflege, ein Spaziergang usw.)

Der case Der Tisch speichert Haustiere und Einrichtungen im Zusammenhang mit Sitzungen, Anrufen oder Besuchen. Ich habe mich für „case“ als Namen der Tabelle entschieden, weil wir hier nicht nur Visits speichern dürfen. Vielleicht möchten wir Anrufe oder andere Kontakte speichern. Für jeden Fall speichern wir:

• facility_id – Die ID der zugehörigen Einrichtung. Das kann der Aufenthaltsort des Haustiers (in einem Hotel) oder die Einrichtung sein, die einen Anruf in Bezug auf diesen Fall erhalten hat.
• pet_id – Die ID des betreffenden Haustiers.
• start_time – Der tatsächliche Zeitstempel, als dieser Fall begonnen hat.
• end_time – Der tatsächliche Zeitstempel, als dieser Fall beendet wurde. Es ist NULL, bis der Fall geschlossen ist.
• notes – Alle zusätzlichen Anmerkungen in Textform zu diesem Fall.
• closed – Ob dieser Fall abgeschlossen ist oder nicht. Es wird auf „True“ gesetzt, wenn end_time eingestellt ist.

Wir verwenden die Kombination aus facility_id – pet_id – start_time als UNIQUE-Schlüssel dieser Tabelle.

Jedem Fall werden ein oder mehrere Status zugewiesen. Wir können davon ausgehen, dass der erste zugewiesene Status anzeigt, wann der Fall begonnen hat. Danach weisen wir nach Bedarf neue Status zu, bis der Fall gelöst (geschlossen) ist.

Das erste Wörterbuch hier ist status_category Wörterbuch. Es enthält eine Liste von UNIQUE status_category_name Werte. Dies sind Gruppierungsstatus nach Typ, z. „Körperlicher Zustand“, „Appetit“ oder „allgemeiner Zustand“.

Alle möglichen Status werden im status Wörterbuch. Für jeden Status speichern wir seinen status_name , die ID der Statuskategorie, zu der es gehört, und der is_closing_status Wert. Wenn der is_closing_status Wert „Wahr“ ist, bedeutet dies, dass der Fall als geschlossen markiert wird, wenn wir diesen Status zuweisen. Der status_name – status_category_id Paar bildet den UNIQUE-Schlüssel dieser Tabelle.

Im case_status Tabelle speichern wir alle Status, die Fällen tatsächlich zugewiesen wurden. Für jeden Datensatz in dieser Tabelle speichern wir Verweise auf den case und der status Tabellen, alle zusätzlichen notes , und die insert_time dieses Status. Wir könnten zum Beispiel die aktuelle körperliche Verfassung und den Appetit eines Haustiers als Status speichern, wenn das Haustier in unsere Einrichtung kommt. Diese Status würden geändert, wenn wir eine Änderung ihres Zustands feststellen. Andererseits speichern wir auch Statusangaben zu jedem Fall (z. B. „Hund wurde Gassi geführt“); Wir werden alle zusätzlichen Details zu diesem Status in die notes aufnehmen Attribut. Diese Status sind keine „Abschluss“-Status, da sie sich auf a) den aktuellen Status des Haustiers zu diesem Zeitpunkt oder b) auf Aktionen beziehen, die während der Sitzung oder des Besuchs durchgeführt wurden. Ein Beispiel für einen „Schließungs“-Status könnte „Hund ausgecheckt“ in unserem Tierhotel sein.

Die letzte Tabelle in diesem Abschnitt ist der note Tisch. Wir verwenden diese Tabelle, um alle Notizen zu Fällen zu speichern, in denen kein neuer Status eingefügt werden muss. Für jeden Datensatz speichern wir den note_text , eine ID des zugehörigen Falls und die insert_time wann diese Notiz erstellt wurde.

Abschnitt 4:Geplant und bereitgestellt

Der letzte Themenbereich ist der Planned & provided Fachbereich. Die drei Tabellen in diesem Themenbereich speichern Daten über geplante und tatsächlich erbrachte Dienstleistungen sowie alle Rechnungen im Zusammenhang mit Fällen.

Der service_planned Die Tabelle enthält eine Liste aller Dienstleistungen, die wir unseren Kunden vorgeschlagen oder die sie reserviert haben. Jeder Datensatz enthält Folgendes:

• case_id – Die ID des zugehörigen Falls.
• service_id – Die ID des zugehörigen Dienstes.
• planned_start_time &planned_end_time – Wann wir planen, diesen Dienst zu starten und zu beenden. Die Startzeit sollte definiert werden, aber die Endzeit kann NULL sein.
• planned_units – Anzahl geplanter Serviceeinheiten, z. 3 Tage im Tierhotel.
• cost_per_unit – Die damaligen Kosten pro Einheit. Es ist wichtig, diesen Wert zu speichern, da der in service gespeicherte Wert .cost_per_unit können sich zwischen dem Zeitpunkt der Reservierung und dem Zeitpunkt der Durchführung ändern.
• planned_price – Der für diese Dienstleistung angegebene Preis. Dies sollte gleich planned_units sein * cost_per_unit .
• notes – Eventuelle zusätzliche Hinweise zum geplanten Dienst.

Der service_provided Die Tabelle hat fast die gleiche Struktur wie service_planned Tisch. Der einzige Unterschied besteht darin, dass die units und price_charged Attribute können NULL-Werte enthalten. Dies liegt daran, dass wir einen Datensatz in diese Tabelle einfügen können, wenn wir mit der Erbringung der Dienstleistung beginnen (z. B. wenn das Haustier das Tierhotel betritt), und wir aktualisieren sie, wenn wir die Erbringung der Dienstleistung einstellen (z. B. wenn der Besitzer die Tierheim).

Die letzte Tabelle in unserem Modell ist die invoice Tisch. Es enthält eine Liste aller Rechnungen, die wir für alle unsere Fälle erstellt haben. Für jede Rechnung speichern wir:

• invoice_code – Eine interne EINZIGARTIGE Nummer, die für jede Rechnung generiert wird.
• case_id – Die ID des zugehörigen Falls.
• time_generated – Wann die Rechnung erstellt wurde.
• invoice_amount – Der ursprüngliche Betrag, den wir dem Kunden in Rechnung stellen. Dieser Betrag sollte gleich der Summe aller Werte in price_charged sein für service_provided .
• discount – Ein Rabatt, der dem Kunden gewährt wird (z. B. aufgrund eines Gutscheins, einer Treuekarte usw. Der Grund spielt keine Rolle.)
• time_charged – Wenn dem Kunden diese Rechnung tatsächlich in Rechnung gestellt wurde. Dieses Attribut enthält einen NULL-Wert, bis die Zahlung erfolgt ist.
• amount_charged – Der tatsächliche Betrag, der dem Kunden für diese Rechnung in Rechnung gestellt wurde.
• notes – Alle zusätzlichen Anmerkungen zu dieser Rechnung.

Was würden Sie hinzufügen?

Heute haben wir über ein mögliches Datenmodell für ein Heimtiergeschäft gesprochen. Dieses Modell deckt die grundlegenden Funktionalitäten ab, aber es gibt Raum für Verbesserungen. Bitte teilen Sie uns Ihre Vorschläge im Kommentarbereich mit. Danke!