खूनी उद्यम में डेटा माइग्रेशन: विश्लेषण करने के लिए क्या, ताकि परियोजना को डूबने के लिए नहीं

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

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

एक परियोजना पर, हमने तीन महीने बस इसलिए खो दिए क्योंकि इंटीग्रेटर्स की एक तृतीय-पक्ष टीम ने स्रोत प्रणालियों में डेटा का अध्ययन नहीं किया था। सबसे कष्टप्रद बात यह थी कि इससे बचा जा सकता था।

उन्होंने इस तरह काम किया:

1. सिस्टम इंटीग्रेटर्स ईटीएल प्रक्रिया को अनुकूलित करते हैं।
2. ईटीएल स्रोत डेटा को रूपांतरित करता है और मुझे देता है।
3. मैं अनलोडिंग का अध्ययन करता हूं और इंटीग्रेटर्स को त्रुटियां भेजता हूं।
4. इंटीग्रेटर्स ईटीएल को सही करते हैं और दोबारा माइग्रेशन शुरू करते हैं।

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

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

लेकिन पहले, सिस्टम एकीकरण के मुख्य मिथकों में से एक के बारे में।

प्रलेखन और वास्तुकार मदद करेगा (वास्तव में नहीं)

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

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

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

एक आम कहानी: ग्राहक तालिका में एक क्षेत्र "एसएनआईएलएस" है, कागज पर यह बहुत महत्वपूर्ण है। लेकिन जब मैं आंकड़ों को देखता हूं, तो देखता हूं - मैदान खाली है। नतीजतन, ग्राहक इस बात से सहमत है कि लक्ष्य आधार SNILS के लिए एक क्षेत्र के बिना करेगा, क्योंकि अभी भी कोई डेटा नहीं है।

प्रलेखन का एक विशेष मामला व्यापार प्रक्रियाओं का नियम और विवरण है: कैसे डेटा डेटाबेस में, किन परिस्थितियों में, किस प्रारूप में मिलता है। यह सब भी मदद नहीं करेगा।

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

नसों को अभी तक क्रम में नहीं रखा गया है, और अनातोली नए ग्राहक के नाम को अंतिम नाम फ़ील्ड में पूरी तरह से चलाती है। वह अपने जन्मदिन के बारे में पूरी तरह से भूल जाता है - डिफ़ॉल्ट "01.01.1900 जी" फॉर्म में रहता है। जब सब कुछ इतना भयावह हो जाता है तो मैं नियमों के बारे में कुछ नहीं बताती हूँ !!!

अराजकता व्यापार प्रक्रियाओं को जीतती है, कागज पर बहुत अच्छी तरह से अनुपातित होती है।

एक सिस्टम आर्किटेक्ट को सब कुछ पता नहीं है। यह फिर से उद्यम प्रणालियों के आदरणीय जीवनकाल के बारे में है। वर्षों से वे काम करते हैं, आर्किटेक्ट बदल गए हैं। यहां तक ​​कि अगर आप वर्तमान के साथ बात करते हैं, तो पिछले वाले फैसले परियोजना के दौरान आश्चर्य के रूप में सामने आएंगे।

और सुनिश्चित करें: यहां तक ​​कि सभी मामलों में एक सुखद वास्तुकार अपने फेकैपी और सिस्टम की बैसाखी को गुप्त रखेगा।

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

भरे हुए खेत और अशक्त मूल्य

सबसे सरल जांच एक पूरे के रूप में और व्यक्तिगत क्षेत्रों की पूर्णता पर तालिकाओं की पूर्णता पर होती है। मैं उनके साथ शुरू कर रहा हूँ

तालिका में कुल पंक्तियाँ कितनी हैं। सबसे सरल अनुरोध संभव है।

SELECT COUNT(*) FROM <table_name>; 

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

प्रत्येक क्षेत्र के लिए अलग-अलग कितनी लाइनें भरी जाती हैं। मैं तालिका के सभी स्तंभों की जांच करता हूं।

 SELECT <column_name>, COUNT(*) AS <column_name> cnt FROM <table_name> WHERE <column_name> IS NOT NULL; 

पहला जन्मदिन मुबारक क्षेत्र में आया, और तुरंत उत्सुक: किसी कारण से, डेटा बिल्कुल नहीं आया।
यदि अपलोड में फ़ील्ड के सभी मान "NULL" हैं, तो पहली चीज़ जो मैं देख रहा हूं वह है स्रोत सिस्टम। शायद डेटा वहाँ ठीक से संग्रहीत है, लेकिन वे प्रवास के दौरान खो गए थे।

मैं देख रहा हूं कि स्रोत प्रणाली में जन्मदिन की जगह है। मैं इंटीग्रेटर्स के पास जाता हूं: दोस्तों, गलती। यह पता चला कि ईटीएल प्रक्रिया में, डिकोड फ़ंक्शन ने गलत तरीके से काम किया। कोड तय किया गया था, अगले अपलोड में हम परिवर्तनों की जांच करेंगे।

मैं टिन के साथ क्षेत्र में आगे जाता हूं।
डेटाबेस में 100 मिलियन लोग हैं, और केवल 65 हजार टीआईएन से भरे हुए हैं - यह 0.07% है। इस तरह के कमजोर कब्जे एक संकेत है कि रिसीवर के आधार में फ़ील्ड बिल्कुल भी आवश्यक नहीं हो सकता है।

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

मुझे ग्राहक हटाने का झंडा मिला।
झंडे खाली हैं। लेकिन क्या, कंपनी ग्राहकों को नहीं हटाती है? मैं स्रोत प्रणाली को देखता हूं, ग्राहक के साथ बात करता हूं। यह पता चला है कि हाँ: झंडा औपचारिक है, ग्राहकों को हटाने के बजाय, उनके खाते हटा दिए जाते हैं। कोई खाता नहीं - मानो ग्राहक हटा दिया गया हो।

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

इसके बाद पता प्लेट है। आमतौर पर ऐसी तालिकाओं के साथ कुछ गलत है, क्योंकि पते एक जटिल चीज हैं, उन्हें अलग-अलग तरीकों से दर्ज किया जाता है।

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

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

विश्लेषण के दौरान, मैं निर्देशिकाओं को विशेषता के साथ जोड़ने वाले क्षेत्रों को भरता हूं। "NULL नहीं है" स्थिति उनके साथ काम नहीं करती है: "NULL" के बजाय, सेल आमतौर पर "0" है। इसलिए, संदर्भ फ़ील्ड अलग से जांचें।

खेतों के भरने में परिवर्तन। इसलिए, मैंने प्रत्येक क्षेत्र के समग्र अधिभोग और अधिभोग की जाँच की। समस्याओं का पता चला, इंटीग्रेटर्स ने ईटीएल प्रक्रिया को तय किया और फिर से माइग्रेशन शुरू किया।

मैं ऊपर सूचीबद्ध सभी चरणों के लिए दूसरा अनलोडिंग चलाता हूं। मैं परिवर्तनों को देखने के लिए उसी फ़ाइल में आंकड़े लिखता हूं।

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

• "रिकॉर्ड क्यों खो गए थे?"
• "क्या डेटा स्क्रीन किया गया था?"
• "आपने क्या डेटा छोड़ा?"

यह पता चला है कि कोई समस्या नहीं है: उन्होंने बस "तकनीकी" ग्राहकों को ताजा उतराई से हटा दिया। वे परीक्षण के लिए डेटाबेस में हैं, वे जीवित लोग नहीं हैं। लेकिन उसी संभावना के साथ, डेटा गलती से खो सकता है, ऐसा होता है।

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

संक्षेप में, क्या जाँचना है।

1. तालिकाओं में प्रविष्टियों की कुल संख्या। क्या यह मात्रा अपेक्षाओं के अनुरूप है?
2. प्रत्येक क्षेत्र में भरी लाइनों की संख्या।
3. प्रत्येक फ़ील्ड में भरी हुई पंक्तियों की संख्या का अनुपात तालिका में पंक्तियों की संख्या के अनुपात में है। यदि यह बहुत छोटा है, तो यह इस बारे में सोचने का अवसर है कि फ़ील्ड को लक्ष्य के आधार पर खींचें या नहीं।

प्रत्येक अपलोड के लिए पहले तीन चरणों को दोहराएं। डायनामिक्स का पालन करें: यह कहां और क्यों बढ़ा या घटा है।

स्ट्रिंग फ़ील्ड में मानों की लंबाई

मैं परीक्षण के बुनियादी नियमों में से एक का पालन करता हूं - मैं सीमा मूल्यों की जांच करता हूं।

कौन से मूल्य बहुत कम हैं। सबसे कम मूल्यों के बीच कबाड़ भरा हुआ है, इसलिए यहां खुदाई करना दिलचस्प है।

 SELECT * FROM <table_name> WHERE LENGTH(<column_name>) < 3; 

इस तरह, मैं नाम, फोन नंबर, टिन, ओकेवीईडी, वेबसाइट पते की जांच करता हूं। बकवास "ए * 1", "0", "11", "-" और "..." जैसे पॉप अप करता है।

क्या अधिकतम मूल्यों के साथ सब कुछ ठीक है। क्लोज फील्ड इस तथ्य का एक मार्कर है कि डेटा ट्रांसफर के दौरान फिट नहीं हुआ, और वे स्वचालित रूप से कट गए। MySQL बिना किसी चेतावनी के इस प्रसिद्ध दरार। इसी समय, ऐसा लगता है कि प्रवास सुचारू रूप से चला गया।

 SELECT * FROM <table_name> WHERE LENGTH(<column_name>) = 65; 

इस तरह, मैंने दस्तावेज़ के प्रकार के साथ फ़ील्ड में पाया "पहचान के लिए आप्रवासी के आवेदन के पंजीकरण का प्रमाण पत्र।" उन्होंने कहा कि इंटीग्रेटर्स, क्षेत्र की लंबाई को सही कर रहे थे।

मान लंबाई के साथ कैसे वितरित किए जाते हैं। HFLabs में, हम पंक्तियों के लिए लंबाई वितरण तालिका कहते हैं।

 SELECT LENGTH(<column_name>), COUNT(<column_name>) FROM <table_name> GROUP BY LENGTH(<column_name>); 

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

क्या जांचना है, संक्षेप में।

1. स्ट्रिंग फ़ील्ड में सबसे छोटा मान। प्रायः तीन वर्णों से कम की रेखाएँ कचरा होती हैं।
2. मान जो फ़ील्ड चौड़ाई की लंबाई के साथ "संक्षिप्त" है। अक्सर उनका खतना किया जाता है।
3. लंबाई के साथ पंक्तियों के वितरण में विसंगतियाँ।

लोकप्रिय मान

मैं तीन श्रेणियों में विभाजित करता हूं जो मूल्य शीर्ष लोकप्रिय में आते हैं:

• वास्तव में आम है , जैसे नाम "तात्याना" या मध्य नाम "व्लादिमीरोविच"। यहां यह याद रखना चाहिए कि सामान्य मामले में, तात्याना अन्ना की तुलना में 100 गुना अधिक लोकप्रिय नहीं होना चाहिए, और इस्माइल शायद ही ईगोर से अधिक लोकप्रिय हो सकता है;
• कचरा , जैसे "।", "1", "-" और जैसा;
• दिनांक के लिए "01/01/1900" के रूप में इनपुट फॉर्म पर डिफ़ॉल्ट ।

तीन मामलों में से दो समस्या के मार्कर हैं, उनके लिए देखना उपयोगी है।

मैं तीन प्रकार के क्षेत्रों में लोकप्रिय मूल्यों की खोज करता हूं:

1. साधारण स्ट्रिंग फ़ील्ड।
2. संदर्भ स्ट्रिंग फ़ील्ड। ये सामान्य स्ट्रिंग क्षेत्र हैं, लेकिन उनमें विभिन्न मूल्यों की संख्या निश्चित रूप से विनियमित है। ये क्षेत्र देशों, शहरों, महीनों, फोन प्रकारों को संग्रहीत करते हैं।
3. क्लासिफायर फ़ील्ड - इनमें तृतीय-पक्ष क्लासिफ़ायर टेबल में प्रविष्टि का लिंक होता है।

मैं इनमें से प्रत्येक प्रकार के क्षेत्रों का थोड़ा अलग तरीके से अध्ययन करता हूं।

स्ट्रिंग फ़ील्ड के लिए - शीर्ष 100 लोकप्रिय मूल्य क्या हैं। यदि आप चाहें, तो आप अधिक ले सकते हैं, लेकिन पहले सौ मूल्यों में सभी विसंगतियों को आमतौर पर रखा जाता है।

 SELECT * FROM (SELECT <column_name>, COUNT(*) cnt FROM <table_name> GROUP BY <column_name> ORDER BY 2 DESC) WHERE ROWNUM <= 100; 

मैं इस तरह से खेतों की जाँच करता हूँ:

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

लगभग हमेशा लोकप्रिय - परीक्षण और डिफ़ॉल्ट मान, कुछ स्टब्स।



ऐसा होता है कि पाई गई समस्या कोई समस्या नहीं है। एक बार मुझे डेटाबेस में एक संदिग्ध लोकप्रिय फोन नंबर मिला। यह पता चला कि ग्राहकों ने इस संख्या को काम करने के रूप में इंगित किया था, और एक ही डेटाबेस में बस बहुत सारे कर्मचारी थे।

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

संदर्भ फ़ील्ड और क्लासिफ़ायर के लिए मैं सभी मानों की लोकप्रियता की जाँच करता हूँ। आरंभ करने के लिए, मैं यह पता लगाता हूं कि कौन से क्षेत्र निर्देशिका हैं। आप स्क्रिप्ट के साथ नहीं जा सकते, मैं दस्तावेज ले जाता हूं और दिखावा करता हूं। आमतौर पर, निर्देशिकाएं मानों के लिए बनाई जाती हैं, जिनमें से संख्या निश्चित रूप से और अपेक्षाकृत छोटी होती है:

• देश
• भाषाओं,
• मुद्रा,
• महीने
• शहर।

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

 SELECT <column_name>, COUNT(*) cnt FROM <table_name> GROUP BY <column_name> ORDER BY 2 DESC; 

आमतौर पर निर्देशिकाओं के स्ट्रिंग-फ़ील्ड में यह निहित होता है।
सामान्य समस्याएं:

• लिखने की त्रुटियों;
• अंतराल;
• अलग मामला।

एक गड़बड़ होने के बाद, मैं हाथ पर उदाहरण के साथ इंटीग्रेटर्स के पास जाता हूं। उन्हें स्रोत में कचरा छोड़ दें, और विसंगतियों को समाप्त करें। फिर कठोरता के लिए लक्ष्य डेटाबेस में संदर्भ लाइनों को क्लासिफायरियर में बदलना संभव होगा।

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

संक्षेप में, क्या जाँचना है।

1. कौन से स्ट्रिंग फ़ील्ड संदर्भ हैं और कौन से नहीं हैं।
2. सरल स्ट्रिंग फ़ील्ड्स के लिए, शीर्ष लोकप्रिय मान। आमतौर पर शीर्ष कचरा और डिफ़ॉल्ट डेटा में।
3. स्ट्रिंग संदर्भ क्षेत्रों के लिए, लोकप्रियता द्वारा सभी मूल्यों का वितरण। चयन संदर्भ मूल्यों में विसंगतियों को दिखाएगा।
4. क्लासिफायर्स के लिए - डेटाबेस में पर्याप्त विकल्प हैं।

संगति और क्रॉस सुलह

तालिकाओं के अंदर डेटा के विश्लेषण से, मैं रिश्तों के विश्लेषण की ओर मुड़ता हूं।

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

 SELECT COUNT(*) FROM ((SELECT <ID1> FROM <table_name_1>) MINUS (SELECT <ID2> FROM <table_name_2>)); 

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

यह विपरीत दिशा में भी काम करता है - मैं उन ग्राहकों की तलाश कर रहा हूं जिनके पास किसी कारण से एक भी अनुबंध, पता, फोन नंबर नहीं है। कभी-कभी यह ठीक है - ठीक है, ग्राहक के पास कोई पता नहीं है। यहां आपको ग्राहक से पता लगाने की आवश्यकता है, प्रलेखन आसानी से धोखा देगा।

क्या अलग-अलग तालिकाओं में प्राथमिक कुंजियों का दोहराव है। कभी-कभी समान इकाइयां विभिन्न तालिकाओं में संग्रहीत होती हैं। उदाहरण के लिए, विषमलैंगिक ग्राहक। (कोई नहीं जानता कि क्यों, क्योंकि ब्रेझनेव ने अभी भी संरचना का दावा किया है।) लेकिन टेबल रिसीवर में एकल है, और जब प्रवास करते हैं, तो ग्राहक पहचानकर्ता संघर्ष करेंगे।

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

यदि समान संस्थाओं के साथ कई टेबल हैं, तो मैं एक क्रॉस-चेक करता हूं: मैं पहचानकर्ताओं के चौराहे की जांच करता हूं। Intersect - एक पैच गोंद। उदाहरण के लिए, हम योजना "स्रोत तालिका + आईडी का नाम" के अनुसार एकल तालिका के लिए पहचानकर्ता एकत्र करते हैं।

संक्षेप में, क्या जाँचना है।

1. लिंक्ड टेबल में कितने असंबंधित डेटा हैं।
2. क्या कोई संभावित प्राथमिक प्रमुख संघर्ष हैं?

जाँच करने के लिए और क्या है

क्या कोई लैटिन वर्ण हैं जहाँ वे नहीं हैं। उदाहरण के लिए, उपनामों में।

 SELECT <column_name> FROM <table_name> WHERE REGEXP_LIKE(<column_name>, '[AZ]', 'i'); 

इसलिए मैं अद्भुत लैटिन पत्र "सी" को पकड़ता हूं, जो सिरिलिक के साथ मेल खाता है। गलती अप्रिय है, क्योंकि लैटिन "सी" नाम के अनुसार ऑपरेटर को कभी भी ग्राहक नहीं मिलेगा।

क्या संख्या के लिए लक्षित स्ट्रिंग क्षेत्रों में कोई विलुप्त वर्ण हैं?

 SELECT <column_name> FROM <table_name> WHERE REGEXP_LIKE(<column_name>, '[^0-9]'); 

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

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

• क्या "सोफ़िया व्लादिमीरोवना" एक क्लाइंट 50,000 फोन है - क्या यह सामान्य है? उत्तर: सामान्य नहीं है। ग्राहक तकनीकी है, वे एसएमएस-मेलिंग करने के लिए उस पर "मालिक रहित" फोन नंबर डालते हैं। क्लाइंट को नए आधार पर खींचने के लिए आवश्यक नहीं है;
• TINs भरे हुए हैं, वास्तव में, कॉलम में "79853617764", "89109462345", "4956780966" और इतने पर हैं। किस तरह के फोन, ओकुडा? सराय कहां है? उत्तर: यह किस प्रकार की संख्या है - यह ज्ञात नहीं है कि इसे किसने लगाया - अस्पष्ट है। कोई भी उनका उपयोग नहीं करता है। वर्तमान टिन को किसी अन्य तालिका के अन्य क्षेत्र में संग्रहीत किया जाता है, वहां से लिया जाता है;
• "एक पंक्ति में पता" फ़ील्ड उन फ़ील्ड्स के अनुरूप नहीं है जिसमें पता भागों में संग्रहीत है। पते अलग क्यों हैं? उत्तर: एक बार ऑपरेटरों ने एक लाइन के साथ पते भरे, और बाहरी सिस्टम ने अलग-अलग क्षेत्रों में पते छांटे। विभाजन के लिए। जैसे-जैसे समय बीतता गया, लोगों ने पते बदले। ऑपरेटरों ने उन्हें नियमित रूप से अपडेट किया, लेकिन केवल एक स्ट्रिंग के रूप में: पता भागों में पुराना रहा।

आपको बस SQL ​​और Excel की आवश्यकता है

डेटा का विश्लेषण करने के लिए, महंगे सॉफ़्टवेयर की आवश्यकता नहीं है। पर्याप्त पुराने एक्सेल और SQL का ज्ञान।

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


_{कॉलम "ए" में मैं खेतों के नाम सम्मिलित करता हूं, मैं उन्हें दस्तावेज या सेवा तालिकाओं में ले जाता हूं। कॉलम "बी" में - अनुरोध को gluing के लिए एक सूत्र}

मैं खेतों के नाम सम्मिलित करता हूं, कॉलम "बी" में पहला सूत्र लिखता हूं, कोने को खींचता हूं - और आप कर रहे हैं।


_{एक्सेल में, और Google डॉक्स में और एक्सेल ऑनलाइन (Yandex.Disk पर उपलब्ध) में काम करता है}

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

संख्या नहीं, बल्कि निष्कर्ष

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

मैं रिपोर्ट के लिए क्या इकट्ठा करता हूं:

• एक परिकल्पना या प्रश्न के रूप में समस्याओं का शब्दांकन: “टिन 0.07% भरा हुआ है। आप इस डेटा का उपयोग कैसे करते हैं, यह कितना प्रासंगिक है, इसकी व्याख्या कैसे करें? क्या एक टेबल में केवल एक INN है? ” आप दोष नहीं दे सकते: "आपका टिन बिलकुल नहीं भरा है।" जवाब में, आप केवल आक्रामकता प्राप्त करेंगे;
• समस्याओं के उदाहरण। ये गोलियाँ हैं जिनमें से लेख में बहुत सारे हैं;
• यह कैसे करें के लिए विकल्प: "यह लक्ष्य बेस से टीआईएन को हटाने के लायक हो सकता है ताकि खाली क्षेत्रों का उत्पादन न हो।"

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

कभी-कभी ग्राहक, समस्या को देखकर जवाब देता है: “चिंता मत करो, ध्यान मत दो। हम मेमोरी की एक अतिरिक्त टेराबाइट खरीदेंगे, बस इतना ही। यह अनुकूलन से सस्ता है। ” आप इसके लिए सहमत नहीं हो सकते हैं: यदि आप एक पंक्ति में सब कुछ लेते हैं, तो रिसीवर में कोई गुणवत्ता नहीं होगी। सभी एक ही कचरा बेमानी डेटा पलायन कर रहे हैं।

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

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

यह सब बुनियादी जांच के साथ है, डेटा का अध्ययन करें!