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

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

اريد فقط ان اتشارك ( إن سمحت لي ) معك ببعض الافكار و التساؤلات حول مراحل تصميم مخطط قاعدة البيانات

و لا ادري إن هذا الوقت المناسب لطرح تساؤلي في سياق الحديث ...

المسألة انه لدي تساؤل مزمن حول التسلسل الافضل لتصميم مخطط قاعدة البيانات ...

انت تعرف ان عملية تصميم مخطط قاعدة البيانات او Database Design تمر بشكل عام بثلاثة مراحل (و هنا اريد ان اقتصر الحديث على قواعد البيانات العلائقية) :

اولاً Concepual Design

ثانيا Logical Design

ثالثاً Physical Design

و هنا تأتي الفكرة التي اريد ان اسأل عنها ...

انا اقوم بالتسلسل التالي عن تصميم اي مخطط قاعدة البيانات

في الـ Concepual Design:

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

تصميم مخطط الـ ER Model

اختيار DBMS (كخطوة إختياريه)

ثانيا Logical Design

تحويل مخطط الـ ER model الى مخطط علائقي Relational Model

تطبيع البيانات Normalization

ثالثاً Physical Design

استخدام اوامر SQL لبناء قاعدة البيانات على الـ DBMS المختار

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

تحياتي ...

تعقيب الحلقة (11)

أخى الكريم ... والكريم ... الكريم جداً ..... أحمد

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

ثم أشكرك لمتابعتك لردودنا نحن قارئيك ومتابعيك.

وقد عظمت يا أخى من شأنى حتى أخجلتنى وليتنى أهل لذلك ..

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

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

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

وإلى الملتقى القريب إن شاء الله.

تحياتى

محمد ندا

تعقيب ثان على الحلقة رقم (11)

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

إخوانى الكرام

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

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

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

تحياتى

محمد ندا

Start_Memo_PDF.rar

Start_Memo_Word.rar

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

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

ملحوظة: كتبت هذا قبل أن أرى الرد الثاني:

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

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

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

Conceptual design

Logic design

Physical design

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

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

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

1. المستوى الفيزيائي (physical level).

2. المستوى المنطقي (logical level).

3. مستوى المعاينة (view level)، ومن الممكن تسميته conceptual level.

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

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

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

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

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

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

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

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

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

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

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

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

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

أخى أحمد

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

تحياتى

محمد ندا

تعقيب الحلقة (12)

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

أنا على أتم إستعداد على المواصلة بإذن الله وأسأل الله أن أكون عند حسن الظن بى وأن أكون أهلاً لهذه الثقة التى أوليتنى إياها ..

ولكن فقط لى اقتراح بسيط:

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

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

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

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

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

فى نهاية التعقيب:

أنا فى انتظار ردك على ما أرفقته فى تعقيبى الثانى على الحلقة (11) حتى أعرف ما يجب فعله تالياً.

تحياتى

محمد ندا

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

تقبل مروري...

أخى أحمد...

واضح أنك مشغول بالبيت الجديد ... بارك الله لك فيه ونحن فى الانتظار.

تحياتى

محمد ندا

أخى أحمد

طالت غيبتك .. وقلقنا عليك .. لعلك غير متصل بالانترنت بسبب الانتقال للمنزل لجديد.

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

تحياتى

محمد ندا

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

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

ثانياً: أشكر جزيلاً الأخوين محمد ندا وgabbary على مشاركتهما واقتراحاتهما التي أرجو أن يتفاعل معها بقية الإخوان...

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

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

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

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

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

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

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

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

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

التنسيقات المختلفة للملفات حسب المبرمجين، توزع البيانات في ملفات مختلفة، المعرفة الدقيقة لتنسيق البيانات في الملفات، كل هذا يجعل حياتك جحيماً، لكنه ليس كل شيء. هناك أنواع أخرى من الــ inconsistency هذه التي تنشأ من الوصول المتزامن لأكثر من مستخدم لنفس الملف. مثلاً، تمت قراءة مديونية العميل السليماني من ملف المديونية من قبل برنامجين مختلفين (لنقل (100000)، في البرنامج الأول تمت إضافة عملية شراء بالآجل، مما زاد المديونية (5000)، وفي العملية الأخرى تم تسديد بعض المديونية (40000)، لكن كلا من البرنامجين قد قرأ القيمة القديمة للمديونية (100000)، والبرنامج الأول أضاف إليها قيمة الفاتورة (105000)، أما البرنامج الثاني فقد خصم منها قيمة السداد (60000). الحاصل أن واحداً منهما سيكتب نتيجته ثم يكتب البرنامج الآخر نتيجته. النتيجة الأخيرة ستمسح الأولى لكنها خطأ (النتيجة الصحيحة 65000)! الــ inconsistency هنا تعني اختلاف قيمة المعلومة في الملفات عن قيمتها الحقيقية في الحياة الواقعية. أخطاء مثل هذه قد تنشأ أيضاً بسبب عدم توفر الذرية (ترجمة غريبة لـ atomicity). هذا يعني أن انقطاع الكهرباء مثلاً قد يؤدي إلى تمام بعض العمليات وعدم تمام البعض الآخر، في حين أن هذه العمليات كلها يجب أن تتم معاً أو لا يتم شيء منها على الإطلاق. طبعاً الافتراض في هذه التسمية أن الذرة هي أصغر جزء غير قابل للتقسيم. إذا كنت ترحل القيد مع إدخال الفاتورة فأنت لا تريد أن يتم إدخال الفاتتورة بدون ترحيل للقيد مثلاً.

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

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

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

حمداً لله على سلامة العودة أولاً.

ثم دعنى أقرأ الحلقة (13) وأعود إليك بعد القراءة.

تحياتى

محمد ندا

تعقيب على الحلقة (13)

أخى أحمد أطال الله فى عمرك وبارك لك فيه.

أولاً: دعنى أنا أتسائل .. هل أنت ....... ؟

مش عارف بدأت أشك فى ذلك .... لأن هذا الأسلوب الذى يزداد كل يوم روعة وجمالاً حرى بالأدباء والإعلاميين وليس بالــــ اللى بالى بالك.

ثم أما بعد..

فقد كانت الحلقة (13) رائعة كسابقاتها ونحن بانتظار الحلقة التالية.

وعلى فكرة:

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

تحياتى

محمد ندا

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

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

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

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

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

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

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

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

برامج إدارة قواعد البيانات العلائقية يجب أن تكون علائقية. هذا يعني أن أصول ومبادئ النموذج العلائقي تطبق على قاعدة البيانات وعلى برنامج إدارته. هذا ما كافح Codd من أجل فرضه، خاصة بعد محاولة بعد الشركات مجرد تعديل برامجها الموجودة من قبل لتصبح برامج إدارة قواعد بيانات علائقية. وضع Codd مجموعة من القواعد (ترقيمها من صفر إلى 12) لتصبح معياراً يحكم على برنامج إدارة قواعد البيانات إن كان حقاً RDBMS (Relational Database Management System). نحن هنا لاتهمنا هذه القواعد، وسنتركها لمصممي برامج إدارة قواعد البيانات، لكننا سنتعرض لبعض القواعد العامة التي تنطبق على قاعدة البيانات نفسها، والتي تشكل مبادئ أساسية لأي قاعدة بيانات علائقية. هذه المفاهيم هي فكرة المفاتيح وفكرة المجال و وأنواع العلاقات وقواعد التسوية، وأخيراً قواعد التكامل. كل واحدة من هذه الكلمات لا أشك في أنها على الأقل تمر عليك كثيراً (أو أنني أشك؟). بالمناسبة، بعض القواعد التي وضعها Codd كانت من الصرامة بحيث أنها لم تطبق حتى في أشهر برامج قواعد البيانات العلائقية، لكن الحياة تمضي كما تعلم...

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

1. موجودة.

2. فريدة.

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

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

1. صغيراً قدر الإمكان.

2. ثابتاً قدر الإمكان.

3. بسيطاً قدر الإمكان.

4. مألوفاً قدر الإمكان.

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

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

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

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

مشكور وما قصرت موضوع ومعلومات في غاية الأهمية وتشكر عليها وننتظر إبداعااااااااااااااااااااااتك

تحياتي

أخى أحمد ...

مرحباً بالحلقة (14) ... والإبداع الذى أصبح معتادا منك.

وأشكرك على السماح الكابتشينو .. وتفضل معى يا أخى.

بالنسبة للحلقة فقد قرأت نصفها .. لأننى أرغب فى القراءة بتركيز وليس على عجل كما هو حالى الآن.

وسوف أكمل عندما أنتهى من عمل ضرورى أقوم به خاص بشركتى (أقصد التى أعمل بها).

تحياتى

محمد ندا

ماشاء الله تبارك الرحمن..

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

دورة مبهرة جداً..

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

بورك ماكتبت .. :clapping:

تحياتي ..

اختك..

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

الأخت نبراس الهاشمي: وإياك جزى الله خيراً، وجعلني عند حسن الظن...

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

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

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

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

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

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

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

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

الاخ الاستاذ احمد

سلام عليكم ....

بارك الله في جهودك الطيبة ...

انا من ثلاثة ايام اقراء صفحات التي كتبها الاستاذ Internetmaster وهي تقريبا 24 صفحة والتي بحق غيرت افكاري عن قواعد البيانات وطريقة تعاطينا معها وها انا اليوم اقرء ما كتبت وشدني الاسلوب نفسه ولكن اقول لك وبصراحة خاب املي في نهاية موضوع الاخ استاذ الانترنت لانه بدا فعلا في تطبيقات متقدمة مثل واجهات الادخال والاخراج بلغة html وفجاءة توقف واقفل الموضوع في حينها ارجو ان لا تخيب من هو مثلي واستمر وبارك الله فيك وحاول التوسع بهذا السؤال العميق وانا اجاوب عن نفسي انا كنت اظن اني مبرمج قواعد بيانات ولكني مخطا؟؟؟؟؟ ولكن ارجو وضع المخطئين على الجادة الصحيحة ومثل ما قال احدهم " اذا بدائت امرا فأتمه "

تقبل مروري واحترامي ...

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

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

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

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

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

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

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

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

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

الخلاصة أن هذه العلاقة تقتضي وجود نفس المفتاح الأساسي في جدولين...

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

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

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

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

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

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

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

اعتذر عن غيابي لانشغالي

أخي احمد لك مني كل التقدير والاحترام طرحك جميل جدا ونتمنى الخوض أكثر واكثر فنحن معك دائماً واقول للأخ robotic لا تستعجل فنحن لا نزال في أول السطر

للكل تقديري واحترامي.

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

بارك الله بهذا المجهود الطيب الذي لطالما انتظره كثير من الإخوان. ولكن عندي طلب صغير وهو أن تشرح لنا ولو بشكل مبسط عملية Normalization & Denormalization وأشكرك أخي على هذا العمل وجعله الله في ميزان حسناتك.

أخوك

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

الأخوان gabbary و Abo Ahmed، جزيتما خيراً، وجعلني الله عند حسن ظنكما...

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

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

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

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

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

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

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

رقم الفاتورة	   تاريخ الفاتورة	   اسم العميل	   هاتف العميل	   رقم الصنف	   اسم الصنف	   الكمية	   السعر	   الإجمالي

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

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

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

الاستاذ أحمد المحترم ..

سلام عليكم ..

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

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

وانا من المتابعين ...

بالنسبة لسؤالك المطروح انا عملت قاعدة بيانات مخازن ومبيعات يتكون فيه جدول الفاتورة من نوع One وجدول الاصناف المباعة من نوع Many ويكون المفتاح الاساسي رقم لا يمثل رقم الفاتورة مجرد ترميز للفواتير وليس ترقيم تلقائي وانما برمجيا يكتب بنموذج الادخال ....

فهل في ذللك عيبا ؟؟؟

تقبل مروري واحترامي

أخى أحمد

أعتذر إعتذاراً شديداً عن غيابى لفترة عن السلسلة .. ولكن كان خارجاً عن إرادتى.

وطبعاً كنت أنا الخاسر ولست أنت .. فأنت تطرح علماً نافعاً لنا ونحن المستفيدون.

وإن شاء الله أنهى اليوم قراءاة ما فاتنى.

تحياتى

محمد ندا