Un modello di dati di gestione degli eventi

Organizzare un evento è un sacco di lavoro! In questo articolo, esaminiamo il modello di dati alla base di un'app per l'organizzazione di eventi.

Se hai mai provato a organizzare un evento per più di dieci persone (e non contiamo feste o incontri di lavoro qui) sai quanto può essere complicata la gestione degli eventi! Abbiamo invitato tutti? Hanno confermato se stanno arrivando? Il locale è prenotato e preparato? Chi ospiterà l'evento? Chi parteciperà alle varie parti? Ci sono molte altre domande a cui rispondere e le cose potrebbero facilmente andare storte.

Puoi fare tutta la tua pianificazione con carta e penna, ma perché non usare un'app? È più conveniente! Qualsiasi app avrà bisogno di un posto dove archiviare tutte le informazioni necessarie sull'evento. È qui che il nostro modello di dati di gestione degli eventi entra in questa storia. Prendi un caffè, accomodati sulla tua sedia preferita e vedremo cosa serve per costruire un modello di dati di gestione degli eventi.

Domande frequenti sulla gestione degli eventi

Prima di spiegare il modello e descrivere come memorizzeremo i dati, esaminiamo innanzitutto alcune nozioni di base sulla gestione degli eventi:

1. Cosa potrebbe essere considerato un evento?

   In questo contesto, un evento è un'occasione in cui molte persone, che spesso non si conoscono, si riuniscono per conoscere o partecipare a qualcosa. Alcuni eventi popolari sono festival musicali o concerti, conferenze IT, eventi sportivi come partite di calcio, conferenze mediche e sanitarie, ecc.

2. Che cosa hanno in comune tutti gli eventi?

   Gli esempi di eventi menzionati in precedenza sono molto diversi in termini di contenuto, scopo e pubblico di destinazione. Tuttavia, condividono molte somiglianze, specialmente nella loro organizzazione.

   Innanzitutto, considera il contenuto dell'evento. Alcuni eventi (ad esempio un concerto o una partita di calcio) forniranno un solo tipo di contenuto e si terranno in un unico luogo. Altri eventi includono molti "sottoeventi" diversi ma correlati, che possono verificarsi in vari luoghi.

   Prendi una conferenza IT come esempio del secondo tipo di evento. Ci sono conferenze, presentazioni, workshop e concorsi. I partecipanti probabilmente andranno da una stanza all'altra o potrebbero persino viaggiare tra edifici diversi mentre partecipano a vari eventi secondari. Alcuni di questi eventi secondari verranno eseguiti contemporaneamente, ma ogni evento secondario è comunque correlato all'IT e ha uno o più host.

3. Cosa serve per il successo di un evento?

   Prima di tutto, ci sono molti membri del personale della sede dell'evento che lavorano sodo in background:tecnici audio e visivi, venditori di biglietti, uscieri, addetti alle pulizie e alla manutenzione e personale amministrativo. Molte persone in molti ruoli diversi trascorreranno molte ore a lavorare sodo per preparare il palco per le "star" e gli altri partecipanti, ma nessuno di loro riceverà molto riconoscimento.

   Chiaramente, tutti gli eventi richiedono un qualche tipo di infrastruttura. Se teniamo una conferenza in un luogo fisico, parleremo di stanze e posti a sedere, un sistema audio, illuminazione, forse video, ecc. Anche un evento online, come un webinar, deve avere un luogo per produrre il contenuto e il Configurazione IT necessaria per connettersi con partecipanti virtuali.

   Gli eventi di solito hanno sponsor e partner dei media che aiutano a organizzarli e promuoverli. Questi sponsor sono per lo più aziende e associazioni legate al tema dell'evento; occasionalmente sono altre aziende in cerca di una buona pubblicità; e più raramente un privato fungerà da sponsor o partner.

4. Cos'è la gestione degli eventi?

   La gestione degli eventi è un processo utilizzato per gestire efficacemente gli eventi e tutto ciò che è ad essi correlato. Potrebbe essere considerato come un tipo di gestione del progetto. In questo articolo abbiamo discusso di un modello di dati di gestione del progetto. Usare un diagramma di Gantt per mostrare l'avanzamento dell'evento, lo stato attuale e le azioni future non è una cattiva idea.

   Probabilmente vorremo che la nostra applicazione di gestione degli eventi si adatti a uno schermo, se possibile. La maggior parte delle azioni, come la creazione di un nuovo spettacolo, l'assegnazione di dipendenti e risorse a un'attività o la stima dei costi, dovrebbero essere trascinate.

Il modello dei dati

Il modello di dati si compone di tre aree tematiche principali:

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

Daremo un'occhiata più da vicino a ciascuna area tematica nell'ordine in cui sono elencate.

Sezione 1:Eventi e partner

Gli Events and Partners l'area tematica è la parte centrale del nostro modello. In queste cinque tabelle memorizzeremo i dettagli più importanti sui nostri eventi. Metteremo in relazione gli eventi anche con i partner.

Cominciamo con l'event tavolo. Questo elenca tutti gli eventi che abbiamo organizzato e tutti gli eventi che prevediamo di organizzare. Gli attributi in questa tabella sono:

• event_name – Il nome di un evento. Non è UNICO perché potremmo avere due o più eventi con lo stesso nome, ad es. un concerto della stessa band avrebbe lo stesso nome dell'evento. Tuttavia, il event_name – start_time la coppia dovrebbe essere UNICA.
• event_type_id – Fa riferimento al event_type dizionario.
• event_location – Descrive il luogo in cui si svolgerà l'evento. L'utilizzo di un attributo descrittivo ci consente di evitare di costruire un modello più complesso con tabelle come "paese" e "città" e attributi come "indirizzo" e "descrizione".
• event_description – Una descrizione dettagliata dell'evento e di tutti gli spettacoli o attività ad esso associati. Per un concerto, è qui che memorizzeremo le informazioni sull'atto di apertura, l'atto principale, eventuali intrattenitori aggiuntivi e l'ordine di esecuzione.
• start_time – Quando inizierà l'evento. È obbligatorio perché dovremmo saperlo in fase di pianificazione.
• end_time – Quando l'evento finisce. Potremmo utilizzare questo attributo per memorizzare l'ora di fine dell'evento prevista o effettiva. Dal momento che potremmo non conoscere questo momento esatto in anticipo (ad es. se un gioco sportivo va ai tempi supplementari), questo attributo è facoltativo.

Il event_type dizionario classifica gli eventi che gestiamo. Conserveremo tutti i possibili tipi di eventi in base alla loro nicchia:concerto, partita di calcio, partita di basket, conferenza IT, ecc. Ogni tipo di evento è definito in modo univoco dal suo type_name .

Come accennato in precedenza, gli eventi di solito hanno dei partner. La maggior parte degli eventi avrà almeno un media partner, mentre alcuni avranno anche sponsor e altri partner. Lo stesso partner potrebbe avere diversi "ruoli partner" nello stesso evento. Ad esempio, una società di trasmissione televisiva potrebbe essere contemporaneamente media partner e sponsor generale dell'evento. Questo è il motivo per cui utilizzeremo tre tabelle per mettere in relazione gli eventi con i partner.

È importante poter aggiungere partner nella fase di pianificazione in modo che tutte le parti interessate all'evento possano avere accesso tempestivo a tali informazioni. Inoltre, potremmo utilizzare i dati passati quando stiamo pianificando nuovi eventi, ad es. potremmo contattare lo stesso partner quando stiamo organizzando un evento ricorrente o un nuovo evento dello stesso tipo. Se un'azienda è stata sponsor generale di una conferenza tecnologica l'anno scorso, potrebbe essere interessata a farlo anche quest'anno.

Ora, diamo un'occhiata alle tre tabelle di partnership. Il primo è il partner Catalogare. Per ogni partner, memorizzeremo il partner_name e il loro indirizzo, informazioni di contatto e altri partner_details . Nota che il partner_name l'attributo non è univoco. Potremmo avere due partner con lo stesso nome, come due privati ​​con lo stesso nome e cognome o due società con la stessa ragione sociale. In questo caso, li distingueremo utilizzando le informazioni memorizzate in partner_details attributo.

La seconda tabella è il partner_role dizionario, che elenca tutti i diversi ruoli che un partner potrebbe avere. Il role_name l'attributo conterrà solo valori UNIQUE. Alcuni nomi di ruolo previsti sono "media partner", "general sponsor" e "sponsor".

L'ultima tabella in questa area tematica mette in relazione i partner con gli eventi. Il is_partner La tabella contiene solo chiavi esterne che mettono in relazione i partner con gli eventi e definiscono ruoli o tipi di partnership. La combinazione di queste chiavi esterne costituisce la chiave UNICA della tabella. Se volessimo, potremmo aggiungere una data di inizio e una data di fine nel caso in cui qualche partner ricopra il proprio ruolo solo per una parte dell'evento. Potremmo anche mettere in relazione i partner con singoli sotto-eventi e piuttosto che interi eventi. Tuttavia, queste sono situazioni relativamente rare, quindi lasceremo questa parte del modello così com'è.

Sezione 2:spettacoli, artisti e attrezzature

Come accennato nell'introduzione, ogni evento può avere diversi sotto-eventi. In questo modello ho deciso di chiamare i sotto-eventi “spettacoli”. Uno spettacolo è un singolo sottoevento, incentrato su un argomento, con almeno un artista, ecc. In un evento di conferenza IT, uno spettacolo potrebbe essere una conferenza sui principi di gestione del progetto; un altro spettacolo potrebbe essere una tavola rotonda sulle migliori pratiche di data warehousing. Entrambi potrebbero svolgersi contemporaneamente, in luoghi diversi ed essere ospitati da presentatori diversi. Definiremo anche tutto ciò che serve per organizzare uno spettacolo, perché lo spettacolo deve continuare (in ogni caso ☺).

La tabella centrale di questa sezione è lo show tavolo. Ciò manterrà un registro di qualsiasi spettacolo associato a eventi passati, presenti e futuri. Quando stiamo pianificando un evento, dovremo aggiungere nuovi spettacoli non appena l'esecutore (ad esempio conferenziere, oratore, presentatore, rock star) avrà accettato di far parte di un evento. Osservare una descrizione degli attributi della tabella ci aiuterà a capire come funziona:

• show_name – Il nome dello spettacolo.
• show_location – Descrive dove si svolgerà lo spettacolo.
• show_description – Una descrizione dettagliata di quello spettacolo.
• start_time – L'ora di inizio prevista.
• end_time – L'ora di fine prevista. Può essere NULL perché potremmo inserire l'ora di fine effettiva (una volta terminato lo spettacolo) anziché l'ora di fine prevista.
• event_id – A quale evento fa parte lo spettacolo.

Nella maggior parte dei casi, gli spettacoli richiederanno attrezzature e artisti. (Teoricamente potremmo fare uno spettacolo senza un artista, ma non ci preoccuperemo di questo qui.) Poiché l'attrezzatura è limitata, è importante prenotare tutto ciò che è necessario nella fase di pianificazione dell'evento. Per farlo correttamente, dobbiamo sapere cosa accadrà a che ora. Ad esempio, se abbiamo due proiettori e due spettacoli che richiedono proiettori programmati per lo stesso orario, non possiamo aggiungere un terzo spettacolo che richiede un proiettore per quel periodo a meno che non otteniamo più attrezzature. Questo è il tipo di informazioni che dobbiamo avere nella fase di pianificazione.

Andando avanti, abbiamo il performer tavolo. Questo è un semplice catalogo di ogni artista con cui abbiamo lavorato o con cui lavoreremo in qualsiasi evento. Per ogni artista memorizzeremo il suo full_name . Potrebbe essere il nome di una band, un conferenziere, ecc. Il genre attributo è qui per distinguere tra i vari tipi di artisti, ad es. gruppi rock di scultori. L'ultimo attributo in questa tabella memorizza i contact_details degli artisti . Utilizzeremo il tipo di dati di testo per memorizzare il lotto, ma potremmo anche dividere i dettagli di contatto in pochi campi separati.

Metteremo in relazione spettacoli e artisti tramite il participate tavolo. Gli attributi in questa tabella sono:

• show_id e performer_id – Riferimenti allo spettacolo correlato e all'esecutore. Questa coppia potrebbe essere una chiave alternativa (unica) della tabella ma ho deciso di non usarla; potremmo avere un artista che fa parte dello stesso spettacolo in due momenti diversi.
• start_time e end_time – Orari esatti che definiscono quando quell'artista faceva parte di quello spettacolo.
• cost_planned e cost_actual – I costi/commissioni che ci aspettiamo di pagare a un artista e quanto effettivamente li abbiamo pagati.

Le restanti tre tabelle servono per definire tutta l'attrezzatura necessaria per uno spettacolo.

Il equipment_type il dizionario classifica le apparecchiature. Per un concerto, queste categorie potrebbero essere "apparecchiature di illuminazione", "strumenti musicali", "costruzione di palchi", ecc. Il type_name l'attributo contiene solo valori UNIQUE.

L'equipment la tabella descrive gli articoli e le quantità dell'attrezzatura. Il suo name attributo definisce l'attrezzatura in modo più specifico di equipment_type .type_name . Per una palla da discoteca, il suo valore "attrezzatura"."nome" sarebbe "palla da discoteca" ma il suo "tipo_attrezzatura"."nome_tipo" sarebbe "attrezzatura di illuminazione". Il available l'attributo definisce quale quantità dell'articolo è disponibile per noi. È un numero decimale perché forse useremo degli “elementi” che non possono essere enumerati, come acqua ed elettricità.

L'ultima tabella di questa sezione riguarda attrezzature e spettacoli. Questo può aiutarci a organizzare le attrezzature in fase di progettazione; ci consente inoltre di creare rapporti sui costi delle apparecchiature in un secondo momento. Quando pianifichiamo l'utilizzo e i costi delle apparecchiature, queste informazioni possono rivelarsi molto utili, soprattutto per eventi ricorrenti (o molto simili). Gli attributi nel required tabella sono:

• show_id e equipment_id – Si riferisce allo spettacolo e alle attrezzature correlate. Questa coppia costituisce la chiave UNICA della tabella.
• quantity – La quantità di tale attrezzatura necessaria.
• cost_planned e cost_actual – Quanto ci aspettiamo di pagare per l'installazione o il noleggio di apparecchiature e quanto effettivamente abbiamo pagato.

Sezione 3:Dipendenti

L'area tematica di questo modello riguarda i dipendenti e i loro ruoli. Mi piace sempre sottolineare che le persone e il loro tempo sono la parte più importante di qualsiasi progetto. Qualsiasi altra cosa è solo uno strumento per fare un lavoro. (E anche quello strumento è stato creato dalle persone, usando il loro tempo. ☺ )

Non spiegherò il employee , role e has_role tabelle qui. L'ho fatto molte volte prima, ad esempio in questo articolo. Se necessario, esaminalo.

Il tavolo finale nel nostro modello mette in relazione dipendenti e ruoli con gli spettacoli. Possiamo aspettarci di avere un numero limitato di dipendenti qualificati e dovremo essere sicuri che saranno disponibili quando necessario. Ovviamente, la stessa persona non può trovarsi in due posti diversi contemporaneamente. Gli attributi nel engaged tabella sono:

• show_id e has_role_id – Fa riferimento allo spettacolo correlato e al ruolo dei dipendenti.
• start_time – Quando ci aspettiamo che un dipendente inizi quel ruolo.
• end_time – Quando quel ruolo finisce. Questo è annullabile perché nella maggior parte dei casi assegneremo un valore dopo che il dipendente ha terminato il proprio ruolo. Tuttavia, potremmo inserire qui un'ora di fine prevista.
• cost_planned e cost_actual – Quanto ci aspettiamo di pagare a un dipendente per la gestione di quel ruolo e quanto effettivamente abbiamo pagato.

Ancora una volta, mi limiterò a sottolineare che questi dati storici possono essere molto utili quando stai organizzando un evento ripetuto o simile a un evento passato.

Oggi abbiamo discusso un possibile modello di dati per un database di gestione degli eventi. Abbiamo trattato le cose davvero importanti, come la descrizione dell'evento, la programmazione degli artisti e l'assegnazione di dipendenti e risorse all'evento. La gestione dei costi in questo modello è semplificata, ma ci fornisce comunque la possibilità di calcolare i costi pianificati ed effettivi per categoria, evento, spettacolo o tipo di attrezzatura.

Non sono un gestore di eventi. Se lo sei, spero che tu abbia trovato questo articolo molto utile. Ma mi piacerebbe sentire il tuo feedback su quali aggiunte o modifiche potrebbero essere utili in situazioni di vita reale.

Naturalmente, tutti sono invitati a inviare i propri suggerimenti e idee nella sezione commenti.