Een gegevensmodel voor dierenverzorging

Dierenverzorging is een enorme industrie. Is er een datamodel dat eigenaren van gezelschapsdieren en professionals kan helpen bij het beheren van hun activiteiten? Dat is er nu!

Veel mensen delen hun leven met katten, honden, vogels en andere dieren. (Ik heb een tijdje een duif gehad, totdat zijn vleugel herstelde.) Wat veel eigenaren van gezelschapsdieren zich niet realiseren, is hoe groot een bedrijf voor dierenverzorging is. In de Verenigde Staten gaven eigenaren van gezelschapsdieren $66,75 miljard uit – en dat was pas in 2016!

Hoewel de meesten van ons onze hamsters in leven kunnen houden zonder geavanceerde technologie te gebruiken, zijn er tal van bedrijven die zich richten op de verzorging van huisdieren:huisdierenkennels (ook wel huisdierenhotels of huisdierenresorts genoemd), trimmers voor huisdieren, huisdierenoppassers (die bij u thuis blijven, met uw huisdier, terwijl u op vakantie gaat), hondenuitlaters, gedragstherapeuten voor huisdieren, zelfs huisdierenmasseurs en therapeuten. Deze bieden vaak vrij complexe diensten aan huisdieren en hun eigenaren, en ze zouden een gegevensmodel nodig hebben om ze georganiseerd te houden. Laten we er dus een bekijken.

Wat komt er in een gegevensmodel voor dierenverzorging?

Laten we, voordat we beginnen met het beschrijven van de details van het model, enkele vereisten bespreken:

Wie heeft dit gegevensmodel nodig?

Hoewel dit datamodel misschien exotisch klinkt, is het niet zo ongewoon. Stelt u zich eens voor dat u een van de bovengenoemde bedrijven runt. Hoe verschillend deze bedrijfsmodellen ook zijn, u moet nog steeds:
- Communiceren met potentiële klanten
- Leg uw diensten uit en vermeld hun prijzen
- Organiseer je schema
- Volg lopende taken en activiteiten
- Klanten in rekening brengen voor verleende diensten
Dus ja, er is een kans dat je dit model voor jezelf of voor je klanten nodig hebt.

Nu kunnen we verder gaan en enkele technische vragen beantwoorden.
Wat moet in dit model worden behandeld?

Het zal algemeen genoeg zijn om veel verschillende situaties te dekken. Ik ga ervan uit dat we een fysieke plek hebben waar we diensten zullen verlenen (zoals een dierenhotel) of die als uitgangspunt dient voor het verlenen van diensten (bijvoorbeeld voor een hondenuitlater).

We moeten ook gegevens opslaan voor individuele huisdieren en hun eigenaren, evenals gegevens over de diensten die we leveren. Als u dat allemaal in verband brengt, zou dit de meeste gevallen van dierenverzorging moeten dekken.
Waarom is dit model belangrijk?

Om het uit te leggen, laat me je vertellen over een "profetie" waarvan ik denk dat die zal uitkomen.

We weten allemaal hoe technologie het bedrijfsleven verandert. We zien artikelen over banen die automatisering de komende 10 of 20 jaar zal overnemen. De meeste van deze banen zullen waarschijnlijk banen zijn die niet afhankelijk zijn van contact met mensen. Veel winkels hebben nu bijvoorbeeld self-checkout-rijen waar één menselijke medewerker 5 of 10 kassa's kan controleren. Vroeger had elk van deze kassa's een kassier. Maar in de rij staan om je boodschappen te betalen is waarschijnlijk niet het leukste moment van de dag. En die baan is ook erg vermoeiend en onderbetaald, dus kassiers zijn niet echt enthousiast om je te zien. Dit soort taken kunnen en worden geautomatiseerd.

De andere reeks taken die zullen worden geautomatiseerd, zijn intellectueel uitdagender, maar enigszins repetitief - b.v. bijna alle financiële diensten, de meeste computerprogrammering en zelfs schrijven.

Dus mijn "profetie" is dat banen die veel menselijk (of, in dit geval, huisdier) contact vereisen, niet alleen zullen overleven, maar ook "banen van de toekomst" zullen worden; we hebben het over psychologen, haarstylisten, hondentrimmers en dierenoppassers, enz. Maar ze hebben wat technologie nodig om hun bedrijf te runnen. En dat is waar dit model om de hoek komt kijken.

Het gegevensmodel

Dit datamodel bestaat uit vier vakgebieden:

Pets
Facilities & services
Cases
Planned & provided

We beginnen met de Pets omdat huisdieren uiteraard het belangrijkste onderdeel zijn van dit bedrijfsmodel. Daarna gaan we verder in dezelfde volgorde als de onderwerpgebieden zijn vermeld.

Sectie 1:Huisdieren

Ik begin met de Pets gebied; dit model is tenslotte hier vanwege onze kleine vrienden gekleed in hun bont en veren. Ik zal het simpel houden, hoewel dit onderwerpgebied kan worden uitgebreid. We zouden bijvoorbeeld veel meer details kunnen opslaan die huisdieren, hun kenmerken en de eigenaren van gezelschapsdieren (en hun kenmerken 😊 ) beschrijven.

De belangrijkste tabel in het hele model is de pet tafel. Voor elk huisdier slaan we op:

name – De naam die de eigenaar hun huisdier heeft gegeven.
species_id – Verwijst naar de species woordenboek en geeft de huisdiersoort aan.
birth_date – De geboortedatum van het huisdier, indien beschikbaar.
notes – Alle aanvullende opmerkingen met betrekking tot dit huisdier, in vrije tekstindeling.

In de owner tabel, slaan we een lijst op van al onze vroegere, huidige en potentiële klanten. Persoonlijk hou ik niet van het woord 'eigenaar', want nadat je met je huisdieren hebt samengewoond, zijn ze meer gezinsleden. Maar ik vind het prima om het in het datamodel te gebruiken. Dus voor elke eigenaar slaan we hun first_name op en last_name , contactgegevens (zoals we ze kennen, kennen we ze misschien niet allemaal) en eventuele aanvullende details in de notes attribuut.

We brengen eigenaren en huisdieren in contact met de pet_owner tafel. Eén eigenaar kan veel huisdieren hebben en één huisdier kan meerdere eigenaren hebben, dus we moeten hier een veel-op-veel-relatie invoegen. Voor elk record slaan we een UNIEKE pet_id op – owner_id paar.

De derde en laatste tabel in dit onderwerpgebied is de species woordenboek. Naast het primaire sleutelkenmerk id , het bevat alleen de UNIEKE species_name waarde. We gebruiken dit woordenboek om de soorteninformatie op te slaan op het niveau dat het bedrijf nodig heeft. We zouden kunnen gaan met een reeks eenvoudige waarden zoals "kat", "hond", "paard" en "vogel". Of we zouden meer beschrijvende waarden kunnen gebruiken zoals "kat - Maine Coon", "kat - Munchkin", enz. We zouden een complexere structuur kunnen gebruiken - d.w.z. één tabel voor soorten en een andere voor rassen - maar ik denk niet dat deze benadering zal iets nieuws toevoegen aan het model.

Sectie 2:Faciliteiten en diensten

Het op één na belangrijkste in dit model zijn de services die we zullen bieden. We hebben ook faciliteiten nodig, wat we eigenaren van gezelschapsdieren ook bieden. Dit kan een plaats zijn, zoals een dierenhotel, of het kan een plaats zijn waar we huisdieren ophalen of afzetten (zoals een hondenuitlater zou gebruiken). We slaan deze informatie op in de Facilities & services onderwerpgebied.

Ik begin met de service tafel. Dit is een woordenboek dat we zullen gebruiken om een lijst op te slaan van alle diensten die we aan onze klanten aanbieden. Voor elke service hebben we een:

service_name – Een naam die UNIEK een dienst definieert.
has_limit – Een waarde die aangeeft of deze service een limiet heeft (bijvoorbeeld het aantal “bedden” in het dierenhotel).
unit_id – De eenheid die we gebruiken om die service te meten. Het hangt af van het type service dat we leveren en of het tijd of materiaal (of beide) vereist. In de meeste gevallen zullen we ons zorgen maken over de tijd. Als een hond bijvoorbeeld in een dierenhotel verblijft, moet de gebruikte eenheid een "dag" zijn. Aan de andere kant, als we een hond uitlaten, moet de eenheid een "uur" of een "minuut" zijn. Naast tijdseenheden zouden we ook andere maten kunnen gebruiken, b.v. als we het aantal traktaties willen definiëren dat de hond zal krijgen "gegeven".
cost_per_unit – De huidige kosten per eenheid voor die service.

De unit woordenboek wordt gebruikt om de lijst met UNIEKE unit_name op te slaan waarden. Er wordt alleen naar waarden uit dit woordenboek verwezen in de service tafel, maar ze zijn erg belangrijk in de planningsfase en wanneer we klanten factureren voor geleverde diensten.

Voor elke service moeten we ook elke geaccepteerde soort definiëren. Misschien bieden we bijvoorbeeld alleen huisdierenhotelservice voor katten en niet voor honden. Dit kan het geval zijn ongeacht het feit dat wij hondenuitlaatservice aanbieden. We bewaren alle UNIEKE service_id – speices_id paren in de available_for tafel.

Nadat we al onze services en hun details hebben beschreven, beschrijven we nu de faciliteiten (plaatsen) waar we deze services gaan leveren.

De kans is groot dat we meer dan één faciliteit zullen exploiteren en meer dan één service zullen bieden. Daarom moeten we al onze faciliteiten en de bijbehorende details opslaan. We gebruiken de facility tabel om de:

. te volgen

facility_name – Een naam die we intern zullen gebruiken om die faciliteit UNIEK aan te duiden.
address , phone , email en contact_person - Locatie- en contactgegevens, die vrijwel vanzelfsprekend zijn.

Voor elke faciliteit slaan we op welke diensten deze levert. We zouden een faciliteit alleen voor katten kunnen hebben en een andere alleen voor honden. Of we kunnen een veterinaire technicus in de ene faciliteit hebben en niet in de andere. In elk geval moeten we alle diensten die we kunnen leveren in elke faciliteit opslaan. In de provides tabel, slaan we een UNIEKE facility_id op - service_id paar. In het geval dat service .has_limit voor de service waarnaar wordt verwezen waar is, moeten we ook de service_limit . definiëren voor die faciliteit ook de currently_used aantal stuks. Die waarde moet opnieuw worden berekend telkens wanneer we die service voor nog een huisdier in die faciliteit beginnen te verlenen (bijv. er wordt nog een plaats in het dierenhotel ingenomen) of we stoppen met het verstrekken aan een huisdier (bijv. het aantal beschikbare bedden voor huisdieren in het hotel is met één toegenomen).

Sectie 3:Gevallen

De Cases In het onderwerpgebied zullen we alle gegevens met betrekking tot bezoeken of sessies beschrijven en opslaan (d.w.z. één bezoek is één verblijf in ons hondenhotel, één trimbeurt, één wandeling, enz.)

De case table slaat huisdieren en faciliteiten op met betrekking tot sessies, oproepen of bezoeken. Ik heb besloten om "case" als naam van de tabel te gebruiken, omdat we hier mogelijk niet alleen bezoeken opslaan. Misschien willen we oproepen of andere contacten opslaan. Voor elk geval slaan we op:

facility_id – De ID van de gerelateerde faciliteit. Dat kan zijn waar het huisdier verbleef (in een hotel) of de faciliteit die een oproep heeft ontvangen met betrekking tot deze zaak.
pet_id – De ID van het betrokken huisdier.
start_time – De werkelijke tijdstempel toen die zaak begon.
end_time – De werkelijke tijdstempel waarop die zaak eindigde. Het is NULL totdat de zaak is gesloten.
notes – Eventuele aanvullende opmerkingen, in tekstvorm, met betrekking tot die zaak.
closed – Of deze zaak al dan niet gesloten is. Het wordt ingesteld op "True" wanneer de end_time is ingesteld.

We gebruiken de combinatie van facility_id – pet_id – start_time als de UNIEKE sleutel van deze tabel.

Elke zaak krijgt een of meer statussen toegewezen. We kunnen verwachten dat de eerste toegewezen status aangeeft wanneer de zaak is gestart. Daarna zullen we zo nodig nieuwe statussen toewijzen, totdat de zaak is opgelost (gesloten).

Het eerste woordenboek hier is de status_category woordenboek. Het bevat een lijst met UNIEKE status_category_name waarden. Dit zijn groepsstatus per type, b.v. "fysieke status", "eetlust" of "algemene status".

Alle mogelijke statussen worden opgeslagen in de status woordenboek. Voor elke status slaan we de status_name op , de ID van de statuscategorie waartoe het behoort, en de is_closing_status waarde. Als de is_closing_status waarde "True" is, betekent dit dat wanneer we deze status toewijzen, de zaak als gesloten wordt gemarkeerd. De status_name – status_category_id paar vormt de UNIEKE sleutel van deze tabel.

In de case_status tabel, slaan we alle statussen op die daadwerkelijk aan cases zijn toegewezen. Voor elk record in deze tabel slaan we verwijzingen op naar de case en de status tabellen, eventuele aanvullende notes , en de insert_time van die stand. We kunnen bijvoorbeeld de huidige fysieke conditie en eetlust van een huisdier opslaan als statussen wanneer het huisdier onze instelling binnenkomt. Deze statussen zouden worden gewijzigd als we een verandering in hun toestand opmerken. Aan de andere kant slaan we ook statussen op met betrekking tot elk geval (bijvoorbeeld "hond is uitgelaten"); we zullen eventuele aanvullende details met betrekking tot die status in de notes plaatsen attribuut. Deze statussen zijn geen "afsluitende" statussen omdat ze gerelateerd zijn aan a) de huidige status van het huisdier op dat moment, of b) aan acties die zijn ondernomen tijdens de sessie of het bezoek. Een voorbeeld van een status 'sluitend' kan zijn:'hond uitgecheckt' van ons dierenhotel.

De laatste tabel in deze sectie is de note tafel. We gebruiken deze tabel om alle notities op te slaan die betrekking hebben op gevallen waarin het niet nodig is om een nieuwe status in te voegen. Voor elke record slaan we de note_text . op , een ID van de gerelateerde zaak, en de insert_time wanneer die notitie is gemaakt.

Sectie 4:Gepland en geleverd

Het laatste onderwerpgebied is het Planned & provided gebied. De drie tabellen in dit onderwerpgebied bevatten gegevens over de diensten die we van plan waren te leveren, de werkelijk geleverde diensten en alle facturen met betrekking tot zaken.

De service_planned tabel bevat een lijst van alle diensten die we onze klanten hebben voorgesteld of die ze hebben gereserveerd. Elke record zal het volgende bevatten:

case_id – De ID van de gerelateerde zaak.
service_id – De ID van de gerelateerde service.
planned_start_time &planned_end_time – Wanneer we van plan zijn om deze service te starten en te beëindigen. De starttijd moet worden gedefinieerd, maar de eindtijd kan NULL zijn.
planned_units – Het aantal geplande service-eenheden, b.v. 3 dagen in een dierenhotel.
cost_per_unit – De kosten per eenheid op dat moment. Het is belangrijk om deze waarde op te slaan omdat de waarde die is opgeslagen in service .cost_per_unit kan veranderen tussen het moment dat de reservering is gemaakt en het moment waarop deze wordt uitgevoerd.
planned_price – De opgegeven prijs voor die dienst. Dit moet gelijk zijn aan planned_units * cost_per_unit .
notes – Eventuele aanvullende opmerkingen met betrekking tot de geplande service.

De service_provided tabel heeft bijna dezelfde structuur als de service_planned tafel. Het enige verschil is dat de units en price_charged attributen kunnen NULL-waarden bevatten. Dit is te wijten aan het feit dat we een record in deze tabel kunnen invoegen wanneer we beginnen met het leveren van de service (bijv. wanneer het huisdier het dierenhotel binnenkomt) en we zullen ze bijwerken wanneer we stoppen met het leveren van de service (bijv. huisdier thuis).

De laatste tabel in ons model is de invoice tafel. Het houdt een lijst bij van alle facturen die we hebben gegenereerd voor al onze zaken. Voor elke factuur slaan we op:

invoice_code – Een intern UNIEK nummer gegenereerd voor elke factuur.
case_id – De ID van de gerelateerde zaak.
time_generated – Wanneer de factuur is gegenereerd.
invoice_amount – Het oorspronkelijke bedrag dat we aan de klant in rekening brengen. Dit bedrag moet gelijk zijn aan de som van alle waarden in price_charged voor service_provided .
discount – Een korting die aan de klant wordt gegeven (bijvoorbeeld vanwege een coupon, klantenkaart, enz. De reden doet er niet echt toe.)
time_charged – Wanneer de opdrachtgever daadwerkelijk voor die factuur in rekening is gebracht. Dit kenmerk bevat een NULL-waarde totdat de betaling is gedaan.
amount_charged – Het werkelijke bedrag dat voor die factuur aan de klant in rekening is gebracht.
notes – Eventuele aanvullende opmerkingen met betrekking tot die factuur.

Wat zou je toevoegen?

Vandaag hadden we het over een mogelijk datamodel voor een dierenverzorgingsbedrijf. Dit model dekt de basisfunctionaliteiten af, maar er is ruimte voor verbetering. Deel uw suggesties met ons in het opmerkingengedeelte. Bedankt!