विवाह संगठन डेटा मॉडल

शादियों में अक्सर मौज-मस्ती और उत्सव होता है, जिसमें कई मेहमान, भोजन, पेय, संगीत और नृत्य होते हैं। लेकिन यह सब उचित तैयारी और समन्वय के बिना नहीं हो सकता। आइए इस पर करीब से नज़र डालें कि कैसे डेटा मॉडलिंग हमें शादी को बेहतर ढंग से व्यवस्थित करने में मदद कर सकती है ताकि सब कुछ सुचारू रूप से चले।

प्रारंभिक पृष्ठभूमि

हालांकि हम सभी जानते हैं कि एक सामान्य शादी समारोह कैसा दिखता है, लेकिन कुछ पहलुओं पर संक्षेप में विचार करना दुख की बात नहीं है जो हमारे डेटा मॉडल को संभावित रूप से प्रभावित कर सकते हैं।

शादी के साथी

हालाँकि अधिकांश पारंपरिक संस्कृतियों में एक पुरुष और महिला के बीच समारोह होंगे, लेकिन अन्य समाजों में भी समलैंगिक विवाह होते हैं। हमारे डेटा मॉडल को इस तरह से डिज़ाइन किया जाना चाहिए कि यह सभी संभावनाओं को समायोजित करे।

पैमाना और जटिलता

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

अंतिम परिणाम और खर्च

ज्यादातर मामलों में, जोड़े उत्सव के बाद शादी कर लेते हैं और सभी लागतों (किराया, भोजन और पेय पदार्थ, बैंड, आदि) के लिए एक चालान प्राप्त करते हैं। वे अपने लिए इन सभी लागतों की देखभाल करने के लिए एक एजेंसी को किराए पर लेने का निर्णय ले सकते हैं, या वे इसे स्वयं ही संभालने का विकल्प चुन सकते हैं। किसी भी तरह से, हमें इन स्थितियों का हिसाब देना चाहिए।

डेटा मॉडल:अवलोकन

इस लेख के लिए हमारे डेटा मॉडल में पांच खंड हैं:

1. स्थान
2. साझेदार, उत्पाद और सेवाएं
3. शादियां
4. प्रतिभागियों
5. चालान

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

अनुभाग 1:स्थान

Locations अनुभाग में सार्वभौमिक तालिकाएँ हैं जिनका उपयोग कई अन्य डेटा मॉडल में किया जा सकता है। जैसा कि हमने पहले उल्लेख किया है, संपूर्ण विवाह समारोह केवल एक ही स्थान पर हो सकता है, या यह संभावित रूप से कई स्थानों पर फैल सकता है। आइए इस खंड की तालिकाओं पर अधिक विस्तार से चर्चा करें।

country तालिका उस देश के बारे में जानकारी संग्रहीत करती है जिसमें शादी होती है। ज्यादातर मामलों में, यह देश हमारी एजेंसी के स्थान से मेल खाएगा, लेकिन अगर हम अंतरराष्ट्रीय स्तर पर काम करते हैं तो ऐसा नहीं हो सकता है। इस तालिका में प्रत्येक देश को उसके country_name . द्वारा विशिष्ट रूप से परिभाषित किया गया है ।

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

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

स्थानों के लिए, ध्यान दें कि हमने असामान्य मामलों को कवर करने से बचने के लिए यहां एक रूढ़िवादी दृष्टिकोण अपनाया है, जिसमें समारोह, ट्रेन या हवाई जहाज में होता है (जिस स्थिति में, "स्थान" में कई शहर शामिल हो सकते हैं)। अगर हम इन मामलों को कवर करना चाहते हैं, तो हमें अपने मॉडल में कुछ बदलाव करने होंगे।

अनुभाग 2:भागीदार, उत्पाद और सेवाएं

इससे पहले कि हम अपने डेटा मॉडल के मध्य भाग की ओर बढ़ें, हमें उन सभी भागीदारों की सूची, जिनके साथ हम काम करते हैं, साथ ही उनके द्वारा ऑफ़र किए जाने वाले उत्पादों और सेवाओं को संग्रहीत करने की आवश्यकता है। इसे प्राप्त करने के लिए, हम पाँच तालिकाओं का उपयोग करेंगे।

सबसे पहले, हमारे साथ काम करने वाले सभी भागीदारों की सूची partner शब्दकोश। प्रत्येक भागीदार के लिए, हम उनका अद्वितीय partner_code संगृहीत करेंगे और partner_name ।

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

• service_code - एक मूल्य जिसका उपयोग हम किसी विशेष सेवा को विशिष्ट रूप से दर्शाने के लिए आंतरिक रूप से करेंगे।
• service_name - सेवा का नाम। ध्यान दें कि विभिन्न सेवाएं एक ही नाम साझा कर सकती हैं। ऐसा तब होगा जब हमारे दो साथी एक ही सेवा की पेशकश करते हैं, जिसकी काफी संभावना है। यह और भी वांछनीय होगा यदि वे समान सेवा प्रकार के लिए समान नाम का उपयोग करते हैं क्योंकि इससे समान सेवाओं के लिए कीमतों की तुलना करना बहुत आसान हो जाएगा।
• description - सेवा का एक वैकल्पिक पाठ्य विवरण।
• picture - उस स्थान का लिंक जहां संबद्ध सेवा चित्र संग्रहीत है।
• price - इस सेवा के लिए वर्तमान मूल्य। इसमें NULL का मान हो सकता है यदि मूल्य पहले विभिन्न कारकों का मूल्यांकन किए बिना निर्धारित नहीं किया जा सकता है, जैसे कि कितने लोग समारोह में भाग लेने की योजना बना रहे हैं।

provides_service तालिका भागीदारों को उनके द्वारा प्रदान की जाने वाली सेवाओं की सूची से संबंधित करती है। partner_id . के प्रत्येक अद्वितीय संयोजन के लिए और service_id , हम भागीदार द्वारा प्रदान की जाने वाली सेवा की प्रकृति और वर्तमान में सेवा उपलब्ध है या नहीं, इसका विस्तृत पाठ्य विवरण संगृहीत करेंगे।

हमें उत्पादों और भागीदारों के साथ उनके संबंधों के बारे में जानकारी संग्रहीत करने के लिए तालिकाओं की भी आवश्यकता होती है। product तालिका service तालिका, सिवाय, जैसा कि नाम से पता चलता है, यह उत्पादों के लिए विशिष्ट है। इस तालिका में, हम सभी संभावित उत्पादों को संग्रहीत करेंगे जो अधिकांश विवाह समारोहों के लिए आवश्यक हैं, जैसे कि अंगूठियां, पोशाक, सजावट, फूल, फर्नीचर, और बहुत कुछ।

इस अनुभाग में अंतिम तालिका provides_product टेबल। यह ठीक वैसे ही काम करता है जैसे provides_service तालिका, सेवाओं के विपरीत उत्पादों के लिए विशिष्ट को छोड़कर। यह निर्दिष्ट करता है कि हमारा कौन सा भागीदार विचाराधीन उत्पाद पेश करता है।

धारा 3:शादियां

आखिरकार हम अपने डेटा मॉडल—Weddings . के केंद्र में पहुंच गए हैं खंड। इसमें पाँच नई तालिकाएँ हैं जो अन्य अनुभागों की तालिकाओं का संदर्भ देती हैं। ध्यान दें कि हमारे मॉडल के आगामी भागों में इस अनुभाग की अपनी तालिकाओं का भी संदर्भ दिया जाएगा।

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

यहां विचार प्रत्येक शादी को घटनाओं की एक श्रृंखला के रूप में पेश करना है। बदले में ईवेंट वांछित उत्पादों/सेवाओं के ऑफ़र, अस्वीकृत और स्वीकृत ऑफ़र, और अन्य प्रासंगिक विवरण से संबंधित होंगे। यह सब कैसे काम करता है, इसके बारे में आपको एक बेहतर विचार देने के लिए, हम पूरी शादी को निम्नलिखित घटनाओं में विभाजित कर सकते हैं:योजना चरण, स्नातक/स्नातक पार्टियां, समारोह, और पार्टी/रात्रिभोज के बाद। बेशक, ये कुछ सबसे आम शादी के कार्यक्रम हैं। सभी शादी की घटनाओं को घटना तालिका में संग्रहीत किया जाता है। एक event यूनिक आईडी होगी।

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

आगे बढ़ते हुए, हम उन सभी सेवाओं और उत्पादों को संग्रहीत करना चाहते हैं जो किसी ईवेंट से संबंधित हैं। ऐसा करने के लिए, हम तीन तालिकाओं का उपयोग करेंगे:status , product_included , और service_included ।

status तालिका एक शब्दकोश है जो किसी विशेष घटना के लिए उत्पादों और सेवाओं से संबंधित सभी स्थितियों का ट्रैक रखता है। इसमें फ़्लैग वेरिएबल्स शामिल हैं जो यह दर्शाते हैं कि किसी उत्पाद/सेवा की पेशकश की गई है, स्वीकार किया गया है या अस्वीकार किया गया है। इस तालिका में प्रत्येक रिकॉर्ड के लिए, हम एक अद्वितीय status_name . संग्रहित करेंगे ।

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

• event_id - संबंधित घटना का संदर्भ।
• provides_product_id / provides_service_id - हमारे भागीदारों के पास उपलब्ध उत्पादों/सेवाओं वाली तालिकाओं के संदर्भ।
• price - उत्पाद / सेवा के लिए प्रस्तावित मूल्य। यदि हम किसी विशेष प्रस्ताव का प्रस्ताव करते हैं तो यह मूल्य हमारे द्वारा दर्ज मानक मूल्य से भिन्न हो सकता है।
• current_status_id - status शब्दकोश यह दर्शाता है कि यह रिकॉर्ड पेश किया गया था, स्वीकार किया गया था या अस्वीकार कर दिया गया था।

अनुभाग 4:प्रतिभागी

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

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

इसके बाद, हम उन सभी संभावित भूमिकाओं को परिभाषित करेंगे जो कोई शादी के दौरान ग्रहण कर सकता है। इन भूमिकाओं में "अतिथि", "सर्वश्रेष्ठ आदमी", "दूल्हे", "दुल्हन", "दुल्हन", "दूल्हे", और इसी तरह शामिल हैं। प्रत्येक भूमिका के लिए, हम केवल अद्वितीय role_name . संग्रहित करेंगे इस तालिका में। एक व्यक्ति किसी विशेष विवाह के लिए केवल एक ही भूमिका निभा सकता है।

इसके बाद, हम शादियों को उनके प्रतिभागियों से जोड़ेंगे। ध्यान दें कि participate तालिका में केवल तालिकाओं के संदर्भ शामिल हैं wedding , person , और role . wedding_id . का संयोजन और person_id इस तालिका के लिए वैकल्पिक कुंजी के रूप में कार्य करता है।

शादी में कई कार्यक्रम शामिल होंगे, लेकिन सभी प्रतिभागी इनमें शामिल नहीं होंगे। इसलिए, हमें इस जानकारी को अलग से स्टोर करने की आवश्यकता है। in_event तालिका में, हम तालिका event और participate . सभी अतिरिक्त जानकारी description . में संगृहीत की जाएगी टेक्स्ट एट्रिब्यूट किया गया।

अनुभाग 5:चालान

हम लगभग कर चुके हैं! हमारे डेटा मॉडल का अंतिम खंड हमें शादी से संबंधित खर्चों को ट्रैक करने की अनुमति देता है। रोमांचक, है ना?

हम आम तौर पर एक invoice प्रति शादी, लेकिन हम जरूरत पड़ने पर और भी अधिक कमा सकते हैं। उम्मीद है, हम जोड़े के चालान की कुल राशि हमारे नियोजित बजट से काफी हद तक मेल खाएंगे, लेकिन ऐसा हमेशा नहीं हो सकता है। प्रत्येक चालान के लिए, हम निम्नलिखित जानकारी संग्रहीत करेंगे:

• wedding_id - उस शादी का संदर्भ जिसके लिए चालान जारी किया गया था।
• time_created - इनवॉइस जनरेट होने का टाइमस्टैम्प।
• due_date - जिस तारीख तक चालान का भुगतान किया जाना चाहिए।
• invoice_amount - भुगतान की जाने वाली कुल राशि।
• payment_time - वह टाइमस्टैम्प जब भुगतान वास्तव में जारी किया गया था। बेशक, भुगतान किए जाने तक इस विशेषता में NULL का मान होगा।
• paid - एक झंडा यह दर्शाता है कि चालान का भुगतान किया गया था या नहीं। payment_time . जैसे ही यह विशेषता "सही" पर सेट हो जाएगी अपडेट किया गया है।

हमारे मॉडल में अंतिम तालिका स्वयं इनवॉइस किए गए आइटम से संबंधित है। हम इन्हें invoice_item टेबल। प्रत्येक रिकॉर्ड के लिए, हम निम्नलिखित विवरण संग्रहीत करेंगे:

• item_name - विशिष्ट वस्तु के लिए हमारा चुना हुआ नाम।
• item_price - वह कीमत जो उस विशिष्ट वस्तु से संबंधित है।
• invoice_id - संबंधित चालान की आईडी।
• service_included_id - चालान आइटम से संबंधित सेवा की आईडी। यह विशेषता NULL पर सेट की जा सकती है यदि विचाराधीन वस्तु वास्तव में किसी सेवा से संबंधित नहीं है या यदि यह केवल एक अतिरिक्त शुल्क है जिसे हमने चालान पर लागू किया है।
• product_included_id - उस उत्पाद की आईडी जिससे इनवॉइस आइटम संबंधित है। यह विशेषता NULL पर सेट की जा सकती है यदि विचाराधीन वस्तु वास्तव में किसी उत्पाद से संबंधित नहीं है या यदि यह केवल एक अतिरिक्त शुल्क है जिसे हमने चालान पर लागू किया है।

सारांश

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

जैसा कि हमने नोट किया, सरलता के लिए कई चीजें हैं जिन्हें हमने अपने डेटा मॉडल से हटा दिया है। उदाहरण के लिए, हमारे मॉडल को आदर्श रूप से ऑफ़र इतिहास, वित्तीय विवरण, और बहुत कुछ ट्रैक करना चाहिए।

अगर आपके पास कोई सुझाव है तो हमें नीचे बताएं। हमें आपके विचार सुनना अच्छा लगेगा!