Модел на данни за грижи за домашни любимци

Грижата за домашни любимци е огромна индустрия. Има ли модел на данни, който може да помогне на собствениците на домашни любимци и професионалистите да управляват дейностите си? Има сега!

Много хора споделят живота си с котки, кучета, птици и други животни. (Веднъж имах гълъб за известно време, докато крилото му не се оправи.) Това, което много собственици на домашни любимци не осъзнават, е колко голяма е грижата за домашни любимци в бизнеса. В Съединените щати собствениците на домашни любимци са похарчили $66,75 милиарда – и това беше само през 2016 г.!

Докато повечето от нас могат да поддържат нашите хамстери живи, без да използват усъвършенствана технология, има много фирми, които се фокусират около грижите за домашни любимци:развъдници за домашни любимци (известни още като хотели за домашни любимци или курорти за домашни любимци), гримери за домашни любимци, гледачки за домашни любимци (които остават във вашия дом, с вашия домашни любимци, докато отидете на почивка), разходки на кучета, поведенчески специалисти за домашни любимци, дори масажисти и терапевти за домашни любимци. Те често предоставят доста сложни услуги на домашни любимци и техните собственици и те ще се нуждаят от модел на данни, за да ги поддържат организирани. Така че нека да разгледаме един.

Какво влиза в модела на данни за грижи за домашни любимци?

Преди да започнем да описваме подробностите за модела, нека обсъдим някои изисквания:

Кой ще се нуждае от този модел на данни?

Въпреки че този модел на данни може да звучи екзотично, всъщност не е толкова необичайно. Просто си представете, че управлявате някой от бизнесите, споменати по-горе. Без значение колко различни са тези бизнес модели, все пак ще трябва:
- Общувайте с потенциални клиенти
- Обяснете услугите си и посочете техните цени
- Организирайте графика си
- Проследяване на текущи задачи и дейности
- Таксувайте клиентите за предоставените услуги
Така че да, има шанс да имате нужда от този модел за себе си или за вашите клиенти.

Сега можем да продължим и да отговорим на някои технически въпроси.
Какво трябва да бъде покрито в този модел?

Ще бъде достатъчно общ, за да обхване много различни ситуации. Ще приема предположението, че ще имаме физическо място, където ще предоставяме услуги (като хотел за домашни любимци) или което служи като отправна точка за предоставяне на услуги (т.е. за разходка на кучета).

Също така ще трябва да съхраняваме записи за отделни домашни любимци и техните собственици, както и записи за услугите, които предоставяме. Всичко това трябва да обхване повечето случаи на грижи за домашни любимци.
Защо е важен този модел?

За да обясня, позволете ми да ви разкажа за едно „пророчество“, което мисля, че ще се сбъдне.

Всички сме наясно как технологиите променят бизнеса. Виждаме статии за работни места, които автоматизацията ще поеме през следващите 10 или 20 години. Повечето от тези работни места вероятно ще бъдат такива, които не зависят от контакт с хора. Например, много магазини вече имат ленти за самоконтрол, където един служител може да наблюдава 5 или 10 каси. Преди всяка от тези каси щеше да има касиер. Но чакането на опашка, за да платите за вашите хранителни стоки, вероятно не е най-добрият момент от деня ви. И тази работа също е много изморителна и ниско платена, така че касиерите не са много развълнувани да ви видят. Тези видове работни места могат и се автоматизират.

Другият набор от работни места, които ще бъдат автоматизирани, са интелектуално по-предизвикателни, но донякъде повтарящи се – напр. почти всички финансови услуги, повечето компютърно програмиране и дори писане.

И така, моето „пророчество” е, че работните места, които изискват много човешки (или, в този случай, домашни) контакт, не само ще оцелеят, но ще се превърнат в „работа на бъдещето”; говорим за психолози, фризьори, гримери на кучета и гледачи на домашни любимци и т.н. Но те ще се нуждаят от някаква технология, за да управляват бизнеса си. И тук идва този модел.

Моделът на данните

Този модел на данни се състои от четири предметни области:

Pets
Facilities & services
Cases
Planned & provided

Ще започнем с Pets зона, защото домашните любимци очевидно са най-важната част от този бизнес модел. След това ще продължим в същия ред, в който са изброени предметните области.

Раздел 1:Домашни любимци

Ще започна с Pets предметна област; все пак този модел е тук заради нашите малки приятели, облечени в техните кожи и пера. Ще го опростя, въпреки че тази тематична област може да бъде разширена. Например, бихме могли да съхраняваме много повече подробности, описващи домашни любимци, техните характеристики и собствениците на домашни любимци (и техните характеристики 😊).

Най-важната маса в целия модел е pet маса. За всеки домашен любимец ще съхраняваме:

name – Името, което собственикът е дал на домашния си любимец.
species_id – Препраща към species речник и обозначава вида домашни любимци.
birth_date – Рождена дата на домашния любимец, ако има такава.
notes – Всички допълнителни бележки, свързани с този домашен любимец, в свободен текстов формат.

В owner таблица, ще съхраняваме списък с всички наши минали, настоящи и потенциални клиенти. Лично аз не харесвам думата „собственик“, защото след като живеете с домашните си любимци, те са повече като членове на семейството. Но съм добре да го използвам в модела на данни. Така че за всеки собственик ще съхраняваме неговото first_name и last_name , данни за контакт (както ги познаваме, може да не ги знаем всички) и всякакви допълнителни подробности в notes атрибут.

Ще свържем собственици и домашни любимци чрез pet_owner маса. Един собственик може да има много домашни любимци, а един домашен любимец може да има няколко собственици, така че ще трябва да вмъкнем тук връзка много към много. За всеки запис ще съхраняваме УНИКАЛЕН pet_id – owner_id чифт.

Третата и последна таблица в тази предметна област е species речник. Освен атрибута на първичния ключ id , съдържа само УНИКАЛНОТО species_name стойност. Ще използваме този речник, за да съхраняваме информацията за видовете на нивото, което бизнесът изисква. Можем да използваме набор от прости стойности като „котка“, „куче“, „кон“ и „птица“. Или бихме могли да използваме по-описателни стойности като „котка – Мейн Кун“, „котка – Манчкин“ и т.н. Бихме могли да използваме по-сложна структура – т.е. да имаме една таблица за видове и друга за породи – но не мисля, че този подход ще внесе нещо ново в модела.

Раздел 2:Съоръжения и услуги

Второто най-важно нещо в този модел са услугите, които ще предоставим. Ще ни трябват и съоръжения, независимо какво предлагаме на собствениците на домашни любимци. Това може да е едно място, като хотел за домашни любимци, или може да е място, където вземаме или оставяме домашни любимци (като разходка на кучета, която би използвал). Ще съхраняваме тази информация в Facilities & services предметна област.

Ще започна с service маса. Това е речник, който ще използваме, за да съхраняваме списък с всички услуги, които предлагаме на нашите клиенти. За всяка услуга ще ни трябва:

service_name – Име, което УНИКАЛНО дефинира услуга.
has_limit – Стойност, която показва дали тази услуга има ограничение (напр. броя на „леглата“ в хотела за домашни любимци).
unit_id – Единицата, която ще използваме за измерване на тази услуга. Зависи от вида на услугата, която предоставяме и дали изисква време или материал (или и двете). В повечето случаи ще се притесняваме за времето. Например, ако куче отсяда в хотел за домашни любимци, тогава използваната единица трябва да бъде „ден“. От друга страна, ако разхождаме куче, тогава единицата трябва да бъде „час“ или „минута“. Освен времеви единици, бихме могли да използваме и други мерки, напр. ако искаме да определим броя лакомства, които кучето ще „предостави“.
cost_per_unit – Текущата цена на единица за тази услуга.

unit речникът се използва за съхраняване на списъка с UNIQUE unit_name стойности. Стойностите от този речник са посочени само в service таблица, но те са много важни във фазата на планиране и когато таксуваме от клиентите за предоставените услуги.

За всяка услуга също ще трябва да дефинираме всеки приет вид. Например, може би ще предоставим хотелски услуги за домашни любимци само за котки, а не за кучета. Това може да е така, независимо от факта, че ние предлагаме разходка и грижа за кучета. Ще съхраняваме всички УНИКАЛНИ service_id – speices_id двойки в available_for таблица.

След като сме описали всички наши услуги и техните подробности, сега ще опишем съоръженията (местата), където ще предоставяме тези услуги.

Има голям шанс да управляваме повече от едно съоръжение и да предоставяме повече от една услуга. Поради това ще трябва да съхраняваме всички наши съоръжения и свързаните с тях подробности. Ще използваме facility таблица за проследяване на:

facility_name – Име, което ще използваме вътрешно, за да обозначим УНИКАЛНО това съоръжение.
address , phone , email и contact_person – Местоположение и информация за контакт, които се разбират от само себе си.

За всяко съоръжение ще съхраняваме кои услуги предоставя. Можем да имаме едно заведение само за котки и друго само за кучета. Или можем да имаме ветеринарен техник в едно заведение, а не в другото. Във всеки случай ще трябва да съхраняваме всички услуги, които можем да предоставим във всяко съоръжение. В provides таблица, ние ще съхраняваме УНИКАЛЕН facility_id - service_id двойка. В случай, че service .has_limit тъй като посочената услуга е вярна, ще трябва също да дефинираме service_limit за това съоръжение, както и currently_used количество. Тази стойност трябва да се преизчислява всеки път, когато започнем да предоставяме тази услуга за още един домашен любимец в това съоръжение (например заемаме още едно място в хотела за домашни любимци) или спрем да я предоставяме на домашен любимец (например броя на наличните легла за домашни любимци в хотела се е увеличил с едно).

Раздел 3:Случаи

Cases Темата е мястото, където ще опишем и съхраняваме всички данни, свързани с посещения или сесии (т.е. едно посещение е един престой в нашия хотел за кучета, едно подстригване, една разходка и т.н.)

Случаят case таблицата съхранява домашни любимци и съоръжения, свързани със сесии, обаждания или посещения. Реших да използвам „case“ като име на таблицата, защото може да не съхраняваме само посещения тук. Може би искаме да съхраняваме обаждания или други контакти. За всеки случай ще съхраняваме:

facility_id – ИД на свързаното съоръжение. Това може да е мястото, където домашният любимец е отседнал (в хотел) или съоръжението, което е получило обаждане, свързано с този случай.
pet_id – Идентификацията на домашния любимец.
start_time – Действителната дата за време, когато е започнал този случай.
end_time – Действителната дата за време, когато този случай е приключил. Ще бъде NULL, докато случаят не бъде приключен.
notes – Всички допълнителни бележки в текстов формат, свързани с този случай.
closed – Ако този случай е приключен или не. Ще бъде зададено на „Вярно“, когато end_time е зададено.

Ще използваме комбинацията от facility_id – pet_id – start_time като УНИКАЛЕН ключ на тази таблица.

Всеки случай ще има един или повече статуси, присвоени му. Можем да очакваме, че първият присвоен статус ще покаже кога е започнал случаят. След това ще присвоим нови статуси според нуждите, докато случаят бъде разрешен (затворен).

Първият речник тук е status_category речник. Той съдържа списък с УНИКАЛНИ status_category_name стойности. Това са групови статуси по тип, напр. „физическо състояние“, „апетит“ или „общо състояние“.

Всички възможни състояния се съхраняват в status речник. За всяко състояние ще съхраняваме неговото status_name , ИД на категорията на състоянието, към която принадлежи, и is_closing_status стойност. Ако is_closing_status стойността е „True“, това означава, че когато присвоим този статус, случаят ще бъде маркиран като затворен. status_name – status_category_id двойка формира УНИКАЛНИЯ ключ на тази таблица.

В case_status таблица, ще съхраняваме всички състояния, които действително са били присвоени на случаите. За всеки запис в тази таблица ще съхраняваме препратки към case и status таблици, всякакви допълнителни notes и insert_time от този статус. Бихме могли например да съхраняваме текущото физическо състояние и апетита на домашния любимец като статуси, когато домашният любимец влезе в нашето съоръжение. Тези статуси биха били променени, ако забележим промяна в състоянието им. От друга страна, ние също така ще съхраняваме статуси за всеки случай (напр. „кучето беше разхождано“); ще поставим всички допълнителни подробности относно това състояние в notes атрибут. Тези състояния няма да бъдат статуси на „затваряне“, защото са свързани с а) текущото състояние на домашния любимец в този момент или б) с действията, предприети по време на сесията или посещението. Пример за състояние на „затваряне“ може да бъде „куче напуснато“ от нашия хотел за домашни любимци.

Последната таблица в този раздел е note маса. Ще използваме тази таблица, за да съхраняваме всички бележки, свързани със случаи, когато няма нужда от вмъкване на ново състояние. За всеки запис ще съхраняваме note_text , идентификатор на свързания случай и insert_time когато бе създадена тази бележка.

Раздел 4:Планирани и предоставени

Последната тема е Planned & provided предметна област. Трите таблици в тази тематична област съхраняват данни за услугите, които планираме да предоставим, действително предоставените и всички фактури, свързани със случаи.

service_planned таблицата съдържа списък на всички услуги, които сме предложили на нашите клиенти или които те са резервирали. Всеки запис ще съдържа:

case_id – Идент. № на свързания случай.
service_id – Идентификационният номер на свързаната услуга.
planned_start_time &planned_end_time – Когато планираме да започнем и да прекратим тази услуга. Началният час трябва да бъде дефиниран, но крайният час може да бъде NULL.
planned_units – Броят на планираните сервизни единици, напр. 3 дни в хотел за домашни любимци.
cost_per_unit – Цената на единица към този момент. Важно е тази стойност да се съхранява, тъй като стойността се съхранява в service .cost_per_unit може да се промени между момента на извършване на резервацията и момента на извършване.
planned_price – Посочената цена за тази услуга. Това трябва да е равно на planned_units * cost_per_unit .
notes – Всички допълнителни бележки, свързани с планираната услуга.

service_provided таблицата има почти същата структура като service_planned маса. Единствената разлика е, че units и price_charged атрибутите могат да съдържат NULL стойности. Това се дължи на факта, че можем да вмъкнем запис в тази таблица, когато започнем да предоставяме услугата (напр. когато домашният любимец влезе в хотела за домашни любимци) и ще ги актуализираме, когато спрем да предоставяме услугата (напр. когато собственикът вземе домашен любимец).

Последната таблица в нашия модел е invoice маса. Той съхранява списък с всички фактури, които сме генерирали за всички наши случаи. За всяка фактура ще съхраняваме:

invoice_code – Вътрешен УНИКАЛЕН номер, генериран за всяка фактура.
case_id – Идент. № на свързания случай.
time_generated – Кога е генерирана фактурата.
invoice_amount – Първоначалната сума, която начисляваме на клиента. Тази сума трябва да е равна на сбора от всички стойности в price_charged за service_provided .
discount – Отстъпка, предоставена на клиента (например заради купон, карта за лоялност и т.н. Причината всъщност няма значение.)
time_charged – Когато клиентът действително е бил таксуван за тази фактура. Този атрибут ще съдържа стойност NULL, докато плащането не бъде извършено.
amount_charged – Действителната сума, която е начислена на клиента за тази фактура.
notes – Всички допълнителни бележки, свързани с тази фактура.

Какво бихте добавили?

Днес говорихме за възможен модел на данни за бизнес за грижа за домашни любимци. Този модел покрива основните функционалности, но има място за подобрение. Моля, споделете вашите предложения с нас в секцията за коментари. Благодаря!