من السؤال إلى البيانات

الشيء الرائع في قاعدة البيانات أنها تتيح لك طرح سؤال لم تفكر فيه من قبل والحصول على إجابة. — Michael Stonebraker

في هذا الفصل، نريد أن نلقي نظرة موجزة على كيفية إنشاء مجموعات البيانات وقواعد البيانات.

من هذا الفصل ينبغي أن تتذكر ما يلي:

• نمذجة البيانات (data modeling) خطوةً في تحليل تطبيقات تكنولوجيا المعلومات؛
• نهجًا تدريجيًا لتطوير قواعد البيانات؛
• نموذج البيانات المفاهيمي والمنطقي والفيزيائي.

ابدأ بسؤال

في الفصل التمهيدي عن SQL شرحنا بإيجاز بالفعل كيف يمكننا، باستخدام SQL، الاستعلام من مجموعة بيانات موجودة. وفي الفصول التالية سنتعمق أكثر في الإمكانات التي تقدمها SQL. وبالتوازي، نريد شرح تحدٍّ مختلف، ألا وهو بناء مجموعات البيانات وقواعد البيانات. وسنتناول الأسئلة التالية:

• كيف تُنشأ مجموعات البيانات وقواعد البيانات؟
• ما العملية التي تؤدي إلى قاعدة بيانات مبنية جيدًا؟
• ما الذي يحدد ما إذا كانت قاعدة البيانات مبنية جيدًا؟

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

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

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

طلب البيانات

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

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

التحليل

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

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

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

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

وفي دورات لاحقة ستتعلم أكثر عن مفهوم منهجية التطوير وتستكشف صيغًا مختلفة (منها Agile وDevOps وwaterfall وrapid application development) بعمق.

نمذجة البيانات

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

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

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

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

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

وفي عمليتنا نميّز ثلاثة أنواع (طبقات) من نماذج البيانات: المفاهيمي والمنطقي والفيزيائي.

نموذج البيانات المفاهيمي

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

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

وفي رسم النموذج المفاهيمي، نحاول الإجابة عن الأسئلة التالية:

• ما المفاهيم المهمة لتطبيقنا؟
• كيف سنصف تلك المفاهيم؟
• ما الروابط القائمة بين هذه المفاهيم؟

وينشأ نموذج البيانات المفاهيمي عادةً من تعاون بين المحللين والمستخدمين. فخلال ورش العمل والمقابلات ونحوها، يصف المستخدمون المعلومات ذات الصلة.

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

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

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

سنعود لاحقًا إلى مزيد من التفاصيل حول نموذج البيانات المفاهيمي وكيفية إنشائه.

نموذج البيانات المنطقي

بمجرد أن تكون لدينا رؤية للمعلومات، وبالتالي للبيانات أو الوقائع أو البيانات الملموسة ذات الصلة بالمستخدمين، نحاول الإجابة عن السؤال التالي: "أي نموذج قاعدة بيانات هو الأنسب لتطوير قاعدة بياناتنا؟". ففي الواقع، هناك عدة نماذج لقواعد البيانات (يجب عدم الخلط بينها وبين نماذج البيانات)، حيث يحدد كل من نماذج قواعد البيانات طريقة معينة لهيكلة البيانات. ولكل نموذج قاعدة بيانات مزاياه وعيوبه، وبالتالي تطبيقاته المحددة، لذا يلزم النظر فيه جيدًا.

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

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

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

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

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

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

وهناك فصل كامل مخصص أيضًا للنموذج المنطقي.

نموذج البيانات الفيزيائي

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

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

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

ويترجم الشكل الأخير نموذج البيانات العلائقي (المنطقي) السابق إلى نموذج بيانات فيزيائي خاص بـ PostgreSQL. ويتضمن الرسم الآن تفاصيل ملموسة كثيرة، مثل أنواع البيانات (char(8) وsmallint...). وبالمناسبة، أُنشئ بأداة أخرى (DBSchema، انظر لاحقًا).

سنعود إلى نموذج البيانات الفيزيائي في فصل لاحق.