Um modelo de dados de cuidados com animais de estimação

Pet care é uma indústria enorme. Existe um modelo de dados que possa ajudar proprietários e profissionais de animais de estimação a gerenciar suas atividades? Existe agora!

Muitas pessoas compartilham suas vidas com gatos, cachorros, pássaros e outros animais. (Uma vez tive um pombo por um tempo, até que sua asa se consertasse.) O que muitos donos de animais de estimação não percebem é o quão grande é um negócio de cuidados com animais de estimação. Nos Estados Unidos, os donos de animais gastaram US$ 66,75 bilhões – e isso foi só em 2016!

Embora a maioria de nós possa manter nossos hamsters vivos sem usar tecnologia sofisticada, existem muitos negócios que se concentram em cuidados com animais de estimação:canis para animais de estimação (também conhecidos como hotéis ou resorts para animais de estimação), tosadores de animais de estimação, babás de animais de estimação (que ficam em sua casa, com seu animal de estimação, enquanto você sai de férias), passeadores de cães, comportamentalistas de animais de estimação, até mesmo massagistas e terapeutas de animais de estimação. Eles geralmente fornecem serviços bastante complexos para animais de estimação e seus donos, e eles precisariam de um modelo de dados para mantê-los organizados. Então vamos dar uma olhada em um.

O que faz parte de um modelo de dados de cuidados com animais de estimação?

Antes de começarmos a descrever os detalhes do modelo, vamos discutir alguns requisitos:

Quem precisará desse modelo de dados?

Embora esse modelo de dados possa parecer exótico, não é tão incomum. Imagine-se administrando qualquer um dos negócios mencionados acima. Não importa quão diferentes sejam esses modelos de negócios, você ainda precisa:
- Comunique-se com clientes em potencial
- Explique seus serviços e indique seus preços
- Organize sua agenda
- Acompanhar tarefas e atividades em andamento
- Cobrar clientes pelos serviços prestados
Então, sim, há uma chance de você precisar desse modelo para você ou para seus clientes.

Agora podemos seguir em frente e responder a algumas perguntas técnicas.
O que deve ser coberto neste modelo?

Será geral o suficiente para cobrir muitas situações diferentes. Parto do pressuposto de que teremos um local físico onde prestaremos serviços (como um hotel para animais de estimação) ou que sirva de ponto de partida para a prestação de serviços (ou seja, para um dog walker).

Também precisaremos armazenar registros de animais de estimação individuais e seus donos, bem como registros dos serviços que prestamos. Relacionar tudo isso deve abranger a maioria dos casos de cuidados com animais de estimação.
Por que esse modelo é importante?

Para explicar, deixe-me falar sobre uma “profecia” que eu acho que vai se tornar realidade.

Todos sabemos como a tecnologia está mudando os negócios. Vemos artigos sobre trabalhos que a automação assumirá nos próximos 10 ou 20 anos. A maioria desses trabalhos provavelmente serão aqueles que não dependem do contato com humanos. Por exemplo, muitas lojas agora têm caixas de autoatendimento onde um funcionário humano pode monitorar 5 ou 10 caixas. Antes, cada um desses caixas teria um caixa. Mas esperar na fila para pagar suas compras provavelmente não é o melhor momento do seu dia. E esse trabalho também é muito cansativo e mal pago, então os caixas não estão muito animados em vê-lo. Esses tipos de trabalhos podem e estão sendo automatizados.

O outro conjunto de trabalhos que serão automatizados são intelectualmente mais desafiadores, mas um pouco repetitivos – por exemplo, quase todos os serviços financeiros, a maioria dos programas de computador e até mesmo a escrita.

Então, minha “profecia” é que trabalhos que exigem muito contato humano (ou, neste caso, animal de estimação) não apenas sobreviverão, mas se tornarão “empregos do futuro”; estamos falando de psicólogos, cabeleireiros, tosadores de cães e babás de animais de estimação, etc. Mas eles precisarão de alguma tecnologia para administrar seus negócios. E é aí que entra esse modelo.

O modelo de dados

Este modelo de dados consiste em quatro áreas temáticas:

Pets
Facilities & services
Cases
Planned & provided

Começaremos com os Pets porque os animais de estimação são obviamente a parte mais importante deste modelo de negócio. Depois disso, continuaremos na mesma ordem em que as áreas de assunto são listadas.

Seção 1:Animais de estimação

Vou começar com os Pets área de estudo; afinal, este modelo está aqui por causa dos nossos amiguinhos vestidos com suas peles e penas. Vou mantê-lo simples, embora esta área de assunto possa ser expandida. Por exemplo, poderíamos armazenar muito mais detalhes descrevendo animais de estimação, suas características e os donos dos animais (e suas características 😊).

A tabela mais importante em todo o modelo é a pet tabela. Para cada animal de estimação, armazenaremos:

name – O nome que o dono deu ao animal de estimação.
species_id – Refere-se à species dicionário e denota a espécie do animal de estimação.
birth_date – A data de nascimento do animal de estimação, se disponível.
notes – Todas as notas adicionais relacionadas a este animal de estimação, em formato de texto livre.

No owner tabela, armazenaremos uma lista de todos os nossos clientes anteriores, atuais e potenciais. Pessoalmente, eu não gosto da palavra “dono”, porque depois que você mora com seus animais de estimação eles são mais como membros da família. Mas posso usá-lo no modelo de dados. Assim, para cada proprietário, armazenaremos seu first_name e last_name , detalhes de contato (como os conhecemos, talvez não conheçamos todos) e quaisquer detalhes adicionais nas notes atributo.

Relacionaremos donos e animais de estimação usando o pet_owner tabela. Um dono pode ter muitos animais de estimação e um animal de estimação pode ter dois donos, então precisaremos inserir uma relação de muitos para muitos aqui. Para cada registro, armazenaremos um pet_id ÚNICO – owner_id par.

A terceira e última tabela nesta área de assunto é a species dicionário. Além do atributo de chave primária id , ele contém apenas o species_name ÚNICO valor. Usaremos este dicionário para armazenar as informações das espécies no nível que o negócio exige. Poderíamos usar um conjunto de valores simples como “gato”, “cachorro”, “cavalo” e “pássaro”. Ou poderíamos usar valores mais descritivos como “gato – Maine Coon”, “gato – Munchkin”, etc. Poderíamos empregar uma estrutura mais complexa – ou seja, ter uma tabela para espécies e outra para raças – mas não acho que essa abordagem trará algo novo ao modelo.

Seção 2:Instalações e Serviços

A segunda coisa mais importante neste modelo são os serviços que forneceremos. Também precisaremos de instalações, não importa o que oferecemos aos donos de animais de estimação. Este pode ser um lugar, como um hotel para animais de estimação, ou pode ser um lugar onde pegamos ou deixamos animais de estimação (como um passeador de cães usaria). Armazenaremos essas informações em Facilities & services área de estudo.

Vou começar com o service tabela. Este é um dicionário que usaremos para armazenar uma lista de todos os serviços que oferecemos aos nossos clientes. Para cada serviço, precisaremos de:

service_name – Um nome que define EXCLUSIVAMENTE um serviço.
has_limit – Um valor que indica se este serviço tem um limite (por exemplo, o número de “camas” no hotel para animais de estimação).
unit_id – A unidade que usaremos para medir esse serviço. Depende do tipo de serviço que prestamos e se requer tempo ou material (ou ambos). Na maioria dos casos, estaremos preocupados com o tempo. Por exemplo, se um cachorro fica em um hotel para animais de estimação, a unidade usada deve ser um “dia”. Por outro lado, se estivermos passeando com um cachorro, a unidade deve ser uma “hora” ou um “minuto”. Além das unidades de tempo, também poderíamos usar outras medidas, por exemplo. se quisermos definir o número de guloseimas que o cão receberá.
cost_per_unit – O custo atual por unidade para esse serviço.

A unit dicionário é usado para armazenar a lista de UNIQUE unit_name valores. Os valores deste dicionário são referenciados apenas no service tabela, mas são muito importantes na fase de planejamento e quando cobramos dos clientes pelos serviços prestados.

Para cada serviço, também precisaremos definir todas as espécies aceitas. Por exemplo, talvez forneçamos serviço de hotel para animais de estimação apenas para gatos e não para cães. Este pode ser o caso, independentemente do fato de oferecermos passeios e tosa de cães. Armazenaremos todos os service_id EXCLUSIVOS – speices_id pares no available_for tabela.

Depois de termos descrito todos os nossos serviços e seus detalhes, agora descreveremos as instalações (locais) onde prestaremos esses serviços.

Há uma boa chance de operarmos mais de uma instalação e fornecer mais de um serviço. Por isso, precisaremos armazenar todas as nossas instalações e seus detalhes relacionados. Usaremos as facility tabela para rastrear:

facility_name – Um nome que usaremos internamente para denotar EXCLUSIVAMENTE esse recurso.
address , phone , email e contact_person – Localização e informações de contato, que são praticamente autoexplicativas.

Para cada instalação, armazenaremos quais serviços ela oferece. Poderíamos ter uma instalação apenas para gatos e outra apenas para cães. Ou poderíamos ter um técnico veterinário em uma instalação e não na outra. Em qualquer caso, precisaremos armazenar todos os serviços que podemos fornecer em cada instalação. No provides tabela, armazenaremos um facility_id ÚNICO - service_id par. Caso o service .has_limit para o serviço referenciado for true, também precisaremos definir o service_limit para esse recurso, bem como o currently_used quantidade. Esse valor deve ser recalculado sempre que começarmos a fornecer esse serviço para mais um animal de estimação naquela instalação (por exemplo, mais um lugar no hotel para animais de estimação é ocupado) ou deixarmos de prestar a um animal de estimação (por exemplo, o número de camas disponíveis para animais de estimação no hotel aumentou em um).

Seção 3:Casos

Os Cases A área de assunto é onde descreveremos e armazenaremos todos os dados relacionados a visitas ou sessões (ou seja, uma visita é uma estadia em nosso hotel para cães, uma tosa, uma caminhada etc.)

O case table armazena animais de estimação e instalações relacionadas a sessões, ligações ou visitas. Decidi usar “case” como nome da tabela porque não podemos armazenar apenas visitas aqui. Talvez queiramos armazenar chamadas ou outros contatos. Para cada caso, armazenaremos:

facility_id – O ID da instalação relacionada. Pode ser onde o animal de estimação ficou (em um hotel) ou na instalação que recebeu uma ligação relacionada a este caso.
pet_id – O ID do animal de estimação envolvido.
start_time – O carimbo de data/hora real quando esse caso foi iniciado.
end_time – O carimbo de data/hora real quando esse caso terminou. Será NULL até que o caso seja encerrado.
notes – Quaisquer notas adicionais, em formato textual, relacionadas a esse caso.
closed – Se este caso está encerrado ou não. Será definido como "True" quando o end_time está definido.

Usaremos a combinação de facility_id – pet_id – start_time como a chave UNIQUE desta tabela.

Cada caso terá um ou mais status atribuídos a ele. Podemos esperar que o primeiro status atribuído indicará quando o caso começou. Depois disso, atribuiremos novos status conforme necessário, até que o caso seja resolvido (encerrado).

O primeiro dicionário aqui é o status_category dicionário. Ele contém uma lista de status_category_name ÚNICO valores. Estes são o status do grupo por tipo, por exemplo, “estado físico”, “apetite” ou “estado geral”.

Todos os status possíveis são armazenados no status dicionário. Para cada status, armazenaremos seu status_name , o ID da categoria de status a que pertence e o is_closing_status valor. Se o is_closing_status valor for “True”, significa que quando atribuirmos este status, o caso será marcado como encerrado. O status_name – status_category_id par forma a chave UNIQUE desta tabela.

No case_status tabela, armazenaremos todos os status que foram realmente atribuídos aos casos. Para cada registro nesta tabela, armazenaremos referências ao case e o status tabelas, quaisquer notes adicionais , e o insert_time desse estado. Poderíamos, por exemplo, armazenar a condição física atual e o apetite de um animal de estimação como status quando o animal entra em nossas instalações. Esses status seriam alterados se notássemos uma mudança em sua condição. Por outro lado, também armazenaremos os status de cada caso (por exemplo, “cachorro foi levado”); colocaremos quaisquer detalhes adicionais sobre esse status nas notes atributo. Esses status não serão status de “fechamento” porque estão relacionados a a) status atual do animal de estimação naquele momento, ou b) a ações realizadas durante a sessão ou visita. Um exemplo de status de “fechamento” pode ser “cachorro verificado” do nosso hotel para animais de estimação.

A última tabela nesta seção é a note tabela. Usaremos esta tabela para armazenar todas as notas relacionadas aos casos em que não há necessidade de inserir novos status. Para cada registro, armazenaremos o note_text , um ID do caso relacionado e o insert_time quando essa nota foi criada.

Seção 4:Planejado e Fornecido

A área de assunto final é o Planned & provided área de estudo. As três tabelas desta área de assunto armazenam dados sobre os serviços que planejamos prestar, os realmente prestados e todas as faturas relacionadas aos casos.

O service_planned tabela contém uma lista de todos os serviços que propusemos aos nossos clientes ou que eles reservaram. Cada registro conterá:

case_id – O ID do caso relacionado.
service_id – O ID do serviço relacionado.
planned_start_time &planned_end_time – Quando planejamos iniciar e encerrar este serviço. A hora de início deve ser definida, mas a hora de término pode ser NULL.
planned_units – O número de unidades de serviço planejadas, por exemplo, 3 dias em um hotel para animais de estimação.
cost_per_unit – O custo por unidade naquele momento. É importante armazenar esse valor porque o valor armazenado em service .cost_per_unit pode mudar entre o momento em que a reserva é feita e o momento em que é realizada.
planned_price – O preço cotado para esse serviço. Deve ser igual a planned_units * cost_per_unit .
notes – Quaisquer notas adicionais relacionadas ao serviço planejado.

O service_provided tabela tem quase a mesma estrutura que o service_planned tabela. A única diferença é que as units e price_charged atributos podem conter valores NULL. Isso se deve ao fato de que podemos inserir um registro nesta tabela quando começamos a prestar o serviço (por exemplo, quando o animal entra no hotel para animais) e os atualizaremos quando deixarmos de prestar o serviço (por exemplo, quando o proprietário tirar o casa de estimação).

A última tabela em nosso modelo é a invoice tabela. Ele mantém uma lista de todas as faturas que geramos para todos os nossos casos. Para cada fatura, armazenaremos:

invoice_code – Um número ÚNICO interno gerado para cada fatura.
case_id – O ID do caso relacionado.
time_generated – Quando a fatura foi gerada.
invoice_amount – O valor original que estamos cobrando do cliente. Esse valor deve ser igual à soma de todos os valores em price_charged para service_provided .
discount – Um desconto dado ao cliente (por exemplo, por causa de um cupom, cartão de fidelidade etc. O motivo realmente não importa.)
time_charged – Quando o cliente foi realmente cobrado por essa fatura. Este atributo conterá um valor NULL até que o pagamento seja feito.
amount_charged – O valor real que foi cobrado do cliente por essa fatura.
notes – Quaisquer notas adicionais relacionadas a essa fatura.

O que você adicionaria?

Hoje falamos sobre um possível modelo de dados para uma empresa de pet care. Este modelo cobre as funcionalidades básicas, mas há espaço para melhorias. Por favor, compartilhe suas sugestões conosco na seção de comentários. Obrigado!