Model Data Manajemen Acara

Mengorganisir sebuah acara adalah banyak pekerjaan! Dalam artikel ini, kami memeriksa model data di balik aplikasi organisasi acara.

Jika Anda pernah mencoba mengatur acara untuk lebih dari sepuluh orang (dan tidak menghitung pesta atau pertemuan bisnis di sini), Anda tahu betapa rumitnya manajemen acara! Sudahkah kita mengundang semua orang? Sudahkah mereka mengkonfirmasi jika mereka akan datang? Apakah tempat sudah dipesan dan disiapkan? Siapa yang akan menjadi tuan rumah acara tersebut? Siapa yang akan berpartisipasi di berbagai bagian? Ada banyak pertanyaan lain yang harus dijawab, dan banyak hal bisa salah dengan mudah.

Anda dapat melakukan semua perencanaan Anda dengan kertas dan pena, tetapi mengapa tidak menggunakan aplikasi? Lebih nyaman! Aplikasi apa pun akan membutuhkan tempat untuk menyimpan semua informasi acara yang diperlukan. Di sinilah model data manajemen acara kami memasuki cerita ini. Ambil kopi, duduk di kursi favorit Anda, dan kami akan melihat apa yang diperlukan untuk membangun model data manajemen acara.

FAQ Manajemen Acara

Sebelum menjelaskan model dan menjelaskan bagaimana kami akan menyimpan data, pertama-tama mari kita tinjau beberapa dasar pengelolaan peristiwa:

Apa yang bisa dianggap sebagai peristiwa?

Dalam konteks ini, suatu peristiwa adalah suatu kesempatan di mana banyak orang, yang seringkali tidak saling mengenal, berkumpul untuk mempelajari atau berpartisipasi dalam sesuatu. Beberapa acara populer adalah festival atau konser musik, konferensi TI, acara olahraga seperti pertandingan sepak bola, konferensi kesehatan dan medis, dll.
Apa kesamaan semua peristiwa?

Contoh acara yang disebutkan sebelumnya sangat berbeda dalam hal konten, tujuan, dan target audiens. Namun, mereka memiliki banyak kesamaan, terutama dalam organisasi mereka.

Pertama, pertimbangkan konten acara. Beberapa acara (misalnya konser atau pertandingan sepak bola) hanya akan menyediakan satu jenis konten dan akan diadakan di satu tempat. Peristiwa lain mencakup banyak "sub-peristiwa" yang berbeda tetapi terkait, yang mungkin terjadi di berbagai tempat.

Ambil konferensi TI sebagai contoh jenis acara kedua. Ada kuliah, presentasi, lokakarya, dan kompetisi. Peserta mungkin akan pergi dari kamar ke kamar atau bahkan mungkin melakukan perjalanan di antara gedung-gedung yang berbeda saat mereka pergi ke berbagai sub-acara. Beberapa sub-acara ini akan berjalan pada waktu yang sama, tetapi setiap sub-acara masih berhubungan dengan TI dan memiliki satu atau beberapa host.
Apa yang diperlukan untuk menyukseskan acara?

Pertama-tama, ada banyak personel tempat acara yang bekerja keras di latar belakang:teknisi audio dan visual, penjual tiket, pengantar, pekerja kebersihan dan pemeliharaan, dan personel administrasi. Banyak orang dalam berbagai peran yang berbeda akan menghabiskan banyak waktu bekerja keras untuk menyiapkan panggung bagi "bintang" dan peserta lainnya, tetapi tidak satu pun dari mereka yang akan mendapatkan banyak pengakuan.

Jelas, semua acara membutuhkan semacam infrastruktur. Jika kita mengadakan konferensi di lokasi fisik, kita akan berbicara tentang ruangan dan kursi, sistem suara, pencahayaan, mungkin video, dll. Bahkan acara online, seperti webinar, harus memiliki tempat untuk menghasilkan konten dan Penyiapan TI diperlukan untuk terhubung dengan peserta virtual.

Acara biasanya memiliki sponsor media dan mitra yang membantu dalam mengatur dan mempromosikannya. Sponsor ini sebagian besar adalah perusahaan dan asosiasi yang terkait dengan topik acara; kadang-kadang mereka adalah perusahaan lain yang mencari publisitas yang bagus; dan yang lebih jarang adalah individu pribadi yang berperan sebagai sponsor atau mitra.
Apa itu manajemen acara?

Manajemen acara adalah proses yang digunakan untuk mengelola acara secara efektif dan segala sesuatu yang terkait dengannya. Ini dapat dianggap sebagai jenis manajemen proyek. Kami membahas model data manajemen proyek dalam artikel ini. Menggunakan bagan Gantt untuk menunjukkan kemajuan acara, status saat ini, dan tindakan di masa mendatang bukanlah ide yang buruk.

Kami mungkin ingin aplikasi manajemen acara kami muat di satu layar, jika memungkinkan. Sebagian besar tindakan – seperti membuat acara baru, menugaskan karyawan dan sumber daya untuk suatu tugas, atau memperkirakan biaya – harus dilakukan dengan cara seret dan lepas.

Model Data

Model data terdiri dari tiga bidang subjek utama:

Events and Partners
Shows, Performers and Equipment
Employees

Kami akan melihat lebih dekat pada setiap area subjek sesuai urutannya.

Bagian 1:Acara dan Mitra

Events and Partners area subjek adalah bagian utama dari model kami. Dalam lima tabel ini, kami akan menyimpan detail terpenting tentang acara kami. Kami juga akan menghubungkan acara dengan mitra.

Mari kita mulai dengan event meja. Ini mencantumkan setiap acara yang telah kami selenggarakan dan setiap acara yang kami rencanakan untuk diselenggarakan. Atribut dalam tabel ini adalah:

event_name - Nama acara. Ini bukan UNIK karena kami mungkin memiliki dua atau lebih acara dengan nama yang sama – mis. konser oleh band yang sama akan memiliki nama acara yang sama. Namun, event_name – start_time pasangan harus UNIK.
event_type_id – Merujuk pada event_type kamus.
event_location - Menjelaskan lokasi dimana acara akan berlangsung. Menggunakan atribut deskriptif memungkinkan kita menghindari pembuatan model yang lebih kompleks dengan tabel seperti "negara" dan "kota" serta atribut seperti "alamat" dan "deskripsi".
event_description – Penjelasan rinci tentang acara dan semua pertunjukan atau kegiatan yang terkait dengannya. Untuk konser, di sinilah kami akan menyimpan info tentang opening act, main act, entertainer tambahan, dan urutan penampilan.
start_time - Kapan acara akan dimulai. Ini wajib karena kita harus mengetahuinya dalam tahap perencanaan.
end_time - Saat acara berakhir. Kita dapat menggunakan atribut ini untuk menyimpan waktu akhir peristiwa yang diharapkan atau aktual. Karena kita mungkin tidak mengetahui waktu yang tepat ini sebelumnya (misalnya jika pertandingan olahraga memasuki waktu lembur), atribut ini opsional.

event_type kamus mengklasifikasikan acara yang kami tangani. Kami akan menyimpan semua kemungkinan jenis acara sesuai dengan ceruknya:konser, pertandingan sepak bola, pertandingan bola basket, konferensi TI, dll. Setiap jenis acara secara unik ditentukan oleh type_name-nya .

Seperti yang kami sebutkan sebelumnya, acara biasanya memiliki mitra. Sebagian besar acara akan memiliki setidaknya mitra media, sementara beberapa juga akan memiliki sponsor dan mitra lainnya. Mitra yang sama dapat memiliki beberapa "peran mitra" yang berbeda pada acara yang sama. Misalnya, sebuah perusahaan penyiaran televisi dapat menjadi media partner dan sponsor umum acara tersebut pada saat yang bersamaan. Inilah sebabnya kami akan menggunakan tiga tabel untuk menghubungkan acara dengan mitra.

Penting untuk dapat menambahkan mitra dalam tahap perencanaan sehingga semua pemangku kepentingan acara dapat memiliki akses tepat waktu ke info tersebut. Selain itu, kami dapat menggunakan data masa lalu saat kami merencanakan acara baru – mis. kami dapat menghubungi mitra yang sama ketika kami mengadakan acara rutin atau acara baru dengan jenis yang sama. Jika sebuah perusahaan menjadi sponsor umum konferensi teknologi tahun lalu, mereka mungkin tertarik untuk melakukannya lagi tahun ini.

Sekarang, mari kita lihat tiga tabel kemitraan. Yang pertama adalah partner katalog. Untuk setiap mitra, kami akan menyimpan partner_name dan alamat mereka, info kontak, dan partner_details lainnya . Perhatikan bahwa partner_name atribut tidak unik. Kami mungkin memiliki dua mitra dengan nama yang sama, seperti dua individu pribadi dengan nama depan dan belakang yang sama atau dua perusahaan dengan nama perusahaan yang sama. Dalam hal ini, kami akan membedakannya menggunakan info yang disimpan di partner_details atribut.

Tabel kedua adalah partner_role kamus, yang mencantumkan semua peran berbeda yang bisa dimiliki pasangan. role_name atribut hanya akan berisi nilai UNIK. Beberapa nama peran yang diharapkan adalah “mitra media”, “sponsor umum”, dan “sponsor”.

Tabel terakhir di bidang subjek ini menghubungkan mitra dengan acara. is_partner tabel hanya berisi kunci asing yang menghubungkan mitra dengan acara dan menentukan peran atau jenis kemitraan. Kombinasi kunci asing ini membentuk kunci UNIK tabel. Jika kami mau, kami dapat menambahkan tanggal mulai dan tanggal akhir jika beberapa mitra hanya mengisi peran mereka untuk bagian dari acara tersebut. Kami juga dapat menghubungkan mitra dengan satu sub-acara dan bukan keseluruhan acara. Namun, ini adalah situasi yang relatif tidak umum, jadi kami akan membiarkan bagian model ini apa adanya.

Bagian 2:Pertunjukan, Penampil, dan Perlengkapan

Seperti disebutkan dalam pendahuluan, setiap acara dapat memiliki beberapa sub-acara. Dalam model ini, saya telah memutuskan untuk menyebut sub-acara "pertunjukan". Pertunjukan adalah sub-acara tunggal, berfokus pada satu topik, memiliki setidaknya satu pemain, dll. Dalam acara konferensi TI, satu pertunjukan dapat berupa kuliah tentang prinsip-prinsip manajemen proyek; acara lain bisa menjadi diskusi panel praktik terbaik pergudangan data. Keduanya bisa berlangsung pada waktu yang sama, di lokasi yang berbeda, dan dibawakan oleh presenter yang berbeda. Kami juga akan menentukan semua yang diperlukan untuk menjalankan pertunjukan, karena pertunjukan harus tetap berjalan (dalam hal apa pun ☺).

Tabel pusat dari bagian ini adalah show meja. Ini akan menyimpan catatan acara apa pun yang terkait dengan peristiwa masa lalu, sekarang, dan masa depan. Saat kita merencanakan sebuah acara, kita perlu menambahkan acara baru segera setelah pemain (yaitu dosen, pembicara, presenter, bintang rock) setuju untuk menjadi bagian dari sebuah acara. Melihat deskripsi atribut tabel akan membantu kita memahami cara kerjanya:

show_name – Nama acaranya.
show_location – Menjelaskan di mana pertunjukan akan berlangsung.
show_description – Penjelasan mendetail tentang pertunjukan itu.
start_time – Waktu mulai yang diharapkan.
end_time - Waktu akhir yang diharapkan. Ini bisa menjadi NULL karena kita mungkin memasukkan waktu akhir yang sebenarnya (setelah pertunjukan selesai) daripada waktu akhir yang diharapkan.
event_id – Acara apa yang menjadi bagian dari pertunjukan tersebut.

Dalam kebanyakan kasus, pertunjukan akan membutuhkan peralatan dan pemain. (Secara teoritis kita bisa mengadakan pertunjukan tanpa seorang penampil, tetapi kita tidak akan mempermasalahkannya di sini.) Karena peralatan terbatas, sangat penting untuk memesan semua yang dibutuhkan dalam tahap perencanaan acara. Untuk melakukan ini dengan benar, kita perlu tahu apa yang akan terjadi pada jam berapa. Misalnya, jika kami memiliki dua proyektor dan dua pertunjukan yang memerlukan proyektor yang dijadwalkan pada waktu yang sama, kami tidak dapat menambahkan pertunjukan yang membutuhkan proyektor ketiga untuk waktu itu kecuali jika kami mendapatkan lebih banyak peralatan. Ini adalah jenis informasi yang harus kita miliki dalam tahap perencanaan.

Selanjutnya, kami memiliki performer meja. Ini adalah katalog sederhana dari setiap pemain yang pernah atau akan bekerja sama dengan kami di acara apa pun. Untuk setiap pemain, kami akan menyimpan full_name mereka . Bisa nama band, dosen, dll. genre atribut di sini untuk membedakan di antara berbagai jenis pemain – mis. band rock dari pematung. Atribut terakhir dalam tabel ini menyimpan contact_details perform pemain . Kami akan menggunakan tipe data teks untuk menyimpan lot, tetapi kami juga dapat membagi detail kontak menjadi beberapa bidang terpisah.

Kami akan menghubungkan pertunjukan dan pemain melalui participate meja. Atribut dalam tabel ini adalah:

show_id dan performer_id – Referensi ke acara terkait dan pemainnya. Pasangan ini bisa menjadi kunci alternatif (unik) dari tabel tetapi saya memutuskan untuk tidak menggunakannya; kita mungkin memiliki satu pemain yang menjadi bagian dari pertunjukan yang sama di dua waktu yang berbeda.
start_time dan end_time – Waktu yang tepat yang menentukan kapan pemain tersebut menjadi bagian dari pertunjukan itu.
cost_planned dan cost_actual – Biaya/biaya yang kami harapkan untuk dibayarkan kepada seorang pemain dan apa yang sebenarnya kami bayarkan kepada mereka.

Tiga tabel yang tersisa digunakan untuk menentukan semua peralatan yang dibutuhkan untuk pertunjukan.

equipment_type kamus mengkategorikan peralatan. Untuk konser, kategori ini dapat berupa “peralatan pencahayaan”, “alat musik”, “konstruksi panggung”, dll. type_name atribut hanya berisi nilai UNIK.

equipment tabel menjelaskan item peralatan dan jumlah. name-nya atribut mendefinisikan peralatan lebih spesifik daripada equipment_type .type_name . Untuk bola disko, nilai “equipment”.”name”-nya akan menjadi “disco ball” tetapi “equipment_type”-nya.”type_name” akan menjadi “lighting equipment”. available atribut menentukan jumlah barang yang tersedia bagi kita. Ini adalah angka desimal karena mungkin kita akan menggunakan beberapa “barang” yang tidak dapat dicacah, seperti air dan listrik.

Tabel terakhir di bagian ini berkaitan dengan peralatan dan pertunjukan. Ini dapat membantu kami mengatur peralatan dalam tahap perencanaan; itu juga memungkinkan kami untuk membuat laporan tentang biaya peralatan di kemudian hari. Saat kami merencanakan penggunaan dan biaya peralatan, informasi ini bisa sangat berguna, terutama untuk acara yang berulang (atau sangat mirip). Atribut di required tabelnya adalah:

show_id dan equipment_id – Mengacu pada pertunjukan dan perlengkapan terkait. Pasangan ini membentuk kunci UNIK tabel.
quantity – Jumlah peralatan yang dibutuhkan.
cost_planned dan cost_actual – Apa yang kami harapkan untuk membayar untuk memasang atau menyewa peralatan dan apa yang sebenarnya kami bayar.

Bagian 3:Karyawan

Area subjek model ini adalah tentang karyawan dan peran mereka. Saya selalu suka menunjukkan bahwa orang dan waktu mereka adalah bagian terpenting dari proyek apa pun. Apa pun hanyalah alat untuk melakukan pekerjaan. (Dan alat itu juga dibuat oleh orang-orang, menggunakan waktu mereka. )

Saya tidak akan menjelaskan employee , role dan has_role tabel di sini. Saya sudah melakukannya berkali-kali sebelumnya, misalnya di artikel ini. Jika perlu, silakan tinjau.

Tabel terakhir dalam model kami menghubungkan karyawan dan peran dengan pertunjukan. Kami dapat berharap untuk memiliki sejumlah karyawan yang memenuhi syarat dan kami perlu memastikan bahwa mereka akan tersedia saat dibutuhkan. Jelas, orang yang sama tidak bisa berada di dua tempat yang berbeda pada waktu yang sama. Atribut di engaged tabelnya adalah:

show_id dan has_role_id – Referensi acara terkait dan peran karyawan.
start_time – Saat kami mengharapkan seorang karyawan untuk memulai peran itu.
end_time – Saat peran itu berakhir. Ini dapat dibatalkan karena dalam banyak kasus kami akan menetapkan nilai setelah karyawan menyelesaikan perannya. Namun, kami mungkin memasuki waktu akhir yang diharapkan di sini.
cost_planned dan cost_actual – Apa yang kita harapkan untuk membayar karyawan untuk menangani peran itu dan apa yang sebenarnya kita bayar.

Sekali lagi, saya hanya akan menunjukkan bahwa data historis ini bisa sangat membantu saat Anda mengatur acara yang berulang atau yang mirip dengan acara sebelumnya.

Hari ini kita telah membahas kemungkinan model data untuk database manajemen acara. Kami telah membahas hal-hal yang sangat penting, seperti menjelaskan acara, menjadwalkan pemain, dan menugaskan karyawan dan sumber daya ke acara tersebut. Penanganan biaya dalam model ini disederhanakan, tetapi tetap memberi kita kemampuan untuk menghitung biaya yang direncanakan dan biaya aktual menurut kategori, acara, pertunjukan, atau jenis peralatan.

Saya bukan manajer acara. Jika ya, saya harap Anda menemukan artikel ini sangat membantu. Tetapi saya ingin mendengar tanggapan Anda tentang penambahan atau perubahan apa yang dapat berguna dalam situasi kehidupan nyata.

Tentu saja, semua orang dipersilakan untuk mengirimkan saran dan ide mereka di bagian komentar.