تحتاج المراجعة الشهرية لأعمال رانيا إلى ثلاثة أشياء في شريحة واحدة: الإيراد حسب الشهر، وما تراكم من إجمالي السنة حتى الآن، وهل نما كل شهر مقارنةً بسابقه. يمكنك حساب رقم ما منذ بداية السنة في جدول بيانات لاحقًا. لكن دوال النافذة نفسها التي رتّبت المنتجات في الدرس الماضي تستطيع أيضًا أن تراكم وتقارن، فيخرج الجدول كله من SQL مباشرةً، وبطريقة قابلة لإعادة الإنتاج.
\nدالة التجميع كدالة نافذة مع ORDER BY داخل OVER تصبح حسابًا تراكميًا: كل صف يرى الصفوف حتى نفسه. أضف PARTITION BY فيبدأ الحساب من جديد لكل مجموعة. هذه طلبات Cartwheel الشهرية مع عدد منذ بداية السنة يبدأ من جديد في كل يناير:
WITH monthly AS (\n SELECT strftime('%Y-%m', order_date) AS month, COUNT(*) AS orders\n FROM orders\n WHERE status <> 'cancelled'\n GROUP BY month\n)\nSELECT\n month,\n orders,\n SUM(orders) OVER (\n PARTITION BY substr(month, 1, 4)\n ORDER BY month\n ) AS orders_ytd\nFROM monthly\nORDER BY month\nLIMIT 14;مفتاح الـ partition هو السنة، مأخوذة من الأحرف الأربعة الأولى في تسمية الشهر. يغلق ديسمبر 2024 السنة على 552 طلبًا، ويبدأ يناير 2025 من جديد بـ 84.
\nنافذتان على الصف نفسه تتكاملان جيدًا. قسمة المجموع التراكمي على مجموع الـ partition كله، 100.0 * SUM(orders) OVER (PARTITION BY substr(month, 1, 4) ORDER BY month) / SUM(orders) OVER (PARTITION BY substr(month, 1, 4))، تعطي النسبة التراكمية من السنة التي بلغها كل شهر. في نشاط موسمي مثل Cartwheel، هذا هو الرقم الذي تتابعه المالية فعلًا: بنهاية أكتوبر 2025 كان قد أُنجز أقل بقليل من ثلثي السنة.
يعيد LAG(x) قيمة x من الصف السابق بترتيب النافذة، ويعيد LEAD(x) قيمتها من الصف التالي. بعدها يصبح التغيّر بين فترتين عملية حسابية بسيطة:
WITH monthly AS (\n SELECT strftime('%Y-%m', order_date) AS month, COUNT(*) AS orders\n FROM orders\n WHERE status <> 'cancelled'\n GROUP BY month\n)\nSELECT\n month,\n orders,\n LAG(orders) OVER (ORDER BY month) AS prev_month,\n orders - LAG(orders) OVER (ORDER BY month) AS change,\n ROUND(100.0 * (orders - LAG(orders) OVER (ORDER BY month))\n / NULLIF(LAG(orders) OVER (ORDER BY month), 0), 1) AS change_pct,\n LAG(orders, 12) OVER (ORDER BY month) AS same_month_last_year\nFROM monthly\nORDER BY month DESC\nLIMIT 4;قفز نوفمبر 2025 بـ 193 طلبًا، ثم هبط ديسمبر بـ 140: Black Friday، ثم الركود الذي يليه. الأرقام الشهرية المتتالية مشوّشة في نشاط موسمي، ولهذا يستخدم العمود الأخير LAG(orders, 12)، أي القيمة قبل اثني عشر صفًا، لمنظور سنة مقابل سنة: 325 طلبًا في نوفمبر هذا العام مقابل 120 في نوفمبر الماضي.
لا يكون LAG(orders, 12) «الشهر نفسه في السنة الماضية» إلا إذا كان لكل شهر صف. الشهر الذي لا طلبات فيه لن يكون له صف، وستنزاح كل مقارنة بعده شهرًا واحدًا بصمت. وهذا الافتراض على وشك أن يصبح مهمًا.
المتوسط المتحرك يخفّف التشويش اليومي. تحتاج النافذة إلى إطار (frame) صريح، أي نطاق الصفوف حول الصف الحالي الذي تراه دالة التجميع: ROWS BETWEEN 6 PRECEDING AND CURRENT ROW هو الصف الحالي مع الستة التي قبله.
يعدّ الإطار الصفوف لا الأيام. إذا لم يكن في يوم ما طلبات، فلا صف له، ويمتد الإطار بصمت إلى زمن أبعد. يُظهر الشهر الأول في Cartwheel مدى سوء هذا التضليل: في يناير 2024 وصلت 8 طلبات فقط، في 8 أيام مختلفة. المتوسط على 7 صفوف من الصفوف الموجودة يقول «طلب واحد يوميًا» طوال الشهر. والحقيقة نحو ربع ذلك.
\nالإصلاح هو تقويم: ولّد صفًا لكل يوم بـ CTE تكراري، واربط به الأعداد اليومية بـ LEFT JOIN، وحوّل الأيام المفقودة إلى أصفار:
\nWITH RECURSIVE days(day) AS (\n SELECT '2024-01-01'\n UNION ALL\n SELECT date(day, '+1 day') FROM days WHERE day < '2024-01-31'\n),\ndaily AS (\n SELECT date(order_date) AS day, COUNT(*) AS orders\n FROM orders\n WHERE status <> 'cancelled'\n AND order_date >= '2024-01-01' AND order_date < '2024-02-01'\n GROUP BY day\n),\nfilled AS (\n SELECT d.day, COALESCE(x.orders, 0) AS orders\n FROM days AS d\n LEFT JOIN daily AS x ON x.day = d.day\n),\nsmoothed AS (\n SELECT day, orders,\n ROUND(AVG(orders) OVER (\n ORDER BY day ROWS BETWEEN 6 PRECEDING AND CURRENT ROW\n ), 2) AS orders_7d_avg\n FROM filled\n)\nSELECT * FROM smoothed\nWHERE day >= '2024-01-25'\nORDER BY day;الآن يعرض 31 يناير 0.43 طلب يوميًا خلال الأسبوع الأخير، وهو الرقم الصادق. لاحظ موضع شرط التاريخ: في الـ SELECT الأخير، بعد حساب المتوسط المتحرك في smoothed. تعمل دوال النافذة بعد WHERE، فالتصفية في الـ query نفسه ستترك الأيام الأولى المعروضة بلا تاريخ سابق يُحسب متوسطه. وحيلة التقويم نفسها تحمي LAG(orders, 12) من الأشهر المفقودة.
أصبحت قادرًا على الترتيب والمراكمة والمقارنة. يضع الدرس التالي هذه الأدوات في خدمة التحليلين اللذين يطلبهما كل فريق منتج: القمع (funnel) ومعدل الاحتفاظ (retention) لكل cohort.
\n","toc":[{"id":"sec-1","text":"المجاميع التراكمية ومنذ بداية السنة","level":2},{"id":"sec-2","text":"المقارنة بالصف السابق","level":2},{"id":"sec-3","text":"المتوسطات المتحركة والإطار","level":2}],"takeaways":["SUM(x) OVER (ORDER BY period) مجموع تراكمي؛ وإضافة PARTITION BY year تجعله يبدأ من جديد كل سنة، أي المجموع منذ بداية السنة.","يقرأ LAG(x) قيمة الصف السابق ويقرأ LEAD(x) قيمة الصف التالي، فيكون التغيّر بين فترتين متتاليتين x - LAG(x).","يحتاج المتوسط المتحرك (moving average) إلى إطار صريح، مثل ROWS BETWEEN 6 PRECEDING AND CURRENT ROW، وإلى صف لكل فترة، بما فيها الفترات الفارغة.","تعمل دوال النافذة بعد WHERE، لذا صفِّ النطاق المعروض في query خارجي، وإلا لن ترى النافذة إلا الصفوف المصفّاة."],"further":[{"title":"SQLite window functions, frame specifications","url":"https://www.sqlite.org/windowfunctions.html#frame_specifications"},{"title":"PostgreSQL window function calls","url":"https://www.postgresql.org/docs/current/sql-expressions.html#SYNTAX-WINDOW-FUNCTIONS"}],"quiz":[{"q":"يُضاف SUM(revenue) OVER () إلى جدول إيرادات شهري. ماذا يعرض كل صف؟
الطلبات الشهرية 84 و63 و70 من يناير إلى مارس. ماذا يعيد orders - LAG(orders) OVER (ORDER BY month) ليناير وفبراير ومارس؟
LAG(orders, 1, 0)، فقط إذا كان 0 هو خط الأساس الصحيح فعلًا."}],"answer":2},{"q":"الطلبات اليومية مفقودة في الأيام التي لا مبيعات فيها. ما الخطأ في AVG(orders) OVER (ORDER BY day ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) على هذا الجدول؟
يُفترض أن يعرض هذا الـ query متوسطًا متحركًا لسبعة أيام للأسبوع الأخير من ديسمبر فقط. لماذا تأتي القيم الأولى منخفضة أكثر من اللازم؟
\nSELECT day, AVG(orders) OVER (ORDER BY day ROWS BETWEEN 6 PRECEDING AND CURRENT ROW)\nFROM filled_days\nWHERE day >= '2025-12-25';ابنِ جدول الشريحة لرانيا: صف واحد لكل شهر في 2025 (الطلبات غير الملغاة) فيه month (‘YYYY-MM’)، وrevenue، وrunning_revenue (الإيراد المتراكم من يناير حتى ذلك الشهر شاملًا إياه)، وmom_change (إيراد هذا الشهر ناقص إيراد الشهر السابق؛ وNULL ليناير). قرّب أعمدة المال إلى منزلتين عشريتين ورتّب حسب month. الترتيب مهم.
الـ CTE المسمّى monthly صحيح. أما عمودا النافذة في الـ SELECT الأخير فكلاهما خاطئ.
running_revenue يعرض الرقم نفسه. ما الذي ينقص داخل OVER ()؟","استخدم SUM(revenue) OVER (ORDER BY month) للمجموع التراكمي.","LEAD ينظر إلى الصف التالي. للمقارنة بالشهر السابق، استخدم revenue - LAG(revenue) OVER (ORDER BY month)."],"explanation":"الـ OVER () الفارغ ينشئ نافذة واحدة تضم الأشهر الاثني عشر كلها، فطبع الكود المبدئي المجموع السنوي في كل صف. إضافة ORDER BY month تحوّلها إلى نافذة تكبر تدريجيًا، أي مجموع تراكمي. وللتغيّر الشهري تحتاج إلى الصف السابق، أي LAG؛ أما LEAD فقارن كل شهر بالشهر التالي وترك ديسمبر NULL بدل يناير. الإيراد التراكمي لديسمبر يساوي إجمالي السنة، وهذا فحص مطابقة مجاني مقابل جدول الفئات من درس الـ JOIN.