ترحيل البيانات في المؤسسة الدامية: ما الذي يجب تحليله ، حتى لا تطغى على المشروع

يبدو مشروع تكامل النظام النموذجي بالنسبة لنا كما يلي: لدى العميل مجموعة من أنظمة حسابات العملاء ، وتتمثل المهمة في جمع بطاقات العملاء في قاعدة بيانات واحدة. وليس فقط لجمع ، ولكن أيضا للتخلص من التكرارات والقمامة. للحصول على بطاقات عملاء نظيفة ومنظمة وكاملة.

بالنسبة للمبتدئين ، سأشرح أن عملية الترحيل تتم وفقًا لهذا المخطط: المصادر ← تحويل البيانات ( ETL أو إجابات الناقل ) ← جهاز الاستقبال .

في مشروع واحد ، خسرنا ثلاثة أشهر لمجرد أن فريقًا من الجهات الخارجية من الجهات المتكاملة لم يدرس البيانات في أنظمة المصدر. الشيء الأكثر إزعاجًا هو أنه كان يمكن تجنب ذلك.

عملوا على هذا النحو:

1. يقوم تكامل النظام بتخصيص عملية ETL.
2. تقوم ETL بتحويل بيانات المصدر وتعطيها لي.
3. أنا أدرس التفريغ وأرسل الأخطاء إلى المندمجين.
4. يصحح المندمجون ETLs ويبدأون الترحيل مرة أخرى.

في المقالة ، سأعرض كيفية تحليل البيانات أثناء تكامل النظام. درست تحميلات ETL ، كانت مفيدة للغاية. ولكن على البيانات المصدر ، فإن نفس التقنيات من شأنها تسريع العمل مرتين.

سوف تكون النصائح مفيدة للمختبرين ومنفذي منتجات المؤسسات ومتكامل الأنظمة والمحللين. تعتبر الاستقبالات عالمية لقواعد البيانات العلائقية ، ويتم الكشف عنها بالكامل في مجلدات من مليون عميل.

لكن أولاً ، حول واحدة من الأساطير الرئيسية لتكامل النظام.

التوثيق والمعماري سيساعدان (في الواقع ليس كذلك)

لا يقوم المندمجون غالبًا بدراسة البيانات قبل الترحيل - فهم يوفرون الوقت. يقرأون الوثائق ، وينظرون إلى الهيكل ، ويتحدثون مع المهندس المعماري - وهذا يكفي. بعد ذلك ، يخططون بالفعل للتكامل.

اتضح سيئة. سيظهر التحليل فقط ما يجري حقًا في قاعدة البيانات. إذا لم تدخل في البيانات بأكمام مدببة وعدسة مكبرة ، فسيكون الترحيل خاطئًا.

الوثائق تكذب. يعمل نظام المؤسسة النموذجي من 5 إلى 20 سنة. كل هذه السنوات ، تم توثيق التغييرات في ذلك من قبل مختلف الإدارات والمقاولين. لكل منها برج الجرس الخاص بها. لذلك ، لا يوجد أي تكامل في الوثائق ، ولا أحد يفهم تمامًا منطق تخزين البيانات وهيكلها. ناهيك عن أن المواعيد النهائية موجودة دائمًا ولا يوجد ما يكفي من الوقت للتوثيق.

قصة شائعة: في جدول العملاء يوجد حقل "SNILS" ، على الورق من المهم جدًا. ولكن عندما أنظر إلى البيانات ، أرى - الحقل فارغًا. ونتيجة لذلك ، يوافق العميل على أن القاعدة المستهدفة ستستغني عن حقل لـ SNILS ، نظرًا لعدم وجود بيانات حتى الآن.

حالة خاصة من التوثيق هي اللوائح وأوصاف العمليات التجارية: كيف تدخل البيانات إلى قاعدة البيانات ، وتحت أي ظروف ، وبأي تنسيق. كل هذا لن يساعد أيضا.

عمليات الأعمال مثالية فقط على الورق. في الصباح الباكر ، يأتي المشغل النائم أناتولي إلى مكتب البنك في ضواحي فيكسا. تحت النافذة صرخوا طوال الليل ، وفي الصباح تشاجرت أناتولي مع الفتاة. يكره العالم كله.

لم يتم ترتيب الأعصاب بعد ، ويقوم Anatoly بتحريك اسم العميل الجديد بالكامل في حقل الاسم الأخير. نسي تمامًا عيد ميلاده - يبقى الرقم الافتراضي "01.01.1900 g" في النموذج. أنا لا أهتم بالقواعد عندما يكون كل شيء غاضبًا جدًا !!!

تنتصر الفوضى على العمليات التجارية ، وتتناسب جيدًا مع الورق.

مهندس النظام لا يعرف كل شيء. يتعلق الأمر مرة أخرى بعمر موقر لأنظمة المؤسسة. على مر السنين التي يعملون فيها ، تغير المهندسون المعماريون. حتى إذا كنت تتحدث مع التيار ، فإن قرارات القرارات السابقة ستظهر كمفاجآت خلال المشروع.

وكن متأكدا: حتى المهندس المعماري اللطيف من جميع النواحي سيبقي fakapy وعكازات النظام سرا.

التكامل "بالأدوات" بدون تحليل البيانات هو خطأ. سأوضح كيف نتعلم في HFLabs البيانات من خلال تكامل النظام. في المشروع الأخير ، قمت فقط بتحليل تحميلات ETL. ولكن عندما يمنح العميل الوصول إلى بيانات المصدر ، أتحقق من ذلك بالتأكيد وفقًا لنفس المبادئ.

الحقول المعبأة والقيم الخالية

تكون أبسط عمليات الفحص على اكتمال الجداول ككل وعلى اكتمال الحقول الفردية. أنا أبدأ معهم.

كم عدد الصفوف الموجودة في الجدول. أبسط طلب ممكن.

SELECT COUNT(*) FROM <table_name>; 

أحصل على النتيجة الأولى.
هنا ألقي نظرة على كفاية البيانات. إذا وصل مليوني عميل إلى التفريغ من أجل بنك كبير ، فمن الواضح أن هناك خطأ ما. ولكن بينما يبدو كل شيء كما هو متوقع ، المضي قدما.

عدد الأسطر المملوءة لكل حقل على حدة. أتحقق من جميع أعمدة الجدول.

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

جاء الأول عبر حقل عيد ميلاد سعيد ، وكان فضوليًا على الفور: لسبب ما ، لم تأت البيانات على الإطلاق.
إذا كانت جميع القيم في الحقل "فارغة" في التحميل ، فإن أول شيء أنظر إليه هو نظام المصدر. ربما يتم تخزين البيانات هناك بشكل صحيح ، ولكن تم فقدها أثناء الترحيل.

أرى أنه في نظام المصدر تكون أعياد الميلاد في مكانها الصحيح. أذهب إلى التكامل: الرجال ، خطأ. اتضح أنه في عملية ETL ، عملت وظيفة فك التشفير بشكل غير صحيح. تم إصلاح الرمز ، في التحميل التالي سنتحقق من التغييرات.

أذهب إلى الميدان مع رقم التعريف الضريبي.
يوجد 100 مليون شخص في قاعدة البيانات ، و 65 ألفًا فقط مملوءين بأرقام التعريف الشخصية - وهذا يمثل 0.07٪. ويشكل هذا الانشغال الضعيف إشارة إلى أن المجال في قاعدة المستقبل قد لا يكون ضروريًا على الإطلاق.

أتحقق من نظام المصدر ، كل شيء صحيح: أرقام التعريف الضريبية مشابهة لتلك الفعلية ، ولكن لا يوجد أي منها تقريبًا. لذلك ، لا يتعلق الأمر بالهجرة. يبقى لمعرفة ما إذا كان العميل يحتاج إلى حقل فارغ تقريبًا تحت رقم التعريف الضريبي في قاعدة البيانات المستهدفة.

وصلت إلى علم إزالة العميل.
الأعلام فارغة. ولكن ماذا ، الشركة لا تزيل العملاء؟ أنا أنظر إلى نظام المصدر ، والتحدث مع العميل. اتضح أن نعم: العلم رسمي ، بدلاً من حذف العملاء ، يتم حذف حساباتهم. لا حسابات - كما لو تم حذف العميل.

في النظام المستهدف ، يلزم وجود إشارة العميل البعيد ، وهذه إحدى ميزات البنية. لذا ، إذا كان العميل ليس لديه حسابات صفرية في نظام الاستقبال ، فيجب إغلاقه من خلال منطق إضافي أو عدم استيراده على الإطلاق. ثم كيف يقرر العميل.

التالي هو لوحة العنوان. عادة ما يكون هناك خطأ في هذه الجداول ، لأن العناوين شيء معقد ، يتم إدخالها بطرق مختلفة.

أتحقق من اكتمال مكونات العنوان.
لم يتم ملء العناوين بشكل موحد ، ولكن من السابق لأوانه استخلاص الاستنتاجات: أولاً سأطلب من العميل ما الغرض منها. إذا كان التقسيم حسب البلد ، كل شيء على ما يرام: هناك بيانات كافية. إذا كانت القوائم البريدية ، فإن المشكلة هي: المنازل فارغة تقريبًا ، ولا توجد شقق.

ونتيجة لذلك ، رأى العميل أن ETL كانت تأخذ عناوين من جهاز لوحي قديم وغير ذي صلة. إنها في القاعدة مثل النصب التذكاري. ولكن هناك جدول آخر ، جديد وجيد ، يجب أخذ البيانات منه.

أثناء التحليل ، أقوم بملء الحقول التي تربط الدلائل بخصوصية. لا يعمل الشرط "IS NOT NULL" معهم: بدلاً من "NULL" ، تكون الخلية عادةً "0". لذلك ، تحقق من الحقول المرجعية بشكل منفصل.

تغييرات في ملء الحقول. لذا ، راجعت الإشغال والإشغال الكلي لكل حقل. تم العثور على مشاكل ، وأصل المندمجون عملية ETL وبدأوا الترحيل مرة أخرى.

أجري عملية التفريغ الثانية لجميع الخطوات المذكورة أعلاه. أكتب إحصائيات إلى نفس الملف لرؤية التغييرات.

اكتمال جميع المجالات.
بين التحميلات ، اختفى 5 ملايين سجل. أذهب إلى الإدماج ، أطرح أسئلة نموذجية:

• "لماذا فقدت السجلات؟" ؛
• "ما هي البيانات التي تم حجبها؟" ؛
• "ما البيانات التي تركتها؟"

اتضح أنه لا توجد مشكلة: لقد أزالوا ببساطة العملاء "التقنيين" من التفريغ الجديد. إنهم في قاعدة البيانات للاختبارات ، إنهم ليسوا أناسًا أحياء. ولكن مع نفس الاحتمال ، قد يتم فقدان البيانات عن طريق الخطأ ، يحدث هذا.

لكن أعياد الميلاد في التفريغ الجديد ظهرت ، كما توقعت.
لكن! ليس بالضرورة جيدًا عندما ظهرت البيانات المفقودة سابقًا فجأة في تحميل جديد. على سبيل المثال ، يمكن ملء أعياد الميلاد بتواريخ افتراضية - لا يوجد شيء نفرح به. لذلك ، أتحقق دائمًا من البيانات التي جاءت.

ما يجب التحقق منه باختصار.

1. إجمالي عدد الإدخالات في الجداول. هل هذه الكمية كافية للتوقعات؟
2. عدد الأسطر المعبأة في كل حقل.
3. نسبة عدد الصفوف المعبأة في كل حقل إلى عدد الصفوف في الجدول. إذا كان صغيرًا جدًا ، فهذه مناسبة للتفكير في سحب الحقل إلى القاعدة المستهدفة.

كرر الخطوات الثلاث الأولى لكل تحميل. اتبع الديناميكيات: أين ولماذا زادت أو انخفضت.

طول القيم في حقول السلسلة

أتبع إحدى القواعد الأساسية للاختبار - أتحقق من قيم الحدود.

ما هي القيم القصيرة للغاية. من بين أقصر القيم مليئة بالخردة ، لذا من المثير للاهتمام الحفر هنا.

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

بهذه الطريقة ، أتحقق من الاسم ورقم الهاتف ورقم التعريف الضريبي و OKVED وعناوين مواقع الويب. ينبثق الهراء مثل "A * 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. الشذوذ في توزيع الصفوف على طول الطول.

القيم الشعبية

أقسم إلى ثلاث فئات القيم التي تقع في أعلى الشعبية:

• شائع حقًا ، مثل اسم "Tatyana" أو الاسم الأوسط "Vladimirovich". هنا يجب أن نتذكر أنه في الحالة العامة ، يجب ألا تكون Tatyana أكثر شعبية 100 مرة من Anna ، وبالكاد يمكن أن يكون اسماعيل أكثر شعبية من Egor ؛
• القمامة ، مثل "." ، "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 مليون رقم معلقة ببساطة في الهواء.

كما أنها تعمل في الاتجاه المعاكس - أبحث عن عملاء ليس لديهم لسبب واحد عقد أو عنوان أو رقم هاتف. في بعض الأحيان يكون هذا طبيعيًا - حسنًا ، ليس لدى العميل عنوان ، فما الخطأ. هنا تحتاج إلى معرفة ذلك من العميل ، ستخدع الوثائق بسهولة.

هل هناك مضاعفات للمفاتيح الأساسية في جداول مختلفة. في بعض الأحيان يتم تخزين الكيانات المتطابقة في جداول مختلفة. على سبيل المثال ، العملاء من جنسين مختلفين. (لا أحد يعرف السبب ، لأن بريجنيف لا يزال يطالب بالبنية). لكن الجدول واحد في جهاز الاستقبال ، وعند التعارض ، تتعارض معرفات العميل.

أنتقل على رأسي وألقي نظرة على هيكل القاعدة: حيث يمكن تجزئة الكيانات المماثلة. يمكن أن تكون جداول للعملاء ، والهواتف للاتصال ، وجوازات السفر ، وهلم جرا.

إذا كانت هناك عدة جداول ذات كيانات متشابهة ، أقوم بإجراء فحص مشترك: أتحقق من تقاطع المعرفات. تقاطع - غراء لصقة. على سبيل المثال ، نقوم بجمع معرفات لجدول واحد وفقًا لمخطط "اسم الجدول المصدر + المعرف".

ما يجب التحقق منه باختصار.

1. عدد البيانات غير ذات الصلة في الجداول المرتبطة.
2. هل هناك أي تعارضات رئيسية محتملة؟

ماذا للتحقق

هل هناك أي أحرف لاتينية لا ينتمون إليها. على سبيل المثال ، في الألقاب.

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

لذا التقطت الحرف اللاتيني الرائع "C" ، الذي يتزامن مع السيريلية. الخطأ غير سار ، لأنه وفقًا للاسم بالحرف اللاتيني "C" لن يعثر المشغل على عميل.

هل هناك أي أحرف غريبة في حقول السلسلة مخصصة للأرقام؟

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

تظهر المشاكل في الحقول برقم جواز السفر للاتحاد الروسي أو رقم التعريف الضريبي. الهواتف هي نفسها ، ولكني أسمح بوجود الأقواس والواصلات. سيكشف الطلب أيضًا عن الحرف "O" ، الذي تم تعيينه بدلاً من الصفر.

ما مدى كفاية البيانات. أنت لا تعرف أبدًا أين ستظهر المشكلة ، لذلك أنا دائمًا على أهبة الاستعداد. قابلت مثل هذه الحالات:

• هل "صوفيا فلاديميروفنا" عميل 50،000 هاتف - هل هذا طبيعي؟ الجواب: ليس طبيعيا. العميل تقني ، وضعوا عليه أرقام هواتف "بدون مالك" للقيام بالرسائل النصية القصيرة. ليس من الضروري سحب العميل إلى قاعدة جديدة ؛
• يتم تعبئة أرقام التعريف الضريبية ، في الواقع ، يحتوي العمود على "79853617764" و "89109462345" و "4956780966" وما إلى ذلك. أي نوع من الهواتف ، أوكودا؟ أين النزل؟ الجواب: أي نوع من الأرقام - من غير المعروف من وضعها - غير واضح. لا أحد يستخدمهم. يتم تخزين رقم التعريف الضريبي الحالي في حقل آخر من جدول آخر ، مأخوذ من هناك ؛
• لا يتوافق حقل "العنوان في سطر واحد" مع الحقول التي يتم تخزين العنوان فيها في أجزاء. لماذا تختلف العناوين؟ الإجابة: بمجرد أن يقوم المشغلون بملء العناوين بخط واحد ، يقوم النظام الخارجي بفرز العناوين إلى حقول منفصلة. للتجزئة. مع مرور الوقت ، قام الناس بتغيير العناوين. قام العاملون بتحديثها بانتظام ، ولكن كسلسلة فقط: ظل العنوان قديمًا في أجزاء.

كل ما تحتاجه هو SQL و Excel

لتحليل البيانات ، ليست هناك حاجة إلى برامج باهظة الثمن. يكفي Excel القديم جيد ومعرفة SQL.

Excel أستخدمه لتجميع استعلام طويل. على سبيل المثال ، أتحقق من الحقول للتأكد من اكتمالها ، وهناك 140 في الجدول. سأكتب بيدي قبل مؤامرة الجزرة ، لذلك أقوم بتجميع الطلب باستخدام الصيغ في لوحة excel.


_{في العمود "أ" ، أدرج أسماء الحقول ، وأخذها في جداول التوثيق أو الخدمة. في العمود "B" - صيغة لإلصاق طلب}

أقوم بإدخال أسماء الحقول ، وأكتب الصيغة الأولى في العمود "B" ، وسحب الزاوية - وبذلك تكون قد انتهيت.


_{يعمل في Excel و Google Docs وفي Excel Online (متوفر على Yandex.Disk)}

يحفظ تحليل البيانات سيارة الوقت ويوفر أعصاب المديرين. مع أنه من السهل الوفاء بالموعد النهائي. إذا كان المشروع كبيرًا ، ستوفر التحليلات ملايين الروبل وسمعة.

لا أرقام ، بل استنتاجات

صاغت قاعدة لنفسها: عدم إظهار الأرقام المكشوفة للعميل ، لن تحصل على التأثير بعد. مهمتي هي تحليل البيانات واستخلاص النتائج ، وإرفاق الأرقام كدليل. الاستنتاجات هي الأولية ، والأرقام ثانوية.

ما أقوم بجمعه للتقرير:

• صياغة المشاكل على شكل فرضية أو سؤال : “يتم تعبئة رقم التعريف الضريبي بنسبة 0.07٪. كيف يمكنك استخدام هذه البيانات ، ما مدى ارتباطها ، وكيفية تفسيرها؟ هل يوجد INN واحد فقط في جدول واحد؟ " لا يمكنك إلقاء اللوم: "رقم TIN الخاص بك غير ممتلئ على الإطلاق." رداً على ذلك ، ستتلقى العدوان فقط ؛
• أمثلة من المشاكل. هذه هي الأجهزة اللوحية التي يوجد الكثير منها في المقالة ؛
• خيارات لكيفية القيام بذلك: "قد يكون من المفيد إزالة TIN من القاعدة الهدف حتى لا تنتج حقول فارغة."

ليس لديّ الحق في تحديد ما يجب اختياره بالضبط من قاعدة البيانات المصدر وكيفية تغيير البيانات أثناء الترحيل. لذلك ، مع التقرير ، أذهب إلى العميل أو إلى الشركة المتكاملة ، ونكتشف كيفية المضي قدمًا.

في بعض الأحيان ، يجيب العميل ، عند رؤية المشكلة ،: "لا تقلق ، لا تنتبه. سنشتري تيرابايت إضافي من الذاكرة ، هذا كل شيء. إنها أرخص من التحسين ". لا يمكنك الموافقة على هذا: إذا كنت تأخذ كل شيء على التوالي ، فلن تكون هناك جودة في جهاز الاستقبال. يتم ترحيل كل البيانات الزائدة عن الحاجة.

لذلك ، نسأل بلطف ولكن بثبات: "أخبرنا كيف ستستخدم هذه البيانات المحددة في النظام المستهدف." ليس "لماذا تحتاج" ، أي "كيف ستستخدم". الأجوبة "ثم سنأتي" أو "فقط في حالة" ليست مناسبة. عاجلاً أم آجلاً ، يفهم العميل البيانات التي يمكن الاستغناء عنها.

الشيء الرئيسي هو إيجاد وحل جميع القضايا حتى يتم إطلاق النظام في همز. لتغيير الهندسة المعمارية ونموذج البيانات على قيد الحياة ، سوف تفقد عقلك.

هذا كل شيء مع الفحوصات الأساسية ، ودراسة البيانات!