تطبيع البيانات Normalization، أساس تصميم قواعد البيانات

تخيّل أن لديك ملفًا كبيرًا لتخزين معلومات الموظفين في شركتك، وكل مرة تحاول تحديث بيانات موظف، تجد أنك مضطر لتغيير نفس المعلومة في أماكن متعددة. أو ربما تُدرك لاحقًا أن هناك أخطاء صغيرة، لكنها تكررت في كل مكان. هنا تبدأ المعاناة الحقيقية مع “فوضى البيانات”.

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

ما هو تطبيع البيانات (Normalization)؟

تطبيع البيانات (Normalization) هو عملية تنظيم جداول قاعدة البيانات بحيث:

• نقلل التكرار غير الضروري في البيانات (تكرار البيانات – Data Redundancy)،
• ونعزز تكامل المعلومات بينها (تكامل البيانات – Data Integrity)،
• ونسهّل عمليات التحديث والتوسعة مستقبلًا.

وتعتمد هذه العملية على مجموعة من القواعد المنهجية تُسمى الأشكال القياسية (Normal Forms)، وهي خطوات تدريجية نتبعها لتحسين هيكل الجداول.

لماذا نحتاج إلى التطبيع؟

عندما تُصمم قاعدة البيانات بطريقة غير منظّمة، تظهر عدة مشكلات مزعجة، منها:

• تخزين نفس البيانات أكثر من مرة، مما يهدر المساحة ويزيد فرصة وقوع الأخطاء.
• وجود معلومات مكررة لكن متضاربة، مثل اسم مدير مختلف لنفس القسم.
• صعوبة التعديل، لأن أي تغيير بسيط يتطلب التحقق من كل الصفوف المتأثرة.

الحل؟ تنظيم البيانات بعناية وفق منهجية التطبيع.

مثال من الواقع: جدول الموظفين

لنفترض أن لدينا جدولًا في قاعدة بيانات شؤون الموظفين على النحو التالي:

رقم الموظف	اسم الموظف	القسم	اسم المدير	الراتب
101	أحمد علي	الموارد البشرية	خالد عبدالله	7000
102	منى سالم	الموارد البشرية	خالد عبدالله	7000
103	خالد يوسف	تقنية المعلومات	ناصر الحربي	9000

في هذا الجدول، نلاحظ بعض الأمور:

• تكرار بيانات القسم واسم المدير. حيث تكرر ذكر قسم الموارد البشرية واسم المدير خالد عبدالله
• إذا تغير اسم المدير، سنحتاج لتعديله في كل صف يتبع هذا القسم.
• لا يوجد فصل واضح بين “الموظف” و”القسم”.

الآن، دعونا نبدأ تطبيق التطبيع خطوة بخطوة والذي يمر يثلاثو مراحل حتى تصل للصيغة النهائية وهي الثالثة.

الشكل القياسي الأول (First Normal Form – 1NF)

عندما نبدأ بتطبيق تطبيع البيانات، فإن أول محطة نقف عندها هي الشكل القياسي الأول (First Normal Form – 1NF)، وهي خطوة أساسية تمهّد الطريق لبناء قاعدة بيانات نظيفة ومنظمة.

فكرة هذا الشكل بسيطة لكنها جوهرية:
لكي نقول إن الجدول يحقق الشكل القياسي الأول، يجب أن تتحقق فيه شرطان رئيسيان:

أولاً: أن تكون كل قيمة في كل خلية ذرية (Atomic Value)

بمعنى آخر، يجب ألا تحتوي الخلية الواحدة في الجدول على أكثر من قيمة.
لا يصح أن نضع في خلية واحدة قائمة من القيم، أو مجموعة بيانات مفصولة بفواصل، أو حتى معلومات مركّبة.
فالخلية يجب أن تحتوي على قيمة واحدة فقط واضحة ومباشرة — وهذا ما يسمى بالقيمة “الذرية” أو “غير القابلة للتقسيم”.

لماذا هذا الشرط مهم؟
لأنه إذا كانت الخلية تحتوي على أكثر من قيمة، فلن نتمكن من إجراء استعلامات دقيقة، ولن نتمكن من فرز البيانات أو البحث عنها بشكل فعال.
تخيّل أنك تسأل قاعدة البيانات: “أعطني كل الموظفين الذين يعملون في قسم التقنية”، فإذا كانت الخلية تحتوي على أكثر من قسم لكل موظف، فسيصعب على النظام فهم الطلب.

ثانيًا: أن يكون هناك مفتاح أساسي (Primary Key)

وهذا المفتاح يُستخدم لتمييز كل صف عن الآخر بشكل فريد.
بمعنى أن كل سجل (صف) في الجدول يجب أن يكون قابلاً للتمييز عن أي سجل آخر، ولا يتكرر.

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

الجدول الأصلي للموظفين:

رقم الموظف	اسم الموظف	القسم	اسم المدير	الراتب
101	أحمد علي	الموارد البشرية	خالد عبدالله	7000
102	منى سالم	الموارد البشرية	خالد عبدالله	7000
103	خالد يوسف	تقنية المعلومات	ناصر الحربي	9000

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

إذن من حيث الشرط الأول، وهو أن تكون القيم ذرية — نعم، الجدول يحقق هذا الشرط.

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

✅ النتيجة:

هذا الجدول يحقق الشكل القياسي الأول (1NF)، لأنه:

• يحتوي على قيم ذرية فقط.
• ويحتوي على عمود يمكن استخدامه كمفتاح أساسي.

لكن… هل هذا يعني أن التصميم مثالي؟
ليس بعد.

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

الشكل القياسي الثاني (Second Normal Form – 2NF)

بعد أن تأكدنا أن جدولنا يحقق الشكل القياسي الأول (1NF)، وأن كل خلية تحتوي على قيمة واحدة فقط، ولدينا مفتاح أساسي يميز كل سجل — ننتقل الآن إلى المستوى التالي من التطبيع: الشكل القياسي الثاني (Second Normal Form – 2NF).

قد تظن أن الأمور أصبحت مثالية، لكن الحقيقة أن هناك مشكلة أكثر خفاءً تبدأ في الظهور عند هذه المرحلة، وهي مشكلة الاعتماد الجزئي (Partial Dependency).

فما المقصود بالاعتماد الجزئي؟

تخيّل أن لديك جدولاً يعتمد على مفتاح مركب مكوّن من أكثر من عمود (مثلاً: رقم الموظف ورقم المشروع)، لكن بعض الأعمدة في الجدول لا تعتمد على المفتاح المركب كله، بل على جزء منه فقط.
هذا يعني أن هناك علاقة غير متوازنة داخل الجدول، وكأن بعض الأعمدة تقول: “أنا لا يهمني المفتاح الكامل، أنا أرتبط فقط بجزء منه”، وهذا ما يُحدث خللاً في التصميم، ويجعل البيانات أكثر عرضة للتكرار والتضارب.

طيب، وماذا لو لم يكن هناك مفتاح مركب؟

سؤال ممتاز!
حتى إن لم يكن المفتاح مركبًا، فإن الشكل القياسي الثاني لا يهتم فقط بالمفاتيح، بل يهتم أيضًا بموقع بعض الأعمدة داخل الجدول: هل مكانها هنا منطقي فعلاً؟ وهل تعتمد هذه الأعمدة على المفتاح الأساسي أم على شيء آخر؟

دعونا نُعيد النظر في جدول الموظفين الذي أصبح على الشكل التالي بعد تطبيق الشكل الأول:

الجدول الحالي للموظفين:

رقم الموظف	اسم الموظف	القسم	اسم المدير	الراتب
101	أحمد علي	الموارد البشرية	خالد عبدالله	7000
102	منى سالم	الموارد البشرية	خالد عبدالله	7000
103	خالد يوسف	تقنية المعلومات	ناصر الحربي	9000

هنا نلاحظ أمراً مهماً:
عمود “القسم” وعمود “اسم المدير” لا يعتمدان على “رقم الموظف” مباشرة، بل يعتمدان على بعضهما البعض.

فكلما تكرر اسم القسم، يتكرر معه اسم المدير — وهذا يدل على أن العلاقة الحقيقية هي بين “القسم” و”المدير”، وليس بين “الموظف” و”المدير” مباشرة.

بعبارة أخرى:
لو أن لدينا موظفاً جديدًا انضم إلى قسم “الموارد البشرية”، فسنحتاج إلى إعادة كتابة اسم القسم واسم المدير مرة أخرى في الجدول، مع أنهما لم يتغيرا.

وهذا يفتح الباب للتكرار، بل وربما للخطأ، كأن نكتب “خالد عبدالله” مرة، و”خالد عبد الله” مرة أخرى، فيبدو كأن هناك مديرين مختلفين لنفس القسم.

الحل؟

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

إعادة هيكلة قاعدة البيانات لتحقيق 2NF:

1. جدول الموظفين:

رقم الموظف	اسم الموظف	رقم القسم	الراتب
101	أحمد علي	1	7000
102	منى سالم	1	7000
103	خالد يوسف	2	9000

2. جدول الأقسام:

رقم القسم	اسم القسم	اسم المدير
1	الموارد البشرية	خالد عبدالله
2	تقنية المعلومات	ناصر الحربي

الآن أصبح لدينا فصل منطقي بين البيانات:

• الموظف له رقم واسم وراتب ورقم القسم فقط.
• القسم له رقم واسم واسم مدير.

بهذا الشكل، إذا تغير اسم المدير لاحقًا، لن نضطر لتعديله في كل صف من جدول الموظفين، بل نعدّله فقط في جدول الأقسام، وسينعكس ذلك في كل مكان.

✅ ماذا حققنا من خلال هذا التغيير؟

• قللنا التكرار في البيانات.
• فصلنا العلاقات بطريقة أوضح.
• جعلنا قاعدة البيانات أسهل في التحديث وأقل عرضة للأخطاء.
• والأهم: أصبح كل عمود في جدول الموظفين يعتمد مباشرة على المفتاح الأساسي “رقم الموظف”، ولا شيء آخر.

لكننا لم نصل بعد إلى نهاية الرحلة… هناك مشكلة أخرى قد لا تزال قائمة، وهي الاعتماد غير المباشر أو ما يُعرف بـ الاعتماد العابر (Transitive Dependency)، وسنتعامل معها في الشكل القياسي الثالث (3NF).

الشكل القياسي الثالث (Third Normal Form – 3NF)

بعد أن أنجزنا المرحلتين السابقتين بنجاح — الشكل القياسي الأول (1NF) والثاني (2NF) — وأصبح جدول الموظفين منظمًا بطريقة تقلل التكرار وتعتمد على علاقات منطقية واضحة، حان الوقت للانتقال إلى الشكل القياسي الثالث (Third Normal Form – 3NF)، الذي يُعد خطوة مهمة جدًا للوصول إلى قاعدة بيانات قوية ومستقرة على المدى الطويل.

ورغم أن شكل الجداول قد يبدو مرتباً عند هذه المرحلة، إلا أن هناك نوعاً من “الاعتماد” يظل يختبئ في الخلفية، ولا نلاحظه إلا إذا نظرنا بتمعّن. هذا النوع من الاعتماد يُسمى الاعتماد غير المباشر (Transitive Dependency).

فما المقصود بالاعتماد غير المباشر؟

الاعتماد غير المباشر يحدث عندما تعتمد سمة (عمود) ما على المفتاح الأساسي، ولكن ليس مباشرة، بل عن طريق سمة أخرى. دعنا نُبسّط ذلك بمثال:

في جدول الأقسام الذي أنشأناه في الشكل القياسي الثاني، لدينا الأعمدة التالية:

رقم القسم	اسم القسم	اسم المدير
1	الموارد البشرية	خالد عبدالله
2	تقنية المعلومات	ناصر الحربي

هنا نلاحظ أن:

• “رقم القسم” هو المفتاح الأساسي.
• “اسم القسم” يعتمد على “رقم القسم” مباشرة، وهذا جيد.
• لكن “اسم المدير” لا يعتمد مباشرة على “رقم القسم”، بل يعتمد عليه عن طريق “اسم القسم”.

بمعنى آخر:
إذا عرفنا رقم القسم، نعرف اسم القسم؛ وإذا عرفنا اسم القسم، نعرف اسم المدير.
وبذلك، أصبح “اسم المدير” يعتمد على “رقم القسم” بطريقة غير مباشرة، وهذا هو ما نسميه الاعتماد غير المباشر (Transitive Dependency).

لماذا هذا النوع من الاعتماد مشكلة؟

لأنه يُضعف استقرار قاعدة البيانات. فلو أن قسماً معيناً تغيّر مديره، سنحتاج إلى تحديث جميع السجلات التي تتعلق بذلك القسم — تمامًا كما كانت المشكلة سابقًا قبل فصل الجداول في 2NF. بل وقد نقع في نفس الفخ مجددًا: تكرار، تناقض، أو أخطاء كتابية في اسم المدير.

والحل هنا أيضًا بسيط ومنطقي:
نقوم بفصل معلومات المدير في جدول مستقل، ونربط بين القسم والمدير من خلال رقم معرف (مثل رقم المدير).

إعادة هيكلة قاعدة البيانات لتحقيق 3NF:

1. جدول الأقسام:

رقم القسم	اسم القسم	رقم المدير
1	الموارد البشرية	201
2	تقنية المعلومات	202

2. جدول المدراء:

رقم المدير	اسم المدير
201	خالد عبدالله
202	ناصر الحربي

الآن أصبحت العلاقة بين الجداول واضحة ونظيفة:

• كل قسم يرتبط فقط بـ”رقم المدير”،
• وكل مدير له سجل مستقل يُعرّفه برقم واسمه.

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

✅ ماذا حققنا من خلال هذه الخطوة؟

• أزلنا الاعتماد غير المباشر بين “اسم المدير” و”رقم القسم”.
• قسّمنا البيانات وفق علاقات منطقية خالصة.
• أصبح كل عمود في كل جدول يعتمد فقط على المفتاح الأساسي الخاص به، وهذا هو جوهر الشكل القياسي الثالث (3NF).

تذكير سريع:

الشكل القياسي	المشكلة التي يحلها	ما تحققنا منه
1NF	تجنب القيم المركبة في الخلايا	✅ تم
2NF	إزالة الاعتماد الجزئي على جزء من المفتاح	✅ تم
3NF	إزالة الاعتماد غير المباشر على المفتاح	✅ تم

بذلك نكون قد أنشأنا بنية قاعدة بيانات نظيفة، مرنة، سهلة التحديث، وقابلة للتوسع دون خوف من تكرار أو تعارض في البيانات. ولكن، هل يعني هذا أن التطبيع هو الحل الأمثل دائمًا؟ ليس بالضرورة… وسنناقش ذلك في الخطوة التالية.

خاتمة ومراجعة لما قمنا به

في رحلة تطبيع البيانات التي خضناها سوياً، بدأنا من جدول بسيط ظاهرياً، لكن مع التدقيق اكتشفنا كمًّا من المشاكل الخفية: تكرار، تداخل غير مبرر، واعتمادات غير واضحة. خطوةً بخطوة، ومع كل شكل قياسي (1NF، ثم 2NF، ثم 3NF)، قمنا بتنظيف الجداول، وتبسيط العلاقات، وفصل المهام بين الكيانات المختلفة.

النتيجة لم تكن مجرد جداول أكثر ترتيباً — بل قاعدة بيانات قابلة للتوسعة، مرنة في التحديث، وأقل عُرضة للأخطاء والتعارضات.

لكن دعنا نكون واقعيين…

رغم كل هذه الفوائد، التطبيع ليس شيئاً نطبّقه بشكل أعمى دائماً. ففي بعض الحالات، مثل أنظمة مستودع البيانات Data Warehouse والتي منها ننتج التقارير الثقيلة أو في حالة التطبيقات التي تعتمد على سرعة القراءة، قد نُضطر إلى تخفيف درجة التطبيع (Denormalization) لاعتبارات تتعلق بالأداء.

الأمر في النهاية يتعلق بالتوازن:

• بين النظرية والممارسة،
• وبين الدقة وسرعة التنفيذ،
• وبين التصميم النظيف والأداء العملي.

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