Модел на данни за управление на събития

Организирането на събитие е много работа! В тази статия разглеждаме модела на данни зад приложение за организация на събития.

Ако някога сте се опитвали да организирате събитие за повече от десет души (и не броете партита или бизнес срещи тук), знаете колко сложно може да бъде управлението на събития! Всички ли поканихме? Потвърдиха ли дали идват? Мястото резервирано и подготвено ли е? Кой ще бъде домакин на събитието? Кой ще участва в различните части? Има много други въпроси, на които трябва да се отговори и нещата лесно могат да се объркат.

Можете да направите цялото си планиране с хартия и химикал, но защо не използвате приложение? По-удобно е! Всяко приложение ще се нуждае от място, където да съхранява цялата необходима информация за събитието. Това е мястото, където нашият модел на данни за управление на събития влиза в тази история. Вземете кафе, настанете се на любимия си стол и ние ще разгледаме какво е необходимо, за да изградим модел на данни за управление на събития.

ЧЗВ за управление на събития

Преди да обясним модела и да опишем как ще съхраняваме данните, нека първо прегледаме някои основни положения за управление на събития:

1. Какво може да се счита за събитие?

   В този контекст събитието е повод, при който много хора, които често не се познават, се събират, за да научат или участват в нещо. Някои популярни събития са музикални фестивали или концерти, ИТ конференции, спортни събития като футболни игри, здравни и медицински конференции и др.

2. Какво е общото между всички събития?

   Споменатите по-горе примери за събития са много различни по отношение на съдържание, цел и целева аудитория. Все пак те споделят много прилики, особено в тяхната организация.

   Първо, помислете за съдържанието на събитието. Някои събития (например концерт или футболен мач) ще предоставят само един вид съдържание и ще се провеждат на едно място. Други събития включват много различни, но свързани „подсъбития“, които могат да се случат на различни места.

   Вземете ИТ конференция като пример за втория тип събитие. Има лекции, презентации, работни срещи и състезания. Участниците вероятно ще ходят от стая в стая или дори може да пътуват между различни сгради, докато отиват на различни подсъбития. Някои от тези подсъбития ще се изпълняват по едно и също време, но всяко подсъбитие все още е свързано с ИТ и има един или повече хостове.

3. Какво е необходимо, за да бъде събитието успешно?

   На първо място, има много служители на местата за провеждане на събития, които работят усилено на заден план:аудио и визуални техници, продавачи на билети, служители, работници по почистване и поддръжка и административен персонал. Много хора в много различни роли ще прекарат много часове в усилена работа, за да подготвят сцената за „звездите“ и други участници, но никой от тях няма да получи голямо признание.

   Ясно е, че всички събития изискват някаква инфраструктура. Ако проведем конференция на физическо място, ще говорим за стаи и места, озвучителна система, осветление, може би видео и т.н. Дори онлайн събитие, като уебинар, трябва да има място за създаване на съдържанието и Необходима е ИТ настройка за свързване с виртуални посетители.

   Събитията обикновено имат медийни спонсори и партньори, които помагат при организирането и популяризирането им. Тези спонсори са предимно фирми и асоциации, свързани с темата на събитието; понякога това са други компании, които търсят добра реклама; и по-рядко частно лице ще служи като спонсор или партньор.

4. Какво е управление на събития?

   Управлението на събития е процес, използван за ефективно управление на събития и всичко свързано с тях. Може да се разглежда като вид управление на проекти. Обсъдихме модел на данни за управление на проекти в тази статия. Използването на диаграма на Гант за показване на напредъка на събитието, текущо състояние и бъдещи действия не е лоша идея.

   Вероятно ще искаме нашето приложение за управление на събития да се побере на един екран, ако е възможно. Повечето действия – като създаване на ново шоу, назначаване на служители и ресурси за задача или оценка на разходите – трябва да се плъзгат и пускат.

Моделът на данните

Моделът на данни се състои от три основни предметни области:

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

Ще разгледаме по-отблизо всяка тематична област в реда, в който са изброени.

Раздел 1:Събития и партньори

Events and Partners предметната област е централната част на нашия модел. В тези пет таблици ще съхраняваме най-важните подробности за нашите събития. Също така ще свързваме събития с партньори.

Нека започнем със event маса. Това изброява всяко събитие, което сме организирали, и всяко събитие, което планираме да организираме. Атрибутите в тази таблица са:

• event_name – Името на събитие. Не е УНИКАЛНО, защото може да имаме две или повече събития с едно и също име – напр. концерт на същата група ще има същото име на събитие. Въпреки това, event_name – start_time двойката трябва да е УНИКАЛНА.
• event_type_id – Препраща event_type речник.
• event_location – Описва мястото, където ще се проведе събитието. Използването на описателен атрибут ни позволява да избягваме изграждането на по-сложен модел с таблици като „страна“ и „град“ и атрибути като „адрес“ и „описание“.
• event_description – Подробно описание на събитието и всички предавания или дейности, свързани с него. За концерт тук ще съхраняваме информация за началото, основното действие, всички допълнителни артисти и реда на изпълнение.
• start_time – Кога ще започне събитието. Това е задължително, защото трябва да знаем това във фазата на планиране.
• end_time – Когато събитието приключи. Можем да използваме този атрибут, за да съхраняваме очаквания или действителен край на събитието. Тъй като може да не знаем това точно време предварително (например, ако дадена спортна игра премине в продължения), този атрибут не е задължителен.

event_type речникът класифицира събитията, които обработваме. Ще съхраняваме всички възможни типове събития според тяхната ниша:концерт, футболен мач, баскетболен мач, IT конференция и т.н. Всеки тип събитие е уникално дефиниран от неговия type_name .

Както споменахме по-рано, събитията обикновено имат партньори. Повечето събития ще имат поне медиен партньор, докато някои също ще имат спонсори и други партньори. Един и същ партньор може да има няколко различни „партньорски роли“ на едно и също събитие. Например, една телевизионна компания за излъчване може да бъде едновременно медиен партньор и генерален спонсор на събитието. Ето защо ще използваме три таблици за свързване на събития с партньори.

Важно е да можете да добавяте партньори във фазата на планиране, така че всички участници в събитието да имат навременен достъп до тази информация. Също така, може да използваме минали данни, когато планираме нови събития – напр. можем да се свържем със същия партньор, когато организираме повтарящо се събитие или ново събитие от същия тип. Ако една компания е била генерален спонсор на технологична конференция миналата година, тя може да се интересува да го направи отново тази година.

Сега нека разгледаме трите таблици за партньорство. Първият е partner каталог. За всеки партньор ще съхраняваме partner_name и техния адрес, информация за връзка и други partner_details . Обърнете внимание, че partner_name атрибутът не е уникален. Може да имаме двама партньори с едно и също име, като например две частни лица с едно и също име и фамилия или две компании с едно и също име на фирма. В този случай ще ги разграничим с помощта на информацията, съхранявана в partner_details атрибут.

Втората таблица е partner_role речник, който изброява всички различни роли, които партньорът може да има. role_name атрибутът ще съдържа само УНИКАЛНИ стойности. Някои очаквани имена на роли са „медиен партньор“, „генерален спонсор“ и „спонсор“.

Последната таблица в тази тематична област свързва партньорите със събития. is_partner таблицата съдържа само външни ключове, които свързват партньорите със събития и дефинират роли или типове партньорства. Комбинацията от тези външни ключове образува УНИКАЛНИЯ ключ на таблицата. Ако искаме, бихме могли да добавим начална и крайна дата, в случай че някой партньор изпълнява ролята си само за част от събитието. Бихме могли също да свържем партньорите с отделни подсъбития, а не с цели събития. Все пак това са относително необичайни ситуации, така че ще оставим тази част от модела такава, каквато е.

Раздел 2:Представления, изпълнители и оборудване

Както бе споменато във въведението, всяко събитие може да има няколко подсъбития. В този модел реших да нарека подсъбитията „шоута“. Шоуто е едно подсъбитие, фокусирано върху една тема, с поне един изпълнител и т.н. В събитие на ИТ конференция едно шоу може да бъде лекция за принципите на управление на проекти; друго шоу може да бъде панелна дискусия за най-добрите практики за съхранение на данни. И двете могат да се проведат по едно и също време, на различни места и да бъдат домакини от различни водещи. Също така ще дефинираме всичко, което е необходимо за провеждане на шоу, защото шоуто трябва да продължи (във всеки случай ☺).

Централната таблица на този раздел е show маса. Това ще запази запис на всяко шоу, свързано с минали, настоящи и бъдещи събития. Когато планираме събитие, ще трябва да добавим нови предавания веднага щом изпълнителят (т.е. лектор, говорител, водещ, рок звезда) се съгласи да бъде част от събитие. Разглеждането на описанието на атрибутите на таблицата ще ни помогне да разберем как работи:

• show_name – Името на шоуто.
• show_location – Описва къде ще се проведе шоуто.
• show_description – Подробно описание на това шоу.
• start_time – Очакван начален час.
• end_time – Очакваното крайно време. Може да е NULL, защото можем да въведем действителния краен час (след като шоуто приключи), а не очаквания краен час.
• event_id – От кое събитие е част от шоуто.

В повечето случаи шоутата ще изискват оборудване и изпълнители. (Теоретично бихме могли да имаме шоу без изпълнител, но тук няма да се занимаваме с това.) Тъй като оборудването е ограничено, важно е да запазите всичко необходимо във фазата на планиране на събитието. За да направим това правилно, трябва да знаем какво ще се случи в кой момент. Например, ако имаме два проектора и две предавания, които изискват проектори, насрочени за едно и също време, не можем да добавим трето предаване, изискващо проектор за това време, освен ако не получим повече оборудване. Това е вид информация, която трябва да имаме във фазата на планиране.

Продължаваме напред, имаме performer маса. Това е прост каталог на всеки изпълнител, с който сме работили или ще работим на всяко събитие. За всеки изпълнител ще съхраняваме неговото full_name . Може да е името на група, лектор и т.н. genre атрибутът е тук, за да прави разлика между различните типове изпълнители – напр. рок групи от скулптори. Последният атрибут в тази таблица съхранява contact_details на изпълнителите . Ще използваме текстовия тип данни, за да съхраняваме партидата, но бихме могли също да разделим данните за контакт на няколко отделни полета.

Ще свържем предавания и изпълнители чрез participate маса. Атрибутите в тази таблица са:

• show_id и performer_id – Препратки към свързаното шоу и изпълнителя. Тази двойка може да бъде алтернативен (уникален) ключ на масата, но реших да не го използвам; може да имаме един изпълнител да бъде част от едно и също шоу в две различни моменти.
• start_time и end_time – Точните часове, които определят кога този изпълнител е бил част от това шоу.
• cost_planned и cost_actual – Разходите/хонорарите, които очакваме да платим на изпълнител и какво всъщност сме им платили.

Останалите три таблици се използват за дефиниране на цялото оборудване, необходимо за шоу.

equipment_type речник категоризира оборудването. За концерт тези категории могат да бъдат „осветително оборудване“, „музикални инструменти“, „конструкция на сцена“ и т.н. type_name атрибутът съдържа само УНИКАЛНИ стойности.

equipment таблицата описва артикули и количества оборудване. Неговото name атрибутът дефинира оборудването по-конкретно от equipment_type .type_name . За диско топка, нейната стойност „equipment“.“name“ ще бъде „диско топка“, но нейният „equipment_type“.“type_name“ ще бъде „осветително оборудване“. available атрибут определя какво количество от артикула е на разположение за нас. Това е десетично число, защото може би ще използваме някои „елементи“, които не могат да бъдат изброени, като вода и електричество.

Последната таблица в този раздел се отнася до оборудването и шоутата. Това може да ни помогне да организираме оборудването във фазата на планиране; също така ни позволява да създаваме отчети за разходите за оборудване по-късно. Когато планираме използването на оборудването и разходите, тази информация може да се окаже много полезна, особено за повтарящи се (или много подобни) събития. Атрибутите в required таблицата са:

• show_id и equipment_id – Отнася се до свързаното шоу и оборудване. Тази двойка формира УНИКАЛНИЯ ключ на таблицата.
• quantity – Необходимото количество от това оборудване.
• cost_planned и cost_actual – Какво очакваме да платим за инсталиране или наемане на оборудване и какво всъщност сме платили.

Раздел 3:Служители

Предметната област на този модел е за служителите и техните роли. Винаги обичам да изтъквам, че хората и тяхното време са най-важната част от всеки проект. Всичко друго е просто инструмент за извършване на работа. (И този инструмент също е направен от хора, използвайки тяхното време. ☺ )

Няма да обяснявам employee , role и has_role таблици тук. Правил съм го много пъти преди, например в тази статия. Ако трябва, моля, прегледайте го.

Финалната таблица в нашия модел свързва служителите и ролите с шоута. Можем да очакваме да имаме ограничен брой квалифицирани служители и ще трябва да сме сигурни, че те ще бъдат на разположение, когато е необходимо. Очевидно един и същ човек не може да бъде на две различни места по едно и също време. Атрибутите в engaged таблицата са:

• show_id и has_role_id – Позовава се на свързаното шоу и ролята на служител.
• start_time – Когато очакваме служител да започне тази роля.
• end_time – Когато тази роля свърши. Това е нулево, защото в повечето случаи ще присвоим стойност, след като служителят завърши ролята си. Тук обаче може да въведете очакван краен час.
• cost_planned и cost_actual – Какво очакваме да платим на служител за изпълнение на тази роля и какво всъщност сме платили.

Още веднъж ще отбележа, че тези исторически данни могат да бъдат много полезни, когато организирате повторно събитие или такова, което е подобно на минало събитие.

Днес обсъдихме възможен модел на данни за база данни за управление на събития. Обхванахме наистина важните неща, като описание на събитието, насрочване на изпълнители и назначаване на служители и ресурси за събитието. Обработката на разходите в този модел е опростена, но все пак ни предоставя възможността да изчисляваме планирани и действителни разходи по категория, събитие, шоу или тип оборудване.

Аз не съм мениджър на събития. Ако сте, надявам се, че сте намерили тази статия за много полезна. Но бих искал да чуя вашите отзиви за това какви допълнения или промени могат да бъдат полезни в реални ситуации.

Разбира се, всеки е добре дошъл да изпрати своите предложения и идеи в секцията за коментари.