التطبيع
Normalization
التطبيع — Normalization
التطبيع يعني تنظيم البيانات لتقليل التكرار وحماية المعنى. إذا كتبت اسم العميل وعنوانه داخل كل طلب، فماذا يحدث عندما يتغير الاسم؟ ستحتاج تحديث عدة صفوف وقد تنسى بعضها. الأفضل أن يكون العميل في جدول، والطلب يشير إليه.
لكن التطبيع ليس هدفاً مطلقاً. لا تفصل كل كلمة إلى جدول. التصميم الجيد يوازن بين سلامة البيانات وسهولة القراءة والأداء. في البداية، افصل المفاهيم الواضحة: customers, orders, products, payments.
مثال الفرق
تخيل جدول طلبات غير منظّم — كل صف يكرر بيانات العميل والمنتج:
orders_raw
┌────┬───────────────┬────────────────────────┬──────────────┬────────────────┐
│ id │ customer_name │ customer_email │ product_name │ price_halalas │
├────┼───────────────┼────────────────────────┼──────────────┼────────────────┤
│ 1 │ Sara │ [email protected] │ Book │ 2500 │
│ 2 │ Sara │ [email protected] │ Pen │ 500 │
│ 3 │ Noura │ [email protected] │ Book │ 2500 │
└────┴───────────────┴────────────────────────┴──────────────┴────────────────┘
إذا تغير بريد Sara، يجب تحديث صفين. إذا نُسي أحدهما، أصبح البريد متعارضاً. الحل: فصل المفاهيم.
الآن بريد Sara موجود في صف واحد فقط. لتحديثه، صف واحد يكفي.
في الترحيل الحقيقي، الاستعلام النموذجي لاستخراج العملاء الفريدين من الجدول القديم:
INSERT INTO customers (name, email)
SELECT DISTINCT customer_name, customer_email FROM orders_raw;
متى تقبل التكرار؟
أحياناً تحتاج snapshot مثل اسم المنتج وقت الطلب حتى يبقى التاريخ صحيحاً حتى لو تغير اسم المنتج لاحقاً. هذا ليس فشلاً في التطبيع، بل قرار مجال.