रिपोर्ट-प्रेरित डिजाइन

यह आलेख अनुप्रयोगों के निर्माण और डेटाबेस संरचना को लागू करने के लिए एक वैकल्पिक दृष्टिकोण पर चर्चा करता है।

इस दृष्टिकोण का मुख्य विचार यह है कि अनुप्रयोग विकास प्रक्रिया उन रिपोर्टों के विश्लेषण पर आधारित है जो एक तैयार किए गए व्यावसायिक अनुप्रयोग द्वारा उत्पन्न की जानी चाहिए।

हम इस RDD दृष्टिकोण रिपोर्ट-प्रेरित डिजाइन कहते हैं ।

शुरुआत में एक रिपोर्ट आई थी

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

इन उपयोगकर्ताओं के साथ संवाद करते हुए, हमने अनपेक्षित रूप से कई समस्याओं की खोज की है जो अक्सर एक विशिष्ट व्यवसाय अनुप्रयोग में रिपोर्टिंग मॉड्यूल को लागू करते समय उत्पन्न होती हैं।

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

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

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

सहमत, यह अक्सर होता है। फिर वाजिब सवाल उठता है: “शुरू से ही रिपोर्टों का ध्यान क्यों नहीं रखा गया? एप्लिकेशन को डिज़ाइन करते समय उन्हें मुख्य लक्ष्य क्यों न बनाएं, अगर यह वास्तव में हमें अंत में क्या चाहिए? ”

एक रिपोर्ट क्या है?

आइए पहले तय करें कि एक रिपोर्ट से हमारा क्या मतलब है।

रिपोर्टिंग करते समय आपके सिर में क्या संघ हैं? संभवतः, ये एक सारणीबद्ध या अन्य रूप में प्रस्तुत कुछ डेटा वाले पृष्ठ हैं, जो आगे के विश्लेषण के लिए सुविधाजनक है।



इसके अलावा, यह स्पष्ट है कि रिपोर्ट आवश्यक रूप से मुद्रित संस्करण नहीं है। यह किसी प्रकार की फ़ाइल हो सकती है, यह xls, pdf, doc या यहां तक ​​कि एक वेब पेज हो सकता है। यह स्पष्ट है कि एक रिपोर्ट में न केवल सारणीबद्ध या क्रॉस-टेबुलर डेटा (तथाकथित पिवट टेबल) हो सकता है, बल्कि ग्राफ भी हो सकता है, और बहुत सारी अन्य जानकारी जो विश्लेषण के लिए भी उपयोगी हो सकती है।



इस प्रकार, एक रिपोर्ट से हमारा मतलब जानकारी वाले किसी भी पृष्ठ से है।

चार "मैं"

तो रिपोर्ट संचालित डिजाइन विकास प्रक्रिया क्या है? सबसे पहले, हम इसे एक पुनरावृत्त प्रक्रिया के रूप में समझते हैं, जो इसे अन्य चुस्त प्रथाओं के समान बनाती है।

इस मामले में, हम चार I के रूप में RDD की मूल अवधारणा तैयार करते हैं:

• सूचना (सूचना)
• इंटरेक्शन (बातचीत)
• इनपुट (डाटा एंट्री)
• Iterate (अगले पर जाएं)

अब मैं समझाता हूं कि इस सब का मतलब क्या है।

इससे पहले कि आप कार्यक्रम और इसके लिए डेटाबेस को डिजाइन करना शुरू करें, आपको ग्राहक से विशिष्ट रिपोर्टों का एक सेट प्राप्त करने की आवश्यकता होती है जिन्हें उत्पन्न करने की आवश्यकता होगी। फिर आप इनमें से एक रिपोर्ट लेते हैं और विश्लेषण करते हैं कि इसमें क्या जानकारी प्रस्तुत की गई है:

• क्षैतिज जानकारी इंगित करती है कि संबंधित तालिका में कौन से कॉलम हो सकते हैं;
• ऊर्ध्वाधर डेटा परिवर्तन इस बात की समझ प्रदान करता है कि किस जानकारी को पंक्तियों में संग्रहीत किया जाना चाहिए;
• और रिपोर्ट में डेटा को समूहीकृत करने से यह पता चलता है कि किन क्षेत्रों को समूह में रखा जाए और उन्हें अलग तालिका में रखा जाए या नहीं।

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

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

खैर, अंतिम बिंदु Iterate है : अगली रिपोर्ट पर जाएं और सभी चरणों को फिर से दोहराएं।

मैं मानता हूं कि पहली बार ऐसी प्रक्रिया आपके लिए अनुपयुक्त हो सकती है, कम से कम आपके विशिष्ट मामले के लिए। लेकिन अगर आपकी एप्लिकेशन रिपोर्टिंग पीढ़ी किसी विशेष स्थान पर है, तो आप सुरक्षित रूप से RDD लागू करने का प्रयास कर सकते हैं और सुनिश्चित कर सकते हैं कि यह काम करता है ।

आइए देखें कि RDD एक जीवंत उदाहरण में कैसे काम करता है। उदाहरण के लिए, आइए एक ऑनलाइन स्टोर के जीवन से विशिष्ट कार्य करें।

उदाहरण 1: गोदाम

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

फिर उसी स्टोर पर 2 अन्य गोदाम दिखाई देते हैं, पहले से ही सामानों का एक अलग वर्गीकरण। और वहां एक ही दृष्टिकोण का उपयोग किया जाने लगा - एक प्रोग्राम वाला सर्वर जहां ऑपरेटर उत्पाद के बारे में जानकारी दर्ज करते हैं। कुल में, हमारे पास 3 डेटाबेस के साथ 3 अलग-अलग गोदाम हैं।

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

इस प्रकार, इन सभी तालिकाओं को एक डेटाबेस में जोड़ना और रिपोर्ट बनाने के लिए आवेदन के साथ एक ही स्थानीय नेटवर्क पर रखना पूरी तरह से तर्कसंगत होगा।

यह संभव है कि डेटा प्रविष्टि धीमा हो जाएगी (यदि ऑपरेटर एक अलग स्थानीय नेटवर्क पर है), लेकिन बहुत अधिक नहीं है, और रिपोर्ट पीढ़ी में काफी वृद्धि होगी।

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



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

उदाहरण 2: मतदान

अब ऑनलाइन स्टोर बनाने के कार्य से एक और उदाहरण पर विचार करें। यह तथाकथित रेटिंग नियंत्रण है - मतदान के लिए एक तत्व, उदाहरण के लिए, खरीदार के लिए चयनित उत्पाद का मूल्यांकन करना।



यहां एल्गोरिदम सरल है: कोई भी उपयोगकर्ता किसी भी उत्पाद के लिए एक बार वोट कर सकता है। इस परिदृश्य के बाद, हम इस तरह के प्रत्येक वोट को अपनी तालिका में दर्ज करते हैं।

CustomerID	ProductID	रेटिंग

अब हमें यह देखने की आवश्यकता है कि इस डेटा के आधार पर हमें किन रिपोर्टों की आवश्यकता है।

उदाहरण के लिए, उपरोक्त तालिका बहुत उपयोगी होगी यदि हमें ऐसी रिपोर्ट की आवश्यकता होती है जिसमें किसी विशेष व्यक्ति द्वारा विभिन्न उत्पादों के लिए मतदान करने की जानकारी शामिल हो।

यदि ऐसी कोई रिपोर्ट हमारी सूची में नहीं है, अर्थात, किसी विशेष मतदाता की जानकारी हमारे लिए महत्वपूर्ण नहीं है, लेकिन किसी विशिष्ट उत्पाद की जानकारी महत्वपूर्ण है, तो हम ग्राहक तालिका से सुरक्षित रूप से इस तालिका को हटा सकते हैं।

ProductID	रेटिंग

(यदि हम अभी भी यह जानकारी सहेजना चाहते हैं कि किसी व्यक्ति ने किन उत्पादों के लिए मतदान किया है - और हम उसे फिर से मतदान करने से रोकना चाहते हैं - हम इस डेटा को या तो अलग ग्राहक आईडी + ProductID तालिका में संग्रहीत कर सकते हैं या ग्राहक तालिका में अन्य RatedProducts स्तंभ जोड़ सकते हैं और इस जानकारी को मेटा डेटा के रूप में स्टोर करें)

आगे बढ़ते हुए, हम अचानक महसूस कर सकते हैं कि उपरोक्त रिपोर्ट या तो हमारे लिए बहुत महत्वपूर्ण नहीं है या इसकी बिल्कुल भी आवश्यकता नहीं है।

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

ProductID	TotalRating	CustomersNumber

जो कुछ भी शेष है वह विभाजन ऑपरेशन है, जिसे हर बार उत्पाद की वर्तमान रेटिंग के बारे में जानकारी प्रदर्शित की जाती है। बहुत बढ़िया।

यह जानकारी कितनी बार दिखाई जाएगी? बहुत बार - आखिरकार, बहुत सारे उपयोगकर्ता अपनी रेटिंग की तुलना करते हुए एक उत्पाद सूची (उदाहरण के लिए, प्रति पृष्ठ 20 उत्पाद) के माध्यम से "पत्ती" कर सकते हैं।



बैकफिल प्रश्न : क्या हम इस मामले में डिवीजन ऑपरेशन से छुटकारा पा सकते हैं? ;-)

उत्तर : हम सभी मतों के योग को नहीं, बल्कि वर्तमान रेटिंग को संग्रहीत कर सकते हैं। तब मतदान के समय, फिर से, डेटा दर्ज करते समय विभाजन ऑपरेशन की आवश्यकता होगी। यहाँ सूत्र है:



जहां x उपयोगकर्ता की आवाज है।

कुल

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

पुनश्च
वैसे, यदि आप इस सप्ताह अचानक देवकोन 11 का दौरा करने जा रहे हैं, तो मैं इस दृष्टिकोण के पेशेवरों और विपक्षों के साथ व्यक्तिगत रूप से चर्चा करने के लिए तैयार हूं। सम्मेलन के दूसरे दिन मैं आरडीडी के विषय पर एक प्रस्तुति करूंगा और आपकी राय सुनकर मुझे बहुत खुशी होगी, ठीक है, बस सभी वास्तविक खब्रोविट्स के साथ हाथ मिलाएं।

देवकॉन में मिलते हैं!