يعرض كريم نتائج 2025 على مجلس الإدارة الأسبوع القادم. طلبه قصير وجادّ: «قبل أن توضع هذه الأرقام على شريحة، ما مدى ثقتنا بالبيانات؟». كل query كتبته حتى الآن يفترض أن البيانات تعني ما تقوله الوثائق. يدور هذا الدرس حول فحص هذا الافتراض بشكل منهجي، حتى تستند عبارة «أنا واثق» إلى queries لا إلى مشاعر.
\nأنفع عادة في جودة البيانات أن تصوغ كل قاعدة كـ query يعيد الصفوف التي تخالفها. النتيجة الفارغة تعني أن القاعدة صامدة؛ وأي شيء آخر دليل يمكنك أن تُطلع عليه أحدًا. هذه القاعدة «المنتج يقع في فئة فرعية، وليس مباشرةً في فئة من المستوى الأعلى»، من وثائق البيانات:
\nSELECT p.product_id, p.name, c.name AS category\nFROM products AS p\nJOIN categories AS c ON c.category_id = p.category_id\nWHERE c.parent_id IS NULL;صفّان: Picnic Blanket مصنّف مباشرةً تحت Outdoor، وBamboo Cutting Board تحت Kitchen. وهذا يفسّر صفّي “Kitchen” و"Outdoor" الغريبين في جدول إيراد الفئات من القسم 2. الفحص الذي يعيد صفوفًا يمكنك تسميتها أقنع بكثير من مجرد عدد.
\nتقع معظم القواعد في خمس عائلات. تشغيل فحص واحد على الأقل من كل عائلة يلتقط الغالبية العظمى من المشكلات:
\n| العائلة | \nالسؤال | \nمثال من Cartwheel | \n
|---|---|---|
| التفرّد | \nهل المفتاح فريد فعلًا؟ | \nعناوين بريد مكرّرة، بتجاهل حالة الأحرف | \n
| الاكتمال | \nهل القيم موجودة حيث يجب؟ | \nتذاكر بلا agent_id | \n
| الصلاحية | \nهل القيم ضمن نطاقها المسموح؟ | \nخصم بين 0 و0.25 | \n
| السلامة المرجعية | \nهل يشير كل مرجع إلى صف حقيقي؟ | \nعناصر طلب لا وجود لطلبها | \n
| الاتساق | \nهل تروي الأعمدة والجداول المترابطة القصة نفسها؟ | \nطلبات موسومة ‘returned’ بلا سجل إرجاع؛ تذاكر مفتوحة لديها تقييم بالفعل | \n
قيود قاعدة البيانات (PRIMARY KEY وNOT NULL وCHECK وFOREIGN KEY) تفرض بعض هذه القواعد عند الكتابة، إن كانت قد عُرّفت، وفي حالة SQLite إن كان فرض المفاتيح الأجنبية مفعّلًا. نادرًا ما يتحكّم المحلّلون في ذلك، وقواعد الاتساق بين الجداول لا يمكن عادةً التعبير عنها كقيود أصلًا. لذا تفحص بنفسك.
الفحص الواحد query؛ ودزينة فحوص مجموعة. أعطِ كل فحص اسمًا، واعدد إخفاقاته، وكدّسها بـ UNION ALL:
SELECT 'customers: duplicate email (any case)' AS check_name, COUNT(*) AS failures\nFROM (SELECT LOWER(email) FROM customers GROUP BY LOWER(email) HAVING COUNT(*) > 1)\nUNION ALL\nSELECT 'order_items: no matching order', COUNT(*)\nFROM order_items AS oi\nWHERE NOT EXISTS (SELECT 1 FROM orders AS o WHERE o.order_id = oi.order_id)\nUNION ALL\nSELECT 'order_items: discount outside 0-0.25', COUNT(*)\nFROM order_items\nWHERE discount NOT BETWEEN 0 AND 0.25\nUNION ALL\nSELECT 'products: filed under a top-level category', COUNT(*)\nFROM products AS p\nJOIN categories AS c ON c.category_id = p.category_id\nWHERE c.parent_id IS NULL\nUNION ALL\nSELECT 'orders: returned but no return record', COUNT(*)\nFROM orders AS o\nWHERE o.status = 'returned'\n AND NOT EXISTS (\n SELECT 1 FROM order_items AS oi\n JOIN returns AS r ON r.order_item_id = oi.order_item_id\n WHERE oi.order_id = o.order_id)\nUNION ALL\nSELECT 'tickets: rated while still open', COUNT(*)\nFROM support_tickets\nWHERE closed_at IS NULL AND satisfaction IS NOT NULL;ثلاثة فحوص تفشل. كل جزء في الـ query المركّب يجب أن يعيد العدد نفسه من الأعمدة؛ والـ SELECT الأول هو الذي يسمّيها. يُبقي UNION ALL كل صف، بينما يزيل UNION التكرار، وهذا يكلّف وقتًا وقد يدمج فحصين صادف أن تشاركا الاسم والعدد. احفظ المجموعة بجانب تحليلك وشغّلها في كل مرة تُحدَّث فيها البيانات؛ فالفحص الذي نجح في أكتوبر قد يفشل في ديسمبر.
الآن اقرأ الإخفاقات كمحلّل، لا كأداة تدقيق آلية:
\nهناك إخفاق آخر مختبئ في هذه البيانات، وهو الأكثر إثارة للاهتمام: منتجات تظهر في طلبات قبل تاريخ إطلاقها المسجّل. العثور عليه هو تمرينك.
\n\nفي الدرس التالي ستنظر إلى الوجه الآخر للثقة، أي الأداء: لماذا يعمل بعض هذه الـ queries فورًا ويزحف بعضها الآخر، وكيف ترى ما تفعله قاعدة البيانات فعلًا.
\n","toc":[{"id":"sec-1","text":"الفحص query يعيد الصفوف السيئة","level":2},{"id":"sec-2","text":"العائلات الخمس للفحوص","level":2},{"id":"sec-3","text":"مجموعة فحوص يمكنك إعادة تشغيلها","level":2},{"id":"sec-4","text":"الإخفاقات أسئلة، لا أحكام","level":2}],"takeaways":["صُغ كل فحص لجودة البيانات كـ query يعيد الصفوف التي تخالف قاعدة ما، فتعني صفر صفوف أن الفحص ناجح.","غطِّ التفرّد والاكتمال والنطاقات الصالحة والسلامة المرجعية والاتساق بين الجداول؛ كلٌّ منها يلتقط نوعًا مختلفًا من المشكلات.","اجمع الفحوص في query واحد بـ UNION ALL فيه اسم وعدد إخفاقات لكل فحص، وشغّله قبل أي تحليل مهم.","الفحص الفاشل سؤال تطرحه على صاحب البيانات، لا شيء تصفّيه بصمت؛ دوّن ما وجدته وما قرّرته."],"further":[{"title":"SQLite compound SELECT statements (UNION ALL)","url":"https://www.sqlite.org/lang_select.html#compound_select_statements"},{"title":"SQLite CREATE TABLE constraints","url":"https://www.sqlite.org/lang_createtable.html#constraints"},{"title":"PostgreSQL constraints","url":"https://www.postgresql.org/docs/current/ddl-constraints.html"}],"quiz":[{"q":"أي query هو أفضل فحص لجودة البيانات للقاعدة «كل عنصر طلب ينتمي إلى طلب موجود»؟
","options":[{"text":"SELECT COUNT(*) FROM order_items JOIN orders USING (order_id)","why":"الـ inner join يُسقط العناصر اليتيمة بصمت، فيبدو العدد سليمًا سواء وُجدت أم لا."},{"text":"SELECT * FROM order_items oi WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.order_id = oi.order_id)","why":"صحيح. إنه يعيد بالضبط الصفوف التي تخالف القاعدة، فتعني النتيجة الفارغة نجاح الفحص، وأي صف دليل."},{"text":"SELECT COUNT(DISTINCT order_id) FROM order_items","why":"هذا يعدّ الطلبات التي تشير إليها العناصر، لكنه لا يستطيع أن يخبرك هل هذه الطلبات موجودة."},{"text":"SELECT * FROM orders WHERE order_id IS NOT NULL","why":"هذا يفحص الجدول الخطأ والقاعدة الخطأ؛ والمفاتيح الأساسية لا تكون NULL أصلًا."}],"answer":1},{"q":"طلبان حالتهما ‘returned’ لكن لا صف لهما في returns. وكلاهما قُدّم في الأسبوعين الأخيرين من ديسمبر 2025. ما الخطوة التالية الأكثر منطقية؟
لماذا نستخدم UNION ALL بدل UNION لجمع نتائج الفحوص في مجموعة واحدة؟
ثلاثة منتجات متوقفة (is_active = 0) ما زالت لها طلبات في ديسمبر 2025. ما نوع هذه المشكلة؟
is_active تحمل 0 أو 1 الصالحين؛ القيمة نفسها ليست خارج النطاق."},{"text":"سؤال اتساق بين الجداول، قد يكون خطأً في البيانات أو حالة عمل مشروعة مثل تصفية المخزون.","why":"صحيح. العلامة والمبيعات لا تتفقان. أمّا هل هذا خطأ فيعتمد على معنى «متوقف» في Cartwheel، وهذا سؤال لفريق المنتج."}],"answer":3}],"exercise":{"kind":"sql","starter":"-- Data-quality check: products sold before their launch date\n-- Write it from scratch. One row per offending product with:\n-- product_id, name, launched_on, first_sold (YYYY-MM-DD), lines\nSELECT product_id, name, launched_on\nFROM products;","solution":"SELECT\n p.product_id,\n p.name,\n p.launched_on,\n date(MIN(o.order_date)) AS first_sold,\n COUNT(*) AS lines\nFROM order_items AS oi\nJOIN orders AS o ON o.order_id = oi.order_id\nJOIN products AS p ON p.product_id = oi.product_id\nWHERE o.order_date < p.launched_on\nGROUP BY p.product_id, p.name, p.launched_on;","orderMatters":false,"title":"بيع قبل الإطلاق","prompt":"اكتب هذا الفحص من الصفر. القاعدة: لا يمكن طلب منتج قبل تاريخ launched_on الخاص به.
أعِد صفًا واحدًا لكل منتج يخالف القاعدة، فيه product_id وname وlaunched_on وfirst_sold (تاريخ أقدم طلب له بالصيغة ‘YYYY-MM-DD’) وlines (عدد سطور الطلبات التي قُدّمت قبل تاريخ الإطلاق). اعدد السطور التي قبل الإطلاق فقط. ترتيب الصفوف لا يهم.
order_items (السطور)، وorders (التاريخ)، وproducts (تاريخ الإطلاق).","شرط المخالفة يقارن عمودين من جدولين مختلفين: o.order_date < p.launched_on. نصوص ISO تُقارَن بشكل صحيح.","جمّع حسب أعمدة المنتج، ثم استخدم date(MIN(o.order_date)) وCOUNT(*)."],"explanation":"ربط السطور بطلباتها ومنتجاتها يضع تاريخ الطلب وتاريخ الإطلاق في الصف نفسه، فتصبح القاعدة شرطًا في WHERE. والتجميع حسب المنتج يحوّل 149 سطرًا مخالفًا إلى 8 منتجات. بعض الفجوات ضخمة: كانت Adjustable Dumbbells تُباع منذ فبراير 2024 لكنها «أُطلقت» في مايو 2025. هذا النمط يوحي بأن launched_on يسجّل شيئًا آخر، ربما إعادة إطلاق أو تاريخ استيراد الكتالوج، لا تاريخ التوفّر الأول الحقيقي. اطرح هذا السؤال على فريق المنتج قبل استخدام launched_on في أي تحليل لـ«المنتجات الجديدة».