الاختبار النهائي

اثنا عشر سؤالًا تغطي الدورة كلها. احصل على 70% أو أكثر لتنجح وتفتح شهادتك. يمكنك إعادته متى شئت.

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

يعيد SELECT COUNT(*) FROM support_tickets WHERE agent_id NOT IN (SELECT manager_id FROM employees) القيمة 0. لماذا؟

كل وكيل دعم هو أيضًا مدير لشخص ما.
قيمة manager_id للمديرة التنفيذية NULL، وNOT IN مقابل قائمة فيها NULL لا يكون TRUE أبدًا.
قيمة agent_id هي NULL في كل التذاكر.
لا يمكن استخدام NOT IN مع subquery.

اتجاه شهري يجمّع حسب strftime('%m', order_date). يعرض يناير قرابة ضعف الطلبات المتوقعة. ماذا حدث؟

التسمية بلا سنة، فدُمج يناير 2024 ويناير 2025 في مجموعة واحدة.
عدّت strftime كل طلب مرتين.
في يناير أيام أكثر من الأشهر الأخرى.
كان الـ query يحتاج إلى ORDER BY ليجمّع بشكل صحيح.

يُعرض SELECT c.country, COUNT(*) FROM customers c JOIN orders o ON o.customer_id = c.customer_id GROUP BY c.country على أنه «العملاء لكل دولة». ما الخطأ؟

يجب أن يستخدم LEFT JOIN.
يجب أن يذكر GROUP BY العمود customer_id.
لا شيء؛ كل صف عميل.
إنه يعدّ الطلبات؛ استخدم COUNT(DISTINCT c.customer_id)، أو استعلم من customers وحده إن كان يجب حساب كل عميل.

query يربط orders وorder_items وreturns ليعرض النتائج لكل دولة. أي مجموع آمن في هذا الـ JOIN؟

SUM(o.shipping_fee)
COUNT(*) كعدد للطلبات
SUM(r.refund_amount)
SUM(DISTINCT o.shipping_fee)

يجب أن يعرض تقرير كل منتج مع إجمالي المبالغ المستردة له في 2025، وصفرًا للمنتجات التي لم يُسترد ثمنها قط. يستخدم LEFT JOINs من products إلى order_items إلى returns، ثم WHERE r.return_date >= ‘2025-01-01’. ماذا يحدث؟

يعمل؛ الـ LEFT JOIN يُبقي كل منتج بغض النظر عن WHERE.
تختفي المنتجات التي ليس لها مرتجعات في 2025؛ يجب نقل اختبار التاريخ إلى عبارة ON في الربط مع returns.
يفشل الـ query لأن الـ LEFT JOIN لا يمكن تسلسله.
تتضاعف إجماليات المبالغ المستردة بسبب شرط التاريخ.

الإيراد لكل عميل مطلوب في خطوتين لاحقتين من تحليل ما. ما أفضل بنية؟

عرّفه مرة واحدة كـ CTE وأشِر إليه في الخطوتين.
انسخ الـ subquery نفسه في الموضعين.
استخدم subquery مترابطًا لكل صف بدلًا من ذلك.
أنشئ جدولًا دائمًا بالنتائج.

تريد هدى أعلى 3 منتجات من حيث الوحدات في كل فئة، مع إبقاء أي منتج متعادل على المركز الثالث. أي دالة تناسب؟

ROW_NUMBER() OVER (PARTITION BY category ORDER BY units DESC)
NTILE(3) OVER (PARTITION BY category ORDER BY units DESC)
RANK() OVER (PARTITION BY category ORDER BY units DESC)، مع إبقاء الترتيب 3 أو أفضل
DENSE_RANK() OVER (ORDER BY units DESC)

يستخدم النمو السنوي LAG(revenue, 12) OVER (ORDER BY month)، لكن شهرًا واحدًا لم تكن فيه أي طلبات. ما الخطر وما الإصلاح؟

لا خطر؛ يبحث LAG عن الشهر الذي قبل 12 شهرًا حسب التاريخ.
يعيد LAG القيمة 0 للشهر المفقود، وهذا صحيح.
استخدم LEAD بدل LAG.
كل مقارنة بعد الفجوة تنزاح شهرًا؛ ولّد تقويمًا للأشهر واربط به الإيراد بـ LEFT JOIN أولًا.

على جدول إيرادات شهري فيه صف واحد لكل شهر، أي إطار يعطي متوسطًا متحركًا لثلاثة أشهر؟

AVG(revenue) OVER (ORDER BY month ROWS BETWEEN 2 PRECEDING AND CURRENT ROW)
AVG(revenue) OVER (ORDER BY month ROWS BETWEEN 3 PRECEDING AND CURRENT ROW)
AVG(revenue) OVER (PARTITION BY month)
AVG(revenue) OVER (ORDER BY month)

الشرط WHERE strftime('%Y', order_date) = '2025' بطيء على جدول طلبات كبير عليه index على order_date. أي إعادة كتابة تعيد الصفوف نفسها وتستطيع استخدام الـ index؟

WHERE order_date LIKE ‘2025%’
WHERE order_date >= ‘2025-01-01’ AND order_date < ‘2026-01-01’
WHERE date(order_date) BETWEEN ‘2025-01-01’ AND ‘2025-12-31’
WHERE CAST(strftime(‘%Y’, order_date) AS INTEGER) = 2025

query في SQLite يجد عملاء دبي بـ WHERE city LIKE 'dubai'. بعد الانتقال إلى PostgreSQL لا يعيد أي صف. لماذا؟

لا يدعم PostgreSQL المعامل LIKE.
حُوّل العمود city إلى رقم.
يحتاج PostgreSQL إلى علامات تنصيص مزدوجة حول القيم النصية.
LIKE في PostgreSQL حسّاس لحالة الأحرف، فلا تطابق ‘dubai’ القيمة ‘Dubai’؛ استخدم ILIKE أو القيمة الدقيقة.

تعرض المراجعة النهائية cohort ديسمبر 2025 بمعدل احتفاظ 0% في الشهر 1، والأردن بنمو +627% في الربع الرابع. كيف يجب عرض الاثنين؟

اعرضهما كما هما؛ فالأرقام جاءت من قاعدة البيانات.
احذف cohort ديسمبر والأردن من الشرائح.
اعرض الشهر 1 لديسمبر على أنه لم يُرصد بعد، واعرض نمو الأردن بجانب قيمه المطلقة الصغيرة.
احسب متوسطهما مع الـ cohorts والدول الأخرى لتنعيمهما.

12 سؤالًا بلا إجابة