एक इवेंट मैनेजमेंट डेटा मॉडल

एक कार्यक्रम आयोजित करना बहुत काम है! इस लेख में, हम एक इवेंट संगठन ऐप के पीछे के डेटा मॉडल की जांच करते हैं।

यदि आपने कभी दस से अधिक लोगों के लिए एक कार्यक्रम आयोजित करने का प्रयास किया है (और यहां पार्टियों या व्यावसायिक बैठकों की गणना नहीं करते हैं) तो आप जानते हैं कि घटना प्रबंधन कितना जटिल हो सकता है! क्या हमने सभी को आमंत्रित किया है? क्या उन्होंने पुष्टि की है कि वे आ रहे हैं? क्या स्थल बुक और तैयार है? आयोजन की मेजबानी कौन करेगा? विभिन्न भागों में कौन भाग लेगा? उत्तर देने के लिए कई अन्य प्रश्न हैं, और चीजें आसानी से गलत हो सकती हैं।

आप अपनी सारी प्लानिंग पेपर और पेन से कर सकते हैं, लेकिन ऐप का इस्तेमाल क्यों नहीं करते? यह अधिक सुविधाजनक है! किसी भी ऐप को सभी आवश्यक ईवेंट जानकारी संग्रहीत करने के लिए एक स्थान की आवश्यकता होगी। यहीं पर हमारा इवेंट मैनेजमेंट डेटा मॉडल इस कहानी में प्रवेश करता है। एक कॉफी लें, अपनी पसंदीदा कुर्सी पर बैठें, और हम देखेंगे कि इवेंट मैनेजमेंट डेटा मॉडल बनाने में क्या लगता है।

इवेंट मैनेजमेंट से जुड़े अक्सर पूछे जाने वाले सवाल

इससे पहले कि हम मॉडल की व्याख्या करें और वर्णन करें कि हम डेटा को कैसे स्टोर करेंगे, आइए पहले कुछ इवेंट मैनेजमेंट बेसिक्स की समीक्षा करें:

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 शब्दकोश उन घटनाओं को वर्गीकृत करता है जिन्हें हम संभालते हैं। हम सभी संभावित प्रकार की घटनाओं को उनके स्थान के अनुसार संग्रहीत करेंगे:संगीत कार्यक्रम, फुटबॉल मैच, बास्केटबॉल खेल, आईटी सम्मेलन, आदि। प्रत्येक घटना प्रकार को इसके type_name द्वारा विशिष्ट रूप से परिभाषित किया गया है। ।

जैसा कि हमने पहले उल्लेख किया है, घटनाओं में आमतौर पर भागीदार होते हैं। अधिकांश आयोजनों में कम से कम एक मीडिया भागीदार होगा, जबकि कुछ में प्रायोजक और अन्य भागीदार भी होंगे। एक ही साथी की एक ही घटना पर कई अलग-अलग "भागीदार भूमिकाएँ" हो सकती हैं। उदाहरण के लिए, एक टेलीविजन प्रसारण कंपनी मीडिया पार्टनर और एक ही समय में कार्यक्रम की सामान्य प्रायोजक हो सकती है। यही कारण है कि हम भागीदारों के साथ ईवेंट को जोड़ने के लिए तीन तालिकाओं का उपयोग करेंगे।

योजना चरण में भागीदारों को जोड़ने में सक्षम होना महत्वपूर्ण है ताकि सभी घटना हितधारकों को उस जानकारी तक समय पर पहुंच प्राप्त हो सके। साथ ही, जब हम नए ईवेंट की योजना बना रहे हों तो हम पिछले डेटा का उपयोग कर सकते हैं - उदा. जब हम एक पुनरावर्ती ईवेंट या उसी प्रकार का कोई नया ईवेंट आयोजित कर रहे हों, तो हम उसी पार्टनर से संपर्क कर सकते हैं। अगर कोई कंपनी पिछले साल तकनीकी सम्मेलन की सामान्य प्रायोजक थी, तो वे इस साल इसे फिर से करने में दिलचस्पी ले सकते हैं।

अब, आइए तीन साझेदारी तालिकाओं को देखें। पहला है partner सूची प्रत्येक भागीदार के लिए, हम partner_name . संग्रहित करेंगे और उनका पता, संपर्क जानकारी और अन्य partner_details . ध्यान दें कि partner_name विशेषता अद्वितीय नहीं है। हमारे पास एक ही नाम के दो साझेदार हो सकते हैं, जैसे कि एक ही प्रथम और अंतिम नाम वाले दो निजी व्यक्ति या एक ही कंपनी नाम वाली दो कंपनियां। इस मामले में, हम partner_details में संग्रहीत जानकारी का उपयोग करके उनके बीच अंतर करेंगे विशेषता।

दूसरी तालिका है partner_role शब्दकोश, जो एक भागीदार की सभी विभिन्न भूमिकाओं को सूचीबद्ध करता है। role_name विशेषता में केवल UNIQUE मान होंगे। कुछ अपेक्षित भूमिका नाम "मीडिया पार्टनर", "सामान्य प्रायोजक" और "प्रायोजक" हैं।

इस विषय क्षेत्र में अंतिम तालिका भागीदारों को घटनाओं से संबंधित करती है। is_partner तालिका में केवल विदेशी कुंजियाँ होती हैं जो भागीदारों को घटनाओं से संबंधित करती हैं और भूमिकाओं या साझेदारी प्रकारों को परिभाषित करती हैं। इन विदेशी कुंजियों का संयोजन तालिका की UNIQUE कुंजी बनाता है। यदि हम चाहें, तो हम एक आरंभ तिथि और एक समाप्ति तिथि जोड़ सकते हैं, यदि कोई भागीदार केवल घटना के भाग के लिए अपनी भूमिका भरता है। हम भागीदारों को एकल उप-घटनाओं के साथ और संपूर्ण घटनाओं के बजाय जोड़ सकते हैं। फिर भी, ये अपेक्षाकृत असामान्य स्थितियां हैं, इसलिए हम मॉडल के इस हिस्से को यथावत छोड़ देंगे।

अनुभाग 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 . डिस्को बॉल के लिए, इसका "उपकरण"।"नाम" का मान "डिस्को बॉल" होगा, लेकिन इसका "उपकरण_प्रकार" होगा।"टाइप_नाम""प्रकाश उपकरण" होगा। available विशेषता परिभाषित करती है कि हमारे लिए कितनी मात्रा में वस्तु उपलब्ध है। यह एक दशमलव संख्या है क्योंकि शायद हम कुछ ऐसी "आइटम" का उपयोग करेंगे जिनकी गणना नहीं की जा सकती, जैसे पानी और बिजली।

इस खंड में अंतिम तालिका उपकरण और शो से संबंधित है। यह हमें योजना चरण में उपकरण व्यवस्थित करने में मदद कर सकता है; यह हमें बाद में उपकरण लागत के बारे में रिपोर्ट बनाने में सक्षम बनाता है। जब हम उपकरण के उपयोग और लागत की योजना बना रहे होते हैं, तो यह जानकारी बहुत उपयोगी हो सकती है, विशेष रूप से आवर्ती (या बहुत समान) घटनाओं के लिए। required टेबल हैं:

• show_id और equipment_id - संबंधित शो और उपकरणों को संदर्भित करता है। यह जोड़ी तालिका की UNIQUE कुंजी बनाती है।
• quantity - उस उपकरण की मात्रा की आवश्यकता है।
• cost_planned और cost_actual - उपकरण स्थापित करने या किराए पर लेने के लिए हम क्या भुगतान करने की अपेक्षा करते हैं और हमने वास्तव में क्या भुगतान किया है।

धारा 3:कर्मचारी

इस मॉडल का विषय क्षेत्र कर्मचारियों और उनकी भूमिकाओं के बारे में है। मुझे हमेशा यह बताना अच्छा लगता है कि लोग और उनका समय किसी भी परियोजना का सबसे महत्वपूर्ण हिस्सा होते हैं। और कुछ भी काम करने के लिए सिर्फ एक उपकरण है। (और वह उपकरण भी लोगों द्वारा अपने समय का उपयोग करके बनाया गया था। )

मैं employee , role और has_role यहाँ टेबल। मैंने इसे पहले भी कई बार किया है, उदाहरण के लिए इस लेख में। यदि आप की आवश्यकता है, तो कृपया इसकी समीक्षा करें।

हमारे मॉडल में अंतिम तालिका शो के साथ कर्मचारियों और भूमिकाओं से संबंधित है। हम सीमित संख्या में योग्य कर्मचारियों की अपेक्षा कर सकते हैं और हमें यह सुनिश्चित करने की आवश्यकता होगी कि आवश्यकता पड़ने पर वे उपलब्ध होंगे। जाहिर है, एक ही व्यक्ति एक ही समय में दो अलग-अलग जगहों पर नहीं हो सकता। engaged टेबल हैं:

• show_id और has_role_id - संबंधित शो और कर्मचारी भूमिका का संदर्भ देता है।
• start_time - जब हम किसी कर्मचारी से उस भूमिका को शुरू करने की अपेक्षा करते हैं।
• end_time - जब वह भूमिका समाप्त हो जाती है। यह अशक्त है क्योंकि ज्यादातर मामलों में हम कर्मचारी द्वारा अपनी भूमिका समाप्त करने के बाद एक मान निर्दिष्ट करेंगे। हालांकि, हम यहां अपेक्षित समाप्ति समय दर्ज कर सकते हैं।
• cost_planned और cost_actual - उस भूमिका को संभालने के लिए हम एक कर्मचारी को कितना भुगतान करने की उम्मीद करते हैं और हमने वास्तव में क्या भुगतान किया है।

एक बार फिर, मैं केवल यह बताना चाहूंगा कि यह ऐतिहासिक डेटा तब बहुत मददगार हो सकता है जब आप किसी दोहराए जाने वाले ईवेंट या पिछले ईवेंट के समान किसी ईवेंट का आयोजन कर रहे हों।

आज हमने इवेंट मैनेजमेंट डेटाबेस के लिए संभावित डेटा मॉडल पर चर्चा की है। हमने वास्तव में महत्वपूर्ण चीजों को कवर किया है, जैसे कि घटना का वर्णन करना, प्रदर्शन करने वालों को शेड्यूल करना और कर्मचारियों और संसाधनों को घटना के लिए असाइन करना। इस मॉडल में लागतों का प्रबंधन सरल है, लेकिन यह अभी भी हमें श्रेणी, घटना, शो या उपकरण प्रकार द्वारा नियोजित और वास्तविक लागतों की गणना करने की क्षमता प्रदान करता है।

मैं इवेंट मैनेजर नहीं हूं। यदि आप हैं, तो मुझे आशा है कि आपको यह लेख बहुत उपयोगी लगा होगा। लेकिन मैं आपकी प्रतिक्रिया सुनना चाहूंगा कि वास्तविक जीवन की स्थितियों में कौन से परिवर्धन या परिवर्तन उपयोगी हो सकते हैं।

बेशक, टिप्पणी अनुभाग में अपने सुझाव और विचार प्रस्तुत करने के लिए सभी का स्वागत है।