5

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

  • हम नई विलय कार्यालय के लिए सभी मौजूदा गतिविधि को देखने के लिए सक्षम होना चाहते हैं:

    रिपोर्टिंग/विश्लेषण आवश्यकताओं इस प्रकार हैं।

  • हम मर्ज किए गए कार्यालय या अभिभावक कार्यालयों द्वारा किए गए सभी गतिविधियों को देखने में सक्षम होना चाहते हैं।
  • हम दूसरे माता-पिता कार्यालय (कम से कम विलय से पहले) की गतिविधि को देखे बिना विलय से पहले और बाद में दोनों माता-पिता कार्यालयों में किए गए समय की गतिविधि को देखने में सक्षम होना चाहते हैं।

मुझे यकीन नहीं है कि किसी भी एससीडी प्रकार के साथ इसे कैसे मॉडल करें। यदि हम केवल एक ही नए के साथ दो मूल कार्यालय प्रविष्टियों को प्रतिस्थापित करते हैं, और तदनुसार सभी तथ्यों को अपडेट करते हैं, तो हमारे पास एक प्रकार का परिवर्तन होता है। इससे हमें वर्तमान गतिविधि को ठीक से देखने की इजाजत मिलती है, लेकिन हम इतिहास खो देते हैं। अगर हम रिकॉर्ड अलग रखते हैं, तो हम विलय के बारे में नहीं जान पाएंगे। यदि हम मर्ज किए गए कार्यालय का प्रतिनिधित्व करने के लिए तीसरा रिकॉर्ड जोड़ते हैं, तो हम इतिहास भी खो देते हैं (कौन सा प्राकृतिक कुंजी होगा? न तो माता-पिता कार्यालयों की प्राकृतिक चाबियाँ उपयुक्त होंगी)।

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

ElectricLlama के प्रश्नकाल के जवाब

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

प्रश्न 1: विलय के कितने स्तर हमें देखने की उम्मीद करते हैं? क्या हम भविष्य में अन्य कार्यालयों में विलय करने वाले कई स्तरों पर कई कार्यालयों को देखने की उम्मीद कर सकते हैं? या क्या हम केवल अपने सबसे जटिल, एकाधिक कार्यालयों को एक ही कार्यालय में विलय करने की उम्मीद करते हैं? प्रश्न 2: "विलय के पहले और बाद में दोनों माता-पिता कार्यालय में गतिविधि होती है"। इसका तात्पर्य है कि इसे किसी भी तरह विलय करने के बाद पूर्व-विलय वाली कार्यालय गतिविधियों का ट्रैक रखने की आवश्यकता है। क्या वो सही है? –

+0

@ElectricLlama: यह संभव है कि विलय का परिणाम होने वाला एक कार्यालय स्वयं भविष्य के बिंदु पर विलय हो सकता है, हालांकि हमारे पास वर्तमान समय में इसका कोई उदाहरण नहीं है। ऐसी संभावना भी है कि कार्यालयों को विभाजित किया जा सकता है, हालांकि मूल या यौगिक विलय से कहीं कम संभावना है। आपके अंतिम प्रश्न के अनुसार, उत्तर हाँ है, मैं पूर्व विलय गतिविधियों को ट्रैक करना चाहता हूं। – siride

+0

मुझे लगता है कि तीसरा विकल्प एकमात्र विकल्प है - एक नया सदस्य बनाएं - क्योंकि यह एकमात्र ऐसा है जो सभी जानकारी को बनाए रखता है। फिर एकमात्र चुनौती नए सदस्य को अपने पूर्व कार्यालयों में जोड़ रही है। यह तय करता है कि अंतिम उपयोगकर्ता को यह जानकारी कैसे मिल रही है। क्या कोई इस के लिए कस्टम एसक्यूएल प्रश्न बना रहा है या क्या आपके पास स्वयं सेवा है या क्या आपके पास इस रिपोर्ट में संबंधित कार्यालयों को शामिल करने के लिए टिक बॉक्स के साथ डिब्बाबंद रिपोर्ट है? मैं इसके लिए एक विशेष सफल पैटर्न से अवगत नहीं हूं लेकिन व्यक्तिगत रूप से मैं चीजों को डिजाइन करने से बचना चाहता हूं। –

उत्तर

1

मैं सबसे आसान संभव समाधान पसंद करूंगा जो ग्राहक स्वीकार कर सकता है, इसलिए मैं निम्नलिखित करूँगा। मैं कार्यालय आयाम में दो कार्यालय क्षेत्र प्रदान करेगा:

  1. Office_as_today
  2. Office_original

(बेशक आप ऐसे नाम हैं जो अपने ग्राहकों के लिए अच्छे हैं लेने के लिए है) से कम दो शुरू खेतों के बराबर सेट किया जाएगा। जब दो कार्यालय विलीन हो जाते हैं तो मैं दो मूल कार्यालयों में वापस जाऊंगा और विलय कार्यालय के नाम से Office_as_today फ़ील्ड को अपडेट करूँगा।

नए तथ्यों (विलय से) को दो फ़ील्ड के साथ एक नई पंक्ति के साथ पंजीकृत किया जाएगा।

समाधान बहुत सरल है और मर्ज के बाद मूल कार्यालयों का पालन करने में असमर्थ होने के अपवाद के साथ लगभग सभी आवश्यकताएं पूरी करता है (यहां मैं आपके "कम से कम" को रेखांकित करता हूं)।

+0

ये फ़ील्ड आयाम या तथ्य में होंगे? मैं आयाम मानता हूं, लेकिन मैं बस स्पष्ट होना चाहता हूं। आपके अंतिम पैराग्राफ के लिए, यह एक स्वीकार्य समझौता हो सकता है। आयाम में – siride

+0

। मैंने जवाब अपडेट किया। – momobo

+0

मुझे लगता है कि जब तक कार्यालय के जीवनकाल में केवल एक विलय होता है (जो शायद> 95% मामलों में सच होगा), यह समाधान सबसे अच्छा होगा। टाइप III एक अच्छा समझौता है। मुझे एक विचार था कि मैं एक सारणी शामिल कर सकता हूं जो पूर्ण इतिहास को अधिक सामान्यीकृत फैशन में स्टोर करता है यदि आवश्यक हो, लेकिन ज्यादातर मामलों में यह नहीं होगा। इस प्रकार, यह जवाब पर्याप्त है। – siride

संबंधित मुद्दे