Un modelo de datos de gestión de eventos

¡Organizar un evento es mucho trabajo! En este artículo, examinamos el modelo de datos detrás de una aplicación de organización de eventos.

Si alguna vez ha intentado organizar un evento para más de diez personas (y no cuente aquí las fiestas o reuniones de negocios), ¡sabe lo complicado que puede ser la gestión de eventos! ¿Hemos invitado a todos? Han confirmado si vienen? ¿El lugar está reservado y preparado? ¿Quién será el anfitrión del evento? ¿Quién participará en las distintas partes? Hay muchas otras preguntas para responder, y las cosas podrían salir mal fácilmente.

Puedes hacer toda tu planificación con papel y bolígrafo, pero ¿por qué no usar una aplicación? ¡Es más conveniente! Cualquier aplicación necesitará un lugar para almacenar toda la información necesaria del evento. Aquí es donde nuestro modelo de datos de gestión de eventos entra en esta historia. Tome un café, siéntese en su silla favorita y veremos qué se necesita para construir un modelo de datos de gestión de eventos.

Preguntas frecuentes sobre la gestión de eventos

Antes de explicar el modelo y describir cómo almacenaremos los datos, primero revisemos algunos conceptos básicos de gestión de eventos:

1. ¿Qué podría considerarse un evento?

   En este contexto, un evento es una ocasión en la que muchas personas, que a menudo no se conocen, se reúnen para aprender o participar en algo. Algunos eventos populares son festivales de música o conciertos, conferencias de TI, eventos deportivos como partidos de fútbol, ​​conferencias médicas y de salud, etc.

2. ¿Qué tienen en común todos los eventos?

   Los ejemplos de eventos mencionados anteriormente son muy diferentes en términos de contenido, propósito y público objetivo. Aún así, comparten muchas similitudes, especialmente en su organización.

   Primero, considere el contenido del evento. Algunos eventos (por ejemplo, un concierto o un partido de fútbol) proporcionarán solo un tipo de contenido y se llevarán a cabo en un solo lugar. Otros eventos incluyen muchos "subeventos" diferentes pero relacionados, que pueden ocurrir en varios lugares.

   Tome una conferencia de TI como ejemplo del segundo tipo de evento. Hay conferencias, presentaciones, talleres y concursos. Los asistentes probablemente irán de una habitación a otra o incluso viajarán entre diferentes edificios mientras asisten a varios subeventos. Algunos de estos subeventos se ejecutarán al mismo tiempo, pero cada subevento aún se relaciona con TI y tiene uno o más hosts.

3. ¿Qué se necesita para que un evento tenga éxito?

   En primer lugar, hay mucho personal del lugar del evento que trabaja arduamente en segundo plano:técnicos de audio y video, vendedores de boletos, ujieres, trabajadores de limpieza y mantenimiento, y personal administrativo. Muchas personas en diferentes roles pasarán muchas horas trabajando arduamente para preparar el escenario para las "estrellas" y otros participantes, pero ninguno de ellos obtendrá mucho reconocimiento.

   Claramente, todos los eventos requieren algún tipo de infraestructura. Si realizamos una conferencia en un lugar físico, estaremos hablando de salas y asientos, un sistema de sonido, iluminación, quizás video, etc. Incluso un evento en línea, como un seminario web, debe tener un lugar para producir el contenido y la Configuración de TI necesaria para conectarse con los asistentes virtuales.

   Los eventos suelen tener patrocinadores de medios y socios que ayudan a organizarlos y promocionarlos. Estos patrocinadores son en su mayoría empresas y asociaciones relacionadas con el tema del evento; ocasionalmente son otras empresas que buscan buena publicidad; y más raramente un particular servirá como patrocinador o socio.

4. ¿Qué es la gestión de eventos?

   La gestión de eventos es un proceso que se utiliza para gestionar eficazmente los eventos y todo lo relacionado con ellos. Podría considerarse como un tipo de gestión de proyectos. Discutimos un modelo de datos de gestión de proyectos en este artículo. Usar un diagrama de Gantt para mostrar el progreso del evento, el estado actual y las acciones futuras no es una mala idea.

   Probablemente querremos que nuestra aplicación de gestión de eventos quepa en una pantalla, si es posible. La mayoría de las acciones, como crear un nuevo programa, asignar empleados y recursos a una tarea o estimar costos, deben arrastrarse y soltarse.

El modelo de datos

El modelo de datos consta de tres áreas temáticas principales:

• Events and Partners
• Shows, Performers and Equipment
• Employees

Echaremos un vistazo más de cerca a cada área temática en el orden en que aparecen.

Sección 1:Eventos y socios

Los Events and Partners El área temática es la parte central de nuestro modelo. En estas cinco tablas, almacenaremos los detalles más importantes sobre nuestros eventos. También relacionaremos eventos con socios.

Comencemos con el event mesa. Aquí se enumeran todos los eventos que hemos organizado y todos los eventos que planeamos organizar. Los atributos de esta tabla son:

• event_name – El nombre de un evento. No es ÚNICO porque podemos tener dos o más eventos con el mismo nombre, p. un concierto de la misma banda tendría el mismo nombre de evento. Sin embargo, el event_name – start_time el par debe ser ÚNICO.
• event_type_id – Hace referencia al event_type diccionario.
• event_location – Describe el lugar donde se llevará a cabo el evento. El uso de un atributo descriptivo nos permite evitar crear un modelo más complejo con tablas como "país" y "ciudad" y atributos como "dirección" y "descripción".
• event_description – Una descripción detallada del evento y de todos los espectáculos o actividades asociados al mismo. Para un concierto, aquí es donde almacenaríamos información sobre el acto de apertura, el acto principal, los artistas adicionales y el orden de actuación.
• start_time – Cuándo comenzará el evento. Es obligatorio porque debemos saberlo en la fase de planificación.
• end_time – Cuando finaliza el evento. Podríamos usar este atributo para almacenar la hora de finalización esperada o real del evento. Dado que es posible que no sepamos este tiempo exacto por adelantado (por ejemplo, si un juego de deportes entra en tiempo extra), este atributo es opcional.

El event_type diccionario clasifica los eventos que manejamos. Almacenaremos todos los tipos de eventos posibles según su nicho:concierto, partido de fútbol, ​​partido de baloncesto, conferencia de TI, etc. Cada tipo de evento se define de forma única por su type_name .

Como mencionamos anteriormente, los eventos suelen tener socios. La mayoría de los eventos tendrán al menos un socio de medios, mientras que algunos también tendrán patrocinadores y otros socios. El mismo socio podría tener varios "roles de socio" diferentes en el mismo evento. Por ejemplo, una empresa de transmisión de televisión podría ser el socio de medios y el patrocinador general del evento al mismo tiempo. Es por eso que usaremos tres tablas para relacionar eventos con socios.

Es importante poder agregar socios en la fase de planificación para que todas las partes interesadas del evento puedan tener acceso oportuno a esa información. Además, podemos usar datos pasados ​​cuando estamos planeando nuevos eventos, p. podríamos contactar al mismo socio cuando estemos organizando un evento recurrente o un nuevo evento del mismo tipo. Si una empresa fue patrocinadora general de una conferencia tecnológica el año pasado, es posible que esté interesada en volver a hacerlo este año.

Ahora, veamos las tres tablas de asociación. El primero es el partner catalogar. Para cada socio, almacenaremos el partner_name y su dirección, información de contacto y otros partner_details . Observe que partner_name El atributo no es único. Podemos tener dos socios con el mismo nombre, como dos personas físicas con el mismo nombre y apellido o dos empresas con la misma razón social. En este caso, distinguiremos entre ellos utilizando la información almacenada en partner_details atributo.

La segunda tabla es el partner_role diccionario, que enumera todos los diferentes roles que podría tener un socio. El role_name El atributo contendrá solo valores ÚNICOS. Algunos nombres de roles esperados son "socio de medios", "patrocinador general" y "patrocinador".

La última tabla en esta área temática relaciona socios con eventos. El is_partner La tabla contiene solo claves externas que relacionan socios con eventos y definen roles o tipos de asociación. La combinación de estas claves foráneas forma la clave ÚNICA de la tabla. Si quisiéramos, podríamos agregar una fecha de inicio y una fecha de finalización en caso de que algún socio solo desempeñe su función durante una parte del evento. También podríamos relacionar socios con subeventos individuales y en lugar de eventos completos. Aún así, estas son situaciones relativamente poco comunes, por lo que dejaremos esta parte del modelo tal como está.

Sección 2:Espectáculos, artistas y equipo

Como se mencionó en la introducción, cada evento puede tener varios subeventos. En este modelo, he decidido llamar a los subeventos "espectáculos". Un espectáculo es un evento secundario único, centrado en un tema, que tiene al menos un artista, etc. En un evento de conferencia de TI, un espectáculo podría ser una conferencia sobre los principios de gestión de proyectos; otro espectáculo podría ser un panel de discusión sobre las mejores prácticas de almacenamiento de datos. Ambos podrían tener lugar al mismo tiempo, en diferentes lugares y ser presentados por diferentes presentadores. También definiremos todo lo que se necesita para ejecutar un programa, porque el programa debe continuar (en cualquier caso, ☺).

La mesa central de esta sección es el show mesa. Esto mantendrá un registro de cualquier programa asociado con eventos pasados, presentes y futuros. Cuando estamos planeando un evento, necesitaremos agregar nuevos espectáculos tan pronto como el artista (es decir, conferenciante, orador, presentador, estrella de rock) haya aceptado ser parte de un evento. Mirar una descripción de los atributos de la tabla nos ayudará a entender cómo funciona:

• show_name – El nombre del programa.
• show_location – Describe dónde se llevará a cabo el espectáculo.
• show_description – Una descripción detallada de ese programa.
• start_time – La hora de inicio prevista.
• end_time – La hora de finalización prevista. Puede ser NULL porque podemos ingresar la hora de finalización real (una vez que finaliza el programa) en lugar de la hora de finalización esperada.
• event_id – De qué evento forma parte el programa.

En la mayoría de los casos, los espectáculos requerirán equipo e intérpretes. (En teoría, podríamos tener un espectáculo sin un artista, pero no nos molestaremos con eso aquí). Debido a que el equipo es limitado, es importante reservar todo lo que se necesita en la fase de planificación del evento. Para hacer esto correctamente, necesitamos saber qué va a pasar en qué momento. Por ejemplo, si tenemos dos proyectores y dos espectáculos que requieren proyectores programados para el mismo horario, no podemos agregar un tercer espectáculo que requiera proyector para ese horario a menos que obtengamos más equipo. Este es el tipo de información que debemos tener en la fase de planificación.

Continuando, tenemos al performer mesa. Este es un catálogo simple de todos los artistas con los que hemos trabajado o trabajaremos en cualquier evento. Para cada artista, almacenaremos su full_name . Podría ser el nombre de una banda, un conferencista, etc. El genre El atributo está aquí para distinguir entre los diversos tipos de artistas, p. bandas de rock de escultores. El último atributo de esta tabla almacena los contact_details de los artistas. . Usaremos el tipo de datos de texto para almacenar el lote, pero también podríamos dividir los detalles de contacto en algunos campos separados.

Relacionaremos espectáculos e intérpretes a través del participate mesa. Los atributos de esta tabla son:

• show_id y performer_id – Referencias al espectáculo relacionado y al intérprete. Este par podría ser una clave alternativa (única) de la tabla pero decidí no usarla; podríamos hacer que un artista sea parte del mismo espectáculo en dos momentos diferentes.
• start_time y end_time – Horas exactas que definen cuándo ese artista fue parte de ese espectáculo.
• cost_planned y cost_actual – Los costos/tarifas que esperamos pagarle a un artista y lo que realmente le pagamos.

Las tres tablas restantes se utilizan para definir todo el equipo necesario para un espectáculo.

El equipment_type el diccionario clasifica el equipo. Para un concierto, estas categorías podrían ser "equipos de iluminación", "instrumentos musicales", "construcción de escenarios", etc. El type_name el atributo contiene solo valores ÚNICOS.

El equipment La tabla describe los artículos y las cantidades del equipo. Su name El atributo define el equipo más específicamente que equipment_type .type_name . Para una bola de discoteca, su valor “equipo”..”nombre” sería “bola de discoteca”, pero su “tipo_equipo”..”tipo_nombre” sería “equipo de iluminación”. El available El atributo define qué cantidad del artículo está disponible para nosotros. Es un número decimal porque tal vez usemos algunos "elementos" que no se pueden enumerar, como el agua y la electricidad.

La última tabla de esta sección relaciona equipos y espectáculos. Esto puede ayudarnos a organizar el equipo en la fase de planificación; también nos permite crear informes sobre los costos de los equipos más adelante. Cuando planificamos el uso y los costos del equipo, esta información puede ser muy útil, especialmente para eventos recurrentes (o muy similares). Los atributos en el required tabla son:

• show_id y equipment_id – Se refiere al espectáculo y equipamiento relacionado. Este par forma la clave ÚNICA de la tabla.
• quantity – La cantidad de ese equipo necesario.
• cost_planned y cost_actual – Lo que esperamos pagar por instalar o alquilar equipos y lo que realmente pagamos.

Sección 3:Empleados

El área temática de este modelo es sobre los empleados y sus funciones. Siempre me encanta señalar que las personas y su tiempo son la parte más importante de cualquier proyecto. Cualquier otra cosa es solo una herramienta para hacer un trabajo. (Y esa herramienta también fue hecha por personas, usando su tiempo. ☺ )

No explicaré el employee , role y has_role mesas aquí. Lo he hecho muchas veces antes, por ejemplo en este artículo. Si es necesario, revíselo.

La tabla final de nuestro modelo relaciona empleados y roles con espectáculos. Podemos esperar tener un número limitado de empleados calificados y debemos asegurarnos de que estarán disponibles cuando sea necesario. Obviamente, la misma persona no puede estar en dos lugares diferentes al mismo tiempo. Los atributos en el engaged tabla son:

• show_id y has_role_id – Hace referencia al programa relacionado y al rol del empleado.
• start_time – Cuando esperamos que un empleado comience ese rol.
• end_time – Cuando termina ese rol. Esto es anulable porque en la mayoría de los casos asignaremos un valor después de que el empleado haya terminado su función. Sin embargo, es posible que ingresemos una hora de finalización prevista aquí.
• cost_planned y cost_actual – Lo que esperamos pagarle a un empleado por desempeñar esa función y lo que realmente pagamos.

Una vez más, solo señalaré que estos datos históricos pueden ser muy útiles cuando organizas un evento repetido o similar a un evento anterior.

Hoy hemos discutido un posible modelo de datos para una base de datos de gestión de eventos. Hemos cubierto las cosas realmente importantes, como describir el evento, programar a los artistas y asignar empleados y recursos al evento. El manejo de los costos en este modelo se simplifica, pero aún nos brinda la capacidad de calcular los costos planificados y reales por categoría, evento, espectáculo o tipo de equipo.

No soy un administrador de eventos. Si es así, espero que hayas encontrado este artículo muy útil. Pero me gustaría escuchar sus comentarios sobre qué adiciones o cambios podrían ser útiles en situaciones de la vida real.

Por supuesto, todos pueden enviar sus sugerencias e ideas en la sección de comentarios.