مذكرات حول تصمبم قواعد البيانات وتطبيقاتها

ما شاء الله... أكثر من أربع وعشرين ساعة وعدد الاستجابات مشجع جداً... (صفر)... هذا يعد بالكثير حقاً...

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

ولكن ما هي قواعد البيانات؟

قاعدة الجنود هي المكان الذي يحوي الجنود، وقاعدة البيانات هي المكان الذي يحوي البيانات. في حالة الأكسس (وما شابهه) قاعدة البيانات هي بشكل أساسي الجداول التي تحوي البيانات.

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

إذاً، ما هو الأكسس بالضبط؟

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

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

أمثلة؟... من الصعب عدم العثور على مثال! أنت برمجت بالسي؟ هي طبقة تخفي عنك (وتريحك) من تفاصيل لغة التجميع (assembly)، المترجم (compiler) يقوم بدور البطولة، ولغة التجميع نفسها هي طبقة تعزلك عن لغة الآلة، المجمع (assembler) له البطولة هاهنا. تعرف نظام التشغيل؟ لا أقصد الإهانة بالطبع، الويندوز هو طبقة تفصلك عن تعقيدات العتاد الصلب وتعريفاته. نعم، نعم، أعلم أن البعض قد درس الشبكات وهو يتذكر طبعاً المرجع الشهير OSI، وطبقات TCP/IP الأربع (أو الخمس حسب بعض المراجع). أصبح الإنسان مرفهاً هذه الأيام، ومستعداً للتضحية بكثير من الفهم من أجل القليل من الراحة... لكن هذا موضوع آخر.

لماذا إذاً لا نستعين بطبقة بيننا وبين نظام التشغيل وملفاته تزيح عنا بعض العبء، وفي نفس الوقت نزودها بالكثير من الميزات التي تخلصنا من المشاكل القديمة؟ هذه الطبقة الجديدة هي، بالضبط كحالة المترجمات وأنظمة التشغيل، مجرد برامج؛ لكنها برامج خاصة ومعقدة جداً. كلمة جداً هنا تعني في الواقع جداً جداً، لأن هذه البرامج من المفترض أن تعد مرة واحدة لتقوم بمهمة شاقة، ثم يستخدمها الجميع ممن ليس لديه الوقت ولا الإمكانية لأداء هذه المهام الشاقة؛ ليس كل مبرمج مستعد لأن يتعلم تفاصيل التعامل مع القرص الصلب حتى من خلال طبقة التعريف المزودة من مصنع القرص الصلب، هو يريد فقط أن يقول (افتح) باستخدام دالة من دوال نظام التشغيل على سبيل المثال، ويقوم نظام التشغيل بالمهمة. الفكرة مشابهة في حالة قواعد البيانات، ولكي تدرك صعوبة هذه البرامج الخاصة التي أعدت خصيصاً من أجل قواعد البيانات، ربما تتذكر أن القليل من الشركات أنتجت القليل من هذه البرامج، بعضها أنت تعرف أسماءها جيداً، نعم نعم، Oracle، Microdsoft، Sybase، IBM والقائمة لا أظنها تطول كثيراً. كإجابة على السؤال الأول (لمن لم يزل ينتظر الإجابة): أكسس هو واحد من هذه البرامج من Microsoft طبعاً.

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

(يتبع إن شاء الله)...

إذأً، فالأكسس هو DBMS آخر... ذلك اختصار DataBase Management System، مصطلح ربما مر عليك مراراً، ويعني كما أسلفت من قبل، نظام (أو برنامج) إدارة قواعد بيانات. لم تكن أشكال قواعد البيانات (كيفية ترتيب البيانات) وبالتالي برامج إدارتها كما نعرفه الآن في الأكسس مثلاً، لكن هذا النوع الذي يرتب البيانات على شكل جداول ذات صفوف وأعمدة ويبني العلاقات بينها بواسطة عمود مشترك أو أكثر، يدعى بقواعد البيانات العلائقية (Relational Databases)، وبرامج إدارته تدعى RDBMS، الـ® في البداية من أجل كلمة (Relational). كل ما تعرفه من قواعد بيانات الآن ومن برامج إدارتها من أمثلة الأوراكل والأكسس ينتمي لهذا النوع.

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

الفرق بين قواعد البيانات وأنظمة إدارتها يشبه الفرق بين الملفات وأنظمة إدارتها (نظم التشغيل)... هذه نتيجة أخرى جيدة... لن يضرك أن تتذكر ذلك.

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

قواعد بيانات، برنامج إدارة قواعد بيانات... تطبيق قواعد بيانات.

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

الفقرة السابقة تثير بعض الأسئلة:

هل هذا يعني أن النماذج والتقارير تشكل ما تسميه تطبيق قاعدة بيانات؟

نعم، المزيد من التوضيح يلحق إن شاء الله حالاً.

إذا كانت قواعد البيانات تختلف عن تطبيقات قواعد البيانات، وكل منشأة تحتاج إلى قاعدة بيانات، لماذا إذاً تشتري المنشآت هذه التطبيقات؟ لماذا لاتتعامل مباشرة مع قاعد البيانات؟

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

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

(يتبع إن شاء الله)...

السلام عليكــم ورحمـة الله وبركاتــه ،،

الاخ العزيز أحمد مبارك الحيقي

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

يشرفني ان اكون احد المتابعين لموضوعك استاذ احمد .. وفقك الله

أخى أحمد المتألق

معلومات غاية فى الأهمية والقيمة العلمية .. ليت لكل من يقرأها يعمل بها.

وليت الله يضاعف لك فى الأجر والثواب .. ويزيدك مثله علماً نافعاً .. آمين.

تحياتى

محمد ندا

الأخ الفاضل يوسف أحمد... يشرفني بالتأكيد أن تكون أول زائر، ويسعدني أن تكون معنا... لا نستغني عن خبرتك بالـتأكيد (وأنا لست أستاذاً، مجرد أخ وجد لديه ما يقوله فأحب أن يشارك به إخوانه)....

وهذا تحرير بعد رؤيتي لمشاركة أخي محمد ندا، مرحباً بك، سعيد بمشاركتك...

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

أنت تريد أن تقول شيئاً، وأنا أعلم ما هو: هل علينا أن نعلم كل هذا؟ لماذا لا نتجه مباشرة إلى الناحية العملية، ونتعلم (كيف) نصنع الأشياء؟ الوقت لا يتسع لكل هذا التنظير، والناس يسبقوننا... أنت تضيع وقتنا!...

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

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

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

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

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

(يتبع إن شاء الله)...

متابعون بحماس ......

فى انتظار الحلقة التالية أخى أحمد

تحياتى

محمد ندا

أكرر السؤال: هل SQL لغة برمجة؟

الإجابة القصيرة (لمن كان وقته ضيقاً): لا...

الإجابة الطويلة (لمن كان ينوي أن يكمل القراءة): لا. ليست SQL بصورتها الأصلية من لغات البرمجة بالمعنى التقليدي للغات البرمجة؛ لماذا؟ لأنها في الأصل لا تملك خصائص لغات البرمجة. هي لغة تحديد (ماذا) تريد من بيانات أكثر من (كيف) تعالج البيانات، وهي في الأصل لا تدعم الإجرءات ولا البنى البرمجية التي تدعمها أية لغة برمجة تحترم نفسها (مثل التكرارات والجمل الشرطية). أقول في الأصل لأن العديد من الإضافات قد تمت على هذه اللغة من قبل المؤسسات المعيارية (التي تضع المعايير standards)، ومن قبل كل منتج لبرنامج إدارة قواعد بيانات. على سبيل المثال Oracle أنشأت لغة البرمجة PL/SQL وتعني SQL الإجرائية، والتي لا تعدو أن تكون SQL مع دعم الإجراءات والبنى الأخرى المشار إليها آنفاً.

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

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

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

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

هل تعلم القدر الكافي عن قواعد البيانات؟ عن البرمجة؟ عن لغة برمجة واحدة على الأقل (ولتكن VBA، لا مانع)؟ أجب عن ذلك، ثم عد إلى السؤال الأول في هذه السلسلة: هل أنت مبرمج (من أجل) قواعد البيانات؟

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

حتى ذلك الحين: هل أنت...........؟!

(يتبع إن شاء الله)...

أخى الكريم أحمد

مجهود كبير ومثابرة هادئة ... إلى الأمام.

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

هأنذا قرأت الحلقة الخامسة ...

وفى انتظار باقى الإبداعات فى الحلقات التالية.

وأقترح عليك أن يكون المثال "قاعدة بيانات الموظفين" لما بها من تباين وتنوع فى البيانات والقوانين والقواعد الحاكمة للكثير من العلاقات وشكل الارتباط بينها.

تحياتى

محمد ندا

السلام عليكــم ورحمـة الله وبركاتــه ،،

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

جزاك الله كل خير .. اخوك ابو عدنان

أخي العزيز محمد ندا... بورك فيك، لولا ردودك لظننت أنني أكلم نفسي...

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

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

لنعد الآن إلى تلك (اللمسات)، ونتحدث قليلاً عن البرمجيات بشكل عام، وعن تطبيقات قواعد البيانات بشكل خاص...

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

مرة أخرى، تطبيق قاعدة بيانات يحوي جزءين: قاعدة البيانات التي عرفنا أن برنامج إدارة قاعدة البيانات (سندعوه باسمه DBMS من الآن فصاعداً) يديرها وفيها تجد كل البيانات، والتطبيق الذي يتعامل المستخدمون مع قاعدة البيانات من خلاله، فهو يشكل واجهة أمامية يبنيها المبرمج من أجل المستخدم العادي. لماذا يبني المستخدم مثل هذه الطبقة الأمامية؟ قلنا من قبل أن ذلك يجنب المستخدم العادي أي تعقيدات للتعامل مع الـ DBMS، مثل ضرورة استخدام الـSQL أو أي غلاف خارجي لها. كذلك فإن هذه الواجهة من المفترض أن تخدم عدة أغراض بكفاءة؛ باختصار مخل، يجب أن تجعل عملية إدخال البيانات (واسترجاعها بعد المعالجة):

1. دقيقة (خالية من الأخطاء) قدر الإمكان.

2. سهلة قدر الإمكان.

3. سريعة قدر الإمكان.

4. (ممتعة قدر الإمكان)؟ نحن لا نصمم ألعاباً هاهنا... لا أحد يتمتع بإدخال البيانات، صدقني. بعض المبتدئين يحاول أن يجعل برنامجه حديقة ملاهي على حساب العمل الحقيقي...

الترتيب المذكور ليس حصرياً، ويختلف باختلاف نوع التطبيق. أحياناً تكون السرعة هي الأولى على حساب أي عامل آخر، وهكذا. بالمناسبة أيضاً، من أجل ربط ما تقرأه هنا بالمصادر التي من الممكن (من الضروري؟) أن تراجعها فيما بعد، تسمى هذه الواجهة عادة بالطرف الأمامي (Front-end)، بينما تسمى قاعدة البيانات بالطرف الخلفي (Back-end). نحن في هذه السلسلة يهمنا أكثر هذا (الطرف الخلفي)، من الواضح أن الخلف لا يعني دائماً الأقل أهمية (أذكر أيام الجامعة، كان يحلو لبعض أذكى الطلبة الجلوس في الخلف دائماً)...

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

لنسمِّ مجموع قاعدة البيانات مع التطبيق نظام قواعد بيانات... إذا كانت مكونات هذا النظام (الطرف الأمامي والخلفي) تشكل وحدة واحدة، وبالطبع تقع في جهاز واحد، فإن هذا النظام يسمى نظام قواعد بيانات مكتبي (Desktop Database System). نعم، كما تقول بالضبط، الأكسس ينتمي إلى هذا النوع من الأنظمة، أنت تجد الجداول مع النماذج مع التقارير في نفس الملف وتدار بنفس البرنامج. نعم نعم، يمكنك الآن تقسيم قاعدة البيانات ووضع الطرف الخلفي (الجداول) في ملف منفصل على جهاز ما، في حين تقع بقية المكونات في ملف آخر (على جهاز آخر ربما). لكن هذا مجرد تطوير لا يغير من حقيقة أن الأكسس في الأصل هو نظام قواعد بيانات مكتبي. لاحظ أنك يجب أن تحتفظ بارتباطات للجداول في ملفك الثاني.

إذا كان الطرف الخلفي مستقلاً تماماً ببرنامج إدارته، والطرف الأمامي له برامجه الخاصة التي تشغله، فإن هذا النظام يسمى نظام قواعد بيانات زبون – خادم (أو عميل – ملقم)، وبالفصيح (Client – Server Database System). لاحظ أن الطرفين قد يجتمعان في نفس الجهاز وإن كان الأصل أن يكونا منفصلين على جهازين مختلفين على شبكة محلية أو خارجية. مثال؟... من أشهر الأمثلة على ذلك أنظمة Oracle. على الرغم من توفر نسخ من أوراكل للاستخدام المكتبي على جهاز واحد (Oracle Personal)، لكن الغالب هو استخدام نسخة Oracle Server على جهاز، وتحميل Oracle Client على بقية الأجهزة لتشغيل النماذج والتقارير. أنا الآن أتكلم عن الصورة الكلاسيكية، على الشبكات المحلية. الزبون يرسل البيانات عبر الشبكة إلى الخادم (حيث الـ DBMS) أو يطلب البيانات من الخادم عبر الشبكة، والخادم (يخدم) بالطبع، أعني يستجيب للطلبات، وبما أنه DBMS، فهو يقوم أيضاً بالوظائف الأخرى التي لم نسهب فيها كثيراً من قبيل التأكد من أمان وسلامة قاعدة البيانات عبر قواعد وشروط السرية والتكامل التي تم تحديدها مسبقاً.

إذاً، فإن لدينا في هذا النظام الثاني طبقتين منفصلتين، ولأن متخصصي الحاسوب (كغيرهم من المتخصصين في كل المجالات) يحبون المصطلحات التي تجعل الأمور تبدو معقدة، فإنهم رأوا هذا الشكل وقالوا: هذا Two-Tier Architecture، أي بنية ذات طبقتين. أحياناً تكون معظم العمليات الحسابية والمنطقية، التي تشكل جزء معالجة البيانات الذي تكلمنا عنه سابقاً، في جانب الـclient (أي الزبون)، وهنا يسمى هذا الزبون سميناً (لا تضحك رجاءً، اسمه في المصادر الرسمية Fat-client)، أو أحياناً يسمونه Rich-client أي الزبون الغني (دعنا نسمه الزبون الدسم). إذا كانت معظم المعالجة تتم في جانب الخادم (server)، فإن الزبون يسمى نحيفاً (Thin-client). لا أدري من أين يأتون بهذه التسميات، لكن من المعروف أن متخصصي الحاسوب عندهم هواية أخرى غير التعقيد، وهي التسميات الطريفة.

من أجل تكملة الموضوع فقط (على الرغم من أن هذا لا يهمنا هنا)، هنالك الآن Three-tier بل و N-tier architectures، أي ثلاث أو عدد غير محدود من الطبقات، ومن أمثلته وجود الواجهة على جهاز مستخدم الإنترنت (صفحة في مستعرض الوب)، التي تتعامل مع خادم وب (web server) على جهاز آخر، وهذا الأخير بدوره يطلب البيانات من خادم قواعد بيانات (database server)، حيث الـDBMS، وقد يكون على جهاز ثالث. لاحظ أن المسافة الفعلية بين هذه الطبقات غير محددة؛ قد تكون سنتيمترات قليلة في نفس الجهاز، مترات معدودة في نفس الغرفة، أو كيلومترات كثيرة في مدن مختلفة من العالم.

حسناً، قد أخذنا الكلام قليلاً، لكن حتى العودة بإذن الله، حاول أن تفكر مرة أخرى: هل أنا.........؟

(يتبع إن شاء الله)...

موضوع أكثر من رائع أخي الكريم , وفقك الله وجعل ماتكتبه في موازين أعمالك يوم لقاه .

تحياتي العطرة لك.

أخى أحمد ..

المعلومات اليوم جمعت بين الثراء فى المعلومة .. والجاذبية فى الطرح.

أقترح على إخواننا المشرفين تثبيت الموضوع لحين انتهائه.

وأقترح أن يتم عمل مجمع منه فى النهاية فى ملف واحد لتعم الاستفادة.

تحياتى

محمد ندا

بارك الله فيك وجزاك الله خير

ونفع الله بعلمك

الله يعطيك الصحة والعافيه

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

دعونا الآن نتقدم قليلاً ونلمس الماء بأطراف أصابعنا... كفى لهواً على الشاطئ...

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

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

على رسلك يابني، لو ذهبت تعدّ بيضة مقليّة لقضيت وقتاً أطول قبل أن تصل إلى مرحلة الـ(طشش)، عندما تكسر البيضة على الزيت... (أوردها سعد وسعد مشتمل... ما هكذا يا سعد تورد الإبل)!

ما يفعله الكثير من أمثال أحمد، أنهم يكسرون دورة الحياة... لا أتكلم عن دورة حياة البعوضة هاهنا، ولكن عما اصطلح الناس عليه لوصف مراحل إعداد التطبيقات البرمجية. تميزت البرمجيات بأنها منتجات تعتمد إلى حد كبير على خبرة ومهارة المبرمج، ولا يمكن أتمتة صناعتها كما هو الحال في بقية المنتجات. إنتاج البرمجيات يتداخل فيه الفن مع العلم بشكل يصعب معه التمييز بينهما. اختلف الوضع قليلاً الآن، وحاول الناس (تقنين) هذه العملية باستنباط قواعد لإنتاج البرمجيات من واقع الخبرة المتراكمة في الماضي. هذه القواعد أثبتت إلى حد ما أنها تعمل بشكل أو بآخر، على الرغم من أنها ليست مطلقة، ومرنة إلى حد كبير. تم ترتيب هذه الأفكار وجمعها في شكل عمليات (processes)، وجمع هذه العمليات في شكل نماذج (models)، ولهذا تجد الآن ما يسمى بـ(software process model) في مادة هندسة البرمجيات. لن أترجم المصطلح السابق لأنني لا أريد أن أضيف مشكلة أخرى إلى مشاكل تعريب المصطلحات التي تزخر بها المصادر العربية.

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

من أشهر النماذج الكلاسيكية التي تجدها في أدبيات هندسة البرمجيات، نموذج يرتب العمليات الأساسية في إنتاج البرامج تدفقياً (يدعونه النموذج الشلالي Waterfall Model). هذا النموذج يقترح أن دورة حياة إنتاج البرنامج تمر في مراحل محددة، مستقلة عن بعضها، ومتتابعة. اكتشفوا بالطبع أن هذا غير ممكن دائماً، وأدخلوا الكثير من التعديلات مما أنتج نماذح أخرى كالنموذج المتكرر (Iterative) و (Component-based Model). هذا ليس مهماً الآن. سأتبنى في هذا النقاش النموذج الكلاسيكي لأنه أوضح وأقرب إلى منطق تسلسل العمليات. لدي رسم اخترته لكم لأنه من أوضح ومن أكثر الأشكال تعبيراً عن دورة حياة البعو... أقصد البرنامج، لكن لا أعلم كيف يمكن إضافته هاهنا. على كل حال الشكل عبارة عن خمس مربعات مرتبة على هيئة شلال، أي أن المربع الأول في اليسار (Analysis)، ينبع منه سهم إلى اليمين وإلى الأسفل قليلاً، ليأتي المربع الثاني (Design)، ثم تحته إلى اليمين قليلاً (Implementation)، ثم (Testing)، وأخيراً (Deployment).

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

1. التحليل.

2. التصميم.

3. التنفيذ.

4. الاختبار.

5. التسليم.

يفترض النموذج أيضاً أن كل مرحلة تنتهي تماماً (بمنتج ما)، قبل أن تبدأ المرحلة التي تليها. مثلاً، التحليل ينتهي بمستند SRS (System Requirements Specification) أو مواصفات متطلبات النظام. هذا طبعاً في المشاريع الرسمية الكبيرة كما أسلفنا، على مستوى شركات برمجة وفرق مبرمجين وغير مبرمجين، لكنك مطالب بشكل أو بآخر بكل هذا ولو على مستوى مصغر. بالمناسبة، رسمياً، وفي الشركات الكبيرة، لكل عملية فريق متخصص من شخص أو أكثر، حسب حجم ونوعية التطبيق والشركة. لذلك تسمع عن وظائف مثل محلل أنظمة ومصمم ومبرمج. وكثيراً ما يشار إلى المبرمج في الوسط ببعض الاستهانة على أنه ليس أكثر من (مشفر coder). ما الذي يعنيه كل هذا بالنسبة لنا هنا ونحن نتحدث عن مشاريع صغيرة (على ضرب نظام مخزني أو نظام شؤون موظفين على مستوى محل أو شركة صغيرة)؟ يعني الكثير لو لاحظت... يعني أنك هنا تلعب دور الجميع ولا فخر: أنت المحلل والمصمم والمبرمج والمختبر والمسلم. ما شاء الله، الله يعطيك العافية. تذكر صديقنا أحمد في بداية الحلقة؟ لقد كان غافلاً عن هذه الحقيقة المروعة، ولذلك لم يحسن لعب الدور...

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

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

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

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

(يتبع إن شاء الله)...

الأخ الفاضل

احمد

طريقة تقديمك للموضوع جميلة بالإضافة إلى قيمة المعلومات

ننتظر إستكمالك المشوار

أجمل تحية

الأخ الكريم (just now)، سررت لمرورك، أسأل الله العون والسداد...

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

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

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

عند النظر إلى النظام البرمجي من زاوية المهام التي يؤديها، وتسلسل هذه المهام، وتدفق البيانات من مهمة إلى أخرى، فإنك تصمم ما يعرف بالنموذج الوظائفي (functional model)، الذي يعلم الأكثرون أحد أشهر أشكاله، وهو مخطط تدفق البيانات (DFD-Data Flow Diagram). هذا الشكل يوضح المهام التي يقوم بها النظام ممثلة بمربعات، يربط بينها أسهم، مع التركيز على تحديد البيانات التي تدخل كل مربع والتي تخرج منه إما إلى مربع (مهمة) أخرى، أو إلى مكان ما تحفظ فيه، أو إلى مخرجات تطبع.

دعني أقودك الآن إلى زاوية أخرى ننظر منها إلى النظام البرمجي، وهذه الزاوية تهمنا كثيراً هنا لأن تركيزنا سيكون عليها بإذن الله... المهم هنا هو بيانات النظام وبنيتها، وليس المهام التي سوف تؤدى عليها. هذا المنظور جزء لا يتجزأ من أنظمة قواعد البيانات. في هندسة البرمجيات، يسمون هذا التصميم (Semantic Data Model)، وفيه يبينون البنية المنطقية للبيانات في النظام. من أشهر أدوات هذا النوع من التصميم، مخطط الكائنات والعلاقات (ERD-Entity Relationship Diagram). مرة أخرى، سنؤجل الكلام عن هذا لما بعد، لأنه موضوعنا الأساسي، وأريد أن أنتهي من ذكر بقية المراحل على عجل حتى نعود إلى موضوعنا بمزاج رائق (أرجو ألا يكون مزاجك قد تعكر منذ الآن...).

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

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

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

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

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

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

1. تصحيح الأخطاء.

2. تعديل بعض الأجزاء.

3. إضافة أجزاء جديدة.

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

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

(يتبع إن شاء الله)....

أدام الله عليك الصحة ومتعك بالعافية وغفر لك ولأبويك ... آمين.

ما زالت لدى حلقة لأقرأها ... ولكن لانشغالى اليوم أستميحك أن أقرأ غدا إن يشاء الله.

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

تحياتى

محمد ندا

بارك الله فيك أخي أحمد ،،،

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

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

أخي أحمد أسأل الله أن يرحم والديك جزاء ماقدمت من هذا الخير ووالدي المسلمين جميعا ،،

الأخ محمد ندا، كفى بك متابعاً جيداً، أسأل الله أن يبارك فيك...

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

ذكرنا مراراً أن تطبيقات قواعد البيانات تتكون من شقين: التطبيق، وقاعدة البيانات. دعونا الآن نتناسى التطبيق، ونهتم بقاعدة البيانات...

اسمح لي أن أقدّم بعض التوضيح لما نحن بصدده، وأرجو أن تتذكر هذا دائماً: قبل أن تخطو الخطوة ينبغي أن تدرك جيداً ما هو محلها من الإعراب، من أين تبدأ وإلى أين تنتهي. هذا الوضوح في الأفكار هو ما يميز ما نسميه بالمنهجية... لكي تبني قاعدة البيانات ينبغي أن تمر على مرحلتين، الأولى هي التحليل والثانية هي التصميم. لا تخلط بينهما. التحليل كما أسلفنا يعني جمع كل ما يمكن من فهم المتطلبات. هنا تشترك قاعدة البيانات مع التطبيق في الحاجة إلى التحليل، وفي مفهوم التحليل، وفي آليات التحليل (طرقه ووسائله لمن كان يكره المصطلحات السمجة). بعد أن تفهم النظام جيداً، تأتي مرحلة التصميم. بالنسبة لقواعد البيانات العلائقية، الهدف النهائي من التصميم هو تحويل الفهم الذي حصلت عليه في مرحلة التحليل إلى مجموعة من الجداول (السوية). ما معنى (سوية)، وكيف تصل إلى جداول (سوية)؟ هذا موضوع آخر في منتهى الأهمية، بل هو في قلب تصميم قواعد البيانات، لذا أنصحك أن تكون موجوداً عندما نتحدث عنه فيما بعد بإذن الله. في سبيل الوصول إلى هذا الهدف، هناك مجموعة من الأدوات التي قد تساعدك، من أبرزها وأكثرها انتشاراً مخطط الكائنات والعلاقات ERD (Entity Relationship Diagram).

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

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

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

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

(يتبع إن شاء الله)...

مضت منذ آخر حلقة بضع أيام... وقد دل عدد الردود والاقتراحات المقدمة خلال هذه الأيام على مدى الاهتمام الذي يحظى به موضوع تحليل وتصميم قواعد البيانات من قبل الأعضاء والزوار الكرام... ولمن كان يتساءل، فقد بلغ عدد الاقتراحات التي طلبتها في الحلقة الماضية (صفراً ،zero، 0)، وعدد الردود (صفر، zero، 0)، وهذا رقم قياسي كما ترى... فكرة السلسلة من البداية هي تبادل النقاش، لكن لا بأس، من الممكن أن نتبادل النظرات عوضاً عن ذلك...!

على كل حال، دعونا نمضي لنتحدث عن التحليل من جانب عملي أكثر... لدينا الكثير لنتذاكره عن تصميم قاعدة البيانات، لكنني أتبع هاهنا أسلوب (اترك الحلو للنهاية)، وأنا أفترض أن موضوع التصميم هنا (حلو)...

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

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

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

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

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

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

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

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

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

(يتبع إن شاء الله)...

أخى أحمد

أولاً أعتذر عن تقصيرنا فى الرد عليك .. هذا إن كنت أنا أحد المقصرين.

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

ولم أقوم بالسؤال عن الجديد لأننى أقدر أن لكل منا مشاغله .. فلا يجوز أن أطالبك بالجديد الذى هو تطوعاً منك أساساً حتى لا أثقل عليك.

وبالنسبة لإقتراح الموضوع فأنا لم أقترح نظراً لسابق إقتراحى كما تفضلت وأنصفتنى.

وأما سبب هذا الإقتراح لنظام شئون الموظفين فقد كان لأسباب تقترب من أسبابك وهى:

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

ثانياً: أردت أن أكون بعد الله عوناً لك لأننى ملم بهذا الجانب كتحليل نظم إلى حد ما .. فلم أرغب أن أكون عبئاً عليك بأن أكون متلقياً فقط.

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

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

خامساً وأخيراً: الموضوع يزداد حلاوة وأسلوبك (والله ليست مجاملة) يزداد جمالاً.

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

على بركة الله توكل

تحياتى

محمد ندا

بســم الله الـرحمــن الرحيــم

السلام عليكــم ورحمـة الله وبركاتــه ،،

بارك الله بك أخي الكريم احمد وجزاك الله كل خير وأثابك الله على هذا الجهد الكبير والحيوي ،،،

اخي العزيز نحن جميعا متابعين باهتمام ما تقدمه لنا مشكورا مأجورا ...

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

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

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

تقبل تحياتي واحترامي وشكرا لك والشكر موصول للاخ محمد ندى على اهتمامه ايضا .

ابو عدنان ..

السلام عليكــم ورحمـة الله وبركاتــه ،،

بارك الله فيك اخي الكريم وجعل جهدك في ميزان حسناتك ونفعك ونفع بك.

------------

بناء على اقتراح استاذنا يوسف احمد فقد تم تثبيت الموضوع لسهولة الطرح المتابعة.

طبتم واهتديتم

رقم الحلقة (11)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(يتبع إن شاء الله)...