دورة MySQL للمبتدئين

2: لمحة حول Entity Relationship Diagram – دورة MySQL

السلام عليكم و رحمة الله و بركاته

في هذا الدرس، لن نتعلم بعد كيفية كتابة كود SQL، و لكن سنتطرق إلى موضوع مهم جدا حول قواعد البيانات العلائقية.

ما هي قواعد البيانات العلائقية؟

كما ذكرنا في مقدمة الدورة، فإن MySQL يعتبر نظام إدارة قواعد بيانات علائقي (RDBMS)، أي أنه قوم بإدارة البيانات انطلاقا من العلاقات التي تربط مختلف جداولها.

ما دام هناك نوع خاص بإلإدارة العلائقية لقواعد البيانات، فلا بد أن تكون هناك أنواع أخرى لأنظمة الإدارة هذه (DBMS).

ما هي أنواع أنظمة إدارة قواعد البيانات المعروفة؟

  • نظام إدارة قواعد البيانات العلائقية؛
  • نظام إدارة قواعد البيانات الهرمية؛
  • نظام إدارة قواعد البيانات الشبكية؛
  • نظام إدارة قواعد البيانات NoSQL؛
  • …إلخ.

و لأننا في هذه الدورة سنركز على النوع الأول، فإنه لا بد لنا في هذا الدرس أن نلقي نظرة على تقنية عمل قاعدة البيانات العلائقية، و ذلك من خلال التعرف على تقنية ERD أي Entity Relationship Diagram,

تعريف ERD :

الـ ERD أو Entity Relationship Diagram هو رسم بياني يجمع بين عدة كيانات و يستعمل عدة رموز و روابط بغرض تسهيل بناء قاعدة بيانات من خلال توضيح أمرين أساسيين جدا:

الوحدات الرئيسية في نظام معين و ماهية العلاقات التي تربط فيما بينها.

إذا من هنا نعرف أصل التسمية: “Entity” و “Relationship”.

ما هي العناصر المكونة لهذا الرسم البياني؟

1 – الكيان Entity

الكيان يجمع عدة نماذج متشابهة تحت سقف واحد، الهدف دائما السهولة و السرعة.

سيتضح الأمر أكثر من خلال مثال:

 لنقل أننا نريد إنجاز قاعدة بيانات تخص معلومات الطلبة. إذا سنحتاج إلى جدول يضم هذه البيانات. و لكن، هل سنضع لكل طالب جدوله الخاص ؟ تخيلوا كم سيأخد هذا من الوقت و المجهود، فما الهدف من نظام قاعدة البيانات العلائقي إن فعلنا هذا؟

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

إذا، فالكيان Entity هو شيء مُعَرف في قاعدة البيانات و يعتبر رئيسيا، يمكن أن يكون شخصا، دورا، شيئا ملموسا، شيئا معنويا…

2 – سمات الكيان Entity Attributes

سمات الكيان، كما يدل على ذلك اسمها، هي ما يصف عناصر الكيان أو ما يميزه. أي، على سبيل نفس المثال أعلاه، ما يميز أو ما يصف الطالب هو الاسم، العمر، العنوان… إذا هي صفات مشتركة بين نماذج الكيان الواحد.

و في الـ ERD، لهذه السمات أنوع مختلفة، مثلا: INT، VARCHAR ،DATE … سنتعمق في هذه الأنواع لاحقا.

إضافة: الـ Attributes تعتبر أيضا Columns، فهي تشكل الأعمدة في الجدول، سيتضح هذا لاحقا..

3 – المفتاح الأساسي (PK) Primary Key

هو ميزة attribute خاصة تميز كل نموذج في نفس الكيان Entity. أي أن كل نموذج (أقصد بالنموذج هنا الطالب الواحد داخل كيان الطالب عامة، أي أن في الجدول المسمى الطالب عدة نماذج لطلبة)، كل نموذج له ميزته الخاصة به وحده، و لا يجب أن تتكرر أكثر من مرة في نفس الجدول، و إلا فلم تعد مفتاحا أساسيا.

ما الهدف من هذا إذا؟

المفتاح الأساسي يساعد على التمييز بين الطلبة، و بهذا يمكن أن نبحث بسرعة عن طالب معين باستعمال هذا المفتاح.

يمكن أن يكون أي ميزة من ميز الكيان، و لكن يفضل أن تكون ميزة لا تتكرر
فمثلا إن اخترنا الاسم كمفتاح أساسي، فلا يجب أن نجد طالبين يحملان نفس الاسم!

و نفس الأمر ينطبق على العنوان، و تاريخ الميلاد.. لذا قد نستخدم رموزا ما أو أرقاما تختلف من طالب لآخر و نضعها في ميزة تسمى ب IDstudent.

قاعدة أساسية جدا: لكل جدول (Entity) مفتاح رئيسي واحد على الأقل.

4 – المفتاح الخارجي (FK) Foreign Key

هو مرجع لمفتاح أساسي في جدول آخر، الهدف منه الربط بين الجداول.

على عكس المفتاح الرئيسي PK، فالمفتاح الخارجي FK يمكن أن يكون متعددا، أي يمكن أن تتوفر عدة نماذج على نفس الـ FK.

مثال:

هكذا سيظهر جدول التطبيق Application بعد إضافة المفتاح الخارجي ProgrammerID:

5 – العلاقة Relationship

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

6 – Cardinality

تُعَرِّف الـ cardinality عدد مرات تكرار نماذج كيان ما في كيان آخر. من خلال مثال الطالب و القسم، فالـ cardinality ببساطة تُعَرِّف كم عدد الطلبة (الأدنى و الأقصى) الذين ينتمون لصف معين، و بالعكس، كم عدد الصفوف التي ينتمي إليها الطلبة.

لنفكك هذه الجملة: الطالب ينتمي لصف واحد فقط، فلا يمكن أن يتواجد نفس الطالب بأكثر من صف في نفس الوقت،

  • العدد الأدنى للصفوف هو 1 (لا يمكن أن يكون 0، فالطالب لا بد أن ينتمي لصف ما كي يعتبر طالبا أساسا) و العدد الأقصى يبقى 1.
  • و من الجهة المعاكسة، العدد الأدنى للطلبة الذين ينتمون للصف الواحد هو 1، و العدد الأقصى هو أكثر من واحد و غير محدد، أي الكثير.

مثال:

1 – One-to-One Cardinality

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

مثال: يحتوي جدول الطالب على عدة صفات إلى جانب صفة “العنوان Address “، و لكن صفة العنوان بدورها قد تحتوي على صفات أخرى؛ كالحي، الرمز البريدي، المدينة…

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

2 – One-to-Many

هذه العلاقة تستعمل عندما يرتبط نموذج واحد من جدول “A” مثلا، مع أكثر من نموذج من جدول “B”، في حين يرتبط نموذج واحد من جدول “B” مع نموذج واحد وفقط من جدول “A”.

مثال: في المدرسة الابتدائية مثلا يدرس المعلم أكثر من صف، و لكن لكل صف معلم واحد لا أكثر.

3 – Many-to-Many

 تستعمل هذه العلاقة عندما يرتبط أكثر من نموذج من جدول “A” مع أكثر من نموذج من جدول “B”،

مثلا: يدرس الطالب درسا واحدا و أكثر، و كل درس يتم دراسته من قبل طالب واحد على الأقل.

 في هذه الحالة، لا يمكن رسم جدولين، جدول الطالب و جدول الدرس، و ربطهما فقط برابط كما في الأمثلة السابقة، هذا مستحيل.

ملاحظة مهمة: لا يوجد رابط واحد يرمز للعلاقة many-to-many

 إذا ما الحل؟

سنفكك العلاقة و نبسطها من خلال إضافة جدول صغير بين كلا الجدولين، حيث يمثل هذا الجدول “العلاقة”، و هذا الجدول سيرتبط بكلا الجدولين الاخرين “الطالب” و “الدرس” من خلال رابط one-to-many.

ملاحظة مهمة: جدول العلاقة هو كيان أيضا، و يتوجب أن يتوفر على مفتاح رئيسي، في هذه الحالة، المفتاح الرئيسي هو مفتاحي الجدولين الآخرين مجموعين، أي أن زوج مفاتيح جدول الطالب و جدول الدرس الرئيسية هو مفتاح رئيسي لجدول العلاقة.

 مثال:

في برنامج Mysql Workbench، يتم إنجاز العلاقة many-to-many بشكل أوتوماتيكي بمجرد الضغط على الزر الموضح في الصورة أسفله، و الضغط على كلا الجدولين:

و تظهر النتيجة كالتالي:

 إذ قام البرنامج برسم جدول جديد يمثل العلاقة بين الجدولين الآخرين، و مفتاحه الأساسي هو مركب المفتاحين الخارجيين.

يُفَضل تغيير اسم هذا الجدول إلى فعل يمثل العلاقة الموجودة، مثلا : studies

نهج المخطط الثلاثي Three-schema approach

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

هذا المنهج يُستعمل من أجل بناء نظم المعلومات وإدارة معلومات النظم. يقترح ثلاث وجهات نظر مختلفة في تطوير النظم، إذ تعتبر النمذجة المفاهيميةConceptual modelling مفتاح تحقيق تكامل البيانات، حيث يقصد بتكامل البيانات الربط فيما بينها و إعطاء رؤية عامة موحدة لجميع البيانات و كذا العلاقات الرابطة بينها.

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

ما هي المستويات الثلاث؟

  • نموذج البيانات التصوري – Conceptual ERD – Conceptual data model
  • نموذج البيانات المنطقي – Logical ERD – Logical data model
  • نموذج البيانات الفيزيائي – Physical ERD – Physical data model

كل المستويات تتضمن على الكيانات Entities و العلاقات، لكنها تختلف في الهدف منها.

فمثلا، قد يستعمل مُحَللٌ ما المستوى الأول لتوضيح الكيانات الأولية و العلاقات فيما بينها، فيما قد يرجع آخر إلى المستوى الثالث من أجل تصميم قاعدة بيانات دقيقة…

 1 – Conceptual modelling

 في هذا المستوى نجد الكيانات الأولية (و التي تعد أيضا business oject أي موضوع عمل) التي يعتبر وجودها ضرورة في نظام ما و العلاقات الرابطة بينها.

الهدف من هذا المستوى إعطاء نظرة عامة على النظام من خلال التعرف على الكيانات المُوَظَّفَة.

يُعَرف هذا المستوى الكيانات الموجودة، و لكن لا يُعَرف الجداول الموجودة. قد يتساءل البعض منكم كيف هذا و الجداول تمثل الكيانات؟

نعم و لكن الجداول لا تمثل الكيانات الأولية فقط، ففي حالة الرابط many-to-many أعلاه، العلاقة بين الجدولين تحولت إلى جدول بحد ذاتها، مثل هذه الجداول التي تمثل العلاقات لا يجب أن تظهر في هذا المستوى،

لأنه مستوى مُعَد لأهداف تبسيط الرؤية العامة فقط، و لكن العلاقات تظهر بشكل مبسط.

و لكن في هذا المستوى لا تظهر السمات و لا أنواعها.

 2 – Logic modelling

يعتبر هذا المستوى نسخة مفصلة عن conceptual data model، حيث يستعمل السمات attributes و كذا الكيانات العملية من أجل تبسيط الروابط بين الكيانات الأولية.

 سؤال: ماذا نقصد بالكيانات العملية و الخاصة بالمعامَلات؟ وهل هي ثانوية؟

أقصد بالكيانات العملية و الخاصة بالمعاملات تلك التي تربط عدة كيانات أخرى من أجل تسهيل العمليات. بمعنى آخر، في بداية تخطيطنا لقاعدة بيانات ما، فإننا نفكر أولا في الكيانات الأولية العامة.

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

و لذلك فكيان الفاتورة ليس ثانويا، وجوده مهم أيضا من أجل دقة العمل.

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

3 – Physical modelling

هذا المستوى يعتبر التخطيط الفعلي لقاعدة بيانات علائقية. فهو يوسع المخطط المنطقي للبيانات logic ERD من خلال إعطاء كل سمة نوعا، طولا محددا، إمكانية قبول قيم فارغة،…إلخ. فالمفاتيح الرئيسية و الخارجية موجودة، و كذا السمات و مختلف أنواعها.

فضلا عن أن العلاقات many-to-many مُوَضحة بشكل أكثر دقة من خلال إضافة جدول جديد يربط بي الفاتورة و المنتج ( لأن المنتج قد يتم شراؤه من عدة مستهلكين و هذا يعني أنه يتواجد بعدة فواتير، كما أن الفاتورات قد تحتوي على أكثر من منتج واحد).

في الأخير، ننصح بالإطلاع على مصادر أخرى من أجل التعرف على مختلف طرق رسم الـ ERD و كذا فهم المفاهيم المذكورة أعلاه بشكل أعمق، و لهذا الغرض نقترح بعض المصادر:

السابق
1: الأدوات – دورة MySQL
التالي
3: أنواع البيانات – دورة MySQL