عملية تطوير قواعد البيانات Database Development

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

يشار أحيانًا إلى مجموعة هذه الخطوات بدورة حياة تطوير البرمجيات software development life cycle -أو SDLC اختصارًا-، حيث ينتقل المنتج البرمجي عبر مراحل دورة الحياة هذه -في بعض الأحيان بصورة متكررة أثناء ضبطه أو إعادة تطويره- حتى يتوقف استخدامه في النهاية، كما يمكن التحقق من كل مرحلة في دورة الحياة للتأكد من صحتها قبل الانتقال إلى المرحلة التالية في الحالة المثالية.

دورة حياة تطوير البرمجيات: نموذج الشلال Waterfall

لنبدأ بإلقاء نظرة عامة على نموذج الشلال waterfall model الذي هو أحد نماذج تمثيل دورة حياة عملية تطوير البرمجيات Software Development Life Cycle كما ستجده في معظم كتب هندسة البرمجيات.

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

يمكننا استخدام عملية نموذج الشلال على أساس وسيلة لتحديد المهام المطلوبة مع دخل وخرج كل نشاط activity.

المهم هنا هو مجالات الأنشطة التي يمكن تلخيصها على النحو التالي:

تتضمن مرحلة إنشاء المتطلبات Establishing requirements التشاور والاتفاق مع أصحاب المصلحة حول ما يريدونه من النظام، ويُعبَّر عنها بما يسمَّى وثيقة المتطلبات statement of requirements.
تبدأ مرحلة التحليل Analysis بالنظر في وثيقة المتطلبات وتنتهي من خلال إنتاج مواصفات النظام system specification، حيث تُعَدّ المواصفات تمثيلًا رسميًا لما يجب على النظام فعله، ويُعبَّر عنها بعبارات مستقلة عن كيفية تطبيقها.
تبدأ مرحلة التصميم Design بمواصفات النظام وينتج عنها وثائق التصميم، كما تقدِّم هذه المرحلة وصفًا تفصيليًا لكيفية بناء النظام.
مرحلة التطبيق Implementation هي بناء نظام حاسوبي وفقًا لوثيقة تصميم معينة مع مراعاة البيئة التي سيعمل فيها النظام، مثل العتاد، والبرمجيات المتاحة للتطوير؛ كما قد تُنفَّذ مرحلة التطبيق على مراحل باستخدام نظام أولي يمكن التحقق من صحته واختباره قبل إصدار النظام النهائي للاستخدام.
توازن مرحلة الاختبار Testing النظام المُطبَّق مع وثائق التصميم ومواصفات المتطلبات، وتنتج هذه المرحلة تقرير قبول، أو قائمةً بالأخطاء والزلات البرمجية bugs التي تتطلب مراجعة عمليات التحليل، والتصميم، والتطبيق لتصحيحها، أي تُعَدّ مرحلة الاختبار عادةً المَهمة التي تؤدي إلى تكرار نموذج الشلال خلال دورة الحياة.
تتضمن مرحلة الصيانة Maintenance التعامل مع تغيرات المتطلبات، أو بيئة التطبيق، أو إصلاح الزلات البرمجية، أو نقل النظام إلى بيئات جديدة مثل ترحيل نظام من حاسوب مستقل إلى محطة عمل يونكس أو بيئة متصلة بالشبكة، كما سيعاد النظر في دورة حياة الشلال بصورة متكررة بسبب احتواء مرحلة الصيانة على تحليل التغيرات المطلوبة، وتصميم حل، وتطبيقه، واختباره على مدى حياة نظام برمجي جرت صيانته.

دورة حياة قاعدة البيانات Database Life Cycle

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

يمكننا فصل تطوير قاعدة البيانات عن عمليات المستخدم التي تستخدم قاعدة البيانات، أي تحديد وإنشاء تخطيط schema لتعريف البيانات في قاعدة البيانات.
يمكننا استخدام معمارية التخطيطات الثلاثة three-schema architecture مثل أساس لتمييز الأنشطة المرتبطة بالتخطيط.
يمكننا تمثيل القيود constraints لفرض دلالات semantics البيانات مرةً واحدةً في قاعدة البيانات عوضًا عن فرضها على كل عملية مستخدِم تستخدِم البيانات.

يمكننا باستخدام هذه الافتراضات والشكل السابق رؤية أنّ هذا المخطط يمثِّل نموذجًا للأنشطة وخرجها لتطوير قاعدة البيانات، فهذا المخطط ليس قابلًا للتطبيق على النهج العلائقي فقط وإنما يُطبَّق على أية صنف class من نظم إدارة قواعد البيانات DBMS أيضًا.

يُعَدّ تطوير تطبيقات قواعد البيانات عمليةً للحصول على متطلبات العالم الحقيقي real-world، وتحليل المتطلبات، وتصميم البيانات ووظائف النظام، ثم تطبيق العمليات في النظام.

جمع المتطلبات Requirements Gathering

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

تتضمن مرحلة إنشاء المتطلبات Establishing requirements التشاور والاتفاق بين جميع المستخدِمين بشأن البيانات الثابتة persistent data التي يرغبون في تخزينها مع الاتفاق على معنى عناصر البيانات وتفسيرها، كما يلعب مسؤول البيانات دورًا رئيسيًا في هذه العملية لأنه يستعرِض القضايا التجارية، والقانونية، والأخلاقية داخل المؤسسة التي تؤثِّر على متطلبات البيانات.

تُستخدَم وثيقة متطلبات البيانات data requirements document لتأكيد فهم المتطلبات مع المستخدِمين، فلا ينبغي أن تكون رسميةً أو مشفرةً بمستوى عالٍ لضمان سهولة فهمها.

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

يجب ألا تصِف المتطلبات كيفية معالجة البيانات، بل تصف عناصر البيانات، والسِمات attributes التي تمتلكها، والقيود المطبَّقة، والعلاقات التي تربط بين عناصر البيانات.

التحليل Analysis

تبدأ مرحلة تحليل البيانات Data analysis بوثيقة متطلبات البيانات، ثم ينتج عنها نموذج بيانات مفاهيمي conceptual data model. الهدف من التحليل هو الحصول على وصف تفصيلي للبيانات التي ستناسب متطلبات المستخدِم، بحيث يجري التعامل مع خصائص البيانات ذات المستوى العالي والمنخفض واستخدامها. تتضمن هذه الخصائص المجال المحتمل من القيم التي يمكن السماح بها للسمات، مثل: رمز مقررات الطالب student course code، وعنوان المقرر course title، ونقاط الائتمان credit points في قاعدة بيانات المدرسة على سبيل المثال.

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

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

التصميم المنطقي Logical Design

تبدأ مرحلة تصميم قاعدة البيانات بنموذج بيانات مفاهيمي وينتج عنها مواصفات التخطيط المنطقي logical schema الذي سيحدِّد نوع نظام قاعدة البيانات المطلوب -أي نوع شبكي، أو علائقي، أو كائني التوجه-.

لا يزال التمثيل العلائقي relational representation مستقلًا عن أي نظام إدارة قواعد البيانات DBMS، فهو نموذج بيانات مفاهيمي آخر.

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

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

يتجه مصممو قواعد البيانات الملمّون بقواعد البيانات العلائقية ولغة الاستعلامات الهيكلية SQL للذهاب مباشرةً إلى مرحلة التطبيق بعد إنتاج نموذج البيانات المفاهيمي، لكن لا يؤدي مثل هذا التحول المباشر للتمثيل العلائقي إلى جداول SQL بالضرورة إلى قاعدة بيانات تحتوي على جميع الخصائص المرغوبة، مثل: الكمال completeness، والسلامة integrity، والمرونة flexibility، والكفاءة efficiency، وقابلية الاستخدام usability.

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

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

يلخص الشكل الآتي الخطوات التكرارية الموجودة في تصميم قاعدة البيانات بناءً على النظرة العامة المقدَّمة، كما يكون الغرض الرئيسي من هذا الشكل هو التمييز بين الهدف العام للجداول التي يجب استخدامها عن التعريف المفصَّل للأجزاء المكوِّنة لكل جدول، حيث تُدرَس هذه الجداول واحدًا تلو الآخر رغم أنها ليست مستقِلةً عن بعضها البعض، كما سيؤدي كل تكرار يتضمّن مراجعةً للجداول إلى تصميم جديد، ويشار إلى هذه التصاميم الجديدة معًا باسم تصاميم القطع الثاني second-cut designs حتى لو تكررت العملية لأكثر من حلقةٍ واحدة.

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

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

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

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

ستحدِّد تعليمات لغة تعريف البيانات data definition language -أو DDL اختصارًا- الخاصة بلغة SQL التخطيط المنطقي في نهاية مرحلة التصميم، حيث تصف لغة DDL قاعدة البيانات التي يجب تطبيقها لتلبية متطلبات المستخدِم.

التطبيق Implementation

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

هناك مهام إضافية تتجاوز مجرد إنشاء تخطيط قاعدة بيانات database schema وتطبيق القيود، إذ يجب إدخال البيانات في الجداول، ومعالجة القضايا المتعلقة بالمستخدِمين وعمليات المستخدِم، كما يجب دعم الأنشطة الإدارية المرتبطة بالجوانب الأوسع لإدارة بيانات الشركة.

نريد معالجة أكبر عدد ممكن من هذه القضايا الموضَّحة أدناه داخل نظام إدارة قواعد البيانات تماشيًا مع نهج نظم إدارة قواعد البيانات.

يتطلب تطبيق التخطيط المنطقي عمليًا في نظام إدارة قواعد البيانات DBMS معرفةً مفصلةً للغاية بالميزات والفوائد المحددة التي يجب تقديمها من قِبَل نظام إدارة قواعد البيانات.

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

تحقيق التصميم Realizing the Design

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

تتمثل إحدى طرق تحقيق ذلك في كتابة تعليمات لغة SQL DDL المناسبة في ملف يمكن لنظام إدارة قواعد البيانات DBMS تنفيذه، بحيث يكون هناك سجل مستقل أو ملف نصي من تعليمات لغة SQL التي تعرِّف قاعدة البيانات؛ أما الطريقة الأخرى فهي العمل تفاعليًا باستخدام أداة قاعدة بيانات مثل الأداتين SQL Server Management Studio أو Microsoft Access.

مهما كانت الآلية المستخدَمة لتطبيق التخطيط المنطقي، فالنتيجة هي أن قاعدة البيانات -مع الجداول والقيود- معرَّفة ولكنها لن تحتوي على بيانات لعمليات المستخدِم.

ملء قاعدة البيانات Populating the Database

يوجد طريقتان لملء الجداول بعد إنشاء قاعدة البيانات؛ إما من بيانات موجودة أو من خلال استخدام تطبيقات المستخدِم المطوَّرة لقاعدة البيانات.

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

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

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

يُسمّى نقل كميات كبيرة من البيانات الموجودة إلى قاعدة بيانات بالتحميل المجمَّع bulk load، وقد يتضمن التحميل المجمَّع للبيانات كميات كبيرةً جدًا من البيانات المُحمَّلة أي تحميل جدول في نفس الوقت، لذلك قد تجد وسائل في نظام إدارة قواعد البيانات DBMS لتأجيل فحص قيد حتى نهاية التحميل المجمَّع.

إرشادات لتطوير مخطط ER

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

وثّق جميع الكيانات المكتشَفة خلال مرحلة جمع المعلومات.
وثّق جميع السمات التي تنتمي إلى كل كيان، وحدّد المفاتيح المرشَّحة candidate keys، والمفاتيح الرئيسية primary keys، كما تأكد من اعتمادية جميع السمات التي ليست مفاتيحًا non-key attributes لكل كيان بصورة كاملة على المفتاح الرئيسي.
طوِّر مخطط ER الأولي وراجعه مع الأشخاص المناسبين، وتذكَّر أن هذه عملية تكرارية.
أنشِئ كيانات -أي جداول- جديدة للسمات متعددة القيم والمجموعات المكرَّرة، ثم ضمِّن هذه الكيانات- أي الجداول- الجديدة في مخطط ER، وراجع ذلك مع الأشخاص المناسبين.
تحقَّق من نمذجة الكيان العلائقي ER عن طريق تطبيق عملية التوحيد normalizing على الجداول.

ترجمة -وبتصرّف- للمقال Database Development Process لصاحبته Adrienne Watt.