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

مشروع: نموذج بيانات متكامل

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

مشروع: نموذج بيانات متكامل

على مدار هذه الوحدة التعليمية درست كل مكوّن من مكوّنات نمذجة البيانات بصورة منفردة: الكيانات والسمات، وتدوين العلاقات والكميات، وقواعد التطبيع، وكيانات الربط، والمفاتيح، وقاموس البيانات. في هذا الدرس الختامي تجمع كل هذه المهارات في نظام واقعي واحد — نظام حجز مواعيد عيادة — وتُنتج التسليمات الثلاث التي يقدمها المحلل المحترف لفريق التطوير: مخطط ERD متكامل، وتدقيق تطبيع، وقاموس بيانات.

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

الخطوة الأولى: فهم النطاق التجاري

قبل رسم أي مربع، اقرأ السيناريو بعناية. إليك الوصف:

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

من هذه الفقرة يستخلص المحلل الماهر الأسماء الرئيسية (الكيانات المحتملة) والأفعال الرئيسية (العلاقات المحتملة) والكلمات الوصفية (السمات المحتملة). القائمة المختصرة هي: Patient وDoctor وSpecialty وAppointment وDiagnosis وMedication وPrescription.

الخطوة الثانية: تحديد العلاقات والكميات

اعمل على كل زوج من الكيانات واسأل: "هل يمكن لنسخة واحدة من A أن ترتبط بنسخ كثيرة من B والعكس؟" النتائج:

  • Patient — Appointment: مريض واحد لمواعيد كثيرة (1:M).
  • Doctor — Appointment: طبيب واحد لمواعيد كثيرة (1:M).
  • Appointment — Diagnosis: موعد واحد ينتج عنه تشخيص واحد على الأكثر (1:0..1).
  • Diagnosis — Medication: علاقة كثير بكثير — تشخيص واحد قد يشمل أدوية متعددة، ودواء واحد يظهر في تشخيصات عديدة. تُحلّ عبر كيان الربط Prescription.
  • Doctor — Specialty: قد يكون للطبيب عدة تخصصات، والتخصص الواحد مشترك بين أطباء كثيرين. تُحلّ عبر DoctorSpecialty.

الخطوة الثالثة: مخطط ERD المتكامل

يستخدم المخطط أدناه تدوين أقدام الغراب. يُدرج كل مربع كياني مفتاحه الأساسي (PK) والمفاتيح الأجنبية (FK) والسمات الرئيسية. تحمل خطوط العلاقات علامات الاختيارية (دائرة = اختياري، شرطة = إلزامي) وأقدام الغراب للدلالة على "كثير".

Complete ERD for the Clinic Booking System Patient PK patientID fullName dateOfBirth phone email registeredAt Doctor PK doctorID fullName licenseNo phone hiredAt DoctorSpecialty FK doctorID FK specialtyID certifiedYear Specialty PK specialtyID specialtyName Appointment PK appointmentID FK patientID FK doctorID scheduledAt status cancelReason createdAt Diagnosis PK diagnosisID FK appointmentID icdCode notes Prescription PK prescriptionID FK diagnosisID FK medicationID dosage / days Medication PK medicationID brandName genericName formulation 1 M 1 M 0..1 1 M M 1 1 : M M : 1
مخطط ERD المتكامل بتدوين أقدام الغراب لنظام حجز مواعيد العيادة — 7 كيانات وجميع العلاقات محلولة.
قراءة المخطط: اتبع أي مسار من Patient يميناً عبر Appointment ثم نزولاً إلى Diagnosis ومنها إلى Prescription / Medication. هذه السلسلة تمثل الدورة الكاملة لزيارة المريض — من الحجز حتى العلاج.

الخطوة الرابعة: تدقيق التطبيع

قبل الموافقة النهائية على أي نموذج، تحقق دائماً من أن كل كيان يستوفي على الأقل الشكل الطبيعي الثالث (3NF). قائمة التحقق:

  1. 1NF: كل خلية تحمل قيمة واحدة ذرية. تأكد من أن Appointment.status قيمة مفردة (لا "confirmed, paid")، وأنه لا توجد مجموعات أدوية متكررة داخل صف الموعد — وهذا محقق لأننا وضعنا الأدوية في كيان Prescription منفصل. ✓
  2. 2NF: كل سمة غير مفتاحية تعتمد على المفتاح الأساسي كاملاً. يمتلك Prescription مفتاحاً مركباً محتملاً (diagnosisID, medicationID). السمات dosage وdays تصف هذه الوصفة المحددة بالذات — لا الدواء وحده ولا التشخيص وحده — وبذلك يتحقق 2NF. ✓
  3. 3NF: لا توجد تبعيات انتقالية. في المسودة الأولى البسيطة، يضع بعض المحللين doctorSpecialty مباشرة في جدول Doctor كحقل نصي، ما يُوجد تبعية انتقالية عند تخزين تخصصات متعددة. نقله إلى DoctorSpecialty وSpecialty يُزيل هذا المسار الانتقالي. ✓
خطأ شائع: تخزين عمر المريض كعمود بدلاً من تاريخ الميلاد ينتهك مبدأ عدم استمرارية البيانات المشتقة. العمر يتغير كل عام؛ أما dateOfBirth فلا يتغير أبداً. خزّن دائماً الحقيقة الخام لا النتيجة المحسوبة.

الخطوة الخامسة: قاموس البيانات (مقتطف)

يُظهر مخطط ERD البنية؛ أما قاموس البيانات فيُعرّف المعنى. فيما يلي مقتطف تمثيلي يغطي كيان Appointment — أكثر الجداول أهمية تشغيلية في هذا النظام.

الجدول: Appointment المفتاح الأساسي: appointmentID العمود | النوع | القابلية للفراغ | القيود | الوصف ----------------|---------------|-----------------|----------------------|----------------------------------------------- appointmentID | INT UNSIGNED | لا | PK, AUTO_INCREMENT | مفتاح بديل يولّده النظام تلقائياً. patientID | INT UNSIGNED | لا | FK → Patient(PK) | يرتبط بالمريض المسجّل. doctorID | INT UNSIGNED | لا | FK → Doctor(PK) | يرتبط بالطبيب المعالج. scheduledAt | DATETIME | لا | — | تاريخ ووقت الموعد (يُخزّن بتوقيت UTC). status | ENUM | لا | DEFAULT 'pending' | القيم: pending | confirmed | completed | cancelled. cancelReason | VARCHAR(500) | نعم | NULL ما لم يكن | ملاحظة موظف الاستقبال. مطلوبة عند status = cancelled. | | | status = cancelled | createdAt | DATETIME | لا | DEFAULT NOW() | ختم زمني لإدراج الصف.
أهمية قاموس البيانات: قد ينفّذ مطوّران يقرأان مخطط ERD فقط حقل scheduledAt بالتوقيت المحلي على أحد الخوادم وبتوقيت UTC على الآخر. يمنع قاموس البيانات هذا الغموض بتحديد قواعد التخزين ومجموعات القيم الصحيحة إلى جانب المخطط البنيوي.

الخطوة السادسة: إمكانية التتبع حتى المتطلبات

يمكن تتبع كل كيان في هذا النموذج حتى متطلب تجاري واحد على الأقل من السيناريو. هذا هو فحص الجودة النهائي:

  • Patient — "يُسجَّل المريض مرة واحدة ويمكنه حجز مواعيد عديدة."
  • Doctor / DoctorSpecialty / Specialty — "لكل طبيب تخصص أو أكثر."
  • Appointment — "كل موعد مع طبيب واحد بالضبط في تاريخ ووقت محددين."
  • Diagnosis — "يُسجّل الطبيب التشخيص."
  • Prescription / Medication — "يمكنه وصف دواء أو أكثر … مع الجرعة والمدة."
  • cancelReason في Appointment — "يُسجّل موظفو الاستقبال حالات الإلغاء … مع ذكر السبب."

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

عادة احترافية: أنشئ مصفوفة إمكانية تتبع بسيطة — جدول يُعيّن كل معرّف متطلب إلى الكيان أو السمة التي تُحقّقه. ستكون ذات قيمة لا تُقدَّر في مراجعات التصميم وطلبات التغيير.

تسليم النموذج

تتكون حزمة نمذجة البيانات المتكاملة لفريق التطوير من ثلاثة وثائق: مخطط ERD المفاهيمي (على مستوى الأعمال بدون مفاتيح)، ومخطط ERD المنطقي (مُطبَّع مع مفاتيح وكميات — مخطط هذا الدرس)، وقاموس البيانات (المواصفات على مستوى الأعمدة). تمنح هذه الوثائق مجتمعةً المهندسين المعماريين ما يكفي لتصميم مخطط مادي، وعمقاً دلالياً كافياً لكتابة قواعد التحقق والتقارير وعقود التكامل الهادفة.

تهانينا — لقد طبّقت الآن كل مفهوم من مفاهيم هذه الوحدة على نموذج بيانات واحد متماسك بمستوى إنتاجي. يتوسع هذا الأسلوب نفسه — استخلاص النص، وتحديد الكيانات، وتحليل العلاقات، ورسم مخطط ERD، وتدقيق التطبيع، وقاموس البيانات — من نظام مؤلف من خمسة جداول حتى مخطط مؤسسي بخمسمائة جدول.

اكتمل الدرس!

تهانينا! لقد أكملت جميع الدروس في هذا البرنامج التعليمي.

الدرس السابق قاموس البيانات
العودة للدورة تحليل الأنظمة
العودة للدورة