En Event Management Data Model

At arrangere et arrangement er meget arbejde! I denne artikel undersøger vi datamodellen bag en app til eventorganisation.

Hvis du nogensinde har prøvet at organisere en begivenhed for mere end ti personer (og tæl ikke fester eller forretningsmøder med her), ved du, hvor kompliceret eventstyring kan være! Har vi inviteret alle? Har de bekræftet, om de kommer? Er lokalet booket og forberedt? Hvem skal være vært for arrangementet? Hvem skal deltage i de forskellige dele? Der er mange andre spørgsmål at besvare, og det kan nemt gå galt.

Du kan lave al din planlægning med papir og pen, men hvorfor ikke bruge en app? Det er mere praktisk! Enhver app skal have et sted til at gemme alle de nødvendige begivenhedsoplysninger. Det er her, vores event management datamodel kommer ind i denne historie. Snup en kop kaffe, sæt dig ned i din yndlingsstol, så ser vi på, hvad der skal til for at bygge en datamodel for eventstyring.

Ofte stillede spørgsmål om begivenhedsstyring

Inden vi forklarer modellen og beskriver, hvordan vi gemmer dataene, lad os først gennemgå nogle grundlæggende principper for eventstyring:

Hvad kan betragtes som en begivenhed?

I denne sammenhæng er et arrangement en lejlighed, hvor mange mennesker, som ofte ikke kender hinanden, samles for at lære om eller deltage i noget. Nogle populære begivenheder er musikfestivaler eller koncerter, IT-konferencer, sportsbegivenheder som fodboldkampe, sundheds- og lægekonferencer osv.
Hvad har alle begivenheder til fælles?

De tidligere nævnte begivenhedseksempler er meget forskellige med hensyn til indhold, formål og målgruppe. Alligevel deler de mange ligheder, især i deres organisation.

Overvej først begivenhedens indhold. Nogle begivenheder (f.eks. en koncert eller en fodboldkamp) vil kun give én type indhold og afholdes ét sted. Andre begivenheder omfatter mange forskellige, men relaterede "underbegivenheder", som kan forekomme forskellige steder.

Tag en it-konference som et eksempel på den anden type arrangement. Der er foredrag, præsentationer, workshops og konkurrencer. Deltagerne vil sandsynligvis gå fra rum til rum eller kan endda rejse mellem forskellige bygninger, når de går til forskellige underbegivenheder. Nogle af disse underbegivenheder vil køre på samme tid, men hver underbegivenhed er stadig relateret til IT og har en eller flere værter.
Hvad skal der til for at gøre en begivenhed vellykket?

Først og fremmest er der mange personale, der arbejder hårdt i baggrunden:audio- og billedteknikere, billetsælgere, betjente, rengørings- og vedligeholdelsesarbejdere og administrativt personale. Mange mennesker i mange forskellige roller vil bruge mange timer på at arbejde hårdt for at gøre scenen klar til "stjernerne" og andre deltagere, men ingen af dem vil få meget anerkendelse.

Det er klart, at alle begivenheder kræver en eller anden form for infrastruktur. Hvis vi afholder en konference et fysisk sted, taler vi om lokaler og sæder, et lydsystem, lys, måske video osv. Selv et online arrangement, som et webinar, skal have et sted at producere indholdet og IT-opsætning er nødvendig for at forbinde med virtuelle deltagere.

Begivenheder har normalt mediesponsorer og partnere, der hjælper med at organisere og promovere dem. Disse sponsorer er for det meste virksomheder og foreninger relateret til arrangementets emne; nogle gange er de andre virksomheder, der leder efter noget god omtale; og mere sjældent vil en privatperson fungere som sponsor eller partner.
Hvad er event management?

Event management er en proces, der bruges til effektivt at styre begivenheder og alt relateret til dem. Det kunne betragtes som en form for projektledelse. Vi diskuterede en projektledelsesdatamodel i denne artikel. Det er ikke en dårlig idé at bruge et Gantt-diagram til at vise begivenhedens fremskridt, nuværende status og fremtidige handlinger.

Vi vil sandsynligvis gerne have, at vores event management-applikation passer på én skærm, hvis det er muligt. De fleste handlinger – som at oprette et nyt show, tildele medarbejdere og ressourcer til en opgave eller estimere omkostninger – bør være træk og slip.

Datamodellen

Datamodellen består af tre hovedfagområder:

Events and Partners
Shows, Performers and Equipment
Employees

Vi vil se nærmere på hvert emneområde i den rækkefølge, de er anført.

Afsnit 1:Begivenheder og partnere

Events and Partners fagområdet er den centrale del af vores model. I disse fem tabeller gemmer vi de vigtigste detaljer om vores begivenheder. Vi vil også relatere begivenheder til partnere.

Lad os starte med event bord. Dette viser enhver begivenhed, vi har arrangeret, og alle begivenheder, vi planlægger at arrangere. Attributterne i denne tabel er:

event_name – Navnet på en begivenhed. Det er ikke UNIKT, fordi vi kan have to eller flere arrangementer med samme navn - f.eks. en koncert med det samme band ville have samme begivenhedsnavn. Men event_name – start_time par skal være UNIK.
event_type_id – Henviser til event_type ordbog.
event_location – Beskriver det sted, hvor begivenheden finder sted. Ved at bruge en beskrivende attribut kan vi undgå at bygge en mere kompleks model med tabeller som "land" og "by" og attributter som "adresse" og "beskrivelse".
event_description – En detaljeret beskrivelse af begivenheden og alle shows eller aktiviteter forbundet med den. Til en koncert er det her, vi gemmer oplysninger om åbningsakten, hovedakten, eventuelle ekstra entertainere og opførelsesrækkefølgen.
start_time – Hvornår begivenheden starter. Det er obligatorisk, fordi vi bør vide dette i planlægningsfasen.
end_time – Når arrangementet slutter. Vi kunne bruge denne attribut til at gemme det forventede eller faktiske sluttidspunkt for hændelsen. Da vi muligvis ikke kender dette nøjagtige tidspunkt på forhånd (f.eks. hvis en sportskamp går i overtid), er denne egenskab valgfri.

event_type ordbog klassificerer de begivenheder, vi håndterer. Vi gemmer alle mulige typer begivenheder i henhold til deres niche:koncert, fodboldkamp, basketballkamp, IT-konference osv. Hver begivenhedstype er unikt defineret af dens type_name .

Som vi tidligere har nævnt, har arrangementer normalt partnere. De fleste arrangementer vil som minimum have en mediepartner, mens nogle også vil have sponsorer og andre partnere. Den samme partner kunne have flere forskellige "partnerroller" på den samme begivenhed. For eksempel kan et tv-selskab være mediepartner og hovedsponsor for arrangementet på samme tid. Det er derfor, vi vil bruge tre tabeller til at relatere begivenheder med partnere.

Det er vigtigt at kunne tilføje partnere i planlægningsfasen, så alle eventinteressenter kan få rettidig adgang til den info. Vi kan også bruge tidligere data, når vi planlægger nye begivenheder - f.eks. vi kan kontakte den samme partner, når vi arrangerer et tilbagevendende arrangement eller et nyt arrangement af samme type. Hvis en virksomhed var generalsponsor for en teknologikonference sidste år, kan de være interesserede i at gøre det igen i år.

Lad os nu se på de tre partnerskabstabeller. Den første er partner katalog. For hver partner gemmer vi partner_name og deres adresse, kontaktoplysninger og andre partner_details . Bemærk, at partner_name egenskaben er ikke unik. Vi kan have to partnere med samme navn, såsom to privatpersoner med samme for- og efternavn eller to virksomheder med samme firmanavn. I dette tilfælde skelner vi mellem dem ved hjælp af de oplysninger, der er gemt i partner_details attribut.

Den anden tabel er partner_role ordbog, som viser alle de forskellige roller, en partner kunne have. role_name attribut vil kun indeholde UNIKKE værdier. Nogle forventede rollenavne er "mediepartner", "generel sponsor" og "sponsor".

Den sidste tabel i dette emneområde relaterer partnere til arrangementer. is_partner tabel indeholder kun fremmednøgler, der relaterer partnere til begivenheder og definerer roller eller partnerskabstyper. Kombinationen af disse fremmednøgler danner tabellens UNIKKE nøgle. Hvis vi ville, kunne vi tilføje en startdato og en slutdato, hvis en partner kun udfylder deres rolle for en del af begivenheden. Vi kunne også relatere partnere til enkelte underbegivenheder og frem for hele arrangementer. Alligevel er dette relativt ualmindelige situationer, så vi lader denne del af modellen være som den er.

Afsnit 2:Shows, kunstnere og udstyr

Som nævnt i indledningen kan hvert arrangement have flere underarrangementer. I denne model har jeg besluttet at kalde underbegivenhederne for "shows". Et show er en enkelt underbegivenhed, fokuseret på ét emne, med mindst én performer osv. I en IT-konferencebegivenhed kunne ét show være et foredrag om projektledelsesprincipper; et andet show kunne være en paneldiskussion af bedste praksis inden for data warehousing. Begge kunne finde sted på samme tid, forskellige steder, og være vært for forskellige oplægsholdere. Vi definerer også alt, hvad der er nødvendigt for at køre et show, for showet skal fortsætte (i alle tilfælde ☺ ).

Den centrale tabel i dette afsnit er show bord. Dette vil føre en registrering af ethvert show, der er forbundet med tidligere, nuværende og fremtidige begivenheder. Når vi planlægger en begivenhed, bliver vi nødt til at tilføje nye shows, så snart den optrædende (dvs. foredragsholder, foredragsholder, oplægsholder, rockstjerne) har sagt ja til at være en del af en begivenhed. At se på en beskrivelse af tabellens attributter vil hjælpe os med at forstå, hvordan det fungerer:

show_name – Navnet på showet.
show_location – Beskriver, hvor showet finder sted.
show_description – En detaljeret beskrivelse af det show.
start_time – Det forventede starttidspunkt.
end_time – Det forventede sluttidspunkt. Det kan være NULL, fordi vi kan indtaste det faktiske sluttidspunkt (når showet er slut) i stedet for det forventede sluttidspunkt.
event_id – Hvilken begivenhed showet er en del af.

I de fleste tilfælde vil shows kræve udstyr og kunstnere. (Teoretisk set kunne vi have et show uden en performer, men det vil vi ikke bøvle med her.) Fordi udstyret er begrænset, er det vigtigt at reservere alt, hvad der er nødvendigt i arrangementets planlægningsfase. For at gøre dette ordentligt skal vi vide, hvad der skal ske på hvilket tidspunkt. For eksempel, hvis vi har to projektorer og to shows, der kræver projektorer planlagt til samme tid, kan vi ikke tilføje et tredje projektor-krævende show for den tid, medmindre vi får mere udstyr. Det er den slags information, vi skal have i planlægningsfasen.

Når vi går videre, har vi performer bord. Dette er et simpelt katalog over alle de optrædende, vi har arbejdet med eller vil arbejde sammen med til enhver begivenhed. For hver kunstner gemmer vi deres full_name . Det kan være navnet på et band, en foredragsholder osv. genre attribut er her for at skelne mellem de forskellige typer udøvende kunstnere – f.eks. rockbands fra billedhuggere. Den sidste egenskab i denne tabel gemmer kunstnernes contact_details . Vi bruger tekstdatatypen til at gemme partiet, men vi kan også opdele kontaktoplysninger i et par separate felter.

Vi vil relatere shows og optrædende via participate bord. Attributterne i denne tabel er:

show_id og performer_id – Referencer til det relaterede show og den optrædende. Dette par kunne være en alternativ (unik) nøgle til bordet, men jeg besluttede ikke at bruge det; vi kan have en kunstner til at være en del af det samme show på to forskellige tidspunkter.
start_time og end_time – Præcis tidspunkter, der definerer, hvornår den optrædende var en del af det show.
cost_planned og cost_actual – De omkostninger/honorarer, vi forventer at betale en kunstner, og hvad vi rent faktisk har betalt dem.

De resterende tre tabeller bruges til at definere alt det nødvendige udstyr til et show.

equipment_type ordbog kategoriserer udstyr. For en koncert kunne disse kategorier være "lysudstyr", "musikinstrumenter", "scenekonstruktion" osv. type_name attribut indeholder kun UNIKKE værdier.

equipment tabel beskriver udstyrsartikler og mængder. Dens name attribut definerer udstyret mere specifikt end equipment_type .type_name . For en diskokugle ville dens "udstyr".."navn"-værdi være "diskokugle", men dens "udstyrstype".."type_navn" ville være "belysningsudstyr". Den available attribut definerer, hvilken mængde af varen der er tilgængelig for os. Det er et decimaltal, fordi vi måske bruger nogle "elementer", som ikke kan optælles, såsom vand og elektricitet.

Den sidste tabel i dette afsnit vedrører udstyr og shows. Dette kan hjælpe os med at organisere udstyr i planlægningsfasen; det giver os også mulighed for senere at lave rapporter om udstyrsomkostninger. Når vi planlægger udstyrsbrug og -omkostninger, kan disse oplysninger være meget nyttige, især til tilbagevendende (eller meget lignende) begivenheder. Attributterne i required tabellen er:

show_id og equipment_id – Henviser til det relaterede show og udstyr. Dette par danner tabellens UNIKKE nøgle.
quantity – Mængden af det nødvendige udstyr.
cost_planned og cost_actual – Hvad vi forventer at betale for at installere eller leje udstyr, og hvad vi faktisk har betalt.

Afsnit 3:Medarbejdere

Denne models emneområde handler om medarbejdere og deres roller. Jeg elsker altid at påpege, at mennesker og deres tid er den vigtigste del af ethvert projekt. Alt andet er bare et værktøj til at udføre et arbejde. (Og det værktøj blev også lavet af folk, der brugte deres tid. ☺ )

Jeg vil ikke forklare employee , role og has_role tabeller her. Jeg har gjort det mange gange før, for eksempel i denne artikel. Hvis du har brug for det, bedes du gennemgå det.

Finaletabellen i vores model relaterer medarbejdere og roller til shows. Vi kan forvente at have et begrænset antal kvalificerede medarbejdere, og vi skal være sikre på, at de vil være tilgængelige, når det er nødvendigt. Det er klart, at den samme person ikke kan være to forskellige steder på samme tid. Attributterne i engaged tabellen er:

show_id og has_role_id – Refererer til det relaterede show og medarbejderrolle.
start_time – Når vi forventer, at en medarbejder starter den rolle.
end_time – Når den rolle slutter. Dette er nullbart, fordi vi i de fleste tilfælde tildeler en værdi, efter at medarbejderen har afsluttet sin rolle. Vi kan dog angive et forventet sluttidspunkt her.
cost_planned og cost_actual – Hvad vi forventer at betale en medarbejder for at håndtere den rolle, og hvad vi rent faktisk har betalt.

Endnu en gang vil jeg lige påpege, at disse historiske data kan være meget nyttige, når du organiserer en gentagelsesbegivenhed eller en, der ligner en tidligere begivenhed.

I dag har vi diskuteret en mulig datamodel for en event management database. Vi har dækket de virkelig vigtige ting, som at beskrive begivenheden, planlægge kunstnere og tildele medarbejdere og ressourcer til begivenheden. Håndteringen af omkostninger i denne model er forenklet, men den giver os stadig mulighed for at beregne planlagte og faktiske omkostninger efter kategori, begivenhed, show eller udstyrstype.

Jeg er ikke event manager. Hvis du er, håber jeg, at du har fundet denne artikel meget nyttig. Men jeg vil gerne høre din feedback om, hvilke tilføjelser eller ændringer der kunne være nyttige i virkelige situationer.

Alle er selvfølgelig velkomne til at indsende deres forslag og ideer i kommentarfeltet.