تصميم قواعد البيانات نمذجة الكيان العلاقي ER عند تصميم قواعد البيانات

تتضمن إحدى النظريات المهمة التي طُوِّرت لنموذج الكيان العلاقي entity relational -واختصارًا ER- فكرة الاعتمادية الوظيفية functional dependency -أو FD اختصارًا-، والهدف من دراستها هو تحسين فهمك للعلاقات بين البيانات، واكتساب المنهجية الكافية للمساعدة في التصميم العملي لقاعدة البيانات.

تُستخلَص الاعتماديات الوظيفية FD من دلالات semantics نطاق التطبيق، أي مثل القيود constraints التي شرحناها في المقال السابق، وتصِف كيفية ارتباط السمات المنفصلة individual attributes ببعضها البعض، كما تُعَدّ الاعتماديات الوظيفية FD نوعًا من القيود بين السمات داخل علاقة، وتساهم في تصميم مخطط علاقي جيد، حيث سنلقي في هذا المقال نظرةً على:

• نظرية الاعتمادية الوظيفية الأساسية وتعريفها.
• منهجية تحسين تصميمات المخططات، وتسمى أيضًا التوحيد normalization.

التصميم العلاقي Relational Design والتكرار Redundancy

يجب احتواء التصميم الجيد لقاعدة البيانات العلاقية على جميع السمات والارتباطات الضرورية، حيث يجب أن يقوم التصميم بذلك بأقل قدرٍ ممكن من المعلومات المخزَّنة مع عدم وجود بيانات مكرَّرة redundant.

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

ضع في بالك الشكل الآتي الذي يوضِّح مثالًا عن التكرار المُستخدَم في الحسابات المصرفية Bank Accounts، وفروع المصرف Branches، حيث يَظهر العميل رقم 1313131 مرتين، أي مرةً للحساب ذو الرقم A-101، ومرةً أخرى للحساب رقم A-102؛ إذ لا يكون رقم العميل زائدًا في هذه الحالة على الرغم من وجود حالات حذفٍ شاذة deletion anomalies في الجدول، وسيحل هذه المشكلة وجود جدول منفصل للعملاء.

إذا تغير عنوان الفرع branch address، فيجب تحديثه في أماكن متعددة، وإذا تُرِك رقم العميل في الجدول كما هو، فلن تحتاج إلى جدول للفرع branch، ولن تكون هناك حاجة إلى عملية ضم، وبالتالي، سيتحسّن الأداء.

التعديلات الشاذة على جداول قاعدة البيانات

سنعرض أشهر الحالات الشاذة التي تحدث نتيجة إجراء تعديلات من إدخل أو تعديل أو حذف على قاعدة البيانات كما سنضرب مثالًا لذلك.

حالة الإدخال الشاذة Insertion Anomaly

تحدث هذه الحالة عند إدخال معلومات متضاربة في جدول، حيث نحتاج إلى التحقق من أن بيانات الفرع branch متوافقة مع الصفوف الموجودة عندما ندخل سجلًا جديدًا مثل رقم الحساب A-306، كما في الشكل التالي:

حالة التحديث الشاذة Update Anomaly

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

حالة الحذف الشاذة Deletion Anomaly

تحدث هذه الحالة عند حذف سجل قد يحتوي على سمات لا ينبغي حذفها، إذا أزلنا معلومات حول الحساب الأخير في أحد الفروع، مثل الحساب رقم A-101 في الفرع داون تاون Downtown في الشكل التالي على سبيل المثال، فستختفي جميع معلومات ذلك الفرع.

مشكلة حذف الصف A-101 هي عدم معرفتنا مكان الفرع Downtown، وأننا سنفقد جميع المعلومات المتعلقة بالعميل 1313131.

نحتاج إلى تفكيك الجدول الأصلي إلى جداول أصغر متعددة بحيث يكون لكل جدول حدًا أدنى من التداخل مع الجداول الأخرى، وذلك لتجنب هذه الأنواع من مشاكل التحديث أو الحذف.

يجب احتواء كل جدول حساب مصرفي على معلومات حول كيان entity واحد فقط، مثل: الفرع Branch، أو العميل Customer، كما هو موضح في الشكل التالي:

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

مثال تطبيقي عن جدول مشروع-موظف والحالات الشاذة

يوضِّح الشكل الآتي مثالًا لجدول مشروع-موظف employee project table، كما يمكننا الافتراض من هذا الجدول أن:

1. معرِّف الموظف EmpID، ومعرِّف المشروع ProjectID هما مفتاح رئيسي مركَّب composite PK.
2. يحدد معرِّف المشروع الميزانية Budget، أي أنّ للمشروع P1 ميزانيةً لفترة 32 ساعة.

فيما يلي بعض الحالات الشاذة anomalies المحتملة التي قد تحدث مع هذا الجدول خلال الخطوات التالية:

1. الإجراء: إضافة الصف Add row الذي هو {S85,35,P1,9}.
2. المشكلة: هناك صفان tuples بميزانيات متضاربة.
3. الإجراء: حذف الصف Delete tuple الذي هو {S79, 27, P3, 1}.
4. المشكلة: الخطوة رقم 3 تحذف ميزانية المشروع P3.
5. الإجراء: تحديث الصف Update tuple من {S75, 32, P1, 7} إلى {S75, 35, P1, 7}.
6. المشكلة: تُنشِئ الخطوة رقم 5 صفَّين بقيم مختلفة لميزانية المشروع P1.
7. الحل: إنشاء جدول منفصل separate table لكل من المشاريع Projects والموظفين Employees، أي كما هو موضَّح في الشكل التالي:

كيفية تجنب الحالات الشاذة

أفضل طريقة لإنشاء جداول بدون حالات شاذة هي التأكد من توحيد الجداول، ويتحقق ذلك من خلال فهم الاعتماديات الوظيفية، حيث تضمن الاعتمادية الوظيفية FD في جدول انتماء جميع السمات attributes إلى هذا الجدول، أي ستزيل التكرار والحالات الشاذة.

مثال تطبيقي: جدولا المشاريع والموظفين المنفصلان

جدول المشروع Project

جدول الموظف Employee

يكون من خلال الاحتفاظ بالبيانات منفصلة باستخدام جدول مشاريع وجدول موظفين ما يلي:

• لن تُنشَأ حالات شاذة إذا تغيرت الميزانية.
• ليست هناك حاجة إلى قيم وهمية للمشاريع التي لم يُعيَّن لها موظفون.
• إذا حُذِفت مساهمة موظف ما، فلن تُفقَد بيانات مهمة.
• لن تُنشَأ حالات شاذة إذا أُضيفت مساهمة موظف.

تمارين

أولًا، طبِّق التوحيد normalization على الشكل التالي:

ثانيًا، أنشِئ مخطط ERD منطقي لخدمة تأجير الأفلام عبر الإنترنت، حيث لا توجد علاقات من النوع متعدد إلى متعدد many to many، واستخدم الوصف التالي للعمليات التي يجب أن تستند عليها قواعد عملك:

تُصنِّف خدمة تأجير الأفلام عبر الإنترنت عناوين الأفلام وفقًا لنوعها إلى: الأفلام الكوميدية comedy، وأفلام الغرب الأمريكي western، والأفلام الكلاسيكية classical، وأفلام الخيال العلمي science fiction، وأفلام الرسوم المتحركة cartoon، وأفلام الحركة action، والأفلام الموسيقية musical، والأفلام المصدرة حديثًا new release.

يحتوي كل نوع على العديد من العناوين المحتملة، وتتوفر نسخ copies متعددة لمعظم العناوين داخل النوع، فمثلًا، لاحظ الملخَّص التالي:

• TYPE TITLE
• Musical My Fair Lady (Copy 1)
• My Fair Lady (Copy 2)
• Oklahoma (Copy 1)
• Oklahoma (Copy 2)
• Oklahoma (Copy 3)

ثالثًا، ما هي الحالات الشاذة الثلاثة للبيانات التي من المحتمل تَشكّلها نتيجةً لتكرار البيانات؟ وكيف يمكن القضاء على مثل هذه الحالات الشاذة؟

وسنتطرق في مقال لاحق لمثال عملي حول تصميم قاعدة بيانات كاملة من الصفر مثل تدريب عملي.

ترجمة -وبتصرف- للمقال ER Modelling لصاحبته Adrienne Watt من كتاب Database Design.

اقرأ أيضًا

• المقال التالي: الاعتماديات الوظيفية المستخدمة في تصميم قواعد البيانات
• المقال السابق: قواعد السلامة وقيودها لضمان سلامة البيانات في قواعد البيانات
• نموذج الكيان والعلاقة ER لتمثيل البيانات وتخزينها في قاعدة البيانات
• المفاهيم الأساسية في قواعد البيانات وتصميمها
• النسخة العربية الكاملة لكتاب تصميم قواعد البيانات