فحوص جودة البيانات

يعرض كريم نتائج 2025 على مجلس الإدارة الأسبوع القادم. طلبه قصير وجادّ: «قبل أن توضع هذه الأرقام على شريحة، ما مدى ثقتنا بالبيانات؟». كل query كتبته حتى الآن يفترض أن البيانات تعني ما تقوله الوثائق. يدور هذا الدرس حول فحص هذا الافتراض بشكل منهجي، حتى تستند عبارة «أنا واثق» إلى queries لا إلى مشاعر.

الفحص query يعيد الصفوف السيئة

أنفع عادة في جودة البيانات أن تصوغ كل قاعدة كـ query يعيد الصفوف التي تخالفها. النتيجة الفارغة تعني أن القاعدة صامدة؛ وأي شيء آخر دليل يمكنك أن تُطلع عليه أحدًا. هذه القاعدة «المنتج يقع في فئة فرعية، وليس مباشرةً في فئة من المستوى الأعلى»، من وثائق البيانات:

SELECT p.product_id, p.name, c.name AS category
FROM products AS p
JOIN categories AS c ON c.category_id = p.category_id
WHERE c.parent_id IS NULL;

صفّان: Picnic Blanket مصنّف مباشرةً تحت Outdoor، وBamboo Cutting Board تحت Kitchen. وهذا يفسّر صفّي “Kitchen” و"Outdoor" الغريبين في جدول إيراد الفئات من القسم 2. الفحص الذي يعيد صفوفًا يمكنك تسميتها أقنع بكثير من مجرد عدد.

العائلات الخمس للفحوص

تقع معظم القواعد في خمس عائلات. تشغيل فحص واحد على الأقل من كل عائلة يلتقط الغالبية العظمى من المشكلات:

قيود قاعدة البيانات (PRIMARY KEY وNOT NULL وCHECK وFOREIGN KEY) تفرض بعض هذه القواعد عند الكتابة، إن كانت قد عُرّفت، وفي حالة SQLite إن كان فرض المفاتيح الأجنبية مفعّلًا. نادرًا ما يتحكّم المحلّلون في ذلك، وقواعد الاتساق بين الجداول لا يمكن عادةً التعبير عنها كقيود أصلًا. لذا تفحص بنفسك.

مجموعة فحوص يمكنك إعادة تشغيلها

الفحص الواحد query؛ ودزينة فحوص مجموعة. أعطِ كل فحص اسمًا، واعدد إخفاقاته، وكدّسها بـ UNION ALL:

SELECT 'customers: duplicate email (any case)' AS check_name, COUNT(*) AS failures
FROM (SELECT LOWER(email) FROM customers GROUP BY LOWER(email) HAVING COUNT(*) > 1)
UNION ALL
SELECT 'order_items: no matching order', COUNT(*)
FROM order_items AS oi
WHERE NOT EXISTS (SELECT 1 FROM orders AS o WHERE o.order_id = oi.order_id)
UNION ALL
SELECT 'order_items: discount outside 0-0.25', COUNT(*)
FROM order_items
WHERE discount NOT BETWEEN 0 AND 0.25
UNION ALL
SELECT 'products: filed under a top-level category', COUNT(*)
FROM products AS p
JOIN categories AS c ON c.category_id = p.category_id
WHERE c.parent_id IS NULL
UNION ALL
SELECT 'orders: returned but no return record', COUNT(*)
FROM orders AS o
WHERE o.status = 'returned'
  AND NOT EXISTS (
    SELECT 1 FROM order_items AS oi
    JOIN returns AS r ON r.order_item_id = oi.order_item_id
    WHERE oi.order_id = o.order_id)
UNION ALL
SELECT 'tickets: rated while still open', COUNT(*)
FROM support_tickets
WHERE closed_at IS NULL AND satisfaction IS NOT NULL;

ثلاثة فحوص تفشل. كل جزء في الـ query المركّب يجب أن يعيد العدد نفسه من الأعمدة؛ والـ SELECT الأول هو الذي يسمّيها. يُبقي UNION ALL كل صف، بينما يزيل UNION التكرار، وهذا يكلّف وقتًا وقد يدمج فحصين صادف أن تشاركا الاسم والعدد. احفظ المجموعة بجانب تحليلك وشغّلها في كل مرة تُحدَّث فيها البيانات؛ فالفحص الذي نجح في أكتوبر قد يفشل في ديسمبر.

الإخفاقات أسئلة، لا أحكام

الآن اقرأ الإخفاقات كمحلّل، لا كأداة تدقيق آلية:

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

هناك إخفاق آخر مختبئ في هذه البيانات، وهو الأكثر إثارة للاهتمام: منتجات تظهر في طلبات قبل تاريخ إطلاقها المسجّل. العثور عليه هو تمرينك.

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