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

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

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

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

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

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

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

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

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

1. يكون الجدول في الشكل السوي الأول First Normal Form (1NF) إذا كانت قيم كل أعمدته ذرية atomic، ولم تكن هناك مجموعات مكررة من الأعمدة.

2. يكون الجدول في الشكل السوي الثاني Second Normal Form(2NF)إذا كان في الشكل السوي الأول، وكل الأعمدة غير المفتاحية معتمدة تماماً على كامل المفتاح الأساسي.

3. يكون الجدول في الشكل السوي الثالث Third Normal Form (3NF) إذا كان في الشكل السوي الثاني، وكل الأعمدة غير المفتاحية مستقلة بعضها عن بعض.

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

دعنا نعود إلى موضوع الفواتير مع الأصناف، ولنفترض أن طالباً مبتدئاً جداً (ربما في سنته الأولى) فكر ثم قدّر ثم جاء بالتصميم التالي لجدول الفواتير:

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

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

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

رقم الطالب		  اسم الطالب		  مادة1		  مادة2		  مادة3		  مادة4		  مادة5		  مادة6		  مادة7

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

رقم الطالب	   اسم الطالب	   مادة	   علامة	   مادة	   علامة	   مادة	   علامة	  مادة	 علامة	   مادة	  علامة	  مادة	  علامة

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

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

رقم الكتاب		 العنوان		 الطبعة		 سنة الطبعة		 عدد الصفحات		 عدد النسخ		 تصنيف1		  تصنيف2		 تصنيف3

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

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

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

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

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

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

000001				 01/05/2009			   صنف1				5				   85
000001				 01/05/2009			   صنف2				1				   300
000001				 01/05/2009			   صنف3				3				   100

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

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

الاسم		 تاريخ الميلاد		 محل الميلاد		 العنوان		 التليفونات 1، 2، جوال		 المؤهل	  خبرة1	  خبرة2	  خبرة3	   اللغات

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

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

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

أخي الكريم سامحني لعدم متابعتي لك في اليومين الماضيين فأنا لا أستطيع أن أدخل إلى الإنترنت إلا من خلال عملي لأن بيتي في منطقة وعملي في منطقة أخرى.أما من ناحية الجدول الأخير الذي وضعته أل يجب أن ينبثق جدول للتليفونات يكون مرتبط بحقل التليفون الموجود في الجدول الأساسي بحسب 3d normal form

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

زد بارك فيك متابعين ......

أسأل الله عز وجل أن تكون بخير

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

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

أشكرك من قلبى على ما أعتبره إطراءاً لا أستحقة.

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

والآن ننتظر منك الحلقة التالية.

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

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

فبنظرة سريعة نجد أن عدد القراءات فى مدة حوالى (50) يوم تعدى (2690) وهو ما يعطى متوسط يزيد عن (50) قراءة باليوم الواحد.

تحياتى لشخصكم الكريم وسعيكم العظيم .. ولعل الله يجعل لك بكل حرف حسنة والله يضاعف لمن يشاء.

تحياتى

محمد ندا

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

أشكر أخوينا Robotic وAbo Ahmed على تفاعلهما ومشاركتهما، كما أقول للأخ الكريم محمد ندا: كلماتك قد دفعت في نفسي طاقة أخرى، يبدو أننا أمام مدير إداري ماهر بالفعل...

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

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

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

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

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

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

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

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

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

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

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

أكرر: ما زالت هناك تصحيحات تنتظر كلامنا عن الشكل السوي الثالث بإذن الله...

أنت ترى، كل التسهيلات الممكنة تقدم لتدفعك للمشاركة، لكنك أثبت عن جدارة أنك رجل مبادئ: لا مشاركة يعني لا مشاركة! على الأقل، هل أجبت عن السؤال: هل أنت.........؟

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

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

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

أما بالنسبة للجداول الطلاب طبعاً فجدول العلامات يكون many to many , junction table بين جدولي الطلاب والمواد.

ويا ليت الأخ محمد أن يعطينا أفكار تتعلق بشؤون الموظفين.

وأخيراً يا إخواني بارك الله بكم .

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

الحمدلله والصلاة والسلام على رسول الله وعلى آله وصحبه أجمعين

مش عارف ابدأ منين:

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

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

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

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

بس الحاجة المهمة جدا (وانا عارف انك عارفها بس استحملنا بقى شوية ولا احنا بس اللى لازم نستحملك :) ) آآه الحاجة المهمة انك بتكتب الموضوع ده مش عشان النهاردة وبكرة انما انت بتكتبه عشان يبقى مرجع ان شاء الله - أيوة مرجع كأنك بتألف كتاب وخلى بالك الموضوع دسم شوية واحنا مش واخدين على كدة - احنا بنحب التيك اواى :P

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

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

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

اللى عايز اقوله يا عمنا ببساطة :

الموضوع دسم جدا ، لازم عشان نشارك نتابعه من الأول ، التمارين رائعة ، انت سكرة.

سر على بركة الله ، وخير الناس أنفعهم للناس ،

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

م ل ح و ظ ة (على هيئة فرق تسد) :wink:

ان شاء الله هارد عليك فى التمرين لو لحقت النهاردة.

جزاك الله خيرا

أخوك

slave

تعقيب على الحلقة رقم (19)

أخى الرائع أحمد ... أشكرك مراااات أخرى على مجاملاتك لى.

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

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

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

تحيات مشفوعة بشكر خاص لشخصك الكريم .... وفى انتظار حلقتك القادمة.

ـــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــ

أخى Abo Ahmed

اقتباس

ويا ليت الأخ محمد أن يعطينا أفكار تتعلق بشؤون الموظفين.

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

ـــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــ

..

أخى الكريم Slave

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

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

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

مرة أخرى تحياتى لك.

محمد ندا

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

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

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

وأشكركم جميعاً على سعة صدوركم وصبركم علينا.

أخوكم

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

كيف الحال يا اخواني واساتذتي وان شاء الله انتوا بالف خير وسلامه

حاب اشكر الاستاذ احمد على تقديمه وشرحة الرائعة وادري انها قليله على وصفه

والله ان شاء الله يرزقك ويبارك فيك على المجهود الكبير هذا واعانك على فعل الخير وبذل العطاء لاخوانك في منتدانا الغالي

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

واسمح لي بالمشاركة

بخصوص تحديد نظام قواعد البيانات افترض ممكن نعمل دمج لهم لو امكن يعني مثلا سوبر ماركت فيه كل ما يخص البيع الشراء وايضا فيه ما يخص بيانات الموظفين

من عناوين ومؤهلات واجازات وخلافه لارضاء الطرفين فكرة صح

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

يتم عمل جدول جديد للبيانات المكررة مثلا في جدول الموظفين المسمى الوظيفي او عنوان السكن او البلد المؤهل الدراسي يتم عمل لهم جداول منفصله لتفادي التكرار

والاخطاء عند ادخال البيانات وهكذا

اما بخصوص جدول المكتبة اتوقع الحل كالتالي

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

ويعطيك الف عافية ان شاء الله والله يبارك فيك

اخوك محمد المسيفري

أخى أحمد مبارك الحيقى.

نرجو أن تطمئننا عليك وعلى أحوالك.

وهذا ليس أى شكل من أشكال الاستعجال ولكنه فقط اطمئنان عليك.

فنحن على علم سابق أن الحلقة التالية ستتأخر قليلاً ونحن فى الانتظار .. فقط نطمئن

أخى مشارف ...

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

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

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

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

على العموم ما زال الطريق مفتوحاً للاختيار..

تحياتى

محمد ندا

أخى الكريم Same7 Mo3az

مرحباً بك فى الحلقات زميلاً ومشاركاً.

وأشكرك على كلماتك الجميلة.

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

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

مرحباً بك مرة أخى وأمتدح لديك المثابرة حتى وصلت إلى هنا.

تحياتى

محمد ندا

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

جزيت خيرا أخى الحبيب "محمد ندا " وبارك الله فيك انت وجميع الإخوة المتابعين معنا فى هذا الموضوع

وبالطبع لا أنسى صاحب الموضوع جزاه الله خيرا :clapping: :clapping: :clapping:

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

إشتقنا لك أخى الحبيب أحمد :hmm: :hmm: :hmm:

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

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

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

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

اقتباس

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

على الرغم من أن لي بعض التحفظ على رأيه بعصير الليمون، لكن أؤكد على قول محمد ندا:

اقتباس

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

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

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

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

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

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

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

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

ربما سيبدو واضحاً أكثر عندما نناقش بإذن الله مخطط الكائنات والعلاقات ERD (Entity-Relationship Diagram) كيف أن التصميم الأول يرجع إلى معاملة التصنيف كخاصية من خصائص الكتب (خاصية متعددة القيم multi-valued property)، أما التصميم الثاني فينشأ عن معاملة التصنيف ككائن مستقل له رقم واسم. في الحالة الأخيرة تكون العلاقة بين كائن الكتب (وبالتالي جدول الكتب)، وكائن التصنيفات (وبالتالي جدول التصنيفات) علاقة متعدد إلى متعدد، ولذلك نجد جدولاً وسيطاً هو تصنيفات الكتب لتمثيل هذه العلاقة في قاعدة البيانات. كلا التصميمين قد تم الوصول إليه عبر اتباع قواعد التسوية حتى الشكل السوي الثاني.

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

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

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

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

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

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

عليك أنت أن تكمل تطبيق الشكل السوي الثالث على جدول الطلاب.

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

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

قبل قراءة الحلقة رقم (20)

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

من خلال هذه المشاركات الرائعة (جزاك الله خيرا)

ولكن ما أرجوه هو ألا تطيل علينا غيبتك مرة أخرى حتى وإن كانت مشاركة عادية منك (نحب أن نتابعك فى كل الأحوال) وجزاك الله خيرا

الآن أعود لقراءة الحلقة :thumb_up: :thumb_up: :thumb_up:

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

عودُُ ُُ أحمد لأخينا أحمد ...

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

ثم أما بعد ....

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

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

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

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

وربما كنت أول من يعترف ... والآن أؤكد (بس ما تسألنيش تانى علشان الإحراج ... من الآن فصاعداً ممكن تسأل الآخرين) أؤكد .. أنا لست ......

تحياتى

محمد ندا

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

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

لك منى التحية.

والتحية لأستاذنا أحمد مبارك الحيقى ...

محمد ندا

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

الله يشفي مرضانى ومرضى المسلمين اجميع

ما اتشوف شر اخوي وان شاء الله دايم بخير وصح دايمة

ويسهل عليك مشاغلك ويسرها في وجهك

انا فعلا كنت اتعامل مع الجدول المستوى الثالث بس كلها بدون ارقام يعني البيانات الي لازم اعملها جدول لحالها بسبب التكرار واهي في نفس الوقت

تتكون من حقل واحد كنت اسوي لها جدول بس من حقل واحد من غير رقم مثل جدول البلد

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

هل نضعه في الجدول او نضعه في استعلام لانه حقل محسوب

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

سلامات اخي العزيز احمد شفاك الله وعافاك من كل مرض ونسأل الله عز وجل ان يشفيك وجميع مرضى المسلمين اللهم آمين ...

بارك الله بك على هذا المجهود الكبير وعلى هذا الطرح الجميل ....

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

والشكر والدعاء موصول للاخ محمد ندى مدير هذه المشاركة ولمن شارك من الاخوة الكرام..

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

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

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

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

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

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

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

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

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

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

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

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

ما شاء الله عليك كل ما اقراء اشتاق للحلقة الي بعدها

انا متابع الموضوع واعتبرني احد التلاميذ وعن اذن مدير الحلقة محمد ندى

تعقيب على الحلقة رقم (21)

مرحباً أستاذنا أحمد مبارك الحيقى...

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

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

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

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

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

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

تحياتى

محمد ندا