خطأ إدخال واضح — عمر 150 سنة مستحيل. (القيمة الشاذة قد تكون حقيقية مثل مليارير في مجموعة أثرياء). التصرف: (1) إذا يمكن التحقق من المصدر: صحّح القيمة. (2) إذا لا: احذف هذا الحقل تحديدًا أو علّمه كـ ‘غير موثوق’. لا تُحذف السجل بالكامل إذا بقية بياناته صالحة.

15% قد يكون كثيرًا لحذفه. الخيارات: (1) الاستيفاء (Imputation): إذا كانت البيانات كمية — استخدام الوسيط أو المتوسط. إذا نوعية — استخدام أكثر قيمة شيوعًا أو قيمة ‘محايد’. (2) الحذف: إذا كانت المفقودة عشوائية ولا ترتبط بنمط (مثلًا: فئة معينة لا تُجيب — تحيز، لا تحذف). (3) إنشاء فئة جديدة ‘غير محدد’. قبل القرار: تحليل ما إذا كانت المفقودة عشوائية أم منهجية.

المشكلة: أي تجميع أو استعلام بالمدينة سيُعطي نتائج مجزأة — تبدو أربع مدن مختلفة. المعالجة: (1) تحديد القيمة القياسية (مثل ‘القاهرة’ بالعربية). (2) تطبيق دالة تحويل لتوحيد كل الصيغ للقياسية. (3) تطبيع الحروف (lowercase، إزالة مسافات زائدة). (4) إضافة قاموس تعيين (Mapping Dictionary) للقيم الشائعة.

Normalization: يُحوّل القيم لنطاق [0, 1] بطرح الحد الأدنى وقسمة المدى. مناسب حين تعرف الحدود مسبقًا وتوزيع البيانات غير طبيعي. Standardization: يُحوّل للمتوسط 0 وانحراف معياري 1. مناسب حين البيانات تتبع توزيعًا طبيعيًا وتحتاج مقارنة بين متغيرات مختلفة. الاستخدام: خوارزميات تعلم الآلة المعتمدة على المسافة (KNN) تحتاج أحدهما.

المخاطر: (1) فقدان 70% من البيانات — عينة أصغر تُقلل الثقة في النتائج. (2) إذا كانت المفقودة ليست عشوائية (مثلًا: العملاء الغاضبون لا يُجيبون عن رضاهم) — الحذف يُحيز العينة نحو العملاء الراضين فقط. الحذف مقبول فقط إذا القيم المفقودة عشوائية تمامًا (MCAR) وتمثّل نسبة صغيرة (<5%).

المسؤولية مشتركة: من يُدخل البيانات (الموظف الإداري) مسؤول عن دقة الإدخال. من يُصمم النظام مسؤول عن قواعد التحقق. محلل البيانات مسؤول عن اكتشاف المشكلات ورفعها. الإدارة مسؤولة عن سياسات حوكمة البيانات. المسؤول الأول رسميًا: حارس البيانات (Data Steward) أو مدير البيانات الرئيسي (CDO). لكن عمليًا: الجودة تبدأ عند نقطة الإدخال.

التحويل: تغيير شكل أو نوع البيانات لتناسب الغرض. الأسباب: (1) تطبيع المقاييس (كما سبق). (2) تحويل متغير مستمر لفئوي (‘العمر’ → ‘شباب/متوسط/كبير’). (3) Encoding — تحويل النوع (ذكر/أنثى) لـ (0/1) للخوارزميات التي تقبل أرقامًا فقط. (4) Log Transformation — للبيانات ذات التوزيع المنحرف جدًا لتقريبه من الطبيعي.

ETL: استخراج البيانات من مصادر متعددة (Extract)، تنقيتها وتحويلها للصيغة الموحدة (Transform)، تحميلها لمستودع البيانات أو قاعدة البيانات المستهدفة (Load). السياقات: دمج بيانات من أنظمة مختلفة (CRM + ERP + موقع الويب) في مستودع بيانات مركزي (Data Warehouse) للتحليل الشامل. كل ليلة يُنفَّذ ETL لتحديث التقارير الإدارية.

لا يحذفها مباشرةً — يُحقق أولًا. الخطوات: (1) التحقق من المصدر — هل هناك صفقة كبيرة استثنائية أو خطأ تقني؟ (2) لو صفقة حقيقية (مناقصة حكومية مثلًا): تُبقيها لكن تُعلّمها كحدث استثنائي. (3) عند حساب المتوسط: يُحسب الوسيط بدلًا من المتوسط لأن الوسيط أقل تأثرًا بالقيم الشاذة. (4) لو خطأ: تُصحح أو تحذف مع توثيق.

Data Pipeline: تسلسل آلي من العمليات تُطبَّق على البيانات من الجمع للتحليل — Extract → Clean → Transform → Store → Analyze. الفرق عن اليدوي: (1) يُنفَّذ تلقائيًا بجدول منتظم. (2) قابل للتكرار بنفس الإجراءات بدون خطأ بشري. (3) يُوثَّق كل خطوة تلقائيًا. (4) يُعالج أحجام أكبر. (5) أسرع. الأداة: Apache Airflow, dbt, AWS Glue.

مشكلة ‘تحديد الكيانات’ (Entity Resolution). الحل: (1) تحديد حقول مميزة للمقارنة (الاسم + تاريخ الميلاد + رقم الهاتف). (2) المطابقة الدقيقة (Exact Match) — نفس الهاتف = نفس الشخص. (3) المطابقة التقريبية (Fuzzy Matching) — ‘أحمد محمد’ و’احمد محمد’ نفس الشخص. (4) قاعدة قرار: في حالة التعارض أي قاعدة بيانات مصدر الحقيقة؟ (5) دمج السجلين في سجل موحد بمعرف جديد.

التحقق بعد التحويل: التأكد أن عملية التنقية والتحويل لم تُدخل أخطاء جديدة. الاختبارات: (1) العدد: هل عدد السجلات معقول (لا حذف مفرط)؟ (2) المدى: هل القيم ضمن النطاق المتوقع بعد التطبيع؟ (3) التوزيع: هل التوزيع الإحصائي منطقي مقارنةً بالأصلي؟ (4) القيم الفريدة: هل المفاتيح فريدة؟ (5) العلاقات: هل العلاقات بين الجداول سليمة؟