1  تخطيط البيانات

السؤال: كيف ننشئ الأساس؟ الجواب: تخطيط البيانات.

مخطط البيانات (Data Schema) هو القالب الذي نسكُب فيه البيانات لتأخذ شكلاً ثاتبًا.

إن سبق لك العمل مع إحدى برامج الجداول (Excel أو Sheets أو Numbers أو Calc)؛ فإن التصميم المنطقي أن يكون لكل جدوَل أعمدة محددة، ثُمَّ تُفرَّغ فيها البيانات على شكل صفوف.

ففي الاصطلاح المجرَّد عن شكل البيانات هذا (كوْنها جداول وأعمدة وصفوف) نسمي كُلَّا كالتالي:

أولاً: الصفة

تعرف الأشياء بمجموع صفاتها.

والصفة إما: 1. أصليَّة (Intrinsic) مثل: حجم الكتاب، وزن الحيوان، حرارة الجسم. 2. أو مشتقة (Derived) وهي ضربان: 1. مشتقة من صفة واحدة: مثل تاريخ الميلاد: من العمر. 2. أو مشتقة من أكثر من صفة: مثل مدة الرحلة: فقد تشتق من الفرق بين وقت النهاية والبداية

وإما: 1. بسيطة (Simple) مثل: تاريخ التسجيل في الدورة. 2. أو مركَّبة (Composite) مثل: الدورة التي سجل فيها الطالب (فهي نفسها علاقة ذات صفات)

الروابط: تعددية قيمة الصفة

وقد تكون متعددة القيمة (Multi-value). ويجوز ذلك في الأمرين: - البسيطة: مثل أن يكون للكتاب الواحد عدة تصنيفات (الأدب، الخيال، المستقبل) - المركبة: مثل أن يسجل الطالب الواحد في عدة دورات

صور التعدد

وللتعدد ثلاث صور -تسمى درجة التعددية (Cardinality)-: 1. الاختصاص (1:1) 2. التعدد من طرف واحد (1:M) 3. التعدد من الطرفين (M:M)

فأما الاختصاص فلا يكاد يوجد في الواقع. وقد نمثِّلُ له: 1. باختصاص المواطن بهويَّة واحدة (والعكس: اختصاص الهوية بذاك المواطن) 2. واختصاص الدولة معاصمة واحدة (وبالعكس: اختصاص العاصمة بتلك الدولة)

لكن سرعانما تُدرِكُ أن المواطِن يجدد هويَّته، وتُبطَلُ الأولى وتفعَّل الثانية، وكلاهما مخزَّن. وكذلك في الدول قد تنتقل عاصمتها أو يكون لها عاصمتان، وهكذا …

وأما مثال التعدد من طرف واحد: 1. عميل وفواتير: فكل عميل واحد له عدة فواتير لا يشترك معه فيها غيره.

وأما مثال التعدد من الطرفين: - طلاب ومواد دراسية: حيث يمكن للطالب الواحد التسجيل في عدة مواد، ويكون في المادة الواحدة عدة طلاب

عودة الإشارة إلى نفس السجل

ولا مانع من إشارة سجل في علاقة لسجل آخر في نفس العلاقة، مثل: - إشارة من شخص لشخص (علاقة صداقة) وكلاهما فردٌ في الأشخاص - أو إشارة المادة لمجموعة المواد المتطلبة لها؛ وكلاهما فردٌ في المواد

ضرورة المعرِّف

تأمل المثال التالي:

العلاقة الأولى: الزبائن، والصفات: الرقم المعرِّف، الاسم والعمر.

العلاقة الثانية: الفواتير، والصفات: الرقم المعرِّف، تاريخ الإصدار، حالة الفاتورة، الرقم المعرِّف للزبون.

ولاحظ وجود الرقم المعرِّف (ID) في موضعين، وله في كل موضعٍ وظيفة:

الأول: في سجل البزون؛ إذْ به تتمايز السجلات وإن تطابقت في جميع الصفات الأخرى. وهذه الخاصية تسمى الفرادة (Uniqueness). وتسمى الصفة حينها: المفتاح الأساسي (Primary Key).

الثاني: في سجل الفاتورة؛ فذكر معرِّف الزبون إشارة تُغني عن ذكر بقية بياناته -التي قد تتغير فيما بعد (بالتقادم: كالعمر) أو (بالتصحيح: كتصحيف الاسم)-. وتسمى الصفحة حينها: المفتاح الأجنبي (Foreign Key).

وتسمى: قاعدة البيانات: علائقية (Relational DB)، لوجود الأرقام التي تربط العلاقات ببعضها على النحو الذي رأيناه: إشارة من مفتاح أجنبي لمفتاح أساسي.

وحين تتعدد الإشارة يزيد تعدد الصفة المركَّبة، كما هو في التعدد من الطرفين: الطلاب والمواد:

فهذه علاقة: تسجيل طلاب بمواد:

  • الصفة الأولى (id) هي المعرِّف الخاص بكل تسجيل
  • الصفة الثانية (student_id) والثالثة (course_id) كل منهما إشارة إلى ما يعرِّف كلا الطرفين
  • الصفة الأخيرة (created_at) هي تابعة للسجل نفسه؛ وهو وقت حدوث هذا التسجيل

ثانيًا: التعريف الوظيفي

ينطلق التخطيط المناسب للاستخدام من واقع الاستخدام. فإننا حين نخطط البيانات فإننا لا نعرِّفُ الأشياء من حيث هي -تعريفًا فلسفيًّا- بل نضع التصميم ليكون أساسًا للعمليات القائمة في التطبيق. وقد نقول إن تصميم البيانات دون فهم لطبيعة العمليات في التطبيق يشبه بناء مطبخ قبل أن نعرف ماذا سنطبخ.

سبر الوقائع

نلاحظ أن السجلات في قواعد البيانات الداعمة للتطبيقات غالبًا ما تكون تدوين لنواتج أفعال المستخدم المباشرة أو لاستجابات النظام له وللعالم الخارجي.

ففي نظام اشتراكات مثلاً، تجد هذه العمليات:

  • إنشاء المدير (م) باقة خدمات (ق) بسعر معيَّن (س)
  • اشتراك المستخدم (خ) في باقة (ق)
  • إصدار النظام فاتورة (ف) للمستخدم (خ) بموجَب اشتراكه (ش)
  • تسديد المستخدم (خ) قيمة الفاتورة (ف)
  • أو جدوَلة المستخدم (خ) تسديد الفاتورة (ف) على دفعات في تواريخ محددة (ت1 ت2 ت3)

وليس ذلك في الإنشاء فقط، بل كذلك في التحديث والحذف:

  • تغيير حالة الاشتراك (ش) إلى “مُجمَّد”
  • حذف الباقة (ق) فلا تظهر للمستخدمين

وكل جملة خبرية من هذه الجُمَل؛ فيها إخبارٌ عن حدثٍ وقع في زمن. ونحن حينما نتكلم عن وقائع فإنها متعلِّقة بأعيان لا بأشياء مجرَّدة؛ ولذلك وضعنا الأحرف إشارة لكل واحد منهم. - الإشارة للمعيَّن (الفاعل أو المفعول أو …إلخ) تكون بالمعرِّف (id) - زمن الإنشاء (created_at) - زمن التحديث (updated_at) - حالة الشيء (status)، مجمَّد، محذوف، …إلخ.

السؤال المفيد هنا: كيف سيكون تصميم مخطط البيانات لاستيعاب هذه الوقائع؟

القوانين

غالبًا ما يشترط لحدوث الواقع أن تكون موافقة (غير متعارضة) مع القوانين التي نضعها. فمثلاً:

  • لا يمكن لأي مستخدم أن يُنشئ باقات ولا أن يغير الأسعار؛ بل يجب أن يكون دوْره: مدير نظام
  • لا يمكن للطالب أن يسجل في مادة وهو لم يستكمل متطلباتها
  • لا يمكن للمستخدم أن يتمتع بالمميزات المتقدمة للتطبيق إلا بعد ترقية اشتراكه

وهذه القوانين تكون في منطق التطبيق (لا في قاعدة البيانات) إلا أنها مبنيَّة على استعلامات لبيانات مخزنة في قاعدة البيانات؛ فإذا لا بد من سبرها أيضًا.

سبر الاستعلامات

والاستعلام نوعان: اختيار وتلخيص.

أولاً: الاختيار: ترشيح سجلات بناءً على مطابقتها لشروط البحث. ومثال ذلك: - ما هو دوْر المستخدم (خ)؟ - ما هي المواد التي أكملها الطالب (ط)؟ - هل هذه المواد تشمل جميع المواد المتطلبة للمادة (م)؟ - ما هي حالة اشتراك المستخدم (خ)؟

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

  • المعرِّف، مثل عدد المشتركين في الباقة (ق)
  • الصنف، مثل معدَّل المشتركين التجريبيين الذين جددوا اشتراكهم من مجموع عدد المشتركين
  • الزمان، مثل متوسط الاشتراكات الجديدة في الربع الأول من كل سنة، خلال السنين الثلاث الأخيرة
  • المكان، مثل إجمالي دخل الطلبات في مدينة (م)

خلاصة

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

السؤال التالي: كيف نصيغ هذا المخطط بلغة البرمجة؟