اذهب إلى المحتوى

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


Ola Abbas

تتضمن إحدى النظريات المهمة التي طُوِّرت لنموذج الكيان العلاقي 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، ولن تكون هناك حاجة إلى عملية ضم، وبالتالي، سيتحسّن الأداء.

accountNo blance customer branch address assets
A-101 500 1313131 Downtown Brooklyn 9000000
A-102 400 1313131 Perryridge Horseneck 1700000
A-113 600 9876543 Round Hill Horseneck 8000000
A-201 900 9676543 brighton Brooklyn 7100000
A-215 700 1111111 Manus Horseneck 400000
A-222 700 1111111 Redwood Palo Alto 2100000
A-305 350 1234567 Round Hill Horseneck 8000000

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

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

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

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

accountNo blance customer branch address assets
A-101 500 1313131 Downtown Brooklyn 9000000
A-102 400 1313131 Perryridge Horseneck 1700000
A-113 600 9876543 Round Hill Horseneck 8000000
A-201 900 9676543 brighton Brooklyn 7100000
A-215 700 1111111 Manus Horseneck 400000
A-222 700 1111111 Redwood Palo Alto 2100000
A-305 350 1234567 Round Hill Horseneck 8000000

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

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

accountNo blance customer branch address assets
A-101 500 1313131 Downtown Brooklyn 9000000
A-102 400 1313131 Perryridge Horseneck 1700000
A-113 600 9876543 Round Hill Horseneck 8000000
A-201 900 9676543 brighton Brooklyn 7100000
A-215 700 1111111 Manus Horseneck 400000
A-222 700 1111111 Redwood Palo Alto 2100000
A-305 350 1234567 Round Hill Horseneck 8000000
A-306 800 1111111 Round Hill Horseneck 8000800

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

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

accountNo blance customer branch address assets
A-101 500 1313131 Downtown Brooklyn 9000000
A-102 400 1313131 Perryridge Horseneck 1700000
A-113 600 9876543 Round Hill Horseneck 8000000
A-201 900 9676543 brighton Brooklyn 7100000
A-215 700 1111111 Manus Horseneck 400000
A-222 700 1111111 Redwood Palo Alto 2100000
A-305 350 1234567 Round Hill Horseneck 8000000

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

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

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

ExamplesOfBankAccountTablesThatContainOneEntityEach.png

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

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

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

  1. معرِّف الموظف EmpID، ومعرِّف المشروع ProjectID هما مفتاح رئيسي مركَّب composite PK.
  2. يحدد معرِّف المشروع الميزانية Budget، أي أنّ للمشروع P1 ميزانيةً لفترة 32 ساعة.
EmpID Budget ProjectID Hours
S75 32 P1 7
S75 40 P2 3
S79 32 P1 4
S79 27 P3 1
S80 40 P2 5
  17 P4  

فيما يلي بعض الحالات الشاذة 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، أي كما هو موضَّح في الشكل التالي:

SeparateTablesForProjectAndEmployee.png

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

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

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

ProjectID Budeget
P1 32
P2 40
P3 27
P4 17

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

Emp ID Project ID Hours
S75 P1 7
S75 P2 3
S79 P1 4
S79 P3 1
S80 P2 5

جدول الموظف Employee

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

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

تمارين

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

Attribute Name Sample Value Sample Value Sample Value
StudentID 1 2 3
StudentName John Smith Sandy Law Sue Rogers
CourselD 2 2 3
CourseName Programming Level 1 Programming Level 1 Business
Grade 75% 61% 81%
CourseDate Jan 5th, 2014 Jan 5th, 2014 Jan 7th, 2014

ثانيًا، أنشِئ مخطط 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.

اقرأ أيضًا


تفاعل الأعضاء

أفضل التعليقات

لا توجد أية تعليقات بعد



انضم إلى النقاش

يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.

زائر
أضف تعليق

×   لقد أضفت محتوى بخط أو تنسيق مختلف.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   جرى استعادة المحتوى السابق..   امسح المحرر

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • أضف...