نمذجة البيانات ومخططات الكيانات والعلاقات

حل علاقات كثير بكثير

18 دقيقة الدرس 6 من 10

حل علاقات كثير بكثير

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

لماذا لا يمكن إبقاء علاقة كثير بكثير دون حل؟

تخيّل متجراً إلكترونياً لبيع الكتب: يمكن للعميل الواحد أن يُنشئ طلبات شراء متعددة، وكل طلب قد يحتوي على كتب متعددة. لو رسمتَ خطاً مباشراً بين Order وBook، لن تتمكن من الإجابة على أسئلة بسيطة مثل: "كم نسخة من هذا الكتاب كانت في ذلك الطلب بالذات؟" أو "ما الخصم المطبّق على هذا الصنف؟" لأنه لا يوجد عمود لتخزين هذه البيانات، ولا صف لاحتوائها.

المبدأ الأساسي: أي سمة تنتمي إلى العلاقة ذاتها — لا إلى أيٍّ من الكيانين — هي الإشارة الأوضح على الحاجة إلى كيان وسيط. إذا لم تستطع تحديد الجدول الذي تنتمي إليه سمة ما، فهي على الأرجح تنتمي إلى الكيان الوسيط.

قبل الحل: علاقة كثير بكثير الخام

يوضح المخطط أدناه سيناريو عيادة طبية قبل حل العلاقة. يمكن للمريض Patient حجز مواعيد مع عدة أطباء Doctor، كما يمكن للطبيب استقبال مرضى متعددين. تُشير رموز "أقدام الغراب" على كلا الطرفين إلى أن العلاقة من نوع كثير بكثير (M:N).

Unresolved many-to-many between Patient and Doctor Patient PK patientID fullName dateOfBirth phone Doctor PK doctorID fullName specialty phone books M N
قبل الحل: علاقة كثير بكثير مباشرة بين المريض والطبيب — صالحة في النموذج المنطقي، لكن لا يمكن تنفيذها في قاعدة بيانات علائقية.

بعد الحل: إدخال الكيان الوسيط

لحل العلاقة، نُزيل خط M:N ونُدخل كياناً جديداً — Appointment — يقع بين Patient وDoctor. يحمل الكيان الوسيط:

  • مفتاح خارجي يربطه بالمريض (patientID) — أحد طرفي الزوج الأصلي.
  • مفتاح خارجي يربطه بالطبيب (doctorID) — الطرف الآخر.
  • مفتاح أساسي مركّب مكوّن من كلا المفتاحين الخارجيين (أو مفتاح بديل مع قيد تفرّد على المفتاحين).
  • أي سمات تخص العلاقة ذاتها — في هذا المثال: appointmentDate وstartTime وstatus وnotes. هذه السمات لا معنى لها منفردةً في جدول المريض أو الطبيب.
Resolved many-to-many: Patient — Appointment — Doctor junction entity Patient PK patientID fullName dateOfBirth phone Appointment PK appointmentID FK patientID FK doctorID appointmentDate startTime status notes Doctor PK doctorID fullName specialty phone 1 M M 1 Junction Entity
بعد الحل: كيان الموعد الوسيط يحوّل علاقة M:N إلى علاقتَي واحد-إلى-كثير، ويكتسب سماته الخاصة التي تصف العلاقة.
تسمية الكيان الوسيط: اختَر له اسماً تجارياً ذا معنى، لا مجرد دمج ميكانيكي كـPatientDoctor. في هذه العيادة، العلاقة هي "موعد" — Appointment — مفهوم حقيقي في المجال. المكتبة قد تسميه "إعارة" — Loan — والمتجر قد يسميه "بند الطلب" — OrderItem. الاسم ذو المعنى يؤكد أن الكيان يستحق الوجود المستقل.

مثال ثانٍ: بنود الطلبات في متجر إلكتروني

في متجر إلكتروني، توجد علاقة M:N خام بين Order وProduct. حلّها يُنشئ كيان OrderItem الوسيط الذي يحمل سمات تخص هذا التركيب تحديداً: quantity وسعر الوحدة unitPrice وقت الشراء (الذي قد يختلف عن السعر الحالي للمنتج).

Order (orderID PK, customerID FK, orderDate, totalAmount) OrderItem (orderID FK, productID FK, <-- مفتاح أساسي مركّب quantity, unitPrice) <-- سمات العلاقة Product (productID PK, name, description, currentPrice, stockQty)

بدون OrderItem، أين ستُخزَّن quantity؟ لا يمكن وضعها في Order لأن الطلب يغطي منتجات متعددة، ولا في Product لأن المنتج يظهر في طلبات كثيرة. الكيان الوسيط هو المكان المنطقي الوحيد لها.

قائمة التحقق: متى تحتاج إلى كيان وسيط؟

  1. كلا علامتَي الكثرة موجودتان — رمز "أقدام الغراب" على طرفَي خط العلاقة هو الإشارة الفورية.
  2. توجد سمات تصف الزوج لا أيًّا من الكيانين منفرداً — الكمية وتاريخ الحجز ودور الموظف في المشروع أمثلة كلاسيكية.
  3. تحتاج إلى تسجيل توقيتات أو ترتيب للعلاقة — متى زار المريض هذا الطبيب لأول مرة؟ متى استُعير الكتاب؟
  4. للعلاقة ذاتها دورة حياة — الموعد قد يكون مؤكداً أو ملغى أو مكتملاً؛ الإعارة قد تكون نشطة أو مُعادة أو متأخرة.
لا تُفرط في الحل. علاقة واحد-إلى-كثير لا تحتاج إلى كيان وسيط. إضافة واحد حيث لا ضرورة له تُولّد تعقيداً غير مبرر، وعمليات ضم إضافية، ومزيداً من الكود للصيانة. أدخل الكيان الوسيط فقط عند وجود علاقة M:N حقيقية أو عندما تحمل العلاقة بيانات خاصة بها.

مثال المكتبة الجامعية: الطالب يستعير كتاباً

تُجسّد مكتبة جامعية نموذجاً مثالياً للكيان الوسيط ذي دورة حياة واضحة. يمكن للطالب Student استعارة كتب Book متعددة، ويمكن لنسخة الكتاب أن تُستعار من طلاب متعددين عبر الزمن. الكيان الوسيط Loan يُسجّل borrowedDate وdueDate وreturnedDate (قابل للقيمة الفارغة) وfineAmount. هذه السمات جميعها لا معنى لها بدون ربط الطالب بالكتاب معاً.

المفتاح المركّب مقابل المفتاح البديل: بعض الفرق تستخدم مفتاحاً أساسياً مركّباً من كلا المفتاحين الخارجيين (مثلاً: studentID + bookCopyID + borrowedDate إذا كان بالإمكان استعارة الكتاب ذاته مرتين). فرق أخرى تفضّل مفتاحاً بديلاً loanID مع قيد تفرّد على التركيبة الطبيعية. كلا الأسلوبين صحيح — وثّق اختيارك في قاموس البيانات.

خلاصة

حل علاقات كثير بكثير هو أحد أكثر الخطوات أثراً في تحويل ERD المنطقي إلى نموذج مادي. كل خط M:N يتحوّل إلى كيان وسيط يحمل مفتاحَين خارجيَّين وأي سمات تخص الارتباط. كثيراً ما يكتسب الكيان الوسيط اسماً تجارياً ذا معنى — Appointment، OrderItem، Loan، Enrollment — لأنه يمثّل مفهوماً حقيقياً في المجال. إتقان هذا التحويل ضروري قبل الانتقال إلى التطبيع.

الدرس السابق المفاتيح: الأساسي والأجنبي والمرشح
الدرس التالي التسوية: الصيغة الأولى والثانية والثالثة
العودة للدورة