Een gegevensmodel voor gebeurtenisbeheer

Een evenement organiseren is veel werk! In dit artikel onderzoeken we het datamodel achter een app voor evenementenorganisatie.

Als je ooit hebt geprobeerd een evenement voor meer dan tien personen te organiseren (en feesten of zakelijke bijeenkomsten hier niet meerekent), weet je hoe ingewikkeld evenementenbeheer kan zijn! Hebben we iedereen uitgenodigd? Hebben ze al bevestigd of ze komen? Is de locatie geboekt en voorbereid? Wie zal het evenement hosten? Wie neemt er deel aan de verschillende onderdelen? Er zijn nog veel meer vragen te beantwoorden, en er kan gemakkelijk iets mis gaan.

Je kunt al je planning met papier en pen doen, maar waarom zou je geen app gebruiken? Het is handiger! Elke app heeft een plek nodig om alle benodigde evenementinformatie op te slaan. Dit is waar ons datamodel voor evenementenbeheer dit verhaal binnenkomt. Pak een kopje koffie, ga zitten in je favoriete stoel en we bekijken wat er nodig is om een datamodel voor evenementenbeheer te bouwen.

Veelgestelde vragen over evenementbeheer

Voordat we het model uitleggen en beschrijven hoe we de gegevens opslaan, laten we eerst enkele basisprincipes van gebeurtenisbeheer bekijken:

Wat kan als een evenement worden beschouwd?

In deze context is een evenement een gelegenheid waar veel mensen, die elkaar vaak niet kennen, samenkomen om iets te leren of eraan deel te nemen. Sommige populaire evenementen zijn muziekfestivals of concerten, IT-conferenties, sportevenementen zoals voetbalwedstrijden, gezondheids- en medische conferenties, enz.
Wat hebben alle evenementen gemeen?

De eerder genoemde evenementenvoorbeelden verschillen qua inhoud, doel en doelgroep erg van elkaar. Toch delen ze veel overeenkomsten, vooral in hun organisatie.

Overweeg eerst de inhoud van het evenement. Sommige evenementen (bijvoorbeeld een concert of een voetbalwedstrijd) bieden slechts één type inhoud en worden op één plaats gehouden. Andere gebeurtenissen omvatten veel verschillende maar gerelateerde "subgebeurtenissen", die op verschillende plaatsen kunnen plaatsvinden.

Neem een IT-conferentie als voorbeeld van het tweede type evenement. Er zijn lezingen, presentaties, workshops en wedstrijden. Bezoekers zullen waarschijnlijk van kamer naar kamer gaan of zelfs tussen verschillende gebouwen reizen als ze naar verschillende sub-evenementen gaan. Sommige van deze sub-evenementen zullen tegelijkertijd plaatsvinden, maar elk sub-evenement heeft nog steeds betrekking op IT en heeft een of meer hosts.
Wat is er nodig om een evenement tot een succes te maken?

Allereerst is er veel personeel van evenementenlocaties dat hard op de achtergrond werkt:audio- en visuele technici, kaartverkopers, bodes, schoonmaak- en onderhoudsmedewerkers en administratief personeel. Veel mensen in veel verschillende rollen zullen vele uren hard werken om het podium klaar te maken voor de "sterren" en andere deelnemers, maar geen van hen zal veel erkenning krijgen.

Het is duidelijk dat alle evenementen een soort infrastructuur vereisen. Als we een conferentie op een fysieke locatie houden, hebben we het over kamers en stoelen, een geluidssysteem, verlichting, misschien video, enz. Zelfs een online evenement, zoals een webinar, moet een plek hebben om de inhoud en de IT-configuratie nodig om verbinding te maken met virtuele deelnemers.

Evenementen hebben meestal mediasponsors en partners die helpen bij het organiseren en promoten ervan. Deze sponsors zijn meestal bedrijven en verenigingen die te maken hebben met het evenementonderwerp; af en toe zijn het andere bedrijven die op zoek zijn naar goede publiciteit; en meer zelden zal een particulier als sponsor of partner optreden.
Wat is evenementbeheer?

Evenementbeheer is een proces dat wordt gebruikt om evenementen en alles wat daarmee samenhangt effectief te beheren. Het kan worden beschouwd als een vorm van projectmanagement. In dit artikel hebben we een projectmanagementdatamodel besproken. Het is geen slecht idee om een Gantt-diagram te gebruiken om de voortgang van het evenement, de huidige status en toekomstige acties weer te geven.

We willen waarschijnlijk dat onze applicatie voor evenementbeheer, indien mogelijk, op één scherm past. De meeste acties, zoals het maken van een nieuwe show, het toewijzen van medewerkers en middelen aan een taak of het schatten van kosten, moeten slepen en neerzetten zijn.

Het gegevensmodel

Het datamodel bestaat uit drie hoofdonderwerpen:

Events and Partners
Shows, Performers and Equipment
Employees

We zullen elk onderwerp nader bekijken in de volgorde waarin ze zijn vermeld.

Sectie 1:Evenementen en partners

De Events and Partners onderwerp is het centrale deel van ons model. In deze vijf tabellen slaan we de belangrijkste details over onze evenementen op. We zullen ook evenementen met partners in verband brengen.

Laten we beginnen met het event tafel. Dit geeft een overzicht van elk evenement dat we hebben georganiseerd en elk evenement dat we van plan zijn te organiseren. De kenmerken in deze tabel zijn:

event_name – De naam van een evenement. Het is niet UNIEK omdat we twee of meer evenementen met dezelfde naam kunnen hebben - b.v. een concert van dezelfde band zou dezelfde evenementnaam hebben. Echter, de event_name – start_time paar moet UNIEK zijn.
event_type_id – Verwijst naar het event_type woordenboek.
event_location – Beschrijft de locatie waar het evenement zal plaatsvinden. Door een beschrijvend attribuut te gebruiken, kunnen we voorkomen dat we een complexer model bouwen met tabellen zoals 'land' en 'stad' en attributen zoals 'adres' en 'beschrijving'.
event_description – Een gedetailleerde beschrijving van het evenement en alle bijbehorende shows of activiteiten. Voor een concert slaan we hier informatie op over de openingsact, de hoofdact, eventuele extra entertainers en de uitvoeringsvolgorde.
start_time – Wanneer het evenement begint. Het is verplicht omdat we dit in de planningsfase zouden moeten weten.
end_time – Wanneer het evenement eindigt. We kunnen dit kenmerk gebruiken om de verwachte of werkelijke eindtijd van de gebeurtenis op te slaan. Aangezien we deze exacte tijd misschien niet van tevoren weten (bijvoorbeeld als een sportwedstrijd overuren gaat), is dit kenmerk optioneel.

Het event_type woordenboek classificeert de gebeurtenissen die we afhandelen. We slaan alle mogelijke soorten evenementen op volgens hun niche:concert, voetbalwedstrijd, basketbalwedstrijd, IT-conferentie, enz. Elk type evenement wordt uniek gedefinieerd door zijn type_name .

Zoals we eerder vermeldden, hebben evenementen meestal partners. De meeste evenementen hebben ten minste een mediapartner, terwijl sommige ook sponsors en andere partners hebben. Dezelfde partner kan verschillende "partnerrollen" hebben op hetzelfde evenement. Een televisieomroeporganisatie kan bijvoorbeeld tegelijkertijd de mediapartner en de hoofdsponsor van het evenement zijn. Daarom gebruiken we drie tabellen om gebeurtenissen met partners te relateren.

Het is belangrijk om in de planningsfase partners toe te kunnen voegen, zodat alle belanghebbenden van het evenement tijdig toegang hebben tot die informatie. We kunnen ook gegevens uit het verleden gebruiken wanneer we nieuwe evenementen plannen, bijv. we kunnen dezelfde partner contacteren wanneer we een terugkerend evenement organiseren of een nieuw evenement van hetzelfde type. Als een bedrijf vorig jaar algemene sponsor was van een technische conferentie, is het misschien interessant om het dit jaar opnieuw te doen.

Laten we nu eens kijken naar de drie partnertabellen. De eerste is de partner catalogus. Voor elke partner slaan we de partner_name op en hun adres, contactgegevens en andere partner_details . Merk op dat de partner_name attribuut is niet uniek. We kunnen twee partners hebben met dezelfde naam, zoals twee particulieren met dezelfde voor- en achternaam of twee bedrijven met dezelfde bedrijfsnaam. In dit geval zullen we ze onderscheiden met behulp van de informatie die is opgeslagen in de partner_details attribuut.

De tweede tabel is de partner_role woordenboek, waarin alle verschillende rollen die een partner kan hebben, worden opgesomd. De role_name attribuut zal alleen UNIEKE waarden bevatten. Sommige verwachte rolnamen zijn "mediapartner", "algemene sponsor" en "sponsor".

De laatste tabel in dit vakgebied brengt partners in contact met evenementen. De is_partner tabel bevat alleen externe sleutels die partners relateren aan gebeurtenissen en rollen of partnerschapstypen definiëren. De combinatie van deze externe sleutels vormt de UNIEKE sleutel van de tabel. Als we zouden willen, kunnen we een startdatum en een einddatum toevoegen voor het geval een partner zijn rol slechts voor een deel van het evenement vervult. We zouden partners ook kunnen relateren aan afzonderlijke sub-evenementen en in plaats van hele evenementen. Toch zijn dit relatief ongebruikelijke situaties, dus laten we dit deel van het model ongewijzigd.

Sectie 2:Shows, artiesten en uitrusting

Zoals vermeld in de inleiding, kan elk evenement meerdere sub-evenementen hebben. In dit model heb ik besloten om de sub-evenementen "shows" te noemen. Een show is een enkel subevenement, gericht op één onderwerp, met ten minste één artiest, enz. In een IT-conferentiegebeurtenis kan één show een lezing zijn over projectmanagementprincipes; een andere show zou een paneldiscussie kunnen zijn over best practices op het gebied van datawarehousing. Beide kunnen tegelijkertijd plaatsvinden, op verschillende locaties, en worden gehost door verschillende presentatoren. We zullen ook alles definiëren wat nodig is om een show te laten draaien, want de show moet doorgaan (in ieder geval ☺ ).

De centrale tabel van deze sectie is de show tafel. Hiermee wordt een overzicht bijgehouden van elke show die verband houdt met eerdere, huidige en toekomstige evenementen. Als we een evenement plannen, moeten we nieuwe shows toevoegen zodra de artiest (d.w.z. docent, spreker, presentator, rockster) ermee heeft ingestemd om deel uit te maken van een evenement. Als we naar een beschrijving van de attributen van de tabel kijken, kunnen we begrijpen hoe deze werkt:

show_name – De naam van de show.
show_location – Beschrijft waar de show zal plaatsvinden.
show_description – Een gedetailleerde beschrijving van die show.
start_time – De verwachte starttijd.
end_time – De verwachte eindtijd. Het kan NULL zijn omdat we de werkelijke eindtijd kunnen invoeren (zodra de show voorbij is) in plaats van de verwachte eindtijd.
event_id – Van welk evenement de show deel uitmaakt.

In de meeste gevallen zullen voor shows apparatuur en artiesten nodig zijn. (Theoretisch zouden we een show kunnen hebben zonder artiest, maar daar gaan we ons hier niet druk om maken.) Omdat de apparatuur beperkt is, is het belangrijk om alles te reserveren wat nodig is in de planningsfase van het evenement. Om dit goed te kunnen doen, moeten we weten wat er op welk moment gaat gebeuren. Als we bijvoorbeeld twee projectoren hebben en twee shows waarvoor projectoren zijn gepland voor dezelfde tijd, kunnen we voor die tijd geen derde projector toevoegen, tenzij we meer apparatuur krijgen. Dit is het soort informatie dat we moeten hebben in de planningsfase.

Verderop hebben we de performer tafel. Dit is een eenvoudige catalogus van elke artiest waarmee we hebben gewerkt of waarmee we zullen werken op elk evenement. Voor elke artiest slaan we hun full_name op . Het kan de naam zijn van een band, een docent, enz. Het genre attribuut is hier om onderscheid te maken tussen de verschillende soorten artiesten - b.v. rockbands van beeldhouwers. Het laatste attribuut in deze tabel slaat contact_details van de artiesten op . We gebruiken het tekstgegevenstype om de kavel op te slaan, maar we kunnen contactgegevens ook opsplitsen in een paar afzonderlijke velden.

We zullen shows en artiesten met elkaar in verband brengen via de participate tafel. De kenmerken in deze tabel zijn:

show_id en performer_id – Verwijzingen naar de gerelateerde show en de artiest. Dit paar zou een alternatieve (unieke) sleutel van de tafel kunnen zijn, maar ik besloot het niet te gebruiken; we kunnen een artiest op twee verschillende tijdstippen deel laten uitmaken van dezelfde show.
start_time en end_time – Exacte tijden die bepalen wanneer die artiest deel uitmaakte van die show.
cost_planned en cost_actual – De kosten/vergoedingen die we een artiest verwachten te betalen en wat we ze daadwerkelijk hebben betaald.

De overige drie tabellen worden gebruikt om alle apparatuur te definiëren die nodig is voor een show.

De equipment_type woordenboek categoriseert apparatuur. Voor een concert kunnen deze categorieën zijn:"verlichtingsapparatuur", "muziekinstrumenten", "podiumconstructie", enz. De type_name attribuut bevat alleen UNIEKE waarden.

De equipment tabel beschrijft uitrustingsitems en hoeveelheden. Zijn name attribuut definieert de apparatuur specifieker dan equipment_type .type_name . Voor een discobal zou de waarde voor "apparatuur"."naam" "discobal" zijn, maar zijn "apparatuurtype"."type_naam" zou "verlichtingsapparatuur" zijn. De available attribuut bepaalt welke hoeveelheid van het artikel voor ons beschikbaar is. Het is een decimaal getal, want misschien gebruiken we enkele "items" die niet kunnen worden opgeteld, zoals water en elektriciteit.

De laatste tabel in deze sectie heeft betrekking op apparatuur en shows. Dit kan ons helpen bij het organiseren van apparatuur in de planningsfase; het stelt ons ook in staat om later rapportages te maken over de apparatuurkosten. Wanneer we het gebruik en de kosten van apparatuur plannen, kan deze informatie erg handig zijn, vooral voor terugkerende (of zeer vergelijkbare) evenementen. De attributen in de required tafel zijn:

show_id en equipment_id – Verwijst naar de gerelateerde show en uitrusting. Dit paar vormt de UNIEKE sleutel van de tafel.
quantity – De hoeveelheid van die apparatuur die nodig is.
cost_planned en cost_actual – Wat we verwachten te betalen voor het installeren of huren van apparatuur en wat we daadwerkelijk hebben betaald.

Sectie 3:Werknemers

Het onderwerp van dit model gaat over medewerkers en hun rollen. Ik wijs er altijd graag op dat mensen en hun tijd het belangrijkste onderdeel zijn van elk project. Al het andere is slechts een hulpmiddel om een klus te klaren. (En die tool is ook gemaakt door mensen die hun tijd gebruiken. ☺ )

Ik zal de employee , role en has_role tafels hier. Ik heb het al vaker gedaan, bijvoorbeeld in dit artikel. Bekijk het indien nodig.

De finaletafel in ons model relateert medewerkers en rollen aan shows. We kunnen een beperkt aantal gekwalificeerde medewerkers verwachten en we moeten er zeker van zijn dat ze beschikbaar zullen zijn wanneer dat nodig is. Het is duidelijk dat dezelfde persoon niet tegelijkertijd op twee verschillende plaatsen kan zijn. De attributen in de engaged tafel zijn:

show_id en has_role_id – Verwijst naar de gerelateerde show en werknemersrol.
start_time – Wanneer we verwachten dat een medewerker die rol start.
end_time – Wanneer die rol eindigt. Dit is nullable omdat we in de meeste gevallen een waarde toewijzen nadat de werknemer zijn functie heeft beëindigd. Het is echter mogelijk dat we hier een verwachte eindtijd invoeren.
cost_planned en cost_actual – Wat we een werknemer verwachten te betalen voor het uitvoeren van die rol en wat we daadwerkelijk hebben betaald.

Ik wil er nogmaals op wijzen dat deze historische gegevens erg handig kunnen zijn wanneer u een terugkerend evenement organiseert of een evenement dat lijkt op een evenement uit het verleden.

Vandaag hebben we een mogelijk datamodel voor een eventmanagementdatabase besproken. We hebben de echt belangrijke dingen besproken, zoals het beschrijven van het evenement, het plannen van artiesten en het toewijzen van medewerkers en middelen aan het evenement. De verwerking van kosten in dit model is vereenvoudigd, maar het biedt ons nog steeds de mogelijkheid om geplande en werkelijke kosten te berekenen per categorie, evenement, show of uitrustingstype.

Ik ben geen eventmanager. Als dat zo is, hoop ik dat je dit artikel erg nuttig hebt gevonden. Maar ik zou graag uw feedback horen over welke toevoegingen of wijzigingen nuttig kunnen zijn in praktijksituaties.

Natuurlijk is iedereen welkom om zijn suggesties en ideeën in te dienen in het opmerkingengedeelte.