من أصعب ما يواجه المتخصص في البيانات هو الفهم الصحيح لهندسة البيانات والتعامل مع قواعد البيانات، حيث يعتقد الكثير أنه بمجرد الوصول إلى قواعد البيانات لم يتبقى عليه إلا العمل على تصحيحها والتأكد من سلامتها. بكل أسف، إن عدم توفر المؤهلات للتعامل مع ضوابط العلاقات بين جداول البيانات أو الملفات ذات العلاقات المتعددة يؤدي إلى الوصول إلى بيانات مخادعة، حتى مع الإلمام بالفهم الصحيح لقواعد إجراءات دورة حياة النظام التي تعرف عند المبرمجين بتحليل الأعمال.
لهذا يجب على المتخصص في البيانات الإلمام بقواعد عمل البيانات عن طريق معرفة أسباب جمع البيانات والهدف من النظام، وكذلك فهم الإجراءات الخاصة بمعالجة البيانات التي بالعادة يجمعها ويوثقها محلل الأعمال. وكذلك فهم الهندسة البرمجية لقواعد البيانات التي يقوم مهندس البيانات بحصرها وتحديد قواعدها، حيث تكون الموجه الأساسي لبناء مستودع البيانات، وتظهر الحاجة لها في المشاريع الكبيرة.
كثير من محلل البيانات يعمل على قواعد البيانات أو يجمع البيانات على شكل ملفات أو حتى يعمل على البيانات المتوفرة على شبكة الانترنت دون الإلمام بهندسة البيانات، وفي الحقيقة يصعب عليه أن يجمع بين هندسة البيانات وتحليل البيانات. لكن لابد من معرفة أساسيات هندسة البيانات إذا كان مضطراً للعمل دون توفر مهندس بيانات.
في هذه المقالة سأشرح أكثر من فخ أو خدعة في عالم البيانات التي في الغالب تصادف متخصص البيانات في مرحلة تجهيز البيانات، وهي فقط من أشهرها وليست حصر.
من خلال خبرتي في التعامل مع البيانات، لن يستطيع محلل البيانات أو مهندس البيانات السيطرة على البيانات بدون العمل كفريق واحد. وأكاد أجزم أنه من المستحيل الوصول لنتائج دقيقة إذا لم يكن فريق إدارة البيانات يتكون من محلل ومهندس بيانات مع أعضاء الفريق الآخرين من عالم بيانات ومحلل الاعمال وبقية الفريق البرمجي. ولمزيد من المعلومات عن تكوين فرق إدارة البيانات يمكن مرجعة مقالة هندسة البيانات وإدارة البيانات.
تنويه: ستحقق هذه المقالة فائدة أكبر في حال معرفتك بالعلاقات بين الجداول ولغة SQL، لذا ننصح بمراجعة دروس في قواعد البيانات.
كمراجعة بسيطة، توجد 4 علاقات بين الجداول على النحو التالي:
- علاقة واحد إلى واحد (One to One)، مثل جدول المواطنين وجدول جوازات السفر، فلكل مواطن جواز سفر واحد والعكس.
- علاقة واحد إلى متعدد (One to Many)، مثل جدول الموظفين وجدول الرواتب.
- علاقة متعدد إلى واحد (Many to One)، مثل جدول الموظفين وجدول الإدارات.
- علاقة متعدد إلى متعدد (Many to Many)، مثل جدول البضائع وجدول المبيعات.
فخ الهوة أو الفجوة (Chasm Trap)
تحدث هذه المشكلة مع العلاقة متعدد إلى متعدد (Many to Many)، فعند استخراج مجموع من كلا الطرفين في جملة SQL واحدة تحدث هذه المشكلة ويصبح الجمع خطأ.
مثال:
جدول العملاء (Customers) وجدول المبيعات (Sales) وجدول الطلبات (Orders)
العلاقة بين المبيعات (Sales) والطلبات (Orders) متعدد إلى متعدد (Many to Many) عن طريق جدول العملاء (Customers).
والبيانات على النحو التالي:
جدول العملاء (Customers)
| CustomerID | CustomerName |
| 1 | Fahad |
| 2 | Nasser |
جدول المبيعات (Sales)
| CustomerID | QuantitySold |
| 1 | 5 |
| 1 | 5 |
| 1 | 2 |
| 2 | 2 |
| 2 | 2 |
| 2 | 5 |
| 2 | 5 |
جدول الطلبات (Orders)
| CustomerID | OrderValue |
| 1 | 10 |
| 1 | 10 |
| 1 | 10 |
| 2 | 20 |
| 2 | 20 |
| 2 | 20 |
عند محاولة عرض البيانات في جدول واحد تظهر المشكلة كما هو موضح في هذه الصورة
كما هو موضح، الأرقام الخاطئة في حالة الدمج في المربع الأحمر. وعند فصل البيانات تظهر الأرقام الصحيحة في المربع الأخضر.
هذة الأخطاء واضحة في قاعدة البيانات لكن ما هو الوضع عند عرضها في برامج تصوير البيانات (Data Visualization)؟ وقد تم اختبارها على 2 منها هي Tableau – Power BI وظهرت النتائج التالية:
Tableau
يوجد في Tableau حالتين لجلب البيانات إما Live وهي الربط المباشر مع قاعدة البيانات، أو Extract وهي تحميل البيانات في نفس الملف ولا حاجة للربط المباشر مع قاعدة البيانات. ولقد عرض Tableau البيانات مع الأخطاء في كلتا الحالتين، حتى عند فصل البيانات وليس فقط عند الدمج كما هو في الصورة التالية:
Power BI
استطاع Power BI في كلتا الحالتين باستخدام Direct Query، وهي الربط المباشر مع قاعدة البيانات، و Import، وهي حفظ البيانات في نفس الملف، من عدم الوقوع في Chasm Tarp عند الدمج. ولكن مع ذلك أظهر البيانات الخطأ عند عدم جلب حقل CustomerID من جدول Customers. وأخطأ في كلتا الحالتين في واحد من الأرقام وتعامل مع رغبة المستخدم وكذلك أظهر رسالة خطأ عند إجباره على دمج كل حقول الجداول بحجة أنه لم يستطع التعرف على العلاقة بينها. كما أظهر الأرقام الخطأ عند جلبها عن طريق جملة SQL بشكل مباشر وهي على النحو التالي:
SELECT A.[CustomerID],
SUM(B.OrderValue) SumOrderValue,
SUM(C.QuantitySold) SumQuantitySol
FROM [Chasm Trap].[dbo].[Customers] A
JOIN [Chasm Trap].[dbo].Orders B ON (A.CustomerID=B.CustomerID)
JOIN [Chasm Trap].[dbo].Sales C ON (A.CustomerID=C.CustomerID)
GROUP BY A.CustomerID
فيجب الانتباه أن بعض البرامج فقط تساعد في الحماية من الفخ إلى حد معين، وإذا كنت غير ملم بها فسوف تظهر لك المشكلة.
ربما تجد المثال السابق سهل في كشف الأرقام الخاطئة، خاصة عند استخدام الرسوم البيانية، لكن عندما تكون قاعدة البيانات كبيرة ومتعددة العلاقات يصعب كشفها عن طريق النظر، وخاصة عندما تعرض البيانات في عدد كبير من التقارير (Dashboards).
الاستنتاجات:
- في التجربة السابقة يظهر التقدم التقني في Power BI أكثر من Tableau إلا أن الأخير مازال يتمتع بمميزات أكثر من Power BI، ولم يصل Power BI إلى مرحلة النضج الكامل، ولكن سيصل لها قريباً.
- فخ الهوة أو الفجوة (Chasm Trap) فخ خطير جداً ولا أعتقد أن هناك قاعدة بيانات لا يوجد بها علاقة متعدد إلى متعدد.
- الحماية في أفضل حالتها هي الإلمام بهذا الفخ، وليس الاعتماد على التقنية الحديثة، خاصة في الوقت الراهن.
- الإلمام بقواعد البيانات السطحي دون التعمق فيها ربما يقودك لمثل هذه المشاكل.
- مراعاة الهندسة البرمجية لقواعد البيانات التي أنت بصدد تحليلها أمر أساسي ومهم.
لتنزيل ملف المثال على Power BI من خلال هذا الرابط
ولتحميل برنامج Power BI من خلال هذا الرابط
في المقالة القادمة نستعرض فخ أخر يسمى فخ المروحة (Fan Trap)
