Un modèle de données sur les soins aux animaux de compagnie

Les soins pour animaux de compagnie sont une industrie énorme. Existe-t-il un modèle de données pouvant aider les propriétaires d'animaux et les professionnels à gérer leurs activités ? Il y a maintenant !

De nombreuses personnes partagent leur vie avec des chats, des chiens, des oiseaux et d'autres animaux. (J'ai eu un pigeon pendant un certain temps, jusqu'à ce que son aile se répare.) Ce que beaucoup de propriétaires d'animaux ne réalisent pas, c'est à quel point une entreprise de soins pour animaux de compagnie est importante. Aux États-Unis, les propriétaires d'animaux ont dépensé 66,75 milliards de dollars – et c'était juste en 2016 !

Alors que la plupart d'entre nous peuvent garder leurs hamsters en vie sans utiliser de technologie sophistiquée, il existe de nombreuses entreprises qui se concentrent sur les soins aux animaux de compagnie :les chenils pour animaux de compagnie (c. animal de compagnie, pendant que vous partez en vacances), les promeneurs de chiens, les comportementalistes pour animaux de compagnie, voire les masseurs et thérapeutes pour animaux de compagnie. Ceux-ci fournissent souvent des services assez complexes aux animaux de compagnie et à leurs propriétaires, et ils auraient besoin d'un modèle de données pour les garder organisés. Alors jetons-y un œil.

Que contient un modèle de données sur les soins aux animaux de compagnie ?

Avant de commencer à décrire les détails du modèle, discutons de certaines exigences :

Qui aura besoin de ce modèle de données ?

Bien que ce modèle de données puisse sembler exotique, il n'est pas vraiment inhabituel. Imaginez-vous à la tête de l'une des entreprises mentionnées ci-dessus. Peu importe à quel point ces modèles commerciaux sont différents, vous devez toujours :
- Communiquer avec des clients potentiels
- Expliquez vos services et indiquez leurs prix
- Organisez votre emploi du temps
- Suivre les tâches et activités en cours
- Facturer les clients pour les services rendus
Alors oui, il est possible que vous ayez besoin de ce modèle pour vous-même ou pour vos clients.

Nous pouvons maintenant passer à autre chose et répondre à quelques questions techniques.
Que doit couvrir ce modèle ?

Il sera suffisamment général pour couvrir de nombreuses situations différentes. Je partirai du principe que nous aurons un lieu physique où nous fournirons des services (comme un hôtel pour animaux de compagnie) ou qui servira de point de départ pour fournir des services (par exemple, pour un promeneur de chiens).

Nous devrons également stocker des enregistrements pour les animaux individuels et leurs propriétaires, ainsi que des enregistrements des services que nous fournissons. Relier tout cela devrait couvrir la plupart des cas de soins pour animaux de compagnie.
Pourquoi ce modèle est-il important ?

Pour vous expliquer, laissez-moi vous parler d'une "prophétie" qui, je pense, se réalisera.

Nous sommes tous conscients de la façon dont la technologie change les affaires. Nous voyons des articles sur les emplois que l'automatisation prendra en charge dans les 10 ou 20 prochaines années. La plupart de ces emplois seront probablement ceux qui ne dépendent pas du contact avec les humains. Par exemple, de nombreux magasins disposent désormais de caisses automatiques où un seul employé humain peut surveiller 5 ou 10 caisses. Avant, chacune de ces caisses aurait eu un caissier. Mais faire la queue pour payer vos courses n'est probablement pas le meilleur moment de votre journée. Et ce travail est aussi très fatigant et sous-payé, donc les caissiers ne sont pas vraiment ravis de vous voir. Ces types de travaux peuvent et sont automatisés.

L'autre ensemble d'emplois qui seront automatisés sont intellectuellement plus difficiles mais quelque peu répétitifs - par ex. presque tous les services financiers, la plupart des programmes informatiques et même l'écriture.

Donc, ma « prophétie » est que les emplois qui nécessitent beaucoup de contacts humains (ou, dans ce cas, des animaux de compagnie) non seulement survivront, mais deviendront des « emplois du futur » ; nous parlons de psychologues, de coiffeurs, de toiletteurs pour chiens, de gardiens d'animaux, etc. Mais ils auront besoin de technologie pour gérer leur entreprise. Et c'est là que ce modèle entre en jeu.

Le modèle de données

Ce modèle de données se compose de quatre domaines :

Pets
Facilities & services
Cases
Planned & provided

Nous allons commencer par les Pets car les animaux de compagnie sont évidemment la partie la plus importante de ce modèle d'entreprise. Après cela, nous continuerons dans le même ordre que les domaines sont répertoriés.

Section 1 :Animaux de compagnie

Je vais commencer par les Pets Domaine; après tout, ce modèle est là à cause de nos petits amis vêtus de leurs fourrures et plumes. Je vais rester simple, même si ce domaine pourrait être élargi. Par exemple, nous pourrions stocker beaucoup plus de détails décrivant les animaux, leurs caractéristiques et les propriétaires d'animaux (et leurs caractéristiques 😊 ).

La table la plus importante de tout le modèle est le pet table. Pour chaque animal, nous stockerons :

name – Le nom que le propriétaire a donné à son animal.
species_id – Fait référence à l'species dictionnaire et désigne l'espèce d'animal de compagnie.
birth_date – La date de naissance de l'animal, si disponible.
notes – Toutes les notes supplémentaires liées à cet animal de compagnie, au format texte libre.

Dans le owner table, nous stockerons une liste de tous nos clients passés, actuels et potentiels. Personnellement, je n'aime pas le mot "propriétaire", car après avoir vécu avec vos animaux de compagnie, ils ressemblent davantage à des membres de la famille. Mais je suis d'accord pour l'utiliser dans le modèle de données. Ainsi, pour chaque propriétaire, nous stockerons son first_name et last_name , les coordonnées (comme nous les connaissons, nous ne les connaissons peut-être pas toutes) et tout détail supplémentaire dans les notes attribut.

Nous mettrons en relation les propriétaires et les animaux de compagnie à l'aide du pet_owner table. Un propriétaire peut avoir plusieurs animaux de compagnie et un animal de compagnie peut avoir plusieurs propriétaires, nous devrons donc insérer ici une relation plusieurs-à-plusieurs. Pour chaque enregistrement, nous stockerons un pet_id UNIQUE – owner_id paire.

Le troisième et dernier tableau de ce domaine est l'species dictionnaire. Outre l'attribut de clé primaire id , il ne contient que le species_name UNIQUE valeur. Nous utiliserons ce dictionnaire pour stocker les informations sur les espèces au niveau requis par l'entreprise. Nous pourrions utiliser un ensemble de valeurs simples comme « chat », « chien », « cheval » et « oiseau ». Ou nous pourrions utiliser des valeurs plus descriptives comme "chat - Maine Coon", "chat - Munchkin", etc. Nous pourrions utiliser une structure plus complexe - c'est-à-dire avoir un tableau pour les espèces et un autre pour les races - mais je ne pense pas que cette approche apportera quelque chose de nouveau au modèle.

Section 2 :Installations et services

La deuxième chose la plus importante dans ce modèle sont les services que nous fournirons. Nous aurons également besoin d'installations, peu importe ce que nous offrons aux propriétaires d'animaux. Il peut s'agir d'un endroit, comme un hôtel pour animaux de compagnie, ou d'un endroit où nous récupérons ou déposons des animaux de compagnie (comme le ferait un promeneur de chiens). Nous stockerons ces informations dans les Facilities & services domaine.

Je vais commencer par le service table. Il s'agit d'un dictionnaire que nous utiliserons pour stocker une liste de tous les services que nous offrons à nos clients. Pour chaque service, nous aurons besoin d'un :

service_name – Un nom qui définit UNIQUEMENT un service.
has_limit – Une valeur qui indique si ce service a une limite (par exemple, le nombre de "lits" dans l'hôtel pour animaux de compagnie).
unit_id – L'unité que nous utiliserons pour mesurer ce service. Cela dépend du type de service que nous fournissons et si cela nécessite du temps ou du matériel (ou les deux). Dans la plupart des cas, nous serons préoccupés par le temps. Par exemple, si un chien séjourne dans un hôtel pour animaux de compagnie, l'unité utilisée doit être un "jour". D'autre part, si nous promenons un chien, l'unité doit être une « heure » ou une « minute ». Outre les unités de temps, nous pourrions également utiliser d'autres mesures, par ex. si l'on veut définir le nombre de friandises que le chien sera "fourni".
cost_per_unit – Le coût actuel par unité pour ce service.

L'unit dictionnaire est utilisé pour stocker la liste UNIQUE de unit_name valeurs. Les valeurs de ce dictionnaire sont référencées uniquement dans le service tableau, mais ils sont très importants dans la phase de planification et lorsque nous facturons les clients pour les services fournis.

Pour chaque service, nous devrons également définir toutes les espèces acceptées. Par exemple, nous fournirons peut-être un service d'hôtel pour animaux de compagnie uniquement pour les chats et non pour les chiens. Cela peut être le cas indépendamment du fait que nous offrons la promenade et le toilettage de chiens. Nous stockerons tous les service_id UNIQUES – speices_id paires dans le available_for tableau.

Après avoir décrit tous nos services et leurs détails, nous allons maintenant décrire les installations (lieux) où nous fournirons ces services.

Il y a de fortes chances que nous exploitions plus d'une installation et que nous fournissions plus d'un service. Pour cette raison, nous devrons stocker toutes nos installations et leurs détails associés. Nous utiliserons la fonctionnalité facility tableau pour suivre :

facility_name – Un nom que nous utiliserons en interne pour désigner UNIQUEMENT cette installation.
address , phone , email et contact_person – Localisation et informations de contact, qui sont assez explicites.

Pour chaque établissement, nous enregistrerons les services qu'il fournit. Nous pourrions avoir une installation pour les chats seulement et une autre pour les chiens seulement. Ou nous pourrions avoir un technicien vétérinaire dans un établissement et pas dans l'autre. Dans tous les cas, nous devrons stocker tous les services que nous sommes en mesure de fournir dans chaque établissement. Dans le provides table, nous stockerons un facility_id UNIQUE - service_id paire. Au cas où ce service .has_limit pour que le service référencé soit vrai, nous devrons également définir le service_limit pour cette installation ainsi que le currently_used quantité. Cette valeur doit être recalculée chaque fois que nous commençons à fournir ce service pour un animal de compagnie de plus dans cet établissement (par exemple, une place de plus dans l'hôtel pour animaux de compagnie est prise) ou que nous arrêtons de le fournir à un animal de compagnie (par exemple, le nombre de lits pour animaux de compagnie disponibles dans l'hôtel a augmenté de un).

Section 3 :Cas

Les Cases le domaine est l'endroit où nous décrirons et stockerons toutes les données relatives aux visites ou aux sessions (c'est-à-dire qu'une visite correspond à un séjour dans notre hôtel canin, un toilettage, une promenade, etc.)

Le case la table stocke les animaux domestiques et les installations liées aux sessions, aux appels ou aux visites. J'ai décidé d'utiliser "case" comme nom de table car nous ne pouvons pas stocker uniquement les visites ici. Peut-être voulons-nous stocker des appels ou d'autres contacts. Pour chaque cas, nous stockerons :

facility_id – L'identifiant de l'installation associée. Il peut s'agir de l'endroit où l'animal a séjourné (dans un hôtel) ou de l'établissement qui a reçu un appel lié à ce cas.
pet_id – L'ID de l'animal impliqué.
start_time – L'horodatage réel du début de ce cas.
end_time – L'horodatage réel auquel ce cas s'est terminé. Il sera NULL jusqu'à ce que le dossier soit fermé.
notes – Toutes les notes supplémentaires, sous forme textuelle, liées à ce cas.
closed – Si ce dossier est clos ou non. Il sera défini sur "True" lorsque le end_time est défini.

Nous utiliserons la combinaison de facility_id – pet_id – start_time comme clé UNIQUE de cette table.

Chaque dossier se verra attribuer un ou plusieurs statuts. Nous pouvons nous attendre à ce que le premier statut attribué indique quand le cas a commencé. Après cela, nous attribuerons de nouveaux statuts au besoin, jusqu'à ce que le cas soit résolu (fermé).

Le premier dictionnaire ici est le status_category dictionnaire. Il contient une liste UNIQUE de status_category_name valeurs. Ce sont des statuts de groupe par type, par ex. "état physique", "appétit" ou "état général".

Tous les statuts possibles sont stockés dans le status dictionnaire. Pour chaque statut, nous stockerons son status_name , l'ID de la catégorie de statut à laquelle il appartient et le is_closing_status valeur. Si le is_closing_status la valeur est "True", cela signifie que lorsque nous attribuons ce statut, le dossier sera marqué comme fermé. Le status_name – status_category_id paire forme la clé UNIQUE de cette table.

Dans le case_status table, nous stockerons tous les statuts qui ont été réellement attribués aux cas. Pour chaque enregistrement de ce tableau, nous stockerons les références au case et le status tableaux, toutes les notes supplémentaires , et le insert_time de ce statut. Nous pourrions, par exemple, stocker la condition physique et l'appétit actuels d'un animal de compagnie en tant que statuts lorsque l'animal entre dans notre établissement. Ces statuts seraient modifiés si nous remarquions un changement dans leur état. D'autre part, nous stockerons également les statuts concernant chaque cas (par exemple, "le chien a été promené"); nous mettrons tous les détails supplémentaires concernant ce statut dans les notes attribut. Ces statuts ne seront pas des statuts de "fermeture" car ils sont liés a) au statut actuel de l'animal à ce moment-là, ou b) aux actions entreprises pendant la session ou la visite. Un exemple de statut de "fermeture" pourrait être "chien sorti" de notre hôtel pour animaux de compagnie.

Le dernier tableau de cette section est la note table. Nous utiliserons cette table pour stocker toutes les notes liées aux cas lorsqu'il n'est pas nécessaire d'insérer un nouveau statut. Pour chaque enregistrement, nous stockerons le note_text , un ID du cas associé et le insert_time lorsque cette note a été créée.

Section 4 :Planifié et fourni

Le dernier domaine est le Planned & provided Domaine. Les trois tables de ce domaine stockent des données sur les services que nous avions prévu de fournir, ceux réellement fournis et toutes les factures liées aux cas.

Le service_planned table contient une liste de tous les services que nous avons proposés à nos clients ou qu'ils ont réservés. Chaque enregistrement contiendra :

case_id – L'identifiant du dossier associé.
service_id – L'identifiant du service associé.
planned_start_time &planned_end_time – Quand nous prévoyons de commencer et de terminer ce service. L'heure de début doit être définie mais l'heure de fin peut être NULL.
planned_units – Le nombre d'unités de service prévues, par ex. 3 jours dans un hôtel pour animaux.
cost_per_unit – Le coût unitaire à ce moment-là. Il est important de stocker cette valeur car la valeur stockée dans service .cost_per_unit peut changer entre le moment où la réservation est effectuée et le moment où elle est effectuée.
planned_price – Le prix indiqué pour ce service. Cela devrait être égal à planned_units * cost_per_unit .
notes – Toutes les notes supplémentaires liées au service prévu.

Le service_provided table a presque la même structure que le service_planned table. La seule différence est que les units et price_charged les attributs peuvent contenir des valeurs NULL. Cela est dû au fait que nous pouvons insérer un enregistrement dans ce tableau lorsque nous commençons à fournir le service (par exemple, lorsque l'animal entre dans l'hôtel pour animaux de compagnie) et nous les mettrons à jour lorsque nous cesserons de fournir le service (par exemple, lorsque le propriétaire prend le maison pour animaux de compagnie).

La dernière table de notre modèle est la invoice table. Il conserve une liste de toutes les factures que nous avons générées pour tous nos cas. Pour chaque facture, nous stockons :

invoice_code – Un numéro UNIQUE interne généré pour chaque facture.
case_id – L'identifiant du dossier associé.
time_generated – Quand la facture a été générée.
invoice_amount – Le montant initial que nous facturons au client. Ce montant doit être égal à la somme de toutes les valeurs de price_charged pour service_provided .
discount – Une remise accordée au client (par exemple grâce à un coupon, une carte de fidélité, etc. La raison n'a pas vraiment d'importance.)
time_charged – Quand le client a effectivement été facturé pour cette facture. Cet attribut contiendra une valeur NULL jusqu'à ce que le paiement soit effectué.
amount_charged – Le montant réel qui a été facturé au client pour cette facture.
notes – Toutes les notes supplémentaires liées à cette facture.

Qu'ajouteriez-vous ?

Aujourd'hui, nous avons parlé d'un modèle de données possible pour une entreprise de soins pour animaux de compagnie. Ce modèle couvre les fonctionnalités de base, mais il y a place à amélioration. S'il vous plaît partagez vos suggestions avec nous dans la section des commentaires. Merci !