سنتحدث في هذا المقال عن مفهوم العلاقات بين جداول قاعدة البيانات، وما أنواع هذه العلاقات وكيف تتمثل وما هو أثرها على العمل.
ما هي العلاقات بين الجداول
عند إنشاء جداول في قاعدة البيانات، فإن الظاهر لنا أننا نقوم ببناء جداول منفصلة وغير مترابطة، ولكننا في الواقع العملي نحتاج لربط هذه الكيانات المنفصلة بحيث تُبنَى علاقات تحكم البيانات الموجودة في هذه الجداول، وتحكم طريقة التعامل مع هذه البيانات.
تنشَأ العلاقة بين جدوليْن عندما يُربط عمودان فيهما مع بعضهما عن طريق وجود قيود مطبقة على العمودين، بحيث يكون قيد المفتاح الرئيسي على عمود في الجدول “الأب” وقيد المفتاح الأجنبي على العمود في الجدول “الابن”، وعادة يكون اسم العمودين واحدًا في كلا الجدولين.
مثلا، لحفظ عناوين الأشخاص نستطيع إنشاء جدول باسم Address
ونربطه بجدول الأشخاص Persons
بعلاقة تحكم البيانات الموجودة في الجدولين، بحيث يكون لكل شخص في الجدول Persons
عنوان واحد مرتبط به في الجدول Address
. يُربَط الجدولان عن طريق عمود باسم Person_Id
في كلا الجدولين.
مثال آخر، لو أردنا أن نتابع عملية استعارة الكتب في مكتبة، فإننا سننشئ جدولًا باسم Borrowed_Books
(كُتُب مُعارة) ونربطها بالجدول Persons
عن طريق العمود Person_Id
. يستطيع الشخص الواحد - في هذا النوع من الربط - أن يستعير أكثر من كتاب. في هذا المثال، لو أننا حفظنا بيانات الأشخاص والكتب المستعارة في جدول واحد، ستظهر لنا مشكلة تكرار البيانات Data Redundancy لأننا سنكرّر بيانات الشخص لكل كتاب يستعيره.
ماذا نستفيد من بناء العلاقات بين الجداول؟
- التخلص من مشكلة تكرار البيانات عن طريق فصلها وحفظها في أكثر من جدول، فمشكلة تكرار البيانات هي عدو مستخدمي قواعد البيانات ومسؤوليها، لأنها تتسبب بزيادة حجم قاعدة البيانات بقدر كبير وبسرعة، وترفع السرعات المطلوبة لتنفيذ الاستعلامات، وتجعل من موضوع صيانة قاعدة البيانات كابوسا مقلقا.
- الحفاظ على دقة وسلامة البيانات في قاعدة البيانات، فمع وجود العلاقات بين الجداول، سوف تضمن مثلا عدم وجود كتاب مُعار ليس له شخص استعاره، أو عنوان وهمي ليس له صاحب، وقس على ذلك العديد من الأمثلة.
- استخراج البيانات من أكثر من جدول بكفاءة وسرعة عن طريق بناء جمل ربط استعلامية تطلب المعلومات من أعمدة مختلفة في جداول مختلفة، وإخراج النتيجة بطريقة مفيدة ومرتبة.
أنواع العلاقات
توجد أربعة أنواع من العلاقات بين الجداول كالتالي:
- علاقة واحد إلى واحد (One-to-One).
- علاقة واحد إلى كثير أو علاقة كثير إلى واحد (One-to-Many / Many-to-One).
- علاقة كثير إلى كثير (Many-to-Many).
- علاقة المرجعية الذاتية (Self Referencing).
علاقة واحد إلى واحد
لنفترض أن الجدول Persons
لديه البنية والبيانات التالية:
Person_ID | First_Name | Last_Name | Age | Address |
101 | Ibrahim | Mohammed | 31 | 12 Main St, Doha |
102 | Mohammed | Khaled | 25 | Gaza, Middle Center |
نستطيع أن نضع بيانات العنوان في جدول منفصل ونسميه Address
وتكون بنية الجدوليْن كالتالي.
-
الجدول
Persons
:
Person_ID | First_Name | Last_Name | Age | Address_Id |
101 | Ibrahim | Mohammed | 31 | 1 |
102 | Mohammed | Khaled | 25 | 2 |
-
الجدول
Address
:
Address_ID | Address |
1 | 12 Main St, Doha |
2 | Gaza, Middle Center |
لاحظ أنه أصبح لدينا عمود بنفس الاسم Address_Id
في كلا الجدولين. لبناء العلاقة بين الجدولين، طبّقنا قيد المفتاح الأجنبي على العمود Address_Id
في الجدول Persons
بحيث يأخذ قيمه من العمود Address_Id
في الجدول Address
والمطبق عليه قيد المفتاح الرئيسي.
أصبحت لدينا الآن علاقة بين الجدولين، وفي حال كان كل عنوان في الجدول Address
يقترن فقط بشخص واحد في الجدول Persons
فعندها نسمي هذه العلاقة واحدًا إلى واحد. يجب التنويه إلى أن هذا النوع من العلاقات غير مستخدم كثيرا، فالجدول الأول الذي يحتوي العنوان وبيانات الشخص يفي بالغرض في أغلب الأحيان.
نستطيع تمثيل العلاقة بالشكل التالي:
لاحظ أن وجود العلاقة اختياري، فمن الممكن أن يكون لدينا سجل في الجدول Persons
دون عنوان له في الجدول Address
وهذا مرتبط بعدم تطبيق قيد القيمة غير الفارغة على العمود Address_Id
.
في حال طُبِّق قيد غير القيمة غير الفارغة على العمود، فهنا تصبح العلاقة واجبة بين الجدولين، ولا يمكن أن نُنْشئ سجلًّا في الجدول Persons
إلا بإدخال قيمة موجودة للعمود Address_Id
وهو في مثالنا هذا غير منقطي نوعا ما.
علاقة واحد إلى كثير أو علاقة كثير إلى واحد
هذا النوع من العلاقات هو الشائع بين أنواع العلاقات بين الجداول في قاعدة البيانات، لوجود تطبيقات كثيرة عليه، فمثلا:
- الطالب (واحد) يستطيع أن يدرس أكثر من مساق (كثير).
- الطبيب يعالج ويتابع حالة مريض واحد أو أكثر.
- طلبية الشراء تحتوي على أكثر من عنصر.
- الشخص يستعير أكثر من كتاب.
وقس على ذلك العديد من الأمثلة.
لنفترض وجود جدول للزبناء Customers
بالهيكلية التالية:
Customer_ID | Customer_Name |
1 | Ibrahim Mohammed |
2 | Mohammed Ahmed |
نستطيع ربط جدول الزبناء السابق بجدولٍ للطلبيات Orders
بعلاقة واحد إلى كثير، لتعبر العلاقة عن الطلبيات التي قام بها العملاء وقيمة كل طلبية وتاريخها. يمكن أن تكون هيكلية الجدول Orders
كالتالي:
Order_ID | Customer_ID | Order_Date | Order_Value |
997 | 101 | 1/5/2017 | 100 |
998 | 102 | 21/4/2016 | 150 |
999 | 101 | 21/4/2015 | 1500 |
تسمح هذه العلاقة للعميل بأن يطلُب طلبيةً أو أكثر، ويمكن ألا تكون له أية طلبية. ولكنّ كل طلبية في الجدول Orders
ستكون تابعة لعميل واحد. ونستطيع تمثيل هذه العلاقة بالشكل التالي:
علاقة كثير إلى كثير
في علاقة كثير إلى واحد، تكون العلاقة مبنية على أن يكون أحد أطرافها “واحدًا”، مثل طالب واحد، عميل واحد، طلبية واحدة، وفي الطرف الثاني “كثير”. نحتاج أحيانا أن يكون طرفا العلاقة كثيرين. فمثلا، قد تكون لدينا طلبية تحتوي أكثر من عنصر، ونفس العنصر يكون متواجدًا في أكثر من طلبية.
في هذه الحالة نحتاج لوجود جدول إضافي لبناء العلاقة، فمثلا تكون هيكلية جدول Orders
كالتالي:
Order_ID | Customer_ID | Order_Date | Order_Value |
997 | 101 | 1/5/2017 | 100 |
998 | 102 | 21/4/2016 | 150 |
999 | 101 | 21/4/2015 | 1500 |
وهيكلية جدول Items
كالتالي:
Item_Id | Item_Name | Item_Description |
201 | Hard Disk 1 | 1 Tera SSD Hard |
202 | Mouse | Microsoft Optical Mouse |
203 | LCD 42 | 42” LCD |
نستطيع بناء علاقة كثير إلى كثير بين الجدولين السابقين بإضافة جدول ثالث يحلّ مكان الرابط وغرضه الوحيد هو بناء هذا النوع من العلاقات. نطلق عليه مثلا الاسم Orders_Items
، ويكون بالهيكلية التالية:
Order_Id | Item_Id |
997 | 201 |
997 | 202 |
999 | 201 |
999 | 202 |
999 | 203 |
998 | 203 |
يمثّل الشكل التالي علاقة كثير إلى كثير كما تظهر في الجدول Orders_Items
:
علاقة المرجعية الذاتية
يُبنى هذا النوع من العلاقات عندما نريد أن نبني علاقة بين جدول ونفس الجدول، وأوضح مثال على هذا النوع من العلاقات هو جدول الموظفين الذي يحتوي على عمود رقم الموظف المسؤول، حيث يمكن ربط كل موظف بموظف آخر (مدير أو مسؤول) من نفس الجدول. فمثلا، لو كان لدينا جدول باسم Employees
خاص بحفظ بيانات الموظفين، ستكون هيكليته على النحو التالي لتطبيق علاقة مرجعية ذاتية عليه:
Employee_ID | Employee_Name | Manager_Id |
100 | Ibrahim Elbouhissi | |
101 | Khaled Saber | 100 |
102 | Yasmeen Hadi | 100 |
103 | Duaa Yousef | 101 |
104 | Sami Saber |
بعلاقة المرجعية الذاتية، من الممكن أن يكون للموظف مسؤولًا أو لا يكون، ومن الممكن أن يكون الموظف مسؤولا عن موظف أو أكثر، ويمكن تمثيل العلاقة بالشكل التالي.
- 5
- 1
أفضل التعليقات
انضم إلى النقاش
يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.