Lesson3

Lesson3

(Explain Mr. Codd’s Relational Database Rules)

(شـــــــرح قوانين مستر كودّ لنظام قواعد  البيانات العلائقية)

 

بسم الله والصلاة والسلام على رسول الله,

شرح مبادئ او قوانين قواعد البيانات العلائقية (Relational Database Concepts Or Rules):

بعد أن إطلعنا معاً بإمعان على قوانين مستر كودّ لقواعد البيانات العلائقية وأعطيتك الفرصة فى أن تفهم ماذا يقصد تحديداً بنفسك فقد حان الوقت الأن لنضع حداً فاصلاً يُصحح لك معلومة من الممكن أن تكون فهمتهاً بشكل خطأ خلال قراءتك للقوانين أو تفسير وشرح الأمر كُلياً لتستريح نفسياً, سنبدأ معاً قانوناً يلي الأخر, فلنبدأ:

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

شرح القوانين أو المبادئ:

1 – كل وحدة من وحدات قاعدة البيانات توضع بجدول مستقل تُعبر محتوياته (حقوله Fields) عن البيانات الخاصة بتلك الوحدة ولا تحتوي على اي من البيانات سوى بيانات تلك الوحدة فقط.

المقصود هنا أن تُقسم قاعدة البيانات إلى وحدات مُنفصلة ومستقلة على عكس ما كانت عليه فى عصر قواعد البيانات المُسطحة (Flat Database) حيث أن تلك الوحدات تعبر عن محتوى كل قسم من أقسام قاعدة البيانات على أساس مجالها وطبيعة بياناتها, مثالاً على ذلك وليكن نحن الأن بصدد القيام بإنشاء قاعدة بيانات لمركز طبي فعلى أساس المجال التي تُنسب له قاعدة البيانات يتم تحديد كل شئ. سيراً على مثالنا دعني اسألك سؤالاً: مما يتكون المركز الطبي؟

من المُمكن أن تُجيب بـ:

-أطباء.    –ممرضات.   –عمال نظافة.    –مُحاسبين.    –عيادات.    –أقسام.    –مرضى.    –حالات.

قد يكون طرأء بعقلك الأقل او الأكثر مما ذكرت ولكن لا بأس أبداً لن نختلف, ولكن دعني اعقب على نفسي قبل أن أُعقب عليك فى أمراً فى شدة الخطورة والأهمية, وهو ألا ننظر ونتعامل مع قاعدة البيانات كما يُمكن أن يتعامل أو ينظر إليها عامة البشر –أقصد بعامة البشر اي الذين لا ينمون لقواعد البيانات بصلة- فأنا وأنت الأن نتبع شريحة معينة من مجالات الحياة ويُطلقون علينا مُسمى “مبرمجي قواعد البيانات” فيجب أن تُفكر كمبرمجاً وليس مُستخدماً… ما هذا الأزدحام؟!. لا لا الأمر فى غاية البساطة فحينما ننظر نحن لقاعدة بيانات المركز الطبي مثلاً ليس لدينا فرق ما بين ممرض وطبيب ومحاسب وعامل نظافة فكل هؤلاء لهم مُسمى واحد لدينا ألا وهو “موظفين” إذن ستكون لدينا  وحدة واحدة فقط تُسمى بوحدة الموظفين وتحمل بين طياتها بيانات جميع الموظفين بكافة وظائفهم.

ولكن سؤالاً:

إذا قمنا بعمل وحدة واحدة فقط للموظفين بكافة وظائفهم .. تمام.

ومن الطبيعي أنه لدينا فى ذلك المركز أكثر من طبيب وأكثر من ممرض وأكثر من محاسب و و …. تمام.

ومن البديهي أننا سنضع لكل من هؤلاء الموظفين الوظيفة التي يَشغلُها داخل البيان الخاص به….تمام.

إذن لو كان لدي مثلاً 4 أطباء فسأقوم بتكرار وظيفة الطبيب لكل بيان من بيانات الأطباء 4 مرات كالتالي مثلاً:

أليس كذلك؟!

هُنا دعني أخبرك أنه بالمثال الذى بالجدول السابق قد إنهار تكامل وترابط قاعدة البيانات كُلياً,…. لما؟!!!

 هل تذكر معي القانون الثاني من قوانين السيد كودّ؟

2 – ممنوع منعاً باتاً وجود أي نوع من أنواع التكرار للبيانات الخاصة بتلك الوحدة.

إذن فما الحل هُنا؟!

الحل أن نقوم بإنشاء وحدة منفصلة تماماً للوظائف كما أخبرنا مستر كودّ فى أول قوانينه ويسري عليها ما يسري على ما قبلها من منع تكرار البيانات فالقانون الواحد يتم تنفيذه على أي وحدة مهما كانت, فالأن سنقوم بإنشاء وحدة للموظفين لا تحتوي إلا على بيانات الموظفين ولا يتكرر فيها بيانات, و وحدة مُنفصلة تماما أيضاً للوظائف لا تحتوى إلا على بيانات الوظائف فقط ولا يتكرر أيضاً فيها بيانات (فأحد قوانين السيد كودّ الخاصة بالوحدات يسري على أي وحدة من وحدات قاعدة البيانات ولو حتى وضعت لك كفيها على وسطها وقالت “أنا وحدة ونص!”).

ولكن سؤال من فضلك…تفضل بكل سرور: إذا كانت الان لدينا وحدتين, الأولى للوظائف والأخرى للموظفين وكما صدعتني سيادتك بحديثك أن كل منهما منفصل عن الأخر تماماً ولا يحتوى على بيانات اي من الأخر كيف يُمكنني أن احدد لكل موظف وظيفته مادام قد انفصلت الوظيفة عن بياناته؟!

جـ- “بصوت وشوشة”:  العلاقااااااات…. J ولكن دعك منها الأن ولا تُخبر أحداً سنتكلم عنها فيما بعد.

بالمناسبة بما أني قد صدعتك بالحديث عن إنفصال وعدم تكرار البيانات داخل الوحدات –ويُمتعني ذلك جداً J- سوف نكتفي فقط خلال حديثنا إلى حد معين من قوانين السيد كودّ بالتعامل مع وحدتي الوظائف والموظفين.

ولكن هُناك نقطة داخل القانون الأول لم ننتبه لها الكثير مع أنها فى شدة الأهمية والخطورة, الا وهي أن الوحدة (تُعبر محتوياتها (حقولها Fields) عن البيانات الخاصة بتلك الوحدة)  السؤال الحكيم هنا وما هي تلك الحقول؟, الحقول هي المُكون الحاضن للبيانات داخل الوحدة أو الجدول فإذا كانت الوحدة قطار فالحقول هي عربات القطار ولا تحتوي عربات القطار إلا على الركاب فقط (بيانات الوحدة) ومن الطبيعي ان الراكب فى القطار لا يركب القطار مرتين فى نفس الوقت إلا إذا حمل مرءأه كبيرة بجانبه ورأى نفسه إثنين!  –لتعلم أن قوانين كودّ قد وصلت حتى لمنطق القطارات- ولكن ما هي الحقول الخاصة بكل وحدة إذن؟!

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

جـ- بكل بساطة ما يُمكنك أن تسأله لصديقك الصدوق حينما تعلم أنه قد حصل على فرصة عمل جديدة –ويحترق قلبك حقداً J (أعوذ بالله من الحقد)-.

 فى مصر مثلاً نقول:

 اشتغلت ايه؟, وبتعمل ايه؟, وبتاخد كام؟… أليس كذلك

ولكن بأسلوب منهجي سنقول:

-الأســـــــــم الوظيفي (Job Title).

-الوصف الوظيفـــي (Job Description).

– الأجـر الشــــــــــــــــهري (Job Salary).

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

إن كان عقلك بدأ يتأثر فعلاً بمنطق قواعد البيانات وكنت أحد مبرمجي قواعد البيانات الواعدين فعلاً بالمستقبل بإذن الله لكنت لاحظت شيئاً فى الثلاثة حقول التي حددناها فى المثال السابق لوحدة الوظائف, هل يُمكنك أن تُخمن ذلك وتؤكد لي أنك أحدهم فعلاً؟!…. فكر قليلاً.

جـ- القانون الثالث يا سيادة المبرمج:

3 – لابد أن تتميز كل وحدة من الوحدات أو الجداول بحقل أساسي ويُفضل دائماً أن يكون حقل واحد فقط (ذلك الحقل يُسمى بالمفتاح الرئيسي أو المفتاح الأساسي للجدول Primary Key Field).

أين الحقل الاساسي! –لا تنزعج إن لم تتمكن من ملاحظته قبل الإطلاع على القانون, فتلك كانت مُحاولة لإثارتك فقط, أنت بالفعل مبرمج ناجح بإذن الله J- نعم الحقل الأساسي للجدول ويتضح لنا من أسمه ومن صيغة القانون الثالث أنه يُميز بيانات تلك الوحدة جميعاً حيث أن البيان الذي سوف يُدخَل بحقل المفتاح الأساسي (Primary Key Field) للجدول أو الوحدة سيكون بمثابة عنوان كل بيان على حدة, معني ذلك أنه لو لدي داخل الوحدة مثلاً مليار بيان سيحتوي الحقل الأساسي على عنواناً يُميز كل بيان من المليار بيان؟!!!……….. نعم.

ولكن كيف ذلك؟!

دعني أسألك سؤالاً بسيطاً, ما هو المنطق الموجود بحياتنا يتميز كل محتوى بداخله عن الأخر؟!

جـ- بكل بساطة, منطق الأعدادJ, يتسلسل من 0 الى ما لا نهاية وكل رقم داخل النظام يتميز عن غيره, أليس كذلك؟!

وأُبشرك أيضاً أن الشااائع بل والعـام لحقل المفتاح الأساسي للوحدات يكون رقمي القيمة (تحتوي بياناته على أرقام فقط), إذن فلو قمنا بتصحيح محتويات او حقول الوحدة السابقة –وحدة الوظائف- سنقول

-رقـــــــــم الوظيفـة (Job ID).                                                            Primary Key Field>>

-الأســـــــــم الوظيفي (Job Title).

-الوصف الوظيفـــي (Job Description).

– الأجـر الشــــــــــــــــهري (Job Salary).

أعتقد الأن أنه يُمكنني أن أقول تلك الوحدة لا بأس بها أبداً حيث قُمنا بتطبيق ثلاثة قوانين من قوانين السيد كودّ عليها, ولكن ماذا عن القانون الرابع… هيا.

4 – لا يُسمح أبدأ بتكرار بيانات الحقل الأساسي او الرئيسي للجدول أي كل سجل للمفتاح الأساسي يحتوى على بيانات مُختلفة عن الأخر. 

بالضبط كمنظق النظام العددي فإذا طلبت من سيادتك أن تقوم بالعد من 1 إلى 10 لن تقول مثلاً 3211 فلقد كررت هنا الرقم 1 وهذا يتنافى مع منطق الأعداد وكذلك المفتاح الأساسي للجدول, وأيضاً لن تقول مثلاً 3,2,1,فراغ,6,5,4 فليست هناك فراغات بين عدد والأخر وكذلك أيضاً المفتاح الأساسي لا يُمكن أن يكون فارغاً, وكذلك من الطبيعي أنك لن تقول مثلاً 1,!,4,3,2 فمن البديهي أني سأسئلك ما هذه القيمة الغير معلومة داخل النظام العددي وكذلك سيسألك حقل المفتاح الأساسي إذن لا تكرار, لا فراغات ولا قيم غير معلومة أو لا تنم لنوع بيانات الحقل الأساسي بصلة.

وبالمناسبة نقطة الفراغات والقيم الغير معلومة فى الفقرة السابقة قد إحتوت القانون الخامس:

5 – لايُسمح أبدأً بوجود فراغ داخل بيانات الحقل الأساسي أو يتم إدخال قيم غير معلومة.

وتلك هدية مني إليك J.

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

Data Normalization

أو تطبيع البيانــــــــــــات (جعل البيانات فى شكل طبيعي ومنطقي)

ومفهوم Data Normalization يتحقق بالإمتناع عن شئ مـا والوصول إلى الأخر.

الإمتناع عن التكرار (Duplicate) أو الكابوس الرهيب الذى يراود أحلام قواعد البيانات.

 والوصول الى التكامل (Integrity) الهدف النهائي التي تسعى إليه أي قاعدة بيانات فى العالم.

ويُمكن بكل بساطة تحقيق التكامل او الـ Integrity داخل قواعد البيانات بشئ بسيط جدا وهو إتباع قوانين السيد كودّ بدقة.

6 – يُعتمَد فرضاً شيئاً يُسمى بالعلاقات ما بين بيانات الوحدات مع بعضها (أهم بل أساس قوانين السيد كودّ).

إن أمعنت النظر فى القانون السابق لوجدت لأول مرة كلمة “علاقات” والتي تُشتق وتتشابه إلى حد كبير للمفهوم العام المُسمى بـ “قواعد البيانات العلائقية” إذن فلتدُرك فعلاً أنه من أهم قوانين قواعد البيانات العلائقية ولكنه أيضاً ليس بصعباً تماماً, دعنا نتحدث عن كلمة علاقات البيانات!.

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

بعد تلك الحالة من الهلوسة وجدت فجأة أنني قد حصرت لك العلاقات التي أبلغ عنها السيد كودّ فى القانون السابع التالي:

7 – تتصنف علاقات بيانات الوحدات مع بعضها إلى ثلاثة أنواع من العلاقات:

–         واحد لمتعدد أو One To Many (وياريت تحفظها One To Many).

–         واحد لواحد أو One To One (مش هقولك تحفظها ازاي).

–          متعدد لمتعدد أو Many To Many  (!).

فلو تخيلنا معاً أننا نقوم بإنشاء قاعدة بيانات لمنضدات (لا أعلم إن كان جمع كلمة منضدة = منضدات ام لا!) وما يوضع عليها من متعلقات فسنجد أنها علاقة واحد لمتعدد (One To Many) حيث أن منضدة واحدة تحتوي على أشياء عديدة وكثيرة, ولكننا فى منطق ومبادئ قواعد البيانات العلائقية نقوم بفصل الوحدات عن بعضها وننشأ كل منها بشكل مستقل عن الأخر فكيف نُطبق تلك العلاقة بين الوحدتين؟!

هُنا يُمكنني أن أُجيبك عن سؤالك القديم:

   إذا كانت الان لدينا وحدتين, الأولى للوظائف والأخرى للموظفين وكما صدعتني بحديثك أن كل منهما منفصل عن الأخر تماماً ولا يحتوى على بيانات اي من الأخر كيف يُمكنني أن احدد لكل موظف وظيفته مادام قد انفصلت الوظيفة عن بياناته؟!

هل تذكره؟…. سأجيبك, ولكن بعد أن نطلع على القانون الثامن والتاسع معاً:

8 – فى تحديد العلاقات يتم إنشاء حقل جديد غريب (كما سماه السيد كودّ بـ Foreign) داخل الوحدة ذات الصلة بالوحدة الأخرى.

9 – يكون الحقل الغريب (Foreign Key Field) مماثلاً للحقل الأساسي للوحدة الأولى ولا يحتوى إلا على بيانات تكون متواجدة بالفعل للحقل الأساسي للوحدة الأولى ولا يحتوى على فراغات.

لن أخذك بعيداً فى الإجابة وسنتحدث عن الوحدتين التي قمنا بالحديث عنهم سابقاً وأخبرتك بصوت خافت بمفهوم يُسمى بالعلاقات, إن سألتك الأن ما هي علاقة الموظفين بالوظيفة؟!

ولاحظ جمع “الموظفين” ومفرد “الوظيفة” وبالمنطق ستجد أن الوظيفة الواحدة يشغلها أكثر من شخص واحد أي أنها فعلاً وبكل بساطة علاقة One To Many او واحد لمتعدد –نِعم العقل كما يُقال- فبالمركز الطبي ذكرنا أن هُناك أكثر من موظف وكلهم يشغلو وظيفة واحدة تُسمى وظيفة الطبيب. أما بالنسبة لكيفية تطبيق تلك العلاقة بين الوحدات فكما يُخبرنا القانون الثامن أن نضع بالجدول الفرعي (الجدول الفرعي هو الجدول المُحتوي على البيانات المتعددة –كجدول الموظفين بمثالنا- حيث أن الموظفين هم المتعددون لوظيفة واحدة وليس العكس) حقلاً غريباً عن الوحدة او Foreign Key كما سماه السيد كودّ وسُمي غريباً حيث أنه لا ينم لبيانات الجدول المتواجد به بصلة بل ينم إلى جدول أخر له علاقة بذلك الجدول الحالي. وسيكون الحقل نسخة من او مماثل للحقل الأساسي فى الجدول الأخر او الجدول الأساسي (الجدول الأساسي هو المُحتوي على البيانات الواحدة –كجدول الوظائف فى مثالنا- حيث أن الوظيفة الواحدة يشغلها أكثر من طبيب وليس العكس) وأيضاً لا يُمكن أن يحتوي الحقل الفرعي (Foreign Key) على بيانات غير متواجدة بالحقل الأساسي (Primary Key) للجدول الأساسي.

وفي الشخبطة التالية وليس المثال التالي تطبيقاً عملياً بسييط جدا لمثال الوظائف والموظفين:

 

سؤلاً:

ما هو الإسم الوظيفي لوظيفة كل من الموظفين المتواجد بياناتهم بوحدة الموظفين؟!

 

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

جـ-

مُحمد عبد الرحمن  = طبيب

سامية علي السيد = طبيب

كاملة عابد كمال     = ممرض

محمود على طارق  = ممرض

وبالمناسبة لقد انهينا القانون العاشر بالمثال السابق.

10 – فى وجود وتطبيق علاقة One To Many ما بين وحدة والأخرى يتم إنشاء الحقل الغريب داخل وحدة المتعدد (Many) ويكون كما أسلفنا مطابقاً لبيانات الحقل الأساسي الخاص بوحدة الواحد (One) ولا يحتوى على أي بيانات خارجة عن بيانات الحقل الأساسي لوحدة الواحد (One).

وتلك كانت علاقة One To Many –بالشفا يا معلم!-.

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

هل تذكر حالة الهلوسة التي إنتابتني منذ فترة وتذكرت حينها أيام المدرسة وأنا تلميذ؟

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

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

كم بطاقة يحملها الفرد؟, وكم فرد تخص كل بطاقة؟

-حتى لو لاحظت ستجد أنهم قد قاموا بتسميتها ببطاقة “شخصية” أي تخص شخص واحداً فقط ولن تجد رقماً قومياً لفلان ونفس الرقم لعلان -إنسى- إذن الإجابة الصحيحة على السؤالين السابقين = واحد.

فمن اليمين واحد ومن اليسار واحد إذن فهي واحد لواحد إذن فهي علاقة One To One.

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

One To One هي العلاقة الوحيدة التي لا يوضع بها حقل غريب بل يوضع حقل فى وحدة يساويه حقل فى وحدة أخرى فى كلللل شئ -فلو هفت نفس الأول على البطاطا فستجد الأول ينادي: “بطا” ويرد الثاني: “طا”- وكل منهم فى وحدته حقلاً أساسياً وإذا إحتوى الأول على رقماً سيحتوي عليه الثاني فى نفس الوقت بل وإن عطس الأول سيرد عليه الثاني بعطسه وبنفس القوة.

لنأخذ مثالاً ونقوم بتطبيقه وليكن نفس مثال بيانات المواطنين والبطاقات الشخصية أو الرقم القومي.

 

بضعة أسئلة بحاجة إلى إجابة (ولكن لا تعتبر نفسك السائل وسأعتبر انا كذلك أيضاً):

–         لماذا لم نقم بوضع بيانات الفرد داخل بيانات وحدة البطاقات الشخصية؟

   جـ-  ألم تذكر ان الوحدة لا يُمكن أن تحتوي على بيانات لا تخصها؟, وأنه التكرار بمثابة مرض الشلل الرعاش لقواعد البيانات؟!.

–         كيف لا تخصها وهي لنفس الفرد, أليست بعلاقة واحد واحد؟

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

–         بما أن الوحدة الثانية هي للبطاقات الشخصية والبطاقة الشخصية تُقدم للفرد حين بلوغه الخامسة عشر من العمر, والحقلين الأساسيين فى علاقة واحد لواحد يسري عليهم ما يسري على الأخر, كيف يقبل الأول تسجيل الرقم فى حين أن الثاني سينتظر 15 عشر عاماً حتى يتم تسجيل نفس الرقم فيه؟

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

أسألك انا الأن: ما هي جهة إصدار البطاقة الخاصة بـالمواطنين المُسجل بياناتهم فى الوحدات السابقة؟

 

جـ-

محمود عادل محمود = شبرا.

سيد عبد الرحمن  = الهرم.

سامر علي السيد = قرية بالمنصورة.

إلى القانون الأخير.

12 – فى علاقة Many To Many تتم العلاقة خارج الوحدتين بإنشاء وحدة جديدة (تُسمى بـ Junction Table أو الجدول الفاصل للوحدتين –بترجمتي الشخصية-) تحمل حقلين فقط الأول مماثل للإساسي فى الوحدة الأولى والأخر مماثل للأساسي فى الوحدة الثانية وكلا الحقلين معاً يكونا مفتاح أساسي اي يسري على الأثنين معاً ما يسري على قوانين المفتاح الأساسي (لا تكرار, لا فراغات, لا بيانات غير معلومة..) ولايحتوي الأول منهم وكذلك الثاني على بيانات غير موجودة داخل الأساسي له من الوحدة الأخرى.

 

قبل أن أبدأ بشرح القانون الأخير يجب عليك أن تعرف ان السيد كودّ قد ابلغنا بأن لا نستخدم العلاقة Many To Many إلا إذا كُنا مُضطرين لفعل ذلك –يُمكنك أن تقول أنه لم يكن مُقتنعاً بها أو أنه لم يجد حل سواها- حيث أنها أصعب علاقة, وتواجدها قليل داخل قواعد البيانات ولم أقصد بأصعب علاقة أن أوهمك بصعوبتها –صدقني قواعد البيانات ليست بصعبة, فهي لا تحتاج سوى بعض المنطق-, دعنا من الثرثرة الأن ولنعد للخلف قليلاً إلى حالة الهلوسة التي جائتني من قبل هل تذكر المواد الدراسية التي ذكرتها وقتها؟

أسألك الان كم مادة دراسية كنت تدرسها فى المرحلة الثالثة الإعدادية مثلاً؟

-بالطبع أكثر من مادة, رائع جداً.

سؤال أخر: هل كان لكل طالب المواد الخاصة به أم كان طلاب عدة يدرسون نفس المواد فى المرحلة الثالثة الإعدادية؟

-بالطبع أكثر من طالب.

إذن فكنتم أكثر من طالب تدرسون أكثر من مادة, أي طلاب متعددين وكذلك مواد متعددة, أي متعدد لمتعدد, أي Many To Many.

قبل أن نبدأ بشرح كيفية التطبيق أطلب منك طلباً إذا سمحت –بالله عليك أن تنفذه-:

إحضر ورقة وقلم وقم بتصميم وحدتين الأولى لبيانات الطلاب والأخرى لبيانات المواد الدراسية, وطبق عليهم علاقة One To Many, وفي ورقة أخرى صممهم من جديد وقم بتطبيق علاقة One To One, ولكن بعد أن تُدخل بيانات داخل الوحتين –عشرة بيانات تكفي- ولا تنسى أن كل الطلاب يدرسون نفس المواد. اذهب الأن للتطبيق وعُد إلي فى النهاية؟!

كيف حالك بعد المعاناة؟!  J

أأبلغك بما فعلت, لتشك فعلاً أني كنت أُراقبك وأنت تقوم بتصميم الوحدتين؟!

 (أه لو احرجتني وقلت انك لم تقم بتصميمهم أصلاً!)

بالنسبة لعلاقة One To Many :

–          إما إنك كنت شخص عصبي وقمت بتقطيع الورقة وكسر القلم, لأنك لم تجد أي طريقة لوضع رقم كل طالب امام كل مادة او العكس.

–          وإما أنك كُنت شخص عنيد وقد قمت بتكرار المواد لكل طالب على حدة حتى تتمكن من وضع رقم كل منهم أمام كل مادة أو العكس.

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

 

أما بالنسبة إلى علاقة One To One :

–          فإما إن كُنت عصبياً أيضاً-وكان موقفك جيد-.

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

ما الحل إذن, هُنا تُدرك فعلاً انك من البداية كان يتوجب عليك أن تستمع لمستر كودّ ولا تواقفني حينما طلبت منك شيئاً غير منطقياً!.

لم يجد مستر كودّ حلاً لعلاقةMany To Many , سوى إنشاء جدول جديد سماه بـ Junction Table أو الجدول الفاصل, يحتوي ذلك الجدول على حقلين فقط ليس أكثر.

الحقل الأول يكون فرعياً (Foreign) للحقل الأساسي للوحدة الأولى, وأما الثاني فيكون فرعياً للحقل الأساسي فى الوحدة الثانية وكلااااااهُمــــــــا معاً حقلاً أساسياً (Primary Key) أي ينطبق عليهم الإثنين معاً ما ينطبق على قوانين الحقل الأساسي, أي لا تكرار فى الإثنين معاً. لا فراغات فى الإثنين معاً, لا قيم غير معلومة فى الأثنين معاً.

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

 

ركز جدا فى إختيار الألوان فى الرسم السابق, وبعدها أجب على السؤال التالي:

حينما تقابل اللون الـ Magenta مع اللون الـ Dark Green فى الـ Junction Table ماذا كان يقصد البيان؟, أي من هو الطالب ما هي المادة المُنتسبة إليه فى ذلك البيان؟!

جـ-

الطالب: برعي الجن J.

المادة: عربي.

وبذلك نكون قد إنتهينا من القانون الأخير, وكيفية تطبيق علاقة Many To Many. بل وإنتهينا من قوانين السيد كودّ (Mr.Codd’s Relational Database Rules) جميعاً…………….

مبروك.

أسئلة وجيهة جداً:

-حفظنا أنه لا يجوز تكرار البيانات داخل الوحدات أو الجداول, ومع ذلك وجدنا ان الحقل الفرعي يجوز به تكرار البيانات, إليس ذلك بتناقد ما بين للقوانين؟

جـ- لا يا سيدي الفاضل فالتكرار هنا إمكانية لربط رأس بأطرافها يُمكنك تسميتها بأسهم تُشير إلى بيان يخصها, ولكني لا أُخالفك الرأي ان هُناك تكرار للبيانات داخل الحقول الفرعية (Foreign Key). ولكن تكرار رقم يا سيدي الفاضل أفضل من تكرار بيان بأكمله.

تخيل معي لو أننا نقوم بتصميم قاعدة بيانات لخدمة بريد إلكتروني كـ ياهو وهوتميل من الوارد جداً أن تكون رسالة واحدة قصة طويلة عريضة يُرسلها فرداً لصديق ووارد جدا جدا أن يكون هناك صور داخل الرسالة ووارد أيضاً إرفاق ملفات داخل الرسالة فلو توفرت كل تلك الإحتمالات قد يصل حجم الرسالة إلى 10 Mega Byte على الأقل أتكرر رقماً فقط حجمه قد لا يبلغ الـ 10 Kilo Byte أم تكرر بيان يحمل رسالة حجمها 10 Mega Byte؟!

 إن كان جوابك نعم, كيف حال قاعدة بياناتك بعد 5 سنوات أو 10 سنوات؟,

 كم حجمها؟,

 كم حجم التكرار؟,

هل تعرض بياناتها للمُستخدم بشكل صحيح؟ !!!.

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

جـ- فى الحقيقة سؤال راائع جداً, ولكن ما قام به السيد كودّ من إبتكار لقوانين قواعد البيانات العلائقية لم تكن الغاية لديه إستخدام الورقة والقلم وخصوصاً أنه كان أحد الباحثين فى شركة IBM وهي أحد مطوري الحاسب الآلي على مستوى العالم, فالغاية من تلك القوانين كانت لبناء تطبيقات إلكترونية يُطلق عليها Relational Database Management Systems أو نُظم إدارة قواعد البيانات العلائقية, ويتضح لك من كلمة Management أو إدارة أنها نُظم تقوم بإدارة قواعد البيانات بشكل إلكتروني أي أنك ستستخدم الحاسب الآلي في التسجيل والإستعلام عن البيانات وكل ما عليك هو إستخدام ذلك النظام الإداري لقواعد البيانات. وفهمك للقوانين السابقة يُوضح لك كيف يُفكر ويتعامل أي من نظم إدارة قواعد البيانات العلائقية (RDBMS: Relational Database Management Systems).

ومن الأمثلة على تلك النظم:

Oracle

Sybase

DB2

Microsoft Access

Microsoft SQL Server

ولكن لحظة, كل ما ذكرته الأن لن يحل مشكلتك, حيث أن الـ RDBMS لا تعرف مثلا رقم الوظيفة التي تخص الموظف الذي تقوم بإدخال بياناته سيادتك, إذن فهُناك شئ ناقص.

فى الحقيقة نعم.!

إذن كل ما قرأته من قوانين وشرح وصداع ينتهي بشئ ناقص وغير كامل؟

جـ- نعم!,  فى الحقيقة لقد أخفيت عنك شيئاً فى غاية الأهمية طيلة تلك الدروس بل هو المُكمل الأساسي لقوانين السيد كودّ, فإذا كانت الـ RDBMS من الباطن تعتمد على قوانين السيد كودّ, فهي فى الظاهر تعتمد فى التعامل مع قواعد البيانات على ذلك الشئ الذى لم اُخبرك به حتى الأن وذلك بسبب رغبتي اللا إرادية في إثارة عصبيتك دائماً! لا أعلم لماذا.

وما هو ذلك الشئ إذن؟!

إنزل لتعرف

/\

/\

/\

/\

/\

/\

/\

/\

/\

/\

/\

/\

/\

/\

/\

/\

إنزل كمان

/\

/\

/\

/\

/\

/\

/\

/\

/\

/\

/\

/\

/\

/\

/\

/\

/\

/\

/\

فى الدرس القادم إن شـاء الله >> (:

 

Advertisements

اترك رد

إملأ الحقول أدناه بالمعلومات المناسبة أو إضغط على إحدى الأيقونات لتسجيل الدخول:

WordPress.com Logo

أنت تعلق بإستخدام حساب WordPress.com. تسجيل خروج   / تغيير )

صورة تويتر

أنت تعلق بإستخدام حساب Twitter. تسجيل خروج   / تغيير )

Facebook photo

أنت تعلق بإستخدام حساب Facebook. تسجيل خروج   / تغيير )

Google+ photo

أنت تعلق بإستخدام حساب Google+. تسجيل خروج   / تغيير )

Connecting to %s