HTML CSS JAVASCRIPT PHP PYTHON SQL LARAVEL
DevArabi
دورة تعلم SQL

التطبيع (Database Normalization)

السابق التالي

التطبيع (Database Normalization) هو عملية منهجية وعلمية لتنظيم البيانات في قاعدة البيانات بهدف تقليل التكرار (Redundancy) وتجنب الشذوذ (Anomalies) الذي قد يحدث عند إدخال، تحديث، أو حذف البيانات. التطبيع ليس مجرد تقنية، بل هو فن وعلم في نفس الوقت، يتطلب فهماً عميقاً لطبيعة البيانات والعلاقات بينها. في هذا الدرس الشامل والمفصل من سلسلة تعلم لغة SQL باللغة العربية، سنتعلم جميع الأشكال الطبيعية (Normal Forms) من الشكل الطبيعي الأول (1NF) حتى شكل Boyce-Codd الطبيعي (BCNF)، مع أمثلة عملية تطبيقية توضح كيفية تحويل جداول غير منظمة إلى جداول محسّنة ومنظمة بشكل احترافي.

1. ما هو التطبيع ولماذا نحتاجه؟

التطبيع (Normalization) هو عملية تقسيم الجداول الكبيرة والمعقدة إلى جداول أصغر ومترابطة، بحيث تكون كل معلومة مخزنة في مكان واحد فقط. تخيل أنك تدير نظام إدارة طلاب، وقررت تخزين جميع المعلومات في جدول واحد ضخم يحتوي على: معلومات الطالب، معلومات المقررات، معلومات الأساتذة، والدرجات. هذا التصميم سيؤدي إلى مشاكل خطيرة:

مشاكل قواعد البيانات غير المطبعة
❌ مشكلة 1: تكرار البيانات (Data Redundancy)

إذا كان الطالب مسجلاً في 5 مقررات، ستُخزن معلوماته الشخصية (الاسم، العنوان، رقم الهاتف) 5 مرات! هذا يهدر المساحة التخزينية ويزيد من احتمالية التناقض.

❌ مشكلة 2: شذوذ التحديث (Update Anomaly)

إذا غيّر الطالب رقم هاتفه، يجب تحديثه في 5 صفوف مختلفة. إذا نسيت تحديث أحدها، ستصبح البيانات متناقضة.

❌ مشكلة 3: شذوذ الحذف (Deletion Anomaly)

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

❌ مشكلة 4: شذوذ الإدراج (Insertion Anomaly)

لا يمكنك إضافة معلومات طالب جديد إلا إذا سجّله في مقرر. ماذا لو أردت تسجيل الطالب قبل اختيار المقررات؟

التطبيع يحل جميع هذه المشاكل من خلال تقسيم البيانات إلى جداول منطقية مترابطة، حيث تُخزن كل معلومة في مكان واحد فقط، وتُربط الجداول ببعضها من خلال المفاتيح الخارجية (Foreign Keys).

2. الأشكال الطبيعية: نظرة عامة

عملية التطبيع تتم على مراحل، كل مرحلة تسمى "شكل طبيعي" (Normal Form). كل شكل طبيعي له قواعد محددة يجب أن تحققها البيانات. الأشكال الطبيعية الرئيسية هي:

الشكل الطبيعي الرمز الهدف الأساسي
الشكل الطبيعي الأول 1NF إزالة المجموعات المتكررة والقيم المتعددة
الشكل الطبيعي الثاني 2NF إزالة التبعيات الجزئية
الشكل الطبيعي الثالث 3NF إزالة التبعيات الانتقالية
شكل Boyce-Codd الطبيعي BCNF نسخة أقوى من 3NF

كل شكل طبيعي يبني على الشكل الذي قبله. أي أن الجدول في 2NF يجب أن يكون أولاً في 1NF، والجدول في 3NF يجب أن يكون في 2NF، وهكذا. في معظم التطبيقات العملية، الوصول إلى 3NF يكون كافياً لتحقيق قاعدة بيانات منظمة وفعالة.

3. الشكل الطبيعي الأول (1NF - First Normal Form)

الشكل الطبيعي الأول هو الخطوة الأولى في عملية التطبيع. الجدول يكون في 1NF إذا حقق الشروط التالية:

  • كل عمود يحتوي على قيم ذرية (Atomic Values) - أي قيمة واحدة فقط، وليس مجموعة قيم
  • لا توجد مجموعات متكررة من الأعمدة
  • كل صف يجب أن يكون فريداً (يُفضل وجود مفتاح أساسي)
  • ترتيب الصفوف والأعمدة غير مهم
مثال: جدول غير محقق لـ 1NF
❌ جدول ينتهك 1NF - يحتوي على قيم متعددة 
-- جدول الطلاب (غير محقق لـ 1NF)
+------------+----------+---------------------------+
| student_id | name     | phone_numbers             |
+------------+----------+---------------------------+
| 1          | أحمد     | 0501234567, 0509876543    |
| 2          | فاطمة    | 0551112222                |
| 3          | محمد     | 0501111111, 0502222222, 0503333333 |
+------------+----------+---------------------------+

هذا الجدول ينتهك 1NF لأن عمود phone_numbers يحتوي على قيم متعددة (أكثر من رقم هاتف في خلية واحدة).

الحل: تحويل الجدول إلى 1NF
✅ جدول محقق لـ 1NF - قيم ذرية 
-- جدول الطلاب
CREATE TABLE students (
    student_id INT PRIMARY KEY,
    name VARCHAR(100) NOT NULL
);

-- جدول أرقام الهواتف (منفصل)
CREATE TABLE student_phones (
    phone_id INT PRIMARY KEY AUTO_INCREMENT,
    student_id INT NOT NULL,
    phone_number VARCHAR(20) NOT NULL,
    FOREIGN KEY (student_id) REFERENCES students(student_id)
);

-- البيانات بعد التطبيع
-- جدول students:
+------------+----------+
| student_id | name     |
+------------+----------+
| 1          | أحمد     |
| 2          | فاطمة    |
| 3          | محمد     |
+------------+----------+

-- جدول student_phones:
+----------+------------+--------------+
| phone_id | student_id | phone_number |
+----------+------------+--------------+
| 1        | 1          | 0501234567   |
| 2        | 1          | 0509876543   |
| 3        | 2          | 0551112222   |
| 4        | 3          | 0501111111   |
| 5        | 3          | 0502222222   |
| 6        | 3          | 0503333333   |
+----------+------------+--------------+

الآن كل خلية تحتوي على قيمة واحدة فقط، والجدول محقق للشكل الطبيعي الأول.

4. الشكل الطبيعي الثاني (2NF - Second Normal Form)

الجدول يكون في 2NF إذا كان:

  • محققاً للشكل الطبيعي الأول (1NF)
  • جميع الأعمدة غير المفتاحية تعتمد بشكل كامل على المفتاح الأساسي بالكامل (لا توجد تبعيات جزئية)

التبعية الجزئية (Partial Dependency) تحدث عندما يكون المفتاح الأساسي مركباً من عدة أعمدة، وبعض الأعمدة الأخرى تعتمد على جزء فقط من المفتاح الأساسي وليس كله.

مثال: جدول غير محقق لـ 2NF
❌ جدول ينتهك 2NF - يحتوي على تبعيات جزئية 
-- جدول تسجيل الطلاب في المقررات (غير محقق لـ 2NF)
CREATE TABLE enrollments (
    student_id INT,
    course_id INT,
    student_name VARCHAR(100),    -- يعتمد فقط على student_id
    student_email VARCHAR(100),   -- يعتمد فقط على student_id
    course_name VARCHAR(100),     -- يعتمد فقط على course_id
    instructor VARCHAR(100),      -- يعتمد فقط على course_id
    grade DECIMAL(5, 2),          -- يعتمد على كلا المفتاحين
    PRIMARY KEY (student_id, course_id)
);

-- مثال على البيانات:
+------------+-----------+--------------+-------------------+-------------+------------+-------+
| student_id | course_id | student_name | student_email     | course_name | instructor | grade |
+------------+-----------+--------------+-------------------+-------------+------------+-------+
| 1          | 101       | أحمد         | ahmed@email.com   | قواعد بيانات| د. محمد    | 95.5  |
| 1          | 102       | أحمد         | ahmed@email.com   | برمجة ويب   | د. فاطمة   | 88.0  |
| 2          | 101       | سارة         | sara@email.com    | قواعد بيانات| د. محمد    | 92.0  |
+------------+-----------+--------------+-------------------+-------------+------------+-------+

المشكلة هنا: student_name و student_email يعتمدان فقط على student_id (جزء من المفتاح)، و course_name و instructor يعتمدان فقط على course_id. هذا يسبب تكراراً: اسم أحمد وبريده مكرران، واسم المقرر والمدرس مكرران.

الحل: تحويل الجدول إلى 2NF
✅ جداول محققة لـ 2NF - تقسيم البيانات 
-- 1. جدول الطلاب (معلومات الطالب فقط)
CREATE TABLE students (
    student_id INT PRIMARY KEY,
    student_name VARCHAR(100) NOT NULL,
    student_email VARCHAR(100) NOT NULL UNIQUE
);

-- 2. جدول المقررات (معلومات المقرر فقط)
CREATE TABLE courses (
    course_id INT PRIMARY KEY,
    course_name VARCHAR(100) NOT NULL,
    instructor VARCHAR(100) NOT NULL
);

-- 3. جدول التسجيل (العلاقة والدرجة فقط)
CREATE TABLE enrollments (
    student_id INT,
    course_id INT,
    grade DECIMAL(5, 2),
    PRIMARY KEY (student_id, course_id),
    FOREIGN KEY (student_id) REFERENCES students(student_id),
    FOREIGN KEY (course_id) REFERENCES courses(course_id)
);

-- البيانات بعد التطبيع:
-- students:
+------------+--------------+-------------------+
| student_id | student_name | student_email     |
+------------+--------------+-------------------+
| 1          | أحمد         | ahmed@email.com   |
| 2          | سارة         | sara@email.com    |
+------------+--------------+-------------------+

-- courses:
+-----------+-------------+------------+
| course_id | course_name | instructor |
+-----------+-------------+------------+
| 101       | قواعد بيانات| د. محمد    |
| 102       | برمجة ويب   | د. فاطمة   |
+-----------+-------------+------------+

-- enrollments:
+------------+-----------+-------+
| student_id | course_id | grade |
+------------+-----------+-------+
| 1          | 101       | 95.5  |
| 1          | 102       | 88.0  |
| 2          | 101       | 92.0  |
+------------+-----------+-------+

الآن لا يوجد تكرار، وكل معلومة مخزنة في مكان واحد فقط. إذا غيّر الطالب بريده الإلكتروني، نحدثه في مكان واحد فقط.

5. الشكل الطبيعي الثالث (3NF - Third Normal Form)

الجدول يكون في 3NF إذا كان:

  • محققاً للشكل الطبيعي الثاني (2NF)
  • لا توجد تبعيات انتقالية (Transitive Dependencies)

التبعية الانتقالية تحدث عندما يعتمد عمود غير مفتاحي على عمود غير مفتاحي آخر، بدلاً من أن يعتمد مباشرة على المفتاح الأساسي. بمعنى: إذا كان A يعتمد على B، و B يعتمد على المفتاح الأساسي، فإن A يعتمد بشكل انتقالي على المفتاح الأساسي.

مثال: جدول غير محقق لـ 3NF
❌ جدول ينتهك 3NF - يحتوي على تبعيات انتقالية 
-- جدول الموظفين (غير محقق لـ 3NF)
CREATE TABLE employees (
    employee_id INT PRIMARY KEY,
    employee_name VARCHAR(100) NOT NULL,
    department_id INT NOT NULL,
    department_name VARCHAR(100) NOT NULL,    -- يعتمد على department_id
    department_location VARCHAR(100) NOT NULL -- يعتمد على department_id
);

-- مثال على البيانات:
+-------------+---------------+---------------+-----------------+---------------------+
| employee_id | employee_name | department_id | department_name | department_location |
+-------------+---------------+---------------+-----------------+---------------------+
| 1           | أحمد          | 10            | المبيعات        | الرياض              |
| 2           | فاطمة         | 10            | المبيعات        | الرياض              |
| 3           | محمد          | 20            | التسويق         | جدة                 |
| 4           | سارة          | 20            | التسويق         | جدة                 |
+-------------+---------------+---------------+-----------------+---------------------+

المشكلة: department_name و department_location يعتمدان على department_id وليس مباشرة على employee_id. هذا يسبب تكراراً: اسم القسم وموقعه مكرران لكل موظف في نفس القسم.

الحل: تحويل الجدول إلى 3NF
✅ جداول محققة لـ 3NF - إزالة التبعيات الانتقالية 
-- 1. جدول الأقسام (معلومات القسم فقط)
CREATE TABLE departments (
    department_id INT PRIMARY KEY,
    department_name VARCHAR(100) NOT NULL,
    department_location VARCHAR(100) NOT NULL
);

-- 2. جدول الموظفين (معلومات الموظف فقط)
CREATE TABLE employees (
    employee_id INT PRIMARY KEY,
    employee_name VARCHAR(100) NOT NULL,
    department_id INT NOT NULL,
    FOREIGN KEY (department_id) REFERENCES departments(department_id)
);

-- البيانات بعد التطبيع:
-- departments:
+---------------+-----------------+---------------------+
| department_id | department_name | department_location |
+---------------+-----------------+---------------------+
| 10            | المبيعات        | الرياض              |
| 20            | التسويق         | جدة                 |
+---------------+-----------------+---------------------+

-- employees:
+-------------+---------------+---------------+
| employee_id | employee_name | department_id |
+-------------+---------------+---------------+
| 1           | أحمد          | 10            |
| 2           | فاطمة         | 10            |
| 3           | محمد          | 20            |
| 4           | سارة          | 20            |
+-------------+---------------+---------------+

الآن معلومات القسم مخزنة في مكان واحد فقط. إذا تغير موقع قسم المبيعات، نحدثه في صف واحد فقط في جدول departments.

6. شكل Boyce-Codd الطبيعي (BCNF)

BCNF هو نسخة أقوى وأكثر صرامة من 3NF. الجدول يكون في BCNF إذا كان:

  • محققاً للشكل الطبيعي الثالث (3NF)
  • لكل تبعية وظيفية (Functional Dependency) X → Y، يجب أن يكون X مفتاحاً مرشحاً (Candidate Key)

في معظم الحالات، الجدول في 3NF يكون أيضاً في BCNF. لكن هناك حالات نادرة حيث يكون الجدول في 3NF لكن ليس في BCNF.

مثال: جدول في 3NF لكن ليس في BCNF
❌ جدول في 3NF لكن ينتهك BCNF 
-- جدول حجوزات القاعات الدراسية
CREATE TABLE room_bookings (
    student_id INT,
    time_slot VARCHAR(20),
    room_number VARCHAR(10),
    professor VARCHAR(100),
    PRIMARY KEY (student_id, time_slot)
);

-- القاعدة: كل أستاذ يستخدم قاعة واحدة فقط في كل فترة زمنية
-- أي: professor → room_number (لكن professor ليس مفتاحاً)
الحل: تحويل إلى BCNF
✅ جداول محققة لـ BCNF 
-- جدول 1: ربط الأستاذ بالقاعة والوقت
CREATE TABLE professor_schedule (
    professor VARCHAR(100),
    time_slot VARCHAR(20),
    room_number VARCHAR(10),
    PRIMARY KEY (professor, time_slot)
);

-- جدول 2: ربط الطالب بالأستاذ والوقت
CREATE TABLE student_bookings (
    student_id INT,
    time_slot VARCHAR(20),
    professor VARCHAR(100),
    PRIMARY KEY (student_id, time_slot),
    FOREIGN KEY (professor, time_slot) 
        REFERENCES professor_schedule(professor, time_slot)
);

7. مثال عملي شامل: تطبيع نظام مكتبة

لنطبق عملية التطبيع الكاملة على مثال واقعي: نظام إدارة مكتبة.

الجدول الأصلي (غير مطبع)
❌ جدول واحد يحتوي على كل شيء (غير مطبع) 
CREATE TABLE library_data (
    borrowing_id INT,
    member_id INT,
    member_name VARCHAR(100),
    member_email VARCHAR(100),
    member_phone VARCHAR(20),
    book_id INT,
    book_title VARCHAR(200),
    book_authors VARCHAR(500),  -- عدة مؤلفين مفصولين بفاصلة
    publisher_id INT,
    publisher_name VARCHAR(100),
    publisher_city VARCHAR(100),
    borrow_date DATE,
    return_date DATE
);
بعد التطبيع الكامل (3NF)
✅ قاعدة بيانات مطبعة بالكامل (3NF) 
-- 1. جدول الأعضاء
CREATE TABLE members (
    member_id INT PRIMARY KEY AUTO_INCREMENT,
    member_name VARCHAR(100) NOT NULL,
    member_email VARCHAR(100) NOT NULL UNIQUE,
    member_phone VARCHAR(20)
);

-- 2. جدول الناشرين
CREATE TABLE publishers (
    publisher_id INT PRIMARY KEY AUTO_INCREMENT,
    publisher_name VARCHAR(100) NOT NULL,
    publisher_city VARCHAR(100)
);

-- 3. جدول الكتب
CREATE TABLE books (
    book_id INT PRIMARY KEY AUTO_INCREMENT,
    book_title VARCHAR(200) NOT NULL,
    publisher_id INT,
    FOREIGN KEY (publisher_id) REFERENCES publishers(publisher_id)
);

-- 4. جدول المؤلفين
CREATE TABLE authors (
    author_id INT PRIMARY KEY AUTO_INCREMENT,
    author_name VARCHAR(100) NOT NULL
);

-- 5. جدول ربط الكتب بالمؤلفين (علاقة Many-to-Many)
CREATE TABLE book_authors (
    book_id INT,
    author_id INT,
    PRIMARY KEY (book_id, author_id),
    FOREIGN KEY (book_id) REFERENCES books(book_id),
    FOREIGN KEY (author_id) REFERENCES authors(author_id)
);

-- 6. جدول الاستعارات
CREATE TABLE borrowings (
    borrowing_id INT PRIMARY KEY AUTO_INCREMENT,
    member_id INT NOT NULL,
    book_id INT NOT NULL,
    borrow_date DATE NOT NULL,
    return_date DATE,
    FOREIGN KEY (member_id) REFERENCES members(member_id),
    FOREIGN KEY (book_id) REFERENCES books(book_id)
);

8. متى نتوقف عن التطبيع؟ (Denormalization)

رغم أن التطبيع مهم جداً، إلا أن التطبيع الزائد قد يؤدي إلى مشاكل في الأداء. في بعض الحالات، قد نحتاج إلى "إلغاء التطبيع" (Denormalization) عمداً لتحسين الأداء.

متى نستخدم Denormalization؟
  • التقارير والتحليلات: عندما تحتاج لاستعلامات معقدة تجمع بيانات من جداول كثيرة
  • البيانات المقروءة بكثرة: إذا كانت البيانات تُقرأ أكثر بكثير مما تُحدّث
  • تحسين الأداء: عندما يكون الأداء أهم من توفير المساحة
  • Data Warehouses: في مستودعات البيانات الضخمة
التوازن هو المفتاح

في معظم التطبيقات، الوصول إلى 3NF يكون كافياً. لا تبالغ في التطبيع إلى درجة تعقيد الاستعلامات، ولا تتجاهل التطبيع تماماً. ابحث عن التوازن المناسب لمشروعك.

9. فوائد التطبيع

الفوائد
  • تقليل تكرار البيانات
  • توفير المساحة التخزينية
  • تحسين سلامة البيانات
  • تسهيل الصيانة والتحديثات
  • منع الشذوذ في البيانات
  • تحسين الأمان (فصل البيانات الحساسة)
  • مرونة أكبر في التطوير المستقبلي
العيوب المحتملة
  • زيادة عدد الجداول
  • استعلامات أكثر تعقيداً (JOINs)
  • قد يؤثر على الأداء في بعض الحالات
  • يتطلب تخطيطاً دقيقاً
  • منحنى تعلم أعلى للمبتدئين
ملخص الدرس

في هذا الدرس الشامل، تعلمنا عملية التطبيع (Normalization) وأهميتها في تصميم قواعد بيانات منظمة وفعالة:

  • 1NF: إزالة القيم المتعددة والمجموعات المتكررة
  • 2NF: إزالة التبعيات الجزئية
  • 3NF: إزالة التبعيات الانتقالية
  • BCNF: نسخة أقوى من 3NF

التطبيع ليس مجرد نظرية أكاديمية، بل هو مهارة عملية أساسية لأي مصمم قواعد بيانات محترف. قاعدة البيانات المطبعة بشكل صحيح توفر عليك الكثير من المشاكل في المستقبل.

الخطوة التالية: الفهارس (Indexes)

أكمل رحلتك التعليمية وانتقل إلى الدرس التالي لتعلم الفهارس (Indexes) وتطوير مهاراتك في قواعد البيانات.

الانتقال إلى الدرس التالي
السابق التالي
المحرر الذكي

اكتب الكود وشاهد النتيجة فوراً

جرب الآن مجاناً
قناة ديف عربي

تابع أحدث الدروس والتحديثات مباشرة على واتساب

انضم الآن