بيكون الشرح عبر مراحل المرحلة التالية هي
من عرض البيانات إلى تحليلها (GROUP BY & HAVING)

📘 الدرس: لماذا نستخدم GROUP BY؟
حتى الآن، كنا نعرض بيانات.
لكن في الواقع،
نحن لا نريد البيانات نفسها…
نريد: تحليلها.
مثال:بدلاً من:عرض كل الطلبات
نريد:كم عدد الطلبات لكل عميل؟

أو: إجمالي المبيعات لكل مدينة؟
هنا يأتي دور GROUP BY

GROUP BY تعني:
تجميع البيانات حسب معيار معين
ثم تطبيق عملية عليها (مثل COUNT أو SUM)

مثال بسيط:
كم عدد الطلبات لكل عميل؟
❓ السؤال لك: هل ترى الفرق بين "عرض البيانات"
و "تحليل البيانات"؟

📘 اليوم التطبيق العملي
📘 التطبيق العملي على GROUP BY

لدينا جدول orders:

order_id | customer_id | total

نريد:
عدد الطلبات لكل عميل

SELECT customer_id, COUNT(*) AS total_orders
FROM orders
GROUP BY customer_id;

ما الذي حدث؟

1- جمعنا البيانات حسب customer_id
2- حسبنا عدد الطلبات لكل مجموعة

النتيجة:
كل عميل + عدد طلباته

مثال آخر:

إجمالي المبيعات لكل عميل:

SELECT customer_id, SUM(total) AS total_sales
FROM orders
GROUP BY customer_id;

الآن بدأنا نحلل البيانات فعلاً.

❓ أيهما أهم برأيك:
COUNT أم SUM في عملك؟

📝 اليوم — تمرين
📝 تمرين اليوم:

لدينا جدول orders يحتوي على:

order_id, customer_id, total

المطلوب:

1- حساب عدد الطلبات لكل عميل
2- حساب إجمالي المبيعات لكل عميل

حاول كتابة الاستعلام بنفسك قبل رؤية الحل.

لا تستعجل… التفكير أهم من الحل.

📘 اليوم — الحل + التحليل الاحترافي
📘 حل التمرين

الحل الأول:

SELECT customer_id, COUNT(*) AS total_orders
FROM orders
GROUP BY customer_id;

الحل الثاني:

SELECT customer_id, SUM(total) AS total_sales
FROM orders
GROUP BY customer_id;

---

التحليل:

لماذا استخدمنا GROUP BY؟

لأننا لا نريد كل الطلبات،
بل نريد نتيجة مجمعة لكل عميل.

الخطأ الشائع:

كتابة COUNT بدون GROUP BY
وهذا يعطي نتيجة واحدة فقط.

---

معلومة مهمة:

GROUP BY بدون فهم
يعطي نتائج مضللة.

الخطوة القادمة:

ماذا لو أردنا عرض العملاء
الذين لديهم أكثر من 5 طلبات فقط؟

هنا نحتاج مفهوم جديد:
HAVING

سنبدأ به في الدرس القادم.

تحديث مهم بخصوص خطة القناة
خلال الفترة القادمة سيتم إيقاف السلسلة الحالية مؤقتًا، والانتقال إلى مسار جديد أكثر احترافية وتركيزًا على قواعد بيانات وأنظمة ERP العملية.
الهدف من هذه الخطوة هو تقديم محتوى أقرب لبيئة العمل الحقيقية، يساعد على فهم تصميم الأنظمة الإدارية وتحليل قواعد البيانات بشكل عملي واحترافي.

بإذن الله ستكون المرحلة القادمة أقوى وأكثر فائدة لكل المهتمين بمجال قواعد البيانات وتطوير الأنظمة 🚀

هذه الخطة مبنية على 3 مبادئ:
كل درس = جزء من مشروع
كل يوم = مخرجات ملموسة
كل 3 أيام = تفاعل + Challenge

🚀 بداية مشروع احترافي على القناة
إذا كنت تعرف أساسيات SQL لكن لا تعرف كيف تبني نظام حقيقي…
فهذا هو التحول الذي كنت تنتظره 👇
🔥 ابتداءً من اليوم:
سنبني معًا نظام ERP متكامل باستخدام SQL Server
❌ لا يوجد شرح عشوائي
❌ لا يوجد نظريات بدون تطبيق
بل:
✅ مشروع حقيقي خطوة بخطوة
✅ من مستوى متوسط → احتراف
✅ كل درس = جزء من النظام
---
🎯 ماذا سنبني؟
نظام يحتوي على:
- إدارة العملاء (Customers)
- المنتجات (Products)
- الطلبات (Orders)
- المخزون (Inventory)
- الموظفين (HR)
---
💡 الهدف النهائي:
تحويلك من:
"شخص يعرف SQL"
إلى:
"شخص يبني أنظمة حقيقية"
---
📅 الخطة:
30 يوم = نظام كامل + مهارات احترافية
---
🔥 إذا أنت جاد: ابد اليوم

📌 Lesson 1: كيف يفكر نظام ERP؟
#Day1 #ERP_Project

قبل كتابة كود، افهم عمل النظام:

🛒 السيناريو:
1️⃣ اختيار المنتج
2️⃣ إنشاء طلب (Order)
3️⃣ إضافة التفاصيل
4️⃣ خصم الكمية من المخزون
5️⃣ تسجيل العملية
💡 هذا يسمى: Business Flow (تدفق العمل)

🎯 مهمتك كمطور:
ليس فقط SQL ❌ بل تحويل السيناريو إلى: جداول + علاقات + منطق
📊 العناصر الأساسية:
- Customers
- Products
- Orders
- Inventory

🔥 Challenge:
هل العميل يمكن أن يملك أكثر من طلب؟ ولماذا؟
💬 اكتب إجابتك في التعليقات

🧠 سؤال سريع (مهم جدًا)

في نظام ERP:

ما نوع العلاقة بين:

Customers و Orders ؟

---

A) One-to-One
B) One-to-Many
C) Many-to-Many

---

💬 اكتب الإجابة + السبب

🎯 الهدف:
نبدأ نفكر كمحللين أنظمة وليس فقط مبرمجين

🔥 سيتم شرح الإجابة في الدرس القادم

🟠 🧠 (Relationships + أول كود)
📌 Lesson 2: فهم العلاقات (Relationships)
#Day3 #ERP_Project
---
📊 الإجابة الصحيحة:
Customers → Orders = One-to-Many ✅
---
💡 لماذا؟
لأن:
عميل واحد يمكن أن ينشئ عدة طلبات
لكن كل طلب يعود لعميل واحد فقط
---
🔥 هذا أهم مفهوم في قواعد البيانات:
Relationship Design
---
🎯 الآن نبدأ أول خطوة حقيقية:

إنشاء جدول Customers 👇

CREATE TABLE Customers (
CustomerID INT PRIMARY KEY IDENTITY,
Name NVARCHAR(100) NOT NULL
);

🎯 ماذا تعلمنا؟
- كل جدول يمثل كيان (Entity)
- كل علاقة تمثل ارتباط منطقي

🔥 Challenge:

كيف تتوقع شكل جدول Orders؟

فكر في:
- ما هي الأعمدة؟
- كيف نربطه بـ Customers؟

💬 اكتب تصميمك في التعليقات

📌 Lesson 3: كيف نفكر في تصميم Orders؟
#Day4 #ERP_Project
🎯 قبل ما نكتب أي كود…
لازم نسأل:
ما هو "Order" داخل النظام؟
---
🧠 تخيل هذا السيناريو:
عميل دخل واشترى منتجات 👇
النظام لازم يسجل:
* من هو العميل؟
* متى تم الطلب؟
* ما هو رقم الطلب؟
---
💡 إذًا جدول Orders يجب أن يحتوي على:

✔️ OrderID
✔️ CustomerID
✔️ OrderDate
---
❗️ سؤال مهم:
هل نضع المنتجات داخل Orders؟ 🤔
---
🚫 الجواب: لا
ليش؟
لأن:
الطلب الواحد يحتوي على أكثر من منتج
---
🔥 Challenge:
برأيك:
ما هو الحل الصحيح لتخزين المنتجات؟
💬 اكتب فكرتك

# 🟢 Day 4 — (فهم Orders قبل الكود)

هذا المنشور هدفه “ترتيب التفكير” وليس كتابة كود

:::writing{variant="social_post" id="58213"}
📌 Lesson 3: كيف نفكر في تصميم Orders؟
#Day4 #ERP_Project

---

🎯 قبل ما نكتب أي كود…

لازم نسأل:
ما هو "Order" داخل النظام؟

---

🧠 تخيل هذا السيناريو:

عميل دخل واشترى منتجات 👇

النظام لازم يسجل:

- من هو العميل؟
- متى تم الطلب؟
- ما هو رقم الطلب؟

---

💡 إذًا جدول Orders يجب أن يحتوي على:

✔️ OrderID
✔️ CustomerID
✔️ OrderDate

---

❗️ سؤال مهم:

هل نضع المنتجات داخل Orders؟ 🤔

---

🚫 الجواب: لا

ليش؟

لأن:
الطلب الواحد يحتوي على أكثر من منتج

---

🔥 Challenge:

برأيك:
ما هو الحل الصحيح لتخزين المنتجات؟

💬 اكتب فكرتك

# 🟢 Day 5 — (إنشاء Orders Table + أول ربط حقيقي)

📌 Lesson 4: إنشاء جدول Orders وربطه بـ Customers
#Day5 #ERP_Project

---

🎯 الآن نحول التفكير إلى كود 👇

---

🔥 الكود:
CREATE TABLE Orders (
OrderID INT PRIMARY KEY IDENTITY,
CustomerID INT,
OrderDate DATETIME DEFAULT GETDATE(),
FOREIGN KEY (CustomerID) REFERENCES Customers(CustomerID)
);
---

💡 ماذا فعلنا هنا؟

✔️ أنشأنا جدول Orders
✔️ ربطناه بجدول Customers
✔️ كل طلب أصبح مرتبط بعميل

---

📊 هذا يسمى:
Relationship (ربط بين الجداول)

---

❗️ سيناريو مهم:

إذا حذفنا Customer مرتبط بطلب…

ماذا سيحدث؟ 🤔

---

🔥 Challenge:

جاوب:
هل يسمح النظام بالحذف أم يمنعه؟ ولماذا؟

💬 اكتب إجابتك

# 🟢 Day 6 — (حل المشكلة الحقيقية: OrderDetails)
📌 Lesson 5: حل مشكلة المنتجات داخل الطلب (OrderDetails)
#Day6 #ERP_Project

---

🎯 المشكلة:

الطلب يحتوي على عدة منتجات ❗️

---

❌ لا يمكن تخزينها داخل Orders

---

💡 الحل الاحترافي:

إنشاء جدول جديد:
OrderDetails

---

🔥 الكود:
CREATE TABLE OrderDetails (
    ID INT PRIMARY KEY IDENTITY,
    OrderID INT,
    ProductID INT,
    Quantity INT,
    FOREIGN KEY (OrderID) REFERENCES Orders(OrderID)
);
---

📊 ماذا حللنا؟

✔️ فصلنا الطلب عن التفاصيل 
✔️ أصبح كل طلب يحتوي على عدة منتجات 
✔️ حللنا مشكلة Many-to-Many

---

🎯 أصبح النظام كالتالي:

Orders → معلومات عامة 
OrderDetails → تفاصيل المنتجات 

---

🔥 Challenge:

ما نوع العلاقة بين:

Orders و OrderDetails ؟

💬 اكتب الإجابة
:::

🔥 تحدي :
اكتب استعلام يعرض:
اسم العميل + تاريخ الطلب
💬 اكتب الحل في التعليقات

سؤال احترافي
💣 إذا استخدمت JOIN غلط…
ممكن تطلع بيانات مضروبة ❌
كيف تتأكد أن النتائج صحيحة؟
#ERP_Project