التبعية متعدية في قاعدة البيانات

التبعية متعدية في قاعدة بيانات هي علاقة غير مباشرة بين القيم في نفس الجدول الذي يسبب تبعية وظيفية. لتحقيق معيار التطبيع للنموذج Normal III (3NF) ، يجب إزالة أي تبعية متعدية.

وبحكم طبيعتها ، يتطلب التبعية متعدية ثلاثة أو أكثر من السمات (أو أعمدة قاعدة البيانات) التي لها تبعية وظيفية بينها ، وهذا يعني أن العمود A في الجدول يعتمد على العمود B خلال عمود وسيط C.

دعونا نرى كيف قد يعمل هذا.

مثال تبعية متعدية

المؤلفون

Author_ID	مؤلف	كتاب	Author_Nationality
Auth_001	أورسون سكوت كارد	لعبة اندر ل	الولايات المتحدة الامريكانية
Auth_001	أورسون سكوت كارد	لعبة اندر ل	الولايات المتحدة الامريكانية
Auth_002	مارجريت اتوود	حكاية خادمة	كندا

في المثال AUTHORS أعلاه:

• كتاب → مؤلف : هنا ، كتاب تحدد السمة مؤلف صفة، عزا. إذا كنت تعرف اسم الكتاب ، يمكنك معرفة اسم المؤلف. ومع ذلك، مؤلف لا يحدد كتاب لأن المؤلف يمكنه كتابة عدة كتب. على سبيل المثال ، لمجرد معرفة اسم المؤلف Orson Scott Card ، لا نزال لا نعرف اسم الكتاب.
• مؤلف → Author_Nationality : وبالمثل ، فإن مؤلف تحدد السمة Author_Nationality ، ولكن ليس العكس؛ فقط لأننا نعرف أن الجنسية لا تعني أنه يمكننا تحديد المؤلف.

لكن هذا الجدول يقدم تبعية متعدية:

• كتاب → Author_Nationality: إذا كنا نعرف اسم الكتاب ، فيمكننا تحديد الجنسية عبر عمود المؤلف.

تجنب التبعيات متعدية

لضمان النموذج العادي الثالث ، دعنا نزيل التبعية متعدية.

يمكننا البدء عن طريق إزالة عمود الكتاب من جدول الكتاب وإنشاء جدول كتب منفصل:

BOOKS

Book_ID	كتاب	Author_ID
Book_001	لعبة اندر ل	Auth_001
Book_001	أطفال العقل	Auth_001
Book_002	حكاية خادمة	Auth_002

المؤلفون

Author_ID	مؤلف	Author_Nationality
Auth_001	أورسون سكوت كارد	الولايات المتحدة الامريكانية
Auth_002	مارجريت اتوود	كندا

هل هذا حلها؟ لنفحص اعتمادياتنا الآن:

كتب الجدول:

• Book_ID → كتاب: ال كتاب يعتمد على Book_ID .
• لا توجد تبعية أخرى في هذا الجدول ، لذلك نحن بخير. لاحظ أن المفتاح الخارجي Author_ID يربط هذا الجدول بجدول AUTHORS من خلال مفتاحه الأساسي Author_ID . لقد أنشأنا علاقة لتجنب التبعية متعدية ، وهو تصميم رئيسي لقواعد البيانات العلائقية.

جدول AUTHORS:

• Author_ID → مؤلف: ال مؤلف يعتمد على Author_ID .
• مؤلف → Author_Nationality: يمكن تحديد الجنسية من قبل المؤلف.
• Author_ID → Author_Nationality: الجنسية يمكن تحديدها من Author_ID عبر ال مؤلف صفة، عزا. لا يزال لدينا اعتمادية متعدية.

نحتاج إلى إضافة جدول ثالث لتطبيع هذه البيانات:

بلدان

Country_ID	بلد
Coun_001	الولايات المتحدة الامريكانية
Coun_002	كندا

المؤلفون

Author_ID	مؤلف	Country_ID
Auth_001	أورسون سكوت كارد	Coun_001
Auth_002	مارجريت اتوود	Coun_002

الآن لدينا ثلاثة جداول ، مع استخدام مفاتيح خارجية للربط بين الجداول:

• المفتاح الخارجي لجدول BOOK Author_ID يربط كتابًا بمؤلف في جدول AUTHORS.
• المفتاح الخارجي لجدول AUTHORS Country_ID يربط المؤلف ببلد في جدول COUNTRIES.
• لا يحتوي جدول COUNTRIES على أي مفتاح خارجي لأنه لا يحتاج إلى الارتباط بجدول آخر في هذا التصميم.

لماذا التبعيات متعدية هي تصميم قاعدة بيانات سيئة

ما هي قيمة تجنب التبعيات متعدية للمساعدة في ضمان 3NF؟ دعنا نفكر في الجدول الأول مرة أخرى ونرى المشكلات التي ينشئها:

المؤلفون

Author_ID	مؤلف	كتاب	Author_Nationality
Auth_001	أورسون سكوت كارد	لعبة اندر ل	الولايات المتحدة الامريكانية
Auth_001	أورسون سكوت كارد	أطفال العقل	الولايات المتحدة الامريكانية
Auth_002	مارجريت اتوود	حكاية خادمة	كندا

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

• إذا حذفت كتابين "أطفال العقل" و "لعبة أندر" ، فستحذف مؤلف "أورسون سكوت كارد" وجنسيته من قاعدة البيانات بالكامل.
• لا يمكنك إضافة مؤلف جديد إلى قاعدة البيانات إلا إذا قمت بإضافة كتاب أيضاً. ماذا لو أن المؤلف لم يتم نشره بعد أو أنك لا تعرف اسم الكتاب الذي قام بتأليفه؟
• إذا غيرت "Orson Scott Card" جنسيته ، فسيتعين عليك تغييرها في جميع السجلات التي يظهر فيها. يمكن أن يؤدي وجود سجلات متعددة مع نفس المؤلف إلى بيانات غير دقيقة: ماذا لو لم يدرك شخص إدخال البيانات وجود سجلات متعددة له وتغيير البيانات في سجل واحد فقط؟
• لا يمكنك حذف كتاب مثل "The Handmaid's Tale" دون حذف المؤلف تمامًا.

هذه ليست سوى بعض الأسباب التي تجعل التطبيع ، وتجنب التبعيات متعدية ، وحماية البيانات وضمان الاتساق.