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

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

1. ابدأ بنمذجة الكيانات قبل الجداول

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

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

2. اختيار نوع قاعدة البيانات المناسب

تنقسم قواعد البيانات الشائعة إلى نوعين رئيسيين، ولكل منهما مواضع يتفوق فيها. والاختيار بينهما يعتمد على شكل البيانات وطريقة استخدامها، لا على الانطباع العام:

• قواعد البيانات العلائقية: مثل PostgreSQL وMySQL وSQL Server، تحفظ البيانات في جداول مترابطة بعلاقات واضحة، وتضمن سلامة المعاملات، وتناسب أغلب أنظمة الأعمال كالمبيعات والمحاسبة والحجوزات.
• قواعد البيانات غير العلائقية: مثل MongoDB، تحفظ البيانات في مستندات مرنة البنية، وتناسب المحتوى متغير الشكل وبعض حالات القراءة الكثيفة.
• المخازن المتخصصة: كمخازن البيانات المؤقتة للتسريع ومحركات البحث النصي، وتُستخدم مكملًا لقاعدة البيانات الرئيسية لا بديلًا عنها.

وفي كثير من المشاريع تكون قاعدة البيانات العلائقية نقطة بداية آمنة، ثم تُضاف المخازن المتخصصة عند ظهور حاجة فعلية لها.

3. التطبيع: كل معلومة في مكان واحد

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

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

4. المفاتيح والقيود: سلامة البيانات من داخل القاعدة

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

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

5. الفهارس وأداء الاستعلامات

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

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

6. قرارات صغيرة تتجنب مشكلات كبيرة

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

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

7. إدارة تغييرات قاعدة البيانات عبر الترحيل

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

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

الخلاصة

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