Datový model péče o domácí mazlíčky

Péče o domácí mazlíčky je obrovský průmysl. Existuje datový model, který může majitelům zvířat a odborníkům pomoci řídit jejich aktivity? Teď existuje!

Mnoho lidí sdílí svůj život s kočkami, psy, ptáky a dalšími zvířaty. (Kdysi jsem měl na chvíli holuba, dokud se mu nespravilo křídlo.) Mnoho majitelů domácích mazlíčků si neuvědomuje, jak velký byznys je péče o domácí mazlíčky. Ve Spojených státech majitelé zvířat utratili 66,75 miliardy dolarů – a to bylo právě v roce 2016!

Zatímco většina z nás dokáže udržet naše křečky naživu bez použití sofistikované technologie, existuje mnoho podniků, které se soustředí na péči o domácí mazlíčky:chovatelské stanice (také znám jako hotely pro domácí mazlíčky nebo střediska pro domácí mazlíčky), chovatelé zvířat, hlídači zvířat (kteří zůstávají u vás doma, s vaší mazlíčka, když jedete na dovolenou), pejskaři, chovatelé zvířat, dokonce i maséři a terapeuti pro domácí mazlíčky. Ty často poskytují domácím mazlíčkům a jejich majitelům poměrně složité služby a potřebovali by datový model, který by je udržoval v pořádku. Pojďme se tedy na jeden podívat.

Co je součástí datového modelu péče o domácí mazlíčky?

Než začneme s popisem detailů modelu, proberme některé požadavky:

Kdo bude tento datový model potřebovat?

Ačkoli tento datový model může znít exoticky, ve skutečnosti to není tak neobvyklé. Představte si, že provozujete některý z výše uvedených podniků. Bez ohledu na to, jak odlišné jsou tyto obchodní modely, stále musíte:
- Komunikujte s potenciálními klienty
- Vysvětlete své služby a uveďte jejich ceny
- Uspořádejte si svůj rozvrh
- Sledování probíhajících úkolů a aktivit
- Účtujte klientům poskytované služby
Takže ano, existuje šance, že tento model budete potřebovat pro sebe nebo pro své klienty.

Nyní můžeme pokračovat a odpovědět na některé technické otázky.
Co by měl tento model obsahovat?

Bude dostatečně obecný, aby pokryl mnoho různých situací. Vycházím z předpokladu, že budeme mít fyzické místo, kde budeme poskytovat služby (např. hotel pro domácí mazlíčky), nebo které bude sloužit jako výchozí bod pro poskytování služeb (tj. pro pejskaře).

Budeme také muset uchovávat záznamy o jednotlivých mazlíčcích a jejich majitelích a také záznamy o službách, které poskytujeme. To vše by mělo pokrýt většinu případů péče o domácí mazlíčky.
Proč je tento model důležitý?

Abych to vysvětlil, dovolte mi, abych vám řekl o „proroctví“, o kterém si myslím, že se splní.

Všichni víme, jak technologie mění podnikání. Vidíme články o pracovních místech, která automatizace převezme v příštích 10 nebo 20 letech. Většina z těchto prací bude pravděpodobně taková, která nezávisí na kontaktu s lidmi. Například mnoho obchodů má nyní pruhy pro samoobslužné pokladny, kde jeden lidský zaměstnanec může sledovat 5 nebo 10 pokladen. Dříve by každá z těchto pokladen měla pokladníka. Ale čekání ve frontě na zaplacení nákupu pravděpodobně není nejlepší okamžik vašeho dne. A tato práce je také velmi únavná a nedostatečně placená, takže pokladní nejsou z toho, že vás vidí, příliš nadšení. Tyto druhy úloh mohou být a jsou automatizovány.

Další sada úloh, které budou automatizovány, jsou intelektuálně náročnější, ale poněkud opakující se – např. téměř všechny finanční služby, většina počítačového programování a dokonce i psaní.

Takže moje „proroctví“ je, že práce, které vyžadují hodně kontaktu s lidmi (nebo v tomto případě s domácími mazlíčky), nejen přežijí, ale stanou se „zaměstnáními budoucnosti“; mluvíme o psychologech, vlasových stylistech, ošetřovatelích psů a hlídačích domácích mazlíčků atd. Ale budou potřebovat nějakou technologii, aby mohli provozovat své podnikání. A tady přichází na řadu tento model.

Datový model

Tento datový model se skládá ze čtyř tematických oblastí:

Pets
Facilities & services
Cases
Planned & provided

Začneme Pets oblast, protože domácí mazlíčci jsou zjevně nejdůležitější součástí tohoto obchodního modelu. Poté budeme pokračovat ve stejném pořadí, v jakém jsou uvedeny předmětové oblasti.

Část 1:Domácí mazlíčci

Začnu s Pets předmětová oblast; vždyť tento model je tu kvůli našim malým kamarádům oblečeným do kožíšek a peří. Budu to jednoduché, i když by tato oblast mohla být rozšířena. Mohli bychom například uložit mnohem více podrobností popisujících domácí mazlíčky, jejich vlastnosti a majitele zvířat (a jejich vlastnosti 😊 ).

Nejdůležitějším stolem v celém modelu je pet stůl. Pro každé zvíře uložíme:

name – Jméno, které majitel dal svému mazlíčkovi.
species_id – Odkazuje na species slovník a označuje druh domácího mazlíčka.
birth_date – Datum narození zvířete, je-li k dispozici.
notes – Všechny další poznámky týkající se tohoto mazlíčka ve formátu volného textu.

V owner tabulky, budeme ukládat seznam všech našich minulých, současných a potenciálních klientů. Osobně nemám rád slovo „majitel“, protože poté, co žijete se svými mazlíčky, jsou spíše členy rodiny. Ale můžu to použít v datovém modelu. U každého vlastníka tedy uložíme jeho first_name a last_name , kontaktní údaje (jak je známe, nemusíme je znát všechny) a další podrobnosti v notes atribut.

Vlastníky a domácí mazlíčky spojíme pomocí pet_owner stůl. Jeden majitel může mít mnoho domácích mazlíčků a jeden mazlíček může mít několik majitelů, takže zde budeme muset vložit vztah mnoho k mnoha. Pro každý záznam uložíme UNIKÁTNÍ pet_id – owner_id pár.

Třetí a poslední tabulkou v této tematické oblasti je species slovník. Kromě atributu primárního klíče id , obsahuje pouze UNIKÁTNÍ species_name hodnota. Tento slovník použijeme k ukládání informací o druzích na úrovni, kterou firma vyžaduje. Mohli bychom jít se sadou jednoduchých hodnot jako „kočka“, „pes“, „kůň“ a „pták“. Nebo bychom mohli použít více popisných hodnot jako „cat – Maine Coon“, „cat – Munchkin“ atd. Mohli bychom použít složitější strukturu – tj. mít jednu tabulku pro druhy a druhou pro plemena – ale nemyslím si, že tento přístup přinese do modelu cokoli nového.

Část 2:Zařízení a služby

Druhou nejdůležitější věcí v tomto modelu jsou služby, které budeme poskytovat. Budeme také potřebovat vybavení, bez ohledu na to, co nabízíme majitelům domácích mazlíčků. Mohlo by to být jedno místo, jako je hotel pro domácí mazlíčky, nebo to může být místo, kde vyzvedáváme nebo odkládáme domácí mazlíčky (například by to využil pejsek). Tyto informace uložíme do Facilities & services předmětová oblast.

Začnu u service stůl. Toto je slovník, který budeme používat k ukládání seznamu všech služeb, které nabízíme našim klientům. Pro každou službu budeme potřebovat:

service_name – Název, který JEDINEČNĚ definuje službu.
has_limit – Hodnota, která označuje, zda má tato služba limit (např. počet „lůžek“ v hotelu pro domácí mazlíčky).
unit_id – Jednotka, kterou použijeme k měření této služby. Záleží na typu služby, kterou poskytujeme a zda to vyžaduje čas nebo materiál (nebo obojí). Ve většině případů nás bude zajímat čas. Pokud se například pes ubytuje v hotelu pro domácí mazlíčky, měla by být použita jednotka „den“. Na druhou stranu, pokud venčíme psa, pak by jednotkou měla být „hodina“ nebo „minuta“. Kromě časových jednotek bychom mohli použít i jiná měření, např. pokud chceme definovat počet pamlsků, které bude psovi „poskytován“.
cost_per_unit – Aktuální cena za jednotku pro danou službu.

unit slovník se používá k uložení seznamu UNIQUE unit_name hodnoty. Na hodnoty z tohoto slovníku se odkazuje pouze ve service tabulky, ale jsou velmi důležité ve fázi plánování a když klientům účtujeme poskytnuté služby.

Pro každou službu budeme také muset definovat každý přijatý druh. Například možná budeme poskytovat hotelové služby pouze pro kočky a ne pro psy. Může tomu tak být bez ohledu na to, že nabízíme venčení a stříhání psů. Uložíme všechna UNIKÁTNÍ service_id – speices_id párů v available_for tabulka.

Poté, co jsme popsali všechny naše služby a jejich podrobnosti, nyní popíšeme zařízení (místa), kde budeme tyto služby poskytovat.

Je velká šance, že budeme provozovat více než jedno zařízení a poskytovat více než jednu službu. Kvůli tomu budeme muset uložit všechna naše zařízení a související podrobnosti. Použijeme facility tabulka pro sledování:

facility_name – Název, který budeme interně používat k JEDINEČNÉMU označení tohoto zařízení.
address , phone , email a contact_person – Umístění a kontaktní informace, které jsou do značné míry samozřejmé.

U každého zařízení uložíme, jaké služby poskytuje. Mohli bychom mít jedno zařízení pouze pro kočky a další pouze pro psy. Nebo bychom mohli mít veterinárního technika v jednom zařízení a ne ve druhém. V každém případě budeme muset v každém zařízení uložit všechny služby, které jsme schopni poskytnout. V provides tabulky, uložíme UNIKÁTNÍ facility_id - service_id pár. V případě, že service .has_limit pro odkazovanou službu je pravda, budeme také muset definovat service_limit pro toto zařízení také currently_used Množství. Tato hodnota by se měla přepočítat pokaždé, když začneme poskytovat tuto službu pro jednoho dalšího domácího mazlíčka v daném zařízení (např. zabere jedno další místo v hotelu pro domácí mazlíčky) nebo ji přestaneme poskytovat domácímu mazlíčkovi (např. počet dostupných postelí pro domácí mazlíčky v hotelu se zvýšil o jednu).

Část 3:Případy

Cases předmětová oblast je místo, kde popíšeme a uložíme všechna data související s návštěvami nebo sezeními (tj. jedna návštěva je jeden pobyt v našem psím hotelu, jedno stříhání, jedna procházka atd.)

case stůl ukládá domácí mazlíčky a zařízení související s relacemi, hovory nebo návštěvami. Rozhodl jsem se použít jako název tabulky „case“, protože zde nemusíme ukládat pouze návštěvy. Možná chceme ukládat hovory nebo jiné kontakty. Pro každý případ uložíme:

facility_id – ID souvisejícího zařízení. Může to být místo, kde zvíře pobývalo (v hotelu) nebo zařízení, které přijalo hovor související s tímto případem.
pet_id – ID dotčeného domácího mazlíčka.
start_time – Skutečné časové razítko, kdy tento případ začal.
end_time – Skutečné časové razítko, kdy daný případ skončil. Dokud nebude případ uzavřen, bude NULL.
notes – Jakékoli další poznámky v textovém formátu související s daným případem.
closed – Jestli je tento případ uzavřen nebo ne. Po end_time bude nastaveno na „True“. je nastaveno.

Použijeme kombinaci facility_id – pet_id – start_time jako UNIKÁTNÍ klíč této tabulky.

Každý případ bude mít přiřazen jeden nebo více statusů. Můžeme očekávat, že první přidělený stav bude indikovat, kdy případ začal. Poté podle potřeby přiřadíme nové stavy, dokud nebude případ vyřešen (uzavřen).

Prvním slovníkem je zde status_category slovník. Obsahuje seznam UNIKÁTNÍCH status_category_name hodnoty. Jedná se o skupinový stav podle typu, např. „fyzický stav“, „chuť k jídlu“ nebo „celkový stav“.

Všechny možné stavy jsou uloženy ve status slovník. Pro každý stav uložíme jeho status_name , ID kategorie stavu, do které patří, a is_closing_status hodnota. Pokud is_closing_status hodnota je „True“, to znamená, že když přiřadíme tento stav, případ bude označen jako uzavřený. status_name – status_category_id pár tvoří UNIKÁTNÍ klíč této tabulky.

V case_status tabulky, uložíme všechny stavy, které byly případům skutečně přiřazeny. Pro každý záznam v této tabulce uložíme odkazy na case a status tabulky, jakékoli další notes a insert_time toho stavu. Mohli bychom například uložit aktuální fyzický stav a chuť k jídlu domácího mazlíčka jako stavy, když zvíře přijde do našeho zařízení. Tyto stavy by se změnily, kdybychom zaznamenali změnu v jejich stavu. Na druhou stranu také uložíme stavy týkající se každého případu (např. „pes byl venčen“); veškeré další podrobnosti týkající se tohoto stavu uvedeme do notes atribut. Tyto stavy nebudou „uzavíracími“ stavy, protože souvisejí s a) aktuálním stavem zvířete v daném okamžiku nebo b) s akcemi provedenými během relace nebo návštěvy. Příkladem stavu „uzavření“ může být „pes odhlášen“ z našeho hotelu pro domácí mazlíčky.

Poslední tabulkou v této sekci je note stůl. Tuto tabulku použijeme k uložení všech poznámek souvisejících s případy, kdy není potřeba vkládat nový stav. Pro každý záznam uložíme note_text , ID souvisejícího případu a insert_time kdy byla tato poznámka vytvořena.

Část 4:Naplánováno a poskytnuto

Poslední předmět je Planned & provided předmětová oblast. Ve třech tabulkách v této oblasti jsou uložena data o službách, které jsme plánovali poskytnout, o těch skutečně poskytnutých a všech fakturách souvisejících s případy.

service_planned tabulka obsahuje seznam všech služeb, které jsme našim klientům navrhli nebo které si rezervovali. Každý záznam bude obsahovat:

case_id – ID souvisejícího případu.
service_id – ID související služby.
planned_start_time &planned_end_time – Kdy plánujeme spuštění a ukončení této služby. Počáteční čas by měl být definován, ale čas ukončení může být NULL.
planned_units – Počet plánovaných servisních jednotek, např. 3 dny v hotelu pro domácí mazlíčky.
cost_per_unit – Náklady na jednotku v té době. Je důležité tuto hodnotu uložit, protože je uložena v service .cost_per_unit se může změnit mezi časem vytvoření rezervace a časem jejího provedení.
planned_price – Cena uvedená za tuto službu. To by se mělo rovnat planned_units * cost_per_unit .
notes – Jakékoli další poznámky týkající se plánované služby.

service_provided tabulka má téměř stejnou strukturu jako service_planned stůl. Jediný rozdíl je v tom, že units a price_charged atributy mohou obsahovat hodnoty NULL. Je to způsobeno tím, že do této tabulky můžeme vložit záznam, když službu začneme poskytovat (např. když zvíře vstoupí do hotelu pro zvířata), a aktualizujeme je, když službu přestaneme poskytovat (např. když majitel převezme domácí mazlíčky).

Poslední tabulkou v našem modelu je invoice stůl. Uchovává seznam všech faktur, které jsme vygenerovali pro všechny naše případy. U každé faktury uložíme:

invoice_code – Interní UNIKÁTNÍ číslo vygenerované pro každou fakturu.
case_id – ID souvisejícího případu.
time_generated – Kdy byla faktura vygenerována.
invoice_amount – Původní částka, kterou účtujeme klientovi. Tato částka by se měla rovnat součtu všech hodnot v price_charged pro service_provided .
discount – Sleva poskytnutá klientovi (např. kvůli kuponu, věrnostní kartě atd. Na důvodu vlastně nezáleží.)
time_charged – Kdy byla klientovi skutečně účtována faktura. Tento atribut bude obsahovat hodnotu NULL, dokud nebude provedena platba.
amount_charged – Skutečná částka, která byla klientovi účtována za tuto fakturu.
notes – Jakékoli další poznámky související s touto fakturou.

Co byste přidali?

Dnes jsme hovořili o možném datovém modelu pro podnikání v oblasti péče o domácí mazlíčky. Tento model pokrývá základní funkce, ale je zde prostor pro vylepšení. Podělte se s námi o své návrhy v sekci komentářů. Díky!