تخيل العمل مع قاعدة بيانات غير منظمة ضخمة مليئة بالمعلومات المتكررة والزائدة. كل تحديث أو حذف يمكن أن يصبح كارثة محتملة، مع خطر الأخطاء وعدم التناسق. الصيغة الطبيعية الثالثة (3NF) هي طريقة مثبتة لتطوير قاعدة البيانات لتجنب هذا الفوضى. تنفيذ 3NF ينظف هيكل بياناتك، مضمنًا أن يكون فعالًا ومنظمًا وخاليًا من التكرارات الغير ضرورية.
في هذه المقالة، سنستكشف كيفية عمل 3NF، ولماذا هو قيم، وكيف يمكنك تطبيقه. كما سنقارن 3NF بالأشكال الأخرى ونتعلم متى يجب استخدام كل واحدة. الجميع يمكن أن يستفيد من معرفة المزيد حول هذه الهياكل، ولكن هذه المعرفة قيمة بشكل خاص إذا كنت مصمم قواعد بيانات أو عالم بيانات، حيث يمكن أن تبسط بشكل كبير عملك وتجعل قواعد البيانات الخاصة بك موثوقة. إذا كنت مهتمًا بتصميم قواعد البيانات بشكل عام، فتحقق من دورتنا الكاملة حول تصميم قواعد البيانات.
تعريف الصيغة الطبيعية الثالثة (3NF)
الشكل الطبيعي الثالث هو مفهوم رئيسي في تطوير قواعد البيانات الذي يزيل التبعيات غير المرغوب فيها. يعتمد الشكل الثالث على الشكل الطبيعي الأول (1NF) والشكل الطبيعي الثاني (2NF)، مما يعني أنه يرث قواعدهم: يتطلب الشكل الأول الذري (الغير قابل للتقسيم) للقيم في كل خلية، ويقوم الشكل الثاني بإزالة التبعيات الجزئية عن مفتاح أساسي مركب. يأخذ الشكل الثالث ذلك بعيدًا عن طريق إزالة التبعيات النقلية، وهو الوضع الذي تعتمد فيه السمات غير المفتاحية بشكل غير مباشر على المفتاح الأساسي.
من خلال التركيز على هذا الأمر، يضمن الشكل الثالث أن يكون كل عمود غير مفتاحي في الجدول مرتبطًا مباشرة بالمفتاح الأساسي ولا شيء آخر. وبمصطلحات عملية أكثر، يساعد الشكل الثالث في تقليل التكرار وتجنب الشوائب عند إدراج البيانات أو تحديثها أو حذفها.
في السبعينيات، قدم إدغار إف. كود الشكل الثالث لتنظيم شروط تحقيق هيكل قاعدة بيانات مُنقح بالكامل. وبعد بضع سنوات، قدم كارلو زانيولو إعادة صياغة تقدير أوضح للفرق بين الشكل الثالث “الكلاسيكي” وشكل بويس-كود الأكثر تقييدًا. لا داعي للقلق كثيرًا بشأن شكل بويس-كود الآن، سنعود إليه لاحقًا.
فهم شروط الشكل الطبيعي الثالث
ما الذي يتطلبه بالضبط لتحقيق 3NF؟ لكي تأهل الجدول، يحتاج إلى استيفاء بعض الشروط:
- أن يكون في 2NF: وهذا يعني أنه بالفعل ذري، دون مجموعات متكررة ودون الاعتماد الجزئي على أي مفاتيح مركبة.
3NF تشمل 2NF و 1NF. صورة من تأليف المؤلف
- لا يوجد اعتماد انتقالي: هذه القاعدة هي المفتاح. في جدول 3NF، يجب أن يعتمد أي عمود غير مفتاح أساسي فقط على المفتاح الأساسي، وليس بشكل غير مباشر من خلال عمود غير مفتاح آخر.
دعونا نلقي نظرة على ما يعني ذلك عمليًا.
تقسيم الجداول لتحقيق الصيغة الطبيعية الثالثة
لنتابع عملية تقسيم الجداول للوصول إلى الصيغة الطبيعية الثالثة. سنستخدم بيانات عينية من دورات DataCamp لتوضيح كل خطوة.
الخطوة 1: تحديد التبعيات الناقلة
للبدء، سنبحث عن أي سمات في جدول تعتمد بشكل غير مباشر على المفتاح الأساسي. كقاعدة عامة، إذا كانت أي سمة تعتمد على شيء غير المفتاح الأساسي، فهذا يشير إلى التبعية الناقلة. هذا إشارة إلى أنه ربما حان الوقت لتقسيم الجدول الخاص بك.
انظر إلى الجداول الثلاثة أدناه. أيها يحتوي على تبعية عابرة؟
الجدول 1: الدورة
| Course ID | Course Name | Difficulty |
|---|---|---|
| 201 | أساسيات SQL | مبتدئ |
| 202 | مقدمة لبايثون | مبتدئ |
| 203 | فهم علوم البيانات | متوسط |
الجدول 2: المدرب
| Instructor ID | Instructor Name | Expertise |
|---|---|---|
| 1 | سارة جونسون | علوم البيانات |
| 2 | توم ويليامز | تعلم الآلة |
| 3 | إميلي براون | بايثون |
الجدول 3: التسجيلات
| Enrollment ID | Student Name | Course ID | Course Name |
|---|---|---|---|
| 1001 | Alice Smith | 201 | SQL الأساسيات |
| 1002 | Bob Green | 202 | مقدمة إلى Python |
| 1003 | Charlie Blue | 201 | SQL الأساسيات |
الجواب هو… الجدول 3!
في هذه الجدول، اسم الدورة يعتمد على معرّف الدورة، ولكن ليس بشكل مباشر على معرّف التسجيل (المفتاح الأساسي). هذه التبعية غير المباشرة تجعل اسم الدورة تبعية انتقالية.
الخطوة 2: فصل البيانات إلى جداول جديدة
لمعالجة التبعية العابرة، سنقوم بتقسيم الجدول 1 إلى جدولين. سيتم التركيز في كل جدول على البيانات المعتمدة مباشرة.
جدول التسجيل المعدل
| Enrollment ID | Student Name | Course ID |
|---|---|---|
| 1001 | أليس سميث | 201 |
| 1002 | بوب جرين | 202 |
| 1003 | تشارلي بلو | 201 |
جدول الدورات
| Course ID | Course Name |
|---|---|
| 201 | أساسيات SQL |
| 202 | مقدمة للبايثون |
الآن، تحتوي كل جدول على معلومات تعتمد مباشرة على مفتاحه الرئيسي: معرف الدورة هو الآن المفتاح الرئيسي لـ اسم الدورة في جدول الدورات، و معرف التسجيل هو المفتاح الرئيسي في جدول التسجيلات.
بهذا التقسيم، تلبي الجداول الآن متطلبات 3NF، محدثة الزيادة وضمان أن كل جدول يخزن معلومات ذات صلة مباشرة فقط.
إذا كنت ترغب في البدء وإنشاء قواعد بيانات خاصة بك، فتحقق من دورتنا إنشاء قواعد بيانات PostgreSQL. إذا كنت تتقدم قليلاً، يمكنك أن تجرب مقدمة لنمذجة البيانات في Snowflake، التي تغطي أفكارًا مثل نمذجة الكيانات والعلاقات والأبعاد.
فوائد وقيود استخدام الشكل الطبيعي الثالث
إذن، لماذا تبذل كل هذه الجهود للوصول إلى 3NF؟ إليك أهم المزايا:
- تحسين سلامة البيانات: من خلال القضاء على التبعيات العابرة، يساعد الشكل الطبيعي الثالث على ضمان أن التحديثات والحذف لا تؤدي إلى بيانات متضاربة أو قديمة عبر الجداول.
- تقليل التكرار: الحد من التكرار يعني أن قاعدة البيانات الخاصة بك أسهل في الصيانة، ويتم تقليل استخدام التخزين.
- تبسيط صيانة البيانات: الاحتفاظ بالمعلومات المماثلة في الجداول المخصصة يجعل من السهل تحديث السجلات دون الحاجة إلى تتبع الإدخالات المتكررة.
مع ذلك، بينما تدعم هياكل 3NF دقة البيانات، يمكن أن تؤدي أيضًا إلى بيانات أكثر تجزئة، مما يجعل الاستعلامات المعقدة أبطأ في بعض الأحيان بسبب الانضمامات الإضافية للجداول. في الحالات التي تتفوق فيها الحاجة إلى السرعة على الحاجة إلى التطبيع، قد تكون BCNF أو 4NF خيارات أكثر عملية.
المقارنة: الأشكال العادية الأولى والثانية والثالثة و BC Normal Forms
لنلقِ نظرة على الفروقات بين الأشكال.
جدول المقارنة: الأشكال العادية الأولى والثانية والثالثة
إليك جدول مقارنة لمساعدتك في فهم متطلبات 1NF و 2NF و 3NF.
| Feature | 1NF | 2NF | 3NF |
|---|---|---|---|
| بيانات ذرية | ✅ | ✅ | ✅ |
| لا توجد اعتماديات جزئية | ❌ | ✅ | ✅ |
| لا توجد اعتماديات انتقالية | ❌ | ❌ | ✅ |
الشكل العادي الثالث مقابل الشكل العادي لبويس-كود (BCNF)
BCNF هو شكل “أكثر صرامة” من 3NF الذي يقضي بشكل أكبر على الشذوذات التي تظهر مع تداخل المفاتيح المرشحة. يمكن أن يكون مفيدًا بشكل خاص في الحالات المعقدة حيث لا يقضي 3NF بمفرده على الاعتماديات بشكل كامل. ينطبق BCNF عندما يعتمد سمة غير أساسية على سمة هي جزء من مفتاح مرشح مركب. أعلم أن هذا يبدو معقدًا، لذا دعونا نفصل الأمر بمثال.
الهيكل الحالي (في 3NF)
بعد التحليل لتحقيق 3NF، كان لدينا هذين الجدولين:
جدول التسجيلات
| Enrollment ID | Student Name | Course ID |
|---|---|---|
| 1001 | أليس سميث | 201 |
| 1002 | بوب غرين | 202 |
| 1003 | تشارلي بلو | 201 |
جدول الدورات
| Course ID | Course Name |
|---|---|
| 201 | أساسيات SQL |
| 202 | مقدمة إلى بايثون |
في هذا الهيكل، كل جدول في 3NF بدون تبعيات انتقالية، والبيانات تم تطبيعها بشكل مناسب.
تقديم متطلب جديد
الآن، دعنا نضيف سمة جديدة إلى الدورات: الفصل الدراسي الذي تُعقد فيه كل دورة. هذه السمة الجديدة قد تؤدي إلى سيناريو يتطلب BCNF.
الجدول المحدث للدورات (3NF)
| Course ID | Course Name | Classroom |
|---|---|---|
| 201 | أساسيات SQL | الغرفة 101 |
| 202 | مقدمة للبايثون | الغرفة 102 |
| 203 | فهم علم البيانات | الغرفة 101 |
هنا، معرف الدورة هو لا يزال المفتاح الأساسي، وجميع السمات الأخرى تعتمد مباشرة عليه. ولكن دعونا نفترض وجود قاعدة جديدة تنص على أن كل فصل يمكنه استيعاب مادة واحدة في وقت واحد. دعونا نفترض أيضًا أن اسم الدورة “SQL Fundamentals” يمكن أن يُقدم تحت مُعرفات دورة مختلفة (مثل 201، 204، إلخ)، إذا تم جدولتها في أوقات مختلفة. في هذه الحالة، سيتم إقامة كل عرض لـ “SQL Fundamentals” في “الغرفة 101″، بغض النظر عن معرف الدورة الخاص بها. ونتيجة لذلك، يُحدد اسم الدورة بشكل فريد أيضًا الفصل.
هذا يعني أن لدينا الآن مفاتيح مرشحة اثنتان:
- معرف الدورة
- اسم الدورة
بعد الحصول على مفاتيح المرشحين الاثنين، نواجه الآن مشكلة لا يعالجها الشكل العام الثالث: الفصل الدراسييعتمد على اسم الدورة بدلاً من فقط معرف الدورة.
تطبيق BCNF
للتخلص من مشكلة التبعية هذه، سيتعين علينا تقسيم جدول الدورات إلى جدولين منفصلين يتناسبان أكثر مع BCNF:
- جدول جديد الدورات, الذي يتضمن فقط معرف الدورة و اسم الدورة.
- جدولتفاصيل الدورة، الذي يخزناسم الدورة والفصل الدراسي المرتبط.
هكذا يبدو ذلك:
جدول الدورات المنقح (BCNF)
| Course ID | Course Name |
|---|---|
| 201 | أساسيات SQL |
| 202 | مقدمة في بايثون |
| 203 | فهم علم البيانات |
جدول تفاصيل الدورة (BCNF)
| Course Name | Classroom |
|---|---|
| أساسيات SQL | الغرفة 101 |
| مقدمة في بايثون | الغرفة 102 |
| فهم علم البيانات | الغرفة 101 |
مع هذا الهيكل الجديد، تلبي كل جدول شروط BCNF:
- في جدول الدورات، معرّف الدورة هو المفتاح الأساسي، وتعتمد جميع السمات فقط عليه.
- في الCourseDetails جدول اسم الدورة هو المفتاح الأساسي، و الصف يعتمد فقط على اسم الدورة.
تعمل هذه الإعدادات على إزالة أي مشاكل تعتمد على المفاتيح المرشحة المتداخلة، مما يضمن هيكلًا مُنظمًا بشكل صارم.
الخاتمة
يعتبر الشكل الطبيعي الثالث أداة قيمة لمصممي قواعد البيانات الذين يهدفون إلى الحفاظ على البيانات نظيفة ومتسقة وخالية من الاعتماديات الإشكالية. مع 3NF، يتم تعزيز سلامة البيانات، مما يجعل الإدارة أكثر سلاسة ويقلل من الازدواجية. تذكر، بينما يعمل 3NF بشكل جيد في معظم الحالات، قد تستفيد قواعد البيانات الأكثر تعقيدًا من أشكال إضافية مثل BCNF أو 4NF.
إذا وجدت هذه المقالة مفيدة، فكر في اتخاذ الخطوة التالية من خلال الحصول على شهادة مساعد SQL. إنها طريقة رائعة للتحقق من مهاراتك في SQL وإدارة قواعد البيانات وإظهار خبرتك لأرباب العمل المحتملين!