Un modèle de données de gestion d'événements

Organiser un événement, c'est beaucoup de travail ! Dans cet article, nous examinons le modèle de données derrière une application d'organisation d'événements.

Si vous avez déjà essayé d'organiser un événement pour plus de dix personnes (et ne comptez pas les fêtes ou les réunions d'affaires ici), vous savez à quel point la gestion d'un événement peut être compliquée ! Avons-nous invité tout le monde ? Ont-ils confirmé s'ils viennent ? Le lieu est-il réservé et préparé ? Qui accueillera l'événement ? Qui participera aux différentes parties ? Il y a beaucoup d'autres questions auxquelles il faut répondre, et les choses pourraient facilement mal tourner.

Vous pouvez faire toute votre planification avec du papier et un stylo, mais pourquoi ne pas utiliser une application ? C'est plus pratique! Toute application aura besoin d'un endroit pour stocker toutes les informations nécessaires sur l'événement. C'est là que notre modèle de données de gestion d'événements entre dans cette histoire. Prenez un café, installez-vous dans votre fauteuil préféré et nous verrons ce qu'il faut pour créer un modèle de données de gestion d'événements.

FAQ sur la gestion des événements

Avant d'expliquer le modèle et de décrire comment nous allons stocker les données, examinons d'abord quelques principes de base de la gestion d'événements :

Qu'est-ce qui pourrait être considéré comme un événement ?

Dans ce contexte, un événement est une occasion où de nombreuses personnes, qui souvent ne se connaissent pas, se rassemblent pour apprendre ou participer à quelque chose. Certains événements populaires sont les festivals de musique ou les concerts, les conférences informatiques, les événements sportifs comme les matchs de football, les conférences sur la santé et la médecine, etc.
Qu'est-ce que tous les événements ont en commun ?

Les exemples d'événements mentionnés précédemment sont très différents en termes de contenu, d'objectif et de public cible. Pourtant, ils partagent de nombreuses similitudes, notamment dans leur organisation.

Tout d'abord, considérez le contenu de l'événement. Certains événements (par exemple, un concert ou un match de football) ne fourniront qu'un seul type de contenu et se dérouleront dans un seul lieu. D'autres événements comprennent de nombreux « sous-événements » différents mais liés, qui peuvent se produire à divers endroits.

Prenons une conférence informatique comme exemple du deuxième type d'événement. Il y a des conférences, des présentations, des ateliers et des concours. Les participants iront probablement de salle en salle ou pourront même voyager entre différents bâtiments lorsqu'ils se rendront à divers sous-événements. Certains de ces sous-événements se dérouleront en même temps, mais chaque sous-événement concerne toujours l'informatique et a un ou plusieurs hôtes.
Que faut-il pour réussir un événement ?

Tout d'abord, il y a de nombreux personnels des lieux événementiels qui travaillent dur en arrière-plan :techniciens audiovisuels, vendeurs de billets, huissiers, agents de nettoyage et d'entretien et personnel administratif. De nombreuses personnes dans de nombreux rôles différents passeront de nombreuses heures à travailler dur pour préparer la scène pour les "stars" et les autres participants, mais aucune d'entre elles n'obtiendra beaucoup de reconnaissance.

De toute évidence, tous les événements nécessitent une sorte d'infrastructure. Si nous organisons une conférence dans un lieu physique, nous parlerons de salles et de sièges, d'un système de sonorisation, d'éclairage, peut-être d'une vidéo, etc. Même un événement en ligne, comme un webinaire, doit avoir un endroit pour produire le contenu et le Configuration informatique nécessaire pour se connecter avec les participants virtuels.

Les événements ont généralement des sponsors et des partenaires médiatiques qui aident à les organiser et à les promouvoir. Ces sponsors sont pour la plupart des entreprises et des associations liées au thème de l'événement; occasionnellement, ce sont d'autres entreprises à la recherche d'une bonne publicité ; et plus rarement un particulier servira de parrain ou de partenaire.
Qu'est-ce que la gestion d'événements ?

La gestion des événements est un processus utilisé pour gérer efficacement les événements et tout ce qui s'y rapporte. Cela pourrait être considéré comme un type de gestion de projet. Nous avons discuté d'un modèle de données de gestion de projet dans cet article. Utiliser un diagramme de Gantt pour montrer la progression de l'événement, son statut actuel et les actions futures n'est pas une mauvaise idée.

Nous voudrons probablement que notre application de gestion d'événements tienne sur un seul écran, si possible. La plupart des actions, telles que la création d'une nouvelle émission, l'affectation d'employés et de ressources à une tâche ou l'estimation des coûts, doivent être effectuées par glisser-déposer.

Le modèle de données

Le modèle de données se compose de trois domaines principaux :

Events and Partners
Shows, Performers and Equipment
Employees

Nous examinerons de plus près chaque domaine dans l'ordre dans lequel ils sont répertoriés.

Section 1 :Événements et partenaires

Les Events and Partners domaine est la partie centrale de notre modèle. Dans ces cinq tableaux, nous stockerons les détails les plus importants sur nos événements. Nous lierons également des événements avec des partenaires.

Commençons par l'event table. Cette liste répertorie tous les événements que nous avons organisés et tous les événements que nous prévoyons d'organiser. Les attributs de ce tableau sont :

event_name – Le nom d'un événement. Ce n'est pas UNIQUE parce que nous pouvons avoir deux événements ou plus avec le même nom - par ex. un concert du même groupe aurait le même nom d'événement. Cependant, le event_name – start_time la paire doit être UNIQUE.
event_type_id – Fait référence au event_type dictionnaire.
event_location – Décrit le lieu où se déroulera l'événement. L'utilisation d'un attribut descriptif nous permet d'éviter de créer un modèle plus complexe avec des tables telles que "pays" et "ville" et des attributs tels que "adresse" et "description".
event_description – Une description détaillée de l'événement et de tous les spectacles ou activités qui y sont associés. Pour un concert, c'est ici que nous stockons les informations sur l'acte d'ouverture, l'acte principal, les éventuels artistes supplémentaires et l'ordre de représentation.
start_time – Quand l'événement commencera. C'est obligatoire, car nous devrions le savoir lors de la phase de planification.
end_time – Lorsque l'événement se termine. Nous pourrions utiliser cet attribut pour stocker l'heure de fin prévue ou réelle de l'événement. Étant donné que nous ne connaissons peut-être pas cette heure exacte à l'avance (par exemple, si un match de sport passe en prolongation), cet attribut est facultatif.

Le event_type dictionnaire classe les événements que nous traitons. Nous stockerons tous les types d'événements possibles en fonction de leur niche :concert, match de football, match de basket, conférence informatique, etc. Chaque type d'événement est défini de manière unique par son type_name .

Comme nous l'avons mentionné précédemment, les événements ont généralement des partenaires. La plupart des événements auront au moins un partenaire média, tandis que certains auront également des sponsors et d'autres partenaires. Le même partenaire peut avoir plusieurs « rôles de partenaire » différents sur le même événement. Par exemple, une société de télédiffusion pourrait être à la fois le partenaire média et le commanditaire général de l'événement. C'est pourquoi nous utiliserons trois tableaux pour relier les événements aux partenaires.

Il est important de pouvoir ajouter des partenaires dans la phase de planification afin que toutes les parties prenantes de l'événement puissent avoir un accès rapide à ces informations. De plus, nous pouvons utiliser des données passées lorsque nous planifions de nouveaux événements - par ex. nous pourrions contacter le même partenaire lorsque nous organisons un événement récurrent ou un nouvel événement du même type. Si une entreprise était sponsor général d'une conférence technologique l'année dernière, elle pourrait être intéressée à le faire à nouveau cette année.

Examinons maintenant les trois tables de partenariat. Le premier est le partner catalogue. Pour chaque partenaire, nous stockerons le partner_name et leur adresse, coordonnées et autres partner_details . Notez que le partner_name l'attribut n'est pas unique. Nous pouvons avoir deux partenaires portant le même nom, comme par exemple deux personnes physiques portant le même nom et prénom ou deux sociétés portant la même raison sociale. Dans ce cas, nous les distinguerons à l'aide des informations stockées dans les partner_details attribut.

Le deuxième tableau est le partner_role dictionnaire, qui répertorie tous les différents rôles qu'un partenaire peut avoir. Le role_name L'attribut ne contiendra que des valeurs UNIQUES. Certains noms de rôles attendus sont "partenaire média", "sponsor général" et "sponsor".

Le dernier tableau de ce domaine concerne les partenaires et les événements. Le is_partner La table contient uniquement des clés étrangères qui associent des partenaires à des événements et définissent des rôles ou des types de partenariat. La combinaison de ces clés étrangères forme la clé UNIQUE de la table. Si nous le voulions, nous pourrions ajouter une date de début et une date de fin au cas où un partenaire ne remplirait son rôle que pour une partie de l'événement. Nous pourrions également associer des partenaires à des sous-événements uniques plutôt qu'à des événements entiers. Néanmoins, ce sont des situations relativement rares, nous allons donc laisser cette partie du modèle telle quelle.

Section 2 :Spectacles, interprètes et équipement

Comme mentionné dans l'introduction, chaque événement peut avoir plusieurs sous-événements. Dans ce modèle, j'ai décidé d'appeler les sous-événements "spectacles". Un spectacle est un sous-événement unique, axé sur un sujet, ayant au moins un interprète, etc. Dans un événement de conférence informatique, un spectacle peut être une conférence sur les principes de gestion de projet ; une autre émission pourrait être une table ronde sur les meilleures pratiques d'entreposage de données. Les deux pourraient avoir lieu en même temps, dans des lieux différents, et être animés par des présentateurs différents. On définira aussi tout ce qu'il faut pour faire tourner un show, car le show doit continuer (de toute façon ☺ ).

Le tableau central de cette section est le show table. Cela gardera un enregistrement de tout spectacle associé à des événements passés, présents et futurs. Lorsque nous planifions un événement, nous devrons ajouter de nouveaux spectacles dès que l'artiste (c'est-à-dire conférencier, conférencier, présentateur, rock star) aura accepté de faire partie d'un événement. La description des attributs du tableau nous aidera à comprendre son fonctionnement :

show_name – Le nom de l'émission.
show_location - Décrit où le spectacle aura lieu.
show_description – Une description détaillée de ce spectacle.
start_time – L'heure de début prévue.
end_time – L'heure de fin prévue. Il peut être NULL car nous pouvons entrer l'heure de fin réelle (une fois l'émission terminée) plutôt que l'heure de fin prévue.
event_id – À quel événement le spectacle fait-il partie ?

Dans la plupart des cas, les spectacles nécessiteront du matériel et des artistes. (Théoriquement, nous pourrions avoir un spectacle sans artiste, mais nous ne nous en soucierons pas ici.) Parce que l'équipement est limité, il est important de réserver tout ce qui est nécessaire dans la phase de planification de l'événement. Pour le faire correctement, nous devons savoir ce qui va se passer à quel moment. Par exemple, si nous avons deux projecteurs et deux spectacles nécessitant des projecteurs programmés à la même heure, nous ne pouvons pas ajouter un troisième spectacle nécessitant un projecteur pour cette période à moins que nous n'obtenions plus d'équipement. C'est le genre d'informations que nous devons avoir dans la phase de planification.

Passons à autre chose, nous avons le performer table. Il s'agit d'un simple catalogue de tous les artistes avec lesquels nous avons travaillé ou travaillerons avec n'importe quel événement. Pour chaque artiste, nous stockerons son full_name . Cela peut être le nom d'un groupe, d'un conférencier, etc. Le genre L'attribut est ici pour distinguer les différents types d'interprètes - par ex. groupes de rock de sculpteurs. Le dernier attribut de ce tableau stocke les contact_details des intervenants . Nous utiliserons le type de données texte pour stocker le lot, mais nous pourrions également diviser les coordonnées en quelques champs distincts.

Nous mettrons en relation les spectacles et les artistes via le participate table. Les attributs de ce tableau sont :

show_id et performer_id – Références au spectacle associé et à l'interprète. Cette paire pourrait être une clé alternative (unique) de la table mais j'ai décidé de ne pas l'utiliser; nous pourrions avoir un artiste faisant partie du même spectacle à deux moments différents.
start_time et end_time – Heures exactes qui définissent quand cet artiste faisait partie de ce spectacle.
cost_planned et cost_actual – Les coûts/honoraires que nous nous attendons à payer à un artiste et ce que nous lui avons réellement payé.

Les trois tableaux restants permettent de définir tout l'équipement nécessaire pour un spectacle.

Le equipment_type dictionnaire catégorise les équipements. Pour un concert, ces catégories pourraient être "équipement d'éclairage", "instruments de musique", "construction de scène", etc. Le type_name l'attribut ne contient que des valeurs UNIQUES.

Le equipment le tableau décrit les éléments d'équipement et les quantités. Son name l'attribut définit l'équipement plus précisément que equipment_type .type_name . Pour une boule disco, sa valeur "equipment"."name" serait "disco ball" mais son "equipment_type"."type_name" serait "lighting equipment". Le available L'attribut définit la quantité de l'article qui nous est disponible. C'est un nombre décimal parce que nous utiliserons peut-être des "éléments" qui ne peuvent pas être énumérés, comme l'eau et l'électricité.

Le dernier tableau de cette section concerne les équipements et les spectacles. Cela peut nous aider à organiser l'équipement dans la phase de planification ; cela nous permet également de créer ultérieurement des rapports sur les coûts d'équipement. Lorsque nous planifions l'utilisation et les coûts de l'équipement, ces informations peuvent s'avérer très utiles, en particulier pour les événements récurrents (ou très similaires). Les attributs dans le required le tableau sont :

show_id et equipment_id – Désigne le spectacle et les équipements associés. Cette paire forme la clé UNIQUE de la table.
quantity – La quantité de cet équipement nécessaire.
cost_planned et cost_actual – Ce que nous prévoyons de payer pour l'installation ou la location d'équipement et ce que nous avons réellement payé.

Section 3 :Employés

Le domaine de ce modèle concerne les employés et leurs rôles. J'aime toujours souligner que les gens et leur temps sont la partie la plus importante de tout projet. Tout le reste n'est qu'un outil pour faire un travail. (Et cet outil a également été créé par des gens, en utilisant leur temps. ☺ )

Je n'expliquerai pas le employee , role et has_role tableaux ici. Je l'ai fait plusieurs fois auparavant, par exemple dans cet article. Si vous en avez besoin, veuillez le consulter.

Le tableau final de notre modèle relie les employés et les rôles aux émissions. Nous pouvons nous attendre à avoir un nombre limité d'employés qualifiés et nous devrons nous assurer qu'ils seront disponibles en cas de besoin. Évidemment, la même personne ne peut pas être à deux endroits différents en même temps. Les attributs du engaged le tableau sont :

show_id et has_role_id – Fait référence à l'émission associée et au rôle de l'employé.
start_time – Quand nous nous attendons à ce qu'un employé commence ce rôle.
end_time – Lorsque ce rôle se termine. Ceci est nullable car dans la plupart des cas, nous attribuerons une valeur une fois que l'employé aura terminé son rôle. Cependant, nous pouvons entrer une heure de fin prévue ici.
cost_planned et cost_actual – Ce que nous nous attendons à payer à un employé pour assumer ce rôle et ce que nous avons réellement payé.

Encore une fois, je soulignerai simplement que ces données historiques peuvent être très utiles lorsque vous organisez un événement récurrent ou similaire à un événement passé.

Aujourd'hui, nous avons discuté d'un modèle de données possible pour une base de données de gestion d'événements. Nous avons couvert les choses vraiment importantes, comme la description de l'événement, la programmation des artistes et l'affectation des employés et des ressources à l'événement. La gestion des coûts dans ce modèle est simplifiée, mais il nous offre toujours la possibilité de calculer les coûts prévus et réels par catégorie, événement, spectacle ou type d'équipement.

Je ne suis pas un gestionnaire d'événements. Si c'est le cas, j'espère que vous avez trouvé cet article très utile. Mais j'aimerais entendre vos commentaires sur les ajouts ou les changements qui pourraient être utiles dans des situations réelles.

Bien sûr, tout le monde est invité à soumettre ses suggestions et ses idées dans la section des commentaires.