دليل التنقيب عن البيانات الصديقة للميزانية

على عكس برمجة التطبيقات التقليدية ، حيث تتغير وظائف API كل يوم ، تظل برمجة قاعدة البيانات كما هي. تم إصدار الإصدار الأول من Microsoft Visual Studio .NET في فبراير 2002 ، مع إصدار إصدار جديد كل عامين تقريبًا ، لا يشمل إصدارات Service Pack. تجبر هذه الوتيرة السريعة للتغيير موظفي تكنولوجيا المعلومات على تقييم تطبيقات شركاتهم كل عامين ، تاركين وظائف تطبيقاتهم سليمة ولكن مع رمز مصدر مختلف تمامًا من أجل مواكبة أحدث التقنيات والتقنيات.

لا يمكن قول الشيء نفسه عن شفرة مصدر قاعدة البيانات الخاصة بك. لا يزال الاستعلام القياسي لـ SELECT / FROM / WHERE / GROUP BY ، الذي تمت كتابته في الأيام الأولى لـ SQL ، يعمل حتى اليوم. بالطبع ، هذا لا يعني أنه لم يكن هناك أي تقدم في برمجة قواعد البيانات العلائقية ؛ كانت هناك ، وكانت منطقية أكثر من كونها تقنية .

بدءًا من الأيام التي نشر فيها Bill Inmon و Ralph Kimball نظرياتهما حول تصميم مستودع البيانات ، ركزت التطورات في برمجة قواعد البيانات على منع فقدان المعلومات القيمة واستخراج جميع المعلومات القيمة من البيانات. بمجرد تقديم Inmon و Kimball لعالم قاعدة البيانات إلى تخزين البيانات ، تم إجراء تغييرات كبيرة على أدوات ETL (استخراج / تحويل / تحميل) والتي منحت مطوري قواعد البيانات وصولاً سهلاً إلى البيانات الوصفية والبيانات من مصادر قواعد البيانات غير العلائقية ، والتي كان من الصعب العمل معها في الماضي. أدى هذا إلى زيادة كمية البيانات المتاحة التي يمكن من خلالها استخراج معلومات قيمة ، وأدت هذه الزيادة في البيانات المتاحة إلى حدوث تقدم في معالجة البيانات من خلال مكعبات OLAP وخوارزميات استخراج البيانات.

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

ومع ذلك ، قبل البدء في إضافة أدوات وتقنيات جديدة ، يجب التأكد من إنشاء قاعدة بيانات المعاملات بشكل صحيح.

قاعدة بيانات المعاملات

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

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

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

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

يوجد أدناه مثال على استعلام يستخدم تنسيقًا يمكن قراءته.

 SELECT c.customer_id, c.name, SUM (po.purchase_amount) total_purchase_amount FROM customer c JOIN purchase_orders po ON c.customer_id = po.customer_id GROUP BY c.customer_id, c.name

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

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

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

ETL (استخراج تحميل التحويل) وإعداد التقارير

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

أسهل طريقة لتحديد حاجة الشركة لعمليات ETL أو التقارير الآلية هي معرفة من يقرأ البيانات من قاعدة بيانات المعاملات ثم معالجة البيانات باستخدام جدول بيانات. جدول البيانات هو نفس بنية جدول قاعدة البيانات. كلاهما يحتوي على صفوف وأعمدة. إذا كان لديك مستخدمون يتلاعبون بالبيانات بأنفسهم ، يجب أن تسأل نفسك ، "لماذا لا يمكن أن تكون هذه العملية مؤتمتة؟"

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

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

يجب أن يوفر نظام ETL المبني جيدًا أيضًا القدرة على إرجاع جميع البيانات التي تم تحميلها في قاعدة بيانات المعاملات إلى ملف المصدر الأصلي. هذا جزء مهم من بنية قاعدة البيانات. إذا كنت لا تعرف التاريخ / الوقت الدقيق الذي تم فيه إضافة كل سجل ، إلى جانب اسم المصدر (اسم المستخدم أو اسم الملف) الذي أضاف السجلات ، فأنت لست مستعدًا للتعامل مع البيانات السيئة التي تم تحميلها في قاعدة بيانات المعاملات الخاصة بك. يجب أن تسأل نفسك ، "ماذا لو أرسل لنا أحدهم ملفًا سيئًا؟" كم من الوقت سيستغرق تحديد السجلات التي جاءت منه؟

مستودع البيانات

هناك نوعان من النظريات لتصميم مستودع البيانات. يمكن تلخيص الفرق بين نظريتي Inmon و Kimball على النحو التالي:

تقوم نظرية Inmon أولاً بتطوير مستودع بيانات ثم بناء مجموعات بيانات ذات أبعاد للإبلاغ من مستودع البيانات. تقوم نظرية Kimball أولاً بتطوير مجموعات بيانات الأبعاد للإبلاغ ثم دمجها معًا لإنشاء مستودع البيانات.

تريد دائمًا تزويد العملاء بأسرع عائد على الاستثمار. بناء مجموعات البيانات عملية بسيطة. تبدأ بأخذ الاستعلامات خلف تقاريرك وتغييرها من إرجاع مجموعات النتائج إلى تخزين مجموعات النتائج في جداول دائمة. يمكنك ببساطة إضافة اسم TRUNCATE TABLE ؛ INSERT INTO tablename قبل الكلمة الأساسية SELECT الأصلية. بمجرد أن يكون لديك عدد قليل من جداول البيانات الوظيفية ، يجب تحديد فرص دمج مجموعات البيانات ؛ ابحث عن استعلامات التقرير التي تستخدم نفس قائمة الجداول ثم ادمج قائمة الحقول. يتطلب هذا استعلامًا أكثر تعقيدًا ، خاصةً عند زيادة قائمة الجداول. ومع ذلك ، طالما أنك تختبر الاستعلام بدقة ، يمكن إجراء كل تغيير تزايدي دون تعطيل عمليات الأعمال العادية.

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

OLAP Cube

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

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

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

كما ذكرنا سابقًا ، قد يكون إنشاء مكعب OLAP أمرًا صعبًا. إنها سياسة جيدة للنظر في مكعب OLAP مختلط. يوفر PowerPivot من Microsoft Excel أدوات سهلة الاستخدام لاستخراج البيانات دون تعقيد مكعب OLAP الكامل. العيب الرئيسي للهجين هو أنه لا يمتلك نفس وقت الاستجابة. ومع ذلك ، هناك ميزة كبيرة تتمثل في أنه من الأسهل إنشاء تقارير استخراج البيانات باستخدام Excel مقارنة باستخدام MDX. عند التنقيب في البيانات ، هناك ثلاثة تقارير مفيدة. يمكننا إلقاء نظرة على بعض الأمثلة من العالم الحقيقي وكيفية تفسيرها.

كل هذه التقارير من تطبيق التداول اليومي الآلي الذي أنشأه المؤلف.

التقارير المرئية

تقرير مخطط مبعثر

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

تقرير الصندوق والشعيرات

يلخص هذا التقرير قيمتي x و y من تقرير مخطط التبعثر. يتم تحديد قيم المحور س في مجموعة من المجموعات.

تمثل نهايات كل خط طولي (خط) القيم المتطرفة. يمثل الشريطان الأصفر والأزرق الفاتح نطاقي الانحراف المعياري العلوي والسفلي.

نموذج الانحدار الخطي

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

خاتمة

مع نمو شركتك ، عادةً ما تنمو قاعدة بياناتك أيضًا.

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

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