Organizar fiestas infantiles no es un trabajo fácil:todo tiene que estar perfectamente planificado y entregado. De lo contrario, sucede el caos. Depende de los adultos, más específicamente, de los organizadores de fiestas, encargarse de todo y hacerlo correctamente.
¿Hay una mejor manera de hacer esto que organizar todo en una base de datos? ¡No lo creemos!
Las fiestas infantiles varían mucho. Algunas son simples, como fiestas de cumpleaños que incluyen solo invitaciones, comida (bocadillos, bebidas y un pastel) y tal vez un payaso o un mago para entretener a los niños. Otros partidos son mucho más complejos. Es posible que necesiten un viaje fuera de la ciudad, alojamiento para dormir y muchas otras actividades. Cuanto más complicado es el partido, menos margen para los errores. Si bien un payaso que llega 10 minutos tarde no es gran cosa, ¡nadie quiere esperar con un grupo de niños aburridos por un autobús que llega dos horas tarde!
Veamos qué puede hacer un modelo de datos para ayudar a los planificadores de fiestas a mantenerse organizados.
¿Qué necesitamos en nuestro modelo de datos?
Supongamos que tenemos un negocio de planificación de fiestas. Tendremos una lista de servicios que ofrecemos a los clientes. Estos servicios podrían ser proporcionados por nosotros, o podríamos usar socios (por ejemplo, contratamos al payaso).
Combinamos estos servicios y los ofrecemos a los clientes como un paquete de fiesta. Cada paquete tiene un punto de inicio y finalización, o horario. Esto incluye no solo la fiesta en sí, sino también la preparación de la fiesta y la limpieza posterior. También podemos tener varias ubicaciones (por ejemplo, una fiesta comienza con pizza en un restaurante, luego se traslada a la playa para nadar).
También necesitaremos relacionar las actividades con los empleados, realizar un seguimiento del progreso de las partes y cobrar por nuestros servicios. Veamos cómo se hace esto.
Modelo de datos de fiestas infantiles
Nuestro modelo de datos de fiestas infantiles consta de cuatro áreas temáticas:
Countries & citiesPartners & servicesEmployees & rolesParty
Presentaremos cada área temática en el mismo orden en que aparece.
Sección 1:Países y Ciudades
Esta área temática contiene solo dos tablas. No son específicos de este modelo, pero los usaremos en otras áreas temáticas.
Podemos esperar operar en varias ciudades y tal vez incluso en varios países. Por lo tanto, tendremos que hacer referencia a varias ciudades. Esto nos ayudará a rastrear dónde se encuentran las partes y también qué servicios ofrecemos en cada lugar.
El country el diccionario contiene solo el country_name ÚNICO valor. Para cada city , almacenaremos la combinación ÚNICA de postal_code – city_name – country_id .
Sección 2:Socios y servicios
A continuación, detallaremos los servicios que brindaremos a nuestros clientes.
Una lista de todos los servicios posibles se almacena en el service diccionario. Contiene solo el ÚNICO service_name atributo.
En este modelo de datos, todos los servicios son proporcionados por socios. Incluso cuando nuestra empresa proporcione el servicio, la trataremos como un partner servicio (y nosotros somos el socio). El diccionario de socios almacenará todos los socios con los que trabajamos, incluidos nosotros. Para cada socio, almacenaremos un partner_name ÚNICO . Los details El atributo almacena cualquier detalle adicional relacionado con ese socio usando un formato estructurado o no estructurado (por ejemplo, usando pares de nombre-valor separados por un separador predefinido).
El provides table es la tabla final y más importante de esta sección. Para cada registro, almacenaremos:
partner_id– Elpartnerque proporciona un servicio.service_id– Elserviceproporciona este socio.city_id– Hace referencia a lacitydonde este servicio es proporcionado por ese socio.date_from– La fecha en que el socio comenzó a ofrecer ese servicio.date_to– La fecha en que el socio dejó de ofrecer ese servicio. Este valor podría ser NULL si la relación entre el servicio y el socio todavía está en curso.details– Todos los detalles adicionales relacionados con ese servicio, como la descripción del servicio, el precio, etc. Podemos esperar que todos los detalles estén en un formato de texto estructurado, utilizando pares clave-valor.
La combinación de partner_id – service_id – city_id – date_from forma la clave ÚNICA en esta tabla. Cuando ingresamos un nuevo registro, debemos verificar que no se superponga con ningún registro existente.
Sección 3:Empleados y roles
Antes de pasar a la parte central y más importante de nuestro modelo, debemos mirar las tablas relacionadas con nuestros empleados y sus funciones.
La mesa central en esta área temática es el employee mesa. Para cada empleado, almacenaremos su first_name , last_name , user_name y password . Usarán estos dos últimos atributos para acceder a nuestra aplicación.
Una lista de todos los roles posibles se almacena en el role diccionario. Cada rol está definido ÚNICAMENTE por su role_name . Los roles están relacionados con las acciones que cada empleado realiza durante una fiesta. Por lo tanto, podemos esperar valores como "gestor de grupo" o "asistente" aquí.
Los roles se pueden asignar a los empleados a través de has_role mesa. El employee_id – role_id par denotará los roles activos que tiene cada empleado en ese momento.
Sección 4:Fiesta
La Party El área temática es la parte central de este modelo. Lo usaremos para relacionar tablas de otras áreas temáticas y también tendremos información nueva aquí.
La mesa central aquí es la party mesa. Para cada fiesta, almacenaremos:
city_id– Lacitydonde se llevará a cabo la fiesta.client_id– Elclientesta fiesta está organizada para.details– Una descripción textual detallada de la fiesta.start_time_plannedyend_time_planned– La hora que hemos programado para esta fiesta, incluida la instalación y la limpieza.start_time_actualyend_time_actual– Las horas reales en que tuvo lugar la fiesta (y sus servicios relacionados).price_offered– El precio que cotizamos para organizar esta fiesta para este cliente.time_offered– Cuándo se hizo la oferta.price_paid– El monto real que el cliente pagó por esta fiesta.time_paid– Cuándo se realizó el pago.
Cada parte está relacionada con un cliente. Ya hemos hecho referencia al client tabla, pero ahora veremos lo que se almacena allí. Fui solo con datos básicos:client_name , datos de contacto (address , email , phone , mobile ), y cualquier detalle adicional en formato de texto.
Cada parte también tendrá una lista de servicios asociados a ella. Esa lista se almacena en el service_included mesa. Para cada registro, necesitaremos:
party_id– Hace referencia a laparty.service_id– Hace referencia alserviceincluido en la fiesta.provides_id– Hace referencia alproviderde ese servicio, así como el propio servicio. Este atributo puede ser NULL, ya que lo actualizaremos cuando seleccionemos el proveedor específico.details– Cualquier detalle textual adicional relacionado con ese servicio en esa parte.start_time_plannedyend_time_planned– Los horarios previstos en los que se debe prestar el servicio durante la fiesta.
También tendremos que seguir el progreso de cada grupo. Usaremos dos tablas para hacer esto.
El status La tabla enumerará todos los estados posibles que podrían asignarse a una parte. Para cada registro, almacenaremos un status_name ÚNICO y tres banderas:
successful– ¿Salió todo bien? ¿O hubo problemas con nuestros servicios?paid– ¿Se ha pagado la fiesta?final– ¿Es este el estado final de esta fiesta?
Asignaremos estados a los servicios agregando nuevos registros a party_status mesa. Para cada registro, almacenaremos referencias a la party y service tablas y la timestamp cuando se asignó este estado.
La tabla final de nuestro modelo es la invoice mesa. No es específico de este modelo, pero sí necesitamos una estructura básica para almacenar las facturas. Para cada factura, registraremos:
client_name– El nombre del cliente en el momento de emisión de la factura.party_id– Lapartyrelacionado con esta factura.client_id– El ID delclientsiendo facturado.invoice_amount,discount,vat_amount,total_amount– Los detalles financieros de la factura.time_issued- Cuándo se emitió esta factura o se agregó a la base de datos.time_paid- Cuándo se pagó esta factura.
¿Qué harías con este modelo de datos?
Este modelo es bastante sencillo, pero veo varias maneras en que podemos mejorarlo. ¿Qué cambios propondría? ¿Hay algo que podamos organizar de manera diferente? Tal vez necesitemos agregar o eliminar una característica. Cuéntanoslo en los comentarios.
