Um modelo de dados de gerenciamento de eventos

Organizar um evento dá muito trabalho! Neste artigo, examinamos o modelo de dados por trás de um aplicativo de organização de eventos.

Se você já tentou organizar um evento para mais de dez pessoas (e não conte aqui festas ou reuniões de negócios) sabe o quão complicado pode ser o gerenciamento de eventos! Convidamos todos? Eles confirmaram se eles estão vindo? O local está reservado e preparado? Quem vai sediar o evento? Quem vai participar nas várias partes? Há muitas outras perguntas a serem respondidas, e as coisas podem facilmente dar errado.

Você pode fazer todo o seu planejamento com papel e caneta, mas por que não usar um aplicativo? É mais conveniente! Qualquer aplicativo precisará de um local para armazenar todas as informações necessárias do evento. É aqui que nosso modelo de dados de gerenciamento de eventos entra nessa história. Pegue um café, sente-se em sua cadeira favorita e veremos o que é necessário para criar um modelo de dados de gerenciamento de eventos.

Perguntas frequentes sobre gerenciamento de eventos

Antes de explicar o modelo e descrever como armazenaremos os dados, vamos primeiro revisar alguns conceitos básicos de gerenciamento de eventos:

O que pode ser considerado um evento?

Nesse contexto, um evento é uma ocasião em que muitas pessoas, que muitas vezes não se conhecem, se reúnem para conhecer ou participar de algo. Alguns eventos populares são festivais de música ou concertos, conferências de TI, eventos esportivos como jogos de futebol, conferências médicas e de saúde, etc.
O que todos os eventos têm em comum?

Os exemplos de eventos mencionados anteriormente são muito diferentes em termos de conteúdo, propósito e público-alvo. Ainda assim, eles compartilham muitas semelhanças, especialmente em sua organização.

Primeiro, considere o conteúdo do evento. Alguns eventos (por exemplo, um show ou um jogo de futebol) fornecerão apenas um tipo de conteúdo e serão realizados em um só lugar. Outros eventos incluem muitos “subeventos” diferentes, mas relacionados, que podem ocorrer em vários lugares.

Tomemos uma conferência de TI como exemplo do segundo tipo de evento. Há palestras, apresentações, workshops e competições. Os participantes provavelmente irão de sala em sala ou podem até viajar entre diferentes prédios enquanto vão para vários subeventos. Alguns desses subeventos serão executados ao mesmo tempo, mas cada subevento ainda está relacionado à TI e possui um ou mais hosts.
O que é necessário para que um evento seja um sucesso?

Em primeiro lugar, há muitos funcionários do local do evento que trabalham duro em segundo plano:técnicos de áudio e vídeo, vendedores de ingressos, porteiros, trabalhadores de limpeza e manutenção e pessoal administrativo. Muitas pessoas em muitos papéis diferentes passarão muitas horas trabalhando duro para preparar o palco para as “estrelas” e outros participantes, mas nenhum deles terá muito reconhecimento.

Claramente, todos os eventos requerem algum tipo de infraestrutura. Se realizarmos uma conferência em um local físico, falaremos sobre salas e assentos, sistema de som, iluminação, talvez vídeo, etc. Mesmo um evento online, como um webinar, deve ter um local para produzir o conteúdo e a Configuração de TI necessária para se conectar com participantes virtuais.

Os eventos costumam ter patrocinadores e parceiros de mídia que ajudam na organização e promoção dos mesmos. Esses patrocinadores são, em sua maioria, empresas e associações relacionadas ao tema do evento; ocasionalmente são outras empresas que procuram alguma boa publicidade; e mais raramente um particular servirá como patrocinador ou parceiro.
O que é gerenciamento de eventos?

O gerenciamento de eventos é um processo usado para gerenciar efetivamente eventos e tudo relacionado a eles. Pode ser considerado como um tipo de gerenciamento de projetos. Discutimos um modelo de dados de gerenciamento de projetos neste artigo. Usar um gráfico de Gantt para mostrar o progresso do evento, o status atual e as ações futuras não é uma má ideia.

Provavelmente, queremos que nosso aplicativo de gerenciamento de eventos caiba em uma tela, se possível. A maioria das ações – como criar um novo programa, atribuir funcionários e recursos a uma tarefa ou estimar custos – deve ser arrastada e solta.

O modelo de dados

O modelo de dados consiste em três áreas principais:

Events and Partners
Shows, Performers and Equipment
Employees

Vamos dar uma olhada mais de perto em cada área de assunto na ordem em que estão listadas.

Seção 1:eventos e parceiros

Os Events and Partners área de assunto é a parte central do nosso modelo. Nestas cinco tabelas, armazenaremos os detalhes mais importantes sobre nossos eventos. Também relacionaremos eventos com parceiros.

Vamos começar com o event tabela. Isso lista todos os eventos que organizamos e todos os eventos que planejamos organizar. Os atributos nesta tabela são:

event_name – O nome de um evento. Não é ÚNICO porque podemos ter dois ou mais eventos com o mesmo nome – ex. um show da mesma banda teria o mesmo nome do evento. No entanto, o event_name – start_time par deve ser ÚNICO.
event_type_id – Faz referência ao event_type dicionário.
event_location – Descreve o local onde o evento acontecerá. O uso de um atributo descritivo evita a construção de um modelo mais complexo com tabelas como “país” e “cidade” e atributos como “endereço” e “descrição”.
event_description – Uma descrição detalhada do evento e de todos os espetáculos ou atividades a ele associados. Para um show, é aqui que armazenamos informações sobre o ato de abertura, o ato principal, quaisquer artistas adicionais e a ordem da apresentação.
start_time – Quando o evento começará. É obrigatório porque devemos saber disso na fase de planejamento.
end_time – Quando o evento termina. Poderíamos usar esse atributo para armazenar a hora de término do evento esperada ou real. Como podemos não saber esse horário exato com antecedência (por exemplo, se um jogo esportivo for para a prorrogação), esse atributo é opcional.

O event_type dicionário classifica os eventos que tratamos. Armazenaremos todos os tipos possíveis de eventos de acordo com seu nicho:show, partida de futebol, jogo de basquete, conferência de TI etc. Cada tipo de evento é definido exclusivamente por seu type_name .

Como mencionamos anteriormente, os eventos costumam ter parceiros. A maioria dos eventos terá pelo menos um parceiro de mídia, enquanto alguns também terão patrocinadores e outros parceiros. O mesmo parceiro pode ter vários “papéis de parceiro” diferentes no mesmo evento. Por exemplo, uma empresa de transmissão de televisão pode ser o parceiro de mídia e o patrocinador geral do evento ao mesmo tempo. É por isso que usaremos três tabelas para relacionar eventos com parceiros.

É importante poder adicionar parceiros na fase de planejamento para que todas as partes interessadas do evento possam ter acesso oportuno a essas informações. Além disso, podemos usar dados anteriores ao planejar novos eventos – por exemplo, podemos entrar em contato com o mesmo parceiro quando estivermos organizando um evento recorrente ou um novo evento do mesmo tipo. Se uma empresa foi patrocinadora geral de uma conferência de tecnologia no ano passado, ela pode estar interessada em fazê-la novamente este ano.

Agora, vamos ver as três tabelas de parceria. O primeiro é o partner Catálogo. Para cada parceiro, armazenaremos o partner_name e seu endereço, informações de contato e outros partner_details . Observe que o partner_name atributo não é único. Podemos ter dois parceiros com o mesmo nome, como duas pessoas físicas com o mesmo nome e sobrenome ou duas empresas com o mesmo nome. Nesse caso, faremos a distinção entre eles usando as informações armazenadas em partner_details atributo.

A segunda tabela é a partner_role dicionário, que lista todos os diferentes papéis que um parceiro pode ter. O role_name O atributo conterá apenas valores UNIQUE. Alguns nomes de funções esperados são “parceiro de mídia”, “patrocinador geral” e “patrocinador”.

A última tabela nesta área temática relaciona parceiros com eventos. O is_partner A tabela contém apenas chaves estrangeiras que relacionam parceiros a eventos e definem funções ou tipos de parceria. A combinação dessas chaves estrangeiras forma a chave ÚNICA da tabela. Se quiséssemos, poderíamos adicionar uma data de início e uma data de término no caso de algum parceiro preencher sua função apenas para parte do evento. Também poderíamos relacionar parceiros com subeventos únicos e em vez de eventos inteiros. Ainda assim, essas são situações relativamente incomuns, então deixaremos essa parte do modelo como está.

Seção 2:Shows, artistas e equipamentos

Conforme mencionado na introdução, cada evento pode ter vários subeventos. Neste modelo, decidi chamar os subeventos de “shows”. Um show é um único subevento, focado em um tópico, com pelo menos um performer, etc. Em um evento de conferência de TI, um show pode ser uma palestra sobre princípios de gerenciamento de projetos; outro show poderia ser um painel de discussão das melhores práticas de armazenamento de dados. Ambos podem ocorrer ao mesmo tempo, em locais diferentes, e ser apresentados por diferentes apresentadores. Também definiremos tudo o que é necessário para fazer um show, porque o show deve continuar (em qualquer caso ☺ ).

A tabela central desta seção é o show tabela. Isso manterá um registro de qualquer show associado a eventos passados, presentes e futuros. Quando estivermos planejando um evento, precisaremos adicionar novos shows assim que o artista (ou seja, palestrante, palestrante, apresentador, estrela do rock) concordar em fazer parte de um evento. Observar uma descrição dos atributos da tabela nos ajudará a entender como ela funciona:

show_name – O nome do programa.
show_location – Descreve onde o show acontecerá.
show_description – Uma descrição detalhada desse programa.
start_time – A hora de início esperada.
end_time – A hora de término esperada. Pode ser NULL porque podemos inserir o horário de término real (quando o show terminar) em vez do horário de término esperado.
event_id – De qual evento o programa faz parte.

Na maioria dos casos, os shows exigirão equipamentos e artistas. (Teoricamente poderíamos ter um show sem artista, mas não vamos nos incomodar com isso aqui.) Como o equipamento é limitado, é importante reservar tudo o que é necessário na fase de planejamento do evento. Para fazer isso corretamente, precisamos saber o que vai acontecer em que momento. Por exemplo, se tivermos dois projetores e dois shows que exigem projetores agendados para o mesmo horário, não podemos adicionar um terceiro show que requeira projetor para esse horário, a menos que tenhamos mais equipamentos. Este é o tipo de informação que devemos ter na fase de planejamento.

Continuando, temos o performer tabela. Este é um catálogo simples de todos os artistas com quem trabalhamos ou com quem trabalharemos em qualquer evento. Para cada artista, armazenaremos seu full_name . Pode ser o nome de uma banda, um palestrante, etc. O genre atributo está aqui para distinguir entre os vários tipos de artistas – por exemplo, bandas de rock de escultores. O último atributo nesta tabela armazena os contact_details dos artistas . Usaremos o tipo de dados de texto para armazenar o lote, mas também podemos dividir os detalhes de contato em alguns campos separados.

Relacionaremos shows e artistas por meio do participate tabela. Os atributos nesta tabela são:

show_id e performer_id – Referências ao espetáculo relacionado e ao intérprete. Este par poderia ser uma chave alternativa (única) da mesa mas decidi não usá-la; podemos ter um artista fazendo parte do mesmo show em dois momentos diferentes.
start_time e end_time – Horários exatos que definem quando aquele artista fez parte daquele show.
cost_planned e cost_actual – Os custos/taxas que esperamos pagar a um artista e o que realmente pagamos a ele.

As três tabelas restantes são usadas para definir todos os equipamentos necessários para um show.

O equipment_type dicionário categoriza equipamentos. Para um show, essas categorias podem ser "equipamento de iluminação", "instrumentos musicais", "construção de palco", etc. O type_name atributo contém apenas valores UNIQUE.

O equipment tabela descreve os itens e quantidades do equipamento. Seu name atributo define o equipamento mais especificamente do que equipment_type .type_name . Para uma bola de discoteca, seu valor “equipment”.”name” seria “disco ball”, mas seu “equipment_type”.”type_name” seria “equipamento de iluminação”. O available atributo define qual quantidade do item está disponível para nós. É um número decimal porque talvez usemos alguns “itens” que não podem ser enumerados, como água e eletricidade.

A última tabela desta seção relaciona equipamentos e shows. Isso pode nos ajudar a organizar os equipamentos na fase de planejamento; ele também nos permite criar relatórios sobre custos de equipamentos posteriormente. Quando estamos planejando o uso e custos de equipamentos, essas informações podem ser muito úteis, especialmente para eventos recorrentes (ou muito semelhantes). Os atributos no required tabela são:

show_id e equipment_id – Refere-se ao show e equipamentos relacionados. Este par forma a chave UNIQUE da tabela.
quantity – A quantidade desse equipamento necessário.
cost_planned e cost_actual – O que esperamos pagar pela instalação ou aluguel de equipamentos e o que realmente pagamos.

Seção 3:Funcionários

A área de assunto deste modelo é sobre funcionários e suas funções. Eu sempre gosto de salientar que as pessoas e seu tempo são a parte mais importante de qualquer projeto. Qualquer outra coisa é apenas uma ferramenta para fazer um trabalho. (E essa ferramenta também foi feita por pessoas, usando seu tempo. ☺ )

Não vou explicar o employee , role e has_role mesas aqui. Eu já fiz isso muitas vezes antes, por exemplo, neste artigo. Se precisar, revise.

A mesa final em nosso modelo relaciona funcionários e funções com shows. Podemos esperar ter um número limitado de funcionários qualificados e precisamos ter certeza de que eles estarão disponíveis quando necessário. Obviamente, a mesma pessoa não pode estar em dois lugares diferentes ao mesmo tempo. Os atributos no engaged tabela são:

show_id e has_role_id – Faz referência ao programa relacionado e à função do funcionário.
start_time – Quando esperamos que um funcionário inicie essa função.
end_time – Quando esse papel termina. Isso é anulável porque, na maioria dos casos, atribuiremos um valor depois que o funcionário terminar sua função. No entanto, podemos inserir um horário de término esperado aqui.
cost_planned e cost_actual – O que esperamos pagar a um funcionário para lidar com essa função e o que realmente pagamos.

Mais uma vez, vou apenas salientar que esses dados históricos podem ser muito úteis quando você está organizando um evento repetido ou semelhante a um evento passado.

Hoje discutimos um possível modelo de dados para um banco de dados de gerenciamento de eventos. Cobrimos as coisas realmente importantes, como descrever o evento, agendar os artistas e atribuir funcionários e recursos ao evento. O tratamento de custos neste modelo é simplificado, mas ainda permite calcular custos planejados e reais por categoria, evento, show ou tipo de equipamento.

Não sou gerente de eventos. Se sim, espero que tenha achado este artigo muito útil. Mas gostaria de ouvir seus comentários sobre quais adições ou alterações podem ser úteis em situações da vida real.

Claro, todos são bem-vindos para enviar suas sugestões e ideias na seção de comentários.