Model danych dotyczących opieki nad zwierzętami

Opieka nad zwierzętami to ogromna branża. Czy istnieje model danych, który może pomóc właścicielom zwierząt domowych i profesjonalistom zarządzać ich działalnością? Jest teraz!

Wiele osób dzieli swoje życie z kotami, psami, ptakami i innymi zwierzętami. (Kiedyś przez jakiś czas miałem gołębia, dopóki jego skrzydło nie zreperowało.) Wielu właścicieli zwierząt nie zdaje sobie sprawy, jak duża jest opieka nad zwierzakiem w biznesie. W Stanach Zjednoczonych właściciele zwierząt wydali 66,75 miliardów $ – i to było dopiero w 2016 roku!

Podczas gdy większość z nas może utrzymać nasze chomiki przy życiu bez korzystania z zaawansowanych technologii, istnieje wiele firm, które koncentrują się na opiece nad zwierzętami:hodowle zwierząt domowych (tzw. hotele dla zwierząt lub ośrodki dla zwierząt domowych), fryzjerzy, opiekunowie zwierząt domowych (którzy przebywają w twoim domu, ze swoimi zwierzaka, gdy jedziesz na wakacje), spacerowicze, behawioryści zwierząt domowych, a nawet masażyści i terapeuci zwierząt domowych. Często zapewniają one zwierzętom domowym i ich właścicielom dość złożone usługi, a do ich uporządkowania potrzebowaliby modelu danych. Przyjrzyjmy się więc jednemu.

Co wchodzi w skład modelu danych dotyczących opieki nad zwierzętami?

Zanim zaczniemy opisywać szczegóły modelu, omówmy kilka wymagań:

Kto będzie potrzebował tego modelu danych?

Chociaż ten model danych może brzmieć egzotycznie, nie jest to aż tak niezwykłe. Wyobraź sobie, że prowadzisz którykolwiek z wyżej wymienionych biznesów. Bez względu na to, jak różne są te modele biznesowe, nadal musisz:
- Komunikuj się z potencjalnymi klientami
- Wyjaśnij swoje usługi i podaj ich ceny
- Uporządkuj swój harmonogram
- Śledź zadania i działania w toku
- Obciążaj klientów za świadczone usługi
Więc tak, jest szansa, że będziesz potrzebować tego modelu dla siebie lub dla swoich klientów.

Teraz możemy przejść dalej i odpowiedzieć na kilka pytań technicznych.
Co powinno być objęte tym modelem?

Będzie wystarczająco ogólny, aby objąć wiele różnych sytuacji. Wychodzę z założenia, że będziemy mieli fizyczne miejsce, w którym będziemy świadczyć usługi (jak hotel dla zwierząt) lub które służy jako punkt wyjścia do świadczenia usług (np. dla wyprowadzacza psów).

Będziemy również musieli przechowywać rejestry dotyczące poszczególnych zwierząt domowych i ich właścicieli, a także rejestry świadczonych przez nas usług. Wszystko to powinno obejmować większość przypadków związanych z opieką nad zwierzętami.
Dlaczego ten model jest ważny?

Aby to wyjaśnić, powiem ci o „proroctwie”, które moim zdaniem się spełni.

Wszyscy wiemy, jak technologia zmienia biznes. Widzimy artykuły o zawodach, które automatyzacja przejmie w ciągu najbliższych 10 czy 20 lat. Większość z tych prac będzie prawdopodobnie tymi, które nie zależą od kontaktu z ludźmi. Na przykład wiele sklepów ma teraz pasy samoobsługowe, w których jeden pracownik może monitorować 5 lub 10 kas. Wcześniej każda z tych kas miała kasjera. Ale czekanie w kolejce, aby zapłacić za zakupy spożywcze, prawdopodobnie nie jest najlepszym momentem twojego dnia. A ta praca jest również bardzo męcząca i słabo płatna, więc kasjerzy nie są podekscytowani tym, że cię zobaczą. Tego rodzaju zadania mogą i są zautomatyzowane.

Inny zestaw zadań, które zostaną zautomatyzowane, są trudniejsze intelektualnie, ale nieco powtarzalne – np. prawie wszystkie usługi finansowe, większość programów komputerowych, a nawet pisanie.

Tak więc moje „proroctwo” jest takie, że prace wymagające wielu kontaktów z ludźmi (lub w tym przypadku ze zwierzętami domowymi) nie tylko przetrwają, ale staną się „pracami przyszłości”; mówimy o psychologach, stylistach fryzur, psich fryzjerach, opiekunach zwierząt domowych itp. Ale będą potrzebować technologii, aby prowadzić swoją działalność. I tu właśnie pojawia się ten model.

Model danych

Ten model danych składa się z czterech obszarów tematycznych:

Pets
Facilities & services
Cases
Planned & provided

Zaczniemy od Pets obszar, ponieważ zwierzęta są oczywiście najważniejszą częścią tego modelu biznesowego. Następnie będziemy kontynuować w tej samej kolejności, w jakiej wymienione są obszary tematyczne.

Sekcja 1:Zwierzęta

Zacznę od Pets Tematyka; w końcu ten model jest tutaj dzięki naszym małym przyjaciołom ubranym w swoje futra i pióra. Powiem to prosto, chociaż ten obszar tematyczny można by rozszerzyć. Na przykład, moglibyśmy przechowywać o wiele więcej szczegółów opisujących zwierzęta, ich cechy oraz właścicieli zwierząt (i ich cechy 😊).

Najważniejszą tabelą w całym modelu jest pet stół. Dla każdego zwierzaka przechowujemy:

name – Imię, które właściciel nadał swojemu zwierzakowi.
species_id – Odwołuje się do species słownika i oznacza gatunek zwierząt domowych.
birth_date – Data urodzenia zwierzaka, jeśli jest dostępna.
notes – Wszystkie dodatkowe notatki związane z tym zwierzakiem, w dowolnym formacie tekstowym.

W owner tabeli, przechowamy listę wszystkich naszych przeszłych, obecnych i potencjalnych klientów. Osobiście nie lubię słowa „właściciel”, ponieważ po zamieszkaniu ze swoimi zwierzakami są bardziej jak członkowie rodziny. Ale mogę go użyć w modelu danych. Tak więc dla każdego właściciela będziemy przechowywać jego first_name i last_name , dane kontaktowe (ponieważ je znamy, możemy nie znać ich wszystkich) oraz wszelkie dodatkowe szczegóły w notes atrybut.

Powiążemy właścicieli i zwierzęta za pomocą pet_owner stół. Jeden właściciel może mieć wiele zwierzaków, a jeden zwierzak może mieć kilku właścicieli, więc musimy wstawić tutaj relację wiele-do-wielu. Dla każdego rekordu przechowujemy UNIKALNY pet_id – owner_id parować.

Trzecia i ostatnia tabela w tym obszarze tematycznym to species słownik. Oprócz głównego atrybutu klucza id , zawiera tylko UNIKALNĄ species_name wartość. Użyjemy tego słownika do przechowywania informacji o gatunkach na poziomie wymaganym przez firmę. Moglibyśmy użyć zestawu prostych wartości, takich jak „kot”, „pies”, „koń” i „ptak”. Albo moglibyśmy użyć bardziej opisowych wartości, takich jak „kot – Maine Coon”, „kot – Munchkin” itp. Moglibyśmy zastosować bardziej złożoną strukturę – tj. mieć jedną tabelę dla gatunków, a drugą dla ras – ale nie sądzę, aby to podejście wniesie coś nowego do modelu.

Sekcja 2:Obiekty i usługi

Drugą najważniejszą rzeczą w tym modelu są usługi, które będziemy świadczyć. Będziemy też potrzebować udogodnień, bez względu na to, co oferujemy właścicielom zwierząt. Może to być jedno miejsce, takie jak hotel dla zwierząt, lub może to być miejsce, w którym odbieramy lub wywozimy zwierzęta (takie, jak używałby wyprowadzacz psów). Będziemy przechowywać te informacje w Facilities & services obszar tematyczny.

Zacznę od service stół. Jest to słownik, którego użyjemy do przechowywania listy wszystkich usług, które oferujemy naszym klientom. Dla każdej usługi potrzebujemy:

service_name – Nazwa, która WYJĄTKOWO definiuje usługę.
has_limit – Wartość określająca, czy ta usługa ma limit (np. liczbę „łóżek” w hotelu dla zwierząt).
unit_id – Jednostka, której użyjemy do pomiaru tej usługi. Zależy to od rodzaju świadczonej przez nas usługi oraz tego, czy wymaga ona czasu lub materiału (lub obu). W większości przypadków będziemy się martwić o czas. Na przykład, jeśli pies przebywa w hotelu dla zwierząt, używaną jednostką powinien być „dzień”. Z drugiej strony, jeśli wyprowadzamy psa, to jednostką powinna być „godzina” lub „minuta”. Poza jednostkami czasu moglibyśmy wykorzystać także inne miary, np. jeśli chcemy określić liczbę smakołyków, które pies będzie „dostarczony”.
cost_per_unit – Aktualny koszt jednostkowy tej usługi.

unit słownik służy do przechowywania listy UNIKATOWYCH unit_name wartości. Wartości z tego słownika są przywoływane tylko w service tabeli, ale są one bardzo ważne w fazie planowania i gdy pobieramy od klientów opłaty za świadczone usługi.

W przypadku każdej usługi musimy również zdefiniować każdy akceptowany gatunek. Na przykład, może będziemy świadczyć usługi hotelarskie tylko dla kotów, a nie dla psów. Może tak być niezależnie od tego, że oferujemy wyprowadzanie i pielęgnację psa. Przechowamy wszystkie UNIKALNE service_id – speices_id pary w available_for tabela.

Po opisie wszystkich naszych usług i ich szczegółów, teraz opiszemy obiekty (miejsca), w których będziemy świadczyć te usługi.

Istnieje duża szansa, że będziemy obsługiwać więcej niż jeden obiekt i świadczyć więcej niż jedną usługę. Z tego powodu będziemy musieli przechowywać wszystkie nasze obiekty i związane z nimi szczegóły. Skorzystamy z facility tabela do śledzenia:

facility_name – Nazwa, której będziemy używać wewnętrznie, aby WYJĄTKOWO oznaczyć tę funkcję.
address , phone , email i contact_person – Informacje o lokalizacji i kontaktach, które są w zasadzie oczywiste.

Dla każdego obiektu zapiszemy, jakie usługi świadczy. Moglibyśmy mieć jeden obiekt tylko dla kotów, a drugi tylko dla psów. Albo moglibyśmy mieć technika weterynarii w jednej placówce, a nie w drugiej. W każdym razie będziemy musieli przechowywać wszystkie usługi, które jesteśmy w stanie świadczyć w każdym obiekcie. W provides tabeli, przechowamy UNIKALNY facility_id - service_id para. W przypadku, gdy service .has_limit ponieważ przywoływana usługa jest prawdziwa, musimy również zdefiniować service_limit dla tego obiektu oraz currently_used Ilość. Wartość ta powinna być przeliczana za każdym razem, gdy zaczynamy świadczyć tę usługę dla jeszcze jednego zwierzaka w tym obiekcie (np. zajęte jest jeszcze jedno miejsce w hotelu dla zwierząt) lub przestajemy ją świadczyć pupilowi (np. ilość wolnych miejsc w hotelu). wzrosła o jeden).

Sekcja 3:Sprawy

Cases obszar tematyczny to miejsce, w którym opisujemy i przechowujemy wszystkie dane związane z wizytami lub sesjami (tj. jedna wizyta to jeden pobyt w naszym hotelu dla psów, jedna pielęgnacja, jeden spacer itp.)

case na stół przechowuje zwierzęta domowe i obiekty związane z sesjami, telefonami lub wizytami. Zdecydowałem się użyć słowa „case” jako nazwy tabeli, ponieważ nie możemy tutaj przechowywać tylko wizyt. Może chcemy przechowywać połączenia lub inne kontakty. W każdym przypadku przechowujemy:

facility_id – Identyfikator powiązanego obiektu. Może to być miejsce, w którym przebywało zwierzę (w hotelu) lub placówka, do której zadzwoniono w związku z tą sprawą.
pet_id – Identyfikator zwierzęcia, którego dotyczy sprawa.
start_time – Faktyczny znacznik czasu, kiedy ta sprawa się rozpoczęła.
end_time – Faktyczny znacznik czasu zakończenia sprawy. Będzie NULL do czasu zamknięcia sprawy.
notes – Wszelkie dodatkowe uwagi w formacie tekstowym związane z tą sprawą.
closed – Czy ta sprawa jest zamknięta, czy nie. Zostanie ustawiony na „True”, gdy end_time jest ustawiony.

Użyjemy kombinacji facility_id – pet_id – start_time jako UNIKATOWY klucz tej tabeli.

Każda sprawa będzie miała przypisany jeden lub więcej statusów. Możemy się spodziewać, że pierwszy przypisany status wskaże, kiedy sprawa się rozpoczęła. Następnie w razie potrzeby przypiszemy nowe statusy, dopóki sprawa nie zostanie rozwiązana (zamknięta).

Pierwszym słownikiem tutaj jest status_category słownik. Zawiera listę UNIKALNYCH status_category_name wartości. Są to statusy grupowe według typu, np. „status fizyczny”, „apetyt” lub „stan ogólny”.

Wszystkie możliwe statusy są przechowywane w status słownik. Dla każdego statusu przechowujemy jego status_name , identyfikator kategorii statusu, do której należy, oraz is_closing_status wartość. Jeśli is_closing_status wartość to „True”, oznacza to, że gdy nadamy ten status, sprawa zostanie oznaczona jako zamknięta. status_name – status_category_id para tworzy UNIKALNY klucz tej tabeli.

W case_status tabeli, będziemy przechowywać wszystkie statusy, które faktycznie zostały przypisane do spraw. Dla każdego rekordu w tej tabeli będziemy przechowywać odniesienia do case i status tabele, wszelkie dodatkowe notes i insert_time tego statusu. Moglibyśmy, na przykład, przechowywać aktualny stan fizyczny i apetyt zwierzaka jako statusy, gdy zwierzę przychodzi do naszego obiektu. Te statusy uległyby zmianie, gdybyśmy zauważyli zmianę ich stanu. Z drugiej strony będziemy również przechowywać statusy dotyczące każdego przypadku (np. „pies był wyprowadzany”); wszelkie dodatkowe szczegóły dotyczące tego statusu umieścimy w notes atrybut. Te statusy nie będą statusami „zamykającymi”, ponieważ są związane z a) aktualnym statusem zwierzaka w danym momencie lub b) z działaniami podejmowanymi podczas sesji lub wizyty. Przykładem statusu „zamknięcia” może być „wymeldowanie psa” z naszego hotelu dla zwierząt.

Ostatnia tabela w tej sekcji to note stół. Użyjemy tej tabeli do przechowywania wszystkich notatek związanych ze sprawami, w których nie ma potrzeby wstawiania nowego statusu. Dla każdego rekordu przechowamy note_text , identyfikator powiązanej sprawy i insert_time kiedy ta notatka została utworzona.

Sekcja 4:Planowane i dostarczane

Ostatnim obszarem tematycznym jest Planned & provided Tematyka. Trzy tabele w tym obszarze tematycznym przechowują dane o usługach, które planowaliśmy świadczyć, faktycznie świadczonych i wszystkich fakturach związanych ze sprawami.

service_planned tabela zawiera listę wszystkich usług, które zaproponowaliśmy naszym klientom lub które zarezerwowali. Każdy rekord będzie zawierał:

case_id – Identyfikator powiązanej sprawy.
service_id – Identyfikator powiązanej usługi.
planned_start_time &planned_end_time – Kiedy planujemy rozpocząć i zakończyć tę usługę. Czas rozpoczęcia powinien być zdefiniowany, ale czas zakończenia może być NULL.
planned_units – Liczba planowanych jednostek serwisowych, m.in. 3 dni w hotelu dla zwierząt.
cost_per_unit – Koszt jednostkowy w tamtym czasie. Przechowywanie tej wartości jest ważne, ponieważ wartość przechowywana w service .cost_per_unit może się zmienić między momentem dokonania rezerwacji a jej wykonaniem.
planned_price – Cena podana za tę usługę. Powinno to być równe planned_units * cost_per_unit .
notes – Wszelkie dodatkowe uwagi związane z planowaną usługą.

service_provided tabela ma prawie taką samą strukturę jak service_planned stół. Jedyna różnica polega na tym, że units i price_charged atrybuty mogą zawierać wartości NULL. Wynika to z faktu, że wpis w tej tabeli możemy wstawić, gdy zaczniemy świadczyć usługę (np. gdy zwierzę wejdzie do hotelu dla zwierząt) i zaktualizujemy je, gdy przestaniemy świadczyć usługę (np. gdy właściciel skorzysta z usługi). dom dla zwierząt).

Ostatnia tabela w naszym modelu to invoice stół. Zawiera listę wszystkich faktur, które wygenerowaliśmy dla wszystkich naszych spraw. Dla każdej faktury przechowujemy:

invoice_code – Wewnętrzny UNIKALNY numer generowany dla każdej faktury.
case_id – Identyfikator powiązanej sprawy.
time_generated – Kiedy wygenerowano fakturę.
invoice_amount – Pierwotna kwota, którą obciążamy klienta. Ta kwota powinna być równa sumie wszystkich wartości w price_charged dla service_provided .
discount – Rabat udzielony klientowi (np. z powodu kuponu, karty lojalnościowej itp. Powód nie ma znaczenia.)
time_charged – Kiedy klient faktycznie został obciążony tą fakturą. Ten atrybut będzie zawierał wartość NULL do momentu dokonania płatności.
amount_charged – Rzeczywista kwota, która została obciążona klientem za tę fakturę.
notes – Wszelkie dodatkowe uwagi związane z tą fakturą.

Co byś dodał?

Dzisiaj rozmawialiśmy o możliwym modelu danych dla firmy zajmującej się opieką nad zwierzętami. Ten model obejmuje podstawowe funkcjonalności, ale jest miejsce na ulepszenia. Podziel się z nami swoimi sugestiami w sekcji komentarzy. Dzięki!