En datamodell för djurvård

Djurvård är en enorm bransch. Finns det en datamodell som kan hjälpa djurägare och proffs att hantera sina aktiviteter? Det finns nu!

Många människor delar sina liv med katter, hundar, fåglar och andra djur. (Jag hade en gång en duva ett tag, tills dess vinge lagade sig.) Vad många husdjursägare inte inser är hur stor ett företag som sköter husdjur är. I USA spenderade husdjursägare 66,75 miljarder USD – och det var bara 2016!

Medan de flesta av oss kan hålla våra hamstrar vid liv utan att använda sofistikerad teknik, finns det många företag som kretsar kring husdjursvård:hundkojor (a.k.a. djurhotell eller djurresorter), djurskötare, djurvakter (som bor i ditt hem, med din husdjur, medan du åker på semester), hundpromenader, djurbeteende, till och med husdjursmassörer och terapeuter. Dessa tillhandahåller ofta ganska komplexa tjänster till husdjur och deras ägare, och de skulle behöva en datamodell för att hålla dem organiserade. Så låt oss ta en titt på en.

Vad ingår i en datamodell för husdjursvård?

Innan vi börjar beskriva modellens detaljer, låt oss diskutera några krav:

Vem behöver den här datamodellen?

Även om den här datamodellen kan låta exotisk, är den egentligen inte så ovanlig. Föreställ dig att du driver något av de företag som nämns ovan. Oavsett hur olika dessa affärsmodeller är, måste du fortfarande:
- Kommunicera med potentiella kunder
- Förklara dina tjänster och ange deras priser
- Ordna ditt schema
- Spåra pågående uppgifter och aktiviteter
- Debitera klienter för utförda tjänster
Så ja, det finns en chans att du behöver den här modellen för dig själv eller för dina kunder.

Nu kan vi gå vidare och svara på några tekniska frågor.
Vad bör omfattas av den här modellen?

Det kommer att vara tillräckligt generellt för att täcka många olika situationer. Jag utgår från att vi kommer att ha en fysisk plats där vi kommer att tillhandahålla tjänster (som ett djurhotell) eller som fungerar som en utgångspunkt för att tillhandahålla tjänster (dvs. för en hundförare).

Vi kommer också att behöva lagra register för enskilda husdjur och deras ägare, såväl som register över de tjänster vi tillhandahåller. Att relatera allt detta bör täcka de flesta fall med vård av husdjur.
Varför är den här modellen viktig?

För att förklara, låt mig berätta om en "profeta" som jag tror kommer att gå i uppfyllelse.

Vi är alla medvetna om hur tekniken förändrar verksamheten. Vi ser artiklar om jobb som automatiseringen kommer att ta över de kommande 10 eller 20 åren. De flesta av dessa jobb kommer förmodligen att vara sådana som inte är beroende av kontakt med människor. Till exempel har många butiker nu självutcheckningsbanor där en mänsklig anställd kan övervaka 5 eller 10 kassor. Förut skulle var och en av dessa kassor ha haft en kassörska. Men att stå i kö för att betala för dina matvaror är förmodligen inte den bästa stunden på din dag. Och det jobbet är också väldigt tröttsamt och underbetalt, så kassörerna är inte riktigt glada över att träffa dig. Den här typen av jobb kan och håller på att automatiseras.

Den andra uppsättningen jobb som kommer att automatiseras är intellektuellt mer utmanande men något repetitiva – t.ex. nästan alla finansiella tjänster, de flesta datorprogrammering och till och med skrivande.

Så, min "profetia" är att jobb som kräver mycket mänsklig (eller, i det här fallet, husdjur) kontakt inte bara kommer att överleva utan bli "framtidens jobb"; vi pratar om psykologer, frisörer, hundfrisörer och djurvakter, etc. Men de kommer att behöva lite teknik för att driva sina företag. Och det är där den här modellen kommer in.

Datamodellen

Denna datamodell består av fyra ämnesområden:

Husdjur
Faciliteter och tjänster
Fall
Planerad och tillhandahållen

Vi börjar med Husdjur område eftersom husdjur uppenbarligen är den viktigaste delen av denna affärsmodell. Därefter fortsätter vi i samma ordning som ämnesområdena är listade.

Avsnitt 1:Husdjur

Jag börjar med Husdjur ämnesområde; trots allt är den här modellen här på grund av våra små vänner klädda i sina pälsar och fjädrar. Jag ska hålla det enkelt, även om detta ämnesområde kan utökas. Vi skulle till exempel kunna lagra många fler detaljer som beskriver husdjur, deras egenskaper och husdjursägare (och deras egenskaper 😊 ).

Den viktigaste tabellen i hela modellen är husdjuret tabell. För varje husdjur lagrar vi:

namn – Namnet ägaren gav sitt husdjur.
species_id – Refererar till arten ordbok och betecknar husdjursarten.
födelsedatum – Husdjurets födelsedatum, om tillgängligt.
anteckningar – Alla ytterligare anteckningar relaterade till detta husdjur, i fritextformat.

I ägaren tabell lagrar vi en lista över alla våra tidigare, nuvarande och potentiella kunder. Personligen gillar jag inte ordet "ägare", för efter att du bor med dina husdjur är de mer som familjemedlemmar. Men jag är okej att använda det i datamodellen. Så för varje ägare lagrar vi deras first_name och efternamn , kontaktuppgifter (som vi känner dem känner vi kanske inte alla) och eventuella ytterligare detaljer i anteckningarna attribut.

Vi kommer att relatera ägare och husdjur med hjälp av pet_owner tabell. En ägare kan ha många husdjur och ett husdjur kan ha ett par ägare, så vi måste infoga en många-till-många relation här. För varje post lagrar vi ett UNIKT pet_id – ägare_id par.

Den tredje och sista tabellen i detta ämnesområde är arten lexikon. Förutom det primära nyckelattributet id , den innehåller bara det UNIKA artsnamn värde. Vi använder den här ordboken för att lagra artinformationen på den nivå som verksamheten kräver. Vi skulle kunna gå med en uppsättning enkla värden som "katt", "hund", "häst" och "fågel". Eller så skulle vi kunna använda mer beskrivande värden som "katt - Maine Coon", "katt - Munchkin" etc. Vi skulle kunna använda en mer komplex struktur - dvs att ha en tabell för arter och en annan för raser - men jag tror inte att det här tillvägagångssättet kommer att tillföra allt nytt till modellen.

Avsnitt 2:Faciliteter och tjänster

Det näst viktigaste i den här modellen är de tjänster vi kommer att tillhandahålla. Vi kommer att behöva faciliteter också, oavsett vad vi erbjuder djurägare. Detta kan vara ett ställe, till exempel ett djurhotell, eller det kan vara en plats där vi hämtar eller lämnar husdjur (som en hundavluftare skulle använda). Vi kommer att lagra denna information i Faciliteter och tjänster ämnesområde.

Jag börjar med tjänsten tabell. Det här är en ordbok som vi kommer att använda för att lagra en lista över alla tjänster vi erbjuder våra kunder. För varje tjänst behöver vi en:

tjänstnamn – Ett namn som UNIKT definierar en tjänst.
har_gräns – Ett värde som anger om denna tjänst har en gräns (t.ex. antalet "bäddar" på djurhotellet).
enhets-id – Enheten vi kommer att använda för att mäta den tjänsten. Det beror på vilken typ av tjänst vi tillhandahåller och om det kräver tid eller material (eller båda). I de flesta fall kommer vi att oroa oss för tiden. Till exempel, om en hund bor på ett djurhotell, bör enheten som används vara en "dag". Å andra sidan, om vi går ut med en hund, bör enheten vara en "timme" eller en "minut". Förutom tidsenheter skulle vi även kunna använda andra mått, t.ex. om vi vill definiera antalet godsaker som hunden kommer att "tillhandahållas".
kostnad_per_enhet – Den aktuella kostnaden per enhet för den tjänsten.

enheten ordboken används för att lagra listan med UNIQUE enhetsnamn värden. Värden från denna ordbok refereras endast i tjänsten tabell, men de är mycket viktiga i planeringsfasen och när vi tar betalt av kunder för tillhandahållna tjänster.

För varje tjänst måste vi också definiera alla accepterade arter. Till exempel kanske vi tillhandahåller hotellservice endast för katter och inte för hundar. Detta kan vara fallet oavsett att vi erbjuder hundpromenad och trimning. Vi lagrar alla UNIKA service_id – species_id par i available_for bord.

Efter att vi har beskrivit alla våra tjänster och deras detaljer kommer vi nu att beskriva faciliteterna (ställena) där vi kommer att tillhandahålla dessa tjänster.

Det finns en god chans att vi kommer att driva mer än en anläggning och tillhandahålla mer än en tjänst. På grund av det måste vi lagra alla våra anläggningar och deras relaterade detaljer. Vi använder faciliteten tabell för att spåra:

anläggningsnamn – Ett namn som vi kommer att använda internt för att UNIKT beteckna den anläggningen.
adress , telefon , e-post och contact_person – Plats och kontaktinformation, som är ganska självförklarande.

För varje anläggning lagrar vi vilka tjänster den tillhandahåller. Vi skulle kunna ha en anläggning endast för katter och en annan endast för hundar. Eller så kan vi ha en veterinärtekniker på den ena anläggningen och inte på den andra. I vilket fall som helst måste vi lagra alla tjänster vi kan tillhandahålla i varje anläggning. I ger tabell lagrar vi ett UNIKT facility_id - service_id par. Om den tjänsten .has_limit för den refererade tjänsten är sann måste vi också definiera service_limit för den anläggningen samt currently_used kvantitet. Det värdet bör räknas om varje gång vi börjar tillhandahålla den tjänsten för ytterligare ett husdjur i den anläggningen (t.ex. en plats till på djurhotellet tas) eller så slutar vi tillhandahålla den till ett husdjur (t.ex. antalet tillgängliga husdjurssängar på hotellet har ökat med en).

Avsnitt 3:Fall

Cases ämnesområdet är där vi kommer att beskriva och lagra all data relaterade till besök eller sessioner (dvs. ett besök är en vistelse på vårt hundhotell, en trimning, en promenad, etc.)

fallet table lagrar husdjur och faciliteter relaterade till sessioner, samtal eller besök. Jag har bestämt mig för att använda "case" som namn på bordet eftersom vi kanske inte bara lagrar besök här. Kanske vill vi lagra samtal eller andra kontakter. För varje fall lagrar vi:

anläggnings-id – ID för den relaterade anläggningen. Det kan vara där husdjuret bodde (på ett hotell) eller anläggningen som fick ett samtal relaterat till det här fallet.
pet_id – ID för det inblandade husdjuret.
starttid – Den faktiska tidsstämpeln när fallet startade.
sluttid – Den faktiska tidsstämpeln när det ärendet avslutades. Den kommer att vara NULL tills ärendet avslutas.
anteckningar – Eventuella ytterligare anteckningar, i textformat, relaterade till det fallet.
stängd – Om detta ärende avslutas eller inte. Den kommer att ställas in på "True" när end_time är inställd.

Vi använder kombinationen facility_id – pet_id – starttid som den UNIKA nyckeln för denna tabell.

Varje ärende kommer att ha en eller flera statuser tilldelade. Vi kan förvänta oss att den första statusen som tilldelas kommer att indikera när ärendet startade. Därefter tilldelar vi nya statusar efter behov, tills ärendet är löst (stängt).

Den första ordboken här är status_category lexikon. Den innehåller en lista med UNIKT status_kategorinamn värden. Dessa är gruppstatus efter typ, t.ex. "fysisk status", "aptit" eller "allmän status".

Alla möjliga statusar lagras i status lexikon. För varje status lagrar vi dess status_name , ID för statuskategorin den tillhör och is_closing_status värde. Om is_closing_status värdet är "True", det betyder att när vi tilldelar denna status kommer ärendet att markeras som avslutat. status_name – status_kategori_id paret bildar den UNIKA nyckeln för denna tabell.

I case_status tabell lagrar vi alla statusar som faktiskt tilldelades ärenden. För varje post i den här tabellen lagrar vi referenser till case och status tabeller, eventuella ytterligare noteringar och insert_time av den statusen. Vi skulle till exempel kunna lagra ett husdjurs nuvarande fysiska tillstånd och aptit som status när husdjuret kommer till vår anläggning. Dessa statusar skulle ändras om vi märkte en förändring i deras tillstånd. Å andra sidan kommer vi också att lagra statusar för varje fall (t.ex. "hunden blev promenerad"); vi kommer att lägga ytterligare information om den statusen i anteckningarna attribut. Dessa statusar kommer inte att vara "stängande" statusar eftersom de är relaterade till a) nuvarande status för husdjuret i det ögonblicket, eller b) till åtgärder som vidtagits under sessionen eller besöket. Ett exempel på en "stängning"-status kan vara "hund utcheckad" från vårt djurhotell.

Den sista tabellen i det här avsnittet är noteringen tabell. Vi kommer att använda den här tabellen för att lagra alla anteckningar relaterade till fall då det inte finns något behov av att infoga ny status. För varje post lagrar vi note_text , ett ID för det relaterade fallet och insert_time när den anteckningen skapades.

Avsnitt 4:Planerad och tillhandahållen

Det sista ämnesområdet är Planerad och tillhandahållen ämnesområde. De tre tabellerna i detta ämnesområde lagrar data om tjänster vi planerade att tillhandahålla, de som faktiskt tillhandahålls och alla fakturor relaterade till ärenden.

service_planned Tabellen innehåller en lista över alla tjänster som vi har föreslagit till våra kunder eller som de har reserverat. Varje post kommer att innehålla:

case-id – ID för det relaterade ärendet.
service_id – ID för den relaterade tjänsten.
planerad_starttid &planerad_sluttid – När vi planerar att starta och avsluta denna tjänst. Starttiden bör definieras men sluttiden kan vara NULL.
planerade_enheter – Antalet planerade serviceenheter, t.ex. 3 dagar på ett djurhotell.
kostnad_per_enhet – Kostnaden per enhet vid den tidpunkten. Det är viktigt att lagra detta värde eftersom värdet lagras i tjänst .cost_per_unit kan ändras mellan tidpunkten då bokningen görs och tiden då den utförs.
planerat_pris – Det angivna priset för den tjänsten. Detta bör vara lika med planerade_enheter * kostnad_per_enhet .
anteckningar – Eventuella ytterligare anmärkningar relaterade till den planerade tjänsten.

service_provided tabellen har nästan samma struktur som service_planned tabell. Den enda skillnaden är att enheterna och price_charged attribut kan innehålla NULL-värden. Detta beror på det faktum att vi kan infoga en post i den här tabellen när vi börjar tillhandahålla tjänsten (t.ex. när husdjuret kommer in på djurhotellet) och vi kommer att uppdatera dem när vi slutar tillhandahålla tjänsten (t.ex. när ägaren tar husdjurshem).

Den sista tabellen i vår modell är fakturan tabell. Den håller en lista över alla fakturor vi har genererat för alla våra ärenden. För varje faktura lagrar vi:

faktura_kod – Ett internt UNIKT nummer genererat för varje faktura.
case-id – ID för det relaterade ärendet.
tid_genererad – När fakturan skapades.
faktura_belopp – Det ursprungliga beloppet vi debiterar kunden. Detta belopp ska vara lika med summan av alla värden i price_charged för service_provided .
rabatt – En rabatt som ges till kunden (t.ex. på grund av en kupong, lojalitetskort, etc. Anledningen spelar ingen roll.)
tid_debiterad – När kunden faktiskt debiterades för den fakturan. Detta attribut kommer att innehålla ett NULL-värde tills betalning görs.
belopp_debiterat – Det faktiska beloppet som debiterades kunden för den fakturan.
anteckningar – Eventuella ytterligare anmärkningar relaterade till den fakturan.

Vad skulle du lägga till?

Idag pratade vi om en möjlig datamodell för ett husdjursvårdsföretag. Denna modell täcker de grundläggande funktionerna, men det finns utrymme för förbättringar. Vänligen dela dina förslag med oss i kommentarsfältet. Tack!