تحليل قواعد البيانات

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

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

بعد المقابلة الشخصية مع الأطراف المعنيين، تم تدوين النقاط المهمة والتي تصف النظام كالآتي:

• مكتب هندسي فيه عدة أقسام.
• مهندسو المكتب ذو تخصصات متنوعة (معماري، ديكور، إنشاءات وبنية تحتية).
• القسم فيه عدة مهندسين، والمهندس يعمل في قسم واحد.
• القسم يشرف على عدة مشاريع، والمشروع الواحد يشرف عليه عدة أقسام.
• العامل يعمل في مشروع واحد، والمشروع يعمل فيه عدد من العمال.

المطلوب: بناء نظام يحقق ما يأتي:

1. حفظ البيانات المتعلقة بالمهندسين والمشاريع والعمال.
2. إدارة عملية الإشراف على المشاريع وطباعة تقارير تتعلق بيانات كل مشروع.
3. بناء استعلامات مناسبة.
4. تصميم نماذج إدخال ومعالجة.
5. طباعة تقارير بالمشاريع التي يشرف عليها المهندسين.

   تأتي خطوات تحليل النظام بعد عملية جميع البيانات وفق التسلسل الآتي:

• أولاً: تحديد كيانات النظام وصفاته.
• ثانياً: رسم نموذج ⁦ERD (Entity Relationship Diagram)⁩.
• ثالثاً: تحديد العلاقات بين كيانات النظام.
• رابعاً: تنفيذ النظام باستخدام أحد برامج معالجة قواعد البيانات.

  ولفهم طريقة التعامل مع الخطوات السابقة، سوف يتم تطبيق هذه الخطوات على النظام السابق.

• كيانات النظام

  يظهر من خلال وصف نظام المكتب الهندسي حاجة النظام إلى مجموعة من الكيانات، كما يأتي: كيان "مهندس" (⁦ENGINEER⁩⁦tbl⁩)، كيان "مشروع" (⁦PROJECT⁩⁦tbl⁩)، كيان "قسم" (⁦DEPARTMENT⁩⁦tbl⁩)، كيان "عامل" (⁦WORKER⁩tbl).

• صفات النظام

  تصنف صفات الجداول من حيث تكوينها إلى: أ) صفة بسيطة أو مركبة ⁦(Simple or Composite Attribute)⁩ يطلق على الصفة التي لا يمكن تجزئتها بالصفة البسيطة، مثل: عمر الطالب؛ حيث لا يمكن تقسيمها، بينما يطلق مفهوم الصفة المركبة على الصفة التي يمكن تقسيمها إلى أجزاء ذات دلالة، مثل: اسم الطالب؛ حيث يمكن أن يكون وحدة واحدة أو يتم تجزئته إلى: الاسم الأول، واسم الأب، واسم الجد، واسم العائلة.

• ب. صفة وحيدة أو متعددة القيم ⁦(Single-valued or Multi-Valued Attribute)⁩

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

ملاحظة: الصفة الوحيدة ليست بالضرورة أن تكون صفة بسيطة.

• ج. الصفة المشتقة ⁦(Derived Attribute)⁩

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

نشاط (١): أمثلة على الصفات بين نوع كل صفة من الصفات الآتية، معللاً السبب.

| | | |---|---| | معدل الطالب | كود الكتاب | | رقم الرخصة | عنوان المنزل | | تاريخ الميلاد | عنوان ⁦MAC⁩ |

سنتعرف إلى الصفات التي تميز الكيانات والمسؤولية عن إنشاء العلاقات والروابط بينها، وهي:

• أ. المفتاح الأساسي ⁦(Primary Key - PK)⁩: الصفة أو مجموعة الصفات المختارة والأكثر ملائمة لتمييز سجلات الكائن؛ ومن خصائصه: القيم في الصفة فريدة ولا تتكرر، كما لا يُسمح بالقيمة الفارغة ⁦(NULL)⁩، وله شكلان:

1. البسيط: صفة واحدة فريدة، مثل: صفة "رقم القسم" في كيان "القسم".
2. المركب: مجموعة صفات تشكل معاً صفة فريدة؛ وذلك في حال عدم وجود صفة واحدة فريدة مثال ذلك: الصفتان ("رقم الفاتورة" و "السنة") في كائن ("الفاتورة") في حال إعادة ترقيم الفواتير بداية كل عام.

• ب. المفتاح الأجنبي ⁦(Foreign Key - FK)⁩: صفة في كيان معين تكون صفة فريدة، في كيان آخر، هدفه الربط وإنشاء العلاقات بين الكيانات (كما سيرد لاحقاً)، ويكون مجال قيمه ضمن مجال قيم الصفة المرتبطة معها في الكيان الآخر ومن نفس نوع البيانات، مع السماحية بتكرار البيانات وقبول القيمة الفارغة ⁦(NULL)⁩، مثال ذلك: ("رقم القسم") في كيان "مهندس".

نشاط (٢): المفتاح الأساسي الأنسب

• حدد أي الحقول أدناه يصلح اختياره أساسياً مع توضيح السبب.

(رقم الهوية، بصمة المريض، اسم الطالب، عنوان المستودع، زمرة الدم، تاريخ البدء بالدورة، رقم ⁦IP⁩)

عند دراسة نظام (المكتب الهندسي) وكياناته السابقة، ومن خلال المعلومات التي قدمها الأشخاص المعنيين بالنظام، فإن الصفات المقترحة لكل كيان منها كالآتي:

• كيان مهندس "⁦ENGINEER_tbl⁩": (رقم المهندس، اسم المهندس، التخصص، تاريخ التعيين، البريد الإلكتروني، رقم القسم).
• كيان مشروع "⁦PROJECT_tbl⁩": (رقم المشروع، اسم المشروع، الموقع، تاريخ التأسيس، التكلفة الاجمالية، رقم القسم).
• كيان قسم "⁦DEPARTMENT_tbl⁩": (رقم القسم، اسم القسم).
• كيان عامل "⁦WORKER_tbl⁩": (رقم العامل، اسم العامل، الأجرة بالساعة، رقم الهاتف، رقم المشروع).

  حيث أن: الصفة "رقم المهندس" في كيان "مهندس"، والصفة "رقم المشروع" في كيان "مشروع" مفتاحان أساسيان، والصفة "رقم القسم" في كيان "المهندس" مفتاح أجنبي.

سؤال: حدد المفاتيح الأساسية والأجنبية المتبقية في الكيانات الأخرى.

ملاحظات:

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

يعتبر وضع معظم البيانات في جدول واحد كبير من الأخطاء الشائعة في التصميم، التي يقع فيها المبرمجون الجدد، وخاصة من تقتصر خبرتهم السابقة على استعمال جداول البيانات ⁦(spreadsheets)⁩ مثل الإكسل، والجدول في الشكل أدناه مثال على التصميم الخاطئ. المقصود من هذا الجدول تسجيل حركة الدورات التدريبية، أي الدورات التي حصل عليها كل موظف في شركة ما، أي أن الموظف ذا الرقم المبين قد حضر دورة معينة، التي كودها، وعنوانها، وتواريخها كما هو مبين في الشكل، نلاحظ أن الصفوف (10,9,8,5,2) تمثل بيانات دورة الإكسل التي كودها ⁦EXC01⁩، والتي تكررت 5 مرات في هذا الجدول الذي لم يزد حجمه عن عشرة صفوف، فهل ترون هذا سليماً؟

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

المشكلة الأساسية هي تكرار المعلومات ⁦(Data Redundancy)⁩ مما يتسبب في استهلاك مساحة تخزينية لا داعي لها، علاوة على المجهود الذي يبذل في إدخال البيانات، كذلك فإن التكرار يؤدي إلى:

• صعوبة التغيير، فلو أردت تعديل بيانات دورة ما، لا بد من تعديلها في سجلات كل من حضرها.
• احتمال حصول الخطأ أثناء الإدخال أو التعديل، مما يؤدي إلى عدم تناسق البيانات ⁦(Data inconsistency)⁩، وبالتالي فقدان الثقة بقاعدة البيانات.

للتغلب على المشاكل السابقة في التصميم، يتم فصل الجدول في الشكل السابق إلى جدولين:

1. جدول الدورات ⁦course⁩ ويحتوي: سجل واحد لكل دورة.
2. جدول تسجيل الموظفين ⁦registration⁩ ويحتوي: رقم الموظف وكود الدورة المسجل لها.

   ضمن بذلك عدم تكرار البيانات الخاصة بالموظفين أو الدورات كلما سجل موظف في دورة جديدة، مما يسهل عملية تغيير معلومات الدورات، ويكون شكل الجدولين كما يأتي:

يُعرف نموذج ⁦(ERD)⁩ أنه مخطط تصويري رسومي لنظام قاعدة البيانات يُظهر الكيانات والصفات، والعلاقات الخاصة بالنظام من خلال أشكال هندسية، لكل منها دلالة كما في الشكل أدناه.

وبناءً عليه، يمكن تمثيل كيان "مهندس" وصفاته بنموذج ⁦(ERD)⁩ كما يأتي:

نشاط (3): نموذج ⁦ERD⁩ ارسم نموذج ⁦ERD⁩ لكيانات النظام المتبقية: ("مشروع"، "قسم"، "عامل").

تهدف العلاقات بين الكيانات إلى تكامل البيانات، مع إمكانية استرجاعها بشكل سليم ودقيق، وهناك عدة أنواع للعلاقات حسب درجة العلاقة بين الجداول:

1. علاقة واحد الى واحد ⁦(One To One)⁩: علاقة تربط كل سجل في كيان ما بسجل واحد من كيان آخر، والعكس صحيح، مثال ذلك: العلاقة بين كياني الدولة والرئيس؛ فكل رئيس يرأس دولة واحدة، وكل دولة لها رئيس واحد. أعط أمثلة أخرى؟ ويرمز لها بالرمز (1:1).

2. علاقة واحد إلى متعدد ⁦(One To Many)⁩: علاقة تربط سجلاً في الكيان الأول بعدة سجلات من الكيان الآخر، والعكس غير صحيح، ومثال ذلك: العلاقة بين كياني الأب والطفل؛ فكل أب له عدة أطفال، وكل طفل له أب واحد. أعط أمثلة أخرى؟ ويرمز لها بالرمز (∞:1) مع مراعاة الترتيب؛ حيث أن: (∞:1) ≠ (1:∞).

ويرمز لها بالرمز (∞:∞).

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

• كيان (مهندس) مع كيان (قسم) : علاقة متعدد لواحد (1:∞).

• كيان (قسم) مع كيان (مشروع) : علاقة متعدد لمتعدد (∞:∞).

وتُحلل العلاقة بين كيان (قسم) وكيان (مشروع) لكونها متعدد لمتعدد لتصبح كما يأتي:

• كيان "مشروع" مع كيان "عامل" : علاقة واحد لمتعدد (1:∞).

  تحديد الروابط بين الكيانات من خلال رسم ⁦ERD⁩ التي تمثل جميع كيانات النظام وحقولها والروابط فيما بينها:

سؤال: أعد رسم نموذج ⁦ERD⁩ السابق بجميع تفاصيله (الكيانات وصفاتها) مع توضيح المفاتيح الأساسية والأجنبية.

نشاط (4): العلاقات بين كيانات النظام

السؤال الأول: فرق بين قواعد البيانات وإدارة قواعد البيانات من حيث:

1. الجهة التي تتعامل مع البيانات.
2. الموقع بالنسبة لنظم إدارة قواعد البيانات.

• أ. ناقش كلاً من الخصائص الآتية ودورها في تميز قواعد البيانات عن الملفات:

• أمن البيانات.
• الوصول المتزامن للبيانات.

• ب. عدد ميزات النموذج العلائقي مقارنة بنماذج نظم قواعد البيانات.

تمعن في صياغة العلاقة بين المبرمج ولغة البرمجة: "كل مبرمج يتقن عدة لغات برمجة، وكل لغة برمجة يتقنها عدة مبرمجين"، ثم أجب عن الأسئلة الآتية:

• ما نوع العلاقة بين الكيانات؟
• هل يمكن تمثيل هذه العلاقة باستخدام برامج قواعد البيانات؟ وضح إجابتك.

السؤال الرابع: قام أحد الموظفين بإنشاء جدول في قاعدة بيانات شركة للمقاولات وصممه بالشكل الآتي:

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

السؤال الخامس: ما المقصود بالتسوية؟ وما الفائدة منها؟