Datový model správy událostí

Uspořádat akci je hodně práce! V tomto článku zkoumáme datový model aplikace pro organizaci událostí.

Pokud jste někdy zkoušeli uspořádat akci pro více než deset lidí (a nepočítáte zde večírky nebo obchodní schůzky), víte, jak komplikované může být event management! Pozvali jsme všechny? Potvrdili, jestli přijdou? Je místo obsazeno a připraveno? Kdo bude pořádat akci? Kdo se bude podílet na jednotlivých částech? Existuje mnoho dalších otázek, na které je třeba odpovědět, a věci se mohou snadno pokazit.

Všechno plánování můžete dělat s papírem a tužkou, ale proč nepoužít aplikaci? Je to pohodlnější! Každá aplikace bude potřebovat místo pro uložení všech nezbytných informací o událostech. Zde do tohoto příběhu vstupuje náš datový model správy událostí. Dejte si kávu, usaďte se do svého oblíbeného křesla a my se podíváme na to, co je potřeba k vytvoření datového modelu správy událostí.

Nejčastější dotazy ke správě událostí

Než vysvětlíme model a popíšeme, jak budeme data ukládat, zopakujme si nejprve některé základy správy událostí:

Co lze považovat za událost?

V tomto kontextu je událost příležitostí, kdy se mnoho lidí, kteří se často navzájem neznají, schází, aby se něco dozvěděli nebo se na něčem podíleli. Mezi oblíbené akce patří hudební festivaly nebo koncerty, IT konference, sportovní akce jako fotbalové zápasy, zdravotní a lékařské konference atd.
Co mají všechny události společného?

Výše uvedené příklady událostí se velmi liší, pokud jde o obsah, účel a cílové publikum. Přesto sdílejí mnoho podobností, zejména ve své organizaci.

Nejprve zvažte obsah události. Některé akce (např. koncert nebo fotbalový zápas) poskytnou pouze jeden typ obsahu a budou se konat na jednom místě. Mezi další události patří mnoho různých, ale souvisejících „dílčích událostí“, které se mohou vyskytovat na různých místech.

Jako příklad druhého typu akce vezměte IT konferenci. Konají se zde přednášky, prezentace, workshopy a soutěže. Účastníci budou pravděpodobně chodit z místnosti do místnosti nebo mohou dokonce cestovat mezi různými budovami, když jdou na různé dílčí akce. Některé z těchto dílčích událostí poběží současně, ale každá dílčí událost se stále týká IT a má jednoho nebo více hostitelů.
Co je potřeba k tomu, aby byla akce úspěšná?

Především je zde mnoho pracovníků v místě konání akcí, kteří tvrdě pracují v pozadí:audio a vizuální technici, prodejci vstupenek, uvaděči, pracovníci úklidu a údržby a administrativní pracovníci. Mnoho lidí v mnoha různých rolích stráví mnoho hodin tvrdou prací, aby připravilo jeviště pro „hvězdy“ a další účastníky, ale žádnému z nich se nedostane velkého uznání.

Je jasné, že všechny akce vyžadují určitý druh infrastruktury. Pokud pořádáme konferenci na fyzickém místě, budeme hovořit o místnostech a sedadlech, zvukovém systému, osvětlení, možná videu atd. Dokonce i online událost, jako je webinář, musí mít místo, kde se bude produkovat obsah a Nastavení IT potřebné pro spojení s virtuálními účastníky.

Akce mají obvykle mediální sponzory a partnery, kteří pomáhají při jejich organizaci a propagaci. Těmito sponzory jsou většinou společnosti a sdružení související s tématem akce; příležitostně jsou to jiné společnosti, které hledají dobrou reklamu; a vzácněji soukromá osoba bude sloužit jako sponzor nebo partner.
Co je správa událostí?

Event management je proces sloužící k efektivnímu řízení událostí a všeho, co s nimi souvisí. Dalo by se to považovat za typ projektového řízení. V tomto článku jsme diskutovali o datovém modelu projektového řízení. Použití Ganttova diagramu k zobrazení průběhu události, aktuálního stavu a budoucích akcí není špatný nápad.

Pravděpodobně budeme chtít, aby se naše aplikace pro správu událostí vešla na jednu obrazovku, pokud je to možné. Většinu akcí – jako je vytvoření nového pořadu, přiřazení zaměstnanců a zdrojů k úkolu nebo odhad nákladů – byste měli přetahovat.

Datový model

Datový model se skládá ze tří hlavních tematických oblastí:

Events and Partners
Shows, Performers and Equipment
Employees

Podíváme se blíže na každou oblast v pořadí, v jakém jsou uvedeny.

Část 1:Události a partneři

Events and Partners předmětová oblast je ústřední částí našeho modelu. V těchto pěti tabulkách uložíme nejdůležitější podrobnosti o našich akcích. Události také spojíme s partnery.

Začněme event stůl. Zde jsou uvedeny všechny akce, které jsme zorganizovali, a všechny akce, které plánujeme uspořádat. Atributy v této tabulce jsou:

event_name – Název události. Není to UNIKÁTNÍ, protože můžeme mít dvě nebo více akcí se stejným názvem – např. koncert stejné kapely by měl stejný název události. Nicméně event_name – start_time pár by měl být UNIKÁTNÍ.
event_type_id – Odkazuje na event_type slovník.
event_location – Popisuje místo, kde se událost bude konat. Použití popisného atributu nám umožňuje vyhnout se vytváření složitějšího modelu s tabulkami jako „země“ a „město“ a atributy jako „adresa“ a „popis“.
event_description – Podrobný popis události a všech představení nebo aktivit s ní spojených. U koncertu sem ukládáme informace o zahajovacím aktu, hlavním aktu, případných dalších bavičích a pořadí vystoupení.
start_time – Kdy akce začne. Je to povinné, protože bychom to měli vědět ve fázi plánování.
end_time – Když akce skončí. Tento atribut bychom mohli použít k uložení očekávaného nebo skutečného času konce události. Vzhledem k tomu, že tento přesný čas nemusíme znát předem (např. pokud sportovní zápas přejde do prodloužení), je tento atribut volitelný.

event_type slovník klasifikuje události, které zpracováváme. Uložíme všechny možné typy událostí podle jejich oblasti:koncert, fotbalový zápas, basketbalový zápas, IT konference atd. Každý typ události je jednoznačně definován svým type_name .

Jak jsme již zmínili, akce mají většinou partnery. Většina akcí bude mít alespoň mediálního partnera, některé budou mít i sponzory a další partnery. Stejný partner může mít na stejné události několik různých „partnerských rolí“. Například televizní společnost by mohla být mediálním partnerem a zároveň generálním sponzorem akce. To je důvod, proč použijeme tři tabulky ke spojení událostí s partnery.

Je důležité mít možnost přidávat partnery ve fázi plánování, aby k těmto informacím měli včasný přístup všichni účastníci akce. Také můžeme použít minulá data, když plánujeme nové události – např. můžeme kontaktovat stejného partnera, když pořádáme opakující se akci nebo novou akci stejného typu. Pokud byla společnost minulý rok generálním sponzorem technologické konference, možná bude mít zájem o to letos znovu.

Nyní se podívejme na tři tabulky partnerství. První je partner katalog. U každého partnera uložíme partner_name a jejich adresu, kontaktní údaje a další partner_details . Všimněte si, že partner_name atribut není jedinečný. Můžeme mít dva partnery se stejným jménem, například dvě soukromé osoby se stejným jménem a příjmením nebo dvě společnosti se stejným názvem společnosti. V tomto případě je rozlišíme pomocí informací uložených v partner_details atribut.

Druhá tabulka je partner_role slovník, který uvádí všechny různé role, které by partner mohl mít. role_name atribut bude obsahovat pouze UNIQUE hodnoty. Některá očekávaná jména rolí jsou „mediální partner“, „generální sponzor“ a „sponzor“.

Poslední tabulka v této tematické oblasti spojuje partnery s akcemi. is_partner tabulka obsahuje pouze cizí klíče, které spojují partnery s událostmi a definují role nebo typy partnerství. Kombinace těchto cizích klíčů tvoří UNIKÁTNÍ klíč tabulky. Pokud bychom chtěli, mohli bychom přidat datum zahájení a datum ukončení pro případ, že by některý partner plnil svou roli pouze pro část akce. Mohli bychom také spojit partnery s jednotlivými dílčími událostmi a spíše než s celými událostmi. Přesto se jedná o relativně neobvyklé situace, takže tuto část modelu necháme tak, jak je.

Část 2:Představení, účinkující a vybavení

Jak již bylo zmíněno v úvodu, každá událost může mít několik dílčích událostí. V tomto modelu jsem se rozhodl nazvat dílčí události „show“. Show je jedna dílčí akce, zaměřená na jedno téma, má alespoň jednoho účinkujícího atd. Na IT konferenci může být jednou show přednáška o principech projektového řízení; další show by mohla být panelová diskuse o osvědčených postupech v oblasti datových skladů. Oba by se mohly odehrávat ve stejnou dobu, na různých místech a být pořádány různými moderátory. Také definujeme vše, co je potřeba k provozování show, protože show musí pokračovat (v každém případě ☺ ).

Ústřední tabulkou této sekce je show stůl. To bude uchovávat záznamy o jakékoli show spojené s minulými, současnými a budoucími událostmi. Když plánujeme událost, budeme muset přidat nové pořady, jakmile účinkující (tj. lektor, řečník, moderátor, rocková hvězda) souhlasí s účastí na události. Pohled na popis atributů tabulky nám pomůže pochopit, jak to funguje:

show_name – Název pořadu.
show_location – Popisuje, kde se bude představení konat.
show_description – Podrobný popis tohoto pořadu.
start_time – Očekávaný čas zahájení.
end_time – Předpokládaný čas ukončení. Může být NULL, protože místo očekávaného času ukončení můžeme zadat skutečný čas ukončení (po skončení pořadu).
event_id – Jaké akce je pořad součástí.

Ve většině případů budou show vyžadovat vybavení a umělce. (Teoreticky bychom mohli mít vystoupení bez účinkujícího, ale s tím se zde nebudeme obtěžovat.) Vzhledem k tomu, že vybavení je omezené, je důležité zarezervovat vše, co je potřeba ve fázi plánování akce. Abychom to udělali správně, musíme vědět, co se v kterou dobu stane. Pokud máme například dva projektory a dvě představení vyžadující projektory naplánované na stejnou dobu, nemůžeme na tuto dobu přidat třetí představení vyžadující projektor, pokud nezískáme další vybavení. Toto je druh informací, které musíme mít ve fázi plánování.

Pokračujeme, máme performer stůl. Toto je jednoduchý katalog všech interpretů, se kterými jsme spolupracovali nebo s nimi budeme pracovat na jakékoli akci. U každého účinkujícího uložíme jeho full_name . Může to být jméno kapely, lektora atd. genre atribut je zde k rozlišení mezi různými typy interpretů – např. rockové kapely od sochařů. Poslední atribut v této tabulce ukládá contact_details účinkujících . K uložení šarže použijeme textový datový typ, ale kontaktní údaje můžeme také rozdělit do několika samostatných polí.

Představení a účinkující spojíme prostřednictvím participate stůl. Atributy v této tabulce jsou:

show_id a performer_id – Odkazy na související představení a účinkujícího. Tento pár by mohl být alternativním (unikátním) klíčem stolu, ale rozhodl jsem se ho nepoužívat; mohli bychom mít jednoho účinkujícího, aby byl součástí stejné show ve dvou různých časech.
start_time a end_time – Přesné časy, které definují, kdy byl daný účinkující součástí této show.
cost_planned a cost_actual – Náklady/poplatky, které očekáváme, že zaplatíme výkonnému umělci, a co jsme jim skutečně zaplatili.

Zbývající tři tabulky se používají k definování veškerého vybavení potřebného pro show.

equipment_type slovník kategorizuje vybavení. U koncertu mohou být tyto kategorie „osvětlovací zařízení“, „hudební nástroje“, „stavba pódia“ atd. type_name atribut obsahuje pouze UNIQUE hodnoty.

equipment tabulka popisuje položky vybavení a množství. Jeho name atribut definuje vybavení konkrétněji než equipment_type .type_name . U diskotékové koule by její hodnota “equipment”.”name” byla “disco ball”, ale její “equipment_type”.”type_name” by byla “lighting equipment”. available atribut definuje, jaké množství položky máme k dispozici. Je to desetinné číslo, protože možná použijeme některé „položky“, které nelze vyčíslit, jako je voda a elektřina.

Poslední tabulka v této části se týká vybavení a ukázek. To nám může pomoci organizovat vybavení ve fázi plánování; také nám to umožňuje později vytvářet zprávy o nákladech na vybavení. Když plánujeme využití zařízení a náklady, mohou být tyto informace velmi užitečné, zejména pro opakující se (nebo velmi podobné) události. Atributy v required tabulka jsou:

show_id a equipment_id – Odkazuje na související představení a vybavení. Tento pár tvoří UNIKÁTNÍ klíč tabulky.
quantity – Množství potřebného vybavení.
cost_planned a cost_actual – Co očekáváme, že zaplatíme za instalaci nebo pronájem vybavení a co jsme skutečně zaplatili.

Část 3:Zaměstnanci

Předmětem tohoto modelu jsou zaměstnanci a jejich role. Vždy rád zdůrazňuji, že lidé a jejich čas jsou nejdůležitější součástí každého projektu. Cokoli jiného je jen nástroj k provedení práce. (A tento nástroj také vyrobili lidé, kteří využili svůj čas. ☺ )

Nebudu vysvětlovat employee , role a has_role tabulky zde. Už jsem to udělal mnohokrát, například v tomto článku. Pokud potřebujete, přečtěte si jej.

Poslední tabulka v našem modelu spojuje zaměstnance a role s pořady. Můžeme očekávat, že budeme mít omezený počet kvalifikovaných zaměstnanců a budeme si muset být jisti, že budou k dispozici v případě potřeby. Je zřejmé, že stejná osoba nemůže být na dvou různých místech současně. Atributy v engaged tabulka jsou:

show_id a has_role_id – Odkazuje na související pořad a roli zaměstnance.
start_time – Když očekáváme, že zaměstnanec začne tuto roli.
end_time – Až ta role skončí. Toto je nulovatelné, protože ve většině případů přiřadíme hodnotu poté, co zaměstnanec dokončí svou roli. Zde však můžeme zadat očekávaný čas ukončení.
cost_planned a cost_actual – Co očekáváme, že zaplatíme zaměstnanci za zvládnutí této role a co jsme skutečně zaplatili.

Ještě jednou zdůrazňuji, že tato historická data mohou být velmi užitečná, když pořádáte opakovanou událost nebo událost, která je podobná minulé události.

Dnes jsme diskutovali o možném datovém modelu pro databázi správy událostí. Zabývali jsme se opravdu důležitými věcmi, jako je popis události, plánování účinkujících a přiřazení zaměstnanců a zdrojů k události. Manipulace s náklady v tomto modelu je zjednodušená, ale stále nám poskytuje možnost vypočítat plánované a skutečné náklady podle kategorie, akce, výstavy nebo typu zařízení.

Nejsem manažer událostí. Pokud ano, doufám, že vám tento článek pomohl. Ale rád bych slyšel váš názor na to, jaké doplňky nebo změny by mohly být užitečné v situacích skutečného života.

Samozřejmě, každý může poslat své návrhy a nápady v sekci komentářů.