Un modelo de datos de cuidado de mascotas

El cuidado de mascotas es una gran industria. ¿Existe un modelo de datos que pueda ayudar a los dueños de mascotas y profesionales a administrar sus actividades? ¡Ya hay!

Muchas personas comparten sus vidas con gatos, perros, pájaros y otros animales. (Una vez tuve una paloma por un tiempo, hasta que su ala se reparó). Lo que muchos dueños de mascotas no se dan cuenta es cuán grande es el negocio del cuidado de mascotas. En los Estados Unidos, los dueños de mascotas gastaron $66.75 mil millones – ¡y eso fue solo en 2016!

Si bien la mayoría de nosotros podemos mantener vivos a nuestros hámsteres sin usar tecnología sofisticada, hay muchas empresas que se centran en el cuidado de mascotas:perreras (también conocidas como hoteles para mascotas o centros turísticos para mascotas), peluqueros de mascotas, cuidadores de mascotas (que se quedan en su casa, con su mascota, mientras se va de vacaciones), paseadores de perros, conductistas de mascotas, incluso masajistas y terapeutas de mascotas. Estos a menudo brindan servicios bastante complejos para las mascotas y sus dueños, y necesitarían un modelo de datos para mantenerlos organizados. Así que echemos un vistazo a uno.

¿Qué incluye un modelo de datos de cuidado de mascotas?

Antes de comenzar a describir los detalles del modelo, analicemos algunos requisitos:

1. ¿Quién necesitará este modelo de datos?

   Aunque este modelo de datos puede sonar exótico, en realidad no es tan inusual. Solo imagínese manejando cualquiera de los negocios mencionados anteriormente. No importa cuán diferentes sean estos modelos de negocios, igual deberá:

   • Comunicarse con clientes potenciales
   • Explica tus servicios e indica sus precios
   • Organiza tu agenda
   • Hacer un seguimiento de las tareas y actividades en curso
   • Cobrar a los clientes por los servicios prestados

   Entonces, sí, existe la posibilidad de que necesite este modelo para usted o para sus clientes.

   Ahora podemos continuar y responder algunas preguntas técnicas.

2. ¿Qué se debe cubrir en este modelo?

   Será lo suficientemente general para cubrir muchas situaciones diferentes. Partiré de la suposición de que tendremos un lugar físico donde brindaremos servicios (como un hotel para mascotas) o que sirva como punto de partida para brindar servicios (es decir, para un paseador de perros).

   También necesitaremos almacenar registros de mascotas individuales y sus dueños, así como registros de los servicios que brindamos. Relacionar todo eso debería cubrir la mayoría de los casos de cuidado de mascotas.

3. ¿Por qué es importante este modelo?

   Para explicar, déjame contarte sobre una "profecía" que creo que se hará realidad.

   Todos somos conscientes de cómo la tecnología está cambiando los negocios. Vemos artículos sobre trabajos que la automatización asumirá en los próximos 10 o 20 años. La mayoría de estos trabajos probablemente serán aquellos que no dependen del contacto con humanos. Por ejemplo, muchas tiendas ahora tienen carriles de autopago donde un empleado humano puede monitorear 5 o 10 cajas. Antes, cada una de estas cajas habría tenido un cajero. Pero esperar en la fila para pagar tus compras probablemente no sea el mejor momento de tu día. Y ese trabajo también es muy agotador y mal pagado, por lo que los cajeros no están muy emocionados de verte. Este tipo de trabajos pueden y están siendo automatizados.

   El otro conjunto de trabajos que se automatizarán son intelectualmente más desafiantes pero algo repetitivos, p. casi todos los servicios financieros, la mayoría de la programación informática, e incluso la redacción.

   Entonces, mi “profecía” es que los trabajos que requieren mucho contacto humano (o, en este caso, mascotas) no solo sobrevivirán sino que se convertirán en “trabajos del futuro”; estamos hablando de psicólogos, peluqueros, peluqueros caninos y cuidadores de mascotas, etc. Pero necesitarán algo de tecnología para administrar sus negocios. Y ahí es donde entra este modelo.

El modelo de datos

Este modelo de datos consta de cuatro áreas temáticas:

• Pets
• Facilities & services
• Cases
• Planned & provided

Comenzaremos con las Pets área porque las mascotas son obviamente la parte más importante de este modelo de negocio. Después de eso, continuaremos en el mismo orden en que se enumeran las áreas temáticas.

Sección 1:Mascotas

Comenzaré con las Pets área temática; después de todo, este modelo está aquí gracias a nuestros amiguitos vestidos con sus pieles y plumas. Lo mantendré simple, aunque esta área temática podría ampliarse. Por ejemplo, podríamos almacenar muchos más detalles describiendo mascotas, sus características y los dueños de las mascotas (y sus características 😊).

La mesa más importante de todo el modelo es la pet mesa. Para cada mascota, almacenaremos:

• name – El nombre que el dueño le dio a su mascota.
• species_id – Hace referencia a la species diccionario y denota la especie de mascota.
• birth_date – La fecha de nacimiento de la mascota, si está disponible.
• notes – Todas las notas adicionales relacionadas con esta mascota, en formato de texto libre.

En el owner tabla, almacenaremos una lista de todos nuestros clientes pasados, actuales y potenciales. Personalmente, no me gusta la palabra “dueño”, porque después de vivir con tus mascotas son más como miembros de la familia. Pero puedo usarlo en el modelo de datos. Entonces, para cada propietario, almacenaremos su first_name y last_name , detalles de contacto (tal como los conocemos, es posible que no los conozcamos todos) y cualquier detalle adicional en las notes atributo.

Relacionaremos dueños y mascotas usando el pet_owner mesa. Un dueño podría tener muchas mascotas y una mascota podría tener un par de dueños, por lo que necesitaremos insertar aquí una relación de muchos a muchos. Para cada registro, almacenaremos un ÚNICO pet_id – owner_id pareja.

La tercera y última tabla en esta área temática es la species diccionario. Además del atributo de clave principal id , contiene solo el ÚNICO species_name valor. Usaremos este diccionario para almacenar la información de especies al nivel que requiere el negocio. Podríamos elegir un conjunto de valores simples como "gato", "perro", "caballo" y "pájaro". O podríamos usar valores más descriptivos como "gato - Maine Coon", "gato - Munchkin", etc. Podríamos emplear una estructura más compleja, es decir, tener una tabla para especies y otra para razas, pero no creo que este enfoque traerá algo nuevo al modelo.

Sección 2:Instalaciones y Servicios

Lo segundo más importante en este modelo son los servicios que brindaremos. También necesitaremos instalaciones, sin importar lo que ofrezcamos a los dueños de mascotas. Este podría ser un lugar, como un hotel para mascotas, o podría ser un lugar donde recojamos o dejemos mascotas (como lo usaría un paseador de perros). Guardaremos esta información en las Facilities & services área temática.

Comenzaré con el service mesa. Este es un diccionario que usaremos para almacenar una lista de todos los servicios que ofrecemos a nuestros clientes. Para cada servicio, necesitaremos:

• service_name – Un nombre que define ÚNICAMENTE un servicio.
• has_limit – Un valor que indica si este servicio tiene un límite (por ejemplo, el número de "camas" en el hotel para mascotas).
• unit_id – La unidad que usaremos para medir ese servicio. Depende del tipo de servicio que prestemos y si requiere tiempo o material (o ambos). En la mayoría de los casos, nos preocuparemos por el tiempo. Por ejemplo, si un perro se hospeda en un hotel para mascotas, entonces la unidad utilizada debe ser un "día". Por otro lado, si estamos paseando a un perro, entonces la unidad debe ser una “hora” o un “minuto”. Además de las unidades de tiempo, también podríamos usar otras medidas, p. si queremos definir el número de golosinas que se le “dará” al perro.
• cost_per_unit – El costo actual por unidad de ese servicio.

La unit el diccionario se utiliza para almacenar la lista de unit_name ÚNICOS valores. Los valores de este diccionario se mencionan solo en el service pero son muy importantes en la fase de planificación y cuando cobramos a los clientes por los servicios prestados.

Para cada servicio, también necesitaremos definir cada especie aceptada. Por ejemplo, tal vez proporcionemos un servicio de hotel para mascotas solo para gatos y no para perros. Este puede ser el caso independientemente del hecho de que ofrecemos servicio de paseo y peluquería canina. Almacenaremos todos los service_id ÚNICOS – species_id pares en el available_for mesa.

Después de haber descrito todos nuestros servicios y sus detalles, ahora describiremos las instalaciones (lugares) donde brindaremos estos servicios.

Existe una buena posibilidad de que operemos más de una instalación y brindemos más de un servicio. Por eso, necesitaremos almacenar todas nuestras instalaciones y sus detalles relacionados. Usaremos la facility tabla para rastrear:

• facility_name – Un nombre que usaremos internamente para indicar EXCLUSIVAMENTE esa instalación.
• address , phone , email y contact_person – Ubicación e información de contacto, que se explican por sí mismas.

Para cada instalación, almacenaremos qué servicios proporciona. Podríamos tener una instalación solo para gatos y otra solo para perros. O podríamos tener un técnico veterinario en una instalación y no en la otra. En cualquier caso, necesitaremos almacenar todos los servicios que podamos proporcionar en cada instalación. En los provides tabla, almacenaremos un facility_id ÚNICO - service_id par. En caso de que service .has_limit para el servicio al que se hace referencia es verdadero, también necesitaremos definir el service_limit para esa instalación también el currently_used cantidad. Ese valor debe recalcularse cada vez que comenzamos a brindar ese servicio para una mascota más en esa instalación (por ejemplo, se toma un lugar más en el hotel para mascotas) o dejamos de brindarlo a una mascota (por ejemplo, el número de camas para mascotas disponibles en el hotel ha aumentado en uno).

Sección 3:Casos

Los Cases El área temática es donde describiremos y almacenaremos todos los datos relacionados con las visitas o sesiones (es decir, una visita es una estadía en nuestro hotel para perros, un aseo, un paseo, etc.)

El case Mesa para almacenar mascotas e instalaciones relacionadas con sesiones, llamadas o visitas. Decidí usar "caso" como el nombre de la tabla porque es posible que no almacenemos solo visitas aquí. Tal vez queramos almacenar llamadas u otros contactos. Para cada caso, almacenaremos:

• facility_id – El ID de la instalación relacionada. Ese podría ser el lugar donde se hospedó la mascota (en un hotel) o el centro que recibió una llamada relacionada con este caso.
• pet_id – El DNI de la mascota involucrada.
• start_time – La marca de tiempo real cuando comenzó ese caso.
• end_time – La marca de tiempo real cuando finalizó ese caso. Será NULL hasta que se cierre el caso.
• notes – Cualquier nota adicional, en formato de texto, relacionada con ese caso.
• closed – Si este caso está cerrado o no. Se establecerá en "Verdadero" cuando end_time está configurado.

Usaremos la combinación de facility_id – pet_id – start_time como clave ÚNICA de esta tabla.

Cada caso tendrá uno o más estados asignados. Podemos esperar que el primer estado asignado indique cuándo comenzó el caso. Después de eso, asignaremos nuevos estados según sea necesario, hasta que el caso se resuelva (cerrado).

El primer diccionario aquí es el status_category diccionario. Contiene una lista de status_category_name ÚNICOS valores. Estos son estados de grupo por tipo, p. “estado físico”, “apetito” o “estado general”.

Todos los estados posibles se almacenan en el status diccionario. Para cada estado, almacenaremos su status_name , el ID de la categoría de estado a la que pertenece y el is_closing_status valor. Si is_closing_status valor es “Verdadero”, significa que cuando asignemos este estado, el caso se marcará como cerrado. El status_name – status_category_id par forma la clave ÚNICA de esta tabla.

En el case_status tabla, almacenaremos todos los estados que realmente se asignaron a los casos. Para cada registro de esta tabla, almacenaremos referencias al case y el status tablas, cualquier notes adicional y el insert_time de ese estatus. Podríamos, por ejemplo, almacenar la condición física actual y el apetito de una mascota como estados cuando la mascota ingresa a nuestras instalaciones. Estos estados cambiarían si notáramos un cambio en su condición. Por otro lado, también almacenaremos estados con respecto a cada caso (por ejemplo, "perro fue paseado"); pondremos cualquier detalle adicional con respecto a ese estado en las notes atributo. Estos estados no serán estados de “cierre” porque están relacionados con a) el estado actual de la mascota en ese momento, ob) con acciones realizadas durante la sesión o visita. Un ejemplo de un estado de "cierre" podría ser "salida de perro" de nuestro hotel para mascotas.

La última tabla de esta sección es la note mesa. Usaremos esta tabla para almacenar todas las notas relacionadas con los casos cuando no sea necesario insertar un nuevo estado. Para cada registro, almacenaremos el note_text , un ID del caso relacionado y el insert_time cuando se creó esa nota.

Sección 4:Planeado y Provisto

El área temática final es Planned & provided área temática. Las tres tablas de esta área temática almacenan datos sobre los servicios que planeamos brindar, los que realmente brindamos y todas las facturas relacionadas con los casos.

El service_planned La tabla contiene una lista de todos los servicios que hemos propuesto a nuestros clientes o que han reservado. Cada registro contendrá:

• case_id – El ID del caso relacionado.
• service_id – El ID del servicio relacionado.
• planned_start_time &planned_end_time – Cuándo tenemos previsto iniciar y finalizar este servicio. La hora de inicio debe definirse, pero la hora de finalización puede ser NULL.
• planned_units – El número de unidades de servicio previstas, p. 3 días en un hotel para mascotas.
• cost_per_unit – El costo por unidad en ese momento. Es importante almacenar este valor porque el valor almacenado en service .cost_per_unit podría cambiar entre el momento en que se realiza la reserva y el momento en que se realiza.
• planned_price – El precio cotizado por ese servicio. Esto debería ser igual a planned_units * cost_per_unit .
• notes – Cualquier nota adicional relacionada con el servicio planificado.

El service_provided la tabla tiene casi la misma estructura que el service_planned mesa. La única diferencia es que las units y price_charged los atributos pueden contener valores NULL. Esto se debe a que podemos insertar un registro en esta tabla cuando comenzamos a brindar el servicio (por ejemplo, cuando la mascota ingresa al hotel para mascotas) y los actualizaremos cuando dejemos de brindar el servicio (por ejemplo, cuando el dueño toma el casa de mascotas).

La última tabla de nuestro modelo es la invoice mesa. Mantiene una lista de todas las facturas que hemos generado para todos nuestros casos. Para cada factura, almacenaremos:

• invoice_code – Un número ÚNICO interno generado para cada factura.
• case_id – El ID del caso relacionado.
• time_generated – Cuándo se generó la factura.
• invoice_amount – La cantidad original que estamos cobrando al cliente. Esta cantidad debe ser igual a la suma de todos los valores en price_charged para service_provided .
• discount – Un descuento otorgado al cliente (por ejemplo, debido a un cupón, tarjeta de fidelización, etc. El motivo realmente no importa).
• time_charged – Cuándo se le cobró al cliente esa factura. Este atributo contendrá un valor NULL hasta que se realice el pago.
• amount_charged – El monto real que se cobró al cliente por esa factura.
• notes – Cualquier nota adicional relacionada con esa factura.

¿Qué agregarías?

Hoy hablamos sobre un posible modelo de datos para un negocio de cuidado de mascotas. Este modelo cubre las funcionalidades básicas, pero hay margen de mejora. Comparta sus sugerencias con nosotros en la sección de comentarios. ¡Gracias!